Loading

Remove obsolete Visualforce from managed packages

Data pubblicazione: Jun 17, 2026
Descrizione

Background: Flexible Managed Packages

In Spring '15, Salesforce introduced the Flexible Managed Packages initiative, which enables the removal of Visualforce pages, global Visualforce components, and static resources from published managed packages. This helps package owners clean up obsolete Visualforce (VF) components. Supported component types include: custom tabs, custom fields, custom objects, validation rules, record types, field sets, buttons, links, VF pages, global VF components, and static resources.

Apex and Packaging Behavior

Public Apex classes and public VF components are deletable from published managed packages. When you delete a public Apex class or VF component in your packaging org, the same component is deleted in the subscriber org upon upgrade. The subscriber has no role in this process.
The Flexible Managed Packages initiative takes a different approach: when you delete a custom field, validation rule, or VF page in the packaging org, the upgrade process does not delete those components in subscriber orgs. Instead, the upgrade enables the Delete button on those components in the subscriber org, giving the subscriber system administrator the flexibility to analyze the impact and then delete manually as needed.

Known Inconsistency in Component Deletion

This design creates an inconsistency: public Apex classes and public VF components are deleted in subscriber orgs upon upgrade, but VF pages and global VF components are not. After deliberation, Salesforce chose to maintain this inconsistency to avoid unintended metadata deletion in subscriber orgs.

Example Scenario: Dependent VF Component Risk

Consider this scenario: your package version 1.0 contains VF page p1, which references public VF component pc1 (relationship: p1 → pc1).

  • In version 1.1, you decide to remove p1 from the package.
  • The subscriber upgrades to 1.1 but does not delete p1 — they now have the Delete button, but the page still exists.
  • In your packaging org, since p1 is gone, nothing prevents you from deleting pc1.
  • You delete pc1 and release version 1.2.
  • When the subscriber upgrades to 1.2, VF page p1 fails to load because pc1 — which it depends on — was deleted upon upgrade.

This can cause serious disruption to business-critical VF functionality in subscriber orgs.

Risoluzione

Resolution: Proactive Upgrade Blocking

To prevent this situation, Salesforce blocks the upgrade if it detects that any VF page or global VF component in the subscriber org is in a DELETED state AND still references a public Apex class or VF component. This upgrade block protects subscriber orgs from ending up in a broken state.

Required Action: Two-Step Upgrade Process

To ensure package upgrades succeed, follow this two-step process (using the example above):

  1. Create a patch version 1.0.1 based on version 1.0.
  2. In version 1.0.1, edit VF page p1 and remove its reference to pc1.
  3. Push version 1.0.1 to all v1.0 subscribers using the push upgrade functionality.
  4. Once subscribers are on 1.0.1 (where p1 no longer references pc1), proceed with the upgrade to 1.1.

By breaking the reference at 1.0.1, the upgrade to 1.1 proceeds smoothly. When you try to delete a VF page or component in your packaging org, a warning message describes this two-step process.

 

 

Numero articolo Knowledge

000387314

 
Caricamento
Salesforce Help | Article