Learn how profiles and namespace visibility are handled for second-generation managed packages.
-
Package Agentforce Metadata Components
Bring the power of conversational AI to your apps with Agentforce.
-
Develop and Package Agent Templates Using Scratch Orgs
At a high-level, agents are distributed by ISVs as agent templates. To package an agent template, you first create and test an agent in a namespaced scratch org. Then retrieve the agent to your Salesforce DX project, generate an agent template from the agent using Salesforce CLI, and finally package the agent template.
-
MCP for Agentforce Metadata in Managed Packages
Bring the capabilities of your externally hosted Model Context Protocol (MCP) servers to Agentforce by configuring, securely packaging, and distributing your MCP server registration. Learn how to set up your Salesforce DX project and create the MCP server registration.
-
Package Data Cloud Metadata Components
Utilize the power of Data Cloud in your apps by including Data Cloud metadata in your managed packages. Working with Data Cloud metadata has some unique requirements. Review these details to understand how to work with Data Cloud metadata in your packages.
-
Package a Custom Flow Connector as a 2GP Managed Package
Use custom flow connectors with MuleSoft Connector Builder to extend flows to any external service. Learn how to package a connector as a managed 2GP that you can list on AgentExchange or distribute privately.
-
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.
-
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 and My Domain settings.
-
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
To make sure custom application logic works accurately on records associated with the Order object, turn on the Enable New Order Save Behavior setting, and test the behavior. We recommend that you support both the new and old order save behavior during testing.
j