Governor Limits for Certified Managed Packages, and What the 11x Rule Really Caps

Once your managed package passes the AppExchange security review, its Apex gets its own copy of most per-transaction governor limits, such as 100 synchronous SOQL queries and 150 DML statements, on top of what the customer's own code gets. CPU time, heap size and transaction execution time are not on that list. Your code shares those with every trigger, flow and package running in the same transaction. The "11x" figure is a ceiling on the total across all certified namespaces in one transaction, not a bigger allowance for your package.

For a SaaS company shipping a Salesforce app, that split decides where your package fails in a large customer org. It rarely runs out of queries. It runs out of CPU time the customer's automation already spent. Appnigma's marketplace apps team builds native Salesforce apps with that budget in mind. The service covers "a native app, marketplace listing preparation, and review support." If you are an admin or developer looking for the full list of Apex limits, Salesforce's Execution Governors and Limits page is the reference.

Updated October 2026. Checked against the Apex Developer Guide's Execution Governors and Limits page. This update corrects the earlier version of this post, which said each package gets 11 times the normal limits, that the synchronous SOQL limit is 150, that CPU time is separate per package and that limits vary by edition. None of those hold. It adds the shared-limit list, the cumulative limit table and how to measure your own namespace in a customer org.

Which limits does a certified package get on its own?

Salesforce calls these packages certified. The Apex Developer Guide defines them as "managed packages that have passed the security review for AppExchange" and says they "get their own set of limits for most per-transaction limits." The guide's own example is DML. A certified package's Apex "gets its own 150 DML statements," and those are "in addition to the 150 DML statements your org's native code can execute." The same holds for queries, with the package getting "its own 100-SOQL-query limit for synchronous Apex."

The exceptions matter more than the rule. The same page lists four limits that "count for the entire transaction, regardless of how many certified managed packages are running."

Per-namespace values and the cumulative column both come from the Winter '27 version of the Execution Governors and Limits page. Older guides still list heap at 6 MB and 12 MB. The per-transaction table has no edition column. Org-level allowances such as daily async Apex executions scale with licenses, but the 100-query limit is the same in an Enterprise or Unlimited org.

Read the table as two design problems. Query, DML and callout counts are yours alone once the package is certified, so you can size them from your own code and test them in isolation. CPU, heap and execution time depend on what the customer's org does in the same transaction, so no test in your own org can tell you how much is left.

What does the 11x cross-namespace limit actually cap?

The cumulative limit is a ceiling on the whole transaction, and Salesforce sets it at "11 times the per-namespace limit." The guide gives the arithmetic. With a per-namespace SOQL limit of 100, "a single transaction can perform up to 1,100 SOQL queries." Those can be spread across "an unlimited number of namespaces, as long as any one namespace doesn't have more than 100 queries."

So your package never gets 1,100 queries. It gets 100, and the 1,100 only becomes the binding number when at least 11 namespaces in one transaction each push close to their own cap. That takes a very busy enterprise org. In most installs your own 100 queries are the limit you will meet, and the cumulative cap is a backstop you can note and move on from.

The same note adds that the cumulative limit "doesn't affect limits that are shared across all namespaces, such as the limit on maximum CPU time." There is no 11x version of CPU time.

CPU time is the budget your package shares with the customer

A certified package gets its own query and DML counts, but every millisecond of CPU in the transaction comes from one pool. The limits page says CPU time is counted "for the executing Apex code, and for any processes that are called from this code, such as package code and workflows." Time spent waiting on the database for SOQL and DML isn't counted, nor is waiting for callouts.

Here is the arithmetic that shapes ISV design. It is a worked example from the documented limit, not a measurement. Say a customer's Account update already runs record-triggered flows, two of their own triggers and another vendor's package, and together they use 7,000 ms of CPU. Your package's Account trigger then has 3,000 ms of the 10,000 ms synchronous limit left. If it needs 4,000 ms, the whole save fails with System.LimitException. The customer sees the error on their record, not in your logs. Your package was under every limit that belongs to it.

Three design choices follow. Keep trigger handlers to the minimum work that has to happen in the same transaction. Move enrichment, scoring and outbound sync to Queueable Apex, which runs as its own transaction with the 60,000 ms async CPU limit. And never assume the test org you built in reflects the CPU a real customer's automation uses before your code starts.

Before certification, your package shares the org's limits

Certification is what separates the counters. The Apex Developer Guide says namespaces in non-certified packages "don't have their own separate governor limits," and the resources they use "continue to count against the same governor limits used by the org's custom code."

That covers the pilots and early installs many SaaS companies run before their first security review passes. During that period your 30 queries and the customer's 80 queries share one 100-query budget. Plan for it, test against it, and treat separate limits as something that arrives with the review, not something to build around beforehand. Our security review guide covers what the review checks and how long it takes.

Certification also changes where your package can run. Apex isn't supported in Group and Professional Editions by default, but the ISVforce guide says Apex "included in a managed package can run in GE/PE." The condition is that "your app has to pass the security review." For a SaaS company selling to smaller Salesforce customers, the review decides your market as well as your limits.

One limit doesn't depend on certification. The org-wide 6 MB Apex code size limit "doesn't apply to Apex code in first generation (1GP) or second generation (2GP) managed packages," because that code "belongs to a namespace unique from the code in your org," per the size-specific limits table. Your package's code size never eats into the customer's allowance for their own Apex.

Reading your namespace's limit usage in a customer org

When a customer reports a limit error, the first question is whose budget ran out. Apex debug logs answer it, because the cumulative usage block lists a LIMIT_USAGE_FOR_NS entry per namespace. The Developer Console log reference describes that event as "Namespace and these limits," followed by SOQL, DML, heap and callout counts. The customer's own code appears as (default), and your package appears under its namespace prefix.

The catch for an ISV is that you can't see inside your own package code in the customer's org by default. Salesforce's Debug Subscriber Orgs guide gives two routes. You can "request login access from the subscriber," or "use the License Management App (LMA) to enable debug logs for a namespace." Two side effects belong in your support runbook. The guide warns that subscribers "can see the debug logs you generate, and these logs contain your unobfuscated Apex code." In 2GP, "enabling debug logs for 2GP means enabling logs for all managed packages in the namespace."

That second point has a limits side too. The limits page says the operations performed "in each namespace must not exceed the per-transaction limits," and 2GP lets several packages share one package namespace. Reading the two together, a base package and its extension in the same namespace draw from one set of counters, not two. Salesforce doesn't spell this case out, so test it before you depend on it. If you plan to split a product into several packages, give that split the same scrutiny as the CPU budget.

For early warning, Salesforce emails selected users when Apex "surpasses 50% of allocated governor limits," per the warning email setup page. The limits page adds that "cumulative resource messages and warning emails are also generated based on managed package namespaces." Asking a pilot customer's admin to turn this on for one user gives you a signal before the first failed save.

Mistakes that hit limits after install

These come up when a package that passed every test meets a production org.

• Testing only in a clean scratch org. The customer's flows and triggers run first and spend CPU time your tests never saw.
• Reading 11x as headroom. Each certified namespace still stops at 100 synchronous queries.
• Doing outbound sync inside the trigger. Callouts can't run in a trigger's transaction, and moving them to async also moves the CPU cost out of the customer's save.
• Assuming a pilot install has separate limits. Until the package is certified, it shares the customer's budget.
• Unbulkified handlers. A data load of 200 records fires one trigger invocation, and a query inside a loop spends the 100 queries quickly.

Frequently Asked Questions

Do managed packages have separate governor limits?

Only certified ones, meaning packages that passed the AppExchange security review. They get their own SOQL, DML and callout counts, while CPU time, heap and execution time stay shared with the whole transaction.

What is the 11x rule for managed packages?

It's the cumulative cross-namespace limit, set at 11 times the per-namespace limit. That means 1,100 SOQL queries and 1,650 DML statements per transaction across all certified namespaces. Each namespace still stops at its own 100 queries and 150 DML statements.

Does a managed package share CPU time with the customer org?

Yes. The CPU limit (10,000 ms synchronous, 60,000 ms asynchronous) counts for the entire transaction. That includes the customer's code, their flows and every installed package.

Do two 2GP packages in the same namespace get separate limits?

Salesforce counts the limits per namespace, so packages sharing a 2GP namespace should share one set of counters. The docs don't address this case directly, so confirm it in a test org.

Does managed package code count toward the org's 6 MB Apex limit?

No. Salesforce excludes Apex in 1GP and 2GP managed packages from that limit, whether or not the package is certified.

Can Appnigma build a managed package that stays within these limits?

Yes. Appnigma's marketplace apps service builds native Salesforce apps and provides "marketplace listing preparation, and review support," with the shared CPU budget in mind.

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Related Articles

• Salesforce Managed Package Guide, 1GP vs 2GP
• What Is a Managed Package in Salesforce
• What Is the Salesforce Security Review
• Salesforce Security Review Checklist
• Platform Events vs Change Data Capture
• Composite and GraphQL API for Fewer Salesforce API Calls

Sources

1. Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
2. Salesforce Developers, Apex Developer Guide, Set Up Governor Limit Email Warnings
3. Salesforce Developers, Apex Developer Guide, Apex Transactions and Governor Limits
4. Salesforce Developers, Salesforce App Limits Cheatsheet, Apex Governor Limits
5. Salesforce Developers, Apex Developer Guide, Working with Logs in the Developer Console
6. Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Debug Subscriber Orgs
7. Salesforce Developers, ISVforce Guide, Using Apex in Group and Professional Editions