First-Generation Managed Packaging Developer Guide

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
Enable Dev Hub and Second-Generation Managed Packaging
Limited Access License for Package Developers
Add a Limited Access User to Your Dev Hub Org
Link a Namespace to a Dev Hub Org
Scratch Orgs and Package Development
Build and Release Your App with Managed Packages
Packaging Checklist
Deploy the Package Metadata to the Packaging Org
Create a Beta Version of Your App
Install the Package in a Target Org
Create a Managed Package Version of Your App
View Information About a Package
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
AgentExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Create a Beta Version of Your App

Test your app in a scratch org, or share the app for evaluation by creating a beta version.
If you specified the package name when you converted source to metadata format, both the changed and new components are automatically added to the package. Including the package name in that stage of the process lets you take full advantage of end-to-end automation.

If, for some reason, you don’t want to include new components, you have two choices. You can omit the package name when you convert source or remove components from the package in the Salesforce UI before you create the package version.

Create the beta version of a managed package by running the commands against your packaging org, not the Dev Hub org.
  1. Ensure that you’ve authorized the packaging org. 
    1sf org login web --set-default me@example.com
  2. Create the beta version of the package. 
    1sf package1 version create --package-id package_id --name package_version_name
    You can get the package ID on the package detail page in the packaging org. If you want to protect the package with an installation key, add it now or when you create the released version of your package. The --installation-key supplied from the CLI is equivalent to the Password field that you see when working with packages through the Salesforce user interface. When you include a value for --installation-key, you or a subscriber must supply the key before you can install the package in a target org.
You’re now ready to create a scratch org and install the package there for testing. By default, the create command generates a beta version of your managed package.

Later, when you’re ready to create the Managed - Released version of your package, include the -m (--managed-released true) parameter.

After you create a managed-released version of your package, many properties of the components added to the package are no longer editable. Refer to the First-Generation Managed Packaging Developer Guide to understand the differences between beta and managed-released versions of your package.

Note