First-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Package and Test Your First-Generation Managed Package
Install a Managed Package
Install First-Generation Managed Packages Using Metadata API
Component Availability After Deployment
Install Notifications for Unauthorized Managed Packages
Resolve Apex Test Failures
Run Apex on Package Install/Upgrade
Run Apex on Package Uninstall
How Does an Uninstall Script Work?
Example of an Uninstall Script
Specifying an Uninstall Script
Uninstall a First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Run Apex on Package Uninstall

App developers can specify an Apex script to run automatically after a subscriber uninstalls a managed package. This script makes it possible to perform cleanup and notification tasks based on details of the subscriber’s organization. For simplicity, you can only specify one uninstall script. It must be an Apex class that is a member of the package.

The uninstall script is subject to default governor limits. It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo. You can only see this user at runtime, not while running tests.

If the script fails, the uninstall continues but none of the changes performed by the script are committed. Any errors in the script are emailed to the user specified in the Notify on Apex Error field of the package. If no user is specified, the uninstall details are unavailable.

The uninstall script has the following restrictions. You can’t use it to initiate batch, scheduled, and future jobs, to access Session IDs, or to perform callouts.