Installing a managed package does not, by itself, slow down or hurt a Salesforce org. It hurts one when its triggers spend CPU time the customer's own automation needed, when its sync burns through the org's daily API requests, or when the admin cannot uninstall it cleanly. All three are design decisions made by the company that built the package, and a careful admin checks each one in a sandbox before the package reaches production.
That makes this a question for the SaaS company, not only for the admin. If you sell into enterprise accounts, the native Salesforce integration your customers asked for ships as a managed package into orgs you don't control, full of other vendors' code and years of their own flows. You build the package, pass security review, publish the listing, and then every new customer's admin runs the same evaluation. Appnigma's marketplace apps team builds that package for SaaS companies. The service includes "a native app, marketplace listing preparation, and review support." It also covers install guidance for customer admins. If you are an admin deciding whether to install an app today, the same facts below tell you what to test.
Updated October 2026. Checked against Salesforce's Apex Developer Guide, the AppExchange installation guide and the second-generation packaging guide. This update corrects four claims in the earlier version of this post. It said a certified package's limits are completely separate from the org's. It printed a fixed table of 400 package fields out of 900 per object. It said the Installed Packages page shows certification status, and that package data is gone after uninstall. It adds the API request arithmetic, the install and uninstall behavior an admin sees, and a query to count your package's fields.
What an installed package changes in the customer's org
Every managed package touches the same six areas of a subscriber org. Salesforce calls the customer's org the subscriber org, and the table shows who controls each effect.
| Area | What the package does | Who decides how much |
|---|---|---|
| Per-transaction Apex limits | Gets its own SOQL and DML counts once certified, shares CPU time and heap | You, through trigger design |
| Daily API requests | Every call your package makes counts against the org's daily total | You, through sync design |
| Custom fields and objects | Counts against the org's total limit, and against the edition allocation if unlisted | Listing status, then you |
| Data storage | Any records your package creates are the customer's storage | You, through configuration design |
| Install | Runs all of the org's Apex tests, hides custom objects from standard users | Salesforce and the admin |
| Uninstall | Blocked while customer metadata references your components | The admin, helped by your docs |
The rows the vendor controls are the ones an admin can see in a sandbox. A slow Account trigger or a sync that makes tens of thousands of API calls a day shows up in the first week of a trial. Each row has its own section here, quoted from Salesforce's documentation.
Which limits does your package share with the customer?
Security review changes how your Apex is counted. Salesforce's Execution Governors and Limits page says certified managed packages "get their own set of limits for most per-transaction limits." Your package gets its own 100 synchronous SOQL queries and 150 DML statements on top of the customer's.
The exceptions are where packages hurt orgs. The same page says "All per-transaction limits count separately for certified managed packages except for" heap size, CPU time, transaction execution time and the number of unique namespaces. So a slow trigger in your package spends the 10,000 ms of synchronous CPU that the customer's flows and other vendors' triggers also need, and the save fails for whoever runs out last. Before review, your package has no separate limits at all. Namespaces in non-certified packages, in the docs' words, "don't have their own separate governor limits," so a pilot install shares everything. Our post on which governor limits a certified package shares with the customer org has the full table and the 11x cross-namespace cap.
Daily API requests are never separate. Salesforce's API request limits page puts it in one line. "API calls made from installed managed packages, count against your org limit." In Enterprise Edition the daily total is 100,000 plus 1,000 per Salesforce license and any purchased add-ons.
Here is what that means for a sync, as worked arithmetic from those documented numbers, not a measurement. A customer with 200 Salesforce licenses gets 100,000 + (200 x 1,000) = 300,000 requests a day. Say your product updates 50,000 records a day with one REST call per record. That uses 50,000 requests, a sixth of the org's budget, before the customer's other integrations run. The same updates through sObject Collections, which update "up to 200 records" per request, take 250 requests. Admins compare API usage before and after a trial, and that difference is what they see. More on the shared pool in our post on the customer org's daily API pool.
How your package's fields count against the customer's limits
Listing status decides which limit your fields count against. Salesforce's AppExchange installation FAQ covers packages installed from a public listing. Their custom objects and fields "don't count against your edition's allocation, but they do count against the total limit of your Salesforce org." The same FAQ adds that an unmanaged package, or "a managed package that's not publicly listed," counts against the edition allocation.
That second sentence catches SaaS companies during pilots. A design partner who installs your package by direct link before the listing is live pays for every packaged field out of the same per-object allocation their own admins use. On a heavily customized Account object, a package with 60 fields can be the reason the install fails. The FAQ lists exceeding the custom object limit as one reason an "installation or upgrade" fails. The Installed Packages page shows the admin "whether the custom apps, tabs, and objects count toward your organization's limits," so the admin will see the difference. It does not show a certification badge, which the earlier version of this post said it did.
Ship only the fields the product reads or writes. Fields are hard to take back. The second-generation packaging guide says most components removed from a package version "remain in the subscriber org after package upgrade and are marked as deprecated." A placeholder field you ship in version 1 stays in every customer org until the admin deletes it or uninstalls.
Admins can count your fields per object with a Tooling API query on FieldDefinition, which must be filtered by object. Replace acme with your namespace.
SELECT QualifiedApiName, DataType
FROM FieldDefinition
WHERE EntityDefinition.QualifiedApiName = 'Account'
AND NamespacePrefix = 'acme'Put the per-object field count in your install guide before anyone asks. An admin who finds 60 fields on Account in your guide is evaluating a product, and one who finds them in a sandbox is evaluating a risk.
What the admin sees when your package installs
Install is the first time the customer's admin watches your package run. Salesforce's installation guide runs all of the org's Apex unit tests when a package containing Apex installs, and the admin "can select to install regardless of unit test failures." A failing test in your package makes the admin choose between your app and their own release process. The FAQ also lists "a failing Apex test" in the package as a reason installs fail.
Custom objects arrive hidden. The FAQ says "all custom objects are installed in "In Development" mode," so your install guide has to tell admins to deploy them. Admins also can't change what you grant. The installation guide says "you can't edit permission sets that are included in the package." A permission set that grants more than the product needs becomes a finding in the customer's security review of your app.
Unreviewed packages carry a warning. For a package the partner program "hasn't authorized for distribution," Salesforce shows a notice during installation that the admin must confirm. In an enterprise deal that notice reaches the customer's security team before your product does.
Security review also changes what the package can do after install. Apex in a managed package runs in Group and Professional Editions only after the package passes review, per the ISVforce Guide. Push upgrades are "only available to first- and second-generation managed packages that have passed the AgentExchange security review," according to the push upgrade guide. Without review you ship fixes by asking every customer's admin to install them.
What happens when a customer uninstalls your package
Uninstall is the test a careful admin runs in a sandbox before buying. The After Installing a Package page says "You can't uninstall a package whenever a component not included in the uninstall references any component in the package." A flow, report type, validation rule or Apex class the customer built on your objects blocks the uninstall until they remove it.
The data is not simply lost. During uninstall the admin can choose to save an export file "containing the package data, associated notes, and any attachments," and Salesforce emails a link when it finishes. The window is short. "We delete export files two days after a completed package uninstall." The earlier version of this post said the data is gone, and admins who read that could skip the export option.
For 2GP packages, uninstall also cleans up what upgrades left behind. The 2GP uninstall page says components, "including any deprecated components that were previously associated with the package, are deleted." If your package must clean up outside data or tell your backend the customer left, an uninstall script runs Apex at that point.
Document the uninstall path in the same guide as the install path. List which of your components customers usually build on, and how to remove those references first. That page answers the question every procurement review asks, which is what leaving costs.
Mistakes that fail a customer's package evaluation
A customer's admin can find each of these in a sandbox within a day of installing a managed package, and each one traces back to documented platform behavior.
- Synchronous callouts or heavy processing in triggers, which spend shared CPU time. Move enrichment and sync to Queueable Apex.
- One API request per record in a sync, when sObject Collections handle 200.
- Placeholder fields "for later" on Account, Contact or Opportunity. They stay deprecated in every org after you remove them.
- Configuration stored as records in custom objects, which grows the customer's data storage and doesn't move with their deployments.
- A permission set that grants Modify All on objects the product only reads.
- A pilot install before the listing is public, without telling the design partner the fields count against their edition allocation.
- No written uninstall path, so the first uninstall attempt fails on a reference nobody documented.
- Unhandled exceptions with no monitoring. The Apex guide lets customer admins add recipients for unhandled exception emails, and "The entered email addresses then apply to all managed packages in the customer's org." Your errors can reach their inbox before yours.
Frequently Asked Questions
Will installing a managed package slow down a Salesforce org?
Only if its code is slow. Trigger and flow work in the package runs inside the customer's own record saves, and CPU time is shared with their automation.
Does a certified managed package use the customer org's CPU time?
Yes. Certified packages get separate SOQL and DML counts, but CPU time, heap size and transaction time are shared with everything in the same transaction.
Do API calls from a managed package count against the customer's daily limit?
Yes. Salesforce says "API calls made from installed managed packages, count against your org limit." No exemption applies to certified packages.
Is package data deleted when a managed package is uninstalled?
The admin can save an export file of the package's data during uninstall. Salesforce deletes that file two days after the uninstall completes.
Do managed package fields count against a customer's field limits?
A publicly listed package's fields count against the org's total limit only. An unlisted package's fields also count against the edition allocation.
Can Appnigma build a managed package that passes a customer's evaluation?
Yes. Appnigma's marketplace apps service builds the native Salesforce app and provides "marketplace listing preparation, and review support," including install docs for customer admins.
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
- Governor Limits for Certified Managed Packages
- What Are Salesforce Objects and Fields
- Salesforce Managed Package Guide, 1GP vs 2GP
- Preparing Your Managed Package for Security Review
- How Customers Can Block Push Upgrades
- What Is a Managed Package in Salesforce
Sources
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
- Salesforce Developers, App Limits Cheatsheet, API Request Limits and Allocations
- Salesforce Developers, REST API, Update Records Using sObject Collections
- Salesforce Developers, AppExchange Installation Guide, FAQ
- Salesforce Developers, AppExchange Installation Guide, Installing Packages
- Salesforce Developers, AppExchange Installation Guide, After Installing a Package
- Salesforce Developers, AppExchange Installation Guide, Unauthorized Managed Packages
- Salesforce Developers, Second-Generation Packaging, Remove Metadata Components
- Salesforce Developers, Second-Generation Packaging, Uninstall a Second-Generation Managed Package
- Salesforce Developers, Second-Generation Packaging, Push Upgrades
- Salesforce Developers, ISVforce Guide, Using Apex in Group and Professional Editions
- Salesforce Developers, Tooling API, FieldDefinition
- Salesforce Developers, First-Generation Packaging, Uninstall Scripts
- Salesforce Developers, Apex Developer Guide, Exceptions in Apex
