8.5 AppExchange Evaluation, Installation, Permissions, and Risk
Key Takeaways
- AppExchange evaluation is a change-management and risk exercise, not a shopping task.
- Admins should review vendor fit, package type, security review status, data access, limits, support model, license impact, and uninstall risk before installation.
- Install in a sandbox or test environment first when possible, then validate metadata changes, permissions, automation, page impact, and data behavior.
- Permission sets, connected apps, integration users, and external services introduced by a package must be governed after go-live.
Evaluate before installing
AppExchange solutions can save months of work, but they also add dependencies. A package may create custom objects, fields, tabs, Lightning components, flows, Apex, permission sets, connected apps, scheduled jobs, validation rules, report types, email templates, or external integrations. The admin should treat installation as a production change. The question is not whether the listing looks useful. The question is whether the package fits the org's security, data, process, license, and support model.
Start with the business problem. If the team needs document generation, territory visualization, survey management, data backup, e-signature, duplicate prevention, or case deflection, define the required outcomes and constraints first. Then compare AppExchange options against those requirements. Avoid installing multiple trial packages in production just to see what happens. Test environments exist for a reason.
| Evaluation area | Admin questions |
|---|---|
| Business fit | Which requirement does the package satisfy, and what process changes are expected? |
| Publisher and support | Who maintains it, how is support provided, and what happens during Salesforce releases? |
| Security and compliance | What data can it access, does it involve external services, and what approvals are needed? |
| Package type | Is it managed, unmanaged, unlocked, or otherwise distributed with upgrade and edit constraints? |
| Metadata footprint | What objects, fields, automations, tabs, layouts, components, and permissions are added? |
| Licenses and cost | Which users need package licenses and Salesforce permissions? |
| Limits and performance | Does it add automation, storage, API usage, scheduled jobs, or page-load impact? |
| Exit plan | Can the package be uninstalled cleanly, and what data or metadata remains? |
Salesforce security review status is important, but it is not the whole risk review. A package can be security reviewed and still be wrong for the company because it exposes more data than needed, conflicts with existing automation, duplicates a native feature, or creates a support dependency the team cannot manage. The administrator should involve security, legal, procurement, architecture, and business owners when the package touches sensitive data or external systems.
Package type affects support. Managed packages usually protect vendor intellectual property and support upgrades, but subscribers may not be able to edit packaged components directly. Unmanaged packages can be modified after installation, but they do not have the same upgrade path. The admin should understand what can be changed, what is locked, and how upgrades are delivered before relying on the package in a critical process.
Installation and post-install governance
Installation should follow the same discipline as other metadata changes. Prefer a sandbox or development environment first, especially for packages that add automation, integrations, or user-facing components. Capture the package version, installation choices, assigned permissions, post-install steps, test cases, and rollback or uninstall notes. If the package must be installed in production, get explicit approval and schedule the work during an appropriate change window.
Package installation workflow:
- Define requirements, success criteria, data sensitivity, and owner for the package.
- Review the listing, documentation, security information, release notes, support terms, and license model.
- Install in a sandbox or test org when possible, using least-privilege installation choices.
- Inspect added metadata, permission sets, connected apps, remote site settings, named credentials, flows, scheduled jobs, and page components.
- Assign package access to a small pilot group with the intended profile and permission set model.
- Test core workflows, reports, automation interactions, mobile behavior, and error handling.
- Document support responsibilities, upgrade process, monitoring, and uninstall considerations.
- Deploy or install for production with change approval, then monitor adoption and issues.
Permissions are often the hardest part after installation. Some packages include permission sets that grant access to package objects, Apex classes, tabs, components, or connected app behavior. The admin should not assign broad package permissions to everyone just because a pilot user cannot open a tab. Check the exact missing permission, whether the user needs a package license, whether field-level access is included, and whether underlying Salesforce objects are also required. Least privilege still applies.
Connected apps and integrations deserve special attention. A package may need OAuth access, API calls, external endpoints, or a dedicated integration user. That means token lifetime, IP policy, profile access, permission sets, login history, and monitoring may matter. If the package syncs data externally, the admin should know which records leave Salesforce, how errors are handled, and who owns data deletion requests. AppExchange installation can become a data governance issue quickly.
Uninstall planning should happen before go-live. Some packages leave data behind, some create dependencies that block uninstall, and some require users to migrate records or remove components from pages first. If a package adds fields that users begin using for key reporting, removing it later may require data export, transformation, and replacement metadata. The admin should document what must be preserved and what can be removed.
Hands-on practice can be safe if you choose a simple free package in a disposable playground or sandbox. Install it, inspect Setup for new objects, tabs, permission sets, profiles, connected apps, and Lightning components, then uninstall it if appropriate. The goal is not to memorize one product. The goal is to learn how installation changes an org and how to ask risk-based questions.
Study trap: do not assume AppExchange is always better than native configuration. Before installing, check whether Salesforce standard features, Flow, reports, Dynamic Forms, Path, duplicate rules, or approval processes already solve the requirement. A package is valuable when it solves a real gap with acceptable risk, not when it adds novelty.
A department asks the admin to install an AppExchange app directly in production because the listing has good reviews. What is the strongest response?
After installing a managed package, a pilot user cannot access the package tab. What should the admin check first?
Why should uninstall risk be reviewed before an AppExchange package goes live?