Installed Packages
Installed Packages is the Salesforce Setup-area page that lists every managed and unmanaged package currently installed in the org.
Definition
Installed Packages is the Salesforce Setup-area page that lists every managed and unmanaged package currently installed in the org. The page shows the package name, namespace prefix, publisher, version, installation date, and whether the package is licensed (for paid AppExchange products) or limited (for trial installations). It is the single source of truth for "what third-party code is running in this org," critical for security audits, license management, and dependency tracking.
Setup, Installed Packages is where admins manage the full lifecycle of each package: viewing the contents (objects, fields, Apex classes shipped by the package), uninstalling, upgrading, viewing dependencies, and configuring post-install setup. Packages from the AppExchange (DocuSign, Conga, Geopointe, Apsona) install here. Internal first-party packages built by the org's developer team using Salesforce DX unlocked packages also appear here. The Installed Packages page is the operational counterpart to the AppExchange listing experience; AppExchange is the storefront, Installed Packages is the running inventory.
How Installed Packages helps admins manage third-party code, dependencies, and upgrades
Managed versus Unmanaged versus Unlocked packages
Three package types appear in Installed Packages. Managed packages are publisher-owned, namespaced (prefix__ObjectName__c), and protect their internals from customer modification; AppExchange ISV products are almost always managed. Unmanaged packages are open code; customers can edit any of it after install but lose upgrade support. Unlocked packages are the modern Salesforce DX format for internal-team packages; they support source control, dependency declarations, and Salesforce CLI deployment without being locked from customer edits.
Namespaces and the package prefix
Every managed package has a registered Namespace Prefix (acme, dsfs, conga) that appears in front of every API name shipped by the package: acme__Custom_Object__c, conga__Document__c. The namespace is unique across the entire Salesforce platform, claimed by the publisher at registration time. The prefix protects against naming collisions between packages and is what makes managed packages survive customer Apex modifications, validation rules, and other org-specific customizations.
Licensing and the per-user seat model
Paid AppExchange packages typically license seats: a 50-seat DocuSign license means 50 specific users can use DocuSign functionality. Installed Packages shows License Status (Active, Expiring, Expired) and Used Seats versus Allocated Seats. Admins assign or revoke seats via the Manage Licenses link. License compliance is on the customer; running 51 users on a 50-seat license is a renewal-cycle problem if the publisher audits, even though the platform does not actively block the 51st user.
Upgrade behaviour and version management
Managed package publishers push updates as new package versions. Customers control when to upgrade: Installed Packages shows the current version and any available upgrades. Upgrades can be Push (publisher initiates, customer is upgraded automatically based on org policy) or Pull (customer must explicitly install the upgrade). Push upgrades are typical for security patches; Pull is typical for major feature releases that require customer testing. Roll-back is not supported for managed packages; pick the upgrade timing carefully.
Dependencies and package extension
Packages can depend on other packages. A Geopointe extension package might require the Geopointe base package. Installed Packages shows dependencies on the package detail page; uninstalling a base package while extensions reference it fails. The Salesforce CLI exposes the same dependency graph for unlocked packages. For first-party internal package strategies, declaring dependencies between packages is the way to enforce build order and prevent half-installed states.
Uninstalling a package and what happens to data
Uninstall from Installed Packages removes the package metadata: objects, fields, Apex classes, page layouts. By default, uninstall offers to export the package data first (a one-time CSV download per object). Data is then dropped along with the schema. Uninstalling without exporting first is permanent; there is no recovery. Plan uninstalls carefully on packages with operational data; some teams build a custom flow to copy data to a non-package custom object before uninstall.
Trial packages and the limited license
AppExchange listings often offer trial installations: 30-day, 60-day, or per-user limited trials. Trial packages appear in Installed Packages with a trial expiration date. Past expiration, the package becomes read-only; data is preserved but no new transactions can use the package. Converting a trial to a paid license is a publisher-side workflow (sign a contract, pay an invoice, get an upgrade key). The trial-to-paid path is one of the largest churn points for AppExchange ISVs.
Managing the Installed Packages list day-to-day
Installed Packages is the page for ongoing package management. Most operations (install, upgrade, uninstall, license assign) are click-through; the deeper audit work involves reading package contents and dependency graphs.
- View the installed inventory
Setup, Quick Find, Installed Packages. The list shows every package with name, publisher, version, install date, and license status. Click any package name to see contents.
- Manage licenses
On a paid package, click Manage Licenses. Assign or revoke seats from the user list. Watch the Used vs Allocated ratio; over-allocation is a renewal conversation, under-allocation may indicate the package is not being used and the renewal can shrink.
- Configure post-install setup
Most packages have a Configure link that opens a publisher-specific setup wizard. Run this after first install. Configure links may include OAuth grants, API key entry, custom object initialization. Skipping this is the most common reason "the package isn''t working" tickets.
- Upgrade to a newer version
When the publisher releases a new version, Upgrade Available appears on the package row. Click Upgrade to install. Read the publisher''s release notes first; major-version upgrades may require post-upgrade reconfiguration.
- Uninstall when no longer needed
Click Uninstall. The wizard offers to export data first (CSV download per object). Confirm and execute. Test in sandbox before production uninstalls; some packages have hidden dependencies on other features.
Managed (namespaced, publisher-protected), Unmanaged (open code, customer-editable), Unlocked (modern DX format for internal teams).
Push (publisher auto-upgrades per org policy) or Pull (customer explicitly installs upgrades). Security patches typically push; major features pull.
Per-seat license (assign specific users) or org-wide license (all users covered). Per-seat is more common for paid AppExchange products.
Optional one-time CSV download per object before removal. Skip only when the package data is irrelevant or already exported elsewhere.
- Uninstalling without data export is permanent. Always export first unless the data is truly disposable.
- Managed packages cannot roll back to a prior version after upgrade. Test upgrades in sandbox; commitment is one-way.
- License over-allocation is a renewal-cycle problem, not a platform-enforced block. Track Used vs Allocated to avoid surprise true-up bills.
- Package dependencies prevent uninstall of base packages while extensions exist. Uninstall extensions first, then the base.
- Trial packages become read-only past expiration. Convert to paid before the trial ends or operational data freezes.
Trust & references
Cross-checked against the following references.
- View Installed PackagesSalesforce Help
- Install a PackageSalesforce Help
Straight from the source - Salesforce's reference material on Installed Packages.
- Uninstall a PackageSalesforce Help
- Manage Licenses for Managed PackagesSalesforce Help
Hands-on resources to go deeper on Installed Packages.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Installed Packages represent in the Salesforce Platform?
Q2. Who can benefit from understanding Installed Packages?
Q3. How does Salesforce's multi-tenant model affect Installed Packages?
Discussion
Loading discussion…