The Answer in 30 Seconds

A well-built, AppExchange-certified managed package will not hurt your Salesforce org — its Apex code runs under its own isolated governor limits and does not compete with your custom code. An uncertified or poorly built managed package can degrade performance, consume your org's shared governor limits, push your custom fields toward edition caps, and create data storage bloat that is hard to reverse. This guide gives you a 50-point framework to evaluate any package before installation, a governor limits breakdown most admins have never seen, and a 30-day post-install health checklist.

Every Salesforce admin has been there: a business stakeholder sends a link to an AppExchange listing with "can we install this?" The package looks promising. The reviews are decent. But you know from experience that what looks clean on a listing page can behave very differently inside your production org — and once you install a managed package, removing it without leaving debris is harder than it looks.

Most guides on this topic give you a generic checklist and send you on your way. This one goes deeper. We cover the critical distinction between certified and uncertified managed packages and what it means for your governor limits. We cover the specific field and storage limits you will hit if you are not careful. We show you what to run in your sandbox to stress-test a package before it touches production. And we give you the red flags that should make you walk away before you click Install.

We build managed packages professionally at Appnigma, so what follows comes from the inside perspective — things you learn from building the packages that get evaluated, not just from evaluating them.

Before any evaluation checklist, you need to understand the one distinction that determines how much risk a managed package poses to your org: whether it is certified (AppExchange Security Review approved) or uncertified. Most admins know this intellectually but do not fully appreciate the governor limit implications.

When a managed package has passed Salesforce's AppExchange Security Review and is listed as ISV-certified, its Apex code runs under a completely separate set of per-transaction governor limits from your custom code. This is one of the most important and least-discussed features of the Salesforce platform.

In practical terms: if a certified managed package executes 150 DML statements in a transaction, those 150 DML statements do not reduce the 150 available to your own Apex. Both pools are isolated. The package's SOQL queries (up to 100 per transaction for verified packages) do not consume your org's 100-query allowance.

The Catch Everyone Misses

Certified packages have isolated per-transaction limits, but daily API call limits are still shared across the entire org. If a certified managed package makes thousands of outbound API calls per day as part of its sync logic, those calls count against your org's total daily API allocation just like your own integrations do. Always ask vendors how many daily API calls their package consumes under normal usage.

On the AppExchange listing page, look for the "Security Review" badge and the "Salesforce Reviewed" label. Packages built by registered Salesforce ISV Partners that have passed security review display these prominently. If you cannot find either badge, treat the package as uncertified for governor limit purposes regardless of what its marketing materials say.

You can also check after installation: in Setup, go to Installed Packages and look at the package details. Verified managed packages show their namespace prefix and certification status.

Governor limits at transaction level are one concern. The limits that silently accumulate over months of running a managed package are the ones that catch admins off guard. Here is the full picture.

In Salesforce Enterprise Edition, every standard object (Account, Contact, Opportunity, Lead, Case) allows a maximum of 900 custom fields. Of those 900, up to 400 can come from installed managed packages. This is a hard limit, not a soft one. Once you hit it, you cannot create new fields on that object — not from a package, not from your own team's development — until you either delete existing fields or uninstall a package.

Critical Detail Most Guides Miss

Undefined empty fields added by a managed package — fields the vendor includes as placeholder mapping fields that you never actually configure or populate — still count against your 400-field managed package allocation. A single large CRM package can add 80 to 150 fields to Account alone. A CPQ package can add another 60 to 100 fields to Opportunity. Two packages in and you have consumed half your allocation before you have written a single line of custom code.

Before installing any new package, run this in your developer console to see your current field count per object:

// Check field counts per object before installing a package
// Run in Developer Console > Execute Anonymous
Map<String, Schema.SObjectType> globalDescribe = Schema.getGlobalDescribe();

List<String> objectsToCheck = new List<String>{
'Account', 'Contact', 'Opportunity', 'Lead', 'Case'
};

for (String objName : objectsToCheck) {
Schema.SObjectType objType = globalDescribe.get(objName);
if (objType != null) {
Map<String, Schema.SObjectField> fields = objType.getDescribe().fields.getMap();
Integer customCount = 0;
Integer packageCount = 0;
for (String fname : fields.keySet()) {
Schema.DescribeFieldResult f = fields.get(fname).getDescribe();
if (!f.isNillable() || fname.endsWith('__c')) {
if (fname.contains('__') && !fname.startsWith('__')
&& fname.split('__').size() > 2) {
packageCount++; // Namespace__FieldName__c pattern
} else if (fname.endsWith('__c')) {
customCount++;
}
}
}
System.debug(objName + ': Custom=' + customCount
+ ' | Package=' + packageCount
+ ' | Total=' + (customCount + packageCount));
}
}

Managed packages impact two distinct storage buckets in Salesforce: data storage (records) and file storage (static resources). Any records created by the package — configuration records, activity logs, sync status objects, error logs — consume data storage. Static resources bundled with the package (JS libraries, CSS, images) consume file storage.

The storage impact that catches teams off guard is when a vendor saves user configuration as data records in custom objects rather than using Custom Metadata or Custom Settings. Custom Metadata records do not count against data storage. Custom Settings have their own allocation. But ordinary custom object records consume data storage at the same rate as your business records. A package that creates 10 configuration records per user can consume meaningful storage at enterprise scale.

Quick Test

Ask the vendor directly: "Do you use Custom Metadata, Custom Settings, or custom objects to store user configuration?" If the answer is custom objects, ask how many records are typically created per org and per user. This tells you exactly what the data storage impact will be at your scale.

Everything that follows happens before you install the package anywhere. This phase is about gathering information and assessing fit — in parallel, not sequentially. Most of these checks take 5 to 15 minutes each and together they give you a complete picture.

1. How many custom fields does your package add to each standard object (Account, Contact, Opportunity)? Any number over 50 per object warrants scrutiny. Ask specifically whether empty placeholder fields are included in that count.

2. How many API calls does your package make daily under normal usage for a 100-user org? This is the shared-limit exposure that even certified packages cannot isolate.

3. Do you use Custom Metadata, Custom Settings, or custom objects for user configuration storage? Anything stored in custom objects hits your data storage budget.

4. What is your uninstall process and what metadata will remain after uninstallation? A vendor that has thought through clean uninstallation signals engineering discipline. A vendor that says "it removes cleanly" without specifics is a yellow flag.

• ✓Check current field counts on all major objects. Run the Apex script above and document current custom and package field counts per object before installation.

• ✓Review current data storage usage. Setup → Company Information shows current usage. Note the percentage remaining before installing.

• ✓Review daily API usage. Setup → Company Information → API Requests, Last 24 Hours. Establish a baseline before the package adds to it.

• ✓Check for conflicting triggers. If the package adds triggers on objects you already have custom triggers on, test trigger ordering in sandbox. Salesforce does not guarantee trigger execution order across packages.

• ✓Review permission requirements. Does the package require new profiles? Custom permission sets? Admin-level access to any object? Document what it will need before granting anything.

• ✓Check edition compatibility. Some packages require Enterprise Edition or above. Verify your edition supports all components the package includes.

• ✓Verify sandbox availability. Confirm you have a Full sandbox or Partial sandbox that mirrors your production data model for realistic testing.

• ✓Document current org governor limit usage. Setup → System Overview shows scheduled jobs, custom objects, and other platform allocations. Note current levels.

Never install a new managed package directly into production. This is not a guideline — it is a non-negotiable rule. A trigger conflict, a governor limit exception, or a data model clash discovered in production costs hours to remediate and carries real business risk. The same discovery in a sandbox costs nothing.

1. Developer sandbox first. Install with Admin-only access initially. Do not grant access to all users until you have completed basic testing.

2. Review the component inventory. After installation, go to Setup → Installed Packages → click the package name → View Components. Screenshot or export this list. It shows every Apex class, trigger, custom object, field, and Flow the package introduced.

3. Run all your existing Apex tests. If any existing test classes fail after the package installation, the package has a conflict with your code. Do not proceed to production until resolved.

4. Stress-test in a Full sandbox with representative data volumes. A package that works fine on 100 test records may hit governor limits on 100,000 production records.

5. User acceptance testing with a pilot group. Identify 3 to 5 representative users across the roles that will use the package. Test their most common workflows, not just the demo scenarios the vendor showed you.

• !Apex test failures. Any existing test class that fails after package installation is a definitive conflict. Investigate before proceeding.

• !Page load time regression. If pages that previously loaded in 1 second now take 3+ seconds, the package has triggers or before-save logic that is adding processing overhead to record operations.

• !SOQL or DML governor limit errors in debug logs. Run debug logs at FINEST level on your test user during normal workflow execution. Look for limit warnings or exceptions in the package's namespace.

• !Unexpected data creation. After completing test workflows, run a SOQL query to count records in the package's custom objects. If the package is creating many configuration records automatically, multiply by your user count to project storage impact.

• !Permission scope creep. Review the package's permission sets carefully. Look for any object-level Create, Read, Edit, Delete or field-level permissions that are broader than the package's stated functionality requires.

• !Trigger ordering conflicts. If you have custom triggers on the same objects as the package, test all your trigger-dependent business processes carefully. Trigger execution order across packages is not guaranteed.

// Run in developer console after installing in sandbox
// Check governor limit usage after a standard workflow (e.g. creating an Account)

// 1. Set up debug log: Setup > Debug Logs > Add your test user
// 2. Perform a standard operation (e.g. create Account with all required fields)
// 3. Review the log — search for these strings:
// "LIMIT_USAGE_FOR_NS" — shows per-namespace limit consumption
// "Maximum CPU time" — if this appears, the package is CPU-heavy
// "Too many SOQL queries" — governor limit exception

// Quick SOQL check to see package records created during testing
// Replace 'pkgnamespace' with the actual package namespace prefix

for (Schema.SObjectType objType : Schema.getGlobalDescribe().values()) {
String name = objType.getDescribe().getName();
if (name.startsWith('pkgnamespace__')) {
System.debug('Package object found: ' + name);
}
}

Not every managed package is worth evaluating in depth. These signals, alone or combined, are reasons to decline before investing time in sandbox testing.

Red Flag 01

Without security review, the package code shares your org governor limits. A poorly optimised trigger can throw limit exceptions that silently roll back your data. This is the single biggest technical risk.

Red Flag 02

Ask the vendor or check any accessible code samples. SOQL queries inside loops exhaust the 100-query limit on bulk operations. This will fail in production on any bulk data load, automation, or trigger cascade.

Red Flag 03

Some packages need broad permissions for legitimate reasons, but a package that requests Modify All Data on Account without a clear functional explanation has over-privileged access that creates security risk in every user org.

Red Flag 04

A vendor that does not document what changed between versions is telling you they do not plan upgrades carefully. Uninformed upgrades to production packages are a major cause of post-upgrade fires.

Yellow Flag 01

A package adding 120+ fields to Account for functionality that could logically need 30 fields is a sign of poor data modelling, placeholder fields, or lack of attention to the subscriber's field limit budget.

Yellow Flag 02

Configuration stored as data records — rather than Custom Metadata or Custom Settings — grows over time and consumes your data storage budget. It also means configuration cannot be deployed via change sets or CI/CD pipelines, which complicates sandbox refreshes.

Yellow Flag 03

Packages that do not document their uninstall process often leave orphaned fields, broken references in Flows, and records in custom objects that block uninstallation until manual cleanup. Ask the vendor before you ever need to find out the hard way.

Yellow Flag 04

AppExchange reviews from paying customers are the only unfiltered signal of vendor responsiveness. If multiple reviewers mention slow support response times or unresolved bugs spanning multiple versions, this pattern will not improve after you install.

Installation day is not the end of the evaluation — it is the start of a 30-day observation window. Most package-related performance issues do not surface in sandbox testing because they depend on production data volumes, user behaviour patterns, and the interaction with other scheduled automation that only runs in production.

• ✓Day 1: Document baseline metrics. Log current data storage usage, file storage usage, daily API call count, and Apex job count before users start using the package.

• ✓Day 1 to 7: Monitor Apex Exception Email notifications. Setup → Apex Exception Email. Any unhandled exceptions from the package's namespace will appear here. Multiple exceptions in the first week signal a stability issue.

• ✓Day 7: Review Apex Jobs (scheduled and batch). Setup → Apex Jobs. Check if the package has registered scheduled jobs and whether they are completing successfully or failing silently.

• ✓Day 14: Run the Salesforce Optimizer. Setup → Salesforce Optimizer. Check for any new recommendations related to the package's components, particularly around unused custom fields or large object queries.

• ✓Day 14: Compare API usage to pre-install baseline. If the package is adding significantly to your daily API consumption, project forward to confirm you will not breach the daily limit during peak periods.

• ✓Day 14: Query package custom objects for record counts. Compare actual data storage growth to vendor's stated projection. Large discrepancies suggest the package is creating more records than documented.

• ✓Day 30: Run a full Apex test suite. Ensure code coverage has not degraded and no test classes have started failing due to the package introducing data that conflicts with your test assumptions.

• ✓Day 30: User adoption and performance survey. Ask your pilot users directly: are pages loading slower? Are any operations that worked before now behaving differently? User-reported slowdowns are often the earliest signal of trigger performance issues.

• ✓Day 30: Field count re-audit. Run the field count script again. Compare to pre-install baseline. Confirm the actual field count matches the vendor's documentation of what the package adds.

Uninstalling a managed package is the step most admins have never practiced — until they need to do it urgently. Salesforce will block the uninstallation if any metadata in your org references the package's components. The cleanup required before uninstalling can take hours on a complex org.

• Export all data from the package's custom objects before removing them. Data Export or a SOQL query to CSV. Once the package is uninstalled and the objects are removed, the data is gone.

• Delete or deactivate all Flows, Process Builders, and Workflow Rules that reference the package's components. These will block uninstallation with a dependency error.

• Remove all custom report types and reports built on the package's custom objects.

• Remove custom fields you added to standard objects that reference the package's custom objects via lookup.

• Update or delete any custom Apex classes your team wrote that import the package's types or reference its namespace.

• Check Lightning pages and page layouts for any components the package provided that you added to your own layouts.

• Practice the uninstall in sandbox first. Even the uninstall itself should be rehearsed.

From the Field — Sunny Chauhan, Appnigma AI

We have seen uninstallations take an entire sprint because the package had been in the org for three years and dozens of Flows, custom reports, and custom Apex classes had accumulated dependencies on its components. The admin team had no record of what they had built on top of the package. The lesson: document your dependencies at installation time, not when you need to remove the package. A simple spreadsheet listing every Flow, report type, and Apex class that touches a managed package's namespace takes 30 minutes to create and can save 30 hours later.

If you are an ISV — someone building a managed package to distribute on AppExchange — everything in this evaluation guide is a specification for what your package needs to do correctly to pass a rigorous admin's evaluation.

The admins who evaluate packages well ask exactly the questions above. They will run your package in sandbox, audit your field count, check your API call volume, test your uninstall process, and read every AppExchange review for support response patterns. If your package fails any of these checks, you lose the evaluation silently — the admin simply does not install.

Building a package that passes these evaluations is not just about good code. It is about: using Custom Metadata for configuration instead of records, keeping your field count minimal and purposeful, providing honest and detailed release notes, testing your own uninstall path in a clean org before every release, and earning AppExchange Security Review certification so your governor limits are isolated and admins know they are not taking on technical risk.

At Appnigma, our platform generates the packaging scaffold — the namespace, the permission architecture, the Custom Metadata design, the deployment configuration — that helps ISVs build packages that pass admin evaluations. If you are building for AppExchange, our Salesforce managed package guide and our AppExchange development guide cover what it takes to build a package that admins trust.

• Certified vs uncertified is the most important distinction. Certified packages have isolated governor limits. Uncertified packages share yours. Check for the Security Review badge before everything else.

• Daily API calls are always shared. Even certified packages consume your org's daily API allocation. Ask vendors for their expected daily API call volume.

• Field limits accumulate silently. In Enterprise Edition, 400 of your 900 custom fields per object can come from managed packages. Empty placeholder fields count. Audit before every installation.

• Storage impact depends on how the vendor stores configuration. Custom Metadata is safe. Custom objects creating configuration records consume your data storage budget at scale.

• Never install in production first. Always sandbox first, run your full Apex test suite, and monitor debug logs for governor limit consumption before production deployment.

• Walk away from uncertified packages, missing release notes, and vendors who cannot explain their uninstall process.

• Document all dependencies at installation time. Flows, reports, Apex, and page layouts that reference the package — document them now, not when you need to uninstall.

• Run a 30-day post-install monitoring cycle. Most performance issues surface under production load, not sandbox testing.

Will a managed package hurt my Salesforce org?

A well-built, AppExchange-certified managed package will not hurt your org. Its Apex code runs under isolated governor limits and does not compete with your custom code. An uncertified or poorly built managed package can degrade performance, consume your org's shared governor limits, push your custom fields toward edition caps, and create data storage bloat that is hard to reverse. The key question is whether the package is certified and whether the vendor's engineering practices meet the standards described in this guide.

What is the difference between a certified and uncertified managed package in Salesforce?

A certified managed package has passed Salesforce's AppExchange Security Review and is listed with the Salesforce-reviewed badge. Critically, certified packages run their Apex code under their own isolated governor limits — their SOQL queries, DML statements, CPU time, and callouts do not consume your org's per-transaction limits. An uncertified managed package shares your org's governor limits. If its code is inefficient, it eats into the same resource pool as your custom code, risking governor limit exceptions on bulk operations.

How many custom fields can a managed package add to my Salesforce org?

In Enterprise Edition, your org allows a maximum of 900 custom fields per object. Of those, up to 400 can come from installed managed packages. Critically, empty undefined fields added by a managed package still count toward this limit even if you never use them. Before installing a package with a large field footprint, audit your current field usage with Schema Builder or the Apex describe script in this guide to confirm you have sufficient headroom.

What should I check before installing a Salesforce managed package?

Before installing any managed package: check whether it is AppExchange-listed and security-reviewed, audit your current custom field count per major object, check your current data storage and daily API usage as a baseline, review what permissions the package requests and whether they are proportional to its functionality, confirm the package version supports your Salesforce edition, and ensure you have a sandbox available for pre-production testing.

Can I uninstall a managed package if it causes problems?

Yes, but uninstalling a managed package requires cleanup first. Salesforce will block uninstallation if any of your Flows, custom Apex, reports, or page layouts reference the package's components. Before uninstalling, you must remove all dependent metadata. Export any data from the package's custom objects before removing them — once the package is uninstalled, that data is gone. Always practice the uninstall in sandbox before attempting it in production.

How do I monitor a managed package after installation?

After installing a managed package, monitor: Apex Exception Email notifications for unhandled exceptions in the package's namespace, the System Overview page for storage consumption growth, daily API usage compared to your pre-install baseline, Apex Jobs for scheduled batch processes the package registered, and run the Salesforce Optimizer at the 14-day mark for any new performance recommendations. Run a full Apex test suite at the 30-day mark to confirm no test failures have emerged.

What are the red flags when evaluating a managed package on AppExchange?

Hard red flags: no Security Review badge, requesting Modify All Data without justification, no sandbox installation option, no version-specific release notes. Yellow flags: field count disproportionate to functionality, configuration stored as data records rather than Custom Metadata, multiple AppExchange reviews mentioning slow support response, and no documented uninstall process. Any single hard red flag is sufficient reason to decline the package or require the vendor to address it before you evaluate further.

Does a managed package consume my org's data storage?

Yes. Records created by the managed package consume your org's data storage. Static resources bundled with the package consume file storage. The packages with the highest storage impact are those that save user configuration as ordinary custom object records rather than Custom Metadata or Custom Settings. Custom Metadata does not count against data storage limits. Ask the vendor specifically whether they use Custom Metadata or custom objects for configuration, and request an estimate of typical storage consumption per user at your scale.