You can still remove a Salesforce managed package after its license expires — but the expiry usually makes the job harder, not easier. When the license lapses, the package's own Setup menu items and admin screens can disappear, so you lose the vendor's guided cleanup tools while Salesforce still blocks the uninstall until every reference (page layouts, record types, automation, custom fields, reports) is cleared. The working path is: inventory what the package owns, remove or rewire every reference in your configuration, export any data you need to keep, then uninstall from Setup > Installed Packages. If the expired license hides components you must edit, ask the vendor or Salesforce Support to temporarily re-enable access — that's a common, supported request.
Two separate mechanisms collide. First, Salesforce won't uninstall anything that's still referenced: if the package's fields sit on page layouts, its record types drive business processes, or its components appear in flows, reports, or permission sets, the uninstall halts with dependency errors. Second, an expired license can hide the package's own admin interface — the Setup pages where you'd normally retire those components — and in some configurations expired-package components can even throw errors in day-to-day transactions.
The result is a frustrating middle state: the org insists you clean up before removing the package, while the expiry removes the tools the vendor gave you to do exactly that. Cleanup is still possible — package components remain visible in standard Salesforce setup areas like Object Manager and page layout editors — but it becomes manual forensic work.
Expect the uninstall attempt to fail with a list of blocking references. The usual suspects, roughly in order of frequency:
| Blocking reference | Where to find and clear it |
|---|---|
| Fields on page layouts | Object Manager > Page Layouts — remove package fields and related lists from every layout, including ones assigned to rarely used profiles |
| Record types | Object Manager > Record Types — deactivate and delete package record types after moving records to a surviving type |
| List views, reports, dashboards | Delete or re-point any report or list view that references package fields |
| Flows, process builders, validation rules | Deactivate, remove package references, reactivate |
| Permission sets and profiles | Remove package object/field permissions and the package's own permission sets |
| Custom fields you built on package objects | Delete or relocate your own additions — they anchor the package too |
| Connected apps, email templates, other packages | Integrations and even other managed packages may depend on this one |
The cheap time to plan a package exit is before the license lapses. While everything still works, export the data, screenshot key configurations, and read the vendor's uninstall guide — many vendors publish one, and it's only useful while you can still open their app. If you're still evaluating whether to keep the package at all, that decision deserves the same rigor as the original purchase; our guide to evaluating managed packages on AppExchange covers the questions that prevent shelfware in the first place.
It's also worth folding package hygiene into regular admin reviews. Licenses, unused fields, and dormant packages tend to surface together — an org that audits these quarterly never faces a forensic cleanup under deadline.
Vantage Point's Salesforce team handles exactly this kind of org housekeeping: package removals, dependency cleanup, data preservation, and the verification pass that keeps users from discovering the breakage. Our managed services clients get this as routine maintenance rather than an emergency project. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If the expired package is tangled into years of configuration — layouts, automation, integrations — a short cleanup engagement is usually faster and safer than learning the dependency graph the hard way.
We'll inventory the package's footprint, map its dependencies, and remove it without breaking the processes that remain.
Yes. The uninstall option in Setup > Installed Packages remains available after expiry. What changes is access to the package's own admin tools and, sometimes, error behavior in transactions — so cleanup of layouts, record types, and automation references may need to happen through standard Salesforce setup areas instead of the vendor's screens.
It can. Uninstalling removes the package's components, and records stored in package objects are typically deleted in the process. Salesforce offers to save a copy of some data during uninstall, but you should export anything that matters beforehand and treat the uninstall as destructive.
Salesforce blocks removal while anything still references the package: fields on page layouts, record types in use, flows and validation rules touching package fields, reports, list views, and permission sets all anchor it. Each error message lists the blocking reference — clear them iteratively and retry.
Contact the vendor or Salesforce Support and request a temporary re-enable for decommissioning. This is a routine request — vendors would rather help you exit cleanly than leave a broken org. Meanwhile, most references can still be cleared from standard areas like Object Manager and the page layout editor.
Managed package licenses are separate from your Salesforce edition's user licenses, but package permission set licenses and the users assigned to them do matter. The related cleanup question — which integration and service accounts consume which licenses — is worth auditing at the same time, since expired packages often leave license assignments behind.
Yes, always. Run the full cleanup and uninstall in a sandbox or developer org first, keep notes on every reference you had to clear, and use that punch list for production. Dependency chains are rarely identical between environments, but the sandbox run surfaces the categories you'll face.