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
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Get Access to Agentforce in Your 1GP Packaging Org
Components Automatically Added to First-Generation Managed Packages
Protected Components in Managed Packages
Set Up a Platform Cache Partition with Provider Free Capacity
Package Dependencies in First-Generation Managed Packages
Metadata Access in Apex Code
Permission Sets and Profile Settings in Packages
Permission Set Groups
Custom Profile Settings
Protecting Your Intellectual Property
Call Salesforce URLs Within a Package
Develop App Documentation
API and Dynamic Apex Access in Packages
Connected Apps
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.

Protected Components in Managed Packages

Developers can mark certain components as protected. Protected components can’t be linked to or referenced by components created in a subscriber org. A developer can delete a protected component in a future release without worrying about failing installations. However, after a component is marked as unprotected and is released globally, the developer can’t delete it.

Developers can mark these components as protected in managed packages.

  • Custom labels
  • Custom links (for Home page only)
  • Custom metadata types
  • Custom objects
  • Custom permissions
  • Custom settings
  • Workflow alerts
  • Workflow field updates
  • Workflow outbound messages
  • Workflow tasks

Considerations for Protected Custom Objects in Subscriber Sandboxes

When a subscriber creates either a full or partial sandbox copy using a template, protected custom objects don’t display in the list of objects to copy. As a result, data contained in the records of protected custom objects isn’t copied to these sandboxes. If a full sandbox is created without selecting a sandbox template, data from protected custom objects is copied to the sandbox.