Second-Generation Managed Packaging Developer Guide
Workflow for Second-Generation Managed Packages
Protected Components in Managed Packages
Set Up a Platform Cache Partition with Provider Free Capacity
Metadata Access in Apex Code
Protecting Your Intellectual Property
Call Salesforce URLs Within a Package
Namespace-Based Visibility for Apex Classes in Second-Generation Managed Packages
Work with Services Outside of Salesforce
Package Connected Apps in Second-Generation Managed Packaging
Test and Respond to the New Order Save Behavior
Best Practices for Second-Generation Managed Packages
Gaps Between First-Generation and Second-Generation Managed Packaging
Newer Version Available
Behavior of Specific Metadata in Second-Generation Managed Packages
Learn how profiles and namespace visibility are handled for second-generation managed
packages.
-
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. -
Set Up a Platform Cache Partition with Provider Free Capacity
Salesforce provides 3 MB of free Platform Cache capacity for security-reviewed managed packages. This is made available through a capacity type called Provider Free capacity and is automatically enabled in all Developer edition orgs. -
Metadata Access in Apex Code
Use the Metadata namespace in Apex to access metadata in your package. -
Permission Sets and Profile Settings in Packages
Permission sets, permission set groups, and profile settings are all ways to grant permissions and other access settings to a package. Only use a profile setting if permission sets don’t support the specific access you need to grant. In all other instances, use permission sets or permission set groups. -
Protecting Your Intellectual Property
The details of your custom objects, custom links, reports, and other installed items are revealed to installers so that they can check for malicious content. However, revealing an app’s components prevents developers from protecting some intellectual property. -
Call Salesforce URLs Within a Package
The URLs that Salesforce serves for a target org vary based on the org type and configuration. To build packages that support all possible URL formats, use relative URLs whenever possible. If your package functionality requires a full URL, use the Apex DomainCreator class to get the corresponding hostname. This method allows your package to work in all orgs, regardless of the org type, My Domain settings, and whether enhanced domains are enabled. -
Namespace-Based Visibility for Apex Classes in Second-Generation Managed Packages
The @NamespaceAccessible makes public Apex in a package available to other packages that use the same namespace. Without this annotation, Apex classes, methods, interfaces, and properties defined in a second-generation managed package aren’t accessible to the other packages with which they share a namespace. Apex that is declared global is always available across all namespaces, and needs no annotation. -
Work with Services Outside of Salesforce
-
Package Connected Apps in Second-Generation Managed Packaging
Add a connected app to a second-generation managed package. -
Test and Respond to the New Order Save Behavior
If you created any type of package that includes the Order object, the installed package sometimes doesn’t work, and package upgrades or new package installations are blocked. Here’s why. The Order Save Behavior Release Update addresses an issue where Salesforce didn't correctly evaluate custom application logic on records associated with the Order object.