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?
Move to 2GP: Migrate Your Managed Packages with Ease
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
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
Create and Upload an Unmanaged Package
Components Available in Unmanaged Packages
Convert Unmanaged Packages to Managed
PDF

Developing and Distributing Unmanaged Packages

Unmanaged packages can be used for distributing open-source projects to developers, or as a one-time drop of applications that require customization after installation.

After the components are installed from an unmanaged package, they can be edited in the org they’re installed in. The developer who creates and uploads an unmanaged package has no control over the installed components, and can't change or upgrade them.

As a best practice, install an unmanaged package only if the org used to upload the package still exists. If that org is deleted, you may not be able to install the unmanaged package.

Don’t use unmanaged packages for sandbox to production migration. Instead, use the Salesforce Extensions for Visual Studio Code or the Ant Migration Tool. If you’re using Enterprise, Unlimited, or Performance Edition, see Change Sets.