Managing a Subscriber Organization is a recurring admin task: keep the installed package healthy, control which users have access, grant Publisher support when needed, and plan upgrades and renewals. The work splits across the Subscriber Org admin (the customer side) and the Publisher LMA admin (the ISV side). This guide covers the Subscriber Org admin tasks, since that is what most readers of a dictionary entry are looking for. Publishers reading this should also know the Subscriber-side view to advise their customers.
- Audit the installed packages in your org
From Setup, search Installed Packages, and review every package installed in the org. For each, note the Publisher, the installed version, the install date, the namespace prefix, and the package install user. Compare against the latest available version on AppExchange or the Publisher site. Identify any packages two or more major versions behind, since those are upgrade candidates. Also identify packages that are no longer used (no traffic, no users logged in to that area). Stale managed packages add governor-limit pressure and complicate upgrades; plan to remove them through coordinated uninstalls.
- Assign permission sets and validate access
Each managed package ships with permission sets that grant access to its objects, fields, and Apex. After every install or upgrade, confirm the right users have the right permission sets assigned. Without explicit assignment, even System Administrators may see only partial functionality. Document the permission-set assignment policy for each package in the org onboarding playbook so new hires automatically get the right access. Audit assignments quarterly and remove permission sets from users who no longer need them. License-counted permission sets are particularly important to audit, since over-assignment can drive license consumption above the contract limit.
- Grant Publisher support access when troubleshooting
When a managed package issue requires Publisher support, open Setup, search Grant Login Access, find the Publisher company name in the list, and grant access for the shortest duration that fits the support need (1 day for a quick fix, 1 week for an investigation). Notify the Publisher support contact that access has been granted. Audit the access grant in your security log; every action the Publisher takes is logged with the Publisher user identity. Revoke the access early if the issue resolves before the duration expires. For sensitive orgs, require approval through your change management process before granting Publisher access.
- Plan and execute managed package upgrades
When a Publisher releases a new managed package version, read the release notes, install the new version in a sandbox that mirrors production, run a full regression test against the affected user journeys, schedule the production upgrade for a maintenance window, and validate post-install. For Push Upgrades initiated by the Publisher, the Subscriber Org admin does not control the timing, but can disable Push Upgrades for specific packages through the Installed Packages settings if change management requires advance notice. Document each upgrade in the org automation log alongside the date, the version installed, and any post-install issues.
- Managed package components are read-only in the Subscriber Org. Editing Apex, Visualforce, or Lightning Web Components from the package is impossible; extensions must live in unmanaged code that references the package.
- Permission sets are not auto-assigned on install. System Administrators may see the package work; rank-and-file users may not. Validate access as a target user before declaring the install complete.
- Sandbox refresh copies the installed package but creates a new License record on the Publisher LMA. High-value sandbox refreshes should be coordinated with the Publisher so license expectations stay in sync.
- Uninstall is destructive. Data on package-defined custom objects is permanently deleted on uninstall. Always export the data first and test the uninstall in a sandbox before running it in production.
- Push Upgrades happen on the Publisher schedule, not yours. Disable Push Upgrades for high-risk packages if your change management requires advance notice for every install.