Updated June 17, 2026 by Sunny Chauhan, Salesforce Platform Developer II.

If your Managed Package has been through the AppExchange Security Review and listed publicly, you're a verified package. That status changes the governor limit math in your favor in a way most ISVs don't fully use. Verified Managed Packages get separate governor limits, set at 11 times the per-namespace allocation, capped at a cumulative cross-namespace ceiling. This is why architecture decisions that look expensive in an unlocked package look fine in a verified one. Here's what changes, and the small set of ISV use cases where it actually matters.

Pro Tip

TL;DR Verified Managed Packages get separate governor limits from the customer's org and from other installed packages. Salesforce sets the per-package limits at roughly 11x the per-namespace allocation, with a cumulative cross-namespace ceiling. Your verified package's 150-SOQL-query-per-transaction limit doesn't draw from the customer's 150 or from another installed package's 150. Matters most for data-heavy ISVs (large SOQL volumes, batch-heavy Apex), high-throughput integrations, and packages that run alongside heavily-customized customer orgs.

A verified Managed Package is one that's passed the AppExchange Security Review. The verification status unlocks the separate-governor-limit treatment Salesforce applies to packaged code. Unmanaged packages and managed packages that haven't gone through the review don't get the same treatment; their Apex runs against the customer's org-level governor limits.

The exact phrasing from Salesforce: "Verified managed packages operate under their own set of governor limits, with Apex code and operations executed within them using separate governor limits that don't affect your organization's total governor limits."

The practical translation: your packaged Apex draws SOQL queries, DML operations, CPU time, and the other governor limits from a pool dedicated to your namespace, not from the customer's org-wide pool.

Salesforce sets per-package governor limits at roughly 11 times the per-namespace allocation. The per-namespace number itself varies by org edition, but the multiplier is consistent. For a standard Enterprise Edition org with 150 SOQL queries per synchronous transaction allowed:

→ The customer's org gets 150 SOQL queries per transaction → Your verified Managed Package gets up to its own 150 per transaction, drawn from a separate pool → Another installed Managed Package gets its own pool too

Three Managed Packages installed in the same org could collectively issue up to (roughly) 450 SOQL queries per transaction without anyone tripping the customer's org-level limit.

There's a cumulative cross-namespace ceiling that caps the total, so you can't stack ten packages and expect unlimited combined volume. The ceiling exists to prevent runaway usage. For most real-world deployments, the ceiling isn't the binding constraint; the per-package limit is.

Not every ISV needs to think about governor limits. If your packaged Apex runs a few queries per page load and writes a handful of records, you're well under any reasonable limit regardless of multiplier. Three use cases where the verified-package treatment changes your architecture:

→ Data-heavy ISVs that batch-process customer records. Conversation intelligence products processing meeting transcripts. Revenue intelligence products processing call data. Anything that runs Apex over large customer datasets.

→ High-throughput integration products that sync large volumes of records to/from external systems. The packaged Apex draws from your own SOQL pool, not the customer's, so your sync doesn't compete with the customer's other batch jobs.

→ Packages that run inside heavily-customized customer orgs. The customer has hundreds of their own Apex triggers, scheduled jobs, batch processes. Without the separate limits, your package would compete with all of that for the org's 150-query budget. With separate limits, you don't.

For ISVs in those categories, the 11x treatment is what makes the architecture viable. For ISVs whose packaged Apex is light, the multiplier is academic.

Salesforce documents a cumulative cross-namespace cap. The exact value varies by org edition and by transaction type, but the pattern is: total combined Apex usage across all installed packages plus the customer's own code stays under a single ceiling.

In practice, the binding cases are:

1/ Customer has 8+ installed Managed Packages, all data-heavy, all running queries in the same transaction. Rare but happens in enterprise orgs.

2/ Customer's own code is already pushing org-level limits, and your package adds enough to put them over the cross-namespace cap.

3/ Heavy synchronous Apex called from your packaged LWC during page render, when the customer's page also calls their own Apex.

For most ISV products in most customer orgs, the cap doesn't bind. You hit your per-package limit before you hit the cumulative limit. If you're architecting for a high-end enterprise deployment, run the math; don't assume.

Three patterns that work in verified packages and don't work in unmanaged code or unverified packages:

→ Heavy batch processing in synchronous flows. You can issue more SOQL queries per transaction than an unmanaged equivalent would allow. Useful when you need to enrich records in real time during page load.

→ Comprehensive query patterns without selectivity tuning. You can write a query that returns more rows than an unmanaged version could afford, because your DML and CPU pool is separate. Doesn't mean you should (efficient queries are still better), but you have more room.

→ Polling and refresh logic that runs alongside the customer's existing Apex. Your package's heartbeat doesn't compete with the customer's batch jobs for SOQL allocation.

The architectural mistake I see most often: ISVs design for the customer's org-level limits when they should be designing for the package's separate pool. They engineer aggressive query batching and caching to fit in 150 queries when they have ~150 of their own. The work isn't wrong, it's just unnecessary.

Two cases where you don't get the multiplier:

1/ Your package hasn't passed the Security Review. Unverified Managed Packages run against the customer's org-level limits.

2/ Your packaged Apex calls into the customer's namespace (via global classes the customer exposed, dynamic Apex, etc.). Once execution crosses into the customer's namespace, you're drawing from the customer's pool.

For new ISVs the first case is the operational reality: until you've passed the review, plan as if you're sharing the customer's pool, because you are.

Appnigma generates 2GP Managed Packages, which become verified after passing the Security Review. The generated code is designed to fit comfortably within the per-package limits without relying on the multiplier as a crutch. The multiplier becomes useful headroom for high-volume customers, not a license to write inefficient queries.

• [ ] Confirmed package will be Managed (not Unmanaged) → Yes / No

• [ ] Planning to submit for Security Review → Yes / No

• [ ] Identified the data-heavy operations that benefit from separate limits → Yes / No

• [ ] Measured current SOQL query count per transaction in dev → Yes / No

• [ ] Considered behavior if your package is installed alongside other heavy packages → Yes / No

• [ ] Documented the limits-related architectural decisions for your engineering team → Yes / No

• [ ] Tested in a sandbox with realistic customer-side Apex load → Yes / No

Verified Managed Packages get separate governor limits set at roughly 11 times the per-namespace allocation, with a cumulative cross-namespace ceiling. Your packaged Apex draws from a separate SOQL, DML, and CPU pool, not from the customer's org-level limits.

A Managed Package becomes verified after passing the AppExchange Security Review. Verification status unlocks the separate-governor-limit treatment Salesforce applies to packaged code. Unverified packages run against the customer's org-level limits.

No. Only verified Managed Packages do. Unmanaged packages and managed packages that haven't passed the Security Review run against the customer's org-level governor limits.

Usually not. For most ISV deployments, you hit your per-package limit (the 11x allocation) before you hit the cumulative cross-namespace ceiling. The ceiling binds when a customer org has many heavy packages installed simultaneously plus their own code.

The review process tests against the package's intended runtime behavior. The reviewer doesn't penalize SOQL volumes that would be valid under the per-package allocation. They will flag inefficient queries that suggest you didn't think about scalability, even if the multiplier covers them.

Tableau Next views ship as metadata, not Apex execution at runtime. The governor limit conversation applies to your Apex controllers backing the views, not the views themselves. Standard verified-package limits apply to the Apex.

For a verified Managed Package post-review, architect around the per-package limits (the 11x allocation). Pre-review and during development, architect conservatively (assume org-level limits) since the package isn't verified yet. Once it passes review, the headroom becomes available.

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. Since launching Appnigma in 2024, his team has helped B2B SaaS companies including Warmly, Hyperbound, Pylon, Seam AI, and Avoma ship native Managed Packages with architectures that respect Salesforce's governor limit model.

Originally published June 17, 2026. Last reviewed June 17, 2026. Governor limit behavior verified against Salesforce Apex Developer Guide documentation and the AppExchange Security Review compliance guidance current as of the published date.

• Salesforce Managed Package: Complete Guide (1GP vs 2GP)

• What is the Salesforce security review

• Salesforce security review checklist

• LWC Licensing in Managed Packages

• Push Upgrade Customization for Managed Packages

• How to build a managed package without a Salesforce developer

1/ Salesforce Apex Developer Guide, Execution Governors and Limits 2/ Salesforce Help, Salesforce App Limits Cheatsheet 3/ Apex Hours, Salesforce Installed Packages Guide 4/ Salesforce Summer '26 Release Notes

What's the SOQL query count per transaction your current architecture assumes, and have you measured what it actually runs?