# developer Platform Pkg Exchange - Full Documentation # About Package Conversion and Package Migration There are two main stages involved in package migrations. It starts with package conversion and ends with package migration. Package conversion takes a managed-released 1GP package version, and creates a 2GP package version with identical metadata. As you explore the package conversion process, you can convert a package to 2GP and still continue your 1GP package development. After a package conversion completes: - The original managed 1GP package is unaltered. - You have both your original managed 1GP package version and a new managed 2GP package version. Package migration is the process of upgrading your existing 1GP subscribers to the new 2GP package. During package migration there’s no change in package metadata or customer data associated with the package. Let's look at an example scenario. ![Graphic displays the package conversion flow](https://developer.salesforce.com/media/pkg1_dev/migration_conversion_states.png) 1. The package conversion process takes the latest released major.minor of Acme's 1GP managed package (4.0) and converts it into a 2GP managed package version with the same major.minor version number (4.0). After package conversion, Acme has a new 2GP managed package version 4.0, and the metadata in both their 1GP and 2GP package versions are identical. 2. Package migration occurs when a 1GP managed package installed in a subscriber org is migrated to the corresponding converted 2GP package. To migrate a subscriber to the managed 2GP package version, the major.minor version of the managed 2GP and the installed managed 1GP must match. In the example in the diagram, Subscriber A has version 4.0 of Acme's 1GP package installed, and after migration Subscriber A has version 4.0 of Acme's 2GP package installed. Moving forward, if Acme decides to release version 4.2, they must use a 2GP package version to upgrade migrated subscribers to version 4.2. # About the Partner WSDL The Partner Web Services WSDL is used for client applications that are metadata-driven and dynamic in nature. It’s particularly—but not exclusively—useful to Salesforce partners who are building client applications for multiple organizations. As a loosely typed representation of the Salesforce data model that works with name-value pairs of field names and values instead of specific data types, it can be used to access data within any organization. This WSDL is most appropriate for developers of clients that can issue a query call to get information about an object before the client acts on the object. The partner WSDL document needs to be downloaded and consumed only once per version of the API. For more information about the Partner WSDL, see [Using the Partner WSDL](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_partner.htm) in _SOAP API Developer Guide_. # Access AgentExchange from Agentforce Builder To keep you in your flow of work, access AgentExchange directly from within Agentforce Builder to discover prebuilt Agentforce assets such as subagents and actions. Before installing an asset, verify that it meets your business needs by reviewing its details. # Access Control in Group and Professional Editions Group Edition doesn’t support field-level security or custom profiles. You can manage field-level security by using the page layout for each object instead. When customers install your app, they can’t define which profiles have access to what. Ensure that your design works for the Standard User Profile. Permission sets can be installed but not updated in Group and Professional Edition orgs. Because the page layout handles field level security, add any fields you want to be visible to the page layout. For fields to be accessible via the API or Visualforce, add them to the page layout. # Access the AgentExchange Partner Console The Partner Console is the complete business management site for ISV partners and consultants with AgentExchange listings. It’s where partners create listings, manage security reviews, and monitor solution performance metrics. ## Before You Begin To access the Partner Console you must have a Salesforce Partner Community login. Learn more in the [Partner Community Registration Guide](https://help.salesforce.com/s/articleView?id=000390506&type=1). |User Permissions Needed| | |-----------------------|--| |To access the AgentExchange Partner Console:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing** to launch the Partner Console. # Accessing REST API in Group and Professional Editions The Lightning Platform REST API provides you with a powerful, convenient, and simple API for interacting with Lightning Platform. As a qualified partner, you can request that we enable your application for REST API calls to GE or PE orgs. To get access to REST API, you must meet these conditions. - Access to the Partner Community. If you’re new, learn about and join one of the ISV Partner Programs. - Pass the security review. All applications enrolled in the ISV or OEM Program must go through a periodic security review. - Access to Salesforce Developer Edition. If you don’t already have access to a DE org, you can get the Partner Developer Edition from the Environment Hub. To request a REST API token: 1. Create a connected app from your DE org. Log in to your Salesforce org with your developer account. From Setup, in the Quick Find box, enter `Apps`, and then select **Apps**. In the Connected Apps section, click **New**. **note:** We strongly recommend that you work in an org that you plan to use for a long time, such as the one where you build your managed package or your Trialforce management org (TMO). 2. Enter the information requested, and click **Save**. Saving your app gives you the Consumer Key and Consumer Secret that the app uses to communicate with Salesforce. 3. Log a support case in the [Salesforce Partner Community](https://partners.salesforce.com). For product, specify **Partner Programs & Benefits**. For topic, specify **ISV Technology Request**. Provide your DE Org ID and the credentials for your connected app. We evaluate your request and enable the appropriate permission. You receive a case notification from us. Wait 24 hours to make sure that the permission is activated. Your client_id (or Consumer Key) and client_secret (or Consumer Secret) are checked against the information that you submit via the case during the OAuth authentication. If it matches, the system allows you to communicate with GE and PE editions. **note:** - This permission is intended solely for REST API. It doesn’t enable your application to use SOAP API, Bulk API, or Metadata API for GE and PE editions. - This permission is applied only to your application. We don’t turn on the API in the GE and PE org. # Add a Limited Access User to Your Dev Hub Org Provide your developers access to the Dev Hub and Salesforce DX development tools by adding a user with Salesforce Limited Access - Free license and the Limited Access user profile in your Dev Hub org. Then create and assign them a permission set to the required Dev Hub objects. ## Before You Begin The Salesforce Limited Access - Free is designed for users whose role is to build customizations or applications. This license provides access to the Dev Hub, development tools, and environments. In the production org, this license restricts access to standard and custom objects. 1. Create a user in your Dev Hub org. 1. In Setup, enter `Users` in the Quick Find box, then select **Users**. 2. Click **New User**. 3. Fill out the form. 4. Select **Salesforce Limited Access - Free** for User License, and then **Limited Access User** for Profile. 5. After filling out the remaining information, click **Save**. 2. Create a permission set that provides your developer users with access to the required Dev Hub objects. For details, see [Create and Assign a Permission Set for Developer Users](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_permission_set.htm) or [Assign Second-Generation Managed Packaging User Permissions](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_user_permission.htm). # Add AI Details to Your Agentforce Solution Listing Showcase the value of your Agentforce solution on your AgentExchange listing. Explain the solution’s capabilities and how it extends Agentforce. State the number of agents, topics, and actions in your managed package. This information aids customer understanding and enables filtering in AgentExchange search results. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Listings**. 3. Select an existing Agentforce solution listing, or create one. 4. Click **Fill in the Basics**. 5. For Agentforce Capabilities Description, summarize what your solution enables Agentforce to do in 100 characters or fewer. It’s ok to get technical. Assume the customer understands Agentforce concepts. 6. Enter the number of agents, topics, and actions. 7. Save your changes. ## Next Steps After you publish your listing, the capabilities description (1) and the number of agents, topics, and actions (2) appear on the listing card. The numeric values also appear on the listing page in the Agentforce Contents section. On AgentExchange, customers can filter solutions based on the agents, topics, and actions they contain. ![A listing tile on AgentExchange shows the Agentforce capabilities description and the number of agents, topics, and actions.](https://developer.salesforce.com/docs/media/appexchange_agentforce_listing_tile.png) **See Also** - [AI Details for Your Agentforce Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-agentforce-listing-details.md) # Add Approvers Add users to the Install Request Approvers list so they can install AgentExchange apps on behalf of requesters in your org. To add users to the Install Request Approvers list: 1. From Setup, go to **Install Request Approvers**. 2. Click **Add Approver**. 3. In the Add approvers window, use **Search this list...** to find users. 4. Select one or more eligible users, and then click **Add Approvers**. Active approvers who have the Download AgentExchange Packages permission receive an in-app notification and an email when someone submits a request. The email identifies the requester, requested asset, containing app, the org where the app will be installed, and the business justification. It also includes an Install link that opens the package installation page. To remove approvers, see Remove Approvers. To stop routing install requests to approvers, see [Turn Off Install Request Approvers](https://developer.salesforce.com/docs/platform/appexchange-install-guide/guide/agentexchange-agentforce-turn-off-install-approvers.md). # Add Feature Parameters to Your Managed Package After you’ve created some feature parameters, you can add them to a managed package as components and reference them in your code. Feature parameters aren’t available in unmanaged packages. A package can include up to 200 feature parameters. Complete these steps in your packaging org. 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. In the Packages section, in the Package Name column, select your managed package. 3. On the Components tab, click **Add**. 4. From the Component Type dropdown, select **Feature Parameter Boolean**, **Feature Parameter Date**, or **Feature Parameter Integer**. 5. Select your feature parameter, and then click **Add to Package**. # Add MCP Servers to Your Agentforce Agents Add Model Context Protocol (MCP) servers to your Agentforce agents. Agentforce doesn’t automatically detect MCP servers from installed packages. Add them manually so your listing accurately presents what’s included in your package listing. ## Steps 1. Open the Agentforce listing that uses the MCP servers. 2. Click **MCP Servers**. 3. Click **List an MCP Server**. 4. Fill in the server name and description. 5. Click **Add** to add tools as needed. Fill in the name and description. Each server needs at least one tool. 6. Save your changes. # Adding Custom Automation to License Management App Objects Here are some examples of how you can use the License Management App (LMA) to grow your business and retain customers. | Availability | | ------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, and **Unlimited** Editions | ## Alert Sales Reps Before a License Expires If you’re managing licenses for several packages, it can be difficult to track the various expirations. If a license expires accidentally, you could even lose a customer. To help your customers with renewals, set up an Apex trigger or create a flow to email a sales rep on your team before the license expires. ## Notify Customer-Retention Specialists When an Offering Is Uninstalled If a customer uninstalls your offering, find out why. By speaking to the customer, you have an opportunity to restore the business relationship or receive feedback that helps you improve your offering. To notify a customer-retention specialist on your team, follow these high-level steps. 1. Create an email template for the notification. 2. Create a workflow rule with a filter that specifies that the License Status equals `Uninstalled`. 3. Associate the workflow rule with a workflow alert that sends an email to the retention specialist. # Advanced Features for Second-Generation Managed Packages After you're comfortable with creating second-generation managed packages, learn about these advanced features to customize your package development processes. - **[Package Ancestors for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-package-ancestor-intro.md)** Second-generation managed packaging (managed 2GP) offers a flexible package versioning model that lets you break your linear versioning and abandon a package version you no longer want to build upon. We call these versioning decisions *package ancestry*. - **[Patch Versions for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-patch-version.md)** Patch versions are a way to fix small issues with your second-generation managed package without introducing major feature changes. Customers who are using an older version of your package can install a patch and not be forced to upgrade to a new major package version. - **[Create Dependencies Between Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-dependencies.md)** To avoid monolithic package development practices, plan to develop smaller, modular packages that group similar functionality and components. You can then define the dependencies between these packages. A package dependency is when metadata contained in one package depends on metadata contained in another package. For example, defining dependencies allow you to extend the functionality of a base package with components and metadata located in a separate package. - **[Considerations for Promoting Packages with Dependencies](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-considerations-pkg-dependency.md)** If your company is developing a package that has a package dependency, ask yourself these questions before promoting (releasing) a new package version. - **[Advanced Project Configuration Parameters for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-adv-config-file.md)** As your managed 2GP package development becomes more complex, consider including these optional parameters in your `sfdx-project.json` file. - **[Second-Generation Managed Packaging Keywords](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-keywords.md)** A keyword is a variable that you can use to specify a package version number. - **[Target a Specific Release for Your Second-Generation Managed Packages During Salesforce Release Transitions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-target-release-version.md)** During major Salesforce release transitions, you can specify `preview` or `previous` when creating a package version. Specifying the release version for a package allows you to test upcoming features, run regression tests, and support customers regardless of which Salesforce release their org is on. Previously, you could only create package versions that matched the Salesforce release your Dev Hub org was on. - **[Use Branches in Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-use-branches.md)** Development teams who use branches in their source control system (SCS), often build package versions based on the metadata in a particular branch of code. - **[Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-unpackaged-md.md)** For scenarios where you require metadata that isn’t part of your second-generation managed package, but is necessary for Apex test runs, you can specify the path containing unpackaged metadata in the `sfdx-project.json` file. The unpackaged metadata isn’t included in the package and isn’t installed in subscriber orgs. - **[Package IDs and Aliases for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-pkg-types-pkg-ids.md)** During the package lifecycle, packages and package versions are identified by an ID or package alias. When you create a second-generation managed package or package version, Salesforce CLI creates a package alias based on the package name, and stores that name in the packageAliases section of the `sfdx-project.json` file. When you run CLI commands or write scripts to automate packaging workflows, it’s often easier to reference the package alias, instead of the package ID or package version ID. - **[Avoid Namespace Collisions in Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-namespace-collisions.md)** Namespaces impact the combination of package types that you can install in an org. - **[Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-remove-md-components.md)** Remove metadata components such as Apex classes that you no longer want in your second-generation managed packages. - **[Delete a Second-Generation Managed Package or Package Version](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-package-deletion.md)** Use the `sf package version delete` and `sf package delete` commands to delete packages and package versions that you no longer need. - **[Frequently Used Packaging Operations for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-packaging-operations.md)** - **[Transfer a Second-Generation Managed Package to a Different Dev Hub](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-package-transfer.md)** You can transfer the ownership of a second-generation managed package (managed 2GP) from one Dev Hub org to another. These transfers can occur either internally between two Dev Hub orgs your company owns, or you can transfer a package externally to another Salesforce Partner or ISV. This change provides a way to sell a managed 2GP package to a different company. - **[Contact Salesforce Partner Support to Enable Specific Packaging Features](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pkg2-feature-enablement.md)** Certain packaging features can only be enabled by Salesforce Partner Support. # Advanced Project Configuration Parameters for Second-Generation Managed Packages As your managed 2GP package development becomes more complex, consider including these optional parameters in your `sfdx-project.json` file. | Name | Details | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | apexTestAccess | **Required?** No **Default if Not Specified:** None Assign permission sets and permission set licenses to the user in context when your Apex tests run at package version creation. See [Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-unpackaged-md.md) | | branch | **Required?** No **Default if Not Specified:** None. If your package has an associated branch, but your package dependency is associated with a different branch, use this format. If your package has an associated branch, but your package dependency doesn’t have an associated branch, use this format. See [Use Branches in Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-use-branches.md) | | calculateTransitiveDependencies | **Required?** No **Default if Not Specified:** false Enables the calculation of the package’s indirect dependencies. A package can have multiple levels of dependencies, where pkgC depends on pkgB, and pkgB depends on pkgA, for example. By default, you list all of a package’s dependencies, including indirect (transitive) dependencies. When calculateTransitiveDependencies is set to `true`, you specify a package’s direct dependencies only, and the indirect dependencies are calculated for you. See the dependencies parameter’s description for example configurations in the `sfdx-project.json` file. calculateTransitiveDependencies also enables you to generate a hierarchical graph of a package version’s dependencies. To generate the dependencies graph, run the `package version displaydependencies` CLI command. See [package version displaydependencies](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_version_displaydependencies_unified) in the _Salesforce CLI Command Reference_. | | dependencies | **Required?** No **Default if Not Specified:** None Specify the dependencies on other packages. To specify dependencies for managed packages within the same Dev Hub, use either the package version alias or a combination of the package name and the version number. To specify dependencies for managed packages outside of the Dev Hub use: To set the dependency, you can use the [keywords](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_keywords.htm) RELEASED or LATEST for the version number. To denote dependencies with package IDs instead of package aliases, use: The `0Ho` ID if you specify the package ID along with the version number; or The `04t` ID if you specify only the package version ID. If the package has more than one dependency, provide a comma-separated list of packages in the order of installation. For example, if a package depends on the package Expense Manager - Util, which in turn depends on the package External Apex Library, the package dependencies are: If you set the calculateTransitiveDependencies parameter to `true`, you specify the package’s direct dependencies only, and the indirect (transitive) dependencies are calculated for you. For example, if calculateTransitiveDependencies is enabled and the package depends on the package Expense Manager - Util, which in turn depends on the package External Apex Library, the package dependency is: See: [Considerations for Promoting Packages with Dependencies](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-considerations-pkg-dependency.md) | | postInstallScript | **Required?** No **Default if Not Specified:** None. An Apex script that runs automatically in the subscriber org after the managed package is installed or upgraded. | | postInstallURL | **Required?** No **Default if Not Specified:** None. A URL to post-install instructions for subscribers. | | releaseNotesUrl | **Required?** No **Default if Not Specified:** None. A URL to release notes. | | scopeProfiles | **Required?** No **Default if Not Specified:** false. The scopeProfiles parameter is a child of packageDirectories. If you set scopeProfiles to true for a package directory, profile settings from only the package directory being packaged are included, and profile settings outside of that package directory are ignored. When you set scopeProfiles to false (the default value), the new package version includes relevant pieces of profile settings in any package directory defined in `sfdx-project.json`. | | unpackagedMetadata | **Required?** No **Default if Not Specified:** None See [Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-unpackaged-md.md). | | uninstallScript | **Required?** No **Default if Not Specified:** None. An Apex script to run automatically in the subscriber org before the managed package is uninstalled. | Example apexTestAccess: ```nolang "apexTestAccess": { "permissionSets": [ "Permission_Set_1", "Permission_Set_2" ], "permissionSetLicenses": [ "SalesConsoleUser" ] } ``` Example branch: ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "1.3.0.LATEST", "branch": "featureC" } ] ``` Example branch: ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "1.3.0.LATEST", "branch": "" } ] ``` Example dependencies: ```javascript "dependencies": [ { "package": "MyPackageName@1.1.0.1" } ] ``` Example dependencies: ```javascript "dependencies": [ { "package": "MyPackageName", "versionNumber": "1.1.0.RELEASED" } ] ``` Example dependencies: ```javascript "dependencies": [ { "package": "04txxx" } ] ``` Example dependencies: ```javascript "dependencies": [ { "package" : "External Apex Library - 1.0.0.4" }, { "package": "Expense Manager - Util", "versionNumber": "4.7.0.RELEASED" } ] ``` Example dependencies: ```javascript "dependencies": [ { "package": "Expense Manager - Util", "versionNumber": "4.7.0.RELEASED" } ] ``` **See Also** - [Project Configuration File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm) # After Installing a Package After installing a solution from AgentExchange, manage it like you manage the other solutions and packages you installed in your Salesforce org. ## Manage Installed Packages Manage packages installed in your Salesforce org, including assigning licenses to users, uninstalling packages, and exporting package data. **note:** Salesforce only lists license information for managed packages. For unmanaged packages, the license-related fields, such as **Allowed Licenses**, **Used Licenses**, and **Expiration Date**, displays the value “N/A.” - Click **Uninstall** to remove the package and all its components from your Salesforce organization. - Click **Upgrade to Recommended Version** to install the package version recommended by the package publisher. - Click **Manage Licenses** to assign available licenses to users in your organization. **note:** If you purchased a site license or if the managed package is not licensed, Salesforce assigns licenses to all your users and you can’t manage licenses. Your users can use the package as long as they have the appropriate permissions. - Click **Become Primary Contact** to update the current contact for the installed package to your username. This contact name displays for the package publisher from the Push Package Upgrade page. Initially, it’s set to the name of the person who installed the package. If you have Download AgentExchange Packages permission and aren’t the current primary contact, this option is enabled. - Click **Configure** if the publisher has included a link to an external website with information about configuring the package. - Click the package name to view details about this package. - View the publisher of the package. - View the status of the licenses for this package. Available values include: - Trial - Active - Suspended - Expired - Free This field is only displayed if the package is managed and licensed. - Track the number of licenses available (Allowed Licenses) and the number of licenses that are assigned to users (Used Licenses). - View the date your licenses for this package are scheduled to expire. - View the date your licenses were installed. - View the number of custom apps, tabs, and objects this package contains. - See whether the custom apps, tabs, and objects count toward your organization’s limits. If they do, the box in the Limits column is checked. **note:** If you have not installed a licensed managed package, the Publisher, Status, Allowed Licenses, Used Licenses, and Expiration Date fields do not appear. After an uninstall, Salesforce automatically creates an export file containing the package data, associated notes, and any attachments. When the uninstall is complete, Salesforce sends an email containing a link to the export file to the user performing the uninstall. The export file and related notes and attachments are listed below the list of installed packages. We recommend storing the file elsewhere because it’s only available for a limited time after the uninstall completes. Using this list, you can: - Click **Download** to open or store the export file. - Click **Del** to delete the export file. If a criteria-based sharing rule references a field from a licensed managed package whose license has expired, (expired) is appended to the label of the field. The field label is displayed in the field drop-down list on the rule’s definition page in Setup. Criteria-based sharing rules that reference expired fields aren't recalculated, and new records aren't shared based on those rules. However, the sharing of existing records prior to the package's expiration is preserved. ## Uninstall a Managed Package Uninstalling a managed package removes its components and data from the org. During the uninstall process, any customizations, including custom fields or links, that you’ve made to the package are removed. 1. From Setup, enter `Installed Packages` in the Quick Find box, then select **Installed Packages**. 2. Click **Uninstall** next to the package that you want to remove. 3. Determine whether to save and export a copy of the package’s data, and then select the corresponding radio button. 4. Select **Yes, I want to uninstall** and click **Uninstall**. If you choose to save a copy of the package data, we create an export file containing the package data, associated notes, and any attachments. When the uninstall is complete, we send an email containing a link to the export file to the user performing the uninstall. We delete export files two days after a completed package uninstall. ## Considerations on Uninstalling Packages - If you’re uninstalling a package that includes a custom object, all components on that custom object are also deleted. Deleted items include custom fields, validation rules, custom buttons, and links, workflow rules, and approval processes. - You can’t uninstall a package whenever a component not included in the uninstall references any component in the package. For example: - When an installed package includes any component on a standard object that another component references, Salesforce prevents you from uninstalling the package. An example is a package that includes a custom user field with a workflow rule that gets triggered when the value of that field is a specific value. Uninstalling the package would prevent your workflow from working. - When you’ve installed two unrelated packages that each include a custom object and one custom object component references a component in the other, you can’t uninstall the package. An example is if you install an expense report app that includes a custom user field and create a validation rule on another installed custom object that references that custom user field. However, uninstalling the expense report app prevents the validation rule from working. - When an installed folder contains components you added after installation, Salesforce prevents you from uninstalling the package. - When an installed letterhead is used for an email template you added after installation, Salesforce prevents you from uninstalling the package. - When an installed package includes a custom field that’s referenced by Einstein Prediction Builder or Case Classification, Salesforce prevents you from uninstalling the package. Before uninstalling the package, edit the prediction in Prediction Builder or Case Classification so that it no longer references the custom field. - You can’t uninstall a package that removes all active business and person account record types. Activate at least one other business or person account record type, and try again. - You can’t uninstall a package if a background job is updating a field added by the package, such as an update to a roll-up summary field. Wait until the background job finishes, and try again. # AgentExchange App Analytics Best Practices To plan and maximize your AgentExchange App Analytics query strategy, follow our best practices. First, use file compression to reduce your data results file size. Second, schedule and automate your regular App Analytics queries. Third, plan, schedule, and automate catch-up queries to supplement your regular query data. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | - **[How Does AgentExchange App Analytics Data Flow?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-data-flow.md)** As your customers use your managed packages, they produce data. Their usage data is collected daily in our data lake from each Salesforce instance. Usage data arrives to our data lake throughout the day. From time to time, there can be data arrival delays. Also, data builds and timestamps vary by data type. For these reasons, to optimize your data retrieval, plan out your AgentExchange App Analytics query strategy. - **[How Should I Plan My App Analytics Query Strategy?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-query-strategy.md)** Your detailed query strategy depends on the size and scope of your business and the data types that you’re querying. - **[Recommendations](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-recommendations.md)** Your query strategy varies based on your business size and scope. Also, your query strategy must adapt as your business grows. To stay current, follow our App Analytics query recommendations for small, medium, and large-sized partners. - **[Where Do I Go for More Information About AgentExchange App Analytics Queries?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-more-information.md)** Questions are natural when you start automating your queries and planning your query strategy. To find a good solution when you have questions, review your code base and the size and skill of your development team. # AgentExchange App Analytics Developer Cookbook Delve deeper into your AgentExchange App Analytics managed package usage data by creating key performance indicators (KPIs). First, complete some prerequisites and retrieve your App Analytics data. Next, prepare your CRM Analytics environment. Finally, to build your KPIs, complete App Analytics recipes. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [ISV Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). 1. [What Are Recipes?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-what-are-recipes.md) The AgentExchange App Analytics Developer Cookbook uses two distinct types of recipes: CRM Analytics recipes and App Analytics recipes. The CRM Analytics recipes are foundational work that you must complete before creating App Analytics recipes. App Analytics recipes build on your CRM Analytics recipe analytics environment and result in key performance indicators (KPIs). 2. [Before You Begin](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-prework.md) Complete these prerequisites before you create App Analytics recipes. 3. [CRM Analytics Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-intro.md) Set up your org to create AgentExchange App Analytics recipes by building your CRM Analytics environment. You first create a country-codes dataset. Then you create two CRM Analytics recipes to produce a dataset of your subscriber info, and an aggregate dataset of all of your daily data. 4. [App Analytics Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-intro.md) To understand how your customers are using your managed packages and components, create App Analytics recipes. Each App Analytics recipe produces a CRM Analytics lens and is a key performance indicator (KPI). Use CRM Analytics dashboards to visualize your KPIs and gain deeper insights. # AgentExchange App Analytics for First-Generation Managed Packages AgentExchange App Analytics provides usage data about how subscribers interact with your first-generation (1GP) managed packages and packaged components. You can use these details to identify attrition risks, inform feature development decisions, and improve user experience. **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). Usage data from [Government Cloud and Government Cloud Plus](https://www.salesforce.com/solutions/industries/government1/products/government-cloud/) orgs isn’t available in App Analytics. App Analytics is available for managed 1GP packages that passed security review and are registered to a License Management App. Usage data is provided as package usage logs, monthly package usage summaries, or subscriber snapshots. All usage data is available as downloadable comma-separated value (.csv) files. To view the data in dashboard or visualization format, use [CRM Analytics](https://help.salesforce.com/articleView?id=bi_explorer.htm) or a third-party analytics tool. In a 24-hour period, you can download a maximum 20 GB of AgentExchange App Analytics data. - **[Enable App Analytics on Your First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/app-analytics-enable-1gp.md)** Activate AgentExchange App Analytics on your first-generation (1GP) managed package to access AgentExchange App Analytics package usage logs and subscriber snapshots. Package usage summaries are available by default. **See Also** - [Get Started with AppExchange App Analytics](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/app_analytics_intro_2gp.htm) # AgentExchange Considerations Keep these considerations in mind when working with the solutions available on AgentExchange. - AgentExchange Support for Lightning Experience on iPad Safari - : AgentExchange solutions aren’t supported on Lightning Experience on iPad Safari. We recommend that you use Lightning Experience on a desktop with solutions that you install from AgentExchange. # AgentExchange Go-To-Market App Guide The Go-To-Market (GTM) app delivers a complete buying experience powered entirely by Salesforce. It offers several major benefits for you—our partners and your customers. Customers get a cohesive purchasing and billing journey, orchestrated within the Salesforce Platform, which means fewer manual steps for everyone. Automating the selling journey creates opportunities for your teams to shift focus from administration to innovation. For partners, your team can focus on innovation and efficiency, which often translates directly to growth. By automating provisioning and payment collection, we simultaneously reduce operational overhead and minimize liability. Best of all, the GTM app unlocks new revenue potential. With a wider range of pricing models, you can create more compelling customer offers, including options for consumption-based selling and permission set licenses. # AgentExchange Lead Sources AgentExchange leads include details to help you understand the source—that is, where and how the lead originated. The lead source code identifies the action that the customer performed to generate the lead, such as watching a demo video. The lead source description provides information about how the customer discovered your listing, such as a third-party marketing campaign. ## Lead Source Codes The Lead Source field stores lead source codes in this format: `SFDC-XX|Listing Name` or `SFDC-dup-XX|Listing Name`. `XX` identifies the action that the customer performed to generate the lead. This table lists source codes. | Source Code | Description | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DM` | The user clicks the demo video tile in the media carousel of your listing. | | `IN` | This code is applied when a user takes one of these actions. Sometimes users don’t complete the installation, or they uninstall your solution later. To track package installations, use the [License Management App (LMA)](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/lma_intro.htm). | | `LM` | The user clicks **Learn More** on your listing. Listings that previously had Learn More buttons now have Get It Now buttons and receive lead source codes with IN actions. | | `OR_NONUS` | A user clicks **Request Private Offer** and selects outside the United States as their country. | | `OR_US` | A user clicks **Request Private Offer** and selects the United States as their country. | | `TD` | The user clicks **Try It** on your listing and starts a test drive of your solution. | | `TS` | This code is applied when a user takes one of these actions. | ## Lead Source Description The lead source description indicates how a customer discovered your listing and, if applicable, their contact preferences about other products or services that you offer. Lead source descriptions vary based on how you market your listing, but can include: - Urchin Tracking Module (UTM) parameters from marketing campaigns. - Codes from referral programs. - External traffic sources, such as Google searches. - Internal traffic sources, such as AgentExchange searches. **note:** UTM, referral code, and traffic source details are available for AgentExchange solution listings. For consultant listings, the lead source description includes only a customer’s contact preference in text format. The Description field stores these details in JSON format: ```javascript { "lead_description": { "allow_contact_other_products": true, "listing_url": "example-URL", "offer_request_details": "example-details", "utm_parameters": { "utm_campaign": "example-campaign", "utm_content": "example-content", "utm_medium": "example-medium", "utm_source": "example-source", "utm_term": "example-term" }, "referral_code": "example-code" } } ``` If UTM or referral code details aren’t available, AgentExchange omits them and populates an `other_source` property from a standard list of internal and external traffic sources: ```javascript { "lead_description": { "allow_contact_other_products": true, "listing_url": "example-URL", "other_source": "example-traffic-source" } } ``` To receive UTM or referral code details in your lead source description, configure a referrer URL as follows: `https://appexchange.salesforce.com/appxListingDetail?listingId=a0NXXXXXXXXXXXXXXX &utm_campaign=example-campaign&utm_content=example-content&utm_medium=example-medium &utm_source=example-source&utm_term=example-term&referral_code=example-code` Where _a0NXXXXXXXXXXXXXXX_ is your listing ID. **tip:** To configure a referrer URL that contains only UTM parameters, consider Google’s [Campaign URL Builder](https://ga-dev-tools.google/campaign-url-builder/). This table lists lead source description properties. | Property | Type | Description | | ------------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `allow_contact_other_products` | Boolean | The customer’s contact preference regarding marketing communications for other products and services that you offer. If you don’t offer products or services outside of the listing where the lead originated, ignore this property. Examples: | | `listing_url` | String | The URL of the listing where the lead was generated, without the UTM parameters, referral codes, and traffic source details. | | `other_source` | String | The source that referred traffic to your listing if UTM parameters or referral codes aren’t provided. This property is set by AgentExchange. The default value is `Web`.Examples: | | `referral_code` | String | A unique identifier associated with the content or campaign, such as a discount code. To populate this property, include one of these parameters in the referrer URL:Example: `ref=astro25off` | | `utm_campaign` | String | The promotional or marketing campaign that referred traffic to your listing. To populate this property, include the `utm_campaign` parameter in the referrer URL. Example: `utm_campaign=appy-dreamforce` | | `utm_content` | String | The content zone or variant that referred traffic to your listing, such as a banner that uses a specific call to action or image. To populate this property, include the `utm_content` parameter in the referrer URL. Example: `utm_content=cta-header-1` | | `utm_medium` | String | The medium that referred traffic to your listing, such as cost per click. To populate this property, include the `utm_medium` parameter in the referrer URL. Example: `utm_medium=cpc` | | `utm_source` | String | The source that referred traffic to your listing, such as a newsletter. To populate this property, include the `utm_source` parameter in the referrer URL. This property is required to use other UTM parameters. Example: `utm_source=newsletter` | | `utm_term` | String | The keyword or phrase that referred traffic to your listing. To populate this property, include the `utm_term` parameter in the referrer URL. Example: `utm_term=sales+productivity` | ## Example This example shows a sample referrer URL and the related JSON block. In this example, we assume that the customer agrees to marketing communications. For this sample URL: `https://appexchange.salesforce.com/appxListingDetail?listingId=a0NXXXXXXXXXXXXXXX &utm_campaign=spring&utm_medium=organic_social&utm_source=newsletter` This JSON block appears in the Description field of the lead: ```javascript { "lead_description": { "allow_contact_other_products": true, "listing_url": "https://appexchange.salesforce.com/appxListingDetail?listingId=a0NXXXXXXXXXXXXXXX", "utm_parameters": { "utm_campaign": "spring", "utm_medium": "organic_social", "utm_source": "newsletter" } } } ``` ## Package Installation Leads Package installation is one example of a user activity that triggers lead creation. However, AgentExchange isn’t the only source of installation leads. The License Management App (LMA) also creates installation leads. Let’s look at an example. A user purchases your solution and installs it via an installation URL. AgentExchange isn’t aware of the user’s activity, so it doesn’t create a lead. However, the installation triggers the License Management App to create a lead. To know which application created the lead, check the lead source code. **note:** The source code for License Management App leads is `Package Installation`. Let's update the example and see how multiple installation leads are created for the same package. First, a user clicks **Get It Now**, and starts but doesn’t complete the installation. AgentExchange creates a lead with source code `SFDC-IN|Simple Sample App`. Later, the same user purchases your solution and installs it via an installation URL. The License Management App creates a second lead with source code `Package Installation`. Same user. Same package. On the surface, the leads appear to be duplicates, but the lead source codes show that they aren’t. Learn more about License Management App leads in [Lead and License Records in the LMA](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/lma_terms_relationships.htm). ## Duplicate Leads A duplicate lead is a lead that AgentExchange sent to your org for this user, listing, or action within the past 180 days. Duplicate lead source codes always contain the string `-dup-` and use the format `SFDC-dup-XX|Listing Name`. For example, `SFDC-dup-DM|Simple Sample App` indicates a duplicate lead from a user who clicked **View Demo** on the Simple Sample App listing. # AgentExchange Leads When you turn on lead collection for your AgentExchange listing and a customer interacts with the listing, AgentExchange records a lead. If you enabled Web-to-Lead in your Salesforce org, AgentExchange delivers the lead to that org. Some Web-to-Lead settings prevent leads from being delivered to your org. You collect leads when a customer: - Installs your solution - Takes a test drive - Watches a demo or video - Signs up for a free trial - Requests a private offer - Clicks **Learn More** Before you turn on lead collection on your listings: - Configure Web-to-Lead in the org where you want to receive leads. - Turn off Require reCAPTCHA verification in the org’s Web-to-Lead settings. No AgentExchange leads are sent to the org if reCAPTCHA is turned on. To collect leads, select and configure the customer interactions for your listing. Some interactions have requirements, such as uploading a video before enabling demo-based lead collection. If lead collection is on, customers are prompted to fill out a sign-up form. The customer form and activity data are then shared as a lead. **note:** You can’t modify the lead form that customers fill out. To share ideas for improving the lead form, go to [IdeaExchange](https://ideas.salesforce.com/). Regardless of your listing’s lead-collection settings, customers can still view your demo, take a test drive, click to learn more, and install your solution. # AgentExchange Leads and License Activities When you turn on lead collection for your AgentExchange listing and a customer interacts with your listing, AgentExchange records a lead. License records generate when a customer installs your solution. AgentExchange captures leads when a customer interacts with your listing: - Installs your solution - Takes a test drive - Watches a demo or video - Signs up for a free trial - Requests a private offer - Clicks **Learn More** By contrast, license records are generated only when a customer installs your solution. To receive licenses, you must also have the [License Management Application (LMA)](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_publish_manage.htm) enabled in your partner business org. To learn more about requests for private offers, visit [AgentExchange Go-To-Market App Guide](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/partner_marketplace_intro.htm). # AgentExchange Security Review for Your Solution The AgentExchange security review tests the security posture of your solution. If your solution is subject to review, it must pass before you can publicly distribute it on AgentExchange. To learn which solutions are subject to security review and how to prepare for and pass your review, see [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-guidelines.md). **See Also** - [Security Requirements for ISV Partners and AgentExchange Solutions](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-create-secure-solution.md) # AgentExchange Solution Types As a Salesforce ISV partner, you can distribute packaged solutions and APIs on AgentExchange. As you're planning your AgentExchange business, make sure that your solution type is supported. |Solution Category|Solution Types| |-----------------|--------------| |Packaged Solution|| |API|| # AI Details for Your Agentforce Solution Help customers assess your Agentforce solution's AI capabilities. Write a description that summarizes what the solution enables Agentforce to do. Let customers know how many agents, topics, and actions are in the solution. On AgentExchange, customers can filter search results to find solutions that contain agents, topics, and actions. You can add information to your Agentforce solution listings that helps customers understand your solution's AI capabilities. Write a description about how it automates tasks, improves productivity, or increases efficiency. Build on the listing's brief description (1). In the AgentExchange Listing Builder, add your AI-focused description to the listing in the Agentforce Capabilties Description field (2). Count how many agents, topics, and actions are in the solution. Add these to your listing in the Number of Agents, Number of Topics, and Number of Actions fields (3). Customers gain valuable insights through these metrics. - Number of Agents: Indicates the scope of automation a customer can expect. - Number of Topics: Helps customers assess if the solution has a specific focus or broad versatility. - Number of Actions: Lets customers gauge how much the solution can reduce manual work. Low numbers indicate a specialized solution that's ideal for a niche process. High numbers indicate a comprehensive solution that supports broad automation. ![The Listing Builder’s Fill in the Basics step is where you describe your Agentforce solution’s capabilities and contents.](https://developer.salesforce.com/docs/media/listing_builder_agentforce_info.png) The capabilities description (1) and the numeric values (2) appear on the [AgentExchange](https://agentexchange.salesforce.com) listing card. ![An Agentforce listing card showing the Agentforce capabilities description and number of agents, topics, and actions](https://developer.salesforce.com/docs/media/appexchange_agentforce_listing_tile.png) The brief description from Fill in the Basics (1) and the numeric values (2) appear on the [AgentExchange](https://appexchange.salesforce.com) listing page. ![ listing page showing the brief description, and the number of agents, topics, and actions](https://developer.salesforce.com/docs/media/appexchange_agentforce_listing.png) On AgentExchange, customers can use Agentforce Contents filters to narrow search results and find solutions that contain actions, agents, and topics. ![The filter panel on AgentExchange showing three Agentforce contents filters: action, agents, and topics](https://developer.salesforce.com/docs/media/agentforce_contents_filters.png) **See Also** - [Add AI Details to Your Agentforce Solution Listing](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-add-ai-details.md) # Apex Deprecation Effects for Subscribers Explore how deprecation of an Apex method impacts subscribers that install your managed package. The table shows a typical sequence of actions by a package developer in the first column and actions by a subscriber in the second column. Each row in the table denotes either a package developer or subscriber action. | Package Developer Action | Subscriber Action | Notes | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create a global Apex class, `PackageDevClass`, containing a global method `m1`. |   |   | | Upload as Managed - Released version 1.0 of a package that contains `PackageDevClass`. |   |   | |   | Install version 1.0 of the package. | The Version Number for the package is 1.0. The First Installed Version Number is 1.0. | |   | Create an Apex class, `SubscriberClass`, that references `m1` in `PackageDevClass`. |   | | Deprecate `m1` and create a new method, `m2`. |   |   | | Upload as Managed - Released version 2.0 of the package. |   |   | |   | Install version 2.0 of the package. | The Version Number for the package is 2.0. The First Installed Version Number is still 1.0. `SubscriberClass` still references version 1.0 of the package and continues to function, as before. | |   | Edit the version settings for `SubscriberClass` to reference version 2.0 of the package. Save the class. Note an error message indicating that `m1` can’t be referenced in version 2.0 of the package. |   | |   | Change `SubscriberClass` to reference `m2` instead of `m1`. Successfully save the class. |   | # Apex Interactions Each record in your package usage log that has a `custom_entity_type` of `ApexClass` or `ApexTrigger` describes an interaction with your packaged Apex class or trigger. | | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | ## Apex Execution When `log_record_type` is `ApexExecution`, the log record is associated with a user action that resulted in the execution of Apex code from an Apex class or trigger. Only the outermost Apex is captured. | Standard Data | Supplemental Data | | -------------------------------------------------- | ------------------ | | | `num_soql_queries` | ## Apex Unexpected Exception When `log_record_type` is `ApexUnexpectedException`, the log record is associated with a user action that resulted in an Apex class or trigger throwing an unhandled exception. The `stack_trace` field provides detail about the Apex unexpected exceptions. | Standard Data | Supplemental Data | | ------------- | ----------------- | | `stack_trace` | none | ## Example Let’s look at an example package usage log record and analyze the Apex interaction. ```nolang { "timestamp_derived": "2022-11-22T06:19:33.990Z", "log_record_type": "ApexExecution", "request_id": "4mbhxFWBBXz83tlq2Z5aAk", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=", "user_type": "Standard", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "InsuranceDetailsBatchable", "custom_entity_type": "ApexClass", "session_key": "2l4YtFB/RmsRKVsS", "login_key": "fGV6RgVOH3ZCgl2v", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "US", "user_time_zone": "America/Los_Angeles", "entry_point": "Acme.InsuranceDetailsBatchable", "num_soql_queries": "2", "quiddity": "A" } ``` The `InsuranceAgentDetailsBatchable` packaged component of type `ApexClass` was interacted with as a result of a user action from subscriber org `MyCustomer Inc.` Specifically, an execution of a batch Apex job occurred on 2022-11-22 at 6:19 am. The batch Apex job is represented by Quiddity = A. The key data in this analysis are: | Question | Field | Value | | -------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | What | | | | Who | | | | How | | | | When | `timestamp_derived` | `2022-11-22T06:19:33.990Z` | **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) - [Apex Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dev_guide.htm) # API Access in Group and Professional Editions API access isn't normally supported in Group and Professional Edition orgs. However, after your app passes the security review, you’re eligible to use some APIs for building composite applications. - Currently, the standard Data SOAP and REST APIs are supported for Group and Professional Edition apps. Metadata API is supported in Professional Edition apps. To request API access, follow the instructions in [Request an API Token for Your Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-request-api-token.md). You can also contact Salesforce to allowlist a connected app to use REST API in Group and Professional Edition orgs. - Other APIs, such as the Bulk API 2.0 and Apex methods exposed as SOAP web services, remain unavailable. - You can enable REST-based web services by using connected app consumer allowlisting. - You can enable SOAP-based web services, including Metadata API, by using an API token called a client ID. Append the client ID to your SOAP headers in integration calls. With this special key, your app can make calls to Group and Professional Edition orgs for Data API and Professional Edition orgs for Metadata API, even if the customer doesn't have API access. The client ID has these properties. - You can't use the client ID with the AJAX Toolkit in custom JavaScript, S-controls, or anywhere in your app where its value is exposed to the end customer. - For development purposes, GE and PE orgs created via the Environment Hub already have Metadata API and SOAP API (Data API) enabled. You can then develop and test your app before the security review. After your app passes security review and you obtain an API token, test your app again to make sure that it’s working correctly. - The client ID grants Group and Professional Edition access to SOAP API, and Professional Edition access to Metadata API. With Metadata API, you can dynamically create various components that you typically create in Setup. For instance, you can create a custom field dynamically in a Professional Edition org with the API token. This table shows which APIs are accessible when using Group Edition (GE) and Professional Edition (PE) with specific methods of access. |API|Access to GE and PE| |---|-------------------| |Web Services (SOAP)|Yes, with token| |Apex methods exposed as web services (SOAP)|No| |Web services (REST)|Yes, with connected app consumer allowlisting| |Apex methods exposed as web services (REST)|Yes, with connected app consumer allowlisting| |Connect REST API|Yes| |Metadata API|Yes, with token| |Bulk API 2.0|No| |Data Loader tool (uses SOAP web services)|No, can’t set the token| # API and Dynamic Apex Access in Packages Apex Package components have access via dynamic Apex and the API to standard and custom objects in the organization where they’re installed. API Access is a package setting that controls the dynamic Apex and API access that package components have to standard and custom objects. The setting displays for both the developer and installer on the package detail page. With this setting: - The developer of an AgentExchange package can restrict API access for a package before uploading it to AgentExchange. After it’s restricted, the package components receive Apex and API sessions that are restricted to the custom objects in the package. The developer can also enable access to specific standard objects, and any custom objects in other packages that this package depends on. - The installer of a package can accept or reject package access privileges when installing the package to their organization. - After installation, an administrator can change Apex and API access for a package at any time. The installer can also enable access on additional objects such as custom objects created in the installer's organization or objects installed by unrelated packages. There are two possible options for the API Access setting: - The default Unrestricted, which gives the package components the same API access to standard objects as the user who is logged in when the component sends a request to the API. Apex runs in system mode. Unrestricted access gives Apex read access to all standard and custom objects. - Restricted, which allows the administrator to select which standard objects the components in the package can access. Further, the components in restricted packages can only access custom objects in the current package if the user has the object permissions that provide access to them. ## Considerations for API and Dynamic Apex Access in Packages By default, dynamic Apex can only access the components with which the code is packaged. To provide access to standard objects not included in the package, the developer must set the API Access. 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. Select the package that contains a dynamic Apex that needs access to standard objects in the installing organization. 3. In the Package Detail related list, click **Enable Restrictions** or Restricted, whichever is available. 4. Set the access level (Read, Create, Edit, Delete) for the standard objects that the dynamic Apex can access. 5. Click **Save**. Choosing Restricted for the API Access setting in a package affects the following: - API access in a package overrides the following user permissions: - Author Apex - Customize Application - Edit HTML Templates - Edit Read Only Fields - Manage Billing - Manage Call Centers - Manage Categories - Manage Custom Report Types - Manage Dashboards - Manage Letterheads - Manage Package Licenses - Manage Public Documents - Manage Public List Views - Manage Public Reports - Manage Public Templates - Manage Users - Transfer Record - Use Team Reassignment Wizards - View Setup and Configuration - Weekly Export Data - If Read, Create, Edit, and Delete access aren’t selected in the API access setting for objects, users don’t have access to those objects from the package components, even if the user has the Modify All Data and View All Data permissions. - A package with Restricted API access can’t create users. - Salesforce denies access to Web service and `executeanonymous` requests from an AgentExchange package that has Restricted access. The following considerations also apply to API access in packages: - Workflow rules and Apex triggers fire regardless of API access in a package. - If a component is in more than one package in an organization, API access is unrestricted for that component in all packages in the organization regardless of the access setting. - If Salesforce introduces a new standard object after you select restricted access for a package, access to the new standard object isn’t granted by default. You must modify the restricted access setting to include the new standard object. - When you upgrade a package, changes to the API access are ignored even if the developer specified them, which ensures that the administrator installing the upgrade has full control. Installers must carefully examine the changes in package access in each upgrade during installation and note all acceptable changes. Then, because those changes are ignored, the administrator must manually apply any acceptable changes after installing an upgrade. - S-controls are served by Salesforce and rendered inline in Salesforce. Because of this tight integration, there are several means by which an s-control in an installed package could escalate its privileges to the user’s full privileges. In order to protect the security of organizations that install packages, s-controls have the following limitations: - For packages you’re developing (that is, not installed from AgentExchange), you can only add s-controls to packages with the default Unrestricted API access. After a package has an s-control, you can’t enable Restricted API access. - For packages you’ve installed, you can enable access restrictions even if the package contains s-controls. However, access restrictions provide only limited protection for s-controls. Salesforce recommends that you understand the JavaScript in an s-control before relying on access restriction for s-control security. - If an installed package has Restricted API access, upgrades are successful only if the upgraded version doesn’t contain any s-controls. If s-controls are present in the upgraded version, you must change the currently installed package to Unrestricted API access. - **[Manage API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/editing-client-security-profile.md)** API Access is a package setting that controls the dynamic Apex and API access that package components have to standard and custom objects. The setting displays for both the developer and installer on the package detail page. - **[Configure Default Package Versions for API Calls](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/dev-api-package-version-settings.md)** You can specify the default package versions for enterprise API and partner API calls. - **[About the Partner WSDL](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-partner-wsdl.md)** The Partner Web Services WSDL is used for client applications that are metadata-driven and dynamic in nature. It’s particularly—but not exclusively—useful to Salesforce partners who are building client applications for multiple organizations. - **[Generate an Enterprise WSDL with Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/dev-wsdl-enterprise-version.md)** If you’re downloading an enterprise WSDL and you have first-generation managed packages installed in your org, you must take an extra step to select the version of each installed package to include in the generated WSDL. - **[Work with Services Outside of Salesforce](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-external-services.md)** # App Analytics Recipes To understand how your customers are using your managed packages and components, create App Analytics recipes. Each App Analytics recipe produces a CRM Analytics lens and is a key performance indicator (KPI). Use CRM Analytics dashboards to visualize your KPIs and gain deeper insights. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [ISV Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). To request and retrieve package usage logs and subscriber snapshots, activate App Analytics on your security-reviewed managed package by logging a support case in the [Salesforce Partner Community](https://partners.salesforce.com/). For product, specify **Partner Programs & Benefits**. For topic, specify **ISV Technology Request**. You can access package usage summaries without activation. For example, to analyze a wide range of daily and monthly package usage metrics, build Daily and Monthly Active User App Analytics recipes. ## Example ![An example CRM Analytics dashboard with Daily Active Users and Monthly Active Users App Analytics recipes](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_daumau_dashboard.png) - **[Customer Success Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-csm-intro.md)** Customer success is a relationship-focused method of ensuring that your customers achieve their desired outcomes while using your managed packages. - **[Custom Object Usage Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-cou-intro.md)** Understanding how your customers use your custom objects is critical to managing the lifecycle of your managed package and its custom objects. Start by measuring custom object usage by create, read, update, and delete (CRUD) operations. **See Also** **Previous topic:** [CRM Analytics Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-intro.md) # App Analytics Use Cases To achieve your business objectives, use App Analytics across your teams. Read this guide to understand common use cases and how to map App Analytics data to sample product features. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | ## App Analytics Use Cases While there are various use cases for App Analytics, these cases tend to be the most common.
Partner User Goal How App Analytics Helps
Presales Engineer or Account Executive Provide a great customer trial experience and close deals

App Analytics provides detailed package usage logs for sandboxes and trial orgs.

  • Use log data to know how many users are trialing your package and which features they’re actively testing.

  • Analyze log data to provide customized recommendations to your prospective subscribers.

  • Help prospective subscribers try more features or further configure the trial experience to demonstrate how your solutions can address their use cases.

Customer Success Representative Drive feature adoption and minimize subscriber attrition

App Analytics provides package usage logs, package usage summaries, and subscriber snapshots in production for subscribers.

  • Use comprehensive usage data from all three data types to know how and when the various users for a subscriber are employing your solutions.

  • Provide tailored recommendations to drive feature adoption, identify upsell opportunities, and forecast attrition risk.

  • Track a user’s activity across multiple packages to help you determine where opportunities and risks lie within a particular package.

  • Combine your App Analytics data with license usage data from the License Management App to get a better picture of how your subscriber is adopting your product.

Product Manager Obtain product insights and drive roadmap prioritization

App Analytics provides you with usage data from your entire subscriber base so that you can carry out high-level and detailed user-level analysis.

As a product manager, you can analyze usage data to:

  • Identify your most-used features.

  • Identify incomplete user journeys.

  • Identify user pain points.

  • Identify unexpected usage patterns or validate expected behavior.

  • Retire rarely used or end-of-life features.

These insights help you design and build product improvements and fixes. Then you can prioritize and adjust your product roadmap accordingly.

Software Engineer Optimize code

App Analytics provides usage data on Apex. Use your data on its own or combine it with more data to optimize your code, making it more performant and reliable.

Consider using your Apex data in combination with these products.

  • Use the Subscriber Support Console to troubleshoot subscriber issues and access logs as code is executed in real time.

  • Use the Salesforce Code Analyzer to identify and fix problems in your code while you develop.

There are other use cases where App Analytics isn’t a good fit. For example, we don’t recommend that you use App Analytics to audit customer license usage based on the `user_id_token` in package usage logs. We provide usage data for users licensed to use your package, for users who indirectly interact with it, and for automated processes. ## Mapping App Analytics Data to Product Features For the most common App Analytics use cases, analyze App Analytics usage data at a feature level. Feature-level analysis supports conversations about those features that you have with subscribers and with your teams. App Analytics data is organized around the concept of a `custom_entity`, which is the developer name of the components that are included in your managed package. `custom_entity` information is included in package usage summaries, package usage logs, and subscriber snapshots. ## Example Imagine that you want to understand how subscribers are using a new feature in your solution that enables them to easily manage newsletter subscriptions from Salesforce. To build this feature, your developers add these components to your managed package. - A new custom object, `Newsletter_Subscription` - A new Lightning Page, `SubscriptionPage` - A new Lightning Component, `SubscriptionComponent` - A new Apex Class, `SubscriptionHandler` As subscribers interact with your components, interaction data flows through in App Analytics. | Component | Package Usage Log (Daily) | Package Usage Summary (Monthly) | Subscriber Snapshot (Daily) | | ------------------------- | ------------------------------------------- | -------------------------------- | --------------------------- | | `Newsletter_Subscription` | Create Read Update and Delete (CRUD) events | CRUD events | Record Counts | | `SubscriptionPage` | Lightning interactions | Lightning interactions | — | | `SubscriptionComponent` | Lightning component interactions | Lightning component interactions | — | | `SubscriptionHandler` | Apex executions | Apex executions | — | The volume of total App Analytics data from your feature’s data mixed with data for your entire solution across all subscribers can be vast. To make it easier for you to analyze, employ one of these strategies. - Select a single component that best represents usage for this feature, and look solely at the data where it appears under `custom_entity`. In this example, the custom object `Newsletter_Subscription` is a good candidate because it tracks CRUD events from all sources, not only from the other components. - Select a combination of components for a user journey that you care about. Using our example, select an interaction for `SubscriptionPage`, followed by `SubscriptionComponent`, `SubscriptionHandler`and CRUD for `Newsletter_Subscription`. Package usage logs and subscriber snapshots are updated daily so that you can track subscriber usage more closely and more frequently. Package usage summaries are updated monthly. To understand how we gather and make this data available to you, read [How Does AgentExchange App Analytics Data Flow?](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/app_analytics_data_flow.htm) **See Also** - [How to Read App Analytics Package Usage Log Data](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs/app-analytics-read-logs-intro.md) - [Customer Success Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook/app-analytics-cookbook-recipe-csm-intro.md) - [Troubleshoot Subscriber Issues](https://developer.salesforce.com/docs/lma/lma-subscriber-support-overview.md) # App Rollout Before you deploy the solution to your users, notify them of the new functionality, and educate them on how to use it. Then make it available to the users who have appropriate permissions. - Review the Splash Page - : The developer of a solution can include a splash page that users see when they click a custom tab. Splash pages explain how the custom object fits in a Salesforce environment and can contain training or support links. Instruct users to review the splash pages for each custom tab. Show them how to use the **Don’t show me this again** link. If the publisher didn’t provide splash pages, create your own. - Preview the Solution for Select Users - : Preview the solution with key users in your Salesforce org. Make any suggested changes from the feedback that you receive. - Announce the New App - : Send an announcement to your users one week before deploying the solution. Let them know when the rollout is and how it benefits them. On the day of the deployment, send another announcement telling users to look for the new solution. # Application Installation Guide Previous PDF Versions | API Version | Release | PDF | | ----------- | ---------- | --- | | 67.0 | Summer '26 | [Download PDF](https://resources.docs.salesforce.com/262/latest/en-us/sfdc/pdf/appexchange_install_guide.pdf) | | 66.0 | Spring '26 | [Download PDF](https://resources.docs.salesforce.com/260/latest/en-us/sfdc/pdf/appexchange_install_guide.pdf) | | 65.0 | Winter '26 | [Download PDF](https://resources.docs.salesforce.com/258/latest/en-us/sfdc/pdf/appexchange_install_guide.pdf) | | 64.0 | Summer '25 | [Download PDF](https://resources.docs.salesforce.com/256/latest/en-us/sfdc/pdf/appexchange_install_guide.pdf) | # Architectural Considerations for Group and Professional Editions Discover the architectural concepts that influence AgentExchange solution design. Salesforce Platform is offered in five tiers, or editions. - Group Edition (GE)* - Professional Edition (PE) - Enterprise Edition (EE) - Unlimited Edition (UE) - Performance Edition (PXE)* **note:** Group and Performance Editions are no longer sold. For a comparison chart of editions and their features, see the [Salesforce Pricing and Editions page](http://www.salesforce.com/crm/editions-pricing.jsp). If you plan to sell your solution to existing Salesforce customers, it’s important to understand the differences between these editions because they will affect the design of your solution. It’s convenient to think about them in clusters, GE/PE and EE/UE/PXE, as the editions in each cluster have similar functionality. For example, you might only want to support EE/UE/PXE if your solution requires certain objects and features that aren't available in GE/PE. Also, instead of a single solution that supports all editions, you can have a tiered offering. This would consist of a basic solution for GE/PE and an advanced one for EE/UE/PXE customers that takes advantage of the additional features. EE/UE/PXE have the most robust functionality. They support Salesforce Platform platform licenses in addition to Salesforce CRM licenses. If your solution doesn’t require Salesforce CRM features, such as Leads, Opportunities, and Cases, Salesforce Platform platform licenses give you the most flexibility in deploying your solution to users who aren’t normally Salesforce users. Your solution is still subject to the edition limits and packaging rules. GE/PE don't contain all of the functionality that you can build in a Developer Edition (DE). Therefore, a solution developed in your DE organization might not install in a GE/PE organization. If you’re designing a solution to work specifically in GE/PE, you must be aware of how these editions differ. There are a number of other considerations to keep in mind when deciding whether to support these editions. Salesforce Platform platform licenses cannot be provisioned in GE/PE organizations. This means that only existing Salesforce CRM users can use your solution. There are some features that aren't available in GE/PE. There are several special permissions available to eligible partner solution that overcome these limitations. See the following sections for available features, limits, and other design considerations. - [Features in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-package-features-pe-ge.md) - [Limits for Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-package-limits-for-pe-ge.md) - [Access Control in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-ge-pe-access-control.md) - [Using Apex in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-apex-ge-pe.md) - [API Access in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-api-access.md) - [Designing Your App to Support Multiple Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-supporting-multiple-editions.md) - [Sample Design Scenarios](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-ge-pe-scenarios.md) # Are the orgs that I create in the Environment Hub the same as the ones I created in the Partner Portal? Yes, the orgs are identical to the ones that you created in the Partner Portal. The Environment Hub uses the same templates, so the orgs come with the same customizations, such as higher limits and more licenses. You can also use the Environment Hub to create the same Group, Professional, and Enterprise Edition orgs that customers use. That way, you can test your app against realistic customer implementations. # Assign Access to New and Changed Features in First- and Second-Generation Managed Packages Determine how to provide existing non-admin users access to new and changed features. By default, any new components included in the push upgrade package version are assigned only to admins. | If the push upgrade includes: | We recommend you: | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | New features | Notify admins about the changes the upgrade introduces, and ask them to assign permissions to all users of the package. This approach allows admins to choose when to make the new features available. | | Enhancements to existing features | Include a post-install script in the package that assigns permissions to the new components or new fields automatically. This approach ensures that current users of the package can continue using features without interruption. Post-install scripts aren’t available to unlocked packages. | # Assign Override Values in Your LMO To override the default value of a feature parameter in a subscriber’s org, update the appropriate junction object record in your LMO. 1. Open the license record for a subscriber’s installation of your package. 2. In the related list for Feature Parameter Booleans, Feature Parameter Integers, or Feature Parameter Dates, select the feature parameter whose value you want to update. 3. Click **Edit**. 4. Set a value. 5. Click **Save**. # Assign Permissions to the Subscriber Support Console Create a permission set to provide users access to the Subscriber Support Console. ## Before You Begin **note:** If you’ve already assigned these permissions via a profile or another permission set, you can skip this task. 1. From Setup, in the Quick Find box, enter `Permission Sets`, and select **Permission Sets**. 2. Click **New** and enter your permission set information. 3. On the Permission Set Overview page, locate the Apps section, and select **Visualforce Page Access**. 1. Click **Edit**. 2. Add **sfLma.LoginToPartnerBT** and **sfLma.SubscriberSupport** to the list of Enabled Visualforce pages, and then click **Save**. 4. On the Permission Set Overview page, locate the System section, and select **System Permissions**. Click **Edit**. 1. Select **Log in to Subscriber Organization**, and click **Save**. 5. From Setup, in the Quick Find box, enter `Profiles`, and select **Profiles**. 1. Click **Edit**. 2. Under Custom App Settings, select **License Management App**. 3. Under Custom Tab Settings, locate the Subscribers tab and select **Default On**. 4. Click **Save**. # Assign Second-Generation Managed Packaging User Permissions To create second-generation managed packages and scratch orgs, developers require access to the Dev Hub org. We recommend enabling the Dev Hub in your Partner Business Org (PBO). A Salesforce admin can create a permission set to grant appropriate permissions to the required Dev Hub objects and system permission. To give developers access to the Dev Hub org, create a permission set that contains these required permissions: - Object Settings \> Scratch Org Info \> Read, Create, and Delete - Object Settings \> Active Scratch Org \> Read and Delete - Object Settings \> Namespace Registry \> Read (to use a linked namespace in a scratch org) To provide users with the ability to create second-generation managed packages and package versions, the permission set must also contain: - System Permissions \> Create and Update Second-Generation Packages This permission provides access to: | Salesforce CLI Command | Tooling API Object (Create and Edit) | | --------------------------- | ------------------------------------ | | `sf package create` | Package2 | | `sf package version create` | Package2VersionCreateRequest | | `sf package version update` | Package2Version | If you choose to test your package in a scratch org, the Create and Update Second-Generation Packages permission is also required when creating the scratch org if you specified an ancestor version in the `sfdx-project.json` file. Alternatively, use the --noancestors flag with the sf org create command when you create the scratch org. # Associate a Package with the License Management App To receive lead and license records for your package, you connect your License Management Org (LMO), your package, and the Salesforce Partner Console. Your LMO is the Salesforce org where the License Management App (LMA) is installed. ## Before You Begin | User Permissions Needed | | | -------------------------------------------- | --------------- | | To manage licenses in the Partner Community: | Manage Listings | A single LMO can manage multiple 1GP and 2GP packages, but a package can be associated with only one LMO. 1. Connect your packaging org (for 1GP) or your Dev Hub org (for 2GP) to the Partner Console. 1. Log in to the [Partner Community](https://partners.salesforce.com/), and select the **Publishing** tab. 2. Click **Technologies** | **Orgs**. 3. Click **Connect Technology**, and then click **Org**. 4. Click **Connect Org**. 5. Log in to the org. Provide a username and a password with a security token appended. For example, if the password is ABC and the token is 123, enter ABC123. Don’t remember your token? [Reset your security token](https://help.salesforce.com/articleView?id=user_security_token.htm&type=5). For 1GP packages, enter the login credentials for the packaging org. Repeat this step for all your 1GP packages. For 2GP packages, enter the login credentials for the Dev Hub org. When you connect the Dev Hub org, all the 2GP packages owned by the Dev Hub org are linked to the Partner Console. 2. Select the **Solutions** tab. 3. Locate the package you want to register with the LMO. To register each package you own, repeat this step. 1. Click the down arrow to expand the list of versions for your package. 2. Click **Register Package** for the package version you want to register. Package versions created after linking to your LMO inherit the association. 3. To register the package, log in to your LMO. 4. Set the default behavior you want for your package license, and then click **Save**. ## Next Steps After the package is registered, a license is created when customers install it. You can view which packages are registered in the LMA. **note:** Beta package versions don’t display in the LMA. Only managed-released package versions (1GP) and promoted package versions (2GP) are visible in the LMA. Unlocked packages aren’t supported. **See Also** - [_Salesforce Help:_ Reset Your Security Token](https://help.salesforce.com/articleView?id=user_security_token.htm&type=5) # Avoid Namespace Collisions in Second-Generation Managed Packages Namespaces impact the combination of package types that you can install in an org. **important:** When sharing a namespace, be intentional about managing component names across packages within that namespace. Ensure that packages associated with the same namespace don’t include components with the same API name. If two packages include a component with the same API name, you can’t install these packages into the same org. To understand how namespaces affect the types of packages you can install in a namespaced or no-namespace org, review this table. | Installation Org | No-namespace Unlocked Package | Namespaced Unlocked Package | Second-generation Managed Package (2GP) | First-generation Managed Package (1GP) | | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Org with a namespace.** For example, a 1GP packaging org, 1GP patch org, Developer Edition org with namespace, or a scratch org with namespace | Fail. You can’t install a no-namespace unlocked package in an org with a namespace. | Pass. Regardless of whether the namespace matches or is different from the org’s namespace, you can install one or many namespaced unlocked packages. | Pass (scratch orgs). Regardless of whether the namespace matches or is different from the scratch org’s namespace, you can install one or many 2GP packages. Fail (1GP packaging and patch orgs). To prevent 1GP packages from depending on 2GP packages, we block the installation of 2GP packages in a 1GP packaging or patch org. We also block the installation of 2GP packages in Developer Edition (DE) orgs that have an associated namespace, unless it’s a DE scratch org. | Pass. If the namespace of the 1GP is different from the namespace of the org, you can install one or many packages. Fail. If the namespace of the 1GP is the same as the namespace of the org, you can’t install the 1GP into the org. | | **Org without a namespace** | Pass. You can install one or many no-namespace unlocked packages. | Pass. You can install one or many namespaced unlocked packages. | Pass. You can install one or many 2GP packages. | Pass. You can install one or many 1GP packages. | To understand how namespaces affect the combination of packages that can be installed into one org, review this table. | Namespace and Package Type | Unlocked Package with Namespace Y | Second-generation Managed Package (2GP) with Namespace Y | First-generation Managed Package (1GP) with Namespace Y | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | | **First-generation Managed Package (1GP) with namespace X** | Pass. If the 1GP and unlocked package use unique namespaces, you can install them in the same org. | Pass. If the 1GP and 2GP use unique namespaces, you can install them in the same org. | Pass. If each 1GP uses a unique namespace, you can install multiple 1GP packages in the same org. | | **First-generation Managed Package (1GP) with namespace Y** | Fail. If the 1GP and unlocked package share a namespace, you can’t install them in the same org. | Fail. If the 1GP and 2GP share a namespace, you can’t install them in the same org. | Fail. If the 1GP packages share a namespace, you can’t install them in the same org. | | **Second-generation Managed Package (2GP) with namespace X** | Pass. You can install a 2GP and a namespaced unlocked package in the same org. The packages can share a namespace or use unique namespaces. | Pass. You can install multiple 2GP packages with unique namespaces, or the same namespace. | Pass. If the 1GP and 2GP use unique namespaces, you can install them in the same org. | | **Second-generation Managed Package (2GP) with namespace Y** | Pass. You can install a 2GP and a namespaced unlocked package in the same org. The packages can share a namespace or use unique namespaces. | Pass. You can install multiple 2GP packages with the same namespace in the same org. | Fail. If the 1GP and 2GP share a namespace, you can’t install them in the same org. | **See Also** - [Namespaces for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_plan_namespaces.htm) - [Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) - [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm) # Before You Begin Complete these prerequisites before you create App Analytics recipes. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | User Permissions Needed | | | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | To access License Management App data, packages, and package versions: | Read on Licenses, Packages, Package Versions | | To request and retrieve AgentExchange App Analytics data: | Create, Read, Edit, Delete, View All, and Modify All on the `AppAnalyticsQueryRequest` object | | To use CRM Analytics: | CRM Analytics Plus Admin user | To brush up on your AgentExchange App Analytics or CRM Analytics skills, we recommend completing these Trailhead modules. - [AgentExchange Partner Intelligence Basics](https://trailhead.salesforce.com/en/content/learn/modules/appexchange-partner-intelligence-basics) - [CRM Analytics Data Integration Basics](https://trailhead.salesforce.com/en/content/learn/modules/wave_enable_data_integration_basics) 1. Set up your [License Management Org](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/package_associate_lmo.htm) (LMO). Use your LMO to track all Salesforce users who install your managed package. The LMO receives a notification in the form of a lead record when a user installs or uninstalls your package. It also tracks each package upload on AgentExchange. Typically, as an AgentExchange partner, you use your [Partner Business Org](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/isv1_3_quickstart.htm) (PBO) as your LMO. 2. Register your security-reviewed managed package with your LMO. Follow the directions in [Link a Package with Your License Management Organization](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/package_associate_lmo.htm). 3. If you’re not using your PBO as your LMO, install the License Management App (LMA) in your LMO. The LMA lets you manage leads and licenses for your AgentExchange offerings. To install the LMA, read [Get Started with the License Management App](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/lma_setup.htm?search_text=license%20management%20app). **note:** If you’re using your PBO as your LMO, you’re all set. The LMA is automatically installed for you. 4. Create an App Analytics Admin permission set that includes create and read access on the AppAnalyticsQueryRequest object. Assign this permission to any non-Admin users so that they can create App Analytics requests. Read [Create Permission Sets](https://help.salesforce.com/articleView?id=platform.perm_sets_create.htm&type=5) in Salesforce Help if you need instructions. 5. Set up the CLI using the [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm). If you need a CLI refresher, take the [App Development with Salesforce DX](https://trailhead.salesforce.com/en/content/learn/modules/sfdx_app_dev) Trailhead module. 6. [Enable CRM Analytics](https://help.salesforce.com/articleView?id=000335760&type=1&mode=1) in your Salesforce org. 7. Create a CRM Analytics app named PartnerIntelligence. 8. To request and retrieve a sample package usage log, create an AgentExchange App Analytics query request using the CLI. Save the CSV data file as `RawPackageLogFile.csv`. 9. To request and retrieve package usage logs automatically, create an automation. Which automation method you choose depends on your business specifications and which data volume you’re automating. - For smaller datasets, such as package usage summaries, Apex scales well for automation. This [GitHub repo](https://github.com/developerforce/partner-intelligence-basics) has the details. - For larger datasets, such as package usage logs, automate using an [Amazon Web Services (AWS) stack](https://medium.com/@kamipatel/automate-appanalytics-aws-stack-74cbebc49d2a). - You can also use the free Salesforce Labs app, [App Analytics](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000G0nUXUAZ). It offers great functionality to retrieve and automate data collection and to get started with recipes and dashboards. Salesforce Labs apps are developed by Salesforce employees and are unsupported. - **[Get Help with Prerequisites](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-prework-help.md)** If you need help with setting up your solution, you can request a consultation with a Platform Expert. **See Also** **Previous topic:** [What Are Recipes?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-what-are-recipes.md) **Next topic:** [CRM Analytics Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-intro.md) # Before You Begin Package Migrations If you’ve never created or worked with managed 2GP packages, scratch orgs, or Salesforce CLI, take some time to learn more about Salesforce DX and second-generation managed packages. Review [Know Your Orgs for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_before_know_orgs.htm), [How Scratch Orgs Fit in the Package Development Workflow](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_so_how_fit_pkg_dev.htm), and [Before You Create Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_before.htm) and ensure you have enabled: - Dev Hub in your Partner Business Org - Second-Generation Managed Packaging in your Dev Hub The [Second-Generation Managed Packages](https://trailhead.salesforce.com/content/learn/modules/second-generation-managed-packages) Trailhead module is a great resource to learn more about 2GP. ## Prerequisites for Package Conversion Before starting package conversion, review the requirements regarding metadata support, API version, and managed-released versions. Ensure your package meets these criteria. **Metadata Support** If your 1GP package contains metadata that isn’t currently supported in 2GP packages, the package conversion fails. You can compare the metadata in your package against the [Metadata Coverage Report](https://developer.salesforce.com/docs/metadata-coverage) and ensure the metadata in your 1GP managed package is also supported in 2GP. Alternatively, you can identify metadata issues by running the CLI `package convert` command. The `package convert` CLI command detects and reports back to you any 1GP metadata types that prevent the package from being converted to 2GP. Using the `package convert` CLI command in this way lets you quickly assess whether you have any packaged metadata that isn’t supported in 2GP. During package conversion, your original managed 1GP package isn’t altered. It’s safe to test out the conversion command, before you are ready to migrate your packages to 2GP. If your package contains metadata that isn’t supported in managed 2GP, either remove the metadata from your package, or wait to convert the package until managed 2GP supports that metadata type. **API Version:** You can convert first-generation managed packages created using API version 57 (Spring ’23) or higher. **Managed-Released Package Versions:** You can convert managed-released package versions only. **User Permissions** Package conversion and migration require the second-generation managed packaging user permissions. See [Assign Second-Generation Managed Packaging User Permissions](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_user_permission.htm) for details. # Before You Create Second-Generation Managed Packages When you use second-generation managed packaging, to be sure that you set it up correctly, verify the following. Did you? - [Enable Dev Hub and Second-Generation Managed Packaging](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_enable_devhub.htm) in your Partner Business Org (PBO) - Install [Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm) - [Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) Developers who work with managed 2GP packages need a user license and permission set that provides access to the Dev Hub org. See [Limited Access License for Package Developers](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_slalf_pkg_dev.htm) and [Assign Second-Generation Managed Packaging User Permissions](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_user_permission.htm). - **[Know Your Orgs for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-before-know-orgs.md)** Some of the orgs that you use with second-generation managed packaging (managed 2GP) have a unique purpose. - **[Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/platform/pkg2-dev/sfdx-dev/workspace-setup/sfdx-dev-reg-namespace.md)** To use a namespace with a scratch org, you must link the Developer Edition org where the namespace is registered to a Dev Hub org. - **[Namespaces for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-namespaces.md)** A namespace is a 1–15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer’s org. A namespace is assigned to a second-generation managed package (managed 2GP) at the time that it’s created, and can’t be changed. - **[Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-namespace.md)** With second-generation managed packaging (managed 2GP), you can share a single namespace with multiple packages. Since sharing of code is much easier if your package shares the same namespace, we recommend that you use a single namespace for all of your managed 2GP packages. - **[Key Concepts in Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-key-concepts.md)** Let’s look at some key high-level concepts in second-generation managed packaging (managed 2GP). - **[How Manageability Rules and Ancestry Impact Upgrades for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-rules-ancestry-upgrades.md)** Before you dive in and create your first second-generation managed package (managed 2GP), it’s important to understand these concepts, and how they affect each other. - **[Which Package Types Can Your Package Depend On?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-dependency-overview.md)** Both second-generation managed packaging (managed 2GP) and unlocked packaging let you easily develop small interdependent packages and share logic between them. If you design your app to rely on small modular packages, both package creation and package installation are faster, and you’re less likely to hit limits. # Behavior of Specific Metadata in First-Generation Managed Packages Learn how profiles and other metadata are handled for first-generation managed packages. - **[Get Access to Agentforce in Your 1GP Packaging Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging1-agentforce-access.md)** Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. - **[Components Automatically Added to First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-components-auto-added.md)** When adding components to your first-generation managed package, related components are automatically added. For example, if you add a Visualforce page to a package that references a custom controller, that Apex class is also added. - **[Protected Components in Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-protected-components.md)** 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](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/data-platform-cache-setup-provider-capacity.md)** 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. - **[Package Dependencies in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/about-dependencies.md)** Package dependencies are created when a component references another component, permission, or preference that is required for the component to be valid. - **[Metadata Access in Apex Code](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-metadata-in-apex.md)** Use the `Metadata` namespace in Apex to access metadata in your package. - **[Permission Sets and Profile Settings in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/distribution-perm-sets-profile-settings.md)** 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. - **[Permission Set Groups](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-permission-set-groups.md)** You can organize permission sets into groups and include them in first and second-generation managed packages. Permission set groups can be updated when you upgrade the package. - **[Custom Profile Settings](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-creating-custom-profile.md)** Create profiles to define how users access objects and data, and what they can do within your app. For example, profiles specify custom object permissions and the tab visibility for your app. When installing or upgrading your app, admins can associate your custom profiles with existing non-standard profiles. Permissions in your custom profile that are related to new components created as part of the install or upgrade are added to the existing profile. The security settings associated with standard objects and existing custom objects in an installer’s organization are unaffected. - **[Protecting Your Intellectual Property](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-protect-ip.md)** 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](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-instanceless-url.md)** 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. - **[Develop App Documentation](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/develop-documentation.md)** To help your subscribers make the most of your app, provide documentation about how to configure and customize your app. - **[API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/about-client-security-profile.md)** Apex Package components have access via dynamic Apex and the API to standard and custom objects in the organization where they’re installed. - **[Connected Apps](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/connected-apps.md)** A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions. For example, when you log in to your Salesforce mobile app and see your data from your Salesforce org, you’re using a connected app. # Behavior of Specific Metadata in Second-Generation Managed Packages Learn how profiles and namespace visibility are handled for second-generation managed packages. - **[Package Agentforce Metadata Components](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-packageable-agentforce-md.md)** Bring the power of conversational AI to your apps with Agentforce. - **[Develop and Package Agent Templates Using Scratch Orgs](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-package-agent-templates.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-package-mcp-agentforce.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-package-data-cloud.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-package-custom-flow-connector.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/pd-packaging-protected-components.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/packaging-metadata-in-apex.md)** Use the `Metadata` namespace in Apex to access metadata in your package. - **[Permission Sets and Profile Settings in Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/pd-distribution-perm-sets-profile-settings.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/packaging-protect-ip.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/packaging-instanceless-url.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-namespace-visibility.md)** 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](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/packaging-external-services.md)** - **[Package Connected Apps in Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-connected-app.md)** Add a connected app to a second-generation managed package. - **[Test and Respond to the New Order Save Behavior](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-order-save-behavior.md)** 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. # Best Practices for Feature Management Here are some best practices when working with feature parameters. - We recommend that you use this feature set in a test package and a test LMO before using it with your production package. Apply changes to your production package only after fully understanding the product’s behavior. - Create LMO-to-subscriber feature parameters to enable features from your LMO for individual subscriber orgs. Don’t use the Apex code in your managed package to modify LMO-to-subscriber feature parameters’ values in subscriber orgs. You can’t send the modified values back to your LMO, and your records will be out of sync. Use LMO-to-subscriber feature parameters as read-only fields to manage app behavior. For example, use LMO-to-subscriber feature parameters to track the maximum number of permitted e-signatures or to make enhanced reporting available. - Create subscriber-to-LMO feature parameters to manage activation metrics. Set these feature parameters’ values in subscriber orgs using the Apex code in your managed package. For example, use subscriber-to-LMO feature parameters to track the number of e-signatures consumed or to check whether a customer has activated enhanced reporting. # Best Practices for Second-Generation Managed Packages We suggest that you follow these best practices when working with second-generation managed packages. - We recommend that you work with only one Dev Hub, and enable Dev Hub in your partner business org. - The Dev Hub org against which you run the `sf package create` command becomes the owner of the package. If the Dev Hub org associated with a package expires or is deleted, its packages no longer work. - Include the `--tag` option when you use the `sf package version create` and `sf package version update` commands. This option helps you keep your version control system tags in sync with specific package versions. - Create user-friendly aliases for packaging IDs, and include those aliases in your Salesforce DX project file and when running CLI packaging commands. See: [Package IDs and Aliases for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-pkg-types-pkg-ids.md). - When adding components to your package, check the product documentation for that component to ensure that the product is generally available (GA). If you choose to package a non-GA component, it may have limitations and isn't guaranteed to GA. This scenario is particularly risky if the component can't be removed from a managed package. # Best Practices for the License Management App Follow these best practices when you use the License Management App (LMA). - To take advantage of entitlements that are unique to ISV partners, use your partner business org as your License Management Org. - Create a list view filter for leads created by installed packages. The filter helps your team separate subscriber-based leads from leads coming from other sources. - Use the API to find licensed users. The `isCurrentUserLicensed` method determines if a user has a license to a managed package. For more information, see the [Apex Reference Guide](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_userinfo.htm). - Treat the LMA custom objects as read-only. Use the Modify License page to edit licenses. Don’t attempt to directly or programmatically edit license records. - The LMA automatically creates package, package version, and license records. Customizations, such as adding required custom fields or creating workflow rules, triggers, or validation rules that require custom fields, can prevent the LMA from working properly. # Build and Release Your App with Managed Packages If you developed and tested your app, you’re well on your way to releasing it. Luckily, when it’s time to build and release an app as a managed package, you’ve got options. You can package an app you developed from scratch. If you’re experimenting, you can also build a sample app from Salesforce and emulate the release process. ## Before You Begin Working with a package is an iterative process. You typically retrieve, convert, and deploy source multiple times as you create scratch orgs, test, and update the package components. Chances are, you already have a namespace and package defined in your packaging org. If not, run this command to open the packaging org in your browser. ```nolang sf org open --target-org me@my.org --path lightning/setup/Package/home ``` In the Salesforce UI, you can define a namespace and a package. Each packaging org can have a single managed package and one namespace. **See Also** - [Retrieve Source from an Existing Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/Retrieve Source from an Existing Managed Packagehttps://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_retrieve_man_pack.htm) # Building Blocks of the Go-To-Market App We built the Go-To-Market (GTM) app around five primary objects. Together, they track each milestone within the lifecycle of the transaction. The objects are: products, offers, orders, invoices, and pay out. Now, we explore each object in-detail. If you want a more detailed view of all objects involved in the GTM app, see the [Go-To-Market App Data Model.](https://developer.salesforce.com/docs/platform/data-models/guide/agentexchange-go-to-market.html) ## GTM App Objects
ObjectWhat It IsHow It's Used
Products

Represent the thing that you’re selling, which can include licenses, apps, and services.

All offers and orders are built on top of one or more products, which you can create in the Partner Business org (PBO).

Products are associated with a Partner Product Catalog (PPC), which the partner account manager (PAM) creates.

After you create a product, you can map it to managed package licenses.
Offers

Represent what the customer reviews and accepts in their Salesforce org, including pricing and contract terms.

Each offer is created as a Partner Offer in the GTM app and references one or more products. An offer can be an initial offer or an add-on offer.

When a customer accepts an offer, Salesforce automatically creates an Order record and handles billing and provisioning on the partner’s behalf.
Orders

Represent the record that Salesforce creates when a customer accepts an offer.

The order mirrors the accepted offer, but is only viewable by the partner. Orders include finer details like finalized purchase amounts, with taxes and calculations applied.

Includes the finalized purchase details that Salesforce uses to trigger billing and provisioning.
InvoicesRepresents the invoice that Stripe generates after an offer is accepted and an order is created.The invoice is emailed to the customer and given the pending status. When the customer pays the invoice in Stripe, the status moves to Paid.
PayoutsRepresent the net revenue that partners receive from settled customer payments.

Stripe consolidates all settled customer payments into a single, daily partner payout, which Stripe deposits into the partner’s bank account.

Every payout shows the related invoices, with Salesforce fees deducted.

 # Calculate Your Expected Payout To calculate your expected payout, look at the relationships between your order items, your products, and the related product catalog. 1. Identify the order items and their subtotals: Find each order item on the order and get the line item total. Line item total is the result of quantity x product unit price per month x contract length. 2. Trace each item to its catalog (PPC): Every order item references a specific Partner Provision Product (PPP). Each PPP is mapped to a Partner Product Catalog (PPC) record in your PBO. Find and open the associated PPC records. 3. Locate the revenue share percentage per item: On the PPC record for each item, find the Revenue Share Percentage field. This field indicates the revenue share percentage Salesforce retains for that specific product. 4. Calculate the Salesforce revenue share per item: Multiply the individual order item's line item total by its specific revenue share percentage. 5. Sum the total Salesforce revenue share: Add together the calculated revenue share amounts for all the items in the order. 6. Calculate your expected payout: To find your expected payout, take your total order subtotal and subtract the total Salesforce revenue share calculated in the previous step. **note:** Sales tax on the Salesforce revenue share itself is also deducted from your final payout based on your local tax jurisdiction. This information is available in the **Partner Revenue Tax** field on the Invoice record. ## Payout Example Here is an example that shows how the expected payout is calculated for an order with a 12-month contract term, containing two different products. Scenario: - Contract Term: 12 months - Product 1: 10 user licenses for Core App at $50/month each. - Product 2: 1 license for Premium Add-On at $200/month. 1. Identify the order items and their subtotals. In this example, Product 1 has a single item, Core App (or Item 1), with a quantity of 10. Product 2 also has a single item, Premium Add-On, with a quantity of one. After identifying those items, we find the line item total for each item. - Item 1 (Core App): 10 × $50 × 12 months = $6,000 (Line Item Total) - Item 2 (Premium Add-On): 1 × $200 × 12 months = $2,400 (Line Item Total) - (Total Order Subtotal = $8,400) 2. Trace each item to its catalog (PPC). - Item 1 (Core App): references the Core App PPP, which maps to PPC A. - Item 2 (Premium Add-On): references the Premium Add-On PPP, which maps to PPC B. 3. Locate the revenue share percentage per item by looking at the PPC records. - PPC A (Core App) has a revenue share percentage of 15%. - PPC B (Premium Add-On) has a revenue share percentage of 10%. 4. Calculate the Salesforce revenue share per item by multiplying each line item total by its revenue share percentage. - Item 1 (Core App): $6,000 × 15% = $900 revenue share - Item 2 (Premium Add-On): $2,400 × 10% = $240 revenue share 5. Sum the total Salesforce revenue share by adding the calculated revenue share amounts for all items. $900 + $240 = $1,140 total Salesforce revenue share 6. Calculate Your Expected Payout by subtracting the total Salesforce revenue share from your total order subtotal. $8,400 (Total Order Subtotal) - $1,140 (Total Salesforce Revenue Share) = $7,260 Expected Payout **note:** - A sales tax on the Salesforce revenue share itself will also be deducted from your final payout based on your local tax jurisdiction. This information will be available in the “Partner Revenue Tax” field in the Invoice object after the invoice record is created. - If a floor price is set on your PPC, it acts as a minimum revenue share. If the calculated revenue share per unit per month falls below this amount, the floor price will be applied instead. # 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. The formats for My Domain URLs vary between production and sandbox orgs. With partitioned domains, hostname formats also vary for demo, Developer Edition, free, patch, and scratch orgs, plus Trailhead playgrounds. For example, there are currently two possible formats for sandbox My Domain login hostname formats and ten possible Visualforce hostname formats. For more information, see [My Domain URL Formats](https://help.salesforce.com/s/articleView?id=products.domain_name_app_url_changes.htm&type=5) and [Partitioned Domains](https://help.salesforce.com/s/articleView?id=products.domain_name_partitioned_domains.htm&type=5) in Salesforce Help. In general, use relative URLs whenever possible within your packages. If a full URL is required, use the [`System.DomainCreator`](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_DomainCreator.htm) Apex class to get the URL’s hostname. **note:** The `System.DomainCreator` Apex class is available in API version 54.0 and later. ## Use the My Domain Login URL for Logins All Salesforce orgs have a My Domain, an org-specific subdomain for the URLs that Salesforce hosts for that org. Customers have the option to prevent user and SOAP API logins from the generic `login.salesforce.com` and `test.salesforce.com` hostnames. When those options are enabled, logins require the My Domain login URL. To get the My Domain login URL format for an org, use the `getOrgMyDomainHostname()` method of the `System.DomainCreator` Apex class. ```apex //Get the My Domain login hostname String myDomainHostname = DomainCreator.getOrgMyDomainHostname(); ``` In this case, in a production org with a My Domain name of `mycompany`, `myDomainHostname` returns `mycompany.my.salesforce.com`. ## Use Relative URLs Whenever possible, we recommend that you use a relative URL, which only includes the path within your packages. For example, assume that you want to add a link on the Visualforce page with a URL of `https://_MyDomainName_--_PackageName_.vf.force.com/apex/myCases` to a Visualforce page with the URL, `https://_MyDomainName_--_PackageName_.vf.force.com/apex/newCase`. In this case, use the relative path when referencing the page: `/apex/newCase`. ## Generate Hostnames for Full URLs Sometimes a full URL is required. For example, when your package delivers a Visualforce page that includes content delivered by your package. If your package includes full URLs, use the `System.DomainCreator` Apex class to get the associated hostnames. Otherwise, users can experience issues with your package functionality. For example, to return the hostname for Visualforce pages, use the `getVisualforceHostname(packageName)` method of the `System.DomainCreator` Apex class. ```apex //Define the name of your package as a string String packageName = 'abcpackage'; //Get the Visualforce hostname String vfHostname = DomainCreator.getVisualforceHostname(packageName); //Build the URL for creating a new case System.URL vfNewCaseUrl = new URL('https', vfHostname, '/apex/newCase'); ``` In this example, in a production org with enhanced domains and a My Domain name of `mycompany`, `vfNewCaseUrl` returns `https://mycompany--abcpackage.vf.force.com/apex/newCase`. ## Get Part of a Domain If you find code in your package that parses a known URL or domain to get a value, we recommend that you update that code to use one of the newer Apex classes. Code that assumes a specific URL format can fail. If you need a hostname, assess whether you can use the `System.DomainCreator` class. If you need that value for another reason, use the Apex [`System.DomainParser`](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_DomainParser.htm) or [`System.Domain`](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_Domain.htm) class instead. In this example, we parse a known URL to get the domain type, the org’s My Domain name, and the package name. ```apex //Parse a known URL System.Domain domain = DomainParser.parse('https://mycompany--abcpackage.vf.force.com'); //Get the domain type System.DomainType domainType = domain.getDomainType(); // Returns VISUALFORCE_DOMAIN //Get the org’s My Domain name String myDomainName = domain.getMyDomainName(); // Returns mycompany //Get the package name String packageName = domain.getPackageName(); // Returns abcpackage ``` # Can an org be a member of multiple Environment Hubs? No, an org can be a member of only one Environment Hub at a time. To remove an org from an Environment Hub so you can associate it with a different one: 1. Go to the Environment Hub tab. 2. Find the org, from the drop-down select **Remove**. 3. Once removed, connect the org to the desired Environment Hub: 1. In the Environment Hub tab, click **Connect Org**. 2. Enter the admin username for the org. 3. Click **Connect Org**. 4. Enter the org’s password, then click **Allow** to allow the Environment Hub to access org information. # Can I disable the Environment Hub? After you install the Environment Hub in an org, you can’t disable it. However, you can hide the Environment Hub from users. Go to Setup and enter `App Menu` in to the Quick Find box, and then select **App Menu**. From the App Menu, you can choose whether to hide an app or make it visible. # Can I enable the Environment Hub in a sandbox org? No, you can’t enable the Environment Hub in a sandbox org. Enable the Environment Hub in a production org that all your users can access. # Can I install the Environment Hub in more than one org? Yes, but you must manage each Environment Hub independently. Although Salesforce recommends one Environment Hub per company, several hubs could make sense for your company. For example, if you want to keep orgs that are associated with product lines separate. # Can I use the Environment Hub in Lightning Experience? Yes, both Salesforce Classic and Lightning Experience support the Environment Hub. # Check LMO-to-Subscriber Values in Your Code You can reference feature parameters in your code, just like you’d reference any other custom object. Use these Apex methods with LMO-to-subscriber feature parameters to check values in your subscriber’s org. - `System.FeatureManagement.checkPackageBooleanValue('YourBooleanFeatureParameter');` - `System.FeatureManagement.checkPackageDateValue('YourDateFeatureParameter');` - `System.FeatureManagement.checkPackageIntegerValue('YourIntegerFeatureParameter');` **See Also** - [_Apex Reference Guide_: FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_System_FeatureManagement.htm) # Check LMO-to-Subscriber Values in Your Code You can reference feature parameters in your code, just like you’d reference any other custom object. Use these Apex methods with LMO-to-subscriber feature parameters to check values in your subscriber’s org. - `System.FeatureManagement.checkPackageBooleanValue('YourBooleanFeatureParameter');` - `System.FeatureManagement.checkPackageDateValue('YourDateFeatureParameter');` - `System.FeatureManagement.checkPackageIntegerValue('YourIntegerFeatureParameter');` # Code Coverage for Second-Generation Managed Packages Before you can release and distribute a second-generation managed package version on AgentExchange, the Apex code must meet a minimum 75% code coverage requirement. And every Apex Trigger in a package needs test coverage. To compute code coverage using Salesforce CLI, use the `--code-coverage` parameter when you run the `sf package version create` command. Package version creation often takes longer to complete when code coverage is being computed, so consider when to include the code coverage parameter. You can create beta package versions without computing code coverage, but these beta versions can’t be promoted. If you try to promote a beta package version to managed-released and the version was created without specifying code coverage, or the code coverage in the package version is less than 75%, the package promotion fails. Code coverage is calculated during package version validation. If you skip validation using the `--skip-validation` parameter, code coverage isn’t calculated for that package version. View code coverage information for a package version using `sf package version list` with the `--verbose` parameter, or `sf package version report` command in Salesforce CLI. # Collect AgentExchange Leads You can configure your AgentExchange listings to collect leads and deliver them to your Salesforce org. Specific customer interactions, such as watching your listing’s demo video, can trigger lead collection. **See Also** - [What’s the Difference Between Lead Events and Leads in AgentExchange Marketplace Analytics?](https://developer.salesforce.com/docs/platform/isvforce/guide/partner-dashboard-lead-events.md) - [Generate Leads from Your Website for Your Sales Teams](https://help.salesforce.com/articleView?id=setting_up_web-to-lead.htm) # Comparison of First- and Second-Generation Managed Packages If you’re familiar with first-generation managed packages (managed 1GP) and wonder how it’s different from second-generation managed packages (managed 2GP), here are some key distinctions. | Managed 1GP Packages | Managed 2GP Packages | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | The packaging org is the source of truth for the metadata in your package. | Your version control system is the source of truth (source-driven system) for the metadata in your package. And unlike managed 1GP, managed 2GP doesn’t use packaging or patch orgs. | | The packaging org owns the package. The metadata in the package resides in the packaging org. | The Dev Hub owns the package, but the Dev Hub doesn’t contain the packaged metadata. We recommend that you enable Dev Hub in your Partner Business Org (PBO). | | A packaging org can own only one managed package. | A Dev Hub can own one or more packages. | | The namespace of the managed package is created in the packaging org. | The namespace of a managed package is created in a namespace org and linked to the Dev Hub. And you can associate multiple namespaces to a single Dev Hub. A namespace is linked to a managed 2GP when you run the `sf package create` Salesforce CLI command. And you must specify the namespace in the `sfdx-project.json` file. See [Namespaces for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-namespaces.md) for more details. | | A namespace can be associated with only one package. | Multiple packages can use the same namespace. | | Global Apex is the only way to share code across packages. | Multiple packages using the same namespace can share code using public Apex classes and methods with the `@namespaceAccessible` annotation. | | Some packaging operations, like package create and package uninstall, can’t be automated. | All packaging operations can be automated using Salesforce CLI. | | Package versioning is linear. | Package versioning is flexible, and you can abandon unwanted package versions. This flexible versioning allows you to use branches and do parallel package development. | | Patch versions can only be created in specialized orgs called patch orgs. | Patch versions are created using Salesforce CLI. The version control system is the source of truth, and there are no patch orgs. | Despite these distinctions, managed 1GP and 2GP packages have many things in common. They share the key packaging concept of associating metadata with a package. And they both allow you to iterate and create package and patch versions, which can be installed and uninstalled in subscriber orgs. Both managed package types enable you to submit a package for AgentExchange security review, and list your package on AgentExchange. And both managed package types can use the License Management App, Subscriber Support Console, and Feature Management App. # Complete the Move to 2GP Package Development To fully transition to 2GP package development, you retrieve the source files for your package’s latest converted version. Then, you confirm in Setup for your packaging org that you’re ready to develop and distribute your package solely using 2GP packaging. ## Before You Begin **important:** Before you complete your move to 2GP package development, it’s critical that you thoroughly test package conversions and subscriber migrations first. See [Test Converted Packages and Subscriber Migrations](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-test-conversions-migrations.md). 1. To retrieve the source files for your package’s latest converted version, run the `sf package version retrieve` CLI command. This example retrieves the package metadata for a converted subscriber package version ID into `my-folder/` within a Salesforce DX project directory: ```nolang sf package version retrieve --package 04tXXX --output-dir my-folder –-target-dev-hub devhub@example.com ``` 2. Open the new `sfdx-project.json` file and update the versionName, versionNumber, and ancestorVersion. 3. From Setup in the packaging org, enter `Package Manager` in the Quick Find box, and then select **Package Manager**. 4. Click the package that you want to move to 2GP development. 5. On the package’s detail page, click **Move to 2GP**. ![The Move to 2GP button on a package's detail page](https://developer.salesforce.com/media/pkg1_dev/migration_move_to_2gp.png) 6. Carefully review and acknowledge the statements in the Move to Second-Generation Managed Packaging window, then click **Proceed**. ![The statements to acknowledge before you proceed with moving to 2GP.](https://developer.salesforce.com/media/pkg1_dev/migration_move_to_2gp_modal.png) ## Next Steps After you click **Proceed**, you can no longer create new major or minor versions in the packaging org. To innovate on the package using 2GP, you create new package versions using the `sf package version create` CLI command. You can continue to create 1GP patch versions for versions prior to moving to 2GP development. For example, if you moved package version 6.0.0 to 2GP development, you can create patch version 5.0.1 or 4.1.1 using 1GP, but you can’t create patch version 6.0.1 or later using 1GP. If a subscriber has installed the version that was moved to 2GP, the subscriber must be migrated to the 2GP version of the package. You create all future patch versions and fixes on 2GP. # Component Availability After Deployment Many components have an **Is Deployed** attribute that controls whether they’re available for end users. After installation, all components are immediately available if they were available in the developer's organization. Installed packages are available to users in your organization with the appropriate permissions and page layout settings. # Components Automatically Added to First-Generation Managed Packages When adding components to your first-generation managed package, related components are automatically added. For example, if you add a Visualforce page to a package that references a custom controller, that Apex class is also added. To understand what components are automatically included in first-generation managed packages, review the following list: | When you add this component | These components are automatically added | | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Action | Action target object (if it’s a custom object), action target field, action record type, predefined field values, action layout; and any custom fields that the action layout or predefined values refer to on the target object | | Apex class | Custom fields, custom objects, and other explicitly referenced Apex classes, and anything else that the Apex class references directly. If an Apex class references a custom label, and that label has translations, you must explicitly package the individual languages desired for those translations to be included. | | Apex trigger | Custom fields, custom objects, and any explicitly referenced Apex classes, and anything else that the Apex trigger references directly | | Article type | Custom fields, the default page layout | | Compact layout | Custom fields | | Custom app | Custom tabs (including web tabs), documents (stored as images on the tab), documents folder, asset files | | Custom button or link | Custom fields and custom objects | | Custom field | Custom objects | | Custom home page layouts | Custom home page components on the layout | | Custom settings | Apex sharing reasons, Apex sharing recalculations, Apex triggers, custom fields, list views, page layouts, record types, validation rules, or custom buttons or links. | | Custom object | Custom fields, validation rules, page layouts, list views, custom buttons, custom links, record types, Apex sharing reasons, Apex sharing recalculations, and Apex triggers. Apex sharing reasons are unavailable in extensions. When packaged and installed, only public list views from an app are installed. If a custom object has any custom list views that you want to include in your package, ensure that the list view is accessible by all users. | | Custom object (as an external object) | External data source, custom fields, page layouts, list views, custom buttons, and custom links. When packaged and installed, only public list views from an app are installed. If an external object has any custom list views that you want to include in your package, ensure that the list view is accessible by all users. In managed and unmanaged packages, external objects are included in the custom object component. | | Custom tab | Custom objects (including all of its components), s-controls, and Visualforce pages | | Dashboard | Folders, reports (including all of its components), s-controls, and Visualforce pages | | Document | Folder | | Email template (Classic) | Folder, Letterhead, Custom fields, and Documents (stored as images on the letterhead or template) | | Email template (Lightning) | Custom object, Custom field references (in Handlebars Merge Language syntax), Enhanced folder (except the default public and private folders), Inline images referencing Salesforce Files, and Attachments referencing Salesforce Files. For Lightning email templates created before Spring ’21, attachments aren’t automatically added to the package. Open and resave these templates to turn the attachments into content assets, which are then automatically added to the package. These items aren’t included and can’t be added to a package: Enhanced letterhead, the associated FlexiPage, or CMS files (Account Engagement only). | | Email template (Lightning) created in Email Template Builder | Custom object, Custom field references (in Handlebars Merge Language syntax), Enhanced folder (except the default public and private folders), Inline images referencing Salesforce Files, Attachments referencing Salesforce Files, and the associated FlexiPage. These items aren’t included and can’t be added to a package: Enhanced letterhead or CMS files (Account Engagement only). | | External Credential | Permission set and authentication provider. External credentials that use the Oauth 2.0 authentication protocol must reference an authentication provider to capture the details of the authorization endpoint. If you add an external credential that references an authentication provider, the authentication provider is added to the package. See [Authentication Providers](https://help.salesforce.com/s/articleView?id=experience.sso_authentication_providers.htm&type=5) for information on which elements of an authentication provider are and aren’t packageable. | | Field set | Any referenced fields | | Lightning page | All Lightning resources referenced by the page, such as record types, actions, custom components, events, and interfaces. Custom fields, custom objects, list views, page layouts, Visualforce pages, and Apex classes referenced by the components on the page. | | Lightning page tab | Lightning page | | Flow | Custom objects, custom fields, Apex classes, and Visualforce pages | | Folder | Everything in the folder | | Lightning application | All Lightning resources referenced by the application, such as components, events, and interfaces. Custom fields, custom objects, list views, page layouts, and Apex classes referenced by the application. | | Lightning component | All Lightning resources referenced by the component, such as nested components, events, and interfaces. Custom fields, custom objects, list views, page layouts, and Apex classes referenced by the component. | | Lightning event | Custom fields, custom objects, list views, and page layouts | | Lightning interface | Custom fields, custom objects, list views, and page layouts | | Lightning web component | All Lightning web component resources referenced by the component, such as nested components and modules. Custom fields, custom objects, list views, page layouts, and Apex classes referenced by the component | | Named Credential | External credential; for legacy named credentials, an authentication provider | | Page layout | Actions, custom buttons, custom links, s-controls, and Visualforce pages | | Permission set | Any custom permissions, external data sources, Visualforce pages, record types, and Apex classes that are assigned in the permission set | | Record type | Record type mappings, compact layout | | Report | Folder, custom fields, custom objects, custom report types, and custom s-controls | | Reporting Snapshot | Reports | | S-control | Custom fields and custom objects | | Translation | Translated terms for the selected language on any component in the package | | Validation rule | Custom fields (referenced in the formula) | | Visualforce home page component | Associated Visualforce page | | Visualforce pages | Apex classes that are used as custom controllers, Visualforce custom components, and referenced field sets | | Workflow rule | All associated workflow alerts, field updates, outbound messages, and tasks; also, if the workflow rule is designed for a custom object, the custom object is automatically included | **note:** Some package components, such as validation rules or record types, don’t appear in the list of package components, but are included and install with the other components. # Components Available in First-Generation Managed Packages Each metadata component that you include in a first-generation managed package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and installed. Before you review the details about the metadata components that can be included in a managed package, be sure you understand the meaning of each manageability rule. | Rule | Description | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Component Can Be Updated During Package Upgrade | **If yes:** The component can be updated during a package upgrade. The component is first deployed to the subscriber org during the initial package installation, and subsequent package upgrades update the installed component. **If no:** The component can’t be updated during package upgrades. Instead, it’s only deployed to the subscriber org during the initial package installation, and subsequent package upgrades don’t update the component. Components in this category can typically be modified by the admin in the subscriber org. | | Subscriber Can Delete Component | **If yes:** The subscriber or installer of the managed package can delete the packaged component from their org. Deleted components aren’t reinstalled during a package upgrade. **If no:** The subscriber or installer of the managed package can’t delete the packaged component from their org. | | Package Developer Can Remove Component | **If yes:** After the package that contains the component is promoted and released, the package developer can choose to remove the component in a future package version. In most cases, removing components from a package version marks the component as deprecated, and doesn’t hard delete the component from the subscriber org. These deprecated components can be deleted by the admin of the subscriber org. To request access to this feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). **If no:** After the package that contains the component is promoted and released, the package developer can’t remove the component in a future package version. | | Component Has IP Protection | **If yes:** To protect the intellectual property of the developer, the component’s metadata, such as Apex code or Custom Metadata record information, is hidden in the installed org. **If no:** The component is visible in the subscriber’s org. | Each component also lists which properties the package developer and subscriber can edit after the package is promoted or installed. For definitions of those categories, see [Editable Properties After Package Promotion or Installation](https://developer.salesforce.com/docs/platform/pkg1-dev/metadata-components/mdc-editable-property-definitions.md). - **[Account Plan Objective Measure Calculation Definition](#account-plan-objective-measure-calculation-definition)** Represents the definition of a target object, rollup field, and logic for calculating the current value of a sales account plan objective measure. - **[Account Relationship Share Rule](#account-relationship-share-rule)** Determines which object records are shared, how they’re shared, the account relationship type that shares the records, and the level of access granted to the records. - **[Action Link Group Template](#action-link-group-template)** Represents the action link group template. Action link templates let you reuse action link definitions and package and distribute action links. - **[Action Plan Template](#action-plan-template)** Represents an instance of an action plan template. - **[Actionable List Definition](#actionable-list-definition)** Represents the data source definition details associated with an actionable list. - **[Actionable List Key Performance Indicator Definition](#actionable-list-key-performance-indicator-definition)** Represents the custom key performance indicators that are defined for a specific field in an object. - **[Activation Platform](#activation-platform)** Represents the ActivationPlatform configuration, such as platform name, delivery schedule, output format, and destination folder. - **[AffinityScoreDefinition](#affinityscoredefinition)** Represents the affinity information used in calculations to analyze and categorize contacts for marketing purposes. - **[Agent Action](#agent-action)** Represents an action, for use in Agentforce. - **[Agent Topic](#agent-topic)** Represents a topic, for use in Agentforce. - **[AI Application](#ai-application)** Represents an instance of an AI application. For example, Einstein Prediction Builder. - **[AI Application Config](#ai-application-config)** Represents additional prediction information related to an AI application. - **[AIUsecaseDefinition](#aiusecasedefinition)** Represents a collection of fields in a Salesforce org used to define a machine learning use case and get real-time predictions. - **[Analytics](#analytics)** Analytics components include analytics applications, dashboards, dataflows, datasets, lenses, recipes, and user XMD. - **[Analytics Dashboard](#analytics-dashboard)** Represents a Tableau Next dashboard. - **[Analytics Visualization](#analytics-visualization)** Represents a Tableau Next visualization. - **[Analytics Workspace](#analytics-workspace)** Represents a Tableau Next workspace. - **[Apex Class](#apex-class)** Represents an Apex Class. An Apex class is a template or blueprint from which Apex objects are created. Classes consist of other classes, user-defined methods, variables, exception types, and static initialization code. - **[Apex Sharing Reason](#apex-sharing-reason)** Represents an Apex sharing reason, which is used to indicate why sharing was implemented for a custom object. - **[Apex Trigger](#apex-trigger)** Represents an Apex trigger. A trigger is Apex code that executes before or after specific data manipulation language (DML) events occur, such as before object records are inserted into the database, or after records have been deleted. - **[App Framework Template Bundle](#app-framework-template-bundle)** Represents the app framework template bundle. Use these templates for Data Cloud and Tableau Next assets. - **[Application Subtype Definition](#application-subtype-definition)** Represents a subtype of an application within an application domain. - **[AssessmentConfiguration](#assessmentconfiguration)** Represents a configuration for Assessment component. An AssessmentConfiguration entry indicates configuration for user flows such as sending out emails or reminder actions on assessments initiated by the patient. - **[AssessmentQuestion](#assessmentquestion)** Represents the container object that stores the questions required for an assessment. - **[AssessmentQuestionSet](#assessmentquestionset)** Represents the container object for Assessment Questions. - **[Aura Component](#aura-component)** Represents an Aura definition bundle. A bundle contains an Aura definition, such as an Aura component, and its related resources, such as a JavaScript controller. The definition can be a component, application, event, interface, or a tokens collection. - **[Batch Calc Job Definition](#batch-calc-job-definition)** Represents a Data Processing Engine definition. - **[Batch Process Job Definition](#batch-process-job-definition)** Represents the details of a Batch Management job definition. - **[Benefit Action](#benefit-action)** Represents details of an action that can be triggered for a benefit. - **[Bot Template](#bot-template)** Represents the configuration details for a specific Einstein Bot template, including dialogs and variables. - **[Branding Set](#branding-set)** Represents the definition of a set of branding properties for an Experience Builder site, as defined in the Theme panel in Experience Builder. - **[Briefcase Definition](#briefcase-definition)** Represents a briefcase definition. A briefcase makes selected records available for specific users and groups to view when they’re offline in the Salesforce Field Service mobile app for iOS and Android. - **[Building Energy Intensity Record Type Configuration](#building-energy-intensity-record-type-configuration)** Represents the setup object that contains the mapping between the Building Energy Intensity Record record type and internal enums. You can primarily use this object for calculations across different record types. - **[Business Process](#business-process)** The BusinessProcess metadata type enables you to display different picklist values for users based on their profile. - **[Business Process Group](#business-process-group)** Represents the surveys used to track customers’ experiences across different stages in their lifecycle. - **[Business Process Type Definition](#business-process-type-definition)** Define the types of business processes that are applied to a rule. - **[Care Benefit Verify Settings](#care-benefit-verify-settings)** Represents the configuration settings for benefit verification requests. - **[Care Limit Type](#care-limit-type)** Defines the characteristics of limits on benefit provision. - **[Care Request Configuration](#care-request-configuration)** Represents the details for a record type such as service request, drug request, or admission request. One or more record types can be associated with a care request. - **[Care System Field Mapping](#care-system-field-mapping)** Represents a mapping from source system fields to Salesforce target entities and attributes. - **[Channel Layout](#channel-layout)** Represents the metadata associated with a communication channel layout. - **[Chatter Extension](#chatter-extension)** Represents the metadata used to describe a Rich Publisher App that’s integrated with the Chatter publisher. - **[Claim Financial Settings](#claim-financial-settings)** Represents the configuration settings for Insurance Claim Financial Services. - **[CommunicationChannelType](#communicationchanneltype)** Represents the type of communication channel, such as WhatsApp and SMS, to use for referral promotions. - **[Community Template Definition](#community-template-definition)** Represents the definition of an Experience Builder site template. - **[Community Theme Definition](#community-theme-definition)** Represents the definition of a theme for an Experience Builder site. - **[Compact Layout](#compact-layout)** Represents the metadata associated with a compact layout. - **[Conditional Formatting Ruleset](#conditional-formatting-ruleset)** Represents a set of rules that define the style and visibility of conditional field formatting on Dynamic Forms-enabled Lightning page field instances. - **[Connected App](#connected-app)** Represents a connected app configuration. A connected app enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. - **[Context Definition](#context-definition)** A context definition defines the relationship between the nodes and the attributes within each node. For efficient data access, users can use nodes and attributes to easily access the relevant data from the mapped data source. Various Salesforce products offer predefined context definitions based on their use case. - **[Contract Type](#contract-type)** A contract type is used to group contracts so that they exhibit similar characteristics. For example, the lifecycle states, the people who access, the templates and clauses used. - **[Conversation Channel Definition](#conversation-channel-definition)** Represents the conversation channel definition that’s implemented for Interaction Service for Bring Your Own Channel and Bring Your Own Channel for CCaaS messaging channels. - **[Conversation Vendor Info](#conversation-vendor-info)** This setup object connects the partner vendor system to the Service Cloud feature. - **[CORS Allowlist](#cors-allowlist)** Represents an origin in the CORS allowlist. - **[CSP Trusted Site](#csp-trusted-site)** Represents a trusted URL. For each CspTrustedSite component, you can specify Content Security Policy (CSP) directives and permissions policy directives. - **[Custom Application](#custom-application)** Represents a custom application. - **[Custom Button or Link](#custom-button-or-link)** Represents a custom link defined in a home page component. - **[Custom Console Components](#custom-console-components)** Represents a custom console component (Visualforce page) assigned to a CustomApplication that is marked as a Salesforce console. Custom console components extend the capabilities of Salesforce console apps. - **[Custom Field on Standard or Custom Object](#custom-field-on-standard-or-custom-object)** Represents the metadata associated with a field. Use this metadata type to create, update, or delete custom field definitions on standard or custom objects. - **[Custom Field on Custom Metadata Type](#custom-field-on-custom-metadata-type)** Represents a custom fields on the custom metadata type. - **[Custom Field Display](#custom-field-display)** Represents the CustomFieldDisplay view type assigned to product attribute custom fields. - **[Custom Help Menu Section](#custom-help-menu-section)** Represents the section of the Lightning Experience help menu that the admin added to display custom, org-specific help resources for the org. The custom section contains help resources added by the admin. - **[Custom Index](#custom-index)** Represents an index used to increase the speed of queries. - **[Custom Label](#custom-label)** The CustomLabels metadata type allows you to create custom labels that can be localized for use in different languages, countries, and currencies. - **[Custom Metadata Type Records](#custom-metadata-type-records)** Represents a record of a custom metadata type. - **[Custom Metadata Type](#custom-metadata-type)** Represents a record of a custom metadata type. - **[Custom Notification Type](#custom-notification-type)** Represents the metadata associated with a custom notification type. - **[Custom Object](#custom-object)** Represents a custom object that stores data unique to an org or an external object that maps to data stored outside an org. - **[Custom Object Translation](#custom-object-translation)** This metadata type allows you to translate custom objects for a variety of languages. - **[Custom Permission](#custom-permission)** Represents a permission that grants access to a custom feature. - **[Custom Tab](#custom-tab)** Represents a custom tab. Custom tabs let you display custom object data or other web content in Salesforce. - **[Dashboard](#dashboard)** Represents a dashboard. Dashboards are visual representations of data that allow you to see key metrics and performance at a glance. - **[DataCalcInsightTemplate](#datacalcinsighttemplate)** Represents the object template for data calculations and insights of Data Cloud objects in DataCalcInsightTemplate. These objects are added inside the data kit. - **[DataCleanRoomProvider](#datacleanroomprovider)** Represents a clean room provider configuration that defines the clean room collaboration details, including templates and the platform used for secure data collaboration in Data 360. - **[DataConnector](#dataconnector)** Represents the white-labeled metadata configuration for an external connector in Data 360. - **[Data Connector Ingest API](#data-connector-ingest-api)** Represents the connection information specific to Ingestion API. - **[Data Connector S3](#data-connector-s3)** Represents the connection information specific to Amazon S3. - **[Data Kit Object Dependency](#data-kit-object-dependency)** Represent the object dependencies and relationships between different objects in Data Kit Object Dependency. These objects are added inside the data kit. - **[Data Kit Object Template](#data-kit-object-template)** Represents the object in Data Kit Object Template. This object template is added inside the data kit. - **[DataObjectBuildOrgTemplate](#dataobjectbuildorgtemplate)** Represents the output objects of the components the user includes in a data kit. - **[Data Package Kit Definition](#data-package-kit-definition)** Represents the top-level Data Kit container definition. Content objects can be added after the Data Kit is defined. - **[Data Package Kit Object](#data-package-kit-object)** Represents the object in Data Kit Content Object. These objects are added inside the data kit. - **[Data Source](#data-source)** Used to represent the system where the data was sourced. - **[Data Source Bundle Definition](#data-source-bundle-definition)** Represents the bundle of streams that a user adds to a data kit. - **[Data Source Object](#data-source-object)** Represents the object from where the data was sourced. - **[Data Src Data Model Field Map](#data-src-data-model-field-map)** Represents the entity that’s used to store the design-time bundle-level mappings for the data source fields and data model fields. - **[Data Stream Definition](#data-stream-definition)** Contains Data Ingestion information such as Connection, API and File retrieval settings. - **[Data Stream Template](#data-stream-template)** Represents the data stream that a user adds to a data kit. - **[DataWeaveResource](#dataweaveresource)** Represents the DataWeaveScriptResource class that is generated for all DataWeave scripts. DataWeave scripts can be directly invoked from Apex. - **[Decision Matrix Definition](#decision-matrix-definition)** Represents a definition of a decision matrix. - **[Decision Matrix Definition Version](#decision-matrix-definition-version)** Represents a definition of a decision matrix version. - **[Decision Table](#decision-table)** Represents the information about a decision table. - **[Decision Table Dataset Link](#decision-table-dataset-link)** Represents the information about a dataset link associated with a decision table. In a dataset link, select an object for whose records, the decision table must provide an outcome. - **[Digital Experience](#digital-experience)** Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. - **[Digital Experience Bundle](#digital-experience-bundle)** Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. - **[Disclosure Definition](#disclosure-definition)** Represents information that defines a disclosure type, such as details of the publisher or vendor who created or implemented the report. - **[Disclosure Definition Version](#disclosure-definition-version)** Represents the version information about the disclosure definition. - **[Disclosure Type](#disclosure-type)** Represents the types of disclosures that are done by an individual or an organization and the associated metadata. - **[Discovery AI Model](#discovery-ai-model)** Represents the metadata associated with a model used in Einstein Discovery. - **[Discovery Goal](#discovery-goal)** Represents the metadata associated with an Einstein Discovery prediction definition. - **[Discovery Story](#discovery-story)** Represents the metadata associated with a story used in Einstein Discovery. - **[Document](#document)** Represents a Document. All documents must be in a document folder, such as sampleFolder/TestDocument. - **[Document Generation Setting](#document-generation-setting)** Represents an org's settings for automatic document generation from templates. - **[Eclair GeoData](#eclair-geodata)** Represents an Analytics custom map chart. Custom maps are user-defined maps that are uploaded to Analytics and are used just as standard maps are. Custom maps are accessed in Analytics from the list of maps available with the map chart type. - **[Email Template (Classic)](#email-template-classic)** Use email templates to increase productivity and ensure consistent messaging. Email templates with merge fields let you quickly send emails that include field data from Salesforce records. - **[Email Template (Lightning)](#email-template-lightning)** Represents a template for an email, mass email, list email, or Sales Engagement email. - **[Embedded Service Config](#embedded-service-config)** Represents a setup node for creating an Embedded Service for Web deployment. - **[Embedded Service Menu Settings](#embedded-service-menu-settings)** Represents a setup node for creating a channel menu deployment. Channel menus list the ways in which customers can contact your business. - **[Enablement Measure Definition](#enablement-measure-definition)** Represents an Enablement measure, which specifies the job-related activity that a user performs to complete a milestone or outcome in an Enablement program. A measure identifies a source object and optional related objects, with optional field filters and filter logic, for tracking the activity. - **[Enablement Program Definition](#enablement-program-definition)** Represents an Enablement program, which includes exercises and measurable milestones to help users such as sales reps achieve specific outcomes related to your company’s revenue goals. - **[Enablement Program Task Subcategory](#enablement-program-task-subcategory)** Represents a custom exercise type that an Enablement admin adds to an Enablement program in Program Builder. A custom exercise type also requires a corresponding EnblProgramTaskDefinition record for Program Builder and corresponding LearningItem and LearningItemType records for when users take the exercise in the Guidance Center. - **[Entitlement Template](#entitlement-template)** Represents an entitlement template. Entitlement templates are predefined terms of customer support that you can quickly add to products. - **[ESignature Config](#esignature-config)** Using the Electronic Signature Configuration setup, the system admin must define the required configurations to support the e-signature APIs and UI. - **[ESignature Envelope Config](#esignature-envelope-config)** Using the Electronic Signature Envelope Config the system admin can define the default reminders and expiry for the envelopes submitted for eSignature. - **[Event Relay](#event-relay)** Represents an event relay that you can use to send platform events and change data capture events from Salesforce to Amazon EventBridge. - **[Explainability Action Definition](#explainability-action-definition)** Define where the metadata for your Decision Explainer business rules are stored in Public Sector Solutions. - **[Explainability Action Version](#explainability-action-version)** Define and store versions of the explainability actions used by your Decision Explainer business rules in Public Sector Solutions. - **[Explainability Message Template](#explainability-message-template)** Represents information about the template that contains the decision explanation message for a specified expression set step type. - **[Expression Set Definition](#expression-set-definition)** Represents an expression set definition. - **[Expression Set Definition Version](#expression-set-definition-version)** Represents a definition of an expression set version. - **[Expression Set Object Alias](#expression-set-object-alias)** Represents information about the alias of the source object that’s used in an expression set. - **[Expression Set Message Token](#expression-set-message-token)** Represents a token that's used in an explainability message template. The token can be replaced with an expression set version resource that the template is used in. This object is available in API version 59.0 and later. - **[External Auth Identity Provider](#external-auth-identity-provider)** Represents the external auth identity provider that obtains OAuth tokens for callouts that use named credentials. - **[External Client App Header](#external-client-app-header)** Represents the header file for an external client application configuration. - **[External Client App Notification Settings](#external-client-app-notification-settings)** Represents the settings configuration for the external client app’s notifications plugin. - **[External Client App OAuth Settings](#external-client-app-oauth-settings)** Represents the settings configuration for the external client app’s OAuth plugin. - **[External Client App Push Settings](#external-client-app-push-settings)** Represents the settings configuration for the external client app’s push notification plugin. - **[External Credential](#external-credential)** Represents the details of how Salesforce authenticates to the external system. - **[External Data Connector](#external-data-connector)** Used to represent the object where the data was sourced. - **[External Data Source](#external-data-source)** Represents the metadata associated with an external data source. Create external data sources to manage connection details for integration with data and content that are stored outside your Salesforce org. - **[External Data Transport Field Template](#external-data-transport-field-template)** Represents the definition of a Data Cloud schema field. - **[External Data Transport Field](#external-data-transport-field)** Use ExternalDataTranField to add a field to the ExternalDataTranObject in your managed packages. ExternalDataTranObject is a Data Cloud schema object. - **[External Data Transport Object Template](#external-data-transport-object-template)** Represents the definition of a Data Cloud schema object. - **[External Data Transport Object](#external-data-transport-object)** To include a Data Cloud schema object in your managed packages, add ExternalDataTranObject. - **[External Document Storage Configuration](#external-document-storage-configuration)** Represents configuration, which admin makes in setup to specify the drive, path, and named credential to be used for storing documents on external drives. - **[External Services](#external-services)** Represents the External Service configuration for an org. - **[Feature Parameter Boolean](#feature-parameter-boolean)** Represents a boolean feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[Feature Parameter Date](#feature-parameter-date)** Represents a date feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[Feature Parameter Integer](#feature-parameter-integer)** Represents an integer feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[Field Set](#field-set)** Represents a field set. A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user's first name, middle name, last name, and business title. - **[Field Source Target Relationship](#field-source-target-relationship)** Stores the relationships between a data model object (DMO) and its fields. For example, the Individual.Id field has a one-to-many relationship (1:M) with the ContactPointEmail.PartyId field. - **[Flow](#flow)** Represents the metadata associated with a flow. With Flow, you can create an application that navigates users through a series of pages to query and update records in the database. You can also execute logic and provide branching capability based on user input to build dynamic applications. - **[Flow Category](#flow-category)** Represents a list of flows that are grouped by category. - **[Flow Definition](#flow-definition)** Represents the flow definition’s description and active flow version number. - **[Flow Test](#flow-test)** Represents the metadata associated with a flow test. Before you activate a record-triggered flow, you can test it to verify its expected results and identify flow run-time failures. - **[Folder](#folder)** Represents a folder. - **[Fuel Type](#fuel-type)** Represents a custom fuel type in an org. - **[Fuel Type Sustainability Unit of Measure](#fuel-type-sustainability-unit-of-measure)** Represents a mapping between the custom fuel types and their corresponding unit of measure (UOM) values defined by a customer in an org. - **[Fundraising Config](#fundraising-config)** Represents a collection of settings to configure the fundraising product. - **[Gateway Provider Payment Method Type](#gateway-provider-payment-method-type)** Represents an entity that allows integrators and payment providers to choose an active payment to receive an order's payment data rather than allowing the Salesforce Order Management platform to select a default payment method. - **[Gen Ai Planner Bundle](#gen-ai-planner-bundle)** Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). - **[Generative AI Prompt Template](#generative-ai-prompt-template)** Represents a generative AI prompt template, for use in Agentforce. - **[Global Picklist](#global-picklist)** Represents the metadata for a global picklist value set, which is the set of shared values that custom picklist fields can use. A global value set isn’t a field itself. In contrast, the custom picklist fields that are based on a global picklist are of type ValueSet. - **[Home Page Component](#home-page-component)** Represents the metadata associated with a home page component. You can customize the Home tab in Salesforce Classic to include components such as sidebar links, a company logo, a dashboard snapshot, or custom components that you create. Use to create, update, or delete home page component definitions. - **[Home Page Layout](#home-page-layout)** Represents the metadata associated with a home page layout. You can customize home page layouts and assign the layouts to users based on their user profile. - **[Identity Verification Proc Def](#identity-verification-proc-def)** Represents the definition of the identity verification process. - **[Inbound Network Connection](#inbound-network-connection)** Represents a private connection between a third-party data service and a Salesforce org. The connection is inbound because the callouts are coming into Salesforce. - **[IntegrationProviderDef](#integrationproviderdef)** Represents an integration definition associated with a service process. Stores data for the Industries: Send Apex Async Request and Industries: Send External Async Request invocable actions. - **[LearningAchievementConfig](#learningachievementconfig)** Represents the mapping details between a Learning Achievement type and a Learning Achievement record type. - **[Learning Item Type](#learning-item-type)** Represents a custom exercise type that an Enablement user takes in an Enablement program in the Guidance Center. A custom exercise type also requires a corresponding LearningItem record for the Guidance Center and corresponding EnblProgramTaskDefinition and EnblProgramTaskSubCategory records for when admins create a program in Program Builder. - **[Letterhead](#letterhead)** Represents formatting options for the letterhead in an email template. A letterhead defines the logo, page color, and text settings for your HTML email templates. Use letterheads to ensure a consistent look and feel in your company’s emails. - **[Life Science Config Category](#life-science-config-category)** Represents the category that a Life Sciences configuration record is organized into. - **[Life Science Config Record](#life-science-config-record)** Represents a configuration record for Life Sciences. This object is a child of Life Science Config Category. - **[Lightning Bolt](#lightning-bolt)** Represents the definition of a Lightning Bolt Solution, which can include custom apps, flow categories, and Experience Builder templates. - **[Lightning Message Channel](#lightning-message-channel)** Represents the metadata associated with a Lightning Message Channel. A Lightning Message Channel represents a secure channel to communicate across UI technologies, such as Lightning Web Components, Aura Components, and Visualforce. - **[Lightning Page](#lightning-page)** Represents the metadata associated with a Lightning page. A Lightning page represents a customizable screen made up of regions containing Lightning components. - **[Lightning Type](#lightning-type)** Represents a custom Lightning type. Use this type to override the default user interface to create a customized appearance based on your business requirements. Deploy this bundle to your organization to implement the overrides. - **[Lightning Web Component](#lightning-web-component)** Represents a Lightning web component bundle. A bundle contains Lightning web component resources. - **[List View](#list-view)** ListView allows you to see a filtered list of records, such as contacts, accounts, or custom objects. - **[Live Chat Sensitive Data Rule](#live-chat-sensitive-data-rule)** Represents a rule for masking or deleting data of a specified pattern. Written as a regular expression (regex). Use this object to mask or delete data of specified patterns, such as credit card, social security, or phone and account numbers. - **[Loyalty Program Setup](#loyalty-program-setup)** Represents the configuration of a loyalty program process including its parameters and rules. Program processes determine how new transaction journals are processed. When new transaction journals meet the criteria and conditions for a program process, actions that are set up in the process are triggered for the transaction journals. - **[Managed Content Type](#managed-content-type)** Represents the definition of custom content types for use with Salesforce CMS. Custom content types are displayed as forms with defined fields. - **[Marketing App Extension](#marketing-app-extension)** Represents an integration with a third-party app or service that generates prospect external activity. - **[Marketing App Extension Activity](#marketing-app-extension-activity)** Represents an Activity Type, which is a prospect activity that occurs in a third-party app and can be used in Account Engagement automations. - **[Market Segment Definition](#market-segment-definition)** Represents the field values for MarketSegmentDefinition. MarketSegmentDefinition is used to store the exportable metadata of a segment, such as segment criteria and other attributes. Developers can create segment definition packages, pass segment definition in the form of data build tool (DBT), and publish it on AgentExchange for subscriber organizations to install and instantiate these segments. - **[MktCalculatedInsightsObjectDef](#mktcalculatedinsightsobjectdef)** Represents Calculated Insight definition such as expression. - **[MktDataConnection](#mktdataconnection)** Represents the connection information of an external connector that can ingest data to Data Cloud, read data from the source, or write data to the source in Data Cloud. - **[MktDataTranObject](#mktdatatranobject)** An entity that is used to deliver (aka transport) information from the source to a target (target will be called a landing entity).This can be the schema of a file, API, Event, or other means of transporting data, such as SubscriberFile1.csv, or SubscriberCDCEvent. - **[Named Credential](#named-credential)** Represents a named credential, which specifies the URL of a callout endpoint and its required authentication parameters in one definition. A named credential can be specified as an endpoint to simplify the setup of authenticated callouts. - **[Object Source Target Map](#object-source-target-map)** Contains the object-level mappings between the source and the target objects. The source and target objects can be an MktDataLakeObject or an MktDataModelObject. For example, an Email source object can be mapped to the ContactPointEmail object. - **[Object Integration Provider Definition Mapping](#object-integration-provider-definition-mapping)** Maps structured, logical data nodes in a context definition to actual Salesforce object fields or external data sources - **[OcrSampleDocument](#ocrsampledocument)** Represents the details of a sample document or a document type that's used as a reference while extracting and mapping information from a customer form. - **[OcrTemplate](#ocrtemplate)** Represents the details of the mapping between a form and a Salesforce object using Intelligent Form Reader. - **[Outbound Network Connection](#outbound-network-connection)** Represents a private connection between a Salesforce org and a third-party data service. The connection is outbound because the callouts are going out of Salesforce. - **[Page Layout](#page-layout)** Represents the metadata associated with a page layout. - **[Path Assistant](#path-assistant)** Represents Path records. - **[Payment Gateway Provider](#payment-gateway-provider)** Represents the metadata associated with a payment gateway provider. - **[Permission Set](#permission-set)** Represents a set of permissions that's used to grant more access to one or more users without changing their profile or reassigning profiles. You can use permission sets to grant access but not to deny access. - **[Permission Set Groups](#permission-set-groups)** Represents a group of permission sets and the permissions within them. Use permission set groups to organize permissions based on job functions or tasks. Then, you can package the groups as needed. - **[Platform Cache](#platform-cache)** Represents a partition in the Platform Cache. - **[Platform Event Channel](#platform-event-channel)** Represents a channel that you can subscribe to in order to receive a stream of events. - **[Platform Event Channel Member](#platform-event-channel-member)** Represents an entity selected for Change Data Capture notifications on a standard or custom channel, or a platform event selected on a custom channel. - **[Platform Event Subscriber Configuration](#platform-event-subscriber-configuration)** Represents configuration settings for a platform event Apex trigger, including the batch size, the trigger’s running user, and parallel subscription settings. - **[Pricing Action Parameters](#pricing-action-parameters)** Represents a pricing action associated to a context definition and a pricing procedure. - **[Pricing Recipe](#pricing-recipe)** Represents one out of various data models or sets of entities of a particular cloud that'll be consumed by the pricing data store during design and run time. - **[Procedure Output Resolution](#procedure-output-resolution)** Represents the pricing resolution for an pricing element determined using strategy name and formula. - **[Process](#process)** Use Flow instead. - **[Process Flow Migration](#process-flow-migration)** Represents a process's migrated criteria and the resulting migrated flow. - **[Product Attribute Set](#product-attribute-set)** Represents the ProductAttribute information being used as and attribute such as color_c, size_c . - **[Product Specification Type](#product-specification-type)** Represents the type of product specification provided by the user to make the product terminology unique to an industry. A product specification type is associated with a product specification record type. - **[Product Specification Record Type](#product-specification-record-type)** Represents the relationship between industry-specific product specifications and the product record type. - **[Prompts (In-App Guidance)](#prompts-in-app-guidance)** Represents the metadata related to in-app guidance, which includes prompts and walkthroughs. - **[Quick Action](#quick-action)** Represents a specified create or update quick action for an object that then becomes available in the Chatter publisher. - **[Recommendation Strategy](#recommendation-strategy)** Represents a recommendation strategy. Recommendation strategies are applications, similar to data flows, that determine a set of recommendations to be delivered to the client through data retrieval, branching, and logic operations. - **[Record Action Deployment](#record-action-deployment)** Represents configuration settings for the Actions & Recommendations, Action Launcher, and Bulk Action Panel components. - **[Record Alert Data Source Expression Set Definition](#record-alert-data-source-expression-set-definition)** Represents information about the data source for a record alert and the association with an expression set definition. - **[Record Type](#record-type)** Represents the metadata associated with a record type. Record types let you offer different business processes, picklist values, and page layouts to different users. Use this metadata type to create, update, or delete record type definitions for a custom object. - **[RedirectWhitelistUrl](#redirectwhitelisturl)** Represents a trusted URL that’s excluded from redirection restrictions when the redirectionWarning or redirectBlockModeEnabled field on the SessionSettings Metadata type is set to true. - **[Referenced Dashboard](#referenced-dashboard)** Represents the ReferencedDashboard object in CRM Analytics. A referenced dashboard stores information about an externally referenced dashboard. - **[Registered External Service](#registered-external-service)** Represents a registered external service, which provides an extension or integration. - **[RelationshipGraphDefinition](#relationshipgraphdefinition)** Represents a definition of a graph that you can configure in your organization to traverse object hierarchies and record details, giving you a glimpse of how your business works. - **[Remote Site Setting](#remote-site-setting)** Represents a remote site setting. - **[Report](#report)** Represents a custom report. - **[Report Type](#report-type)** Represents the metadata associated with a custom report type. Custom report types allow you to build a framework from which users can create and customize reports. - **[ServiceProcess](#serviceprocess)** Represents a process created in Service Process Studio and its associated attributes. - **[Slack App (Beta)](#slack-app-beta)** Represents a Slack app. - **[Service Catalog Category](#service-catalog-category)** Represents the grouping of individual catalog items in Service Catalog. - **[Service Catalog Filter Criteria](#service-catalog-filter-criteria)** Represents an eligibility rule that determines if a Service Catalog user has access to a catalog item. - **[Service Catalog Item Definition](#service-catalog-item-definition)** Represents the entity associated with a specific, individual service available in the Service Catalog. - **[Service Catalog Fulfillment Flow](#service-catalog-fulfillment-flow)** Represents the flow associated with a specific catalog item in the Service Catalog. - **[Stationary Asset Environmental Source Record Type Configuration](#stationary-asset-environmental-source-record-type-configuration)** Represents the setup object that contains the mapping between the Stationary Asset Environmental Source record type and internal enums. You can primarily use this object for calculations across different record types. - **[Static Resource](#static-resource)** Represents a static resource file, often a code library in a ZIP file. - **[Streaming App Data Connector](#streaming-app-data-connector)** Represents the connection information specific to Web and Mobile Connectors. - **[Sustainability UOM](#sustainability-uom)** Represents information about the additional unit of measure values defined by a customer. - **[Sustainability UOM Conversion](#sustainability-uom-conversion)** Represents information about the unit of measure conversion for the additional fuel types defined by a customer. - **[Timeline Object Definition](#timeline-object-definition)** Represents the container that stores the details of a timeline configuration. You can use this resource with Salesforce objects to see their records' related events in a linear time-sorted view. - **[Timesheet Template](#timesheet-template)** Represents a template for creating time sheets in Field Service. - **[Translation](#translation)** Add translations to your managed packages. - **[UI Object Relation Config](#ui-object-relation-config)** Represents the admin-created configuration of the object relation UI component. - **[User Access Policy](#user-access-policy)** Represents a user access policy. - **[Validation Rule](#validation-rule)** Represents a validation rule, which is used to verify that the data a user enters in a record is valid and can be saved. - **[Vehicle Asset Emissions Source Record Type Configuration](#vehicle-asset-emissions-source-record-type-configuration)** Represents the setup object that contains the mapping between the Vehicle Asset Emissions Source record type and internal enums. You can primarily use this object for calculations across different record types. - **[View Definition (Beta)](#view-definition-beta)** Represents a view definition on a Slack app. - **[Virtual Visit Config](#virtual-visit-config)** Represents an external video provider configuration, which relays events from Salesforce to the provider. - **[Visualforce Component](#visualforce-component)** Represents a Visualforce component. - **[Visualforce Page](#visualforce-page)** Represents a Visualforce page. - **[Wave Analytic Asset Collection](#wave-analytic-asset-collection)** A collection of CRM Analytics assets. - **[Wave Application](#wave-application)** A CRM Analytics application. - **[Wave Component](#wave-component)** A CRM Analytics dashboard component. - **[Wave Dataflow](#wave-dataflow)** A CRM Analytics data prep dataflow. - **[Wave Dashboard](#wave-dashboard)** A CRM Analytics dashboard. - **[Wave Dataset](#wave-dataset)** A CRM Analytics dataset. - **[Wave Lens](#wave-lens)** A CRM Analytics lens. - **[Wave Recipe](#wave-recipe)** A CRM Analytics data prep recipe. - **[Wave Template Bundle](#wave-template-bundle)** A CRM Analytics template bundle. - **[Wave Xmd](#wave-xmd)** The extended metadata for CRM Analytics dataset fields and their formatting for dashboards and lenses. - **[Web Store Template](#web-store-template)** Represents a configuration for creating commerce stores. - **[Workflow Alert](#workflow-alert)** WorkflowAlert represents an email alert associated with a workflow rule. - **[Workflow Field Update](#workflow-field-update)** WorkflowFieldUpdate represents a workflow field update. - **[Workflow Knowledge Publish](#workflow-knowledge-publish)** WorkflowKnowledgePublish represents Salesforce Knowledge article publishing actions and information. - **[Workflow Outbound Message](#workflow-outbound-message)** WorkflowOutboundMessage represents an outbound message associated with a workflow rule. - **[Workflow Rule](#workflow-rule)** This metadata type represents a workflow rule. - **[Workflow Task](#workflow-task)** This metadata type references an assigned workflow task. ## Account Plan Objective Measure Calculation Definition Represents the definition of a target object, rollup field, and logic for calculating the current value of a sales account plan objective measure. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, DeveloperName, MasterLabel, RollupType, Status, TargetField, TargetObject | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AccountPlanObjMeasCalcDef; Component Type in 1GP Package Manager UI: Account Plan Objective Measure Calculation Definition **Documentation:** [Sales Account Plan Objectives, Measures, and Calculation Definitions](https://help.salesforce.com/s/articleView?id=sales.account_plans_objective_measures.htm&type=5) ## Account Relationship Share Rule Determines which object records are shared, how they’re shared, the account relationship type that shares the records, and the level of access granted to the records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Name, Developer Name, Description, Account Relationship Type, Access Level, Object Type, Account to Criteria Field | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AccountRelationshipShareRule **Use Case:** To share data between external accounts. **License Requirements:** Orgs with Digital Experiences enabled can use this package. **Documentation:** _Salesforce Help:_ [Account Relationships and Account Relationship Data Sharing Rules](https://help.salesforce.com/s/articleView?id=platform.networks_partner_account_relationships_and_sharing.htm&type=5) ## Action Link Group Template Represents the action link group template. Action link templates let you reuse action link definitions and package and distribute action links. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionLinkGroupTemplate; Component Type in 1GP Package Manager UI: Action Link Group Template **Documentation:** _Salesforce Help:_ [Action Link Templates](https://help.salesforce.com/s/articleView?id=platform.action_link_group_template.htm&type=5) ## Action Plan Template Represents an instance of an action plan template. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionPlanTemplate **Documentation:** _Salesforce Help:_ [Action Plans](https://help.salesforce.com/s/articleView?id=ind.fsc_action_plans.htm&type=5) ## Actionable List Definition Represents the data source definition details associated with an actionable list. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionableListDefinition; Component Type in 1GP Package Manager UI: ActionableListDefinition **Documentation:** _Salesforce Help:_ [Actionable Segmentation](https://help.salesforce.com/s/articleView?id=ind.actionable_segmentation.htm&type=5) ## Actionable List Key Performance Indicator Definition Represents the custom key performance indicators that are defined for a specific field in an object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes, Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActnblListKeyPrfmIndDef; Component Type in 1GP Package Manager UI: ActnblListKeyPrfmIndDef **License Requirements:** Actionable Segmentation **Documentation:** _Salesforce Help:_ [Create Custom Key Performance Indicators](https://help.salesforce.com/s/articleView?id=ind.create_custom_kpis.htm&type=5); _Salesforce Help:_ [ActnblListKeyPrfmIndDef](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/sforce_api_objects_actnbllistkeyprfminddef.htm) ## Activation Platform Represents the ActivationPlatform configuration, such as platform name, delivery schedule, output format, and destination folder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------- | | Only Package Developer Can Edit | DataConnector, Description, LogoUrl, MasterLabel, OutputFormat, RefreshMode, Type | | Both Package Developer and Subscriber Can Edit | Enabled (only subscriber editable), IncludeSegmentNames (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | ID, OutputGrouping, PeriodicRefreshFrequency, RefreshFrequency | ### More Information **Feature Name:** Metadata Name: ActivationPlatform; Component Type in 1GP Package Manager UI: ActivationPlatform **Use Case:** Allows ISVs to specify capabilities of their Activation Platform integrations and publish it on AgentExchange for subscriber organizations to install and instantiate instances of the platform as a disparate activation target. **Considerations When Packaging** Some upgrade scenarios are not support: - Adding a new required field - Removing a previously supported ID type - Removing a previously supported optional field or required field - Changing a previously supported field property from optional to required Some update scenarios are supported and don't automatically cascade to Activation Target or Activations created before the upgrade installations: - Adding a new ID type - Adding of a new optional field - Adding a new hidden field - Value change on a previously supported hidden field To apply updates to future Activation run jobs, the user must edit and resave all Activation Targets created before the upgrade. Developers provide post-install instructions informing the subscriber of this required action anytime a change is made in a new version release. **License Requirements:** Data Cloud enabled orgs can access this package. **Post Install Steps:** An admin from the subscriber org enables the activation platform to start using this platform in Activation creations. **Documentation:** _Metadata API Developer Guide:_ [ActivationPlatform](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_activationplatform.htm) ## AffinityScoreDefinition Represents the affinity information used in calculations to analyze and categorize contacts for marketing purposes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AffinityScoreType, NumberOfMonths, NumberOfRanges, SourceFieldApiNameList, TargetFieldApiNameList, ScoreRangeList | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AffinityScoreDefinition **Documentation** ## Agent Action Represents an action, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ------------------------------------------------------------------------------------ | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No (However, actions can incorporate flows or Apex code that do have IP protection.) | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | Description, IsConfirmationRequired, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, InvocationTarget, InvocationTargetType | Action Input Fields: - CopilotAction.IsUserInput - Description - IsPII - Properties (Inherited from invocationTarget like flows or Apex code.) - Title (Inherited from invocationTarget like flows or Apex code.) - Required - Lightning.Type Action Output Fields: - Description - CopilotAction.IsDisplayable - IsPII - CopilotAction.IsUsedByPlanner - Properties (Inherited from invocationTarget like flows or Apex code.) - Title (Inherited from invocationTarget like flows or Apex code.) ### More Information **Feature Name:** Metadata Name: [GenAiFunction](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaifunction.htm); Component Type in 1GP Package Manager UI: Generative AI Function Definition **Use Case:** Provide actions that customers can add to their own topics and agents. **Considerations When Packaging** When creating an Agent Action of type Apex, the Apex class, invocable Apex method, and any invocable Apex variables must all be marked as global. If any of these are public or private, the Apex method won't appear in the list of options to add to the Agent Action, and won't be invoked by an Agent at runtime. **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [Agentforce Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_actions.htm); _Metadata API Developer Guide:_ [GenAiFunction](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaifunction.htm) ## Agent Topic Represents a topic, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, MasterLabel, Scope, AiPluginUtterances, GenAiFunctions, GenAiPluginInstructions | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, PluginType | ### More Information **Feature Name:** Metadata Name: [GenAiPlugin](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiplugin.htm); Component Type in 1GP Package Manager UI: Generative AI Plugin Definition **Use Case** Provide topics that customers can add to their own agents. Actions can be added to topics. **Considerations When Packaging** Subscribers can't edit which actions are associated with a managed-installed topic. Instead, subscribers must manually create a copy of the topic and then assign actions to their copy of the topic. We're working to improve this experience. **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [Agentforce Topics](https://help.salesforce.com/s/articleView?id=ai.copilot_topics.htm) ## AI Application Represents an instance of an AI application. For example, Einstein Prediction Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | Type | | Both Package Developer and Subscriber Can Edit | Status, ExternalId, MlExternalId | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: AIApplication **Considerations When Packaging** AIApplication is the parent entity for all Einstein configuration entities. Packaging of Einstein features must always begin with the selection of one or more AIApplications. To create a package with ML Prediction Definition, select the parent AIApplication (Type = PredictionBuilder). To create a package with ML Recommendation Definition, select the parent AIApplication (Type = RecommendationBuilder). Packaging automatically analyzes the relationships and includes the associated MLPredictionDefinitions, MLRecommendationDefinitions, and MLDataDefinitions necessary to fully define the Einstein configuration. **Documentation:** _Metadata API Developer Guide:_ [AIApplication](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_aiapplication.htm); _Salesforce Help:_ [Einstein Prediction Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_prediction_builder_lm.htm&type=5); _Salesforce Help:_ [Einstein Recommendation Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_recommendation_builder.htm&type=5) ## AI Application Config Represents additional prediction information related to an AI application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------- | | Only Package Developer Can Edit | AIApplicationId | | Both Package Developer and Subscriber Can Edit | Rank, IsInsightReasonEnabled, AIScoringMode, ExternalId | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: AIApplicationConfig **Considerations When Packaging** AIApplicationConfig is always associated with an AIApplication. Packaging of Einstein features must always begin with the selection of one or more AIApplications. To create a package with AI Application Config, select the parent AIApplication. Packaging automatically analyzes the relationships and includes the associated MLApplicationConfig, MLPredictionDefinition, MLRecommendationDefinitions, and MLDataDefinitions necessary to fully define the Einstein configuration. **Documentation:** _Metadata API Developer Guide:_ [AIApplicationConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_aiapplicationconfig.htm); _Salesforce Help:_ [Einstein Prediction Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_prediction_builder_lm.htm&type=5); _Salesforce Help:_ [Einstein Recommendation Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_recommendation_builder.htm&type=5) ## AIUsecaseDefinition Represents a collection of fields in a Salesforce org used to define a machine learning use case and get real-time predictions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | All the AIUsecaseDefinition fields | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AIUsecaseDefinition; Component Type in 1GP Package Manager UI: AIUsecaseDefinition **Use Case** AI Usecase Definition lets you ship data that can be used to set up use cases for which you want to generate real-time predictions. This data includes machine learning models and feature extractors required to generate the real-time predictions. **License Requirements:** This feature is available with the CRM Plus license and the use case-related product’s CRM license. **Documentation:** _Industries Common Resources Developer Guide_: [AI Accelerator](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/ai_accelerator.htm); _Salesforce Help_: [AI Accelerator](https://help.salesforce.com/s/articleView?id=ind.ai_accelerator.htm&type=5) ## Analytics Analytics components include analytics applications, dashboards, dataflows, datasets, lenses, recipes, and user XMD. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (Analytics Dataflow only). All other analytics components can’t be updated. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (Analytic snapshot only). Supported in managed 2GP packages only. All other analytics components can’t be removed. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### More Information ## Analytics Dashboard Represents a Tableau Next dashboard. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Template Asset Source Name, Template Source, Version | ### More Information **Feature Name:** Metadata Name: AnalyticsDashboard; Component Type in 1GP Package Manager UI: Analytics Dashboard **License Requirements:** Tableau Next Admin or Tableau Next Analyst permission sets **Documentation:** For more information on Tableau Next dashboards, see [Create Effective Dashboards With Tableau Next](https://help.salesforce.com/s/articleView?id=analytics.tua_create_dashboard.htm) in in _Salesforce Help_.. ## Analytics Visualization Represents a Tableau Next visualization. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Full Name, Is Original, Version | ### More Information **Feature Name:** Metadata Name: AnalyticsVisualization; Component Type in 1GP Package Manager UI: Analytics Visualization **License Requirements:** Tableau Next Admin or Tableau Next Analyst permission sets **Documentation:** For more information on Tableau Next visualizations, see [Build Insightful Visualizations in Tableau Next](https://help.salesforce.com/s/articleView?id=analytics.tua_create_viz.htm) in in _Salesforce Help_.. ## Analytics Workspace Represents a Tableau Next workspace. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AnalyticsWorkspace; Component Type in 1GP Package Manager UI: Analytics Workspace **License Requirements:** Tableau Next Admin or Tableau Next Analyst permission sets **Documentation:** For more information on Tableau Next workspaces, see [Tableau Next Workspaces](https://help.salesforce.com/s/articleView?id=analytics.tua_workspace.htm) in in _Salesforce Help_.. ## Apex Class Represents an Apex Class. An Apex class is a template or blueprint from which Apex objects are created. Classes consist of other classes, user-defined methods, variables, exception types, and static initialization code. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (if not set to `global` access). Supported in both 1GP and 2GP packages. | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | API Version, Code | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexClass; Component Type in 1GP Package Manager UI: Apex Class **Considerations When Packaging** - Any Apex that is included as part of a package must have at least 75% cumulative test coverage. Each trigger must also have some test coverage. When you upload your package to AgentExchange, all tests are run to ensure that they run without errors. In addition, all tests are run when the package is installed in the installer’s org. If any test fails, the installer can decide whether to install the package. - Managed packages receive a unique namespace. This namespace is prepended to your class names, methods, variables, and so on, which helps prevent duplicate names in the installer’s org. - In a single transaction, you can only reference 10 unique namespaces. For example, suppose that you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the first package didn’t access the second package directly, the access occurs in the same transaction. It’s therefore included in the number of namespaces accessed in a single transaction. - If you’re exposing any methods as Web services, include detailed documentation so that subscribers can write external code that calls your Web service. - If an Apex class references a custom label and that label has translations, explicitly package the individual languages desired to include those translations in the package. - If you reference a custom object’s sharing object (such as MyCustomObject\_\_share) in Apex, you add a sharing model dependency to your package. Set the default org-wide access level for the custom object to Private so other orgs can install your package successfully. - The code contained in an Apex class, trigger, or Visualforce component that’s part of a managed package is obfuscated and can’t be viewed in an installing org. The only exceptions are methods declared as global. You can view global method signatures in an installing org. In addition, License Management Org users with the View and Debug Managed Apex permission can view their packages’ obfuscated Apex classes when logged in to subscriber orgs via the Subscriber Support Console. - You can use the `deprecated` annotation in Apex to identify `global` methods, classes, exceptions, enums, interfaces, and variables that can’t be referenced in later releases of a managed package. So you can refactor code in managed packages as the requirements evolve. After you create another package version as Managed - Released, new subscribers that install the latest package version can’t see the deprecated elements, while the elements continue to function for existing subscribers and API integrations. - Apex code that refers to Data Categories can’t be uploaded. - Before deleting Visualforce pages or global Visualforce components from your package, remove all references to public Apex classes and public Visualforce components. After removing the references, upgrade your subscribers to an interim package version before you delete the page or global component. **Usage Limits** The maximum number of class and trigger code units in a deployment of Apex is 7500. For more information, see [Execution Governors and Limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) in the in the _Apex Developer Guide_. . **Documentation:** _Second-Generation Managed Packaging Developer Guide:_ [Namespace-Based Visibility for Apex Classes in Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_namespace_visibility.htm); _First-Generation Managed Packaging Developer Guide:_ [About API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/about_client_security_profile.htm); _First-Generation Managed Packaging Developer Guide:_[Using Apex in Group and Professional Editions](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/dev_packages_apex_ge_pe.htm) ## Apex Sharing Reason Represents an Apex sharing reason, which is used to indicate why sharing was implemented for a custom object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------ | | Only Package Developer Can Edit | Reason Label | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Reason Name | ### More Information **Feature Name:** Metadata Name: SharingReason; Component Type in 1GP Package Manager UI: Apex Sharing Reason **Considerations When Packaging:** Apex sharing reasons can be added directly to a package, but are only available for custom objects. **Documentation:** _Metadata API Developer Guide_: [SharingReason](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_apexsharingreason.htm) ## Apex Trigger Represents an Apex trigger. A trigger is Apex code that executes before or after specific data manipulation language (DML) events occur, such as before object records are inserted into the database, or after records have been deleted. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | API Version, Code | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexTrigger; Component Type in 1GP Package Manager UI: Apex Trigger **Documentation:** _Apex Developer Guide:_ [Triggers](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers.htm) ## App Framework Template Bundle Represents the app framework template bundle. Use these templates for Data Cloud and Tableau Next assets. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Label, MaxAppCount | | Both Package Developer and Subscriber Can Edit | Description, TemplateBadgeIcon | | Neither Package Developer or Subscriber Can Edit | AssetVerion, TemplateType | ### More Information **Feature Name:** Metadata Name: AppFrameworkTemplateBundle; Component Type in 1GP Package Manager UI: App Framework Template Bundle **Considerations When Packaging** Data Cloud and Tableau Next assets are installed in subscriber orgs via templates using the AppFrameworkTemplateBundle. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. **License Requirements:** Tableau Included App Manager permission set ## Application Subtype Definition Represents a subtype of an application within an application domain. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Developer Name, Description, Application Usage Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ApplicationSubtypeDefinition **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentSubtypeDefinition**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/tooling_api_objects_applicationsubtypedefinition.htm) ## AssessmentConfiguration Represents a configuration for Assessment component. An AssessmentConfiguration entry indicates configuration for user flows such as sending out emails or reminder actions on assessments initiated by the patient. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in managed 1GP packages only. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentConfiguration; Component Type in 1GP Package Manager UI: AssessmentConfiguration **Documentation:** _Health Cloud Developer Guide:_ [AssessmentConfiguration](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_assessmentconfiguration.htm) ## AssessmentQuestion Represents the container object that stores the questions required for an assessment. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | All except DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentQuestion **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentQuestion**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_assessmentquestion.htm) ## AssessmentQuestionSet Represents the container object for Assessment Questions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | All except DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentQuestionSet **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentQuestionSet**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_assessmentquestionset.htm) ## Aura Component Represents an Aura definition bundle. A bundle contains an Aura definition, such as an Aura component, and its related resources, such as a JavaScript controller. The definition can be a component, application, event, interface, or a tokens collection. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. You can build Lightning components using two programming models: the Lightning Web Components model, and the original Aura Components model. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | When a package developer removes an Aura or Lightning web component from a package, the component remains in a subscriber’s org after they install the upgraded package. The administrator of the subscriber’s org can delete the component, if desired. This behavior is the same for a Lightning web component or an Aura component with a `public` or `global` access value. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Aura Component:** Metadata Name: AuraDefinitionBundle; Component Type in 1GP Package Manager UI: Aura Component Bundle **Documentation:** [Lightning Aura Components Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/) ## Batch Calc Job Definition Represents a Data Processing Engine definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | Entire Data Processing Engine definition | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BatchCalcJobDefinition; Component Type in 1GP Package Manager UI: Batch Calculation Job Definition **Use Case** Data Processing Engine helps you transform data that's available in your Salesforce org and write back the transformation results as new or updated records. You can transform the data for standard and custom objects using Data Processing Engine definitions. **License Requirements:** Either Financial Services Cloud, Manufacturing Cloud, Loyalty Management, Net Zero Cloud, or Rebate Management; Data Pipelines **Documentation:** _Salesforce Help:_ [Data Processing Engine](https://help.salesforce.com/s/articleView?id=ind.dpe_intro.htm&type=5) ## Batch Process Job Definition Represents the details of a Batch Management job definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------- | | Only Package Developer Can Edit | Entire Batch Management job | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BatchProcessJobDefinition; Component Type in 1GP Package Manager UI: Batch Process Job Definition **Use Case** Automate the processing of records in scheduled flows with Batch Management. With Batch Management, you can process a high volume of standard and custom object records. **License Requirements:** Either Loyalty Management, Manufacturing Cloud, or Rebate Management; System Administrator Profile **Documentation:** _Salesforce Help:_ [Batch Management](https://help.salesforce.com/s/articleView?id=ind.concept_batch_management.htm&type=5) ## Benefit Action Represents details of an action that can be triggered for a benefit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Entire Benefit Action record | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BenefitAction; Component Type in 1GP Package Manager UI: Benefit Action **Use Case:** Benefit Actions are actions that can be triggered for a loyalty program benefit. **License Requirements:** Loyalty Management permission set license **Documentation:** _Salesforce Help:_ [Benefit Action](https://help.salesforce.com/s/articleView?id=xcloud.benefit_actions.htm&type=5) ## Bot Template Represents the configuration details for a specific Einstein Bot template, including dialogs and variables. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Bot Dialog Groups, Bot Dialogs, Conversation Context Variables, Conversation Languages, Conversation Definition Goals, Conversation System Dialogs, Conversation Variables, Description, Entry Dialog, Icon, Main Menu Dialog, Label, MlDomain, Rich Content Enabled | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BotTemplate; Component Type in 1GP Package Manager UI: Bot Template **Documentation:** [Salesforce Help: Create an Einstein Bot Template](https://help.salesforce.com/s/articleView?id=service.bots_service_create_new_template.htm&type=5); [Salesforce Help: Create a Template from an Einstein Bot](https://help.salesforce.com/s/articleView?id=service.bots_service_create_template_bot.htm&type=5); [Salesforce Help: Package an Einstein Bot Template](https://help.salesforce.com/s/articleView?id=service.bots_service_create_package_template.htm&type=5); [Metadata API Developer Guide: BotTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_bottemplate.htm) ## Branding Set Represents the definition of a set of branding properties for an Experience Builder site, as defined in the Theme panel in Experience Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------- | | Only Package Developer Can Edit | brandingSetProperty, description, masterLabel, type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BrandingSet **Relationship to Other Components** BrandingSet can’t be added to a package by itself. BrandingSet is included automatically in a package if it’s referenced by another object in the package, such as CommunityThemeDefinition, LightningExperienceTheme, or EmbeddedServiceMenuSettings. **Documentation:** _Salesforce Help_: [Use Branding Sets in Experience Builder](https://help.salesforce.com/s/articleView?id=experience.community_designer_brandsets.htm&type=5) ## Briefcase Definition Represents a briefcase definition. A briefcase makes selected records available for specific users and groups to view when they’re offline in the Salesforce Field Service mobile app for iOS and Android. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------- | | Only Package Developer Can Edit | Entire briefcase | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Full Name | ### More Information **Feature Name:** Metadata Name: BriefcaseDefinition; Component Type in 1GP Package Manager UI: Briefcase Definition **Considerations When Packaging** As a best practice, package Briefcase Definition with IsActive set to false. If you package Briefcase Definition with IsActive set to true, the package installation fails if installing the package exceeds any limits. **Usage Limits** All [Briefcase Builder limits](https://help.salesforce.com/s/articleView?id=xcloud.briefcase_builder_limits_considerations.htm&type=5) apply to a Briefcase Definition package. apply to a Briefcase Definition package. **Relationship to Other Components** After you install the package, assign the briefcase to the application that the briefcase's data is for. **Documentation:** _Salesforce Help:_ [Briefcase Builder](https://help.salesforce.com/s/articleView?id=xcloud.briefcase_builder_overview.htm&type=5) ## Building Energy Intensity Record Type Configuration Represents the setup object that contains the mapping between the Building Energy Intensity Record record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BldgEnrgyIntensityCnfg; Component Type in 1GP Package Manager UI: Building Energy Intensity Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new stationary asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting - Manage Building Energy Intensity **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Benchmark Building Energy Intensity Data](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_manage_bei.htm&type=5) ## Business Process The BusinessProcess metadata type enables you to display different picklist values for users based on their profile. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BusinessProcess **Use Case:** You can use this component to define different picklist values that you associate with record types. **Relationship to Other Components:** Record types of corresponding entities. **Documentation:** _Salesforce Help:_ [Tailor Business Processes to Different Users Using Record Types](https://help.salesforce.com/s/articleView?id=platform.customize_recordtype.htm&type=5) ## Business Process Group Represents the surveys used to track customers’ experiences across different stages in their lifecycle. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | All Business Process Group fields including Business Process Definition and Business Process Feedback. | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Developer Name, Customer Satisfaction Metric | ### More Information **Feature Name:** Metadata Name: BusinessProcessGroup; Component Type in 1GP Package Manager UI: Business Process Group **Use Case** Business Process Group lets you ship groupings relevant to survey metrics that are captured as part of any purchase or product lifecycle. For a specific business process group, you can define different stages and associate relevant questions from one or more surveys for reporting purposes. **License Requirements:** This feature is available with the Feedback Management - Growth license. **Relationship to Other Components:** This feature can be used in conjunction with Surveys and Survey Invitation Rules Flow types, and their corresponding dependencies. **Documentation:** _Metadata API Developer Guide_: [BusinessProcessGroup](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_businessprocessgroup.htm); _Salesforce Help_: [Track Satisfaction Across a Customer's Lifecycle](https://help.salesforce.com/s/articleView?id=xcloud.task_customer_lifecycle_maps.htm&type=5) ## Business Process Type Definition Define the types of business processes that are applied to a rule. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Developer Name, Description, Application Usage Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BusinessProcessTypeDefinition ## Care Benefit Verify Settings Represents the configuration settings for benefit verification requests. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, ServiceApexClass, ServiceNamedCredential, UriPath, isDefault, GeneralPlanServiceTypeCode, ServiceTypeSourceSystem, OrganizationName, DefaultNpi, CodeSetType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareBenefitVerifySettings; Component Type in 1GP Package Manager UI: Care Benefit Verification Settings **Use Case:** Provides out-of-the-box configuration settings for benefit verification requests in Health Cloud. **License Requirements:** Industries Health Cloud **Relationship to Other Components:** CareBenefitVerifySettings can contain ApexClass as well as NamedCredentials. **Documentation:** _Health Cloud Developer Guide_: [CareBenefitVerifySettings](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carebenefitverifysettings.htm) ## Care Limit Type Defines the characteristics of limits on benefit provision. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | LimitType, MetricType, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareLimitType; Component Type in 1GP Package Manager UI: Care Limit Type **Use Case:** Provide the characteristics of limits on benefit provision in Health Cloud. **License Requirements:** Industries Health Cloud Add On or an org with a Health Cloud Financial Data Platform license **Documentation:** _Health Cloud Developer Guide_: [CareLimitType](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carelimittype.htm) ## Care Request Configuration Represents the details for a record type such as service request, drug request, or admission request. One or more record types can be associated with a care request. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, CareRequestType, CareRequestRecordType, CareRequestRecords, IsDefaultRecordType | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareRequestConfiguration; Component Type in 1GP Package Manager UI: Care Request Configuration **Use Case:** Provides the details for a record type such as a service request, drug request, or admission request in Health Cloud. **License Requirements:** Industries Health Cloud Add On an org with a Health Cloud Utilization Mgmt Platform license **Relationship to Other Components** Ensure that the record type specified in the Case Record Type field in CareRequestConfiguration is available in the subscriber org. Otherwise, the package must include the record type. **Documentation:** _Health Cloud Developer Guide_: [CareRequestConfiguration](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carerequestconfiguration.htm) ## Care System Field Mapping Represents a mapping from source system fields to Salesforce target entities and attributes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------- | | Only Package Developer Can Edit | External ID Field, Is Active, Label, Source System, Target Object | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareSystemFieldMapping; Component Type in 1GP Package Manager UI: Care System Field Mapping **Use Case:** Provides an out-of-the-box mapping for an external system to Salesforce for the Care Program Enrollment or Remote Monitoring features in Health Cloud. **License Requirements:** Industries Health Cloud **Documentation:** _Health Cloud Developer Guide_: [CareSystemFieldMapping](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/sforce_api_objects_caresystemfieldmapping.htm) ## Channel Layout Represents the metadata associated with a communication channel layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ChannelLayout; Component Type in 1GP Package Manager UI: Communication Channel Layout **Considerations When Packaging:** ChannelLayout can only be installed in Salesforce Classic orgs with Knowledge enabled.; ChannelLayout includes the article type `*__kav`, which is not supported by Lightning Knowledge., which is not supported by Lightning Knowledge.; If you try to install ChannelLayout into an org with Lightning Knowledge enabled, this message is displayed: “When Lightning Knowledge is enabled, you can’t add an article type”. **License Requirements:** Enable Knowledge in Salesforce Classic orgs. **Documentation:** [Salesforce Knowledge Developer Guide: ChannelLayout](https://developer.salesforce.com/docs/atlas.en-us.knowledge_dev.meta/knowledge_dev/meta_articletype_channellayout.htm) ## Chatter Extension Represents the metadata used to describe a Rich Publisher App that’s integrated with the Chatter publisher. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | Description, Header Text, Hover Text, Icon, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Composition CMP, Render CMP, Type | ### More Information **Feature Name:** Metadata Name: ChatterExtension **Documentation:** _Metadata API Developer Guide:_ [ChatterExtension](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_chatterextensions.htm); _Object Reference for the Salesforce Platform:_ [ChatterExtension](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_chatterextension.htm) ## Claim Financial Settings Represents the configuration settings for Insurance Claim Financial Services. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Claim Coverage Pending Authority Status, Claim Coverage Payment Detail Pending Authority Status, Claim Pending Authority Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ClaimFinancialSettings **Documentation:** _Salesforce Help:_ [Claim Financial Settings](https://help.salesforce.com/s/articleView?id=ind.insurance_finauth_claim_financial_settings.htm) ## CommunicationChannelType Represents the type of communication channel, such as WhatsApp and SMS, to use for referral promotions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: CommunicationChannelType **Use Case:** Use WhatsApp as a communication channel for referral promotions. **License Requirements:** Referral Marketing permission set license **Documentation:** _Salesforce Help:_ [Communication Assets](https://help.salesforce.com/s/articleView?id=mktg.referral_promotion_wizard_step_content.htm&type=5) ## Community Template Definition Represents the definition of an Experience Builder site template. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CommunityTemplateDefinition; Component Type in 1GP Package Manager UI: Lightning Community Template **Use Case:** Share or distribute your Experience Builder site templates. **License Requirements:** Customize Application user permission; Create and Set Up Experiences user permission; View Setup and Configuration user permission **Relationship to Other Components:** If you add CommunityTemplateDefinition to a package, you must also add CommunityThemeDefinition to the package. **Documentation:** _Salesforce Help:_ [Export a Customized Experience Builder Template for a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_template.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Community Theme Definition Represents the definition of a theme for an Experience Builder site. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CommunityThemeDefinition; Component Type in 1GP Package Manager UI: Lightning Community Theme **Use Case:** Share or distribute your Experience Builder site themes. **License Requirements:** Customize Application user permission; Create and Set Up Experiences user permission; View Setup and Configuration user permission **Relationship to Other Components:** CommunityThemeDefinition must contain a BrandingSet.; CommunityThemeDefinition can be added to a package without a CommunityTemplateDefinition, but CommunityTemplateDefinition must contain a CommunityThemeDefinition to be added to a package. **Documentation:** _Salesforce Help:_ [Export a Customized Experience Builder Theme for a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_theme.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Compact Layout Represents the metadata associated with a compact layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CompactLayout; Component Type in 1GP Package Manager UI: Compact Layout **Documentation:** _Metadata API Developer Guide:_ [CompactLayout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_compactlayout.htm) ## Conditional Formatting Ruleset Represents a set of rules that define the style and visibility of conditional field formatting on Dynamic Forms-enabled Lightning page field instances. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Conditional formatting ruleset | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: UiFormatSpecificationSet; Component Type in 1GP Package Manager UI: UI Format Specification Set **Relationship to Other Components:** You can only assign a conditional formatting ruleset to a field on a Dynamic Forms-enabled [Lightning page](#lightning-page).. **Documentation:** _Salesforce Help:_ [Conditional Field Formatting in Lightning App Builder](https://help.salesforce.com/s/articleView?id=platform.conditional_formatting_overview.htm&type=5); _Metadata API Developer Guide:_ [UiFormatSpecificationSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_uiformatspecificationset.htm) ## Connected App Represents a connected app configuration. A connected app enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Access Method, Canvas App URL, Callback URL, Connected App Name, Contact Email, Contact Phone, Description, Icon URL, Info URL, Trusted IP Range, Locations, Logo Image URL, OAuth Scopes | | Both Package Developer and Subscriber Can Edit | ACS URL, Entity ID, IP Relaxation, Mobile Start URL, Permitted Users, Refresh Token Policy, SAML Attributes, Service Provider Certificate, Start URL, Subject Type | | Neither Package Developer or Subscriber Can Edit | API Name, Created Date/By, Consumer Key, Consumer Secret, Installed By, Installed Date, Last Modified Date/By, Version | ### More Information ## Context Definition A context definition defines the relationship between the nodes and the attributes within each node. For efficient data access, users can use nodes and attributes to easily access the relevant data from the mapped data source. Various Salesforce products offer predefined context definitions based on their use case. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component doesn’t contain any active context definitions. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Standard Context Definitions | ### More Information **Feature Name:** Metadata Name: ContextDefinition; Component Type in 1GP Package Manager UI: Context Definition **Documentation:** _Industries Common Resources Developer Guide:_ [Context Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_contextdefinition.htm); _Salesforce Help:_ [Context Service](https://help.salesforce.com/s/articleView?id=ind.context_service_context_definitions.htm&type=5) ## Contract Type A contract type is used to group contracts so that they exhibit similar characteristics. For example, the lifecycle states, the people who access, the templates and clauses used. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Both Package Developer and Subscriber Can Edit | Is Default, Sub Types | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ContractType **Use Case:** Allows admin users to modify Contract Type properties. **License Requirements:** CLM Admin Permission Set (CLM User PSL). **Documentation:** _Salesforce Contracts Developer Guide:_ [ContractType](https://developer.salesforce.com/docs/atlas.en-us.clm_developer_guide.meta/clm_developer_guide/meta_contracttype.htm) ## Conversation Channel Definition Represents the conversation channel definition that’s implemented for Interaction Service for Bring Your Own Channel and Bring Your Own Channel for CCaaS messaging channels. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Connected App, Description, Label, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ConversationChannelDefinition; Component Type in 1GP Package Manager UI: ConversationChannelDefinition **Use Case:** To enable and set up Bring Your Own Channel, integrating third-party messaging services with Salesforce.; To enable and set up Bring Your Own Channel for Contact Center as a Service (CCaaS), integrating a third party CCaaS provider with Salesforce. **License Requirements:** Service Cloud license with Digital Engagement add-on license **Post Install Steps:** Set up and enable Bring Your Own Channel or Bring Your Own Channel for CCaaS. **Relationship to Other Components:** Linked to ConversationVendorInfo. **Documentation:** _Salesforce Developer Documentation:_ [Bring Your Own Channel](https://developer.salesforce.com/docs/service/messaging-partner/overview); _Salesforce Developer Documentation:_ [Bring Your Own Channel for CCaaS](https://developer.salesforce.com/docs/service/messaging-byoc-ccaas/overview); _Salesforce Help:_ [Set Up Bring Your Own Channel](https://help.salesforce.com/s/articleView?id=service.partner_messaging_intro.htm&type=5); _Salesforce Help:_ [Set Up Bring Your Own Channel for CCaaS](https://help.salesforce.com/s/articleView?id=service.byoc_ccaas_setup.htm&type=5) ## Conversation Vendor Info This setup object connects the partner vendor system to the Service Cloud feature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ConversationVendorInfo; Component Type in 1GP Package Manager UI: ConversationVendorInfo **Use Case:** Include information about a Service Cloud Voice implementation. **License Requirements:** Enable Service Cloud Voice in your org. **Documentation:** _Service Cloud Voice for Partner Telephony Developer Guide:_ [ConversationVendorInfo](https://developer.salesforce.com/docs/atlas.en-us.voice_pt_developer_guide.meta/voice_pt_developer_guide/sforce_api_objects_conversationvendorinfo.htm); _Object Reference for the Salesforce Platform:_ [ConversationVendorInfo](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_conversationvendorinfo.htm) ## CORS Allowlist Represents an origin in the CORS allowlist. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Url pattern | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CorsWhitelistOrigin; Component Type in 1GP Package Manager UI: CORS Allowed Origin List **Use Case** Customers can add a URL pattern that includes an HTTPS protocol and a domain name. Including a port number is optional. The wildcard character (\*) is supported only for the second-level domain name, for example, `https://*.example.com`. . **Documentation:** _Salesforce Help:_ [Enable CORS for OAuth Endpoints](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_endpoints_cors.htm&type=5); _Salesforce Help:_ [Configure Salesforce CORS Allowlist](https://help.salesforce.com/s/articleView?id=xcloud.extend_code_cors.htm&type=5) ## CSP Trusted Site Represents a trusted URL. For each CspTrustedSite component, you can specify Content Security Policy (CSP) directives and permissions policy directives. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | context, description, endpointUrl, isActive, isApplicableToConnectSrc, isApplicableToFontSrc, isApplicableToFrameSrc, isApplicableToImgSrc, isApplicableToMediaSrc, isApplicableToStyleSrc | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CspTrustedSite; Component Type in 1GP Package Manager UI: CspTrustedSite **Use Case** The Lightning Component framework uses Content Security Policy ( [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)) to impose restrictions on content. The main objective of CSP is to help prevent cross-site scripting ( ) to impose restrictions on content. The main objective of CSP is to help prevent cross-site scripting ( [XSS](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/%3Chttps://www.owasp.org/index.php/Cross-site_Scripting_(XSS)>)) and other code injection attacks. If your package includes sites or pages that load content from an external (non-Salesforce) server or via a WebSocket connection, add the external server as a CSP trusted site. Each CSP trusted site can apply to Experience Cloud sites, Lightning Experience pages, custom Visualforce pages, or all three. ) and other code injection attacks. If your package includes sites or pages that load content from an external (non-Salesforce) server or via a WebSocket connection, add the external server as a CSP trusted site. Each CSP trusted site can apply to Experience Cloud sites, Lightning Experience pages, custom Visualforce pages, or all three. **Considerations When Packaging** When you include the CspTrustedSite component in a package, the permissions for the third-party APIs and Websocket connections apply to sites and pages across the org. Because this component modifies security, we don’t recommend including CspTrustedSite components in packages. Instead, we recommend that you instruct customers to use the CSP Trusted Sites Setup page or the CSPTrustedSites metadata API type to add the URLs to their allowlist as part of activating your package. If you choose to include CspTrustedSite components in your package, disclose this change prominently in your package documentation to ensure that your customers are aware of the security modification. You can’t load JavaScript resources from a third-party site, even if it’s a CSP Trusted Site. To use a JavaScript library from a third-party site, add it to a static resource, and then add the static resource to your component. After the library is loaded from the static resource, you can use it as normal. CSP isn’t enforced by all browsers. For a list of browsers that enforce CSP, see [caniuse.com](https://caniuse.com). . **Usage Limits** CspTrustedSite components are available in API version 39.0 and later. Multiple properties and enumeration values are available in later API versions. For details, see CspTrustedSite in the _Metadata API Developer Guide_. . For Experience Builder sites, if the HTTP header size is greater than 8 KB, the directives are moved from the CSP header to the `` tag. To avoid errors from infrastructure limits, ensure that the HTTP header size doesn’t exceed 3 KB per context. tag. To avoid errors from infrastructure limits, ensure that the HTTP header size doesn’t exceed 3 KB per context. **Relationship to Other Components:** This component can be used only in conjunction with an Aura or Lightning Web Runtime (LWR) page for an Experience Cloud site, a [Lightning Page](#lightning-page), or a , or a [Visualforce page](#visualforce-page).. **Documentation:** _Salesforce Help:_ [Manage CSP Trusted Sites](https://help.salesforce.com/s/articleView?id=xcloud.security_trusted_urls_manage.htm&type=5); _Metadata API Developer Guide_: [CspTrustedSites](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_csptrustedsite.htm) ## Custom Application Represents a custom application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Show in Lightning Experience (Salesforce Classic only), Selected Items (Lightning Experience only), Utility Bar (Lightning Experience only) | | Both Package Developer and Subscriber Can Edit | All attributes, except App Name and Show in Lightning Experience (Salesforce Classic only), All attributes, except Developer Name, Selected Items, and Utility Bar (Lightning Experience only) | | Neither Package Developer or Subscriber Can Edit | App Name (Salesforce Classic only), Developer Name (Lightning Experience only) | ### More Information **Feature Name:** Metadata Name: CustomApplication **Documentation:** _Metadata API Developer Guide:_ [CustomApplication](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customapplication.htm) ## Custom Button or Link Represents a custom link defined in a home page component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Behavior, Button or Link URL, Content Source, Description, Display Checkboxes, Label, Link Encoding | | Both Package Developer and Subscriber Can Edit | Height, Resizeable, Show Address Bar, Show Menu Bar, Show Scrollbars, Show Status Bar, Show Toolbars, Width, Window Position | | Neither Package Developer or Subscriber Can Edit | Display Type, Name | ### More Information **Feature Name:** Metadata Name: WebLink, CustomPageWebLink **Documentation:** _Salesforce Help:_ [Custom Buttons and Links](https://help.salesforce.com/s/articleView?id=platform.customize_enterprise.htm&type=5) ## Custom Console Components Represents a custom console component (Visualforce page) assigned to a CustomApplication that is marked as a Salesforce console. Custom console components extend the capabilities of Salesforce console apps. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. A package that has a custom console component can only be installed in an org with the Service Cloud license or Sales Console permission enabled. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomApplicationComponent; Component Type in 1GP Package Manager UI: Custom Console Component **Documentation:** _Metadata API Developer Guide:_ [CustomApplicationComponent](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customapplicationcomponent.htm); _Salesforce Help:_ [Create Console Components in Salesforce Classic](https://help.salesforce.com/s/articleView?id=service.console2_components_create_overview.htm&type=5) ## Custom Field on Standard or Custom Object Represents the metadata associated with a field. Use this metadata type to create, update, or delete custom field definitions on standard or custom objects. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Auto-Number Display Format, Decimal Places, Description, Default Value, Field Label, Formula, Length, Lookup Filter, Related List Label, Required, Roll-Up Summary Filter Criteria | | Both Package Developer and Subscriber Can Edit | Chatter Feed Tracking, Help Text, Mask Type, Mask Character, Sharing Setting, Sort Picklist Values, Track Field History | | Neither Package Developer or Subscriber Can Edit | Child Relationship Name, Data Type, External ID, Field Name, Roll-Up Summary Field, Roll-Up Summary Object, Roll-Up Summary Type, Unique | ### More Information - Developers can add required and universally required custom fields to managed packages as long as they have default values. - Auto-number type fields and required fields can’t be added after the object is included in a Managed - Released package. - Subscriber orgs can’t install roll-up summary fields that summarize detail fields set to protected. ## Custom Field on Custom Metadata Type Represents a custom fields on the custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ## Custom Field Display Represents the CustomFieldDisplay view type assigned to product attribute custom fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomFieldDisplay **License Requirements:** A B2B Commerce or D2C Commerce license and access to Commerce objects is required. **Documentation:** _Salesforce Help:_ [Create Attributes for Product Variations in Commerce Cloud](https://help.salesforce.com/s/articleView?id=commerce.comm_config_att_set.htm) ## Custom Help Menu Section Represents the section of the Lightning Experience help menu that the admin added to display custom, org-specific help resources for the org. The custom section contains help resources added by the admin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: CustomHelpMenuSection **Documentation:** _Metadata API Developer Guide:_ [CustomHelpMenuSection](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customhelpmenusection.htm) ## Custom Index Represents an index used to increase the speed of queries. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No. It can only be removed if the associated custom field is removed. | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: CustomIndex; Component Type in 1GP Package Manager UI: Custom Index **Considerations When Packaging:** Subscribers can remove the custom index using Metadata API only. **Documentation:** _Best Practices for Deployments with Large Data Volumes:_ [Indexes](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_indexes.htm) ## Custom Label The CustomLabels metadata type allows you to create custom labels that can be localized for use in different languages, countries, and currencies. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | Category, Short Description, Value | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CustomLabels **Considerations When Packaging** If a label is translated, the language must be explicitly included in the package for the translations to be included in the package. Subscribers can override the default translation for a custom label. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomLabels](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customlabels.htm) ## Custom Metadata Type Records Represents a record of a custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in managed 1GP if protected, and managed 2GP whether protected or not. | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: CustomObject This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. **Usage Limits** Deprecated custom metadata type records count against the subscriber’s org limit. When removing custom metadata type records from a second-generation managed package, encourage subscribers to delete the deprecated records from their org. If the subscriber org reaches their org limit for custom metadata type records, package upgrades that include new custom metadata type records fail. For details see [Custom Metadata and Allocations and Usage Calculations](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_limits.htm&type=5) in in _Salesforce Help_. . **Documentation:** _Salesforce Help:_ [Package Custom Metadata Types and Records](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_package_install.htm&type=5) ## Custom Metadata Type Represents a record of a custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### More Information Second-generation managed packages (2GP) include the fields and records for custom metadata types that you add. You can’t add fields directly to an existing package after the package version is promoted. If you create multiple packages that share a namespace, then layouts and records can be in separate packages. Custom fields on the custom metadata type must be in the same package. You can add fields to a custom metadata type by publishing an extension to the existing package, creating an entity relationship field, and mapping the field to the custom metadata type in your extension. See [Add Custom Metadata Type Fields to Existing Packages](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_add_fields_packages.htm&type=5). This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Custom Notification Type Represents the metadata associated with a custom notification type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------- | | Only Package Developer Can Edit | Desktop, Mobile | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomNotificationType; Component Type in 1GP Package Manager UI: Custom Notification Type **License Requirements:** Database.com editions don’t have permission to access this component. **Usage Limits** You can package up to 500 custom notification types, but keep in mind that subscriber orgs are limited to a total of 500 custom notification types. The subscriber org limit is shared across namespaces. A subscriber org can execute up to 10,000 notification actions per hour. **Documentation:** _Salesforce Help:_ [Create and Send Custom Desktop or Mobile Notifications](https://help.salesforce.com/s/articleView?id=platform.notif_builder_custom.htm&type=5); _Salesforce Help:_ [Considerations for Processes that Send Custom Notifications](https://help.salesforce.com/s/articleView?id=platform.process_limits_customnotification.htm&type=5) ## Custom Object Represents a custom object that stores data unique to an org or an external object that maps to data stored outside an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Label, Plural Label, Record Name, Record Name Display Format, Starts with a Vowel Sound | | Both Package Developer and Subscriber Can Edit | Allow Activities, Allow Reports, Available for Customer Portal, Context-Sensitive Help Setting, Default Sharing Model, Development Status, Enable Divisions, Enhanced Lookup, Grant Access Using Hierarchy, Search Layouts, Track Field History | | Neither Package Developer or Subscriber Can Edit | Object Name, Record Name Data Type | ### More Information **Feature Name:** Metadata Name: CustomObject; Component Type in 1GP Package Manager UI: Custom Object **Considerations When Packaging** If a developer enables the Allow Reports or Allow Activities attributes on a packaged custom object, the subscriber’s org also has these features enabled during a package upgrade. After it’s enabled in a Managed - Released package, the developer and the subscriber can’t disable these attributes. Standard button and link overrides are also packageable. In your extension package, if you want to access history information for custom objects contained in the base package, work with the base package owner to: 1. Enable history tracking in the release org of the base package. 2. Create a new version of the base package. 3. Install the new version of the base package in the release org of the extension package to access the history tracking info. As a best practice, don’t enable history tracking for custom objects contained in the base package directly in the extension package’s release org. Doing so can result in an error when you install the package and when you create patch orgs for the extension package. This component can be marked as protected. For more details, see This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) and and [Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_hide_custom_objects_permissions.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) ## Custom Object Translation This metadata type allows you to translate custom objects for a variety of languages. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All attributes except Description of WorkflowTask, Help of CustomField, PicklistValueTranslation, and MasterLabel of LayoutSection. | | Both Package Developer and Subscriber Can Edit | Description of WorkflowTask, Help of CustomField, PicklistValueTranslation, MasterLabel of LayoutSection | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomObjectTranslation **Relationship to Other Components** When you create a first-generation managed package and add the [Translation](#translation) component, the Custom Object Translation component is automatically added to your package. component, the Custom Object Translation component is automatically added to your package. When you create a second-generation managed package, you must add Custom Object Translation to your package, even if you've already added the Translation component. **Documentation:** _Metadata API Developer Guide:_ [CustomObjectTranslation](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customobjecttranslation.htm) ## Custom Permission Represents a permission that grants access to a custom feature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Connected App, Description, Label, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomPermission; Component Type in 1GP Package Manager UI: Custom Permission **Considerations When Packaging** If you deploy a change set with a custom permission that includes a connected app, the connected app must already be installed in the destination org. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) and and [Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_hide_custom_objects_permissions.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomPermission](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_custompermission.htm) ## Custom Tab Represents a custom tab. Custom tabs let you display custom object data or other web content in Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Encoding, Has Sidebar, Height, Label, S-control, Splash Page Custom Link, Type, URL, Width | | Both Package Developer and Subscriber Can Edit | Tab Style | | Neither Package Developer or Subscriber Can Edit | Tab Name | ### More Information **Feature Name:** Metadata Name: CustomTab **Considerations When Packaging** - The tab style for a custom tab must be unique within your app. However, it doesn’t have to be unique within the org where it’s installed. A custom tab style doesn’t conflict with an existing custom tab in the installer’s environment. - To provide custom tab names in different languages, from Setup, in the Quick Find box, enter `Rename Tabs and Labels`, then select **Rename Tabs and Labels**. **Documentation:** _Metadata API Developer Guide:_ [CustomTab](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_tab.htm) ## Dashboard Represents a dashboard. Dashboards are visual representations of data that allow you to see key metrics and performance at a glance. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Dashboard Unique Name | | Neither Package Developer or Subscriber Can Edit | Dashboard Unique Name | ### More Information **Feature Name:** Metadata Name: Dashboard; Type in 1GP Package Manager UI: Dashboard **Considerations When Packaging** Developers of managed packages must consider the implications of introducing dashboard components that reference reports released in a previous version of the package. If the subscriber deleted the report or moved the report to a personal folder, the dashboard component referencing the report is dropped during the installation. Also, if the subscriber has modified the report, the report results can impact what displays in the dashboard component. As a best practice, release a dashboard and the related reports in the same version. **Documentation:** _Metadata API Developer Guide:_ [Dashboard](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_dashboard.htm) ## DataCalcInsightTemplate Represents the object template for data calculations and insights of Data Cloud objects in DataCalcInsightTemplate. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataCalcInsightTemplate; Component Type in 1GP Package Manager UI: Calculated Insight Template **Use Case:** DataCalcInsightTemplate represents the data calculations and insights for objects of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. A calculated insight template is added to a package when you add a data calculation and insight into a data kit, and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Calculated Insight Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datacal_insight_template.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataCleanRoomProvider Represents a clean room provider configuration that defines the clean room collaboration details, including templates and the platform used for secure data collaboration in Data 360. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------- | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer nor Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataCleanRoomProvider; Component Type in 2GP Package Manager UI: Data Kit Package Definition **Use Case** Clean room providers (Partners and ISVs) include DataCleanRoomProvider in a DataKit which can be added to a managed package to offer clean room collaboration templates to consumers via AgentExchange. Consumers install the package to initiate a collaboration with the provider using pre-defined use case templates. **Considerations When Packaging** - Providers need a Data Cloud Developer edition org to create and publish a clean room package. - The package name must be unique. The UI may not display a clear error for duplicate package names. If you encounter an issue, check your browser’s Network tab for the specific conflict error. - The provider logo URL must be a publicly accessible URL in an appropriate image format (such as .png). If the URL is not accessible externally, the UI falls back to a standard icon on the Collaboration Summary screen for consumers. - Data 360 clean rooms don't support cross-geo collaboration (for example, AMER to APAC or EMEA is not supported). Cross-region collaboration within the same geo is supported. - This feature is not available in Government Cloud. **License Requirements** Clean room providers need a Data Cloud license and a Developer edition to create the package. Clean room consumers require a Data Cloud license to install and deploy the package. **Post Install Steps** After installing a package that contains DataCleanRoomProvider, the consumer must manually deploy the data kit components in Data Cloud Setup. See [Deploy a Clean Room from an AgentExchange Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_deploy_cr_from_appexchange.htm&type=5). . **Relationship to Other Components** To include DataCleanRoomProvider in a managed package, you must add the component to a data kit (DataPackageKitDefinition). Then, add the DataPackageKitDefinition to the managed package. DataCleanRoomProvider requires Data Cloud to Data Cloud (DC to DC) sharing. Providers and consumers using Data 360 must have DC to DC sharing configured. **Documentation:** _Salesforce Help:_ [Clean Rooms](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_clean_rooms.htm&type=5); _Salesforce Help:_ [How a Data 360 Clean Room Works](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_how_clean_room_works.htm&type=5); _Salesforce Help:_ [Create a Clean Room Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_create_clean_room_package.htm&type=5); _Salesforce Help:_ [Publish a Clean Room Package to AgentExchange](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_publish_package_to_appexchange.htm&type=5); _Salesforce Help:_ [Deploy a Clean Room from an AgentExchange Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_deploy_cr_from_appexchange.htm&type=5) ## DataConnector Represents the white-labeled metadata configuration for an external connector in Data 360. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Connector JAR/implementation (InteArtifactResource blob), groupId, connector operations and schema | | Both Package Developer and Subscriber Can Edit | displayName, description, iconName (via Static Resource), connection credentials/named credentials (subscriber supplies auth; these are excluded from the package) | | Neither Package Developer or Subscriber Can Edit | developerName (once promoted), namespace-prefixed identifiers | ### More Information **Feature Name:** Metadata Name: IntegArtifactDef; Component Type in 1GP Package Manager UI: MktDataConnection is the Connector parent type **Use Case** ISV partners can build, package, and distribute custom Data 360 connectors, which extend existing native Data 360 Connector Framework (DCF) connectors via AgentExchange. Partners configure the connector metadata, icon, and localization, then package it as a data kit in a 2GP or 1GP managed package. Customers see the connector in the Data 360 new stream page with a "partner built" indicator. **Considerations When Packaging** - No automatic spidering in 2GP; ISVs must manually include all related components. - One version per connector name per package. Minor or patch versions are upgrades in-place. - Major version changes require a new connector name (e.g., AsanaV2). - Connection credentials are excluded (subscriber must supply post-install). - PACKAGING_DISABLED capability exists. isGlobal=true must be set. **License Requirements:** Data 360 must be provisioned in the subscriber org. **Usage Limits:** The number of connections per connector type can be up to 200. **Post Install Steps** Connection will be INACTIVE post-install. To activate, the subscriber admin must supply the credentials or authenticate, and then manually activate the connection. **Relationship to Other Components** Not a requirement but DataConnector should be used with data stream and activation components. A connector package is typically bundled inside a data kit. If packaging with a flow or data stream, all dependent metadata (for example, the connection or Named Credentials) must be explicitly included. **Documentation:** _Developer Guide:_ [Data 360 Connectors and Integrations](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-thirdparty-connectors.html) ## Data Connector Ingest API Represents the connection information specific to Ingestion API. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataConnectorIngestApi; Component Type in 1GP Package Manager UI: Adding DataStreamDefinition brings in DataConnectorIngestApi for Ingestion API DataStreams. **Use Case:** This component is part of the Ingestion API Data stream metadata that is packaged and installed in subscriber. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Documentation:** _Salesforce Help:_ [Ingestion API](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-ingestion-api.html) ## Data Connector S3 Represents the connection information specific to Amazon S3. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Delimiter, FileNameWildCard, ImportFromDirectory, S3AccessKey, S3BucketName, S3SecretKey | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataConnectorS3 **Use Case:** This includes the bucket details for the S3 connector in Data Cloud. **Considerations When Packaging** To package this component, first add it to a data kit. For more information about data kits, see [Data Kits](https://help.salesforce.com/s/articleView?id=data.c360_a_data_package_kits.htm&type=5) in in _Salesforce Help_. . Credentials are encrypted and need “IsDevInternal” permission for the encryption service. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Documentation:** _Salesforce Help:_[Data Connector S3](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-gcs-connector.html) ## Data Kit Object Dependency Represent the object dependencies and relationships between different objects in Data Kit Object Dependency. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataKitObjectDependency; Component Type in 1GP Package Manager UI: Data Kit Object Dependency **Use Case:** DataKitObjectDependency represents the relationship of objects of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Data Kit Object Dependency](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datakitobjectdependency.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Kit Object Template Represents the object in Data Kit Object Template. This object template is added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataKitObjectTemplate; Component Type in 1GP Package Manager UI: Data Kit Object Dependency **Use Case:** DataKitObjectTemplate represents the objects the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit, and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Data Kit Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datakitobjecttemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataObjectBuildOrgTemplate Represents the output objects of the components the user includes in a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataObjectBuildOrgTemplate; Component Type in 1GP Package Manager UI: DataObjectBuildOrgTemplate **Use Case** Supports extension packages that reference the output of any object. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the data object build org template to a data kit, and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. **Post Install Steps** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Package Kit Definition Represents the top-level Data Kit container definition. Content objects can be added after the Data Kit is defined. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------- | | Only Package Developer Can Edit | description, developerName, isDeployed, isEnabled, masterLabel, versionNumber | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataPackageKitDefinition; Component Type in 1GP Package Manager UI: Data Package Kit Definition **Use Case** Represents the top-level data kit container definition. Content objects can be added after the data kit is defined. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataPackageKitDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datapackagekitdefinition.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Package Kit Object Represents the object in Data Kit Content Object. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------- | | Only Package Developer Can Edit | parentDataPackageKitDefinitionName, referenceObjectName, referenceObjectType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataPackageKitObject; Component Type in 1GP Package Manager UI: Data Package Kit Object **Use Case:** Represents an object in a data kit. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataPackageKitObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datapackagekitobject.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Source Used to represent the system where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | DataSourceStatus, ExternalRecordIdentifier, LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataSource **Use Case:** DataSource gives the lineage information of the datastream. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** Create DataStream using ui-api or the Data Cloud App. **Relationship to Other Components** This isn't a top-level entity. AddDataStreamDefinition or DataKitDefinition to pick up DataSource. **Documentation:** _Salesforce Help:_ [Connection Tasks in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_connection_tasks.htm&type=5) ## Data Source Bundle Definition Represents the bundle of streams that a user adds to a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | dataPlatform, isMultiDeploymentSupported, masterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataSourceBundleDefinition; Component Type in 1GP Package Manager UI: Data Source Bundle Definition **Use Case:** Represents the data stream data sources that a user adds to a data kit. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. A data source bundle definition is added to a package when you add a data stream to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataSourceBundleDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datasourcebundledefinition.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Source Object Represents the object from where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataObjectType, DataSource, ExternalRecordId | ### More Information **Feature Name:** Metadata Name: DataSourceObject **Use Case:** DataSourceObject contains specific information about the source of the data like filename, table names. **Considerations When Packaging:** DataSourceObject pulls in child DataSourceField entity records when packaged with DataKitDefinition. **License Requirements:** Customer 360 Audiences Corporate (cdpPsl) licenses must be available on both package developer org and subscriber org. **Post Install Steps:** Create a DataStream via ui-api or using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition or DataKitDefinition to pick up DataSourceObject. **Documentation:** _Salesforce Help:_ [Connection Tasks in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_connection_tasks.htm&type=5) ## Data Src Data Model Field Map Represents the entity that’s used to store the design-time bundle-level mappings for the data source fields and data model fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------- | | Only Package Developer Can Edit | masterLabel, sourceField, targetField, versionNumber | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataSrcDataModelFieldMap; Component Type in 1GP Package Manager UI: Data Source Data Model Field Mapping **Use Case:** Represents the entity that contains design-time bundle-level mappings for the data source fields and data model fields. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. Data model field mappings are added to a package when you add a data stream and any associated mappings to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataSrcDataModelFieldMap](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datasrcdatamodelfieldmap.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Stream Definition Contains Data Ingestion information such as Connection, API and File retrieval settings. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AreHeadersIncludedInTheFiles, BulkIngest, Description, IsLimitedToNewFiles, IsMissingFileFailure | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataConnectionGCS, DataConnectorType, DataExtractField, DataExtractMethod, DataPlatformDataSetBundle, FileNameWildcard, MktDataLakeObject, MktDataTranObject | ### More Information **Feature Name:** Metadata Name: DataStreamDefinition; Component Type in 1GP Package Manager UI: DataStreamDefinition **Use Case** DataStreamDefinition is the starting point for packaging a Datastream and its mappings. **Considerations When Packaging** Data Cloud admin user can install or upgrade the package. Admin User or Data Aware Specialist User can create Datastreams out of the installed package. **License Requirements** Customer 360 Audiences Corporate (cdpPsl) licenses must be available on both package developer org and subscriber org. CDP Admin User can install,upgrade, or uninstall the package. **Post Install Steps** Create the DataStream via ui-api or using the Data Cloud App. **Documentation:** _Metadata API Developer Guide:_ [DataStreamDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datastreamdefinition.htm) ## Data Stream Template Represents the data stream that a user adds to a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | dataImportRefreshFrequency, dataSourceBundleDefinition, dataSourceObject, objectCategory, refreshFrequency, refreshHours, refreshMode | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataStreamTemplate; Component Type in 1GP Package Manager UI: Data Stream Template **Use Case:** Represents the data stream that a user adds to a data kit. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. A data stream template is added to a package when you add a data stream to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataStreamTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datastreamtemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataWeaveResource Represents the DataWeaveScriptResource class that is generated for all DataWeave scripts. DataWeave scripts can be directly invoked from Apex. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (if not set to `global` access). | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------- | | Only Package Developer Can Edit | API Version, DataWeave Script | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataWeaveResource; Component Type in 1GP Package Manager UI: DataWeaveResource **Use Case:** Include MuleSoft DataWeave scripts to read and parse data from one format, transform it, and export it in a different format directly from Apex. **Considerations When Packaging:** There’s a maximum of 50 DataWeave scripts per org. **Documentation:** _Apex Developer Guide:_ [DataWeave in Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/DataWeaveInApex.htm).. ## Decision Matrix Definition Represents a definition of a decision matrix. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is inactive. | | Subscriber Can Delete Component From Org | Yes. Only if the component is inactive. | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------- | | Only Package Developer Can Edit | Type, GroupKey, SubGroupKey | | Both Package Developer and Subscriber Can Edit | versions | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DecisionMatrixDefinition; Component Type in 1GP Package Manager UI: Decision Matrix Definition **Use Case** Decision matrices are lookup tables that match input values to a matrix row and return the row’s output values. Expression sets and various digital procedures can call decision matrices. Decision matrices accept JSON input from, and return JSON output to the digital processes that call the matrices. Decision matrices are useful for implementing complex rules in a systematic, readable manner. **Documentation:** _Industries Common Resources Developer Guide:_ [Decision Matrix Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_decisionmatrixdefinition.htm); _Salesforce Help:_ [Decision Matrices](https://help.salesforce.com/s/articleView?id=ind.decision_matrices.htm&type=5); _Salesforce Help:_ [Decision Matrix Migration Considerations](https://help.salesforce.com/s/articleView?id=ind.decision_matrix_migration_considerations.htm&type=5) ## Decision Matrix Definition Version Represents a definition of a decision matrix version. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is inactive. | | Subscriber Can Delete Component From Org | Yes. Only if the component is inactive. | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | columns | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DecisionMatrixDefinitionVersion; Component Type in 1GP Package Manager UI: Decision Matrix Definition Version **Post Install Steps** After migrating a decision matrix version, upload the row data to the active version manually. The row data isn’t migrated as part of the migration. **Relationship to Other Components:** A DecisionMatrixDefinitionVersion is a child of DecisionMatrixDefinition, and can’t exist without the parent DecisionMatrixDefinition. **Documentation:** _Industries Common Resources Developer Guide:_ [Decision Matrix Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_decisionmatrixdefinition.htm); _Salesforce Help:_ [Decision Matrices](https://help.salesforce.com/s/articleView?id=ind.decision_matrices.htm&type=5); _Salesforce Help:_ [Decision Matrix Migration Considerations](https://help.salesforce.com/s/articleView?id=ind.decision_matrix_migration_considerations.htm&type=5) ## Decision Table Represents the information about a decision table. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Decision Table | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: DecisionTable; Component Type in 1GP Package Manager UI: Decision Table **Use Case:** Decision tables read business rules and decide the outcome for records in your Salesforce org or for the values that you specify. **License Requirements:** Either Loyalty Management or Rebate Management **Documentation:** _Salesforce Help:_ [Decision Tables](https://help.salesforce.com/s/articleView?id=ind.concept_decision_table.htm&type=5) ## Decision Table Dataset Link Represents the information about a dataset link associated with a decision table. In a dataset link, select an object for whose records, the decision table must provide an outcome. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Dataset Link record | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: DecisionTableDatasetLink **Use Case:** In a dataset link, you can map the decision table’s input fields with fields of different standard or custom objects. **License Requirements:** Either Loyalty Management or Rebate Management **Documentation:** _Salesforce Help:_ [Add Dataset Links to a Decision Table](https://help.salesforce.com/s/articleView?id=ind.task_decision_table_dataset_link.htm&type=5) ## Digital Experience Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------- | | Only Package Developer Can Edit | Content Title, Content Body, Content Folder | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DigitalExperience **Use Case:** To move Digital Experience metadata Content from one org to another **Post Install Steps:** After the package is installed, publish the site to make it available to customers. **Documentation:** _Salesforce Help:_ [CMS Content](https://help.salesforce.com/s/articleView?id=xcloud.community_managed_content_content_creation.htm&type=5) ## Digital Experience Bundle Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Labels, Description, Content | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DigitalExperienceBundle **Use Case** Share or distribute the content of an enhanced workspace in Salesforce CMS, including images, documents, and news articles. In Marketing Cloud, you can package the content of general and marketing workspaces, including landing pages, forms, and emails (and their associated images and branding). **Considerations When Packaging** Enhanced LWR sites are unsupported. In marketing workspaces, the default data graph, personalization recommenders, personalization points, and decisions aren't included in the bundle. If the workspace includes emails with personalized content that’s based on these objects, then: - Any merge field or repeater that uses the default data graph or a personalization recommender from the source org is broken in the target org. - Any dynamic content variations of email components are removed and only the default variations appear in the email. **Post Install Steps:** After the package is installed, publish the workspace content to make it available to customers. **Documentation:** _Salesforce Help:_ [Salesforce CMS](https://help.salesforce.com/s/articleView?id=xcloud.community_managed_content_overview.htm); _Salesforce Help:_ [Marketing Cloud](https://help.salesforce.com/s/articleView?id=products.mktg_main.htm&type=5); _Metadata API Developer Guide:_ [DigitalExperienceBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_digitalexperiencebundle.htm) ## Disclosure Definition Represents information that defines a disclosure type, such as details of the publisher or vendor who created or implemented the report. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureDefinition; Component Type in 1GP Package Manager UI: Disclosure Definition **Use Case:** You can use this component to define a disclosure type, such as details of the publisher or vendor who created or implemented the report. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuredefinition.htm) ## Disclosure Definition Version Represents the version information about the disclosure definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | DisclosureDefinition, Description, IsActive, VersionNumber, OmniScriptCnfgApiName, IsCurrentVersion, DisclosureDefCurrVer | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureDefinitionVersion; Component Type in 1GP Package Manager UI: Disclosure Definition Version **Use Case:** You can use this component to define the version information about the disclosure definition. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureDefinitionVersion](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuredefinitionversion.htm) ## Disclosure Type Represents the types of disclosures that are done by an individual or an organization and the associated metadata. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureType; Component Type in 1GP Package Manager UI: Disclosure Type **Use Case:** You can use this component to create types of disclosures that are done by an individual or an organization. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuretype.htm) ## Discovery AI Model Represents the metadata associated with a model used in Einstein Discovery. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery AI Model Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery AI Model Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryAIModel **Documentation:** _Metadata API Developer Guide:_ [DiscoveryAIModel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoveryaimodel.htm) ## Discovery Goal Represents the metadata associated with an Einstein Discovery prediction definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery Goal Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery Goal Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryGoal **Documentation:** _Metadata API Developer Guide:_ [DiscoveryGoal](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoverygoal.htm) ## Discovery Story Represents the metadata associated with a story used in Einstein Discovery. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery Story Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery Story Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryStory **Documentation:** _Metadata API Developer Guide:_ [DiscoveryStory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoverystory.htm) ## Document Represents a Document. All documents must be in a document folder, such as sampleFolder/TestDocument. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### More Information **Feature Name:** Metadata Name: Document; Component Type in 1GP Package Manager UI: Document **Documentation:** _Metadata API Developer Guide:_ [Document](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_document.htm) ## Document Generation Setting Represents an org's settings for automatic document generation from templates. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Document Template Library Name, Generation Mechanism, Guest Access Named Credential, Label, Preview Type | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: DocumentGenerationSetting **Use Case:** Allows admin users to modify document generation properties. **License Requirements:** DocGen Designer (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [DocumentGenerationSetting](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_documentgenerationsetting.htm) ## Eclair GeoData Represents an Analytics custom map chart. Custom maps are user-defined maps that are uploaded to Analytics and are used just as standard maps are. Custom maps are accessed in Analytics from the list of maps available with the map chart type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Eclair GeoData Unique Name | | Neither Package Developer or Subscriber Can Edit | Eclair GeoData Unique Name | ### More Information **Feature Name:** Metadata Name: EclairGeoData **Documentation:** _Metadata API Developer Guide:_ [EclairGeoData](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_eclairgeodata.htm) ## Email Template (Classic) Use email templates to increase productivity and ensure consistent messaging. Email templates with merge fields let you quickly send emails that include field data from Salesforce records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Email Template Name | | Neither Package Developer or Subscriber Can Edit | Email Template Name | ## Email Template (Lightning) Represents a template for an email, mass email, list email, or Sales Engagement email. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. However, 1GP packages created in Email Template Builder can't be removed. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All attributes | ### More Information These packaging considerations apply to Lightning email templates, including email templates created in Email Template Builder. - For email templates created in Email Template Builder before the Spring ’21 release, attachments aren’t automatically added to the package. Open and resave these templates to turn the attachments into content assets, which are then automatically added to the package. * Enhanced email template folders have these behaviors: - If a package includes an enhanced email template folder, the target organization must have enhanced folders enabled for the deploy to succeed. - If an email template is in a subfolder, adding the root folder to a package doesn’t automatically add the email template to the package. If the email template is in the root folder, it’s automatically added to the package. - You can’t package an email template in the default public and private folders. * For merge fields based on custom fields that are used in the Recipients prefix (for leads and contacts), we add references to those merge fields. If the custom field is renamed, the reference in the template isn’t updated. Edit the custom merge field to use the new field name and update the reference. **note:** An email template created in Email Template Builder can’t be edited after it’s downloaded. To edit the template, clone it. When upgrading a package that has Email Template Builder email templates, only the associated FlexiPage is updated. After downloading the new version of the template, clone it to see the changes. ## Embedded Service Config Represents a setup node for creating an Embedded Service for Web deployment. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EmbeddedServiceConfig **Documentation:** _Metadata API Developer Guide:_ [EmbeddedServiceConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_embeddedserviceconfig.htm); _Salesforce Help:_ [Embedded Chat](https://help.salesforce.com/s/articleView?id=service.snapins_chat_overview.htm&type=5) ## Embedded Service Menu Settings Represents a setup node for creating a channel menu deployment. Channel menus list the ways in which customers can contact your business. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EmbeddedServiceMenuSettings **Documentation:** _Metadata API Developer Guide:_ [EmbeddedServiceMenuSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_embeddedservicemenusettings.htm); _Salesforce Help:_ [Channel Menu Setup](https://help.salesforce.com/s/articleView?id=service.embedded_chat_channel_menu.htm&type=5) ## Enablement Measure Definition Represents an Enablement measure, which specifies the job-related activity that a user performs to complete a milestone or outcome in an Enablement program. A measure identifies a source object and optional related objects, with optional field filters and filter logic, for tracking the activity. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | All but Status and DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnablementMeasureDefinition **Use Case** Include this component in a package with a program if the program has outcomes or milestones. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. For Partner Enablement programs in supported Experience Cloud sites, a [supported Partner Relationship Management (PRM) add-on license](https://help.salesforce.com/s/articleView?id=slack.prm_support_license_template.htm&type=5) is also required. is also required. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** An Enablement measure is used within an Enablement program. Package the Enablement Measure Definition component with the Enablement Program Definition component. Or, package the Enablement Measure Definition component separately. Each measure references a source object and optional related objects. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnablementMeasureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enablementmeasuredefinition.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) ## Enablement Program Definition Represents an Enablement program, which includes exercises and measurable milestones to help users such as sales reps achieve specific outcomes related to your company’s revenue goals. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All but DeveloperName | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnablementProgramDefinition **Use Case** Include this component in a package when you want to move a program from one org to another. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. For Partner Enablement programs in supported Experience Cloud sites, a [supported Partner Relationship Management (PRM) add-on license](https://help.salesforce.com/s/articleView?id=slack.prm_support_license_template.htm&type=5) is also required. is also required. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** An Enablement program can contain other items that are related to other packageable components. Package the Enablement Program Definition component with other appropriate components. - Exercises that reference Digital Experiences content. Package the Digital Experience component. - Exercises that reference assessment surveys. Package the Flow component. - Custom exercise types that reference user-defined content. Package the Learning Item Type and Enablement Program Task Subcategory components. - Measures that track job-related activity using specific objects. Package the Enablement Measure Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnablementMeasureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enablementmeasuredefinition.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) ## Enablement Program Task Subcategory Represents a custom exercise type that an Enablement admin adds to an Enablement program in Program Builder. A custom exercise type also requires a corresponding EnblProgramTaskDefinition record for Program Builder and corresponding LearningItem and LearningItemType records for when users take the exercise in the Guidance Center. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnblProgramTaskSubCategory **Use Case** Include this component in a package with a program if the program has a custom exercise type. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. **important:** Custom exercises aren’t compatible with Partner Enablement programs. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** The Enablement Program Task Subcategory component requires a corresponding Learning Item Type component. Both components are used with custom exercise types in Enablement programs. Package both of these components with an Enablement Program Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnblProgramTaskSubCategory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enblprogramtasksubcategory.htm) - _Metadata API Developer Guide_: [LearningItemType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_learningitemtype.htm) - _Object Reference for the Salesforce Platform_: [EnblProgramTaskDefinition](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_enblprogramtaskdefinition.htm) - _Object Reference for the Salesforce Platform_: [LearningItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_learningitem.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Implement Custom Exercise Types for Enablement Programs](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-custom-exercises-intro.html) ## Entitlement Template Represents an entitlement template. Entitlement templates are predefined terms of customer support that you can quickly add to products. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EntitlementTemplate **Documentation:** _Metadata API Developer Guide:_ [EntitlementTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_entitlementtemplate.htm); _Salesforce Help:_ [Set Up an Entitlement Template](https://help.salesforce.com/s/articleView?id=service.entitlements_setting_up_templates.htm&type=5) ## ESignature Config Using the Electronic Signature Configuration setup, the system admin must define the required configurations to support the e-signature APIs and UI. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Config Type, Config Value, Description, Group Type, Vendor | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ESignatureConfig **Use Case:** Allows users to get the electronic signatures on their documents. **License Requirements:** DocGen Designer (Permission Set License) ## ESignature Envelope Config Using the Electronic Signature Envelope Config the system admin can define the default reminders and expiry for the envelopes submitted for eSignature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Expiration Enabled, Expiration Period, Expiration Warning Period, First Reminder Period, Reminder Enabled, Reminder Interval Period, Target Object Name, Vendor, Vendor Account Identifier, Vendor Default Notification Enabled | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ESignatureEnvelopeConfig **Use Case:** Allows users to get the electronic signatures and notifications on their documents. **License Requirements:** DocGen Designer (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [ESignatureEnvelopeConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_esignatureenvelopeconfig.htm) ## Event Relay Represents an event relay that you can use to send platform events and change data capture events from Salesforce to Amazon EventBridge. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, RelayOption, State | | Neither Package Developer or Subscriber Can Edit | DestinationResourceName, EventChannel, UsageType | ### More Information **Feature Name:** Metadata Name: EventRelayConfig; Component Type in 1GP Package Manager UI: Event Relay **Documentation:** _Metadata API Developer Guide:_ [EventRelayConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_eventrelayconfig.htm) ## Explainability Action Definition Define where the metadata for your Decision Explainer business rules are stored in Public Sector Solutions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Description, Developer Name, Business Process Type, Application Type, Action Log Schema Type, Application Subtype | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityActionDefinition ## Explainability Action Version Define and store versions of the explainability actions used by your Decision Explainer business rules in Public Sector Solutions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Active, Description, Explainability Action Definition | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityActionVersion ## Explainability Message Template Represents information about the template that contains the decision explanation message for a specified expression set step type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Message, Name, Result Type, Default, Expression Set Step Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityMsgTemplate **Documentation:** _Industries Common Resources Developer Guide:_ [ExplainabilityMsgTemplate](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_explainabilitymsgtemplate.htm); _Salesforce Help:_ [Create Explainability Message Templates](https://help.salesforce.com/s/articleView?id=ind.create_explainability_message_templates.htm&type=5) ## Expression Set Definition Represents an expression set definition. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component doesn’t contain any active versions. | | Subscriber Can Delete Component From Org | Yes. Only if the component doesn’t contain any active versions. | | Package Developer Can Remove Component From Package | Yes. Only if the component doesn’t contain any active versions. | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | versions | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetDefinition; Component Type in 1GP Package Manager UI: ExpressionSet Definition **Relationship to Other Components:** To use this component, any expression set version dependencies such as decision matrices, decision tables, object field aliases, and subexpressions must be present in the target org. **Documentation:** _Industries Common Resources Developer Guide:_ [Expression Set Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetdefinition.htm); _Salesforce Help:_ [Expression Set Migration Considerations](https://help.salesforce.com/s/articleView?id=sf.expression_set_migration_considerations.htm&type=5) ## Expression Set Definition Version Represents a definition of an expression set version. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is in an inactive state. | | Subscriber Can Delete Component From Org | Yes. Only if the component is in an inactive state. | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | variables, steps | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetDefinitionVersion; Component Type in 1GP Package Manager UI: Expression Set Definition Version **Relationship to Other Components:** This component can be used only if the ExpressionSetDefinition to which this ExpressionSetDefinitionVersion component belongs is present in the target org.; To use this component, any expression set version dependencies such as decision matrices, decision tables, object field aliases, and subexpressions must be present in the target org. **Documentation:** _Industries Common Resources Developer Guide:_ [Expression Set Definition Version](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetdefinition.htm); _Salesforce Help:_ [Expression Set Migration Considerations](https://help.salesforce.com/s/articleView?id=sf.expression_set_migration_considerations.htm&type=5) ## Expression Set Object Alias Represents information about the alias of the source object that’s used in an expression set. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | mappings.sourceFieldName, mappings.fieldAlias | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | objectApiName, usageType, dataType | ### More Information **Feature Name:** Metadata Name: ExpressionSetObjectAlias; Component Type: Expression Set Object Alias **Use Case** Expression set object aliases allow you to use object fields as variables in expression sets. Aliases are relevant and user-friendly names that are created for underlying source object fields. Field aliases are grouped under an object alias. **Documentation:** _Industries Common Resources Developer Guide:_ [ExpressionSetObjectAlias](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetobjectalias.htm); _Salesforce Help:_ [Object Variables in Expression Sets](https://help.salesforce.com/s/articleView?id=ind.object_variables_in_expression_sets.htm&type=5) ## Expression Set Message Token Represents a token that's used in an explainability message template. The token can be replaced with an expression set version resource that the template is used in. This object is available in API version 59.0 and later. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Master Label, Developer Name, Description | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetMessageToken; Component Type in 1GP Package Manager UI: ExpressionSetMessageToken **Documentation:** _Industries Common Resources Developer Guide:_ [ExpressionSetMessageToken](https://developer.salesforce.com/docs/atlas.en-us.250.0.industries_reference.meta/industries_reference/tooling_api_objects_expressionsetmessagetoken.htm); _Salesforce Help:_ [Create Expression Set Message Tokens](https://help.salesforce.com/s/articleView?id=ind.task_create_expression_set_message_tokens.htm&type=5) ## External Auth Identity Provider Represents the external auth identity provider that obtains OAuth tokens for callouts that use named credentials. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterName, ParameterType, ParameterValue, and SequenceNumber properties have the same editability as the ExternalAuthIdentityProviderParameters they’re included in. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AuthenticationFlow, AuthenticationProtocol, Description, Label | | Both Package Developer and Subscriber Can Edit | ExternalAuthIdentityProviderParameter | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: ExternalAuthIdentityProvider; Component Type in 1GP Package Manager UI: External Auth Identity Provider **Considerations When Packaging** Though external auth identity providers are represented by metadata, the standard Metadata API can’t fully expose and render sensitive information like tokens in plain text. This means that sensitive values such as client secrets aren’t included in packages. Package upgrades delete any additional custom request parameters that subscribers add after installing the package. Alert subscribers that they must recreate custom parameters. Package developers can only create parameters and delete existing parameters. After package installation, subscribers don’t receive updated parameter values from package upgrades. **Relationship to Other Components** A callout to an external system references a named credential, which in turn links to an external credential. For external credentials that use OAuth 2.0 authentication, external auth identity providers obtain the OAuth tokens necessary for outbound callouts. **Documentation:** _Salesforce Help:_ [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [ExternalAuthIdentityProvider](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalauthidentityprovider.htm) ## External Client App Header Represents the header file for an external client application configuration. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalClientApplication **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components** ExternalClientApplication is the header file for an external client app. This defines the basic configurations of the external client app, including whether the external client app can be packaged or if it is developed for local use only. ExtlClntAppGlobalOauthSettings includes sensitive information for the External Client Apps OAuth plugin, like OAuth consumer credentials that can’t be packaged or added to source control. ExtlClntAppOauthSettings includes packageable configurations. All settings are determined by the developer and can’t be edited by the admin. Admin-controlled configurations are called policies and are included in ExtlClntAppOauthConfigurablePolicies. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); _Salesforce Help:_ [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) ## External Client App Notification Settings Represents the settings configuration for the external client app’s notifications plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppNotificationSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components:** ExtlClntAppNotificationSettings contains all of the packageable configurations for the External Client Apps notifications plugin. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); [ExtlClntAppNotificationSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extlclntappnotificationsettings.htm) ## External Client App OAuth Settings Represents the settings configuration for the external client app’s OAuth plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppOauthSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components** External Client App plugins like the OAuth plugin include two types of configurations: settings and policies. All settings are determined by the external client app developer and can’t be edited by the admin for the subscriber org. Admin-controlled configurations are called policies. ExtlClntAppOauthSettings contains all of the packageable configurations for the External Client Apps OAuth plugin. Sensitive information, like OAuth consumer credentials that can’t be packaged or added to source control, are stored in the ExtlClntAppGlobalOauthSettings. Policies are saved in ExtlClntAppOauthConfigurablePolicies, which is not packaged but is generated with default values at runtime. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5) ## External Client App Push Settings Represents the settings configuration for the external client app’s push notification plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppPushSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. To deploy ExtlClntAppPushSettings retrieved from the Dev Hub org, delete androidPushConfig or applePushConfig from the metadata file. **Relationship to Other Components** External Client App plugins like the push notification plugin include two types of configurations: settings and policies. All settings are determined by the external client app developer and can’t be edited by the admin for the subscriber org. Admin-controlled configurations are called policies. ExtlClntAppPushSettings contains all of the packageable configurations for the External Client Apps push notifcation plugin. Sensitive information, like APNS or Firebase consumer credentials that can’t be packaged or added to source control, are stored in the ExtlClntAppApplePushConfig and ExtlClntAppAndroidPushConfig, respectively. Policies are saved in ExtlClntAppSamlConfigurablePolicies, which is not packaged but is generated with default values at runtime. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); [ExtlClntAppPushSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extlclntapppushsettings.htm) ## External Credential Represents the details of how Salesforce authenticates to the external system. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterGroup, ParameterName, ParameterValue, and SequenceNumber properties have the same editability as the ExternalCredentialParameters they’re included in. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Label, AuthenticationProtocol, ExternalCredentialParameters | | Both Package Developer and Subscriber Can Edit | Description, ExternalCredentialParameters | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: ExternalCredential **Considerations When Packaging** Though named and external credentials are represented by metadata, the standard Metadata API can’t fully expose the definition of a credential and render sensitive information like tokens in plain text. This means that packaged named credentials don’t include the access tokens or certificates that are needed to perform authenticated callouts. You can create the external credential’s principal or populate its tokens or certificates in the UI or via the Connect API. In managed 1GP packages, external credentials that use the OAuth 2.0 authentication protocol must reference an authentication provider to capture the details of the authorization endpoint. If you add an external credential that references an authentication provider, the authentication provider is added to the package. See [Authentication Providers](https://help.salesforce.com/s/articleView?id=experience.sso_authentication_providers.htm&type=5) for information on which elements of an authentication provider are and aren’t packageable. In managed 2GP packages, if an external credential uses an authentication provider to capture the details of the authorization endpoint, you can’t include the reference to the authentication provider in the package. If the external credential references an authentication provider, you must recreate the authentication provider in the subscriber org and add it to the external credential. **Post Install Steps** After installing an external credential from a managed or unmanaged package, you must: - Create the external credential’s principal or populate its tokens or certificates in the UI or via the Connect API. - Give permission sets and profiles access to the principals of the external credential. See Enable External Credential Principals. - Reauthenticate to the external system. - For a Named Principal, the admin must go to **Setup \> Named Credential \> External Credential** to authenticate. - For a Per User Principal, each user must go to **My Personal Information \> External Credential** to authenticate. **Relationship to Other Components** ExternalCredential can be added to a package without a NamedCredential, but NamedCredential must be packaged with an ExternalCredential. The named credential defines a callout endpoint and an HTTP transport protocol, while the external credential represents the details of how Salesforce authenticates to an external system via an authentication protocol. Each named credential must be mapped to at least one external credential. **Documentation:** _Salesforce Help:_ [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [ExternalCredential](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalcredential.htm) ## External Data Connector Used to represent the object where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataConConfiguration, DataConnectionStatus, DataConnectorType, DataPlatform, ExternalRecordId | ### More Information **Feature Name:** Metadata Name: ExternalDataConnector; Component Type in 1GP Package Manager UI: Adding DataStreamDefinition or DataKitDefinition brings ExternalDataConnector for S3 data streams. **Use Case:** This component holds reference to Source Data Connector Metadata. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition or DataKitDefinition to pick up this entity. ## External Data Source Represents the metadata associated with an external data source. Create external data sources to manage connection details for integration with data and content that are stored outside your Salesforce org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Type | | Both Package Developer and Subscriber Can Edit | Auth Provider, Certificate, Custom Configuration, Endpoint, Identity Type, OAuth Scope, Password, Protocol, Username | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ExternalDataSource; Component Type in 1GP Package Manager UI: External Data Source **Considerations When Packaging** - After installing an external data source from a managed or unmanaged package, the subscriber must reauthenticate to the external system. - For password authentication, the subscriber must reenter the password in the external data source definition. - For OAuth, the subscriber must update the callback URL in the client configuration for the authentication provider, then reauthenticate by selecting Start Authentication Flow on Save on the external data source. - Certificates aren’t packageable. If you package an external data source that specifies a certificate, make sure that the subscriber org has a valid certificate with the same name. **Documentation:** _Metadata API Developer Guide:_ [ExternalDataSource](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externaldatasource.htm) ## External Data Transport Field Template Represents the definition of a Data Cloud schema field. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------- | | Only Package Developer Can Edit | DataSourceField, ExternalDataTranField, ExternalName, IsDataRequired | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtDataTranFieldTemplate; Component Type in 1GP Package Manager UI: External Data Transport Field Template **Use Case:** ExtDataTranFieldTemplate represents the definition of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [External Data Transport Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extdatatranfieldtemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## External Data Transport Field Use ExternalDataTranField to add a field to the ExternalDataTranObject in your managed packages. ExternalDataTranObject is a Data Cloud schema object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Length, Precision, Scale, IsDataRequired, ExternalName, PrimaryIndexOrder, DateFormat, CreationType, MktDataTranField, Sequence, IsImplicitFilteringRequired, ExtDataTranFieldTemplate, IsCurrencyIsoCode | | Both Package Developer and Subscriber Can Edit | CustomFieldDatatypes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalDataTranField **Use Case:** This component holds reference to ExternalDataTranObject metadata and represents the fields in the ExternalDataTranObject. **License Requirements:** Data Cloud must be provisioned. **Post Install Steps:** You must to create a data stream via ui-api or by using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition to pick up this entity. This entity’s parent is ExternalDataTranObject. **Documentation:** _Metadata API Developer Guide:_ [ExternalDataTranField](https://developer.salesforce.com/docs/atlas.en-us.254.0.api_meta.meta/api_meta/meta_externaldatatranobject.htm#subtype_ExternalDataTranField) ## External Data Transport Object Template Represents the definition of a Data Cloud schema object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------ | | Only Package Developer Can Edit | DataSourceObject, ExternalDataTranObject, ExternalName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtDataTranObjectTemplate; Component Type in 1GP Package Manager UI: External Data Transport Object Template **Use Case:** ExtDataTranObjectTemplate represents the definition of a Data Cloud schema object the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport object template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [External Data Transport Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extdatatranobjecttemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## External Data Transport Object To include a Data Cloud schema object in your managed packages, add ExternalDataTranObject. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AvailabilityStatus, CreationType, MktDataTranObject, ObjectCategory, ExtDataTranObjectTemplate | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalDataTranObject **Use Case** ExternalDataTranObject contains specific schema event information that is used to describe events for ingestion via Data Cloud Ingestion API, Web, and Mobile connectors. This object is related to many child schema fields, ExternalDataTranField. **License Requirements:** Data Cloud must be provisioned. **Post Install Steps:** You must create a data stream via ui-api or by using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition to pick up this entity. This entity’s parent is ExternalDataConnector. **Documentation:** _Data Cloud Integration Guide:_ [Mobile and Web SDK Schema Quick Guide for Data Cloud](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-mobile-web-sdk-schema-quick-guide.html); _Data Cloud Integration Guide:_ [Requirements for Ingestion API Schema File](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-ingestion-api-schema-req.html); _Metadata API Developer Guide:_ [ExternalDataTranObject](https://developer.salesforce.com/docs/atlas.en-us.254.0.api_meta.meta/api_meta/meta_externaldatatranobject.htm) ## External Document Storage Configuration Represents configuration, which admin makes in setup to specify the drive, path, and named credential to be used for storing documents on external drives. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Target Object, Record Type, External Document Storage Identifier, Document Path, Named Credential, Storage Drive Type | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ExternalDocStorageConfig **Use Case:** Represents the configuration that the admin makes in Setup to specify the drive, path, and named credential to be used for storing the documents on external drives. **License Requirements:** Microsoft Word 365 **Documentation:** _Salesforce Help:_ [Configure External Document Storage for Contracts](https://help.salesforce.com/s/articleView?id=ind.sf_contracts_Configure_External_Document_Storage_for_Contracts.htm&type=5) ## External Services Represents the External Service configuration for an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes (If there are no dependencies on the External Services registration and its actions from flows or other features) | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | Description, Label, Schema, Schema URL | | Both Package Developer and Subscriber Can Edit | Named Credential | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalServiceRegistration; Component Type in 1GP Package Manager UI: ExternalServiceRegistration **Considerations When Packaging** Package developers must add named credential components to the External Services registration package. A subscriber can also create a named credential in Salesforce. However, the subscriber must use the same name as the named credential specified in the External Services registration that references it. Create named credentials manually or with Apex. Be sure to add the named credential to a package so that subscriber orgs can install it. When a subscriber org installs a named credential, it can use the Apex callouts generated by the External Services registration process. **Usage Limits:** _Salesforce Help:_ [External Services System Limits](https://help.salesforce.com/s/articleView?id=platform.external_services_schema_def_limits.htm&type=5) **Documentation:** _Metadata API Developer Guide:_ [ExternalServiceRegistration](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalserviceregistration.htm); _Salesforce Help:_ [External Services](https://help.salesforce.com/s/articleView?id=platform.external_services.htm&type=5) ## Feature Parameter Boolean Represents a boolean feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterBoolean; Component Type in 1GP Package Manager UI: Feature Parameter Boolean **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterBoolean](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterboolean.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## Feature Parameter Date Represents a date feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterDate; Component Type in 1GP Package Manager UI: Feature Parameter Date **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterDate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterdate.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## Feature Parameter Integer Represents an integer feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterInteger; Component Type in 1GP Package Manager UI: Feature Parameter Integer **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterInteger](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterinteger.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## Field Set Represents a field set. A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user's first name, middle name, last name, and business title. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------ | | Only Package Developer Can Edit | Description, Label, Available fields | | Both Package Developer and Subscriber Can Edit | Selected fields (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: FieldSet; Component Type in 1GP Package Manager UI: Field Set **Considerations When Packaging** Field sets in installed packages perform different merge behaviors during a package upgrade: | If a package developer: | Then in the package upgrade: | | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Changes a field from **Unavailable** to **Available for the Field Set** or **In the Field Set** | The modified field is placed at the end of the upgraded field set in whichever column it was added to. | | Adds a field | The new field is placed at the end of the upgraded field set in whichever column it was added to. | | Changes a field from **Available for the Field Set** or **In the Field Set** to **Unavailable** | The field is removed from the upgraded field set. | | Changes a field from **In the Field Set** to **Available for the Field Set** (or vice versa) | The change isn’t reflected in the upgraded field set. | **note:** Subscribers aren’t notified of changes to their installed field sets. The developer must notify users of changes to released field sets through the package release notes or other documentation. Merging has the potential to remove fields in your field set. **Documentation:** _Metadata API Developer Guide:_ [FieldSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_fieldset.htm) ## Field Source Target Relationship Stores the relationships between a data model object (DMO) and its fields. For example, the Individual.Id field has a one-to-many relationship (1:M) with the ContactPointEmail.PartyId field. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DeveloperName, MasterLabel, RelationshipCardinality, SourceField, TargetField | | Both Package Developer and Subscriber Can Edit | LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode, Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FieldSrcTrgtRelationship; Component Type in 1GP Package Manager UI: Field Source Target Relationship **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [FieldSrcTrgtRelationship](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_fieldsrctrgtrelationship.htm) ## Flow Represents the metadata associated with a flow. With Flow, you can create an application that navigates users through a series of pages to query and update records in the database. You can also execute logic and provide branching capability based on user input to build dynamic applications. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ----------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | Yes, except a flow that is a template or overridable. | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Entire flow | | Both Package Developer and Subscriber Can Edit | Flow Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | Flow API Name, URL | ### More Information **Feature Name:** Metadata Name: Flow **Use Case:** To repeat a business process automatically such as creating an account when some criteria are met or sending an email every week, build a flow to save time and resources **Considerations When Packaging** - When you upload a package or package version, the active flow version is included. If the flow has no active version, the latest version is packaged. - To update a managed package with a different flow version, activate that version and upload the package again. Or deactivate all versions of the flow, make sure the latest flow version is the one to distribute, and then upload the package. - In a packaging org, you can’t delete a flow after you upload it to a released or beta first-generation managed package. You can only delete a flow version from a packaging org after you upload it to a released or beta first-generation managed package, if: - Salesforce Customer Support activated the Managed Component Deletion permission. - The flow version is not the most recently packaged version of the flow. - The flow version is not active. - The flow version is not the only version. - You can’t delete a flow from an installed package. To remove a packaged flow from your org, deactivate it and then uninstall the package. - If you have multiple versions of a flow installed from multiple unmanaged packages, you can’t remove only one version by uninstalling its package. Uninstalling a package—managed or unmanaged—that contains a single version of the flow removes the entire flow, including all versions. - You can’t include flows in package patches. - An active flow in a package is active after it’s installed. The previous active version of the flow in the destination org is deactivated in favor of the newly installed version. Any in-progress flows based on the now-deactivated version continue to run without interruption but reflect the previous version of the flow. The same behavior is true even if the destination org deactivated the flow. Future active versions of the flow that are packaged activate the flow during package upgrade. - Upgrading a managed package in your org installs a new flow version only if there’s a newer flow version from the developer. After several upgrades, you can end up with multiple flow versions. - A package version can contain only one flow version per flow. If you install a managed package version that contains a flow, only the active flow version is deployed. If the flow has no active version, the latest version is deployed. - If you install a flow from an unmanaged package that has the same name but a different version number as a flow in your org, the newly installed flow becomes the latest version of the existing flow. However, if the packaged flow has the same name and version number as a flow already in your org, the package install fails. You can’t overwrite a flow. - A flow can be modified if it’s deployed in a managed package or between a package developer org and a subscriber org where either org has a namespace and the other doesn’t have a namespace. - Flow Builder can’t open a flow that is installed from a managed package, unless the flow is a template or overridable. - You can’t create a package that contains flows invoked by both managed and unmanaged package pages. As a workaround, create two packages, one for each type of component. For example, suppose that you want to package a customizable flow invoked by a managed package page. Create one unmanaged package with the flow that users can customize. Then create another managed package with the Visualforce page referencing the flow (including namespace) from the first package. - When you translate a flow from a managed package, the flow’s Master Definition Name doesn’t appear on the Translate page or the Override page. To update the translation for the Master Definition Name, edit the flow label and then update the translation from the Translate page. - If any of the following elements are used in a flow, packageable components that they reference aren’t included in the package automatically. To deploy the package successfully, manually add those referenced components to the package. - Post to Chatter - Send Email - Submit for Approval - If a flow references a Lightning component that depends on a CSP Trusted Site, the trusted site isn’t included in the package or change set automatically. **Usage Limits:** _Salesforce Help:_ [General Flow Limits](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5) **Relationship to Other Components:** The associated Flow Definition component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide_: [Flow](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm); _Salesforce Help:_ [Packaging Considerations for Flows](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5); _Salesforce Help:_ [Considerations for Deploying Flows with Packages](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5); _Salesforce DX Developer Guide:_ [Hard-Deleted Components in Unlocked Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_hard_deleted_components.htm) ## Flow Category Represents a list of flows that are grouped by category. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------ | | Only Package Developer Can Edit | label, description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FlowCategory **Use Case:** To reuse flow-based automated processes, group the flows into a flow category, and then add one or more flow categories to a Lightning Bolt Solution. **License Requirements:** Customize Application user permission; View Setup and Configuration user permission **Relationship to Other Components:** You can use FlowCategory only as part of a Lightning Bolt Solution. **Documentation:** _Salesforce Help:_ [Add Flows to a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_flow_category.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Flow Definition Represents the flow definition’s description and active flow version number. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Active Version Number, Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: Flow Definition; Component Type in 1GP Package Manager UI: Flow Definition **Use Case:** Include this component when you use managed 1GP to package flows. **Considerations When Packaging:** [Considerations for Deploying Flows with Packages](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5) **Relationship to Other Components:** The associated Flow component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide:_ [Flow Definition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flowdefinition.htm); _Salesforce Help:_ [Flow Builder](https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5) ## Flow Test Represents the metadata associated with a flow test. Before you activate a record-triggered flow, you can test it to verify its expected results and identify flow run-time failures. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: FlowTest; Component Type in 1GP Package Manager UI: FlowTest **Use Case:** Include this component when you use managed 1GP to package flow tests. **Usage Limits:** _Salesforce Help_: [Considerations for Testing Flows](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_feature_testing.htm&type=5) **Relationship to Other Components:** The associated Flow component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide_: [Flow Test](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flowtest.htm); _Salesforce Help:_ [Testing Your Flow](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_testing.htm&type=5) ## Folder Represents a folder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Folder Unique Name | | Neither Package Developer or Subscriber Can Edit | Folder Unique Name | ### More Information - Five different folder metadata types can be packaged: - DashboardFolder - DocumentFolder - EmailFolder (available for Salesforce Classic email templates only) - EmailTemplateFolder - ReportFolder - Components that Salesforce stores in folders, such as documents, can’t be added to packages when stored in personal and unfiled folders. Put documents, reports, and other components that Salesforce stores in folders in one of your publicly accessible folders. - Components such as documents, email templates, reports, or dashboards are stored in new folders in the installer’s org using the publisher’s folder names. Give these folders names that indicate they’re part of the package. - If a new report, dashboard, document, or email template is installed during an upgrade, and the folder containing the component was deleted by the subscriber, the folder is re-created. Any components in the folder that were previously deleted aren’t restored. - The name of a component contained in a folder must be unique across all folders of the same component type, excluding personal folders. Components contained in a personal folder must be unique within the personal folder only. **Documentation:** _Metadata API Developer Guide:_ [Folder](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_folder.htm) ## Fuel Type Represents a custom fuel type in an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FuelType; Component Type in 1GP Package Manager UI: Fuel Type **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create a Custom Fuel Type](https://help.salesforce.com/s/articleView?language=en_US&id=sf.netzero_admin_create_custom_fuel_type.htm) ## Fuel Type Sustainability Unit of Measure Represents a mapping between the custom fuel types and their corresponding unit of measure (UOM) values defined by a customer in an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FuelTypeSustnUom; Component Type in 1GP Package Manager UI: Fuel Type Sustainability Unit of Measure **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Associate a Custom Fuel Type with a Unit of Measure](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_associate_custom_fuel_type_with_unitofmeasure.htm&type=5) ## Fundraising Config Represents a collection of settings to configure the fundraising product. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | LapsedUnpaidTrxnCount, HouseholdSoftCreditRole, IsHshldSoftCrAutoCrea, InstallmentExtDayCount, DonorMatchingMethod, FailedTransactionCount, ShouldCreateRcrSchdTrxn, ShouldClosePaidRcrCmt | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FundraisingConfig **License Requirements:** Fundraising Access (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [FundraisingConfig](https://developer.salesforce.com/docs/atlas.en-us.nonprofit_cloud.meta/nonprofit_cloud/npc_fundraising_api_objects_fundraisingconfig.htm) ## Gateway Provider Payment Method Type Represents an entity that allows integrators and payment providers to choose an active payment to receive an order's payment data rather than allowing the Salesforce Order Management platform to select a default payment method. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All fields | ### More Information **Feature Name:** Metadata Name: GatewayProviderPaymentMethodType **License Requirements** Salesforce Order Management, B2B Commerce, or B2C Commerce (for B2B2C Commerce) licenses are required. These licenses enable the Payment Platform org permission required to use payments objects. **Documentation:** _Salesforce Help:_ [Processing Payments with Payment Gateways](https://help.salesforce.com/s/articleView?id=sales.blng_payment_gateways.htm&type=5) ## Gen Ai Planner Bundle Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | Capabilities, Description, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: [GenAiPlannerBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiplannerbundle.htm); Component Type in 2GP Package Manager UI: Generative AI Planner Bundle **Use Case** Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm) ## Generative AI Prompt Template Represents a generative AI prompt template, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | Template Active Version | | Both Package Developer and Subscriber Can Edit | Template Description | | Neither Package Developer or Subscriber Can Edit | Prompt Template Name, Prompt Template Version | ### More Information **Feature Name:** Metadata Name: GenAIPromptTemplate; Component Type in 1GP Package Manager UI: Generative AI Prompt Template **Use Case:** To package prompt templates created from Prompt Builder for Generative AI use cases. **Considerations When Packaging:** See [Considerations for Packaging Prompt Templates](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_considerations_packaging.htm).. **License Requirements:** Generative AI SKUs are needed to provision Prompt Builder in the org. **Documentation:** _Metadata API Developer Guide:_ [GenAiPromptTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiprompttemplate.htm) ## Global Picklist Represents the metadata for a global picklist value set, which is the set of shared values that custom picklist fields can use. A global value set isn’t a field itself. In contrast, the custom picklist fields that are based on a global picklist are of type ValueSet. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: Global Value Set; Component Type in 1GP Package Manager UI: Global Value Set **Considerations When Packaging** When explicitly referencing a picklist value in code, keep in mind that picklist values for a custom field can be renamed, added, edited, or deleted by subscribers. Picklist field values can be added or deleted in the developer’s org. Changes to standard picklists can’t be packaged and deployed to subscriber orgs, and picklist values deleted by the developer are still available in the subscriber’s org. If there are differences between the package and the target org, or if there are dependencies on new values from features such as PathAssistant, the deploy fails. To change values in subscriber orgs, you must manually add or modify the values in the target subscriber org. Updating picklist values in unlocked packages isn’t supported. Manually add or modify the values in the target subscriber org. Package upgrades retain dependent picklist values that are saved in a managed custom field. Global value sets can be added to developer and subscriber orgs. Global value sets have these behaviors during a package upgrade. - Label and API names for field values don’t change in subscriber orgs. - New field values aren’t added to the subscriber orgs. - Active and inactive value settings in subscriber orgs don’t change. - Default values in subscriber orgs don’t change. - Global value set label names change if the package upgrade includes a global value set label change. When you create a custom global value set in API version 56.0 or later, the developer name is appended with the suffix `__gvs`. . - A global value set created before API version 56.0 doesn’t have the developer name suffix. For example, `myGlobalValueSet`. - A global value set created in API version 56.0 or later automatically has the developer name suffix `__gvs`, and you refer to it using the suffix. For example, `myNewGlobalValueSet__gvs`. If you have a package.xml manifest file that contains global value sets, and you upgrade the package.xml file to API version 56.0, you must add the `__gvs` suffix to all of the global value sets in the file. You can do a new package retrieve in API version 56.0 to get all the global value set names. Your package.xml file looks like this XML. ```xml gvs1 GlobalValueSet gvs2 GlobalValueSet 55.0 ``` To upgrade the file to API version 56.0, the file looks like this XML. ```xml gvs1__gvs GlobalValueSet gvs2__gvs GlobalValueSet 56.0 ``` **Documentation:** _Salesforce Help:_ [Create a Global Picklist Value Set](https://help.salesforce.com/s/articleView?id=platform.fields_creating_global_picklists.htm&type=5); _Salesforce Help:_ [Make Your Custom Picklist Field Values Global](https://help.salesforce.com/s/articleView?id=platform.fields_promote_picklists.htm&type=5) ## Home Page Component Represents the metadata associated with a home page component. You can customize the Home tab in Salesforce Classic to include components such as sidebar links, a company logo, a dashboard snapshot, or custom components that you create. Use to create, update, or delete home page component definitions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | Body, Component Position | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name, Type | ### More Information **Feature Name:** Metadata Name: HomePageComponent; Component Type in 1GP Package Manager UI: Home Page Component **Relationship to Other Components** When you package a custom home page layout, all the custom home page components included on the page layout are automatically added. Standard components such as Messages & Alerts aren’t included in the package and don’t overwrite the installer’s Messages & Alerts. To include a message in your custom home page layout, create an HTML Area type custom Home tab component containing your message. From Setup, in the Quick Find box, enter `Home Page Components`, then select **Home Page Components**. Then add the message to your custom home page layout. **Documentation:** _Metadata API Developer Guide:_ [HomePageComponent](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_homepagecomponent.htm) ## Home Page Layout Represents the metadata associated with a home page layout. You can customize home page layouts and assign the layouts to users based on their user profile. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Layout Name | | Neither Package Developer or Subscriber Can Edit | Layout Name | ### More Information **Feature Name:** Metadata Name: HomePageLayout; Component Type in 1GP Package Manager UI: Home Page Layout **Considerations When Packaging** After they’re installed, your custom home page layouts are listed with all the subscriber’s home page layouts. Distinguish them by including the name of your app in the page layout name. **Documentation:** _Metadata API Developer Guide:_ [HomePageLayout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_homepagelayouts.htm) ## Identity Verification Proc Def Represents the definition of the identity verification process. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------- | | Only Package Developer Can Edit | MasterLabel, SearchLayoutType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: IdentityVerificationProcDef; Component Type in 1GP Package Manager UI: Identity Verification Process Definition **Use Case:** Links the configuration for Identity Verification to a flow. **License Requirements:** Industries Health Cloud, Industries Sales Excellence, and Industries Service Excellence licenses.; Actionable Segmentation Engagement, Industries Sales Excellence, Industry Service Excellence or Health Cloud Platform Permission set license is required to use this metadata type. **Relationship to Other Components:** An Identity Verification Process Field record looks up to an Identity Verification Process Details record, which in turn looks up to an Identity Verification Process Definition record. **Documentation:** _Health Cloud Developer Guide_: [IdentityVerificationProcDef](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/meta_identityverificationprocdef.htm) ## Inbound Network Connection Represents a private connection between a third-party data service and a Salesforce org. The connection is inbound because the callouts are coming into Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | You can only delete connections that are in an unprovisioned state. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AWS VPC Endpoint ID, Connection Type, Developer Name, Description, Link ID, Master Label, Region, Source IP Ranges | | Both Package Developer and Subscriber Can Edit | Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: InboundNetworkConnection; Component Type in 1GP Package Manager UI: Inbound Network Connection **Considerations When Packaging** - Packaged connections are installed as unprovisioned. Alert subscribers about how to provision connections after package installation. - If a developer changes the Region of a packaged connection that is subscriber-provisioned, the upgrade fails for the subscriber. Alert subscribers about tearing down the connection before updating the Region field. As a best practice, avoid changing the Region of a packaged connection unless necessary. **License Requirements:** This feature is available with the Private Connect license. **Documentation:** _Salesforce Help:_ [Secure Cross-Cloud Integrations with Private Connect](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5); _Salesforce Help:_ [Establish an Inbound Connection with AWS](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_inbound_aws.htm&type=5) ## IntegrationProviderDef Represents an integration definition associated with a service process. Stores data for the Industries: Send Apex Async Request and Industries: Send External Async Request invocable actions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | StringValue, IntegerValue, DateTimeValue, DateValue, PercentageValue, DoubleValue, IsTrueOrFalseValue | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **IntegrationProviderDef:** Metadata Name: IntegrationProviderDef; Component Type in 1GP Package Manager UI: IntegrationProviderDef **Documentation:** [IntegrationProviderDef](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_integrationproviderdef.htm) in _Metadata API Developer Guide_. ## LearningAchievementConfig Represents the mapping details between a Learning Achievement type and a Learning Achievement record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: LearningAchievementConfig **Documentation:** Education Cloud Developer Guide **See Also** - [https://developer.salesforce.com/docs/atlas.en-us.edu_cloud_dev_guide.meta/edu_cloud_dev_guide/sforce_api_objects_learningachievementconfig.htm](https://developer.salesforce.com/docs/atlas.en-us.edu_cloud_dev_guide.meta/edu_cloud_dev_guide/sforce_api_objects_learningachievementconfig.htm) ## Learning Item Type Represents a custom exercise type that an Enablement user takes in an Enablement program in the Guidance Center. A custom exercise type also requires a corresponding LearningItem record for the Guidance Center and corresponding EnblProgramTaskDefinition and EnblProgramTaskSubCategory records for when admins create a program in Program Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: LearningItemType **Use Case** Include this component in a package with a program if the program has a custom exercise type. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. **important:** Custom exercises aren’t compatible with Partner Enablement programs. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** The Learning Item Type component requires a corresponding Enablement Program Task Subcategory component. Both components are used with custom exercise types in Enablement programs. Package both of these components with an Enablement Program Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnblProgramTaskSubCategory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enblprogramtasksubcategory.htm) - _Metadata API Developer Guide_: [LearningItemType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_learningitemtype.htm) - _Object Reference for the Salesforce Platform_: [EnblProgramTaskDefinition](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_enblprogramtaskdefinition.htm) - _Object Reference for the Salesforce Platform_: [LearningItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_learningitem.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Implement Custom Exercise Types for Enablement Programs](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-custom-exercises-intro.html) ## Letterhead Represents formatting options for the letterhead in an email template. A letterhead defines the logo, page color, and text settings for your HTML email templates. Use letterheads to ensure a consistent look and feel in your company’s emails. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Letterhead Name | | Neither Package Developer or Subscriber Can Edit | Letterhead Name | ### More Information **Feature Name:** Metadata Name: Letterhead **Documentation:** _Metadata API Developer Guide:_ [Letterhead](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_letterhead.htm) ## Life Science Config Category Represents the category that a Life Sciences configuration record is organized into. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | CategoryLabel, DeveloperName, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | CategoryType | ### More Information **Feature Name:** Metadata Name: LifeSciConfigCategory; Component Type in 1GP Package Manager UI: Life Science Config Category **Considerations When Packaging:** When packaging the LifeSciConfigCategory component, the DeveloperName must match the Category. **License Requirements:** Industries Life Sciences Cloud with the Life Sciences Cloud for Customer Engagement Add-on license and the Life Sciences Customer Engagement managed package. **Relationship to Other Components:** This component defines the category of the configuration defined in a child LifeSciConfigRecord component. **Documentation:** _Life Sciences Cloud Developer Guide_: [LifeSciConfigCategory](https://developer.salesforce.com/docs/atlas.en-us.life_sciences_dev_guide.meta/life_sciences_dev_guide/meta_lifesciconfigcategory.htm) ## Life Science Config Record Represents a configuration record for Life Sciences. This object is a child of Life Science Config Category. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | IsActive, IsOrgLevel, MasterLabel, ParentConfigRecordId, Type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, LifeSciConfigCategoryId | ### More Information **Feature Name:** Metadata Name: LifeSciConfigRecord; Component Type in 1GP Package Manager UI: Life Science Config Record **Use Case:** This component holds the configuration records for Life Sciences Cloud for Customer Engagement application. **Considerations When Packaging** - You must package the LifeSciConfigRecord component with its parent LifeSciConfigCategory component. - The component must be in the inactive state. **License Requirements:** Industries Life Sciences Cloud with the Life Sciences Cloud for Customer Engagement Add-on license and the Life Sciences Customer Engagement managed package. **Post Install Steps:** For the configuration to work, make the component active by setting IsActive to true. **Relationship to Other Components:** A LifeSciConfigRecord is a child of LifeSciConfigCategory, and can’t exist without the parent LifeSciConfigCategory.; A LifeSciConfigRecord is also a parent to LifeSciConfigFieldValue and LifeSciConfigAssignment. **Documentation:** _Life Sciences Cloud Developer Guide_: [LifeSciConfigRecord](https://developer.salesforce.com/docs/atlas.en-us.life_sciences_dev_guide.meta/life_sciences_dev_guide/meta_lifesciconfigrecord.htm) ## Lightning Bolt Represents the definition of a Lightning Bolt Solution, which can include custom apps, flow categories, and Experience Builder templates. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: LightningBolt; Component Type in 1GP Package Manager UI: Lightning Bolt **Documentation:** _Metadata API Developer Guide:_ [LightningBolt](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningbolt.htm) ## Lightning Message Channel Represents the metadata associated with a Lightning Message Channel. A Lightning Message Channel represents a secure channel to communicate across UI technologies, such as Lightning Web Components, Aura Components, and Visualforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: LightningMessageChannel; Component Type in 1GP Package Manager UI: Lightning Message Channel **Considerations When Packaging:** To pass the [AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm), the , the isExposed attribute must be set to attribute must be set to false.. **Documentation:** _Metadata API Developer Guide_: [Lightning Message Channel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningmessagechannel.htm); _Lightning Web Components Developer Guide_: [Create a Message Channel](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_intro) ## Lightning Page Represents the metadata associated with a Lightning page. A Lightning page represents a customizable screen made up of regions containing Lightning components. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | Lightning page | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | **note:** You must have the Manage Prompt Templates permission to successfully package Lightning pages that reference prompt templates. Without this permission, package creation succeeds, but the prompt template isn't included in the package. ### More Information **Feature Name:** Metadata Name: FlexiPage **Documentation:** _Metadata API Developer Guide:_ [Flexipage](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flexipage.htm) ## Lightning Type Represents a custom Lightning type. Use this type to override the default user interface to create a customized appearance based on your business requirements. Deploy this bundle to your organization to implement the overrides. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: LightningTypeBundle; Component Type in 1GP Package Manager UI: Lightning Type **Documentation:** _Metadata API Developer Guide_: [LightningTypeBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningtypebundle.htm) ## Lightning Web Component Represents a Lightning web component bundle. A bundle contains Lightning web component resources. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. You can build Lightning components using two programming models: the Lightning Web Components model, and the original Aura Components model. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | When a package developer removes an Aura or Lightning web component from a package, the component remains in a subscriber’s org after they install the upgraded package. The administrator of the subscriber’s org can delete the component, if desired. This behavior is the same for a Lightning web component or an Aura component with a `public` or `global` access value. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | API Version, Description, isExposed (can only change from false to true), Label, Markup, Targets, targetConfigs, targetConfig, property | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | You can’t make certain changes to `` tags on a custom component that’s used in a managed package or an Experience Builder site. For more information, see [Considerations](https://developer.salesforce.com/docs/platform/lwc/guide/use-config-for-community-builder.html#considerations) for configuring a component for Experience Builder in the _Lightning Web Components Developer Guide_. ### More Information **Lightning Web Component:** Metadata Name: LightningComponentBundle; Component Type in 1GP Package Manager UI: Lightning Web Component (LWC) Bundle **Considerations When Packaging** Licensing Considerations: LWC components don’t automatically enforce managed package licensing. LWC components in a managed package can be seen and used by users who don’t have active licenses for that managed package. These components can also be seen and used after a trial of that managed package expires. AgentExchange partners are responsible for enforcing package licensing in their LWC Components. We recommend using an Apex controller that calls either the [UserInfo.isCurrentUserLicensed(namespace)](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_userinfo.htm#apex_System_UserInfo_isCurrentUserLicensed) or or [UserInfo.isCurrentUserLicensedForPackage(packageID)](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_userinfo.htm#apex_System_UserInfo_isCurrentUserLicensedForPackage) methods, and only rendering the component if methods, and only rendering the component if `true` is returned. is returned. Considerations When Using `isExposed`:: If `isExposed` is false, the package developer can remove configuration targets and a public (@api) property from a component. The component isn't available to other namespaces or to Salesforce builders like Lightning App Builder and Experience Builder. is false, the package developer can remove configuration targets and a public (@api) property from a component. The component isn't available to other namespaces or to Salesforce builders like Lightning App Builder and Experience Builder. If `isExposed` is true and the component is in a published managed package, the package developer can’t remove configuration targets or a public (@api) property from a component. This restriction is enforced even if the target or public property was added after the most recent publication of the package. is true and the component is in a published managed package, the package developer can’t remove configuration targets or a public (@api) property from a component. This restriction is enforced even if the target or public property was added after the most recent publication of the package. If `isExposed` is true, the component is available to other namespaces, including namespaces outside of a published managed package. is true, the component is available to other namespaces, including namespaces outside of a published managed package. If `isExposed` is true and a is true and a Targets value is also provided, the component is available to Salesforce builders such as Lightning App Builder and Experience Builder. value is also provided, the component is available to Salesforce builders such as Lightning App Builder and Experience Builder. When you delete an LWC component with an `isExposed` value of true, we recommend a two-stage process to ensure that the deleted component has no dependencies on the other items in the package. See value of true, we recommend a two-stage process to ensure that the deleted component has no dependencies on the other items in the package. See [Remove Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm) for details. for details. Considerations When Working with LWC Dynamic Imports: When installing a managed package that contains an LWC component with [dynamic imports](https://developer.salesforce.com/docs/platform/lwc/guide/js-dynamic-components.html), , [Lightning Web Security](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-enable.html) must be enabled in your org. must be enabled in your org. **Documentation:** [Lightning Web Components Developer Guide](https://developer.salesforce.com/docs/component-library/documentation/en/lwc); _Lightning Web Components Developer Guide:_ [Add Components to Managed Packages](https://developer.salesforce.com/docs/platform/lwc/guide/use-packaging-add.html); _Lightning Web Components Developer Guide:_ [Delete Components from Managed Packages](https://developer.salesforce.com/docs/platform/lwc/guide/use-packaging-delete.html) ## List View ListView allows you to see a filtered list of records, such as contacts, accounts, or custom objects. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except View Unique Name | | Neither Package Developer or Subscriber Can Edit | View Unique Name | ### More Information **Feature Name:** Metadata Name: ListView; Component Type in 1GP Package Manager UI: List View **Considerations When Packaging** If a subscriber removes a packaged listview from their production org, that listview is deprecated, but not deleted. If that subscriber org later creates a sandbox org, and upgrades the package in the sandbox org, the removed listview persists in the sandbox org. To remove the listview from the sandbox, package subscribers can click ![List View Controls](https://developer.salesforce.com/media/shared/settings_120.png) and select and select **Delete**. . **Relationship to Other Components** List views associated with queues can’t be included in a managed package or an unlocked package. **Documentation:** _Metadata API Developer Guide:_ [ListView](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_listview.htm) ## Live Chat Sensitive Data Rule Represents a rule for masking or deleting data of a specified pattern. Written as a regular expression (regex). Use this object to mask or delete data of specified patterns, such as credit card, social security, or phone and account numbers. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes, Supported in 1GP Packages only | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: LiveChatSensitiveDataRule; Component Type in 1GP Package Manager UI: Sensitive Data Rules **Documentation:** _Metadata API Developer Guide:_ [LiveChatSensitiveDataRule](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_livechatsensitivedatarule.htm) ## Loyalty Program Setup Represents the configuration of a loyalty program process including its parameters and rules. Program processes determine how new transaction journals are processed. When new transaction journals meet the criteria and conditions for a program process, actions that are set up in the process are triggered for the transaction journals. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Loyalty Program Process records | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: LoyaltyProgramSetup; Component Type in 1GP Package Manager UI: Loyalty Program Setup **Use Case:** Promotion setup allows loyalty program managers to create loyalty program processes. **License Requirements:** Loyalty Management permission set license **Documentation:** _Salesforce Help:_ [Create Processes with Promotion Setup](https://help.salesforce.com/s/articleView?id=https://help.salesforce.com/s/articleView?id=xcloud.promotion_setup.htm&type=5) ## Managed Content Type Represents the definition of custom content types for use with Salesforce CMS. Custom content types are displayed as forms with defined fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Content, Description, Labels | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ManagedContentType **Use Case:** Share or distribute custom content types for use in enhanced workspaces in Salesforce CMS. **Considerations When Packaging** Installed content types are available only to enhanced CMS workspaces. To refer to an installed content type when using Connect REST API, you must use the content type’s fully qualified name. Installed content types are available only to enhanced CMS workspace resources. **Documentation:** _Metadata API Developer Guide_: [ManagedContentType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_managedcontenttype.htm); _Connect REST API Developer Guide_: [Enhanced CMS Workspaces Resources](https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_managed_content_enhanced_resources.htm); _CMS Developer Guide_: [Create Custom Content Type Sample](https://developer.salesforce.com/docs/platform/cms/guide/cms-dev-create-custom-content-type-sample.html) ## Marketing App Extension Represents an integration with a third-party app or service that generates prospect external activity. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | DeveloperName, MasterLabel, Description | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MarketingAppExtension; Component Type in 1GP Package Manager UI: Marketing App Extension **Use Case:** Partners and ISVs can provide integrations with third-parties so Account Engagement customers can enhance their automations. **Considerations When Packaging** Marketing app extensions require an associated action type component to function. The related component activity type isn’t supported for packaging. **License Requirements** This feature is available in Plus, Advanced, or Premium editions of Account Engagement. To work with marketing app extensions, users must be a Salesforce admin or have the [required permissions to access Marketing Setup](https://help.salesforce.com/s/articleView?id=mktg.pardot_admin_marketing_admin.htm&type=5). . **Usage Limits** The number of active extensions, activities, and actions the end user can have at one time depends on their edition of Account Engagement. - Plus—10 active extensions, with 10 active activities and 10 active actions per active extension - Advanced—20 active extensions, with 20 active activities and 20 active actions per active extension - Premium—30 active extensions, with 30 active activities and 30 active actions per active extension For more on limits, see For more on limits, see [Considerations for Working with Marketing App Extensions.](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensions_considerations.htm&type=5) **Post Install Steps:** To receive data, the extension must be activated for automations and have a business unit assignment. **Relationship to Other Components:** The extension requires an associated action type component to function. **Documentation** This component is part of Account Engagement’s extensibility feature set. - _Salesforce Help:_ [Automate Data Sharing with Third-Party Apps](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensibility_parent.htm&type=5) - _Developer Guide:_ [Work with Extensibility Features](https://developer.salesforce.com/docs/marketing/pardot/guide/extensibility-features-overview.html) ## Marketing App Extension Activity Represents an Activity Type, which is a prospect activity that occurs in a third-party app and can be used in Account Engagement automations. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, Description | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | DeveloperName, EndpointUrl, MarketingAppExtension | ### More Information **Feature Name:** Metadata Name: MarketingAppExtActivity; Component Type in 1GP Package Manager UI: Marketing App Extension **Use Case:** Partners and ISVs can use Activities to submit external prospect engagement data to Marketing Cloud Account Engagement. **Considerations When Packaging** This component is included when the parent component [MarketingAppExtension](#marketing-app-extension) is added to a package. The related component MarketingAppExtActivity isn’t supported for packaging. is added to a package. The related component MarketingAppExtActivity isn’t supported for packaging. **License Requirements** This feature is available in Plus, Advanced, or Premium editions of Account Engagement. To work with marketing app extensions and related components, users must be a Salesforce admin or have the [required permissions to access Marketing Setup](https://help.salesforce.com/s/articleView?id=mktg.pardot_admin_marketing_admin.htm&type=5). . **Usage Limits** The number of active extensions, activities, and actions the end user can have at one time depends on their edition of Account Engagement. - Plus—10 active activities per active extension - Advanced—20 active activities per active extension - Premium—30 active activities per active extension For more information, see For more information, see [Considerations for Working with Marketing App Extensions.](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensions_considerations.htm&type=5) **Post Install Steps:** To receive data, the activity and its related extension must be activated for automations. **Relationship to Other Components** This component is a child of the [MarketingAppExtension](#marketing-app-extension) component. Activities interact with Marketing Cloud Account Engagement features that support external activities. For more information, see component. Activities interact with Marketing Cloud Account Engagement features that support external activities. For more information, see [Capture External Prospect Activity](https://help.salesforce.com/s/articleView?id=mktg.pardot_external_activity_parent.htm&type=5). . **Documentation** This component is part of Account Engagement’s extensibility feature set. - _Salesforce Help:_ [Automate Data Sharing with Third-Party Apps](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensibility_parent.htm&type=5) - _Developer Guide:_ [Work with Extensibility Features](https://developer.salesforce.com/docs/marketing/pardot/guide/extensibility-features-overview.html) ## Market Segment Definition Represents the field values for MarketSegmentDefinition. MarketSegmentDefinition is used to store the exportable metadata of a segment, such as segment criteria and other attributes. Developers can create segment definition packages, pass segment definition in the form of data build tool (DBT), and publish it on AgentExchange for subscriber organizations to install and instantiate these segments. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------- | | Only Package Developer Can Edit | Yes, applicable for all properties. | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MarketSegmentDefinition; Component Type in 1GP Package Manager UI: Market Segment Definition **Documentation:** [REQUIRED] ## MktCalculatedInsightsObjectDef Represents Calculated Insight definition such as expression. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------- | | Only Package Developer Can Edit | BuilderExpression, CalculatedInsightCreationType, Description, Expression, Label | | Both Package Developer and Subscriber Can Edit | CalculatedInsightObjectDefinitionStatus, Description | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: MktCalcInsightObjectDef; Component Type in 1GP Package Manager UI: MktCalcInsightObjectDef. **Use Case:** Defines CDP calculated insight for easy creation on subscriber organizations. **Considerations When Packaging** To package this component, first add it to a data kit. For more information about data kits, see [Data Kits](https://help.salesforce.com/s/articleView?id=data.c360_a_data_package_kits.htm&type=5) in in _Salesforce Help_. . **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps** User has to go to the **Calculated Insights** object home in Customer Data Platform, click object home in Customer Data Platform, click **New action** and select and select **Create from a Package**. . **Relationship to Other Components** Calculated Insight Component is tied to the Data Model Object component. The Calculated Insight component must have Data Model Object dependencies available on the subscriber organization that are used in the Calculated Insight. **Documentation:** _Metadata API Developer Guide:_ [MktCalcInsightObjectDef](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_mktcalcinsightobjectdef.htm) ## MktDataConnection Represents the connection information of an external connector that can ingest data to Data Cloud, read data from the source, or write data to the source in Data Cloud. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | masterLabel, Parameters, Credentials | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MktDataConnection; Component Type in 1GP Package Manager UI: Data Connection **Use Case:** To reuse connection parameters. **Considerations When Packaging** Connection credentials are excluded from the package. Available parameters are defined in Connector Metadata which is exposed from Connect API. **License Requirements** Data Cloud must be provisioned. For more information, see [Data Cloud: Access and Provisioning.](https://help.salesforce.com/s/articleView?id=000396444&type=1) **Usage Limits:** The number of connections per connector type can be up to 200. **Post Install Steps:** After you create the connection, it will be in INACTIVE state, you must manually activate the connection. **Relationship to Other Components:** Must be used with Data Stream and Activation. **Documentation:** Salesforce Help: [Third-Party Data Cloud Connectors](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-data-cloud-integrations.html) ## MktDataTranObject An entity that is used to deliver (aka transport) information from the source to a target (target will be called a landing entity).This can be the schema of a file, API, Event, or other means of transporting data, such as SubscriberFile1.csv, or SubscriberCDCEvent. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DataSource, DataSourceObject, DeveloperName, ObjectCategory, Status | | Both Package Developer and Subscriber Can Edit | DataConnector | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name** Metadata Name: MktDataTranObject Component Type in 1GP Package Manager UI: It's not a top-level component, it can only be spidered in when customer selects some other component. You won't be able to add this component directly to the package. **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [MktDataTranObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_mktdatatranobject.htm) ## Named Credential Represents a named credential, which specifies the URL of a callout endpoint and its required authentication parameters in one definition. A named credential can be specified as an endpoint to simplify the setup of authenticated callouts. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterName, ParameterValue, and SequenceNumber properties have the same editability as the NamedCredentialParameters they’re included in. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label, NamedCredentialType, Legacy Named Credentials only (deprecated and unsupported in future releases) | | Both Package Developer and Subscriber Can Edit | CalloutOptions, NamedCredentialParameters, Legacy Named Credentials only (deprecated and unsupported in future releases) | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: NamedCredential **Considerations When Packaging** Certificates aren’t packageable. If a certificate needs access to an external system, an administrator must upload one to the subscriber org and reference it in the named credential. **Relationship to Other Components** You must package NamedCredential with the associated ExternalCredential component. The named credential defines a callout endpoint and an HTTP transport protocol, while the external credential represents the details of how Salesforce authenticates to an external system via an authentication protocol. Each named credential must be mapped to at least one external credential. **Legacy Named Credentials** **important:** In Winter ’23, Salesforce introduced an improved named credential that is extensible and customizable. We strongly recommend that you use this preferred credential instead of legacy named credentials. For information on extensible, customizable named credentials, see [Named Credentials and External Credentials](https://help.salesforce.com/s/articleView?id=nc_named_creds_and_ext_creds.htm). Legacy named credentials are deprecated and will be discontinued in a future release. After installing a named credential from a managed or unmanaged package, the subscriber must reauthenticate to the external system. - For password authentication, the subscriber reenters the password in the named credential definition. - For OAuth, the subscriber updates the callback URL in the client configuration for the authentication provider and then reauthenticates by selecting **Start Authentication Flow on Save** on the named credential. **Documentation:** _Salesforce Help_: [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [NamedCredential](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_namedcredential.htm) ## Object Source Target Map Contains the object-level mappings between the source and the target objects. The source and target objects can be an MktDataLakeObject or an MktDataModelObject. For example, an Email source object can be mapped to the ContactPointEmail object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DeveloperName, MasterLabel, ParentObject, SequenceNbr, SourceObject, TargetObject | | Both Package Developer and Subscriber Can Edit | LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode, Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name** Metadata Name: ObjectSourceTargetMap Component Type in 1GP Package Manager UI: It's not a top-level component, it can only be spidered in when customer selects some other component. You won't be able to add this component directly to the package. **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [ObjectSourceTargetMap](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_objectsourcetargetmap.htm) ## Object Integration Provider Definition Mapping Maps structured, logical data nodes in a context definition to actual Salesforce object fields or external data sources ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ## OcrSampleDocument Represents the details of a sample document or a document type that's used as a reference while extracting and mapping information from a customer form. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** OcrSampleDocument; Component Type in 1GP Package Manager UI: OcrSampleDocument **Use Case:** Migrate sample documents created with the Intelligent Form Reader or Intelligent Document Reader feature. **Considerations When Packaging:** If you update the package by deleting OcrSampleDocumentFields associated with the OCRTemplate, the OcrSampleDocumentFields are not deleted. **License Requirements:** AWSTextract1000LimitAddOn-1 for the Intelligent Form Reader feature or IntelligentDocumentReaderAddOn-1 for the Intelligent Document Reader feature. **Relationship to Other Components:** DocumentType, ContentAsset, and OcrTemplate (Optional) **Documentation:** _Metadata API Developer Guide:_ [OcrSampleDocument](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_ocrsampledocument.htm) ## OcrTemplate Represents the details of the mapping between a form and a Salesforce object using Intelligent Form Reader. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** OcrTemplate; Component Type in 1GP Package Manager UI: OcrTemplate **Use Case:** Migrate Mappings created with the Intelligent Form Reader or Intelligent Document Reader feature. **Considerations When Packaging** OcrTemplate has a dependency on OcrSampleDocument. Before deploying the package, make sure to either include OcrSampleDocument in the package or deploy a package that contains OcrSampleDocument. **License Requirements:** AWSTextract1000LimitAddOn-1 for the Intelligent Form Reader feature or IntelligentDocumentReaderAddOn-1 for the Intelligent Document Reader feature. **Relationship to Other Components:** DocumentType and OcrSampleDocument **Documentation:** _Metadata API Developer Guide:_ [OcrTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_ocrtemplate.htm) ## Outbound Network Connection Represents a private connection between a Salesforce org and a third-party data service. The connection is outbound because the callouts are going out of Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** You can only delete connections that are in an unprovisioned state. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Connection Type, Developer Name, Description, Master Label, Region, Service Name | | Both Package Developer and Subscriber Can Edit | Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: OutboundNetworkConnection; Component Type in 1GP Package Manager UI: Outbound Network Connection **Considerations When Packaging** - Packaged connections are installed as unprovisioned. Alert subscribers about how to provision connections after package installation. - If a developer changes the Region or Service Name of a packaged connection that is subscriber-provisioned, the upgrade fails for the subscriber. Alert subscribers about tearing down the connection before you update the Region or Service Name fields. As a best practice, avoid changing the Region or Service Name of a packaged connection unless necessary. - If you package a Named Credential that references an Outbound Network Connection, the referenced Outbound Network Connection component is automatically added to the package. **License Requirements:** This feature is available with the Private Connect license. **Documentation:** _Salesforce Help:_ [Secure Cross-Cloud Integrations with Private Connect](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5); _Salesforce Help:_ [Establish an Outbound Connection with AWS](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_outbound_aws.htm&type=5) ## Page Layout Represents the metadata associated with a page layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Page Layout Name | | Neither Package Developer or Subscriber Can Edit | Page Layout Name | ### More Information **Feature Name:** Metadata Name: Layout **Considerations** The page layout of the person uploading a package is the layout used for Group and Professional Edition orgs and becomes the default page layout for Enterprise, Unlimited, Performance, and Developer Edition orgs. Package page layouts alongside complimentary record types if the layout is being installed on an existing object. Otherwise, manually apply the installed page layouts to profiles. If a page layout and a record type are created as a result of installing a package, the uploading user’s page layout assignment for that record type is assigned to that record type for all profiles in the subscriber org, unless a profile is mapped during an install or upgrade. **Documentation:** _Metadata API Developer Guide:_ [Layout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_layouts.htm) ## Path Assistant Represents Path records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | IsActive field | | Neither Package Developer or Subscriber Can Edit | SobjectType, SobjectProcessField, and RecordType | ### More Information **Feature Name:** Metadata Name: PathAssistant; Component Type in 1GP Package Manager UI: Path Assistant **Documentation:** _Metadata API Developer Guide:_ [PathAssistant](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_pathassistant.htm) ## Payment Gateway Provider Represents the metadata associated with a payment gateway provider. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All fields | ### More Information **Feature Name:** Metadata Name: PaymentGatewayProvider **License Requirements** Salesforce Order Management, B2B Commerce, or B2C Commerce (for B2B2C Commerce) licenses are required. These licenses enable the Payment Platform org permission required to use payments objects. **Documentation:** _Salesforce Help:_ [Processing Payments with Payment Gateways](https://help.salesforce.com/s/articleView?id=sales.blng_payment_gateways.htm&type=5) ## Permission Set Represents a set of permissions that's used to grant more access to one or more users without changing their profile or reassigning profiles. You can use permission sets to grant access but not to deny access. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Label, Custom object permissions, Custom field permissions, Apex class access settings, Visualforce page access settings | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: PermissionSet; Component Type in 1GP Package Manager UI: Permission Set **Documentation:** _Metadata API Developer Guide:_ [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm) ## Permission Set Groups Represents a group of permission sets and the permissions within them. Use permission set groups to organize permissions based on job functions or tasks. Then, you can package the groups as needed. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Permission Set Group Components (Developer can add and remove while Subscriber can add) | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PermissionSetGroup; Component Type in 1GP Package Manager UI: Permission Set Group **Considerations When Packaging** Don't assume that a subscriber's permission set group is the same as what the developer has specified. Although developers can define the permission set group and what permission sets can go into it, subscribers can add additional permission sets or mute permissions. **Relationship to Other Components:** This feature can only be used in conjunction with Permission Sets. **Documentation:** _Salesforce Help:_ [Permission Set Groups](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups.htm&type=5) ## Platform Cache Represents a partition in the Platform Cache. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------- | | Only Package Developer Can Edit | Master Label, Description, Default Partition | | Both Package Developer and Subscriber Can Edit | Organization Capacity, Trial Capacity | | Neither Package Developer or Subscriber Can Edit | Developer Name | ### More Information **Feature Name:** Metadata Name: PlatformCachePartition; Component Type in 1GP Package Manager UI: Platform Cache Partition **Documentation:** [Set Up a Platform Cache Partition with Provider Free Capacity](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/data_platform_cache_setup_provider_capacity.htm); _Metadata API Developer Guide:_ [PlatformCachePartition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformcachepartition.htm); _Apex Developer Guide:_ [Platform Cache Partitions](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_partition_setup.htm) ## Platform Event Channel Represents a channel that you can subscribe to in order to receive a stream of events. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: PlatformEventChannel; Component Type in 1GP Package Manager UI: Platform Event Channel **Documentation:** _Metadata API Developer Guide:_ [PlatformEventChannel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformeventchannel.htm) ## Platform Event Channel Member Represents an entity selected for Change Data Capture notifications on a standard or custom channel, or a platform event selected on a custom channel. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: PlatformEventChannelMember; Component Type in 1GP Package Manager UI: Platform Event Channel Member **Considerations When Packaging** - As of Winter ’22, installing a managed package that contains Change Data Capture entity selections no longer causes an installation error. Before Winter ’22, installing a managed package that contained Change Data Capture entity selections that were over the default allocation caused package installation errors. - To package Change Data Capture entity selections, create a custom channel through the PlatformEventChannel metadata type. Then add entity selections to the custom channel through the PlatformEventChannelMember metadata type. **Documentation:** _Metadata API Developer Guide:_ [PlatformEventChannelMember](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformeventchannelmember.htm) ## Platform Event Subscriber Configuration Represents configuration settings for a platform event Apex trigger, including the batch size, the trigger’s running user, and parallel subscription settings. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No. PlatformEventSubscriberConfig is tied to an Apex trigger. If the package developer removes the Apex trigger, PlatformEventSubscriberConfig is also removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | batchSize, numPartitions, partitionKey, platformEventConsumer | | Both Package Developer and Subscriber Can Edit | user | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PlatformEventSubscriberConfig; Component Type in 1GP Package Manager UI: Platform Event Subscriber Configuration **Use Case:** Override the default running user and batch size of a platform event Apex trigger. **Relationship to Other Components:** PlatformEventSubscriberConfig is tied to an Apex trigger. **Documentation:** _Platform Events Developer Guide_: [Configure the User and Batch Size for Your Platform Event Trigger](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_trigger_config.htm); _Platform Events Developer Guide_: [Platform Event Processing at Scale with Parallel Subscriptions for Apex Triggers](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_ps.htm) ## Pricing Action Parameters Represents a pricing action associated to a context definition and a pricing procedure. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Pricing Action Parameters Name | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PricingActionParameters; Component Type in 1GP Package Manager UI: PricingActionParameters **License Requirements:** Salesforce Pricing permissions **Relationship to Other Components:** All the components that pricing depends on are packaged along with the Pricing Action Parameters component. **Documentation:** _Salesforce Help:_ [Pricing Action Parameters in Salesforce Pricing](https://help.salesforce.com/s/articleView?id=ind.pricing_pricing_action_parameters.htm&type=5) ## Pricing Recipe Represents one out of various data models or sets of entities of a particular cloud that'll be consumed by the pricing data store during design and run time. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Recipe Name | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PricingRecipe; Component Type in 1GP Package Manager UI: PricingRecipe **Considerations When Packaging** There are two prerequisites currently. All the associated contexts aren’t exported. For decision tables, while exporting, column additions made to the associated objects aren’t refreshed during export. **License Requirements:** Salesforce Pricing permissions **Relationship to Other Components:** All the components that pricing is dependent on are packaged along with the pricing recipe. **Documentation:** _Salesforce Help:_ [Pricing Recipes](https://help.salesforce.com/s/articleView?language=en_US&id=sf.pricing_pricing_recipes.htm) ## Procedure Output Resolution Represents the pricing resolution for an pricing element determined using strategy name and formula. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------- | | Only Package Developer Can Edit | Active Checkbox | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ProcedureOutputResolution; Component Type in 1GP Package Manager UI: ProcedureOutputResolution **Use Case:** To determine the best price for a product if a pricing rule produces multiple outcomes. **License Requirements:** Salesforce Pricing permissions **Documentation:** _Salesforce Help:_ [Procedure Output Resolution](https://help.salesforce.com/s/articleView?id=ind.pricing_procedure_output_resolution.htm&type=5) ## Process Use Flow instead. See [Flow](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_flow) ## Process Flow Migration Represents a process's migrated criteria and the resulting migrated flow. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Description, Label, Name | ### More Information **Feature Name:** Metadata Name: ProcessFlowMigration; Component Type in 1GP Package Manager UI: Process Flow Migration **Use Case** Include this component only if you’ve used Migrate to Flow tool and wish to have pending Scheduled Actions from migrated Processes converted into pending Flow Scheduled Paths in subscriber orgs. This occurs after the migrated Flow is activated in the subscriber org. **Considerations When Packaging** When packaging a Flow that was migrated from a Process, this component is added automatically. When adding a Flow that was migrated from a Process to a change set, this component would need to be added manually. **Relationship to Other Components** Flows **Documentation:** _Salesforce Help:_ [Migrate Processes and Workflows to Flow](https://help.salesforce.com/s/articleView?id=platform.flow_migrate_to_flow.htm&type=5) ## Product Attribute Set Represents the ProductAttribute information being used as and attribute such as color_c, size_c . ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ProductAttributeSet **License Requirements:** A B2B Commerce or D2C Commerce license and access to Commerce objects is required. **Usage Limits:** An org can have a maximum of 100 product attribute sets.; For each product attribute set, you can have a maximum of five associated product attribute set items. **Documentation:** _Salesforce Help:_ [Product Variations and Attributes](https://help.salesforce.com/s/articleView?id=commerce.comm_var_att_intro.htm&type=5); _Metadata API Developer Guide:_ [ProductAttributeSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_productattributeset.htm) ## Product Specification Type Represents the type of product specification provided by the user to make the product terminology unique to an industry. A product specification type is associated with a product specification record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------ | | Only Package Developer Can Edit | Label, Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ProductSpecificationType; Component Type in 1GP Package Manager UI: ProductSpecificationType **License Requirements** Only Salesforce Admins can set up the product specification type. To create and edit product specification type, the Product Catalog Management Designer permission set is required. To view product specification type, the Product Catalog Management Viewer permission set is required. **Documentation:** _Salesforce Help:_ [Product Specification](https://help.salesforce.com/s/articleView?id=ind.product_catalog_product_specification.htm&type=5); _Salesforce Help:_ [Create Product Specification Type and Product Specification Record Type](https://help.salesforce.com/s/articleView?id=ind.product_catalog_create_product_specification_type_and_product_specification_record_type.htm&type=5) ## Product Specification Record Type Represents the relationship between industry-specific product specifications and the product record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------- | | Only Package Developer Can Edit | Label, Record Type, Product Specification Type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name, Is Commercial | ### More Information **Feature Name:** Metadata Name: ProductSpecificationRecType; Component Type in 1GP Package Manager UI: ProductSpecificationRecType **License Requirements** Only Salesforce admins can set up the product specification record type. To create and edit product specification record type, the Product Catalog Management Designer permission set is required. To view product specification record type, the Product Catalog Management Viewer permission set is required. **Documentation:** _Salesforce Help:_ [Product Specification](https://help.salesforce.com/s/articleView?id=ind.product_catalog_product_specification.htm&type=5); _Salesforce Help:_ [Create Product Specification Type and Product Specification Record Type](https://help.salesforce.com/s/articleView?id=ind.product_catalog_create_product_specification_type_and_product_specification_record_type.htm&type=5) ## Prompts (In-App Guidance) Represents the metadata related to in-app guidance, which includes prompts and walkthroughs. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: Prompt; Component Type in 1GP Package Manager UI: Prompt **Considerations When Packaging** For 2GP packages, ensure that the scratch org definition file includes the `GuidanceHubAllowed` and `Enablement` features. See [Build Your Own Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) in the _Salesforce DX Developer Guide_. **License Requirements:** Enablement Admin permission set and Enablement permission set license are required. **Documentation:** _Metadata API Developer Guide:_ [Prompt](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_prompt.htm); _Salesforce Help:_ [Guidelines for In-App Guidance in Managed Packages](https://help.salesforce.com/s/articleView?id=sales.customhelp_iag_packages.htm&type=5) ## Quick Action Represents a specified create or update quick action for an object that then becomes available in the Chatter publisher. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | Field Overrides | | Both Package Developer and Subscriber Can Edit | All attributes except Field Overrides | | Neither Package Developer or Subscriber Can Edit | None | **note:** You can only modify managed package quick action layouts in Salesforce Setup. You can't make changes using Metadata API. ### More Information **Feature Name:** Metadata Name: QuickAction; Component Type in 1GP Package Manager UI: Quick Action **Documentation:** _Salesforce Help:_ [Quick Actions](https://help.salesforce.com/s/articleView?id=platform.actions_overview.htm&type=5) ## Recommendation Strategy Represents a recommendation strategy. Recommendation strategies are applications, similar to data flows, that determine a set of recommendations to be delivered to the client through data retrieval, branching, and logic operations. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### More Information **Feature Name:** Metadata Name: RecommendationStrategy; Component Type in 1GP Package Manager UI: Recommendation Strategy **Use Case** You can use this component to create personalized recommendations for end users. A recommendation displays contextually in Salesforce and prompts the end user to accept or reject the suggestion. When an end user accepts or rejects the recommendation, Salesforce automates a process, such as creating or updating a record. **Considerations When Packaging:** When you package a recommendation strategy, you must manually add object dependencies, such as recommendation, recommendationReaction, and flow. **Usage Limits:** An admin must select an object dependency for Recommendation and RecommendationReaction because object dependencies aren't added automatically. **Documentation:** _Salesforce Help:_ [Einstein Next Best Action](https://help.salesforce.com/s/articleView?id=platform.einstein_next_best_action.htm&type=5) ## Record Action Deployment Represents configuration settings for the Actions & Recommendations, Action Launcher, and Bulk Action Panel components. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Channel Configurations, Deployment Contexts, HasGuidedActions, HasRecommendations, Label, Recommendations, SelectableItems, ShouldLaunchActionOnReject | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: RecordActionDeployment; Component Type in 1GP Package Manager UI: RecordAction Deployment **Considerations When Packaging:** If the record action deployment component uses flows, quick actions, objects, or Next Best Action recommendations, include them in the package too. **Documentation:** _Metadata API Developer Guide:_ [RecordActionDeployment](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_recordactiondeployment.htm); _Salesforce Help:_ [Create an Actions & Recommendations Deployment](https://help.salesforce.com/s/articleView?id=service.console_lex_guided_action_deployment.htm&type=5) ## Record Alert Data Source Expression Set Definition Represents information about the data source for a record alert and the association with an expression set definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | ExpressionSetDefinition, ExpressionSetObject, IsActive, RecordAlertDataSource | | Neither Package Developer or Subscriber Can Edit | FullName, Metadata | ### More Information **RecAlrtDataSrcExpSetDef:** Metadata Name: RecAlrtDataSrcExpSetDef; Component Type in 1GP Package Manager UI: RecAlrtDataSrcExpSetDef **Documentation:** [RecAlrtDataSrcExpSetDef](https://developer.salesforce.com/docs/atlas.en-us.financial_services_cloud_object_reference.meta/financial_services_cloud_object_reference/sforce_api_objects_recalrtdatasrcexpsetdef.htm) in in _Financial Services Cloud Developer Guide_.. ## Record Type Represents the metadata associated with a record type. Record types let you offer different business processes, picklist values, and page layouts to different users. Use this metadata type to create, update, or delete record type definitions for a custom object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Description, Record Type Label | | Both Package Developer and Subscriber Can Edit | Active, Business Process | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: RecordType; Component Type in 1GP Package Manager UI: Record Type **Considerations When Packaging** - If record types are included in the package, the subscriber’s org must support record types to install the package. - When a new picklist value is installed, it’s associated with all installed record types according to the mappings specified by the developer. A subscriber can change this association. - Referencing an object’s record type field in a report’s criteria—for example, Account Record Type—causes a dependency. - Summarizing by an object’s record type field in a report’s criteria—for example, Account Record Type—causes a dependency. - If an object’s record type field is included as a column in a report, and the subscriber’s org isn’t using record types on the object or doesn’t support record types, the column is dropped during installation. - If you install a custom report type that includes an object’s record type field as a column, that column is dropped if the org doesn’t support record types or the object doesn’t have record types defined. **Documentation:** _Metadata API Developer Guide:_ [RecordType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_recordtype.htm) ## RedirectWhitelistUrl Represents a trusted URL that’s excluded from redirection restrictions when the redirectionWarning or redirectBlockModeEnabled field on the SessionSettings Metadata type is set to true. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Url | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RedirectWhitelistUrl; Component Type in 1GP Package Manager UI: RedirectWhitelistUrl **Use Case** Customers can use a Salesforce security setting to specify what happens when a user clicks a hyperlink that redirects to an untrusted URL outside the salesforce.com domain. The customer can choose to block these redirections or alert the user that the link is taking them outside the Salesforce domain. The URLs in RedirectWhiteListURL are considered trusted for the purpose of that security setting. If the Experience Cloud site pages, Lightning Experience pages, or custom Visualforce pages in your package include hyperlinks to URLs outside the salesforce.com domain, use RedirectWhitelistURL to ensure that users can access those hyperlinks. **Considerations When Packaging** When you include a RedirectWhitelistURL in a package, the URLs are trusted for redirections across Salesforce. Because this component modifies the security of the org, we don’t recommend that you include RedirectWhitelistURL in packages. Instead, instruct customers to use the Trusted URLs for Redirects Setup page or the RedirectWhitelistURL Metadata API type to add the URLs to their allowlist as part of activating your package. If you choose to include RedirectWhitelistURL components in your package, disclose this change prominently in your package documentation to ensure that your customers are aware of the security modification. **Usage Limits:** The RedirectWhiteListURL component is available in API version 48.0 and later. **Relationship to Other Components:** This component can be used only in conjunction with an Aura or Lightning Web Runtime (LWR) page for an Experience Cloud site, a [Lightning Page](#lightning-page), or a , or a [Visualforce Page](#visualforce-page).. **Documentation:** _Metadata API Developer Guide_: [RedirectWhitelistUrl](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_redirectwhitelisturl.htm); Salesforce Help: [Manage Redirections to External URLs](https://help.salesforce.com/s/articleView?id=xcloud.security_external_redirects.htm&type=5); _Metadata API Developer Guide_: [SecuritySettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_securitysettings.htm)]] ## Referenced Dashboard Represents the ReferencedDashboard object in CRM Analytics. A referenced dashboard stores information about an externally referenced dashboard. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Embed URL, Template Asset Source Name, Visibility | ### More Information **Feature Name:** Metadata Name: ReferencedDashboard **License Requirements:** Enables Tableau Dashboards in CRM Analytics ## Registered External Service Represents a registered external service, which provides an extension or integration. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RegisteredExternalService; Component Type in 1GP Package Manager UI: RegisteredExternalService **Documentation:** _Object Reference for the Salesforce Platform:_ [RegisteredExternalService](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_registeredexternalservice.htm) ## RelationshipGraphDefinition Represents a definition of a graph that you can configure in your organization to traverse object hierarchies and record details, giving you a glimpse of how your business works. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RelationshipGraphDefinition; Component Type in 1GP Package Manager UI: RelationshipGraphDefinition **Documentation:** _Metadata API Developer Guide:_ [RelationshipGraphDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_relationshipgraphdefinition.htm) ## Remote Site Setting Represents a remote site setting. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Remote Site Name | | Neither Package Developer or Subscriber Can Edit | Remote Site Name | ### More Information **Feature Name:** Metadata Name: RemoteSiteSettings **Documentation:** _Metadata API Developer Guide:_ [RemoteSiteSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_remotesitesetting.htm) ## Report Represents a custom report. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Report Unique Name | | Neither Package Developer or Subscriber Can Edit | Report Unique Name | ### More Information **Feature Name:** Metadata Name: Report; Component Type in 1GP Package Manager UI: Report **Considerations When Packaging** If a report includes elements that can’t be packaged, those elements are dropped or downgraded, or the package creation fails. For example: - Hierarchy drill-downs are dropped from activity and opportunities reports. - Filters on unpackageable fields are automatically dropped (for example, in filters on standard object record types). - Package upload fails if a report includes filter logic on an unpackageable field (for example, in filters on standard object record types). - Lookup values on the Select Campaign field of standard campaign reports are dropped. - Reports are dropped from packages if they’ve been moved to a private folder or to the Unfiled Public Reports folder. - When a package is installed into an org that doesn’t have Chart Analytics 2.0: - Combination charts are downgraded instead of dropped. For example, a combination vertical column chart with a line added is downgraded to a simple vertical column chart. A combination bar chart with more bars is downgraded to a simple bar chart. - Unsupported chart types, such as donut and funnel, are dropped. **Documentation:** _Metadata API Developer Guide:_ [Report](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_report.htm) ## Report Type Represents the metadata associated with a custom report type. Custom report types allow you to build a framework from which users can create and customize reports. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | All attributes except Development Status and Report Type Name | | Both Package Developer and Subscriber Can Edit | Development Status | | Neither Package Developer or Subscriber Can Edit | Report Type Name | ### More Information **Feature Name:** Metadata Name: ReportType; Component Type in 1GP Package Manager UI: Custom Report Type **Considerations When Packaging** A developer can edit a custom report type in a managed package after it’s released, and can add new fields. Subscribers automatically receive these changes when they install a new version of the managed package. However, developers can’t remove objects from the report type after the package is released. If you delete a field in a custom report type that’s part of a managed package, and the deleted field is part of bucketing or used in grouping, an error message appears. **Documentation:** _Metadata API Developer’s Guide:_ [ReportType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_reporttype.htm) ## ServiceProcess Represents a process created in Service Process Studio and its associated attributes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | Status, Description, ServiceProcessAttribute, ServiceProcessDependency, ServiceProcessItemGroup | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **ServiceProcess:** Metadata Name: ServiceProcess; Component Type in 1GP Package Manager UI: ServiceProcess **Documentation:**[ServiceProcess](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_serviceprocess.htm) in _Metadata API Developer Guide_.. ## Slack App (Beta) Represents a Slack app. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AppKey, AppToken, ClientKey, ClientSecret, SigningSecret, BotScopes, UserScopes, Config, IntegrationUser, DefaultUser | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SlackApp; Component Type in 1GP Package Manager UI: Slack App **Use Case:** Represents configuration of a Slack application **License Requirements:** Connect to Slack Permission **Relationship to Other Components:** Slack apps reference handlers (Apex classes) and view definition components. **Documentation:** [Apex SDK for Slack Developer Guide](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/overview) ## Service Catalog Category Represents the grouping of individual catalog items in Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | ParentCategory | | Both Package Developer and Subscriber Can Edit | SortOrder, IsActive, Image | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogCategory; Component Type in 1GP Package Manager UI: Service Catalog Category **Use Case:** Group your service catalog items together by associating them with a catalog category. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Post Install Steps:** Categories appear in the Service Catalog user UI only if they contain active items. **Documentation:** _Salesforce Help:_ [Create a Catalog Category](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_category.htm&type=5) ## Service Catalog Filter Criteria Represents an eligibility rule that determines if a Service Catalog user has access to a catalog item. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All fields | | Both Package Developer and Subscriber Can Edit | All fields | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogFilterCriteria; Component Type in 1GP Package Manager UI: Service Catalog Item Definition **Use Case:** Use the filter criteria to filter on catalog items. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Relationship to Other Components:** Service catalog filter criteria are related to a catalog item definition. **Documentation:** _Salesforce Help:_ [Create a Catalog Category](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_category.htm&type=5) ## Service Catalog Item Definition Represents the entity associated with a specific, individual service available in the Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------- | | Only Package Developer Can Edit | Flow | | Both Package Developer and Subscriber Can Edit | Status, Description, InternalNotes, Image, IsFeatured, IsPublic | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogItemDef; Component Type in 1GP Package Manager UI: Service Catalog Item Definition **Use Case:** Create a service catalog item that employees can request in the Service Catalog user UI. **Considerations When Packaging:** Subscribers can't change properties stored in the catalog item fulfillment flow unless they make a clone of the item and its related flow. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Usage Limits:** The org can have only 1000 SvcCatalogItemDefs, including those items installed from a managed package. **Post Install Steps:** If the item was installed in draft mode, it must be activated before employees can see it in the Service Catalog user UI. **Relationship to Other Components:** SvcCatalogItemDef requires a relationship with a catalog category. **Documentation:** _Salesforce Help:_ [Create a Catalog Item](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_item.htm&type=5) ## Service Catalog Fulfillment Flow Represents the flow associated with a specific catalog item in the Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------- | | Only Package Developer Can Edit | Description, Flow, Icon | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogFulfillmentFlow; Component Type in 1GP Package Manager UI: Service Catalog Fulfillment Flow **Use Case** Make a screen flow available in the Service Catalog builder. You can also use SvcCatalogFulfillmentFlow metadata to describe the flow and its inputs in the builder, enabling a clicks-not-code experience for providing inputs to the flow. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Post Install Steps:** Fulfillment flows appear in the Service Catalog builder only if the underlying screen flow is active in the org. **Relationship to Other Components:** SvcCatalogFulfillmentFlow must be related to a FlowDefinition.; SvcCatalogFulfillmentFlow can have related SvcCatalogFulfillFlowItem records. **Documentation:** _Salesforce Help:_ [Catalog Item Fulfillment Flows](https://help.salesforce.com/s/articleView?id=service.esc_catalog_item_fulfillment_flows.htm&type=5) ## Stationary Asset Environmental Source Record Type Configuration Represents the setup object that contains the mapping between the Stationary Asset Environmental Source record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: StnryAssetEnvSrcCnfg; Component Type in 1GP Package Manager UI: Stationary Asset Environmental Source Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new stationary asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Create a Stationary Asset Environmental Source Record](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_create_building_asset.htm&type=5) ## Static Resource Represents a static resource file, often a code library in a ZIP file. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | Description, File | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: StaticResource; Component Type in 1GP Package Manager UI: Static Resource **Documentation:** _Metadata API Developer Guide:_ [StaticResource](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_staticresource.htm) ## Streaming App Data Connector Represents the connection information specific to Web and Mobile Connectors. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | AppIdentifier, DataConnectorType, StreamingAppDataConnectorType | ### More Information **Feature Name:** Metadata Name: StreamingAppDataConnector **Use Case** The StreamingAppDataConnector is included in a package when you add a data stream (DataStreamDefinition). You need this component if you want to package a web or mobile data stream. **Post Install Steps** The package doesn't contain any connection information. The package subscriber must create the connection in their subscriber org and then select that connection when they deploy the data kit. **Documentation:** _Data Cloud Reference Guide_: [Capture Web Interactions](https://developer.salesforce.com/docs/atlas.en-us.c360a_api.meta/c360a_api/c360a_api_salesforce_interactions_web_sdk.htm); _Data Cloud Reference Guide_: [Integrate your Mobile Applications](https://developer.salesforce.com/docs/atlas.en-us.c360a_api.meta/c360a_api/c360a_api_engagement_mobile_sdk.htm) ## Sustainability UOM Represents information about the additional unit of measure values defined by a customer. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SustainabilityUom; Component Type in 1GP Package Manager UI: Sustainability Unit of Measure **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create Custom Units of Measure](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_create_custom_unitsofmeasure.htm&type=5) ## Sustainability UOM Conversion Represents information about the unit of measure conversion for the additional fuel types defined by a customer. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SustnUomConversion; Component Type in 1GP Package Manager UI: Sustainability Unit of Measure Conversion **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create a Unit of Measure Conversion for a Custom Fuel Type](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_create_unitofmeasure_conversion_for_custom_fuel_type.htm&type=5) ## Timeline Object Definition Represents the container that stores the details of a timeline configuration. You can use this resource with Salesforce objects to see their records' related events in a linear time-sorted view. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | Label, FullName, Definition, IsActive | | Both Package Developer and Subscriber Can Edit | Label, FullName, Definition, IsActive | | Neither Package Developer or Subscriber Can Edit | BaseObject | ### More Information **Feature Name:** Metadata Name: TimelineObjectDefinition; Component Type in 1GP Package Manager UI: Timeline Object Definition **Use Case:** Provides out-of-the-box Timeline object definitions. **License Requirements** Industries Health Cloud or any other License that has Timeline Permission enabled in them. **Legacy Component:** There’s a legacy Timeline component in the Health Cloud Package which is being deprecated in favor of this component. **Documentation:** _Health Cloud Developer Guide_: [TimelineObjectDefinition](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/meta_timelineobjectdefinition.htm) ## Timesheet Template Represents a template for creating time sheets in Field Service. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: TimesheetTemplate ## Translation Add translations to your managed packages. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: Translation **Relationship to Other Components** When you add this component to a first-generation managed package, the [Custom Object Translation](#custom-object-translation) component is automatically added to your package. component is automatically added to your package. For details on how subscribers can override translations after installing a package, see [Override Translations in Second-Generation Managed Packages and Unlocked Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/entering_translated_terms_in_packages.htm) in the Salesforce DX Developer Guide. ### Considerations When Packaging (Beta) Enable Language Extension Packages in Dev Hub to create language extension packages that contain translations of components in other packages. **note:** This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms. Language extension packages can only contain translations: Translations and CustomObjectTranslations. If a base package includes components that can’t be translated, those components aren’t included when you create a language extension package. To remove translations delivered by a package extension, uninstall the base package and all related extensions, then reinstall the base package and any other desired extensions. Otherwise, translations delivered by the extension remain until you uninstall all packages with that namespace. ## UI Object Relation Config Represents the admin-created configuration of the object relation UI component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | Reference Name, Developer Name, IsActive | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | ContextObject | ### More Information **Feature Name:** Metadata Name: UIObjectRelationConfig; Component Type in 1GP Package Manager UI: UI Object Relation Configuration **Use Case:** Provides out-of-the-box relationship card configuration in Health Cloud. **License Requirements:** Industries Health Cloud, Industries Insurance, or Industries Automotive licenses **Documentation:** _Salesforce Help_: [Set Up Provider Relationship Cards to Show Practitioner Information](https://help.salesforce.com/s/articleView?id=ind.admin_provider_cards.htm&type=5) ## User Access Policy Represents a user access policy. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Description, Name, Label, User Criteria Filters, Actions | | Both Package Developer and Subscriber Can Edit | Order (only subscriber editable), Status (only subscriber editable), Trigger Type (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: UserAccessPolicy; Component Type in 1GP Package Manager UI: User Access Policy **Usage Limits** User access policies have their status set to Design when installed and can be activated by the subscriber. Subscribers can have up to 200 active policies at one time. **Post Install Steps:** The subscriber can activate user access policies so that they run automatically when a user record matching the policy’s user criteria is created, updated, or both. **Documentation:** _Metadata API Developer Guide:_ [UserAccessPolicy](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_useraccesspolicy.htm); _Salesforce Help:_ [User Access Policies](https://help.salesforce.com/s/articleView?id=platform.perm_user_access_policies.htm&type=5) ## Validation Rule Represents a validation rule, which is used to verify that the data a user enters in a record is valid and can be saved. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Error Condition Formula, Error Location, Error Message | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Rule Name | ### More Information **Feature Name:** Metadata Name: ValidationRule; Component Type in 1GP Package Manager UI: Validation Rule **Considerations When Packaging:** For custom objects that are packaged, any associated validation rules are implicitly packaged as well. **Documentation:** _Metadata API Developer Guide:_ [ValidationRule](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_validationformulas.htm) ## Vehicle Asset Emissions Source Record Type Configuration Represents the setup object that contains the mapping between the Vehicle Asset Emissions Source record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: VehicleAssetEmssnSrcCnfg; Component Type in 1GP Package Manager UI: Vehicle Asset Emissions Source Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new vehicle asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Create a Vehicle Asset Emissions Source Record](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_create_vehicle_asset.htm&type=5) ## View Definition (Beta) Represents a view definition on a Slack app. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | TargetType, Content, Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ViewDefinition; Component Type in 1GP Package Manager UI: View Definition **Use Case:** Represents a view within a Slack application **License Requirements:** Connect to Slack Permission **Relationship to Other Components:** View definitions are referenced by Slack apps. **Documentation:** [Apex SDK for Slack Developer Guide](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/overview) ## Virtual Visit Config Represents an external video provider configuration, which relays events from Salesforce to the provider. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | ComprehendServiceType, ExperienceCloudSiteUrl, ExternalRoleIdentifier, Label, MessagingRegion, NamedCredential, StorageBucketName, UsageType, VideoCallApptTypeValue, VideoControlRegion, VisitRegion | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: VirtualVisitConfig **Documentation:** _Salesforce Help_: [Virtual Care](https://help.salesforce.com/s/articleView?id=ind.admin_virtual_care.htm&type=5) ## Visualforce Component Represents a Visualforce component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | Yes | If a developer removes a public Visualforce component from a new version of your 1GP managed package, the component is removed from the subscriber’s org upon upgrade. If the Visualforce component is global, it remains in the subscriber org until the administrator deletes it. For 2GP packages, Visualforce components are hard deleted, and only components that aren’t marked as global can be removed from a package. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexComponent **Documentation:** [Visualforce Components](https://help.salesforce.com/s/articleView?id=platform.pages_custom_components.htm&type=5) ## Visualforce Page Represents a Visualforce page. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP and 2GP packages. | | Component Has IP Protection | No | If a developer removes a public Visualforce component from a new version of your package, the component is removed from the subscriber’s org upon upgrade. If the Visualforce component is global, it remains in the subscriber org until the administrator deletes it. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexPage; Component Type in 1GP Package Manager UI: Visualforce Page ## Wave Analytic Asset Collection A collection of CRM Analytics assets. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Folder, Items, Label | | Both Package Developer and Subscriber Can Edit | Color, Description, Shares | | Neither Package Developer or Subscriber Can Edit | Collection Type | ### More Information **Feature Name:** Metadata Name: WaveAnalyticAssetCollection; Component Type in 1GP Package Manager UI: Wave Analytic Asset Collection **Use Case:** Represents a collection of CRM Analytics assets. **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics **Documentation:** _Salesforce Help_: [Curate and Share Insights with Collections](https://help.salesforce.com/s/articleView?id=analytics.bi_home_collections&type=5) ## Wave Application A CRM Analytics application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Asset Icon, Description, Shares | | Neither Package Developer or Subscriber Can Edit | Folder, Template Origin, Template Version | ### More Information **Feature Name:** Metadata Name: WaveApplication **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Component A CRM Analytics dashboard component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveComponent **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dataflow A CRM Analytics data prep dataflow. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Dataflow Type | ### More Information **Feature Name:** Metadata Name: WaveDataflow **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dashboard A CRM Analytics dashboard. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Date Version, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveDashboard **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dataset A CRM Analytics dataset. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Template Asset Source Name, Type | ### More Information **Feature Name:** Metadata Name: WaveDataset **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Lens A CRM Analytics lens. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description, Visualization Type | | Neither Package Developer or Subscriber Can Edit | Application, Datasets, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveLens **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Recipe A CRM Analytics data prep recipe. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description, Security Predicate, Target Dataset Alias | | Neither Package Developer or Subscriber Can Edit | Application, Dataflow, Format, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: Wave Recipe **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Template Bundle A CRM Analytics template bundle. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Asset Icon, Description | | Neither Package Developer or Subscriber Can Edit | Asset Version, Template Type | ### More Information **Feature Name:** Metadata Name: WaveTemplateBundle **Considerations When Packaging** Analytics assets are installed in subscriber orgs via Analytics Templates using the WaveTemplateBundle. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Xmd The extended metadata for CRM Analytics dataset fields and their formatting for dashboards and lenses. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Dates, Dimensions, Measures, Organizations, Wave Visualization | | Neither Package Developer or Subscriber Can Edit | Application, Dataset, Dataset Connector, Dataset Fully Qualified Name, Origin, Type | ### More Information **Feature Name:** Metadata Name: WaveXmd **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Web Store Template Represents a configuration for creating commerce stores. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: WebStoreTemplate **Documentation:** _Metadata API Developer Guide:_ [WebStoreTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_webstoretemplate.htm) ## Workflow Alert WorkflowAlert represents an email alert associated with a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Additional Emails, Email Template, From Email Address, Recipients | | Neither Package Developer or Subscriber Can Edit | Description | ### More Information **Feature Name:** Metadata Name: Workflow - Salesforce prevents you from uploading workflow alerts that have a public group, partner user, or role recipient. Change the recipient to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - You can package workflow rules and associated workflow actions, such as email alerts and field updates. However, any time-based triggers aren’t included in the package. Notify your installers to set up any time-based triggers that are essential to your app. - References to a specific user in workflow actions, such as the email recipient of a workflow email alert, are replaced by the user installing the package. Sometimes workflow actions referencing roles, public groups, account team, opportunity team, or case team roles aren’t uploaded. - References to an org-wide address, such as the From email address of a workflow email alert, are reset to Current User during installation. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Field Update WorkflowFieldUpdate represents a workflow field update. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Description, Field Value, Formula Value | | Both Package Developer and Subscriber Can Edit | Lookup | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Field Update - Salesforce prevents you from uploading workflow field updates that change an Owner field to a queue. Change the updated field value to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. - You can package workflow rules and associated workflow actions, such as email alerts and field updates. However, any time-based triggers aren’t included in the package. Notify your installers to set up any time-based triggers that are essential to your app. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Knowledge Publish WorkflowKnowledgePublish represents Salesforce Knowledge article publishing actions and information. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes, if protected | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | Action, Description, Unique Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Object Name | ### More Information **Feature Name:** Metadata Name: WorkflowKnowledgePublish; Component Type in 1GP Package Manager UI: Knowledge Action **Considerations When Packaging** WorkflowKnowledgePublish can only be installed in Salesforce Classic orgs with Knowledge enabled. WorkflowKnowledgePublish includes the article type `*__kav`, which is not supported by Lightning Knowledge. If you try to install WorkflowKnowledgePublish into an org with Lightning Knowledge enabled, this message is displayed: When Lightning Knowledge is enabled, you can’t add an article type. **License Requirements:** Salesforce Classic orgs with Knowledge enabled can use this package. **Documentation:** _Salesforce Help_: [Create Workflow Actions for Knowledge](https://help.salesforce.com/s/articleView?id=service.knowledge_actions_create.htm&type=5) ## Workflow Outbound Message WorkflowOutboundMessage represents an outbound message associated with a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | Description, Endpoint URL, Fields to Send, Send Session ID | | Both Package Developer and Subscriber Can Edit | User to Send As | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Outbound Message Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Rule This metadata type represents a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------- | | Only Package Developer Can Edit | Description, Evaluation Criteria, Rule Criteria | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Rule Name | ### More Information - Feature Name: Metadata Name: Workflow Component Type in 1GP Package Manager UI: Workflow Rule * Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. * Developers can associate or disassociate workflow actions with a workflow rule at any time. These changes, including disassociation, are reflected in the subscriber’s org upon install. In managed packages, a subscriber can’t disassociate workflow actions from a workflow rule if it was associated by the developer. * On install, all workflow rules newly created in the installed or upgraded package, have the same activation status as in the uploaded package. * You can't package workflow rules with time triggers. ## Workflow Task This metadata type references an assigned workflow task. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Assign To, Comments, Due Date, Priority, Record Type, Status | | Neither Package Developer or Subscriber Can Edit | Subject | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Task - Salesforce prevents you from uploading workflow tasks that are assigned to a role. Change the Assigned To field to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. # Components Available in Second-Generation Managed Packages Each metadata component that you include in a second-generation managed package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and installed. Before you review the details about the metadata components that can be included in a managed package, be sure you understand the meaning of each manageability rule. | Rule | Description | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Component Can Be Updated During Package Upgrade | **If yes:** The component can be updated during a package upgrade. The component is first deployed to the subscriber org during the initial package installation, and subsequent package upgrades update the installed component. **If no:** The component can’t be updated during package upgrades. Instead, it’s only deployed to the subscriber org during the initial package installation, and subsequent package upgrades don’t update the component. Components in this category can typically be modified by the admin in the subscriber org. | | Subscriber Can Delete Component | **If yes:** The subscriber or installer of the managed package can delete the packaged component from their org. Deleted components aren’t reinstalled during a package upgrade. **If no:** The subscriber or installer of the managed package can’t delete the packaged component from their org. | | Package Developer Can Remove Component | **If yes:** After the package that contains the component is promoted and released, the package developer can choose to remove the component in a future package version. In most cases, removing components from a package version marks the component as deprecated, and doesn’t hard delete the component from the subscriber org. These deprecated components can be deleted by the admin of the subscriber org. For details about which managed 2GP components are deprecated, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_remove_md_components.htm). To request access to this feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). **If no:** After the package that contains the component is promoted and released, the package developer can’t remove the component in a future package version. | | Component Has IP Protection | **If yes:** To protect the intellectual property of the developer, the component’s metadata, such as Apex code or Custom Metadata record information, is hidden in the installed org. **If no:** The component is visible in the subscriber’s org. | Each component also lists which properties the package developer and subscriber can edit after the package is promoted or installed. For definitions of those categories, see [Editable Properties After Package Promotion or Installation](https://developer.salesforce.com/docs/platform/pkg2-dev/metadata-components/mdc-editable-property-definitions.md). - **[Account Plan Objective Measure Calculation Definition](#account-plan-objective-measure-calculation-definition)** Represents the definition of a target object, rollup field, and logic for calculating the current value of a sales account plan objective measure. - **[Account Relationship Share Rule](#account-relationship-share-rule)** Determines which object records are shared, how they’re shared, the account relationship type that shares the records, and the level of access granted to the records. - **[Action Link Group Template](#action-link-group-template)** Represents the action link group template. Action link templates let you reuse action link definitions and package and distribute action links. - **[Action Plan Template](#action-plan-template)** Represents an instance of an action plan template. - **[Actionable List Definition](#actionable-list-definition)** Represents the data source definition details associated with an actionable list. - **[Actionable List Key Performance Indicator Definition](#actionable-list-key-performance-indicator-definition)** Represents the custom key performance indicators that are defined for a specific field in an object. - **[Activation Platform](#activation-platform)** Represents the ActivationPlatform configuration, such as platform name, delivery schedule, output format, and destination folder. - **[AffinityScoreDefinition](#affinityscoredefinition)** Represents the affinity information used in calculations to analyze and categorize contacts for marketing purposes. - **[Agent Action](#agent-action)** Represents an action, for use in Agentforce. - **[Agent Topic](#agent-topic)** Represents a topic, for use in Agentforce. - **[AI Application](#ai-application)** Represents an instance of an AI application. For example, Einstein Prediction Builder. - **[AI Application Config](#ai-application-config)** Represents additional prediction information related to an AI application. - **[AIUsecaseDefinition](#aiusecasedefinition)** Represents a collection of fields in a Salesforce org used to define a machine learning use case and get real-time predictions. - **[Analytics](#analytics)** Analytics components include analytics applications, dashboards, dataflows, datasets, lenses, recipes, and user XMD. - **[Analytics Visualization](#analytics-visualization)** Represents a Tableau Next visualization. - **[Analytics Workspace](#analytics-workspace)** Represents a Tableau Next workspace. - **[Apex Class](#apex-class)** Represents an Apex Class. An Apex class is a template or blueprint from which Apex objects are created. Classes consist of other classes, user-defined methods, variables, exception types, and static initialization code. - **[Apex Sharing Reason](#apex-sharing-reason)** Represents an Apex sharing reason, which is used to indicate why sharing was implemented for a custom object. - **[Apex Trigger](#apex-trigger)** Represents an Apex trigger. A trigger is Apex code that executes before or after specific data manipulation language (DML) events occur, such as before object records are inserted into the database, or after records have been deleted. - **[App Framework Template Bundle](#app-framework-template-bundle)** Represents the app framework template bundle. Use these templates for Data Cloud and Tableau Next assets. - **[Application Subtype Definition](#application-subtype-definition)** Represents a subtype of an application within an application domain. - **[AssessmentConfiguration](#assessmentconfiguration)** Represents a configuration for Assessment component. An AssessmentConfiguration entry indicates configuration for user flows such as sending out emails or reminder actions on assessments initiated by the patient. - **[AssessmentQuestion](#assessmentquestion)** Represents the container object that stores the questions required for an assessment. - **[AssessmentQuestionSet](#assessmentquestionset)** Represents the container object for Assessment Questions. - **[Aura Component](#aura-component)** Represents an Aura definition bundle. A bundle contains an Aura definition, such as an Aura component, and its related resources, such as a JavaScript controller. The definition can be a component, application, event, interface, or a tokens collection. - **[Batch Calc Job Definition](#batch-calc-job-definition)** Represents a Data Processing Engine definition. - **[Batch Process Job Definition](#batch-process-job-definition)** Represents the details of a Batch Management job definition. - **[Benefit Action](#benefit-action)** Represents details of an action that can be triggered for a benefit. - **[Bot Template](#bot-template)** Represents the configuration details for a specific Einstein Bot template, including dialogs and variables. - **[Branding Set](#branding-set)** Represents the definition of a set of branding properties for an Experience Builder site, as defined in the Theme panel in Experience Builder. - **[Briefcase Definition](#briefcase-definition)** Represents a briefcase definition. A briefcase makes selected records available for specific users and groups to view when they’re offline in the Salesforce Field Service mobile app for iOS and Android. - **[Building Energy Intensity Record Type Configuration](#building-energy-intensity-record-type-configuration)** Represents the setup object that contains the mapping between the Building Energy Intensity Record record type and internal enums. You can primarily use this object for calculations across different record types. - **[Business Process](#business-process)** The BusinessProcess metadata type enables you to display different picklist values for users based on their profile. - **[Business Process Group](#business-process-group)** Represents the surveys used to track customers’ experiences across different stages in their lifecycle. - **[Business Process Type Definition](#business-process-type-definition)** Define the types of business processes that are applied to a rule. - **[Care Benefit Verify Settings](#care-benefit-verify-settings)** Represents the configuration settings for benefit verification requests. - **[Care Limit Type](#care-limit-type)** Defines the characteristics of limits on benefit provision. - **[Care Request Configuration](#care-request-configuration)** Represents the details for a record type such as service request, drug request, or admission request. One or more record types can be associated with a care request. - **[Care System Field Mapping](#care-system-field-mapping)** Represents a mapping from source system fields to Salesforce target entities and attributes. - **[Channel Layout](#channel-layout)** Represents the metadata associated with a communication channel layout. - **[Chatter Extension](#chatter-extension)** Represents the metadata used to describe a Rich Publisher App that’s integrated with the Chatter publisher. - **[Claim Financial Settings](#claim-financial-settings)** Represents the configuration settings for Insurance Claim Financial Services. - **[CommunicationChannelType](#communicationchanneltype)** Represents the type of communication channel, such as WhatsApp and SMS, to use for referral promotions. - **[Community Template Definition](#community-template-definition)** Represents the definition of an Experience Builder site template. - **[Community Theme Definition](#community-theme-definition)** Represents the definition of a theme for an Experience Builder site. - **[Compact Layout](#compact-layout)** Represents the metadata associated with a compact layout. - **[Conditional Formatting Ruleset](#conditional-formatting-ruleset)** Represents a set of rules that define the style and visibility of conditional field formatting on Dynamic Forms-enabled Lightning page field instances. - **[Connected App](#connected-app)** Represents a connected app configuration. A connected app enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. - **[Context Definition](#context-definition)** A context definition defines the relationship between the nodes and the attributes within each node. For efficient data access, users can use nodes and attributes to easily access the relevant data from the mapped data source. Various Salesforce products offer predefined context definitions based on their use case. - **[Contract Type](#contract-type)** A contract type is used to group contracts so that they exhibit similar characteristics. For example, the lifecycle states, the people who access, the templates and clauses used. - **[Conversation Channel Definition](#conversation-channel-definition)** Represents the conversation channel definition that’s implemented for Interaction Service for Bring Your Own Channel and Bring Your Own Channel for CCaaS messaging channels. - **[Conversation Vendor Info](#conversation-vendor-info)** This setup object connects the partner vendor system to the Service Cloud feature. - **[CORS Allowlist](#cors-allowlist)** Represents an origin in the CORS allowlist. - **[CSP Trusted Site](#csp-trusted-site)** Represents a trusted URL. For each CspTrustedSite component, you can specify Content Security Policy (CSP) directives and permissions policy directives. - **[Custom Application](#custom-application)** Represents a custom application. - **[Custom Button or Link](#custom-button-or-link)** Represents a custom link defined in a home page component. - **[Custom Console Components](#custom-console-components)** Represents a custom console component (Visualforce page) assigned to a CustomApplication that is marked as a Salesforce console. Custom console components extend the capabilities of Salesforce console apps. - **[Custom Field on Standard or Custom Object](#custom-field-on-standard-or-custom-object)** Represents the metadata associated with a field. Use this metadata type to create, update, or delete custom field definitions on standard or custom objects. - **[Custom Field on Custom Metadata Type](#custom-field-on-custom-metadata-type)** Represents a custom fields on the custom metadata type. - **[Custom Field Display](#custom-field-display)** Represents the CustomFieldDisplay view type assigned to product attribute custom fields. - **[Custom Help Menu Section](#custom-help-menu-section)** Represents the section of the Lightning Experience help menu that the admin added to display custom, org-specific help resources for the org. The custom section contains help resources added by the admin. - **[Custom Index](#custom-index)** Represents an index used to increase the speed of queries. - **[Custom Label](#custom-label)** The CustomLabels metadata type allows you to create custom labels that can be localized for use in different languages, countries, and currencies. - **[Custom Metadata Type Records](#custom-metadata-type-records)** Represents a record of a custom metadata type. - **[Custom Metadata Type](#custom-metadata-type)** Represents a record of a custom metadata type. - **[Custom Notification Type](#custom-notification-type)** Represents the metadata associated with a custom notification type. - **[Custom Object](#custom-object)** Represents a custom object that stores data unique to an org or an external object that maps to data stored outside an org. - **[Custom Object Translation](#custom-object-translation)** This metadata type allows you to translate custom objects for a variety of languages. - **[Custom Permission](#custom-permission)** Represents a permission that grants access to a custom feature. - **[Custom Tab](#custom-tab)** Represents a custom tab. Custom tabs let you display custom object data or other web content in Salesforce. - **[Dashboard](#dashboard)** Represents a dashboard. Dashboards are visual representations of data that allow you to see key metrics and performance at a glance. - **[DataCalcInsightTemplate](#datacalcinsighttemplate)** Represents the object template for data calculations and insights of Data Cloud objects in DataCalcInsightTemplate. These objects are added inside the data kit. - **[DataCleanRoomProvider](#datacleanroomprovider)** Represents a clean room provider configuration that defines the clean room collaboration details, including templates and the platform used for secure data collaboration in Data 360. - **[DataConnector](#dataconnector)** Represents the white-labeled metadata configuration for an external connector in Data 360. - **[Data Connector Ingest API](#data-connector-ingest-api)** Represents the connection information specific to Ingestion API. - **[Data Connector S3](#data-connector-s3)** Represents the connection information specific to Amazon S3. - **[Data Kit Object Dependency](#data-kit-object-dependency)** Represent the object dependencies and relationships between different objects in Data Kit Object Dependency. These objects are added inside the data kit. - **[Data Kit Object Template](#data-kit-object-template)** Represents the object in Data Kit Object Template. This object template is added inside the data kit. - **[DataObjectBuildOrgTemplate](#dataobjectbuildorgtemplate)** Represents the output objects of the components the user includes in a data kit. - **[Data Package Kit Definition](#data-package-kit-definition)** Represents the top-level Data Kit container definition. Content objects can be added after the Data Kit is defined. - **[Data Package Kit Object](#data-package-kit-object)** Represents the object in Data Kit Content Object. These objects are added inside the data kit. - **[Data Source](#data-source)** Used to represent the system where the data was sourced. - **[Data Source Bundle Definition](#data-source-bundle-definition)** Represents the bundle of streams that a user adds to a data kit. - **[Data Source Object](#data-source-object)** Represents the object from where the data was sourced. - **[Data Src Data Model Field Map](#data-src-data-model-field-map)** Represents the entity that’s used to store the design-time bundle-level mappings for the data source fields and data model fields. - **[Data Stream Definition](#data-stream-definition)** Contains Data Ingestion information such as Connection, API and File retrieval settings. - **[Data Stream Template](#data-stream-template)** Represents the data stream that a user adds to a data kit. - **[DataWeaveResource](#dataweaveresource)** Represents the DataWeaveScriptResource class that is generated for all DataWeave scripts. DataWeave scripts can be directly invoked from Apex. - **[Decision Matrix Definition](#decision-matrix-definition)** Represents a definition of a decision matrix. - **[Decision Matrix Definition Version](#decision-matrix-definition-version)** Represents a definition of a decision matrix version. - **[Decision Table](#decision-table)** Represents the information about a decision table. - **[Decision Table Dataset Link](#decision-table-dataset-link)** Represents the information about a dataset link associated with a decision table. In a dataset link, select an object for whose records, the decision table must provide an outcome. - **[Digital Experience](#digital-experience)** Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. - **[Digital Experience Bundle](#digital-experience-bundle)** Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. - **[Disclosure Definition](#disclosure-definition)** Represents information that defines a disclosure type, such as details of the publisher or vendor who created or implemented the report. - **[Disclosure Definition Version](#disclosure-definition-version)** Represents the version information about the disclosure definition. - **[Disclosure Type](#disclosure-type)** Represents the types of disclosures that are done by an individual or an organization and the associated metadata. - **[Discovery AI Model](#discovery-ai-model)** Represents the metadata associated with a model used in Einstein Discovery. - **[Discovery Goal](#discovery-goal)** Represents the metadata associated with an Einstein Discovery prediction definition. - **[Discovery Story](#discovery-story)** Represents the metadata associated with a story used in Einstein Discovery. - **[Document](#document)** Represents a Document. All documents must be in a document folder, such as sampleFolder/TestDocument. - **[Document Generation Setting](#document-generation-setting)** Represents an org's settings for automatic document generation from templates. - **[Eclair GeoData](#eclair-geodata)** Represents an Analytics custom map chart. Custom maps are user-defined maps that are uploaded to Analytics and are used just as standard maps are. Custom maps are accessed in Analytics from the list of maps available with the map chart type. - **[Email Template (Classic)](#email-template-classic)** Use email templates to increase productivity and ensure consistent messaging. Email templates with merge fields let you quickly send emails that include field data from Salesforce records. - **[Email Template (Lightning)](#email-template-lightning)** Represents a template for an email, mass email, list email, or Sales Engagement email. - **[Embedded Service Config](#embedded-service-config)** Represents a setup node for creating an Embedded Service for Web deployment. - **[Embedded Service Menu Settings](#embedded-service-menu-settings)** Represents a setup node for creating a channel menu deployment. Channel menus list the ways in which customers can contact your business. - **[Enablement Measure Definition](#enablement-measure-definition)** Represents an Enablement measure, which specifies the job-related activity that a user performs to complete a milestone or outcome in an Enablement program. A measure identifies a source object and optional related objects, with optional field filters and filter logic, for tracking the activity. - **[Enablement Program Definition](#enablement-program-definition)** Represents an Enablement program, which includes exercises and measurable milestones to help users such as sales reps achieve specific outcomes related to your company’s revenue goals. - **[Enablement Program Task Subcategory](#enablement-program-task-subcategory)** Represents a custom exercise type that an Enablement admin adds to an Enablement program in Program Builder. A custom exercise type also requires a corresponding EnblProgramTaskDefinition record for Program Builder and corresponding LearningItem and LearningItemType records for when users take the exercise in the Guidance Center. - **[Entitlement Template](#entitlement-template)** Represents an entitlement template. Entitlement templates are predefined terms of customer support that you can quickly add to products. - **[ESignature Config](#esignature-config)** Using the Electronic Signature Configuration setup, the system admin must define the required configurations to support the e-signature APIs and UI. - **[ESignature Envelope Config](#esignature-envelope-config)** Using the Electronic Signature Envelope Config the system admin can define the default reminders and expiry for the envelopes submitted for eSignature. - **[Event Relay](#event-relay)** Represents an event relay that you can use to send platform events and change data capture events from Salesforce to Amazon EventBridge. - **[Explainability Action Definition](#explainability-action-definition)** Define where the metadata for your Decision Explainer business rules are stored in Public Sector Solutions. - **[Explainability Action Version](#explainability-action-version)** Define and store versions of the explainability actions used by your Decision Explainer business rules in Public Sector Solutions. - **[Explainability Message Template](#explainability-message-template)** Represents information about the template that contains the decision explanation message for a specified expression set step type. - **[Expression Set Definition](#expression-set-definition)** Represents an expression set definition. - **[Expression Set Definition Version](#expression-set-definition-version)** Represents a definition of an expression set version. - **[Expression Set Object Alias](#expression-set-object-alias)** Represents information about the alias of the source object that’s used in an expression set. - **[Expression Set Message Token](#expression-set-message-token)** Represents a token that's used in an explainability message template. The token can be replaced with an expression set version resource that the template is used in. This object is available in API version 59.0 and later. - **[External Auth Identity Provider](#external-auth-identity-provider)** Represents the external auth identity provider that obtains OAuth tokens for callouts that use named credentials. - **[External Client App Canvas Settings](#external-client-app-canvas-settings)** Represents an external client app's canvas app settings. - **[External Client App Header](#external-client-app-header)** Represents the header file for an external client application configuration. - **[External Client App Notification Settings](#external-client-app-notification-settings)** Represents the settings configuration for the external client app’s notifications plugin. - **[External Client App OAuth Settings](#external-client-app-oauth-settings)** Represents the settings configuration for the external client app’s OAuth plugin. - **[External Client App Push Settings](#external-client-app-push-settings)** Represents the settings configuration for the external client app’s push notification plugin. - **[External Credential](#external-credential)** Represents the details of how Salesforce authenticates to the external system. - **[External Data Connector](#external-data-connector)** Used to represent the object where the data was sourced. - **[External Data Source](#external-data-source)** Represents the metadata associated with an external data source. Create external data sources to manage connection details for integration with data and content that are stored outside your Salesforce org. - **[External Data Transport Field Template](#external-data-transport-field-template)** Represents the definition of a Data Cloud schema field. - **[External Data Transport Field](#external-data-transport-field)** Use ExternalDataTranField to add a field to the ExternalDataTranObject in your managed packages. ExternalDataTranObject is a Data Cloud schema object. - **[External Data Transport Object Template](#external-data-transport-object-template)** Represents the definition of a Data Cloud schema object. - **[External Data Transport Object](#external-data-transport-object)** To include a Data Cloud schema object in your managed packages, add ExternalDataTranObject. - **[External Document Storage Configuration](#external-document-storage-configuration)** Represents configuration, which admin makes in setup to specify the drive, path, and named credential to be used for storing documents on external drives. - **[External Services](#external-services)** Represents the External Service configuration for an org. - **[Feature Parameter Boolean](#feature-parameter-boolean)** Represents a boolean feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[Feature Parameter Date](#feature-parameter-date)** Represents a date feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[Feature Parameter Integer](#feature-parameter-integer)** Represents an integer feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. - **[FieldMappingConfig](#fieldmappingconfig)** Represents the configuration for fields mapped between a source object and one or more destination objects and fields. This object is available in API version 63.0 and later. - **[Field Set](#field-set)** Represents a field set. A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user's first name, middle name, last name, and business title. - **[Field Source Target Relationship](#field-source-target-relationship)** Stores the relationships between a data model object (DMO) and its fields. For example, the Individual.Id field has a one-to-many relationship (1:M) with the ContactPointEmail.PartyId field. - **[Flow](#flow)** Represents the metadata associated with a flow. With Flow, you can create an application that navigates users through a series of pages to query and update records in the database. You can also execute logic and provide branching capability based on user input to build dynamic applications. - **[Flow Category](#flow-category)** Represents a list of flows that are grouped by category. - **[Flow Definition](#flow-definition)** Represents the flow definition’s description and active flow version number. - **[Flow Test](#flow-test)** Represents the metadata associated with a flow test. Before you activate a record-triggered flow, you can test it to verify its expected results and identify flow run-time failures. - **[Folder](#folder)** Represents a folder. - **[Fuel Type](#fuel-type)** Represents a custom fuel type in an org. - **[Fuel Type Sustainability Unit of Measure](#fuel-type-sustainability-unit-of-measure)** Represents a mapping between the custom fuel types and their corresponding unit of measure (UOM) values defined by a customer in an org. - **[Fundraising Config](#fundraising-config)** Represents a collection of settings to configure the fundraising product. - **[Gateway Provider Payment Method Type](#gateway-provider-payment-method-type)** Represents an entity that allows integrators and payment providers to choose an active payment to receive an order's payment data rather than allowing the Salesforce Order Management platform to select a default payment method. - **[Gen Ai Planner Bundle](#gen-ai-planner-bundle)** Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). - **[Generative AI Prompt Template](#generative-ai-prompt-template)** Represents a generative AI prompt template, for use in Agentforce. - **[Global Picklist](#global-picklist)** Represents the metadata for a global picklist value set, which is the set of shared values that custom picklist fields can use. A global value set isn’t a field itself. In contrast, the custom picklist fields that are based on a global picklist are of type ValueSet. - **[Global Value Set Translation](#global-value-set-translation)** Add global value set translations to your managed packages. - **[Home Page Component](#home-page-component)** Represents the metadata associated with a home page component. You can customize the Home tab in Salesforce Classic to include components such as sidebar links, a company logo, a dashboard snapshot, or custom components that you create. Use to create, update, or delete home page component definitions. - **[Home Page Layout](#home-page-layout)** Represents the metadata associated with a home page layout. You can customize home page layouts and assign the layouts to users based on their user profile. - **[Identity Verification Proc Def](#identity-verification-proc-def)** Represents the definition of the identity verification process. - **[Inbound Network Connection](#inbound-network-connection)** Represents a private connection between a third-party data service and a Salesforce org. The connection is inbound because the callouts are coming into Salesforce. - **[IndustriesEinsteinFeatureSettings](#industrieseinsteinfeaturesettings)** Represents the settings for enabling the Industries Einstein feature. - **[IntegrationProviderDef](#integrationproviderdef)** Represents an integration definition associated with a service process. Stores data for the Industries: Send Apex Async Request and Industries: Send External Async Request invocable actions. - **[Invocable Action Extension](#invocable-action-extension)** Represents extended metadata for Apex classes that are used as invocable actions or data types. This allows developers to specify how to present the action's inputs without writing custom code. - **[LearningAchievementConfig](#learningachievementconfig)** Represents the mapping details between a Learning Achievement type and a Learning Achievement record type. - **[Learning Item Type](#learning-item-type)** Represents a custom exercise type that an Enablement user takes in an Enablement program in the Guidance Center. A custom exercise type also requires a corresponding LearningItem record for the Guidance Center and corresponding EnblProgramTaskDefinition and EnblProgramTaskSubCategory records for when admins create a program in Program Builder. - **[Letterhead](#letterhead)** Represents formatting options for the letterhead in an email template. A letterhead defines the logo, page color, and text settings for your HTML email templates. Use letterheads to ensure a consistent look and feel in your company’s emails. - **[Life Science Config Category](#life-science-config-category)** Represents the category that a Life Sciences configuration record is organized into. - **[Life Science Config Record](#life-science-config-record)** Represents a configuration record for Life Sciences. This object is a child of Life Science Config Category. - **[Lightning Bolt](#lightning-bolt)** Represents the definition of a Lightning Bolt Solution, which can include custom apps, flow categories, and Experience Builder templates. - **[Lightning Message Channel](#lightning-message-channel)** Represents the metadata associated with a Lightning Message Channel. A Lightning Message Channel represents a secure channel to communicate across UI technologies, such as Lightning Web Components, Aura Components, and Visualforce. - **[Lightning Page](#lightning-page)** Represents the metadata associated with a Lightning page. A Lightning page represents a customizable screen made up of regions containing Lightning components. - **[Lightning Type](#lightning-type)** Represents a custom Lightning type. Use this type to override the default user interface to create a customized appearance based on your business requirements. Deploy this bundle to your organization to implement the overrides. - **[Lightning Web Component](#lightning-web-component)** Represents a Lightning web component bundle. A bundle contains Lightning web component resources. - **[List View](#list-view)** ListView allows you to see a filtered list of records, such as contacts, accounts, or custom objects. - **[Live Chat Sensitive Data Rule](#live-chat-sensitive-data-rule)** Represents a rule for masking or deleting data of a specified pattern. Written as a regular expression (regex). Use this object to mask or delete data of specified patterns, such as credit card, social security, or phone and account numbers. - **[Loyalty Program Setup](#loyalty-program-setup)** Represents the configuration of a loyalty program process including its parameters and rules. Program processes determine how new transaction journals are processed. When new transaction journals meet the criteria and conditions for a program process, actions that are set up in the process are triggered for the transaction journals. - **[Managed Content Type](#managed-content-type)** Represents the definition of custom content types for use with Salesforce CMS. Custom content types are displayed as forms with defined fields. - **[Marketing App Extension](#marketing-app-extension)** Represents an integration with a third-party app or service that generates prospect external activity. - **[Marketing App Extension Activity](#marketing-app-extension-activity)** Represents an Activity Type, which is a prospect activity that occurs in a third-party app and can be used in Account Engagement automations. - **[Market Segment Definition](#market-segment-definition)** Represents the field values for MarketSegmentDefinition. MarketSegmentDefinition is used to store the exportable metadata of a segment, such as segment criteria and other attributes. Developers can create segment definition packages, pass segment definition in the form of data build tool (DBT), and publish it on AgentExchange for subscriber organizations to install and instantiate these segments. - **[MktCalculatedInsightsObjectDef](#mktcalculatedinsightsobjectdef)** Represents Calculated Insight definition such as expression. - **[MktDataConnection](#mktdataconnection)** Represents the connection information of an external connector that can ingest data to Data Cloud, read data from the source, or write data to the source in Data Cloud. - **[MktDataTranObject](#mktdatatranobject)** An entity that is used to deliver (aka transport) information from the source to a target (target will be called a landing entity).This can be the schema of a file, API, Event, or other means of transporting data, such as SubscriberFile1.csv, or SubscriberCDCEvent. - **[Named Credential](#named-credential)** Represents a named credential, which specifies the URL of a callout endpoint and its required authentication parameters in one definition. A named credential can be specified as an endpoint to simplify the setup of authenticated callouts. - **[Object Source Target Map](#object-source-target-map)** Contains the object-level mappings between the source and the target objects. The source and target objects can be an MktDataLakeObject or an MktDataModelObject. For example, an Email source object can be mapped to the ContactPointEmail object. - **[Object Integration Provider Definition Mapping](#object-integration-provider-definition-mapping)** Maps structured, logical data nodes in a context definition to actual Salesforce object fields or external data sources - **[OcrSampleDocument](#ocrsampledocument)** Represents the details of a sample document or a document type that's used as a reference while extracting and mapping information from a customer form. - **[OcrTemplate](#ocrtemplate)** Represents the details of the mapping between a form and a Salesforce object using Intelligent Form Reader. - **[Outbound Network Connection](#outbound-network-connection)** Represents a private connection between a Salesforce org and a third-party data service. The connection is outbound because the callouts are going out of Salesforce. - **[Page Layout](#page-layout)** Represents the metadata associated with a page layout. - **[Path Assistant](#path-assistant)** Represents Path records. - **[Payment Gateway Provider](#payment-gateway-provider)** Represents the metadata associated with a payment gateway provider. - **[Permission Set](#permission-set)** Represents a set of permissions that's used to grant more access to one or more users without changing their profile or reassigning profiles. You can use permission sets to grant access but not to deny access. - **[Permission Set Groups](#permission-set-groups)** Represents a group of permission sets and the permissions within them. Use permission set groups to organize permissions based on job functions or tasks. Then, you can package the groups as needed. - **[Platform Cache](#platform-cache)** Represents a partition in the Platform Cache. - **[Platform Event Channel](#platform-event-channel)** Represents a channel that you can subscribe to in order to receive a stream of events. - **[Platform Event Channel Member](#platform-event-channel-member)** Represents an entity selected for Change Data Capture notifications on a standard or custom channel, or a platform event selected on a custom channel. - **[Platform Event Subscriber Configuration](#platform-event-subscriber-configuration)** Represents configuration settings for a platform event Apex trigger, including the batch size, the trigger’s running user, and parallel subscription settings. - **[Pricing Action Parameters](#pricing-action-parameters)** Represents a pricing action associated to a context definition and a pricing procedure. - **[Pricing Recipe](#pricing-recipe)** Represents one out of various data models or sets of entities of a particular cloud that'll be consumed by the pricing data store during design and run time. - **[Procedure Output Resolution](#procedure-output-resolution)** Represents the pricing resolution for an pricing element determined using strategy name and formula. - **[Process](#process)** Use Flow instead. - **[Process Flow Migration](#process-flow-migration)** Represents a process's migrated criteria and the resulting migrated flow. - **[Product Attribute Set](#product-attribute-set)** Represents the ProductAttribute information being used as and attribute such as color_c, size_c . - **[Product Specification Type](#product-specification-type)** Represents the type of product specification provided by the user to make the product terminology unique to an industry. A product specification type is associated with a product specification record type. - **[Product Specification Record Type](#product-specification-record-type)** Represents the relationship between industry-specific product specifications and the product record type. - **[Prompts (In-App Guidance)](#prompts-in-app-guidance)** Represents the metadata related to in-app guidance, which includes prompts and walkthroughs. - **[Quick Action](#quick-action)** Represents a specified create or update quick action for an object that then becomes available in the Chatter publisher. - **[Recommendation Strategy](#recommendation-strategy)** Represents a recommendation strategy. Recommendation strategies are applications, similar to data flows, that determine a set of recommendations to be delivered to the client through data retrieval, branching, and logic operations. - **[Record Action Deployment](#record-action-deployment)** Represents configuration settings for the Actions & Recommendations, Action Launcher, and Bulk Action Panel components. - **[Record Alert Data Source Expression Set Definition](#record-alert-data-source-expression-set-definition)** Represents information about the data source for a record alert and the association with an expression set definition. - **[Record Type](#record-type)** Represents the metadata associated with a record type. Record types let you offer different business processes, picklist values, and page layouts to different users. Use this metadata type to create, update, or delete record type definitions for a custom object. - **[RedirectWhitelistUrl](#redirectwhitelisturl)** Represents a trusted URL that’s excluded from redirection restrictions when the redirectionWarning or redirectBlockModeEnabled field on the SessionSettings Metadata type is set to true. - **[Referenced Dashboard](#referenced-dashboard)** Represents the ReferencedDashboard object in CRM Analytics. A referenced dashboard stores information about an externally referenced dashboard. - **[Registered External Service](#registered-external-service)** Represents a registered external service, which provides an extension or integration. - **[RelationshipGraphDefinition](#relationshipgraphdefinition)** Represents a definition of a graph that you can configure in your organization to traverse object hierarchies and record details, giving you a glimpse of how your business works. - **[Remote Site Setting](#remote-site-setting)** Represents a remote site setting. - **[Report](#report)** Represents a custom report. - **[Report Type](#report-type)** Represents the metadata associated with a custom report type. Custom report types allow you to build a framework from which users can create and customize reports. - **[ServiceProcess](#serviceprocess)** Represents a process created in Service Process Studio and its associated attributes. - **[Slack App (Beta)](#slack-app-beta)** Represents a Slack app. - **[Service Catalog Category](#service-catalog-category)** Represents the grouping of individual catalog items in Service Catalog. - **[Service Catalog Filter Criteria](#service-catalog-filter-criteria)** Represents an eligibility rule that determines if a Service Catalog user has access to a catalog item. - **[Service Catalog Item Definition](#service-catalog-item-definition)** Represents the entity associated with a specific, individual service available in the Service Catalog. - **[Service Catalog Fulfillment Flow](#service-catalog-fulfillment-flow)** Represents the flow associated with a specific catalog item in the Service Catalog. - **[Stationary Asset Environmental Source Record Type Configuration](#stationary-asset-environmental-source-record-type-configuration)** Represents the setup object that contains the mapping between the Stationary Asset Environmental Source record type and internal enums. You can primarily use this object for calculations across different record types. - **[Static Resource](#static-resource)** Represents a static resource file, often a code library in a ZIP file. - **[Streaming App Data Connector](#streaming-app-data-connector)** Represents the connection information specific to Web and Mobile Connectors. - **[Sustainability UOM](#sustainability-uom)** Represents information about the additional unit of measure values defined by a customer. - **[Sustainability UOM Conversion](#sustainability-uom-conversion)** Represents information about the unit of measure conversion for the additional fuel types defined by a customer. - **[Timeline Object Definition](#timeline-object-definition)** Represents the container that stores the details of a timeline configuration. You can use this resource with Salesforce objects to see their records' related events in a linear time-sorted view. - **[Timesheet Template](#timesheet-template)** Represents a template for creating time sheets in Field Service. - **[Transaction Processing Type](#transaction-processing-type)** Represents the processing constraint settings for a transaction processing request. - **[Translation](#translation)** Add translations to your managed packages. - **[UI Bundle](#ui-bundle)** Represents the UI of a Multi-Framework app that's built with a supported frontend framework, such as React or Angular, and runs on the Salesforce platform. - **[UI Object Relation Config](#ui-object-relation-config)** Represents the admin-created configuration of the object relation UI component. - **[User Access Policy](#user-access-policy)** Represents a user access policy. - **[Validation Rule](#validation-rule)** Represents a validation rule, which is used to verify that the data a user enters in a record is valid and can be saved. - **[Vehicle Asset Emissions Source Record Type Configuration](#vehicle-asset-emissions-source-record-type-configuration)** Represents the setup object that contains the mapping between the Vehicle Asset Emissions Source record type and internal enums. You can primarily use this object for calculations across different record types. - **[View Definition (Beta)](#view-definition-beta)** Represents a view definition on a Slack app. - **[Virtual Visit Config](#virtual-visit-config)** Represents an external video provider configuration, which relays events from Salesforce to the provider. - **[Visualforce Component](#visualforce-component)** Represents a Visualforce component. - **[Visualforce Page](#visualforce-page)** Represents a Visualforce page. - **[Wave Analytic Asset Collection](#wave-analytic-asset-collection)** A collection of CRM Analytics assets. - **[Wave Application](#wave-application)** A CRM Analytics application. - **[Wave Component](#wave-component)** A CRM Analytics dashboard component. - **[Wave Dataflow](#wave-dataflow)** A CRM Analytics data prep dataflow. - **[Wave Dashboard](#wave-dashboard)** A CRM Analytics dashboard. - **[Wave Dataset](#wave-dataset)** A CRM Analytics dataset. - **[Wave Lens](#wave-lens)** A CRM Analytics lens. - **[Wave Recipe](#wave-recipe)** A CRM Analytics data prep recipe. - **[Wave Template Bundle](#wave-template-bundle)** A CRM Analytics template bundle. - **[Wave Xmd](#wave-xmd)** The extended metadata for CRM Analytics dataset fields and their formatting for dashboards and lenses. - **[Web Store Template](#web-store-template)** Represents a configuration for creating commerce stores. - **[Workflow Alert](#workflow-alert)** WorkflowAlert represents an email alert associated with a workflow rule. - **[Workflow Field Update](#workflow-field-update)** WorkflowFieldUpdate represents a workflow field update. - **[Workflow Knowledge Publish](#workflow-knowledge-publish)** WorkflowKnowledgePublish represents Salesforce Knowledge article publishing actions and information. - **[Workflow Outbound Message](#workflow-outbound-message)** WorkflowOutboundMessage represents an outbound message associated with a workflow rule. - **[Workflow Rule](#workflow-rule)** This metadata type represents a workflow rule. - **[Workflow Task](#workflow-task)** This metadata type references an assigned workflow task. ## Account Plan Objective Measure Calculation Definition Represents the definition of a target object, rollup field, and logic for calculating the current value of a sales account plan objective measure. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, DeveloperName, MasterLabel, RollupType, Status, TargetField, TargetObject | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AccountPlanObjMeasCalcDef; Component Type in 1GP Package Manager UI: Account Plan Objective Measure Calculation Definition **Documentation:** [Sales Account Plan Objectives, Measures, and Calculation Definitions](https://help.salesforce.com/s/articleView?id=sales.account_plans_objective_measures.htm&type=5) ## Account Relationship Share Rule Determines which object records are shared, how they’re shared, the account relationship type that shares the records, and the level of access granted to the records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Name, Developer Name, Description, Account Relationship Type, Access Level, Object Type, Account to Criteria Field | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AccountRelationshipShareRule **Use Case:** To share data between external accounts. **License Requirements:** Orgs with Digital Experiences enabled can use this package. **Documentation:** _Salesforce Help:_ [Account Relationships and Account Relationship Data Sharing Rules](https://help.salesforce.com/s/articleView?id=platform.networks_partner_account_relationships_and_sharing.htm&type=5) ## Action Link Group Template Represents the action link group template. Action link templates let you reuse action link definitions and package and distribute action links. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionLinkGroupTemplate; Component Type in 1GP Package Manager UI: Action Link Group Template **Documentation:** _Salesforce Help:_ [Action Link Templates](https://help.salesforce.com/s/articleView?id=platform.action_link_group_template.htm&type=5) ## Action Plan Template Represents an instance of an action plan template. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionPlanTemplate **Documentation:** _Salesforce Help:_ [Action Plans](https://help.salesforce.com/s/articleView?id=ind.fsc_action_plans.htm&type=5) ## Actionable List Definition Represents the data source definition details associated with an actionable list. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActionableListDefinition; Component Type in 1GP Package Manager UI: ActionableListDefinition **Documentation:** _Salesforce Help:_ [Actionable Segmentation](https://help.salesforce.com/s/articleView?id=ind.actionable_segmentation.htm&type=5) ## Actionable List Key Performance Indicator Definition Represents the custom key performance indicators that are defined for a specific field in an object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes, Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ActnblListKeyPrfmIndDef; Component Type in 1GP Package Manager UI: ActnblListKeyPrfmIndDef **License Requirements:** Actionable Segmentation **Documentation:** _Salesforce Help:_ [Create Custom Key Performance Indicators](https://help.salesforce.com/s/articleView?id=ind.create_custom_kpis.htm&type=5); _Salesforce Help:_ [ActnblListKeyPrfmIndDef](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/sforce_api_objects_actnbllistkeyprfminddef.htm) ## Activation Platform Represents the ActivationPlatform configuration, such as platform name, delivery schedule, output format, and destination folder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------- | | Only Package Developer Can Edit | DataConnector, Description, LogoUrl, MasterLabel, OutputFormat, RefreshMode, Type | | Both Package Developer and Subscriber Can Edit | Enabled (only subscriber editable), IncludeSegmentNames (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | ID, OutputGrouping, PeriodicRefreshFrequency, RefreshFrequency | ### More Information **Feature Name:** Metadata Name: ActivationPlatform; Component Type in 1GP Package Manager UI: ActivationPlatform **Use Case:** Allows ISVs to specify capabilities of their Activation Platform integrations and publish it on AgentExchange for subscriber organizations to install and instantiate instances of the platform as a disparate activation target. **Considerations When Packaging** Some upgrade scenarios are not support: - Adding a new required field - Removing a previously supported ID type - Removing a previously supported optional field or required field - Changing a previously supported field property from optional to required Some update scenarios are supported and don't automatically cascade to Activation Target or Activations created before the upgrade installations: - Adding a new ID type - Adding of a new optional field - Adding a new hidden field - Value change on a previously supported hidden field To apply updates to future Activation run jobs, the user must edit and resave all Activation Targets created before the upgrade. Developers provide post-install instructions informing the subscriber of this required action anytime a change is made in a new version release. **License Requirements:** Data Cloud enabled orgs can access this package. **Post Install Steps:** An admin from the subscriber org enables the activation platform to start using this platform in Activation creations. **Documentation:** _Metadata API Developer Guide:_ [ActivationPlatform](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_activationplatform.htm) ## AffinityScoreDefinition Represents the affinity information used in calculations to analyze and categorize contacts for marketing purposes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AffinityScoreType, NumberOfMonths, NumberOfRanges, SourceFieldApiNameList, TargetFieldApiNameList, ScoreRangeList | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AffinityScoreDefinition **Documentation** ## Agent Action Represents an action, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ------------------------------------------------------------------------------------ | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No (However, actions can incorporate flows or Apex code that do have IP protection.) | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | Description, IsConfirmationRequired, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, InvocationTarget, InvocationTargetType | Action Input Fields: - CopilotAction.IsUserInput - Description - IsPII - Properties (Inherited from invocationTarget like flows or Apex code.) - Title (Inherited from invocationTarget like flows or Apex code.) - Required - Lightning.Type Action Output Fields: - Description - CopilotAction.IsDisplayable - IsPII - CopilotAction.IsUsedByPlanner - Properties (Inherited from invocationTarget like flows or Apex code.) - Title (Inherited from invocationTarget like flows or Apex code.) ### More Information **Feature Name:** Metadata Name: [GenAiFunction](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaifunction.htm); Component Type in 1GP Package Manager UI: Generative AI Function Definition **Use Case:** Provide actions that customers can add to their own topics and agents. **Considerations When Packaging** When creating an Agent Action of type Apex, the Apex class, invocable Apex method, and any invocable Apex variables must all be marked as global. If any of these are public or private, the Apex method won't appear in the list of options to add to the Agent Action, and won't be invoked by an Agent at runtime. **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [Agentforce Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_actions.htm); _Metadata API Developer Guide:_ [GenAiFunction](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaifunction.htm) ## Agent Topic Represents a topic, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, MasterLabel, Scope, AiPluginUtterances, GenAiFunctions, GenAiPluginInstructions | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, PluginType | ### More Information **Feature Name:** Metadata Name: [GenAiPlugin](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiplugin.htm); Component Type in 1GP Package Manager UI: Generative AI Plugin Definition **Use Case** Provide topics that customers can add to their own agents. Actions can be added to topics. **Considerations When Packaging** Subscribers can't edit which actions are associated with a managed-installed topic. Instead, subscribers must manually create a copy of the topic and then assign actions to their copy of the topic. We're working to improve this experience. **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [Agentforce Topics](https://help.salesforce.com/s/articleView?id=ai.copilot_topics.htm) ## AI Application Represents an instance of an AI application. For example, Einstein Prediction Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | Type | | Both Package Developer and Subscriber Can Edit | Status, ExternalId, MlExternalId | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: AIApplication **Considerations When Packaging** AIApplication is the parent entity for all Einstein configuration entities. Packaging of Einstein features must always begin with the selection of one or more AIApplications. To create a package with ML Prediction Definition, select the parent AIApplication (Type = PredictionBuilder). To create a package with ML Recommendation Definition, select the parent AIApplication (Type = RecommendationBuilder). Packaging automatically analyzes the relationships and includes the associated MLPredictionDefinitions, MLRecommendationDefinitions, and MLDataDefinitions necessary to fully define the Einstein configuration. **Documentation:** _Metadata API Developer Guide:_ [AIApplication](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_aiapplication.htm); _Salesforce Help:_ [Einstein Prediction Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_prediction_builder_lm.htm&type=5); _Salesforce Help:_ [Einstein Recommendation Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_recommendation_builder.htm&type=5) ## AI Application Config Represents additional prediction information related to an AI application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------- | | Only Package Developer Can Edit | AIApplicationId | | Both Package Developer and Subscriber Can Edit | Rank, IsInsightReasonEnabled, AIScoringMode, ExternalId | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: AIApplicationConfig **Considerations When Packaging** AIApplicationConfig is always associated with an AIApplication. Packaging of Einstein features must always begin with the selection of one or more AIApplications. To create a package with AI Application Config, select the parent AIApplication. Packaging automatically analyzes the relationships and includes the associated MLApplicationConfig, MLPredictionDefinition, MLRecommendationDefinitions, and MLDataDefinitions necessary to fully define the Einstein configuration. **Documentation:** _Metadata API Developer Guide:_ [AIApplicationConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_aiapplicationconfig.htm); _Salesforce Help:_ [Einstein Prediction Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_prediction_builder_lm.htm&type=5); _Salesforce Help:_ [Einstein Recommendation Builder](https://help.salesforce.com/s/articleView?id=sales.custom_ai_recommendation_builder.htm&type=5) ## AIUsecaseDefinition Represents a collection of fields in a Salesforce org used to define a machine learning use case and get real-time predictions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | All the AIUsecaseDefinition fields | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AIUsecaseDefinition; Component Type in 1GP Package Manager UI: AIUsecaseDefinition **Use Case** AI Usecase Definition lets you ship data that can be used to set up use cases for which you want to generate real-time predictions. This data includes machine learning models and feature extractors required to generate the real-time predictions. **License Requirements:** This feature is available with the CRM Plus license and the use case-related product’s CRM license. **Documentation:** _Industries Common Resources Developer Guide_: [AI Accelerator](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/ai_accelerator.htm); _Salesforce Help_: [AI Accelerator](https://help.salesforce.com/s/articleView?id=ind.ai_accelerator.htm&type=5) ## Analytics Analytics components include analytics applications, dashboards, dataflows, datasets, lenses, recipes, and user XMD. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (Analytics Dataflow only). All other analytics components can’t be updated. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (Analytic snapshot only). Supported in managed 2GP packages only. All other analytics components can’t be removed. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### More Information ## Analytics Visualization Represents a Tableau Next visualization. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Full Name, Is Original, Version | ### More Information **Feature Name:** Metadata Name: AnalyticsVisualization; Component Type in 1GP Package Manager UI: Analytics Visualization **License Requirements:** Tableau Next Admin or Tableau Next Analyst permission sets **Documentation:** For more information on Tableau Next visualizations, see [Build Insightful Visualizations in Tableau Next](https://help.salesforce.com/s/articleView?id=analytics.tua_create_viz.htm) in in _Salesforce Help_.. ## Analytics Workspace Represents a Tableau Next workspace. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: AnalyticsWorkspace; Component Type in 1GP Package Manager UI: Analytics Workspace **License Requirements:** Tableau Next Admin or Tableau Next Analyst permission sets **Documentation:** For more information on Tableau Next workspaces, see [Tableau Next Workspaces](https://help.salesforce.com/s/articleView?id=analytics.tua_workspace.htm) in in _Salesforce Help_.. ## Apex Class Represents an Apex Class. An Apex class is a template or blueprint from which Apex objects are created. Classes consist of other classes, user-defined methods, variables, exception types, and static initialization code. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (if not set to `global` access). Supported in both 1GP and 2GP packages. | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | API Version, Code | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexClass; Component Type in 1GP Package Manager UI: Apex Class **Considerations When Packaging** - Any Apex that is included as part of a package must have at least 75% cumulative test coverage. Each trigger must also have some test coverage. When you upload your package to AgentExchange, all tests are run to ensure that they run without errors. In addition, all tests are run when the package is installed in the installer’s org. If any test fails, the installer can decide whether to install the package. - Managed packages receive a unique namespace. This namespace is prepended to your class names, methods, variables, and so on, which helps prevent duplicate names in the installer’s org. - In a single transaction, you can only reference 10 unique namespaces. For example, suppose that you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the first package didn’t access the second package directly, the access occurs in the same transaction. It’s therefore included in the number of namespaces accessed in a single transaction. - If you’re exposing any methods as Web services, include detailed documentation so that subscribers can write external code that calls your Web service. - If an Apex class references a custom label and that label has translations, explicitly package the individual languages desired to include those translations in the package. - If you reference a custom object’s sharing object (such as MyCustomObject\_\_share) in Apex, you add a sharing model dependency to your package. Set the default org-wide access level for the custom object to Private so other orgs can install your package successfully. - The code contained in an Apex class, trigger, or Visualforce component that’s part of a managed package is obfuscated and can’t be viewed in an installing org. The only exceptions are methods declared as global. You can view global method signatures in an installing org. In addition, License Management Org users with the View and Debug Managed Apex permission can view their packages’ obfuscated Apex classes when logged in to subscriber orgs via the Subscriber Support Console. - You can use the `deprecated` annotation in Apex to identify `global` methods, classes, exceptions, enums, interfaces, and variables that can’t be referenced in later releases of a managed package. So you can refactor code in managed packages as the requirements evolve. After you create another package version as Managed - Released, new subscribers that install the latest package version can’t see the deprecated elements, while the elements continue to function for existing subscribers and API integrations. - Apex code that refers to Data Categories can’t be uploaded. - Before deleting Visualforce pages or global Visualforce components from your package, remove all references to public Apex classes and public Visualforce components. After removing the references, upgrade your subscribers to an interim package version before you delete the page or global component. **Usage Limits** The maximum number of class and trigger code units in a deployment of Apex is 7500. For more information, see [Execution Governors and Limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) in the in the _Apex Developer Guide_. . **Documentation:** _Second-Generation Managed Packaging Developer Guide:_ [Namespace-Based Visibility for Apex Classes in Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_namespace_visibility.htm); _First-Generation Managed Packaging Developer Guide:_ [About API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/about_client_security_profile.htm); _First-Generation Managed Packaging Developer Guide:_[Using Apex in Group and Professional Editions](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/dev_packages_apex_ge_pe.htm) ## Apex Sharing Reason Represents an Apex sharing reason, which is used to indicate why sharing was implemented for a custom object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------ | | Only Package Developer Can Edit | Reason Label | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Reason Name | ### More Information **Feature Name:** Metadata Name: SharingReason; Component Type in 1GP Package Manager UI: Apex Sharing Reason **Considerations When Packaging:** Apex sharing reasons can be added directly to a package, but are only available for custom objects. **Documentation:** _Metadata API Developer Guide_: [SharingReason](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_apexsharingreason.htm) ## Apex Trigger Represents an Apex trigger. A trigger is Apex code that executes before or after specific data manipulation language (DML) events occur, such as before object records are inserted into the database, or after records have been deleted. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | API Version, Code | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexTrigger; Component Type in 1GP Package Manager UI: Apex Trigger **Documentation:** _Apex Developer Guide:_ [Triggers](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers.htm) ## App Framework Template Bundle Represents the app framework template bundle. Use these templates for Data Cloud and Tableau Next assets. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Label, MaxAppCount | | Both Package Developer and Subscriber Can Edit | Description, TemplateBadgeIcon | | Neither Package Developer or Subscriber Can Edit | AssetVerion, TemplateType | ### More Information **Feature Name:** Metadata Name: AppFrameworkTemplateBundle; Component Type in 1GP Package Manager UI: App Framework Template Bundle **Considerations When Packaging** Data Cloud and Tableau Next assets are installed in subscriber orgs via templates using the AppFrameworkTemplateBundle. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. **License Requirements:** Tableau Included App Manager permission set ## Application Subtype Definition Represents a subtype of an application within an application domain. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Developer Name, Description, Application Usage Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ApplicationSubtypeDefinition **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentSubtypeDefinition**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/tooling_api_objects_applicationsubtypedefinition.htm) ## AssessmentConfiguration Represents a configuration for Assessment component. An AssessmentConfiguration entry indicates configuration for user flows such as sending out emails or reminder actions on assessments initiated by the patient. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in managed 1GP packages only. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentConfiguration; Component Type in 1GP Package Manager UI: AssessmentConfiguration **Documentation:** _Health Cloud Developer Guide:_ [AssessmentConfiguration](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_assessmentconfiguration.htm) ## AssessmentQuestion Represents the container object that stores the questions required for an assessment. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | All except DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentQuestion **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentQuestion**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_assessmentquestion.htm) ## AssessmentQuestionSet Represents the container object for Assessment Questions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | All except DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: AssessmentQuestionSet **Documentation:** _Industries Common Resources Developer Guide:_ [**AssessmentQuestionSet**](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_assessmentquestionset.htm) ## Aura Component Represents an Aura definition bundle. A bundle contains an Aura definition, such as an Aura component, and its related resources, such as a JavaScript controller. The definition can be a component, application, event, interface, or a tokens collection. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. You can build Lightning components using two programming models: the Lightning Web Components model, and the original Aura Components model. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | When a package developer removes an Aura or Lightning web component from a package, the component remains in a subscriber’s org after they install the upgraded package. The administrator of the subscriber’s org can delete the component, if desired. This behavior is the same for a Lightning web component or an Aura component with a `public` or `global` access value. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Aura Component:** Metadata Name: AuraDefinitionBundle; Component Type in 1GP Package Manager UI: Aura Component Bundle **Documentation:** [Lightning Aura Components Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/) ## Batch Calc Job Definition Represents a Data Processing Engine definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | Entire Data Processing Engine definition | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BatchCalcJobDefinition; Component Type in 1GP Package Manager UI: Batch Calculation Job Definition **Use Case** Data Processing Engine helps you transform data that's available in your Salesforce org and write back the transformation results as new or updated records. You can transform the data for standard and custom objects using Data Processing Engine definitions. **License Requirements:** Either Financial Services Cloud, Manufacturing Cloud, Loyalty Management, Net Zero Cloud, or Rebate Management; Data Pipelines **Documentation:** _Salesforce Help:_ [Data Processing Engine](https://help.salesforce.com/s/articleView?id=ind.dpe_intro.htm&type=5) ## Batch Process Job Definition Represents the details of a Batch Management job definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------- | | Only Package Developer Can Edit | Entire Batch Management job | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BatchProcessJobDefinition; Component Type in 1GP Package Manager UI: Batch Process Job Definition **Use Case** Automate the processing of records in scheduled flows with Batch Management. With Batch Management, you can process a high volume of standard and custom object records. **License Requirements:** Either Loyalty Management, Manufacturing Cloud, or Rebate Management; System Administrator Profile **Documentation:** _Salesforce Help:_ [Batch Management](https://help.salesforce.com/s/articleView?id=ind.concept_batch_management.htm&type=5) ## Benefit Action Represents details of an action that can be triggered for a benefit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Entire Benefit Action record | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: BenefitAction; Component Type in 1GP Package Manager UI: Benefit Action **Use Case:** Benefit Actions are actions that can be triggered for a loyalty program benefit. **License Requirements:** Loyalty Management permission set license **Documentation:** _Salesforce Help:_ [Benefit Action](https://help.salesforce.com/s/articleView?id=xcloud.benefit_actions.htm&type=5) ## Bot Template Represents the configuration details for a specific Einstein Bot template, including dialogs and variables. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Bot Dialog Groups, Bot Dialogs, Conversation Context Variables, Conversation Languages, Conversation Definition Goals, Conversation System Dialogs, Conversation Variables, Description, Entry Dialog, Icon, Main Menu Dialog, Label, MlDomain, Rich Content Enabled | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BotTemplate; Component Type in 1GP Package Manager UI: Bot Template **Documentation:** [Salesforce Help: Create an Einstein Bot Template](https://help.salesforce.com/s/articleView?id=service.bots_service_create_new_template.htm&type=5); [Salesforce Help: Create a Template from an Einstein Bot](https://help.salesforce.com/s/articleView?id=service.bots_service_create_template_bot.htm&type=5); [Salesforce Help: Package an Einstein Bot Template](https://help.salesforce.com/s/articleView?id=service.bots_service_create_package_template.htm&type=5); [Metadata API Developer Guide: BotTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_bottemplate.htm) ## Branding Set Represents the definition of a set of branding properties for an Experience Builder site, as defined in the Theme panel in Experience Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------- | | Only Package Developer Can Edit | brandingSetProperty, description, masterLabel, type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BrandingSet **Relationship to Other Components** BrandingSet can’t be added to a package by itself. BrandingSet is included automatically in a package if it’s referenced by another object in the package, such as CommunityThemeDefinition, LightningExperienceTheme, or EmbeddedServiceMenuSettings. **Documentation:** _Salesforce Help_: [Use Branding Sets in Experience Builder](https://help.salesforce.com/s/articleView?id=experience.community_designer_brandsets.htm&type=5) ## Briefcase Definition Represents a briefcase definition. A briefcase makes selected records available for specific users and groups to view when they’re offline in the Salesforce Field Service mobile app for iOS and Android. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------- | | Only Package Developer Can Edit | Entire briefcase | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Full Name | ### More Information **Feature Name:** Metadata Name: BriefcaseDefinition; Component Type in 1GP Package Manager UI: Briefcase Definition **Considerations When Packaging** As a best practice, package Briefcase Definition with IsActive set to false. If you package Briefcase Definition with IsActive set to true, the package installation fails if installing the package exceeds any limits. **Usage Limits** All [Briefcase Builder limits](https://help.salesforce.com/s/articleView?id=xcloud.briefcase_builder_limits_considerations.htm&type=5) apply to a Briefcase Definition package. apply to a Briefcase Definition package. **Relationship to Other Components** After you install the package, assign the briefcase to the application that the briefcase's data is for. **Documentation:** _Salesforce Help:_ [Briefcase Builder](https://help.salesforce.com/s/articleView?id=xcloud.briefcase_builder_overview.htm&type=5) ## Building Energy Intensity Record Type Configuration Represents the setup object that contains the mapping between the Building Energy Intensity Record record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BldgEnrgyIntensityCnfg; Component Type in 1GP Package Manager UI: Building Energy Intensity Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new stationary asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting - Manage Building Energy Intensity **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Benchmark Building Energy Intensity Data](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_manage_bei.htm&type=5) ## Business Process The BusinessProcess metadata type enables you to display different picklist values for users based on their profile. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BusinessProcess **Use Case:** You can use this component to define different picklist values that you associate with record types. **Relationship to Other Components:** Record types of corresponding entities. **Documentation:** _Salesforce Help:_ [Tailor Business Processes to Different Users Using Record Types](https://help.salesforce.com/s/articleView?id=platform.customize_recordtype.htm&type=5) ## Business Process Group Represents the surveys used to track customers’ experiences across different stages in their lifecycle. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | All Business Process Group fields including Business Process Definition and Business Process Feedback. | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Developer Name, Customer Satisfaction Metric | ### More Information **Feature Name:** Metadata Name: BusinessProcessGroup; Component Type in 1GP Package Manager UI: Business Process Group **Use Case** Business Process Group lets you ship groupings relevant to survey metrics that are captured as part of any purchase or product lifecycle. For a specific business process group, you can define different stages and associate relevant questions from one or more surveys for reporting purposes. **License Requirements:** This feature is available with the Feedback Management - Growth license. **Relationship to Other Components:** This feature can be used in conjunction with Surveys and Survey Invitation Rules Flow types, and their corresponding dependencies. **Documentation:** _Metadata API Developer Guide_: [BusinessProcessGroup](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_businessprocessgroup.htm); _Salesforce Help_: [Track Satisfaction Across a Customer's Lifecycle](https://help.salesforce.com/s/articleView?id=xcloud.task_customer_lifecycle_maps.htm&type=5) ## Business Process Type Definition Define the types of business processes that are applied to a rule. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Developer Name, Description, Application Usage Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: BusinessProcessTypeDefinition ## Care Benefit Verify Settings Represents the configuration settings for benefit verification requests. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, ServiceApexClass, ServiceNamedCredential, UriPath, isDefault, GeneralPlanServiceTypeCode, ServiceTypeSourceSystem, OrganizationName, DefaultNpi, CodeSetType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareBenefitVerifySettings; Component Type in 1GP Package Manager UI: Care Benefit Verification Settings **Use Case:** Provides out-of-the-box configuration settings for benefit verification requests in Health Cloud. **License Requirements:** Industries Health Cloud **Relationship to Other Components:** CareBenefitVerifySettings can contain ApexClass as well as NamedCredentials. **Documentation:** _Health Cloud Developer Guide_: [CareBenefitVerifySettings](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carebenefitverifysettings.htm) ## Care Limit Type Defines the characteristics of limits on benefit provision. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | LimitType, MetricType, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareLimitType; Component Type in 1GP Package Manager UI: Care Limit Type **Use Case:** Provide the characteristics of limits on benefit provision in Health Cloud. **License Requirements:** Industries Health Cloud Add On or an org with a Health Cloud Financial Data Platform license **Documentation:** _Health Cloud Developer Guide_: [CareLimitType](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carelimittype.htm) ## Care Request Configuration Represents the details for a record type such as service request, drug request, or admission request. One or more record types can be associated with a care request. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, CareRequestType, CareRequestRecordType, CareRequestRecords, IsDefaultRecordType | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareRequestConfiguration; Component Type in 1GP Package Manager UI: Care Request Configuration **Use Case:** Provides the details for a record type such as a service request, drug request, or admission request in Health Cloud. **License Requirements:** Industries Health Cloud Add On an org with a Health Cloud Utilization Mgmt Platform license **Relationship to Other Components** Ensure that the record type specified in the Case Record Type field in CareRequestConfiguration is available in the subscriber org. Otherwise, the package must include the record type. **Documentation:** _Health Cloud Developer Guide_: [CareRequestConfiguration](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/tooling_api_objects_carerequestconfiguration.htm) ## Care System Field Mapping Represents a mapping from source system fields to Salesforce target entities and attributes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------- | | Only Package Developer Can Edit | External ID Field, Is Active, Label, Source System, Target Object | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CareSystemFieldMapping; Component Type in 1GP Package Manager UI: Care System Field Mapping **Use Case:** Provides an out-of-the-box mapping for an external system to Salesforce for the Care Program Enrollment or Remote Monitoring features in Health Cloud. **License Requirements:** Industries Health Cloud **Documentation:** _Health Cloud Developer Guide_: [CareSystemFieldMapping](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/sforce_api_objects_caresystemfieldmapping.htm) ## Channel Layout Represents the metadata associated with a communication channel layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ChannelLayout; Component Type in 1GP Package Manager UI: Communication Channel Layout **Considerations When Packaging:** ChannelLayout can only be installed in Salesforce Classic orgs with Knowledge enabled.; ChannelLayout includes the article type `*__kav`, which is not supported by Lightning Knowledge., which is not supported by Lightning Knowledge.; If you try to install ChannelLayout into an org with Lightning Knowledge enabled, this message is displayed: “When Lightning Knowledge is enabled, you can’t add an article type”. **License Requirements:** Enable Knowledge in Salesforce Classic orgs. **Documentation:** [Salesforce Knowledge Developer Guide: ChannelLayout](https://developer.salesforce.com/docs/atlas.en-us.knowledge_dev.meta/knowledge_dev/meta_articletype_channellayout.htm) ## Chatter Extension Represents the metadata used to describe a Rich Publisher App that’s integrated with the Chatter publisher. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | Description, Header Text, Hover Text, Icon, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Composition CMP, Render CMP, Type | ### More Information **Feature Name:** Metadata Name: ChatterExtension **Documentation:** _Metadata API Developer Guide:_ [ChatterExtension](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_chatterextensions.htm); _Object Reference for the Salesforce Platform:_ [ChatterExtension](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_chatterextension.htm) ## Claim Financial Settings Represents the configuration settings for Insurance Claim Financial Services. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Claim Coverage Pending Authority Status, Claim Coverage Payment Detail Pending Authority Status, Claim Pending Authority Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ClaimFinancialSettings **Documentation:** _Salesforce Help:_ [Claim Financial Settings](https://help.salesforce.com/s/articleView?id=ind.insurance_finauth_claim_financial_settings.htm) ## CommunicationChannelType Represents the type of communication channel, such as WhatsApp and SMS, to use for referral promotions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: CommunicationChannelType **Use Case:** Use WhatsApp as a communication channel for referral promotions. **License Requirements:** Referral Marketing permission set license **Documentation:** _Salesforce Help:_ [Communication Assets](https://help.salesforce.com/s/articleView?id=mktg.referral_promotion_wizard_step_content.htm&type=5) ## Community Template Definition Represents the definition of an Experience Builder site template. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CommunityTemplateDefinition; Component Type in 1GP Package Manager UI: Lightning Community Template **Use Case:** Share or distribute your Experience Builder site templates. **License Requirements:** Customize Application user permission; Create and Set Up Experiences user permission; View Setup and Configuration user permission **Relationship to Other Components:** If you add CommunityTemplateDefinition to a package, you must also add CommunityThemeDefinition to the package. **Documentation:** _Salesforce Help:_ [Export a Customized Experience Builder Template for a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_template.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Community Theme Definition Represents the definition of a theme for an Experience Builder site. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CommunityThemeDefinition; Component Type in 1GP Package Manager UI: Lightning Community Theme **Use Case:** Share or distribute your Experience Builder site themes. **License Requirements:** Customize Application user permission; Create and Set Up Experiences user permission; View Setup and Configuration user permission **Relationship to Other Components:** CommunityThemeDefinition must contain a BrandingSet.; CommunityThemeDefinition can be added to a package without a CommunityTemplateDefinition, but CommunityTemplateDefinition must contain a CommunityThemeDefinition to be added to a package. **Documentation:** _Salesforce Help:_ [Export a Customized Experience Builder Theme for a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_theme.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Compact Layout Represents the metadata associated with a compact layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CompactLayout; Component Type in 1GP Package Manager UI: Compact Layout **Documentation:** _Metadata API Developer Guide:_ [CompactLayout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_compactlayout.htm) ## Conditional Formatting Ruleset Represents a set of rules that define the style and visibility of conditional field formatting on Dynamic Forms-enabled Lightning page field instances. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Conditional formatting ruleset | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: UiFormatSpecificationSet; Component Type in 1GP Package Manager UI: UI Format Specification Set **Relationship to Other Components:** You can only assign a conditional formatting ruleset to a field on a Dynamic Forms-enabled [Lightning page](#lightning-page).. **Documentation:** _Salesforce Help:_ [Conditional Field Formatting in Lightning App Builder](https://help.salesforce.com/s/articleView?id=platform.conditional_formatting_overview.htm&type=5); _Metadata API Developer Guide:_ [UiFormatSpecificationSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_uiformatspecificationset.htm) ## Connected App Represents a connected app configuration. A connected app enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Access Method, Canvas App URL, Callback URL, Connected App Name, Contact Email, Contact Phone, Description, Icon URL, Info URL, Trusted IP Range, Locations, Logo Image URL, OAuth Scopes | | Both Package Developer and Subscriber Can Edit | ACS URL, Entity ID, IP Relaxation, Mobile Start URL, Permitted Users, Refresh Token Policy, SAML Attributes, Service Provider Certificate, Start URL, Subject Type | | Neither Package Developer or Subscriber Can Edit | API Name, Created Date/By, Consumer Key, Consumer Secret, Installed By, Installed Date, Last Modified Date/By, Version | ### More Information ## Context Definition A context definition defines the relationship between the nodes and the attributes within each node. For efficient data access, users can use nodes and attributes to easily access the relevant data from the mapped data source. Various Salesforce products offer predefined context definitions based on their use case. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component doesn’t contain any active context definitions. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Standard Context Definitions | ### More Information **Feature Name:** Metadata Name: ContextDefinition; Component Type in 1GP Package Manager UI: Context Definition **Documentation:** _Industries Common Resources Developer Guide:_ [Context Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_contextdefinition.htm); _Salesforce Help:_ [Context Service](https://help.salesforce.com/s/articleView?id=ind.context_service_context_definitions.htm&type=5) ## Contract Type A contract type is used to group contracts so that they exhibit similar characteristics. For example, the lifecycle states, the people who access, the templates and clauses used. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Both Package Developer and Subscriber Can Edit | Is Default, Sub Types | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ContractType **Use Case:** Allows admin users to modify Contract Type properties. **License Requirements:** CLM Admin Permission Set (CLM User PSL). **Documentation:** _Salesforce Contracts Developer Guide:_ [ContractType](https://developer.salesforce.com/docs/atlas.en-us.clm_developer_guide.meta/clm_developer_guide/meta_contracttype.htm) ## Conversation Channel Definition Represents the conversation channel definition that’s implemented for Interaction Service for Bring Your Own Channel and Bring Your Own Channel for CCaaS messaging channels. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Connected App, Description, Label, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ConversationChannelDefinition; Component Type in 1GP Package Manager UI: ConversationChannelDefinition **Use Case:** To enable and set up Bring Your Own Channel, integrating third-party messaging services with Salesforce.; To enable and set up Bring Your Own Channel for Contact Center as a Service (CCaaS), integrating a third party CCaaS provider with Salesforce. **License Requirements:** Service Cloud license with Digital Engagement add-on license **Post Install Steps:** Set up and enable Bring Your Own Channel or Bring Your Own Channel for CCaaS. **Relationship to Other Components:** Linked to ConversationVendorInfo. **Documentation:** _Salesforce Developer Documentation:_ [Bring Your Own Channel](https://developer.salesforce.com/docs/service/messaging-partner/overview); _Salesforce Developer Documentation:_ [Bring Your Own Channel for CCaaS](https://developer.salesforce.com/docs/service/messaging-byoc-ccaas/overview); _Salesforce Help:_ [Set Up Bring Your Own Channel](https://help.salesforce.com/s/articleView?id=service.partner_messaging_intro.htm&type=5); _Salesforce Help:_ [Set Up Bring Your Own Channel for CCaaS](https://help.salesforce.com/s/articleView?id=service.byoc_ccaas_setup.htm&type=5) ## Conversation Vendor Info This setup object connects the partner vendor system to the Service Cloud feature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ConversationVendorInfo; Component Type in 1GP Package Manager UI: ConversationVendorInfo **Use Case:** Include information about a Service Cloud Voice implementation. **License Requirements:** Enable Service Cloud Voice in your org. **Documentation:** _Service Cloud Voice for Partner Telephony Developer Guide:_ [ConversationVendorInfo](https://developer.salesforce.com/docs/atlas.en-us.voice_pt_developer_guide.meta/voice_pt_developer_guide/sforce_api_objects_conversationvendorinfo.htm); _Object Reference for the Salesforce Platform:_ [ConversationVendorInfo](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_conversationvendorinfo.htm) ## CORS Allowlist Represents an origin in the CORS allowlist. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Url pattern | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CorsWhitelistOrigin; Component Type in 1GP Package Manager UI: CORS Allowed Origin List **Use Case** Customers can add a URL pattern that includes an HTTPS protocol and a domain name. Including a port number is optional. The wildcard character (\*) is supported only for the second-level domain name, for example, `https://*.example.com`. . **Documentation:** _Salesforce Help:_ [Enable CORS for OAuth Endpoints](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_endpoints_cors.htm&type=5); _Salesforce Help:_ [Configure Salesforce CORS Allowlist](https://help.salesforce.com/s/articleView?id=xcloud.extend_code_cors.htm&type=5) ## CSP Trusted Site Represents a trusted URL. For each CspTrustedSite component, you can specify Content Security Policy (CSP) directives and permissions policy directives. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | context, description, endpointUrl, isActive, isApplicableToConnectSrc, isApplicableToFontSrc, isApplicableToFrameSrc, isApplicableToImgSrc, isApplicableToMediaSrc, isApplicableToStyleSrc | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CspTrustedSite; Component Type in 1GP Package Manager UI: CspTrustedSite **Use Case** The Lightning Component framework uses Content Security Policy ( [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)) to impose restrictions on content. The main objective of CSP is to help prevent cross-site scripting ( ) to impose restrictions on content. The main objective of CSP is to help prevent cross-site scripting ( [XSS](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/%3Chttps://www.owasp.org/index.php/Cross-site_Scripting_(XSS)>)) and other code injection attacks. If your package includes sites or pages that load content from an external (non-Salesforce) server or via a WebSocket connection, add the external server as a CSP trusted site. Each CSP trusted site can apply to Experience Cloud sites, Lightning Experience pages, custom Visualforce pages, or all three. ) and other code injection attacks. If your package includes sites or pages that load content from an external (non-Salesforce) server or via a WebSocket connection, add the external server as a CSP trusted site. Each CSP trusted site can apply to Experience Cloud sites, Lightning Experience pages, custom Visualforce pages, or all three. **Considerations When Packaging** When you include the CspTrustedSite component in a package, the permissions for the third-party APIs and Websocket connections apply to sites and pages across the org. Because this component modifies security, we don’t recommend including CspTrustedSite components in packages. Instead, we recommend that you instruct customers to use the CSP Trusted Sites Setup page or the CSPTrustedSites metadata API type to add the URLs to their allowlist as part of activating your package. If you choose to include CspTrustedSite components in your package, disclose this change prominently in your package documentation to ensure that your customers are aware of the security modification. You can’t load JavaScript resources from a third-party site, even if it’s a CSP Trusted Site. To use a JavaScript library from a third-party site, add it to a static resource, and then add the static resource to your component. After the library is loaded from the static resource, you can use it as normal. CSP isn’t enforced by all browsers. For a list of browsers that enforce CSP, see [caniuse.com](https://caniuse.com). . **Usage Limits** CspTrustedSite components are available in API version 39.0 and later. Multiple properties and enumeration values are available in later API versions. For details, see CspTrustedSite in the _Metadata API Developer Guide_. . For Experience Builder sites, if the HTTP header size is greater than 8 KB, the directives are moved from the CSP header to the `` tag. To avoid errors from infrastructure limits, ensure that the HTTP header size doesn’t exceed 3 KB per context. tag. To avoid errors from infrastructure limits, ensure that the HTTP header size doesn’t exceed 3 KB per context. **Relationship to Other Components:** This component can be used only in conjunction with an Aura or Lightning Web Runtime (LWR) page for an Experience Cloud site, a [Lightning Page](#lightning-page), or a , or a [Visualforce page](#visualforce-page).. **Documentation:** _Salesforce Help:_ [Manage CSP Trusted Sites](https://help.salesforce.com/s/articleView?id=xcloud.security_trusted_urls_manage.htm&type=5); _Metadata API Developer Guide_: [CspTrustedSites](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_csptrustedsite.htm) ## Custom Application Represents a custom application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Show in Lightning Experience (Salesforce Classic only), Selected Items (Lightning Experience only), Utility Bar (Lightning Experience only) | | Both Package Developer and Subscriber Can Edit | All attributes, except App Name and Show in Lightning Experience (Salesforce Classic only), All attributes, except Developer Name, Selected Items, and Utility Bar (Lightning Experience only) | | Neither Package Developer or Subscriber Can Edit | App Name (Salesforce Classic only), Developer Name (Lightning Experience only) | ### More Information **Feature Name:** Metadata Name: CustomApplication **Documentation:** _Metadata API Developer Guide:_ [CustomApplication](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customapplication.htm) ## Custom Button or Link Represents a custom link defined in a home page component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Behavior, Button or Link URL, Content Source, Description, Display Checkboxes, Label, Link Encoding | | Both Package Developer and Subscriber Can Edit | Height, Resizeable, Show Address Bar, Show Menu Bar, Show Scrollbars, Show Status Bar, Show Toolbars, Width, Window Position | | Neither Package Developer or Subscriber Can Edit | Display Type, Name | ### More Information **Feature Name:** Metadata Name: WebLink, CustomPageWebLink **Documentation:** _Salesforce Help:_ [Custom Buttons and Links](https://help.salesforce.com/s/articleView?id=platform.customize_enterprise.htm&type=5) ## Custom Console Components Represents a custom console component (Visualforce page) assigned to a CustomApplication that is marked as a Salesforce console. Custom console components extend the capabilities of Salesforce console apps. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. A package that has a custom console component can only be installed in an org with the Service Cloud license or Sales Console permission enabled. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomApplicationComponent; Component Type in 1GP Package Manager UI: Custom Console Component **Documentation:** _Metadata API Developer Guide:_ [CustomApplicationComponent](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customapplicationcomponent.htm); _Salesforce Help:_ [Create Console Components in Salesforce Classic](https://help.salesforce.com/s/articleView?id=service.console2_components_create_overview.htm&type=5) ## Custom Field on Standard or Custom Object Represents the metadata associated with a field. Use this metadata type to create, update, or delete custom field definitions on standard or custom objects. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Auto-Number Display Format, Decimal Places, Description, Default Value, Field Label, Formula, Length, Lookup Filter, Related List Label, Required, Roll-Up Summary Filter Criteria | | Both Package Developer and Subscriber Can Edit | Chatter Feed Tracking, Help Text, Mask Type, Mask Character, Sharing Setting, Sort Picklist Values, Track Field History | | Neither Package Developer or Subscriber Can Edit | Child Relationship Name, Data Type, External ID, Field Name, Roll-Up Summary Field, Roll-Up Summary Object, Roll-Up Summary Type, Unique | ### More Information - Developers can add required and universally required custom fields to managed packages as long as they have default values. - Auto-number type fields and required fields can’t be added after the object is included in a Managed - Released package. - Subscriber orgs can’t install roll-up summary fields that summarize detail fields set to protected. ## Custom Field on Custom Metadata Type Represents a custom fields on the custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ## Custom Field Display Represents the CustomFieldDisplay view type assigned to product attribute custom fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomFieldDisplay **License Requirements:** A B2B Commerce or D2C Commerce license and access to Commerce objects is required. **Documentation:** _Salesforce Help:_ [Create Attributes for Product Variations in Commerce Cloud](https://help.salesforce.com/s/articleView?id=commerce.comm_config_att_set.htm) ## Custom Help Menu Section Represents the section of the Lightning Experience help menu that the admin added to display custom, org-specific help resources for the org. The custom section contains help resources added by the admin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: CustomHelpMenuSection **Documentation:** _Metadata API Developer Guide:_ [CustomHelpMenuSection](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customhelpmenusection.htm) ## Custom Index Represents an index used to increase the speed of queries. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No. It can only be removed if the associated custom field is removed. | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: CustomIndex; Component Type in 1GP Package Manager UI: Custom Index **Considerations When Packaging:** Subscribers can remove the custom index using Metadata API only. **Documentation:** _Best Practices for Deployments with Large Data Volumes:_ [Indexes](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_indexes.htm) ## Custom Label The CustomLabels metadata type allows you to create custom labels that can be localized for use in different languages, countries, and currencies. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------- | | Only Package Developer Can Edit | Category, Short Description, Value | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: CustomLabels **Considerations When Packaging** If a label is translated, the language must be explicitly included in the package for the translations to be included in the package. Subscribers can override the default translation for a custom label. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomLabels](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customlabels.htm) ## Custom Metadata Type Records Represents a record of a custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in managed 1GP if protected, and managed 2GP whether protected or not. | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: CustomObject This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. **Usage Limits** Deprecated custom metadata type records count against the subscriber’s org limit. When removing custom metadata type records from a second-generation managed package, encourage subscribers to delete the deprecated records from their org. If the subscriber org reaches their org limit for custom metadata type records, package upgrades that include new custom metadata type records fail. For details see [Custom Metadata and Allocations and Usage Calculations](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_limits.htm&type=5) in in _Salesforce Help_. . **Documentation:** _Salesforce Help:_ [Package Custom Metadata Types and Records](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_package_install.htm&type=5) ## Custom Metadata Type Represents a record of a custom metadata type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### More Information Second-generation managed packages (2GP) include the fields and records for custom metadata types that you add. You can’t add fields directly to an existing package after the package version is promoted. If you create multiple packages that share a namespace, then layouts and records can be in separate packages. Custom fields on the custom metadata type must be in the same package. You can add fields to a custom metadata type by publishing an extension to the existing package, creating an entity relationship field, and mapping the field to the custom metadata type in your extension. See [Add Custom Metadata Type Fields to Existing Packages](https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_add_fields_packages.htm&type=5). This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Custom Notification Type Represents the metadata associated with a custom notification type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------- | | Only Package Developer Can Edit | Desktop, Mobile | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomNotificationType; Component Type in 1GP Package Manager UI: Custom Notification Type **License Requirements:** Database.com editions don’t have permission to access this component. **Usage Limits** You can package up to 500 custom notification types, but keep in mind that subscriber orgs are limited to a total of 500 custom notification types. The subscriber org limit is shared across namespaces. A subscriber org can execute up to 10,000 notification actions per hour. **Documentation:** _Salesforce Help:_ [Create and Send Custom Desktop or Mobile Notifications](https://help.salesforce.com/s/articleView?id=platform.notif_builder_custom.htm&type=5); _Salesforce Help:_ [Considerations for Processes that Send Custom Notifications](https://help.salesforce.com/s/articleView?id=platform.process_limits_customnotification.htm&type=5) ## Custom Object Represents a custom object that stores data unique to an org or an external object that maps to data stored outside an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Label, Plural Label, Record Name, Record Name Display Format, Starts with a Vowel Sound | | Both Package Developer and Subscriber Can Edit | Allow Activities, Allow Reports, Available for Customer Portal, Context-Sensitive Help Setting, Default Sharing Model, Development Status, Enable Divisions, Enhanced Lookup, Grant Access Using Hierarchy, Search Layouts, Track Field History | | Neither Package Developer or Subscriber Can Edit | Object Name, Record Name Data Type | ### More Information **Feature Name:** Metadata Name: CustomObject; Component Type in 1GP Package Manager UI: Custom Object **Considerations When Packaging** If a developer enables the Allow Reports or Allow Activities attributes on a packaged custom object, the subscriber’s org also has these features enabled during a package upgrade. After it’s enabled in a Managed - Released package, the developer and the subscriber can’t disable these attributes. Standard button and link overrides are also packageable. In your extension package, if you want to access history information for custom objects contained in the base package, work with the base package owner to: 1. Enable history tracking in the release org of the base package. 2. Create a new version of the base package. 3. Install the new version of the base package in the release org of the extension package to access the history tracking info. As a best practice, don’t enable history tracking for custom objects contained in the base package directly in the extension package’s release org. Doing so can result in an error when you install the package and when you create patch orgs for the extension package. This component can be marked as protected. For more details, see This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) and and [Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_hide_custom_objects_permissions.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) ## Custom Object Translation This metadata type allows you to translate custom objects for a variety of languages. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All attributes except Description of WorkflowTask, Help of CustomField, PicklistValueTranslation, and MasterLabel of LayoutSection. | | Both Package Developer and Subscriber Can Edit | Description of WorkflowTask, Help of CustomField, PicklistValueTranslation, MasterLabel of LayoutSection | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomObjectTranslation **Relationship to Other Components** When you create a first-generation managed package and add the [Translation](#translation) component, the Custom Object Translation component is automatically added to your package. component, the Custom Object Translation component is automatically added to your package. When you create a second-generation managed package, you must add Custom Object Translation to your package, even if you've already added the Translation component. **Documentation:** _Metadata API Developer Guide:_ [CustomObjectTranslation](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customobjecttranslation.htm) ## Custom Permission Represents a permission that grants access to a custom feature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Connected App, Description, Label, Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: CustomPermission; Component Type in 1GP Package Manager UI: Custom Permission **Considerations When Packaging** If you deploy a change set with a custom permission that includes a connected app, the connected app must already be installed in the destination org. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) and and [Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_hide_custom_objects_permissions.htm) in the in the _First-Generation Managed Packaging Developer Guide_. . **Documentation:** _Metadata API Developer Guide:_ [CustomPermission](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_custompermission.htm) ## Custom Tab Represents a custom tab. Custom tabs let you display custom object data or other web content in Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Encoding, Has Sidebar, Height, Label, S-control, Splash Page Custom Link, Type, URL, Width | | Both Package Developer and Subscriber Can Edit | Tab Style | | Neither Package Developer or Subscriber Can Edit | Tab Name | ### More Information **Feature Name:** Metadata Name: CustomTab **Considerations When Packaging** - The tab style for a custom tab must be unique within your app. However, it doesn’t have to be unique within the org where it’s installed. A custom tab style doesn’t conflict with an existing custom tab in the installer’s environment. - To provide custom tab names in different languages, from Setup, in the Quick Find box, enter `Rename Tabs and Labels`, then select **Rename Tabs and Labels**. **Documentation:** _Metadata API Developer Guide:_ [CustomTab](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_tab.htm) ## Dashboard Represents a dashboard. Dashboards are visual representations of data that allow you to see key metrics and performance at a glance. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Dashboard Unique Name | | Neither Package Developer or Subscriber Can Edit | Dashboard Unique Name | ### More Information **Feature Name:** Metadata Name: Dashboard; Type in 1GP Package Manager UI: Dashboard **Considerations When Packaging** Developers of managed packages must consider the implications of introducing dashboard components that reference reports released in a previous version of the package. If the subscriber deleted the report or moved the report to a personal folder, the dashboard component referencing the report is dropped during the installation. Also, if the subscriber has modified the report, the report results can impact what displays in the dashboard component. As a best practice, release a dashboard and the related reports in the same version. **Documentation:** _Metadata API Developer Guide:_ [Dashboard](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_dashboard.htm) ## DataCalcInsightTemplate Represents the object template for data calculations and insights of Data Cloud objects in DataCalcInsightTemplate. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataCalcInsightTemplate; Component Type in 1GP Package Manager UI: Calculated Insight Template **Use Case:** DataCalcInsightTemplate represents the data calculations and insights for objects of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. A calculated insight template is added to a package when you add a data calculation and insight into a data kit, and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Calculated Insight Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datacal_insight_template.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataCleanRoomProvider Represents a clean room provider configuration that defines the clean room collaboration details, including templates and the platform used for secure data collaboration in Data 360. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------- | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer nor Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataCleanRoomProvider; Component Type in 2GP Package Manager UI: Data Kit Package Definition **Use Case** Clean room providers (Partners and ISVs) include DataCleanRoomProvider in a DataKit which can be added to a managed package to offer clean room collaboration templates to consumers via AgentExchange. Consumers install the package to initiate a collaboration with the provider using pre-defined use case templates. **Considerations When Packaging** - Providers need a Data Cloud Developer edition org to create and publish a clean room package. - The package name must be unique. The UI may not display a clear error for duplicate package names. If you encounter an issue, check your browser’s Network tab for the specific conflict error. - The provider logo URL must be a publicly accessible URL in an appropriate image format (such as .png). If the URL is not accessible externally, the UI falls back to a standard icon on the Collaboration Summary screen for consumers. - Data 360 clean rooms don't support cross-geo collaboration (for example, AMER to APAC or EMEA is not supported). Cross-region collaboration within the same geo is supported. - This feature is not available in Government Cloud. **License Requirements** Clean room providers need a Data Cloud license and a Developer edition to create the package. Clean room consumers require a Data Cloud license to install and deploy the package. **Post Install Steps** After installing a package that contains DataCleanRoomProvider, the consumer must manually deploy the data kit components in Data Cloud Setup. See [Deploy a Clean Room from an AgentExchange Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_deploy_cr_from_appexchange.htm&type=5). . **Relationship to Other Components** To include DataCleanRoomProvider in a managed package, you must add the component to a data kit (DataPackageKitDefinition). Then, add the DataPackageKitDefinition to the managed package. DataCleanRoomProvider requires Data Cloud to Data Cloud (DC to DC) sharing. Providers and consumers using Data 360 must have DC to DC sharing configured. **Documentation:** _Salesforce Help:_ [Clean Rooms](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_clean_rooms.htm&type=5); _Salesforce Help:_ [How a Data 360 Clean Room Works](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_how_clean_room_works.htm&type=5); _Salesforce Help:_ [Create a Clean Room Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_create_clean_room_package.htm&type=5); _Salesforce Help:_ [Publish a Clean Room Package to AgentExchange](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_publish_package_to_appexchange.htm&type=5); _Salesforce Help:_ [Deploy a Clean Room from an AgentExchange Package](https://help.salesforce.com/s/articleView?id=data.c360_a_crc_deploy_cr_from_appexchange.htm&type=5) ## DataConnector Represents the white-labeled metadata configuration for an external connector in Data 360. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Connector JAR/implementation (InteArtifactResource blob), groupId, connector operations and schema | | Both Package Developer and Subscriber Can Edit | displayName, description, iconName (via Static Resource), connection credentials/named credentials (subscriber supplies auth; these are excluded from the package) | | Neither Package Developer or Subscriber Can Edit | developerName (once promoted), namespace-prefixed identifiers | ### More Information **Feature Name:** Metadata Name: IntegArtifactDef; Component Type in 1GP Package Manager UI: MktDataConnection is the Connector parent type **Use Case** ISV partners can build, package, and distribute custom Data 360 connectors, which extend existing native Data 360 Connector Framework (DCF) connectors via AgentExchange. Partners configure the connector metadata, icon, and localization, then package it as a data kit in a 2GP or 1GP managed package. Customers see the connector in the Data 360 new stream page with a "partner built" indicator. **Considerations When Packaging** - No automatic spidering in 2GP; ISVs must manually include all related components. - One version per connector name per package. Minor or patch versions are upgrades in-place. - Major version changes require a new connector name (e.g., AsanaV2). - Connection credentials are excluded (subscriber must supply post-install). - PACKAGING_DISABLED capability exists. isGlobal=true must be set. **License Requirements:** Data 360 must be provisioned in the subscriber org. **Usage Limits:** The number of connections per connector type can be up to 200. **Post Install Steps** Connection will be INACTIVE post-install. To activate, the subscriber admin must supply the credentials or authenticate, and then manually activate the connection. **Relationship to Other Components** Not a requirement but DataConnector should be used with data stream and activation components. A connector package is typically bundled inside a data kit. If packaging with a flow or data stream, all dependent metadata (for example, the connection or Named Credentials) must be explicitly included. **Documentation:** _Developer Guide:_ [Data 360 Connectors and Integrations](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-thirdparty-connectors.html) ## Data Connector Ingest API Represents the connection information specific to Ingestion API. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataConnectorIngestApi; Component Type in 1GP Package Manager UI: Adding DataStreamDefinition brings in DataConnectorIngestApi for Ingestion API DataStreams. **Use Case:** This component is part of the Ingestion API Data stream metadata that is packaged and installed in subscriber. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Documentation:** _Salesforce Help:_ [Ingestion API](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-ingestion-api.html) ## Data Connector S3 Represents the connection information specific to Amazon S3. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Delimiter, FileNameWildCard, ImportFromDirectory, S3AccessKey, S3BucketName, S3SecretKey | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataConnectorS3 **Use Case:** This includes the bucket details for the S3 connector in Data Cloud. **Considerations When Packaging** To package this component, first add it to a data kit. For more information about data kits, see [Data Kits](https://help.salesforce.com/s/articleView?id=data.c360_a_data_package_kits.htm&type=5) in in _Salesforce Help_. . Credentials are encrypted and need “IsDevInternal” permission for the encryption service. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Documentation:** _Salesforce Help:_[Data Connector S3](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-gcs-connector.html) ## Data Kit Object Dependency Represent the object dependencies and relationships between different objects in Data Kit Object Dependency. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataKitObjectDependency; Component Type in 1GP Package Manager UI: Data Kit Object Dependency **Use Case:** DataKitObjectDependency represents the relationship of objects of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Data Kit Object Dependency](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datakitobjectdependency.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Kit Object Template Represents the object in Data Kit Object Template. This object template is added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataKitObjectTemplate; Component Type in 1GP Package Manager UI: Data Kit Object Dependency **Use Case:** DataKitObjectTemplate represents the objects the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit, and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [Data Kit Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datakitobjecttemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataObjectBuildOrgTemplate Represents the output objects of the components the user includes in a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataObjectBuildOrgTemplate; Component Type in 1GP Package Manager UI: DataObjectBuildOrgTemplate **Use Case** Supports extension packages that reference the output of any object. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the data object build org template to a data kit, and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. **Post Install Steps** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Package Kit Definition Represents the top-level Data Kit container definition. Content objects can be added after the Data Kit is defined. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Supported in 1GP packages only. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------- | | Only Package Developer Can Edit | description, developerName, isDeployed, isEnabled, masterLabel, versionNumber | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataPackageKitDefinition; Component Type in 1GP Package Manager UI: Data Package Kit Definition **Use Case** Represents the top-level data kit container definition. Content objects can be added after the data kit is defined. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataPackageKitDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datapackagekitdefinition.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Package Kit Object Represents the object in Data Kit Content Object. These objects are added inside the data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------- | | Only Package Developer Can Edit | parentDataPackageKitDefinitionName, referenceObjectName, referenceObjectType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataPackageKitObject; Component Type in 1GP Package Manager UI: Data Package Kit Object **Use Case:** Represents an object in a data kit. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataPackageKitObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datapackagekitobject.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Source Used to represent the system where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | DataSourceStatus, ExternalRecordIdentifier, LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: DataSource **Use Case:** DataSource gives the lineage information of the datastream. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** Create DataStream using ui-api or the Data Cloud App. **Relationship to Other Components** This isn't a top-level entity. AddDataStreamDefinition or DataKitDefinition to pick up DataSource. **Documentation:** _Salesforce Help:_ [Connection Tasks in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_connection_tasks.htm&type=5) ## Data Source Bundle Definition Represents the bundle of streams that a user adds to a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | dataPlatform, isMultiDeploymentSupported, masterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataSourceBundleDefinition; Component Type in 1GP Package Manager UI: Data Source Bundle Definition **Use Case:** Represents the data stream data sources that a user adds to a data kit. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. A data source bundle definition is added to a package when you add a data stream to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataSourceBundleDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datasourcebundledefinition.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Source Object Represents the object from where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataObjectType, DataSource, ExternalRecordId | ### More Information **Feature Name:** Metadata Name: DataSourceObject **Use Case:** DataSourceObject contains specific information about the source of the data like filename, table names. **Considerations When Packaging:** DataSourceObject pulls in child DataSourceField entity records when packaged with DataKitDefinition. **License Requirements:** Customer 360 Audiences Corporate (cdpPsl) licenses must be available on both package developer org and subscriber org. **Post Install Steps:** Create a DataStream via ui-api or using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition or DataKitDefinition to pick up DataSourceObject. **Documentation:** _Salesforce Help:_ [Connection Tasks in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_connection_tasks.htm&type=5) ## Data Src Data Model Field Map Represents the entity that’s used to store the design-time bundle-level mappings for the data source fields and data model fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------- | | Only Package Developer Can Edit | masterLabel, sourceField, targetField, versionNumber | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataSrcDataModelFieldMap; Component Type in 1GP Package Manager UI: Data Source Data Model Field Mapping **Use Case:** Represents the entity that contains design-time bundle-level mappings for the data source fields and data model fields. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. Data model field mappings are added to a package when you add a data stream and any associated mappings to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataSrcDataModelFieldMap](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datasrcdatamodelfieldmap.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## Data Stream Definition Contains Data Ingestion information such as Connection, API and File retrieval settings. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AreHeadersIncludedInTheFiles, BulkIngest, Description, IsLimitedToNewFiles, IsMissingFileFailure | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataConnectionGCS, DataConnectorType, DataExtractField, DataExtractMethod, DataPlatformDataSetBundle, FileNameWildcard, MktDataLakeObject, MktDataTranObject | ### More Information **Feature Name:** Metadata Name: DataStreamDefinition; Component Type in 1GP Package Manager UI: DataStreamDefinition **Use Case** DataStreamDefinition is the starting point for packaging a Datastream and its mappings. **Considerations When Packaging** Data Cloud admin user can install or upgrade the package. Admin User or Data Aware Specialist User can create Datastreams out of the installed package. **License Requirements** Customer 360 Audiences Corporate (cdpPsl) licenses must be available on both package developer org and subscriber org. CDP Admin User can install,upgrade, or uninstall the package. **Post Install Steps** Create the DataStream via ui-api or using the Data Cloud App. **Documentation:** _Metadata API Developer Guide:_ [DataStreamDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datastreamdefinition.htm) ## Data Stream Template Represents the data stream that a user adds to a data kit. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | dataImportRefreshFrequency, dataSourceBundleDefinition, dataSourceObject, objectCategory, refreshFrequency, refreshHours, refreshMode | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataStreamTemplate; Component Type in 1GP Package Manager UI: Data Stream Template **Use Case:** Represents the data stream that a user adds to a data kit. **Considerations When Packaging** Any Data Cloud feature is always packaged via a data kit. A data stream template is added to a package when you add a data stream to a data kit and package that data kit. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [DataStreamTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_datastreamtemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## DataWeaveResource Represents the DataWeaveScriptResource class that is generated for all DataWeave scripts. DataWeave scripts can be directly invoked from Apex. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (if not set to `global` access). | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------- | | Only Package Developer Can Edit | API Version, DataWeave Script | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DataWeaveResource; Component Type in 1GP Package Manager UI: DataWeaveResource **Use Case:** Include MuleSoft DataWeave scripts to read and parse data from one format, transform it, and export it in a different format directly from Apex. **Considerations When Packaging:** There’s a maximum of 50 DataWeave scripts per org. **Documentation:** _Apex Developer Guide:_ [DataWeave in Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/DataWeaveInApex.htm).. ## Decision Matrix Definition Represents a definition of a decision matrix. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is inactive. | | Subscriber Can Delete Component From Org | Yes. Only if the component is inactive. | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------- | | Only Package Developer Can Edit | Type, GroupKey, SubGroupKey | | Both Package Developer and Subscriber Can Edit | versions | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DecisionMatrixDefinition; Component Type in 1GP Package Manager UI: Decision Matrix Definition **Use Case** Decision matrices are lookup tables that match input values to a matrix row and return the row’s output values. Expression sets and various digital procedures can call decision matrices. Decision matrices accept JSON input from, and return JSON output to the digital processes that call the matrices. Decision matrices are useful for implementing complex rules in a systematic, readable manner. **Documentation:** _Industries Common Resources Developer Guide:_ [Decision Matrix Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_decisionmatrixdefinition.htm); _Salesforce Help:_ [Decision Matrices](https://help.salesforce.com/s/articleView?id=ind.decision_matrices.htm&type=5); _Salesforce Help:_ [Decision Matrix Migration Considerations](https://help.salesforce.com/s/articleView?id=ind.decision_matrix_migration_considerations.htm&type=5) ## Decision Matrix Definition Version Represents a definition of a decision matrix version. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is inactive. | | Subscriber Can Delete Component From Org | Yes. Only if the component is inactive. | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | columns | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DecisionMatrixDefinitionVersion; Component Type in 1GP Package Manager UI: Decision Matrix Definition Version **Post Install Steps** After migrating a decision matrix version, upload the row data to the active version manually. The row data isn’t migrated as part of the migration. **Relationship to Other Components:** A DecisionMatrixDefinitionVersion is a child of DecisionMatrixDefinition, and can’t exist without the parent DecisionMatrixDefinition. **Documentation:** _Industries Common Resources Developer Guide:_ [Decision Matrix Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_decisionmatrixdefinition.htm); _Salesforce Help:_ [Decision Matrices](https://help.salesforce.com/s/articleView?id=ind.decision_matrices.htm&type=5); _Salesforce Help:_ [Decision Matrix Migration Considerations](https://help.salesforce.com/s/articleView?id=ind.decision_matrix_migration_considerations.htm&type=5) ## Decision Table Represents the information about a decision table. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Decision Table | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: DecisionTable; Component Type in 1GP Package Manager UI: Decision Table **Use Case:** Decision tables read business rules and decide the outcome for records in your Salesforce org or for the values that you specify. **License Requirements:** Either Loyalty Management or Rebate Management **Documentation:** _Salesforce Help:_ [Decision Tables](https://help.salesforce.com/s/articleView?id=ind.concept_decision_table.htm&type=5) ## Decision Table Dataset Link Represents the information about a dataset link associated with a decision table. In a dataset link, select an object for whose records, the decision table must provide an outcome. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Dataset Link record | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: DecisionTableDatasetLink **Use Case:** In a dataset link, you can map the decision table’s input fields with fields of different standard or custom objects. **License Requirements:** Either Loyalty Management or Rebate Management **Documentation:** _Salesforce Help:_ [Add Dataset Links to a Decision Table](https://help.salesforce.com/s/articleView?id=ind.task_decision_table_dataset_link.htm&type=5) ## Digital Experience Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------- | | Only Package Developer Can Edit | Content Title, Content Body, Content Folder | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DigitalExperience **Use Case:** To move Digital Experience metadata Content from one org to another **Post Install Steps:** After the package is installed, publish the site to make it available to customers. **Documentation:** _Salesforce Help:_ [CMS Content](https://help.salesforce.com/s/articleView?id=xcloud.community_managed_content_content_creation.htm&type=5) ## Digital Experience Bundle Represents a text-based code structure of your organization’s workspaces, organized by workspace type, and each workspace’s content items. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Labels, Description, Content | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DigitalExperienceBundle **Use Case** Share or distribute the content of an enhanced workspace in Salesforce CMS, including images, documents, and news articles. In Marketing Cloud, you can package the content of general and marketing workspaces, including landing pages, forms, and emails (and their associated images and branding). **Considerations When Packaging** Enhanced LWR sites are unsupported. In marketing workspaces, the default data graph, personalization recommenders, personalization points, and decisions aren't included in the bundle. If the workspace includes emails with personalized content that’s based on these objects, then: - Any merge field or repeater that uses the default data graph or a personalization recommender from the source org is broken in the target org. - Any dynamic content variations of email components are removed and only the default variations appear in the email. **Post Install Steps:** After the package is installed, publish the workspace content to make it available to customers. **Documentation:** _Salesforce Help:_ [Salesforce CMS](https://help.salesforce.com/s/articleView?id=xcloud.community_managed_content_overview.htm); _Salesforce Help:_ [Marketing Cloud](https://help.salesforce.com/s/articleView?id=products.mktg_main.htm&type=5); _Metadata API Developer Guide:_ [DigitalExperienceBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_digitalexperiencebundle.htm) ## Disclosure Definition Represents information that defines a disclosure type, such as details of the publisher or vendor who created or implemented the report. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureDefinition; Component Type in 1GP Package Manager UI: Disclosure Definition **Use Case:** You can use this component to define a disclosure type, such as details of the publisher or vendor who created or implemented the report. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuredefinition.htm) ## Disclosure Definition Version Represents the version information about the disclosure definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | DisclosureDefinition, Description, IsActive, VersionNumber, OmniScriptCnfgApiName, IsCurrentVersion, DisclosureDefCurrVer | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureDefinitionVersion; Component Type in 1GP Package Manager UI: Disclosure Definition Version **Use Case:** You can use this component to define the version information about the disclosure definition. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureDefinitionVersion](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuredefinitionversion.htm) ## Disclosure Type Represents the types of disclosures that are done by an individual or an organization and the associated metadata. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: DisclosureType; Component Type in 1GP Package Manager UI: Disclosure Type **Use Case:** You can use this component to create types of disclosures that are done by an individual or an organization. **License Requirements** - Net Zero Cloud Growth license - Disclosure and Compliance Hub permission set license - Disclosure and Compliance Hub User permission set **Post Install Steps** Enable these org settings: - Manage Disclosure and Compliance Hub **Documentation** - _Salesforce Help:_ [Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_setup_disclosure_and_compliance_hub.htm&type=5) - _Salesforce Help:_ [Generate Disclosures Using Disclosure and Compliance Hub](https://help.salesforce.com/articleView?id=ind.netzero_manager_generate_disclosures_using_disclosure_compliance_hub.htm&type=5) - _Metadata API Developer Guide:_[DisclosureType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_disclosuretype.htm) ## Discovery AI Model Represents the metadata associated with a model used in Einstein Discovery. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery AI Model Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery AI Model Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryAIModel **Documentation:** _Metadata API Developer Guide:_ [DiscoveryAIModel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoveryaimodel.htm) ## Discovery Goal Represents the metadata associated with an Einstein Discovery prediction definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery Goal Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery Goal Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryGoal **Documentation:** _Metadata API Developer Guide:_ [DiscoveryGoal](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoverygoal.htm) ## Discovery Story Represents the metadata associated with a story used in Einstein Discovery. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Discovery Story Unique Name | | Neither Package Developer or Subscriber Can Edit | Discovery Story Unique Name | ### More Information **Feature Name:** Metadata Name: DiscoveryStory **Documentation:** _Metadata API Developer Guide:_ [DiscoveryStory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_discoverystory.htm) ## Document Represents a Document. All documents must be in a document folder, such as sampleFolder/TestDocument. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### More Information **Feature Name:** Metadata Name: Document; Component Type in 1GP Package Manager UI: Document **Documentation:** _Metadata API Developer Guide:_ [Document](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_document.htm) ## Document Generation Setting Represents an org's settings for automatic document generation from templates. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Document Template Library Name, Generation Mechanism, Guest Access Named Credential, Label, Preview Type | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: DocumentGenerationSetting **Use Case:** Allows admin users to modify document generation properties. **License Requirements:** DocGen Designer (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [DocumentGenerationSetting](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_documentgenerationsetting.htm) ## Eclair GeoData Represents an Analytics custom map chart. Custom maps are user-defined maps that are uploaded to Analytics and are used just as standard maps are. Custom maps are accessed in Analytics from the list of maps available with the map chart type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Eclair GeoData Unique Name | | Neither Package Developer or Subscriber Can Edit | Eclair GeoData Unique Name | ### More Information **Feature Name:** Metadata Name: EclairGeoData **Documentation:** _Metadata API Developer Guide:_ [EclairGeoData](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_eclairgeodata.htm) ## Email Template (Classic) Use email templates to increase productivity and ensure consistent messaging. Email templates with merge fields let you quickly send emails that include field data from Salesforce records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Email Template Name | | Neither Package Developer or Subscriber Can Edit | Email Template Name | ## Email Template (Lightning) Represents a template for an email, mass email, list email, or Sales Engagement email. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. However, 1GP packages created in Email Template Builder can't be removed. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All attributes | ### More Information These packaging considerations apply to Lightning email templates, including email templates created in Email Template Builder. - For email templates created in Email Template Builder before the Spring ’21 release, attachments aren’t automatically added to the package. Open and resave these templates to turn the attachments into content assets, which are then automatically added to the package. * Enhanced email template folders have these behaviors: - If a package includes an enhanced email template folder, the target organization must have enhanced folders enabled for the deploy to succeed. - If an email template is in a subfolder, adding the root folder to a package doesn’t automatically add the email template to the package. If the email template is in the root folder, it’s automatically added to the package. - You can’t package an email template in the default public and private folders. * For merge fields based on custom fields that are used in the Recipients prefix (for leads and contacts), we add references to those merge fields. If the custom field is renamed, the reference in the template isn’t updated. Edit the custom merge field to use the new field name and update the reference. **note:** An email template created in Email Template Builder can’t be edited after it’s downloaded. To edit the template, clone it. When upgrading a package that has Email Template Builder email templates, only the associated FlexiPage is updated. After downloading the new version of the template, clone it to see the changes. ## Embedded Service Config Represents a setup node for creating an Embedded Service for Web deployment. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EmbeddedServiceConfig **Documentation:** _Metadata API Developer Guide:_ [EmbeddedServiceConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_embeddedserviceconfig.htm); _Salesforce Help:_ [Embedded Chat](https://help.salesforce.com/s/articleView?id=service.snapins_chat_overview.htm&type=5) ## Embedded Service Menu Settings Represents a setup node for creating a channel menu deployment. Channel menus list the ways in which customers can contact your business. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EmbeddedServiceMenuSettings **Documentation:** _Metadata API Developer Guide:_ [EmbeddedServiceMenuSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_embeddedservicemenusettings.htm); _Salesforce Help:_ [Channel Menu Setup](https://help.salesforce.com/s/articleView?id=service.embedded_chat_channel_menu.htm&type=5) ## Enablement Measure Definition Represents an Enablement measure, which specifies the job-related activity that a user performs to complete a milestone or outcome in an Enablement program. A measure identifies a source object and optional related objects, with optional field filters and filter logic, for tracking the activity. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | All but Status and DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnablementMeasureDefinition **Use Case** Include this component in a package with a program if the program has outcomes or milestones. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. For Partner Enablement programs in supported Experience Cloud sites, a [supported Partner Relationship Management (PRM) add-on license](https://help.salesforce.com/s/articleView?id=slack.prm_support_license_template.htm&type=5) is also required. is also required. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** An Enablement measure is used within an Enablement program. Package the Enablement Measure Definition component with the Enablement Program Definition component. Or, package the Enablement Measure Definition component separately. Each measure references a source object and optional related objects. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnablementMeasureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enablementmeasuredefinition.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) ## Enablement Program Definition Represents an Enablement program, which includes exercises and measurable milestones to help users such as sales reps achieve specific outcomes related to your company’s revenue goals. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All but DeveloperName | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnablementProgramDefinition **Use Case** Include this component in a package when you want to move a program from one org to another. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. For Partner Enablement programs in supported Experience Cloud sites, a [supported Partner Relationship Management (PRM) add-on license](https://help.salesforce.com/s/articleView?id=slack.prm_support_license_template.htm&type=5) is also required. is also required. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** An Enablement program can contain other items that are related to other packageable components. Package the Enablement Program Definition component with other appropriate components. - Exercises that reference Digital Experiences content. Package the Digital Experience component. - Exercises that reference assessment surveys. Package the Flow component. - Custom exercise types that reference user-defined content. Package the Learning Item Type and Enablement Program Task Subcategory components. - Measures that track job-related activity using specific objects. Package the Enablement Measure Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnablementMeasureDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enablementmeasuredefinition.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) ## Enablement Program Task Subcategory Represents a custom exercise type that an Enablement admin adds to an Enablement program in Program Builder. A custom exercise type also requires a corresponding EnblProgramTaskDefinition record for Program Builder and corresponding LearningItem and LearningItemType records for when users take the exercise in the Guidance Center. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: EnblProgramTaskSubCategory **Use Case** Include this component in a package with a program if the program has a custom exercise type. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. **important:** Custom exercises aren’t compatible with Partner Enablement programs. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** The Enablement Program Task Subcategory component requires a corresponding Learning Item Type component. Both components are used with custom exercise types in Enablement programs. Package both of these components with an Enablement Program Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnblProgramTaskSubCategory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enblprogramtasksubcategory.htm) - _Metadata API Developer Guide_: [LearningItemType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_learningitemtype.htm) - _Object Reference for the Salesforce Platform_: [EnblProgramTaskDefinition](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_enblprogramtaskdefinition.htm) - _Object Reference for the Salesforce Platform_: [LearningItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_learningitem.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Implement Custom Exercise Types for Enablement Programs](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-custom-exercises-intro.html) ## Entitlement Template Represents an entitlement template. Entitlement templates are predefined terms of customer support that you can quickly add to products. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: EntitlementTemplate **Documentation:** _Metadata API Developer Guide:_ [EntitlementTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_entitlementtemplate.htm); _Salesforce Help:_ [Set Up an Entitlement Template](https://help.salesforce.com/s/articleView?id=service.entitlements_setting_up_templates.htm&type=5) ## ESignature Config Using the Electronic Signature Configuration setup, the system admin must define the required configurations to support the e-signature APIs and UI. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Config Type, Config Value, Description, Group Type, Vendor | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ESignatureConfig **Use Case:** Allows users to get the electronic signatures on their documents. **License Requirements:** DocGen Designer (Permission Set License) ## ESignature Envelope Config Using the Electronic Signature Envelope Config the system admin can define the default reminders and expiry for the envelopes submitted for eSignature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Both Package Developer and Subscriber Can Edit | Expiration Enabled, Expiration Period, Expiration Warning Period, First Reminder Period, Reminder Enabled, Reminder Interval Period, Target Object Name, Vendor, Vendor Account Identifier, Vendor Default Notification Enabled | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ESignatureEnvelopeConfig **Use Case:** Allows users to get the electronic signatures and notifications on their documents. **License Requirements:** DocGen Designer (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [ESignatureEnvelopeConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_esignatureenvelopeconfig.htm) ## Event Relay Represents an event relay that you can use to send platform events and change data capture events from Salesforce to Amazon EventBridge. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, RelayOption, State | | Neither Package Developer or Subscriber Can Edit | DestinationResourceName, EventChannel, UsageType | ### More Information **Feature Name:** Metadata Name: EventRelayConfig; Component Type in 1GP Package Manager UI: Event Relay **Documentation:** _Metadata API Developer Guide:_ [EventRelayConfig](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_eventrelayconfig.htm) ## Explainability Action Definition Define where the metadata for your Decision Explainer business rules are stored in Public Sector Solutions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Description, Developer Name, Business Process Type, Application Type, Action Log Schema Type, Application Subtype | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityActionDefinition ## Explainability Action Version Define and store versions of the explainability actions used by your Decision Explainer business rules in Public Sector Solutions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Active, Description, Explainability Action Definition | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityActionVersion ## Explainability Message Template Represents information about the template that contains the decision explanation message for a specified expression set step type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Label, Message, Name, Result Type, Default, Expression Set Step Type | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExplainabilityMsgTemplate **Documentation:** _Industries Common Resources Developer Guide:_ [ExplainabilityMsgTemplate](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_explainabilitymsgtemplate.htm); _Salesforce Help:_ [Create Explainability Message Templates](https://help.salesforce.com/s/articleView?id=ind.create_explainability_message_templates.htm&type=5) ## Expression Set Definition Represents an expression set definition. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component doesn’t contain any active versions. | | Subscriber Can Delete Component From Org | Yes. Only if the component doesn’t contain any active versions. | | Package Developer Can Remove Component From Package | Yes. Only if the component doesn’t contain any active versions. | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | versions | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetDefinition; Component Type in 1GP Package Manager UI: ExpressionSet Definition **Relationship to Other Components:** To use this component, any expression set version dependencies such as decision matrices, decision tables, object field aliases, and subexpressions must be present in the target org. **Documentation:** _Industries Common Resources Developer Guide:_ [Expression Set Definition](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetdefinition.htm); _Salesforce Help:_ [Expression Set Migration Considerations](https://help.salesforce.com/s/articleView?id=sf.expression_set_migration_considerations.htm&type=5) ## Expression Set Definition Version Represents a definition of an expression set version. **note:** 2GP support for Business Rules Engine Components is a pilot or beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/agreements/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes. Only if the component is in an inactive state. | | Subscriber Can Delete Component From Org | Yes. Only if the component is in an inactive state. | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | variables, steps | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetDefinitionVersion; Component Type in 1GP Package Manager UI: Expression Set Definition Version **Relationship to Other Components:** This component can be used only if the ExpressionSetDefinition to which this ExpressionSetDefinitionVersion component belongs is present in the target org.; To use this component, any expression set version dependencies such as decision matrices, decision tables, object field aliases, and subexpressions must be present in the target org. **Documentation:** _Industries Common Resources Developer Guide:_ [Expression Set Definition Version](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetdefinition.htm); _Salesforce Help:_ [Expression Set Migration Considerations](https://help.salesforce.com/s/articleView?id=sf.expression_set_migration_considerations.htm&type=5) ## Expression Set Object Alias Represents information about the alias of the source object that’s used in an expression set. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | mappings.sourceFieldName, mappings.fieldAlias | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | objectApiName, usageType, dataType | ### More Information **Feature Name:** Metadata Name: ExpressionSetObjectAlias; Component Type: Expression Set Object Alias **Use Case** Expression set object aliases allow you to use object fields as variables in expression sets. Aliases are relevant and user-friendly names that are created for underlying source object fields. Field aliases are grouped under an object alias. **Documentation:** _Industries Common Resources Developer Guide:_ [ExpressionSetObjectAlias](https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/meta_expressionsetobjectalias.htm); _Salesforce Help:_ [Object Variables in Expression Sets](https://help.salesforce.com/s/articleView?id=ind.object_variables_in_expression_sets.htm&type=5) ## Expression Set Message Token Represents a token that's used in an explainability message template. The token can be replaced with an expression set version resource that the template is used in. This object is available in API version 59.0 and later. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Master Label, Developer Name, Description | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExpressionSetMessageToken; Component Type in 1GP Package Manager UI: ExpressionSetMessageToken **Documentation:** _Industries Common Resources Developer Guide:_ [ExpressionSetMessageToken](https://developer.salesforce.com/docs/atlas.en-us.250.0.industries_reference.meta/industries_reference/tooling_api_objects_expressionsetmessagetoken.htm); _Salesforce Help:_ [Create Expression Set Message Tokens](https://help.salesforce.com/s/articleView?id=ind.task_create_expression_set_message_tokens.htm&type=5) ## External Auth Identity Provider Represents the external auth identity provider that obtains OAuth tokens for callouts that use named credentials. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterName, ParameterType, ParameterValue, and SequenceNumber properties have the same editability as the ExternalAuthIdentityProviderParameters they’re included in. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AuthenticationFlow, AuthenticationProtocol, Description, Label | | Both Package Developer and Subscriber Can Edit | ExternalAuthIdentityProviderParameter | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: ExternalAuthIdentityProvider; Component Type in 1GP Package Manager UI: External Auth Identity Provider **Considerations When Packaging** Though external auth identity providers are represented by metadata, the standard Metadata API can’t fully expose and render sensitive information like tokens in plain text. This means that sensitive values such as client secrets aren’t included in packages. Package upgrades delete any additional custom request parameters that subscribers add after installing the package. Alert subscribers that they must recreate custom parameters. Package developers can only create parameters and delete existing parameters. After package installation, subscribers don’t receive updated parameter values from package upgrades. **Relationship to Other Components** A callout to an external system references a named credential, which in turn links to an external credential. For external credentials that use OAuth 2.0 authentication, external auth identity providers obtain the OAuth tokens necessary for outbound callouts. **Documentation:** _Salesforce Help:_ [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [ExternalAuthIdentityProvider](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalauthidentityprovider.htm) ## External Client App Canvas Settings Represents an external client app's canvas app settings. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppCanvasSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components** External Client App plugins like the canvas plugin include two types of configurations: settings and policies. All settings are determined by the external client app developer and can’t be edited by the admin for the subscriber org. Admin-controlled configurations are called policies. ExtlClntAppCanvasSettings contains all of the packageable configurations for the External Client Apps canvas plugin. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); _Metadata API Developer Guide:_ [ExtlClntAppCanvasSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extlclntappcanvassettings.htm); _Canvas Developer Guide:_ [Introducing Canvas](https://developer.salesforce.com/docs/atlas.en-us.platform_connect.meta/platform_connect/canvas_framework_intro.htm) ## External Client App Header Represents the header file for an external client application configuration. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalClientApplication **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components** ExternalClientApplication is the header file for an external client app. This defines the basic configurations of the external client app, including whether the external client app can be packaged or if it is developed for local use only. ExtlClntAppGlobalOauthSettings includes sensitive information for the External Client Apps OAuth plugin, like OAuth consumer credentials that can’t be packaged or added to source control. ExtlClntAppOauthSettings includes packageable configurations. All settings are determined by the developer and can’t be edited by the admin. Admin-controlled configurations are called policies and are included in ExtlClntAppOauthConfigurablePolicies. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); _Salesforce Help:_ [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) ## External Client App Notification Settings Represents the settings configuration for the external client app’s notifications plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppNotificationSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components:** ExtlClntAppNotificationSettings contains all of the packageable configurations for the External Client Apps notifications plugin. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); [ExtlClntAppNotificationSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extlclntappnotificationsettings.htm) ## External Client App OAuth Settings Represents the settings configuration for the external client app’s OAuth plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppOauthSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. for more information. **Relationship to Other Components** External Client App plugins like the OAuth plugin include two types of configurations: settings and policies. All settings are determined by the external client app developer and can’t be edited by the admin for the subscriber org. Admin-controlled configurations are called policies. ExtlClntAppOauthSettings contains all of the packageable configurations for the External Client Apps OAuth plugin. Sensitive information, like OAuth consumer credentials that can’t be packaged or added to source control, are stored in the ExtlClntAppGlobalOauthSettings. Policies are saved in ExtlClntAppOauthConfigurablePolicies, which is not packaged but is generated with default values at runtime. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5) ## External Client App Push Settings Represents the settings configuration for the external client app’s push notification plugin. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtlClntAppPushSettings **Considerations When Packaging** Unlike most metadata, External Client Apps can’t be created via the Setup menu in a scratch org. ISVs who intend to package External Client Apps in a managed 2GP should instead define the External Client App in their PBO (Partner Business Org) Dev Hub. The External Client App can then be retrieved via Salesforce CLI and deployed into a scratch org, or packaged and installed into a scratch org for testing. See [Configure Packageable External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm&type=5) for more information. To deploy ExtlClntAppPushSettings retrieved from the Dev Hub org, delete androidPushConfig or applePushConfig from the metadata file. **Relationship to Other Components** External Client App plugins like the push notification plugin include two types of configurations: settings and policies. All settings are determined by the external client app developer and can’t be edited by the admin for the subscriber org. Admin-controlled configurations are called policies. ExtlClntAppPushSettings contains all of the packageable configurations for the External Client Apps push notifcation plugin. Sensitive information, like APNS or Firebase consumer credentials that can’t be packaged or added to source control, are stored in the ExtlClntAppApplePushConfig and ExtlClntAppAndroidPushConfig, respectively. Policies are saved in ExtlClntAppSamlConfigurablePolicies, which is not packaged but is generated with default values at runtime. **Documentation:** _Salesforce Help:_ [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm&type=5); [ExtlClntAppPushSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extlclntapppushsettings.htm) ## External Credential Represents the details of how Salesforce authenticates to the external system. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterGroup, ParameterName, ParameterValue, and SequenceNumber properties have the same editability as the ExternalCredentialParameters they’re included in. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Label, AuthenticationProtocol, ExternalCredentialParameters | | Both Package Developer and Subscriber Can Edit | Description, ExternalCredentialParameters | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: ExternalCredential **Considerations When Packaging** Though named and external credentials are represented by metadata, the standard Metadata API can’t fully expose the definition of a credential and render sensitive information like tokens in plain text. This means that packaged named credentials don’t include the access tokens or certificates that are needed to perform authenticated callouts. You can create the external credential’s principal or populate its tokens or certificates in the UI or via the Connect API. In managed 1GP packages, external credentials that use the OAuth 2.0 authentication protocol must reference an authentication provider to capture the details of the authorization endpoint. If you add an external credential that references an authentication provider, the authentication provider is added to the package. See [Authentication Providers](https://help.salesforce.com/s/articleView?id=experience.sso_authentication_providers.htm&type=5) for information on which elements of an authentication provider are and aren’t packageable. In managed 2GP packages, if an external credential uses an authentication provider to capture the details of the authorization endpoint, you can’t include the reference to the authentication provider in the package. If the external credential references an authentication provider, you must recreate the authentication provider in the subscriber org and add it to the external credential. **Post Install Steps** After installing an external credential from a managed or unmanaged package, you must: - Create the external credential’s principal or populate its tokens or certificates in the UI or via the Connect API. - Give permission sets and profiles access to the principals of the external credential. See Enable External Credential Principals. - Reauthenticate to the external system. - For a Named Principal, the admin must go to **Setup \> Named Credential \> External Credential** to authenticate. - For a Per User Principal, each user must go to **My Personal Information \> External Credential** to authenticate. **Relationship to Other Components** ExternalCredential can be added to a package without a NamedCredential, but NamedCredential must be packaged with an ExternalCredential. The named credential defines a callout endpoint and an HTTP transport protocol, while the external credential represents the details of how Salesforce authenticates to an external system via an authentication protocol. Each named credential must be mapped to at least one external credential. **Documentation:** _Salesforce Help:_ [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [ExternalCredential](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalcredential.htm) ## External Data Connector Used to represent the object where the data was sourced. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DataConConfiguration, DataConnectionStatus, DataConnectorType, DataPlatform, ExternalRecordId | ### More Information **Feature Name:** Metadata Name: ExternalDataConnector; Component Type in 1GP Package Manager UI: Adding DataStreamDefinition or DataKitDefinition brings ExternalDataConnector for S3 data streams. **Use Case:** This component holds reference to Source Data Connector Metadata. **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps:** User has to create DataStream via ui-api or using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition or DataKitDefinition to pick up this entity. ## External Data Source Represents the metadata associated with an external data source. Create external data sources to manage connection details for integration with data and content that are stored outside your Salesforce org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Type | | Both Package Developer and Subscriber Can Edit | Auth Provider, Certificate, Custom Configuration, Endpoint, Identity Type, OAuth Scope, Password, Protocol, Username | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ExternalDataSource; Component Type in 1GP Package Manager UI: External Data Source **Considerations When Packaging** - After installing an external data source from a managed or unmanaged package, the subscriber must reauthenticate to the external system. - For password authentication, the subscriber must reenter the password in the external data source definition. - For OAuth, the subscriber must update the callback URL in the client configuration for the authentication provider, then reauthenticate by selecting Start Authentication Flow on Save on the external data source. - Certificates aren’t packageable. If you package an external data source that specifies a certificate, make sure that the subscriber org has a valid certificate with the same name. **Documentation:** _Metadata API Developer Guide:_ [ExternalDataSource](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externaldatasource.htm) ## External Data Transport Field Template Represents the definition of a Data Cloud schema field. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------- | | Only Package Developer Can Edit | DataSourceField, ExternalDataTranField, ExternalName, IsDataRequired | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtDataTranFieldTemplate; Component Type in 1GP Package Manager UI: External Data Transport Field Template **Use Case:** ExtDataTranFieldTemplate represents the definition of a Data Cloud schema field the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport field template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [External Data Transport Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extdatatranfieldtemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## External Data Transport Field Use ExternalDataTranField to add a field to the ExternalDataTranObject in your managed packages. ExternalDataTranObject is a Data Cloud schema object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Length, Precision, Scale, IsDataRequired, ExternalName, PrimaryIndexOrder, DateFormat, CreationType, MktDataTranField, Sequence, IsImplicitFilteringRequired, ExtDataTranFieldTemplate, IsCurrencyIsoCode | | Both Package Developer and Subscriber Can Edit | CustomFieldDatatypes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalDataTranField **Use Case:** This component holds reference to ExternalDataTranObject metadata and represents the fields in the ExternalDataTranObject. **License Requirements:** Data Cloud must be provisioned. **Post Install Steps:** You must to create a data stream via ui-api or by using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition to pick up this entity. This entity’s parent is ExternalDataTranObject. **Documentation:** _Metadata API Developer Guide:_ [ExternalDataTranField](https://developer.salesforce.com/docs/atlas.en-us.254.0.api_meta.meta/api_meta/meta_externaldatatranobject.htm#subtype_ExternalDataTranField) ## External Data Transport Object Template Represents the definition of a Data Cloud schema object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes (supported only in 1GP packages) | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes (supported only in 1GP packages) | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------ | | Only Package Developer Can Edit | DataSourceObject, ExternalDataTranObject, ExternalName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExtDataTranObjectTemplate; Component Type in 1GP Package Manager UI: External Data Transport Object Template **Use Case:** ExtDataTranObjectTemplate represents the definition of a Data Cloud schema object the user includes in a data kit. **Considerations When Packaging** A Data Cloud feature is always packaged via a data kit. You add the external data transport object template to a data kit and then add that data kit to a package. You can’t directly add this component to a package. **License Requirements** For more information, see [Data Cloud Standard Permission Sets](https://help.salesforce.com/s/articleView?id=data.c360_a_userpermissions.htm&type=5) in Salesforce Help. in Salesforce Help. **Post Install Steps:** After you install a package that contains a data kit, you must manually deploy the features from the installed data kit. **Documentation:** _Metadata API Developer Guide:_ [External Data Transport Object Template](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_extdatatranobjecttemplate.htm); _Data Cloud Developer Guide:_ [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html); _Salesforce Help:_ [Packaging in Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_packaging_in_customer_360_audiences.htm&type=5) ## External Data Transport Object To include a Data Cloud schema object in your managed packages, add ExternalDataTranObject. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AvailabilityStatus, CreationType, MktDataTranObject, ObjectCategory, ExtDataTranObjectTemplate | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalDataTranObject **Use Case** ExternalDataTranObject contains specific schema event information that is used to describe events for ingestion via Data Cloud Ingestion API, Web, and Mobile connectors. This object is related to many child schema fields, ExternalDataTranField. **License Requirements:** Data Cloud must be provisioned. **Post Install Steps:** You must create a data stream via ui-api or by using the Data Cloud App. **Relationship to Other Components** This isn’t a top-level entity. Add DataStreamDefinition to pick up this entity. This entity’s parent is ExternalDataConnector. **Documentation:** _Data Cloud Integration Guide:_ [Mobile and Web SDK Schema Quick Guide for Data Cloud](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-mobile-web-sdk-schema-quick-guide.html); _Data Cloud Integration Guide:_ [Requirements for Ingestion API Schema File](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-ingestion-api-schema-req.html); _Metadata API Developer Guide:_ [ExternalDataTranObject](https://developer.salesforce.com/docs/atlas.en-us.254.0.api_meta.meta/api_meta/meta_externaldatatranobject.htm) ## External Document Storage Configuration Represents configuration, which admin makes in setup to specify the drive, path, and named credential to be used for storing documents on external drives. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Target Object, Record Type, External Document Storage Identifier, Document Path, Named Credential, Storage Drive Type | | Neither Package Developer or Subscriber Can Edit | DeveloperName, MasterLabel | ### More Information **Feature Name:** Metadata Name: ExternalDocStorageConfig **Use Case:** Represents the configuration that the admin makes in Setup to specify the drive, path, and named credential to be used for storing the documents on external drives. **License Requirements:** Microsoft Word 365 **Documentation:** _Salesforce Help:_ [Configure External Document Storage for Contracts](https://help.salesforce.com/s/articleView?id=ind.sf_contracts_Configure_External_Document_Storage_for_Contracts.htm&type=5) ## External Services Represents the External Service configuration for an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes (If there are no dependencies on the External Services registration and its actions from flows or other features) | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | Description, Label, Schema, Schema URL | | Both Package Developer and Subscriber Can Edit | Named Credential | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ExternalServiceRegistration; Component Type in 1GP Package Manager UI: ExternalServiceRegistration **Considerations When Packaging** Package developers must add named credential components to the External Services registration package. A subscriber can also create a named credential in Salesforce. However, the subscriber must use the same name as the named credential specified in the External Services registration that references it. Create named credentials manually or with Apex. Be sure to add the named credential to a package so that subscriber orgs can install it. When a subscriber org installs a named credential, it can use the Apex callouts generated by the External Services registration process. **Usage Limits:** _Salesforce Help:_ [External Services System Limits](https://help.salesforce.com/s/articleView?id=platform.external_services_schema_def_limits.htm&type=5) **Documentation:** _Metadata API Developer Guide:_ [ExternalServiceRegistration](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalserviceregistration.htm); _Salesforce Help:_ [External Services](https://help.salesforce.com/s/articleView?id=platform.external_services.htm&type=5) ## Feature Parameter Boolean Represents a boolean feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterBoolean; Component Type in 1GP Package Manager UI: Feature Parameter Boolean **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterBoolean](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterboolean.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## Feature Parameter Date Represents a date feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterDate; Component Type in 1GP Package Manager UI: Feature Parameter Date **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterDate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterdate.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## Feature Parameter Integer Represents an integer feature parameter in the Feature Management App (FMA). Feature parameters let you drive app behavior and track activation metrics in subscriber orgs that install your package. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No. See note. | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Note: Feature parameters with a data flow direction set as LMO-to-Subscriber, can be updated in the LMO (License Management Org). Feature parameters with a data flow direction set as Subscriber-to-LMO can be updated using Apex in the subscriber org. Neither of these changes require a package upgrade. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------- | | Only Package Developer Can Edit | Master Label, Value (When Data Flow Direction is set to LMO to Subscriber) | | Both Package Developer and Subscriber Can Edit | Value (When Data Flow Direction is set to Subscriber to LMO) | | Neither Package Developer or Subscriber Can Edit | Full Name, Data Type, Data Flow Direction | ### More Information **Feature Name:** Metadata Name: FeatureParameterInteger; Component Type in 1GP Package Manager UI: Feature Parameter Integer **Use Case:** Use LMO-to-Subscriber feature parameters to enable and disable your app’s features, or use Subscriber-to-LMO feature parameters to track customer preferences and activation metrics. **Considerations When Packaging** Feature parameters are an extension of the License Management App (LMA), and because beta package versions can’t be registered with the LMA, there are aspects of feature parameters that can’t be tested using a beta package version. If you use the default value, you can test LMO-to-Subscriber values in beta package versions. You can’t test any Subscriber-to-LMO feature parameter values in a beta managed package version. **Usage Limits:** A package can include up to 200 feature parameters. **Documentation:** _Metadata API Developer Guide:_ [FeatureParameterInteger](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_featureparameterinteger.htm); [Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_fma_create_feature_parameters.htm); [Create Feature Parameters in Your First-Generation Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm); _Apex Reference Guide:_ [FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm) ## FieldMappingConfig Represents the configuration for fields mapped between a source object and one or more destination objects and fields. This object is available in API version 63.0 and later. **important:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. ### Supported Calls `create()`, `delete()`, `describeSObjects()`, `query()`, `retrieve()`, `update()`, `upsert()` ### Special Access Rules This object is available only if the Fundraising Access license is enabled and the Fundraising User system permission is assigned to users. ### Fields | Field | Type | Properties | Description | | --------------- | -------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Description | textarea | Create, Defaulted on create, Filter, Group, Nillable, Sort, Update | The description of the field mapping configuration. | | DeveloperName | string | Create, Filter, Group, Sort, Update | The unqiue name for FieldMappingConfig. | | Language | picklist | Create, Defaulted on create, Filter, Group, Nillable, Restricted picklist, Sort, Update | The language of the FieldMappingConfig. Possible values are: | | MasterLabel | string | Create, Filter, Group, Sort, Update | Label for the FieldMappingConfig. | | NamespacePrefix | string | Filter, Group, Nillable, Sort | The namespace prefix associated with this object. Each Developer Edition organization that creates a managed package has a unique namespace prefix. Limit: 15 characters. You can refer to a component in a managed package by using the `namespacePrefix__componentName` notation. The namespace prefix can have one of the following values: | | ProcessType | picklist | Create, Defaulted on create, Filter, Group, Nillable, Restricted picklist, Sort, Update | Specifies the type of process that the field mapping configuration supports. Possible values are `ChangeRequest`, `GiftEntry`, `Incident`, or `Problem`. The default value is `GiftEntry`. | | SourceObjectId | picklist | Create, Filter, Group, Restricted picklist, Sort, Update | The ID of the source object for all of the fields mapped in the configuration. Possible values are `GiftEntry`. | ## Field Set Represents a field set. A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user's first name, middle name, last name, and business title. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------ | | Only Package Developer Can Edit | Description, Label, Available fields | | Both Package Developer and Subscriber Can Edit | Selected fields (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: FieldSet; Component Type in 1GP Package Manager UI: Field Set **Considerations When Packaging** Field sets in installed packages perform different merge behaviors during a package upgrade: | If a package developer: | Then in the package upgrade: | | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Changes a field from **Unavailable** to **Available for the Field Set** or **In the Field Set** | The modified field is placed at the end of the upgraded field set in whichever column it was added to. | | Adds a field | The new field is placed at the end of the upgraded field set in whichever column it was added to. | | Changes a field from **Available for the Field Set** or **In the Field Set** to **Unavailable** | The field is removed from the upgraded field set. | | Changes a field from **In the Field Set** to **Available for the Field Set** (or vice versa) | The change isn’t reflected in the upgraded field set. | **note:** Subscribers aren’t notified of changes to their installed field sets. The developer must notify users of changes to released field sets through the package release notes or other documentation. Merging has the potential to remove fields in your field set. **Documentation:** _Metadata API Developer Guide:_ [FieldSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_fieldset.htm) ## Field Source Target Relationship Stores the relationships between a data model object (DMO) and its fields. For example, the Individual.Id field has a one-to-many relationship (1:M) with the ContactPointEmail.PartyId field. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DeveloperName, MasterLabel, RelationshipCardinality, SourceField, TargetField | | Both Package Developer and Subscriber Can Edit | LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode, Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FieldSrcTrgtRelationship; Component Type in 1GP Package Manager UI: Field Source Target Relationship **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [FieldSrcTrgtRelationship](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_fieldsrctrgtrelationship.htm) ## Flow Represents the metadata associated with a flow. With Flow, you can create an application that navigates users through a series of pages to query and update records in the database. You can also execute logic and provide branching capability based on user input to build dynamic applications. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ----------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | Yes, except a flow that is a template or overridable. | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Entire flow | | Both Package Developer and Subscriber Can Edit | Flow Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | Flow API Name, URL | ### More Information **Feature Name:** Metadata Name: Flow **Use Case:** To repeat a business process automatically such as creating an account when some criteria are met or sending an email every week, build a flow to save time and resources **Considerations When Packaging** - When you upload a package or package version, the active flow version is included. If the flow has no active version, the latest version is packaged. - To update a managed package with a different flow version, activate that version and upload the package again. Or deactivate all versions of the flow, make sure the latest flow version is the one to distribute, and then upload the package. - In a packaging org, you can’t delete a flow after you upload it to a released or beta first-generation managed package. You can only delete a flow version from a packaging org after you upload it to a released or beta first-generation managed package, if: - Salesforce Customer Support activated the Managed Component Deletion permission. - The flow version is not the most recently packaged version of the flow. - The flow version is not active. - The flow version is not the only version. - You can’t delete a flow from an installed package. To remove a packaged flow from your org, deactivate it and then uninstall the package. - If you have multiple versions of a flow installed from multiple unmanaged packages, you can’t remove only one version by uninstalling its package. Uninstalling a package—managed or unmanaged—that contains a single version of the flow removes the entire flow, including all versions. - You can’t include flows in package patches. - An active flow in a package is active after it’s installed. The previous active version of the flow in the destination org is deactivated in favor of the newly installed version. Any in-progress flows based on the now-deactivated version continue to run without interruption but reflect the previous version of the flow. The same behavior is true even if the destination org deactivated the flow. Future active versions of the flow that are packaged activate the flow during package upgrade. - Upgrading a managed package in your org installs a new flow version only if there’s a newer flow version from the developer. After several upgrades, you can end up with multiple flow versions. - A package version can contain only one flow version per flow. If you install a managed package version that contains a flow, only the active flow version is deployed. If the flow has no active version, the latest version is deployed. - If you install a flow from an unmanaged package that has the same name but a different version number as a flow in your org, the newly installed flow becomes the latest version of the existing flow. However, if the packaged flow has the same name and version number as a flow already in your org, the package install fails. You can’t overwrite a flow. - A flow can be modified if it’s deployed in a managed package or between a package developer org and a subscriber org where either org has a namespace and the other doesn’t have a namespace. - Flow Builder can’t open a flow that is installed from a managed package, unless the flow is a template or overridable. - You can’t create a package that contains flows invoked by both managed and unmanaged package pages. As a workaround, create two packages, one for each type of component. For example, suppose that you want to package a customizable flow invoked by a managed package page. Create one unmanaged package with the flow that users can customize. Then create another managed package with the Visualforce page referencing the flow (including namespace) from the first package. - When you translate a flow from a managed package, the flow’s Master Definition Name doesn’t appear on the Translate page or the Override page. To update the translation for the Master Definition Name, edit the flow label and then update the translation from the Translate page. - If any of the following elements are used in a flow, packageable components that they reference aren’t included in the package automatically. To deploy the package successfully, manually add those referenced components to the package. - Post to Chatter - Send Email - Submit for Approval - If a flow references a Lightning component that depends on a CSP Trusted Site, the trusted site isn’t included in the package or change set automatically. **Usage Limits:** _Salesforce Help:_ [General Flow Limits](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5) **Relationship to Other Components:** The associated Flow Definition component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide_: [Flow](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm); _Salesforce Help:_ [Packaging Considerations for Flows](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5); _Salesforce Help:_ [Considerations for Deploying Flows with Packages](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5); _Salesforce DX Developer Guide:_ [Hard-Deleted Components in Unlocked Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_hard_deleted_components.htm) ## Flow Category Represents a list of flows that are grouped by category. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------ | | Only Package Developer Can Edit | label, description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FlowCategory **Use Case:** To reuse flow-based automated processes, group the flows into a flow category, and then add one or more flow categories to a Lightning Bolt Solution. **License Requirements:** Customize Application user permission; View Setup and Configuration user permission **Relationship to Other Components:** You can use FlowCategory only as part of a Lightning Bolt Solution. **Documentation:** _Salesforce Help:_ [Add Flows to a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_flow_category.htm&type=5); _Salesforce Help:_ [Package and Distribute a Lightning Bolt Solution](https://help.salesforce.com/s/articleView?id=experience.community_builder_export_package.htm&type=5) ## Flow Definition Represents the flow definition’s description and active flow version number. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Active Version Number, Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: Flow Definition; Component Type in 1GP Package Manager UI: Flow Definition **Use Case:** Include this component when you use managed 1GP to package flows. **Considerations When Packaging:** [Considerations for Deploying Flows with Packages](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_packaging.htm&type=5) **Relationship to Other Components:** The associated Flow component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide:_ [Flow Definition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flowdefinition.htm); _Salesforce Help:_ [Flow Builder](https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5) ## Flow Test Represents the metadata associated with a flow test. Before you activate a record-triggered flow, you can test it to verify its expected results and identify flow run-time failures. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | API Name | ### More Information **Feature Name:** Metadata Name: FlowTest; Component Type in 1GP Package Manager UI: FlowTest **Use Case:** Include this component when you use managed 1GP to package flow tests. **Usage Limits:** _Salesforce Help_: [Considerations for Testing Flows](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_feature_testing.htm&type=5) **Relationship to Other Components:** The associated Flow component is required for managed 1GP packages. **Documentation:** _Metadata API Developer Guide_: [Flow Test](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flowtest.htm); _Salesforce Help:_ [Testing Your Flow](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_testing.htm&type=5) ## Folder Represents a folder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Folder Unique Name | | Neither Package Developer or Subscriber Can Edit | Folder Unique Name | ### More Information - Five different folder metadata types can be packaged: - DashboardFolder - DocumentFolder - EmailFolder (available for Salesforce Classic email templates only) - EmailTemplateFolder - ReportFolder - Components that Salesforce stores in folders, such as documents, can’t be added to packages when stored in personal and unfiled folders. Put documents, reports, and other components that Salesforce stores in folders in one of your publicly accessible folders. - Components such as documents, email templates, reports, or dashboards are stored in new folders in the installer’s org using the publisher’s folder names. Give these folders names that indicate they’re part of the package. - If a new report, dashboard, document, or email template is installed during an upgrade, and the folder containing the component was deleted by the subscriber, the folder is re-created. Any components in the folder that were previously deleted aren’t restored. - The name of a component contained in a folder must be unique across all folders of the same component type, excluding personal folders. Components contained in a personal folder must be unique within the personal folder only. **Documentation:** _Metadata API Developer Guide:_ [Folder](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_folder.htm) ## Fuel Type Represents a custom fuel type in an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FuelType; Component Type in 1GP Package Manager UI: Fuel Type **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create a Custom Fuel Type](https://help.salesforce.com/s/articleView?language=en_US&id=sf.netzero_admin_create_custom_fuel_type.htm) ## Fuel Type Sustainability Unit of Measure Represents a mapping between the custom fuel types and their corresponding unit of measure (UOM) values defined by a customer in an org. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FuelTypeSustnUom; Component Type in 1GP Package Manager UI: Fuel Type Sustainability Unit of Measure **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Associate a Custom Fuel Type with a Unit of Measure](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_associate_custom_fuel_type_with_unitofmeasure.htm&type=5) ## Fundraising Config Represents a collection of settings to configure the fundraising product. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | LapsedUnpaidTrxnCount, HouseholdSoftCreditRole, IsHshldSoftCrAutoCrea, InstallmentExtDayCount, DonorMatchingMethod, FailedTransactionCount, ShouldCreateRcrSchdTrxn, ShouldClosePaidRcrCmt | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: FundraisingConfig **License Requirements:** Fundraising Access (Permission Set License) **Documentation:** _Metadata API Developer Guide:_ [FundraisingConfig](https://developer.salesforce.com/docs/atlas.en-us.nonprofit_cloud.meta/nonprofit_cloud/npc_fundraising_api_objects_fundraisingconfig.htm) ## Gateway Provider Payment Method Type Represents an entity that allows integrators and payment providers to choose an active payment to receive an order's payment data rather than allowing the Salesforce Order Management platform to select a default payment method. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All fields | ### More Information **Feature Name:** Metadata Name: GatewayProviderPaymentMethodType **License Requirements** Salesforce Order Management, B2B Commerce, or B2C Commerce (for B2B2C Commerce) licenses are required. These licenses enable the Payment Platform org permission required to use payments objects. **Documentation:** _Salesforce Help:_ [Processing Payments with Payment Gateways](https://help.salesforce.com/s/articleView?id=sales.blng_payment_gateways.htm&type=5) ## Gen Ai Planner Bundle Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | Capabilities, Description, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: [GenAiPlannerBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiplannerbundle.htm); Component Type in 2GP Package Manager UI: Generative AI Planner Bundle **Use Case** Represents a planner for an agent or agent template. It’s a container for all the topics and actions used to interact with a large language model (LLM). **Documentation:** _Salesforce Help:_ [Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5); _Salesforce Help:_ [The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm) ## Generative AI Prompt Template Represents a generative AI prompt template, for use in Agentforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | Template Active Version | | Both Package Developer and Subscriber Can Edit | Template Description | | Neither Package Developer or Subscriber Can Edit | Prompt Template Name, Prompt Template Version | ### More Information **Feature Name:** Metadata Name: GenAIPromptTemplate; Component Type in 1GP Package Manager UI: Generative AI Prompt Template **Use Case:** To package prompt templates created from Prompt Builder for Generative AI use cases. **Considerations When Packaging:** See [Considerations for Packaging Prompt Templates](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_considerations_packaging.htm).. **License Requirements:** Generative AI SKUs are needed to provision Prompt Builder in the org. **Documentation:** _Metadata API Developer Guide:_ [GenAiPromptTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_genaiprompttemplate.htm) ## Global Picklist Represents the metadata for a global picklist value set, which is the set of shared values that custom picklist fields can use. A global value set isn’t a field itself. In contrast, the custom picklist fields that are based on a global picklist are of type ValueSet. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: Global Value Set; Component Type in 1GP Package Manager UI: Global Value Set **Considerations When Packaging** When explicitly referencing a picklist value in code, keep in mind that picklist values for a custom field can be renamed, added, edited, or deleted by subscribers. Picklist field values can be added or deleted in the developer’s org. Changes to standard picklists can’t be packaged and deployed to subscriber orgs, and picklist values deleted by the developer are still available in the subscriber’s org. If there are differences between the package and the target org, or if there are dependencies on new values from features such as PathAssistant, the deploy fails. To change values in subscriber orgs, you must manually add or modify the values in the target subscriber org. Updating picklist values in unlocked packages isn’t supported. Manually add or modify the values in the target subscriber org. Package upgrades retain dependent picklist values that are saved in a managed custom field. Global value sets can be added to developer and subscriber orgs. Global value sets have these behaviors during a package upgrade. - Label and API names for field values don’t change in subscriber orgs. - New field values aren’t added to the subscriber orgs. - Active and inactive value settings in subscriber orgs don’t change. - Default values in subscriber orgs don’t change. - Global value set label names change if the package upgrade includes a global value set label change. When you create a custom global value set in API version 56.0 or later, the developer name is appended with the suffix `__gvs`. . - A global value set created before API version 56.0 doesn’t have the developer name suffix. For example, `myGlobalValueSet`. - A global value set created in API version 56.0 or later automatically has the developer name suffix `__gvs`, and you refer to it using the suffix. For example, `myNewGlobalValueSet__gvs`. If you have a package.xml manifest file that contains global value sets, and you upgrade the package.xml file to API version 56.0, you must add the `__gvs` suffix to all of the global value sets in the file. You can do a new package retrieve in API version 56.0 to get all the global value set names. Your package.xml file looks like this XML. ```xml gvs1 GlobalValueSet gvs2 GlobalValueSet 55.0 ``` To upgrade the file to API version 56.0, the file looks like this XML. ```xml gvs1__gvs GlobalValueSet gvs2__gvs GlobalValueSet 56.0 ``` **Documentation:** _Salesforce Help:_ [Create a Global Picklist Value Set](https://help.salesforce.com/s/articleView?id=platform.fields_creating_global_picklists.htm&type=5); _Salesforce Help:_ [Make Your Custom Picklist Field Values Global](https://help.salesforce.com/s/articleView?id=platform.fields_promote_picklists.htm&type=5) ## Global Value Set Translation Add global value set translations to your managed packages. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: GlobalValueSetTranslation; Component Type in 1GP Package Manager UI: Language Translation **Considerations When Packaging** GlobalValueSet and GlobalValueSetTranslation must be in the same package for translations to install correctly. If they are in separate packages, enable the Language Extension Package feature in your Dev Hub. **Relationship to Other Components** GlobalValueSetTranslation requires the associated [Global Picklist](#global-picklist) component to be in the same package. component to be in the same package. **Documentation:** _Metadata API Developer Guide:_ [GlobalValueSetTranslation](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_globalvaluesettranslation.htm); _Metadata API Developer Guide:_ [Translations](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_translations.htm) For details on how subscribers can override translations after installing a package, see [Override Translations in Second-Generation Managed Packages and Unlocked Packages](https://help.salesforce.com/s/articleView?id=platform.entering_translated_terms_in_packages.htm&type=5). ## Home Page Component Represents the metadata associated with a home page component. You can customize the Home tab in Salesforce Classic to include components such as sidebar links, a company logo, a dashboard snapshot, or custom components that you create. Use to create, update, or delete home page component definitions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | Body, Component Position | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name, Type | ### More Information **Feature Name:** Metadata Name: HomePageComponent; Component Type in 1GP Package Manager UI: Home Page Component **Relationship to Other Components** When you package a custom home page layout, all the custom home page components included on the page layout are automatically added. Standard components such as Messages & Alerts aren’t included in the package and don’t overwrite the installer’s Messages & Alerts. To include a message in your custom home page layout, create an HTML Area type custom Home tab component containing your message. From Setup, in the Quick Find box, enter `Home Page Components`, then select **Home Page Components**. Then add the message to your custom home page layout. **Documentation:** _Metadata API Developer Guide:_ [HomePageComponent](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_homepagecomponent.htm) ## Home Page Layout Represents the metadata associated with a home page layout. You can customize home page layouts and assign the layouts to users based on their user profile. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Layout Name | | Neither Package Developer or Subscriber Can Edit | Layout Name | ### More Information **Feature Name:** Metadata Name: HomePageLayout; Component Type in 1GP Package Manager UI: Home Page Layout **Considerations When Packaging** After they’re installed, your custom home page layouts are listed with all the subscriber’s home page layouts. Distinguish them by including the name of your app in the page layout name. **Documentation:** _Metadata API Developer Guide:_ [HomePageLayout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_homepagelayouts.htm) ## Identity Verification Proc Def Represents the definition of the identity verification process. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------- | | Only Package Developer Can Edit | MasterLabel, SearchLayoutType | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: IdentityVerificationProcDef; Component Type in 1GP Package Manager UI: Identity Verification Process Definition **Use Case:** Links the configuration for Identity Verification to a flow. **License Requirements:** Industries Health Cloud, Industries Sales Excellence, and Industries Service Excellence licenses.; Actionable Segmentation Engagement, Industries Sales Excellence, Industry Service Excellence or Health Cloud Platform Permission set license is required to use this metadata type. **Relationship to Other Components:** An Identity Verification Process Field record looks up to an Identity Verification Process Details record, which in turn looks up to an Identity Verification Process Definition record. **Documentation:** _Health Cloud Developer Guide_: [IdentityVerificationProcDef](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/meta_identityverificationprocdef.htm) ## Inbound Network Connection Represents a private connection between a third-party data service and a Salesforce org. The connection is inbound because the callouts are coming into Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | You can only delete connections that are in an unprovisioned state. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | AWS VPC Endpoint ID, Connection Type, Developer Name, Description, Link ID, Master Label, Region, Source IP Ranges | | Both Package Developer and Subscriber Can Edit | Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: InboundNetworkConnection; Component Type in 1GP Package Manager UI: Inbound Network Connection **Considerations When Packaging** - Packaged connections are installed as unprovisioned. Alert subscribers about how to provision connections after package installation. - If a developer changes the Region of a packaged connection that is subscriber-provisioned, the upgrade fails for the subscriber. Alert subscribers about tearing down the connection before updating the Region field. As a best practice, avoid changing the Region of a packaged connection unless necessary. **License Requirements:** This feature is available with the Private Connect license. **Documentation:** _Salesforce Help:_ [Secure Cross-Cloud Integrations with Private Connect](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5); _Salesforce Help:_ [Establish an Inbound Connection with AWS](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_inbound_aws.htm&type=5) ## IndustriesEinsteinFeatureSettings Represents the settings for enabling the Industries Einstein feature. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: IndustriesEinsteinFeatureSettings **Documentation:** _Salesforce Help:_ [Intelligent Document Reader](https://help.salesforce.com/s/articleView?id=ind.intelligent_document_reader.htm&type=5); _Salesforce Help:_ [Intelligent Form Reader](https://help.salesforce.com/s/articleView?id=ind.form_reader.htm&type=5) ## IntegrationProviderDef Represents an integration definition associated with a service process. Stores data for the Industries: Send Apex Async Request and Industries: Send External Async Request invocable actions. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | StringValue, IntegerValue, DateTimeValue, DateValue, PercentageValue, DoubleValue, IsTrueOrFalseValue | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **IntegrationProviderDef:** Metadata Name: IntegrationProviderDef; Component Type in 1GP Package Manager UI: IntegrationProviderDef **Documentation:** [IntegrationProviderDef](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_integrationproviderdef.htm) in _Metadata API Developer Guide_. ## Invocable Action Extension Represents extended metadata for Apex classes that are used as invocable actions or data types. This allows developers to specify how to present the action's inputs without writing custom code. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: InvocableActionExtension **Use Case** To control ordering, grouping, and conditional visibility of action input parameters. Other uses will be available in the future. **Considerations When Packaging** The maximum number of files that can be included in a package is 10,000. Invocable Action Extensions can significantly affect the file count, as each extended Apex class adds five additional extension files. Each extension file also increases ‌package version, creation and installation times. If you receive an error regarding too many files or the installation takes too long, consider breaking your package into a set of dependent packages. For more details, see [Create Dependencies Between Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_dependencies.htm). . **Relationship to Other Components:** This component is paired with an Apex Invocable Action. **Documentation:** _Metadata API Developer Guide:_ InvocableActionExtensionInvocableActionExtension ## LearningAchievementConfig Represents the mapping details between a Learning Achievement type and a Learning Achievement record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: LearningAchievementConfig **Documentation:** Education Cloud Developer Guide **See Also** - [https://developer.salesforce.com/docs/atlas.en-us.edu_cloud_dev_guide.meta/edu_cloud_dev_guide/sforce_api_objects_learningachievementconfig.htm](https://developer.salesforce.com/docs/atlas.en-us.edu_cloud_dev_guide.meta/edu_cloud_dev_guide/sforce_api_objects_learningachievementconfig.htm) ## Learning Item Type Represents a custom exercise type that an Enablement user takes in an Enablement program in the Guidance Center. A custom exercise type also requires a corresponding LearningItem record for the Guidance Center and corresponding EnblProgramTaskDefinition and EnblProgramTaskSubCategory records for when admins create a program in Program Builder. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------- | | Only Package Developer Can Edit | All but DeveloperName | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: LearningItemType **Use Case** Include this component in a package with a program if the program has a custom exercise type. **Considerations When Packaging:** See [Considerations for Packaging Enablement Programs and Dependencies](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package-considerations.html).. **License Requirements** Enablement add-on license and the Enablement permission set license are required. **important:** Custom exercises aren’t compatible with Partner Enablement programs. **Usage Limits:** See [Enablement Limits](https://help.salesforce.com/s/articleView?id=sales.enablement_limits.htm&type=5).. **Relationship to Other Components** The Learning Item Type component requires a corresponding Enablement Program Task Subcategory component. Both components are used with custom exercise types in Enablement programs. Package both of these components with an Enablement Program Definition component. **Documentation** - _Salesforce Help_: [Sales Programs and Partner Tracks with Enablement](https://help.salesforce.com/s/articleView?id=sales.enablement.htm&type=5) - _Metadata API Developer Guide_: [EnblProgramTaskSubCategory](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_enblprogramtasksubcategory.htm) - _Metadata API Developer Guide_: [LearningItemType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_learningitemtype.htm) - _Object Reference for the Salesforce Platform_: [EnblProgramTaskDefinition](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_enblprogramtaskdefinition.htm) - _Object Reference for the Salesforce Platform_: [LearningItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_learningitem.htm) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Create a Managed Package for Enablement Programs, Measures, and Content](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-package.html) - _Sales Programs and Partner Tracks with Enablement Developer Guide_: [Implement Custom Exercise Types for Enablement Programs](https://developer.salesforce.com/docs/sales/enablement/guide/enablement-custom-exercises-intro.html) ## Letterhead Represents formatting options for the letterhead in an email template. A letterhead defines the logo, page color, and text settings for your HTML email templates. Use letterheads to ensure a consistent look and feel in your company’s emails. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Letterhead Name | | Neither Package Developer or Subscriber Can Edit | Letterhead Name | ### More Information **Feature Name:** Metadata Name: Letterhead **Documentation:** _Metadata API Developer Guide:_ [Letterhead](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_letterhead.htm) ## Life Science Config Category Represents the category that a Life Sciences configuration record is organized into. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | CategoryLabel, DeveloperName, MasterLabel | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | CategoryType | ### More Information **Feature Name:** Metadata Name: LifeSciConfigCategory; Component Type in 1GP Package Manager UI: Life Science Config Category **Considerations When Packaging:** When packaging the LifeSciConfigCategory component, the DeveloperName must match the Category. **License Requirements:** Industries Life Sciences Cloud with the Life Sciences Cloud for Customer Engagement Add-on license and the Life Sciences Customer Engagement managed package. **Relationship to Other Components:** This component defines the category of the configuration defined in a child LifeSciConfigRecord component. **Documentation:** _Life Sciences Cloud Developer Guide_: [LifeSciConfigCategory](https://developer.salesforce.com/docs/atlas.en-us.life_sciences_dev_guide.meta/life_sciences_dev_guide/meta_lifesciconfigcategory.htm) ## Life Science Config Record Represents a configuration record for Life Sciences. This object is a child of Life Science Config Category. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | IsActive, IsOrgLevel, MasterLabel, ParentConfigRecordId, Type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | DeveloperName, LifeSciConfigCategoryId | ### More Information **Feature Name:** Metadata Name: LifeSciConfigRecord; Component Type in 1GP Package Manager UI: Life Science Config Record **Use Case:** This component holds the configuration records for Life Sciences Cloud for Customer Engagement application. **Considerations When Packaging** - You must package the LifeSciConfigRecord component with its parent LifeSciConfigCategory component. - The component must be in the inactive state. **License Requirements:** Industries Life Sciences Cloud with the Life Sciences Cloud for Customer Engagement Add-on license and the Life Sciences Customer Engagement managed package. **Post Install Steps:** For the configuration to work, make the component active by setting IsActive to true. **Relationship to Other Components:** A LifeSciConfigRecord is a child of LifeSciConfigCategory, and can’t exist without the parent LifeSciConfigCategory.; A LifeSciConfigRecord is also a parent to LifeSciConfigFieldValue and LifeSciConfigAssignment. **Documentation:** _Life Sciences Cloud Developer Guide_: [LifeSciConfigRecord](https://developer.salesforce.com/docs/atlas.en-us.life_sciences_dev_guide.meta/life_sciences_dev_guide/meta_lifesciconfigrecord.htm) ## Lightning Bolt Represents the definition of a Lightning Bolt Solution, which can include custom apps, flow categories, and Experience Builder templates. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: LightningBolt; Component Type in 1GP Package Manager UI: Lightning Bolt **Documentation:** _Metadata API Developer Guide:_ [LightningBolt](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningbolt.htm) ## Lightning Message Channel Represents the metadata associated with a Lightning Message Channel. A Lightning Message Channel represents a secure channel to communicate across UI technologies, such as Lightning Web Components, Aura Components, and Visualforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: LightningMessageChannel; Component Type in 1GP Package Manager UI: Lightning Message Channel **Considerations When Packaging:** To pass the [AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm), the , the isExposed attribute must be set to attribute must be set to false.. **Documentation:** _Metadata API Developer Guide_: [Lightning Message Channel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningmessagechannel.htm); _Lightning Web Components Developer Guide_: [Create a Message Channel](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_intro) ## Lightning Page Represents the metadata associated with a Lightning page. A Lightning page represents a customizable screen made up of regions containing Lightning components. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | Lightning page | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | **note:** You must have the Manage Prompt Templates permission to successfully package Lightning pages that reference prompt templates. Without this permission, package creation succeeds, but the prompt template isn't included in the package. ### More Information **Feature Name:** Metadata Name: FlexiPage **Documentation:** _Metadata API Developer Guide:_ [Flexipage](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flexipage.htm) ## Lightning Type Represents a custom Lightning type. Use this type to override the default user interface to create a customized appearance based on your business requirements. Deploy this bundle to your organization to implement the overrides. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: LightningTypeBundle; Component Type in 1GP Package Manager UI: Lightning Type **Documentation:** _Metadata API Developer Guide_: [LightningTypeBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_lightningtypebundle.htm) ## Lightning Web Component Represents a Lightning web component bundle. A bundle contains Lightning web component resources. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. You can build Lightning components using two programming models: the Lightning Web Components model, and the original Aura Components model. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | When a package developer removes an Aura or Lightning web component from a package, the component remains in a subscriber’s org after they install the upgraded package. The administrator of the subscriber’s org can delete the component, if desired. This behavior is the same for a Lightning web component or an Aura component with a `public` or `global` access value. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | API Version, Description, isExposed (can only change from false to true), Label, Markup, Targets, targetConfigs, targetConfig, property | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | You can’t make certain changes to `` tags on a custom component that’s used in a managed package or an Experience Builder site. For more information, see [Considerations](https://developer.salesforce.com/docs/platform/lwc/guide/use-config-for-community-builder.html#considerations) for configuring a component for Experience Builder in the _Lightning Web Components Developer Guide_. ### More Information **Lightning Web Component:** Metadata Name: LightningComponentBundle; Component Type in 1GP Package Manager UI: Lightning Web Component (LWC) Bundle **Considerations When Packaging** Licensing Considerations: LWC components don’t automatically enforce managed package licensing. LWC components in a managed package can be seen and used by users who don’t have active licenses for that managed package. These components can also be seen and used after a trial of that managed package expires. AgentExchange partners are responsible for enforcing package licensing in their LWC Components. We recommend using an Apex controller that calls either the [UserInfo.isCurrentUserLicensed(namespace)](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_userinfo.htm#apex_System_UserInfo_isCurrentUserLicensed) or or [UserInfo.isCurrentUserLicensedForPackage(packageID)](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_userinfo.htm#apex_System_UserInfo_isCurrentUserLicensedForPackage) methods, and only rendering the component if methods, and only rendering the component if `true` is returned. is returned. Considerations When Using `isExposed`:: If `isExposed` is false, the package developer can remove configuration targets and a public (@api) property from a component. The component isn't available to other namespaces or to Salesforce builders like Lightning App Builder and Experience Builder. is false, the package developer can remove configuration targets and a public (@api) property from a component. The component isn't available to other namespaces or to Salesforce builders like Lightning App Builder and Experience Builder. If `isExposed` is true and the component is in a published managed package, the package developer can’t remove configuration targets or a public (@api) property from a component. This restriction is enforced even if the target or public property was added after the most recent publication of the package. is true and the component is in a published managed package, the package developer can’t remove configuration targets or a public (@api) property from a component. This restriction is enforced even if the target or public property was added after the most recent publication of the package. If `isExposed` is true, the component is available to other namespaces, including namespaces outside of a published managed package. is true, the component is available to other namespaces, including namespaces outside of a published managed package. If `isExposed` is true and a is true and a Targets value is also provided, the component is available to Salesforce builders such as Lightning App Builder and Experience Builder. value is also provided, the component is available to Salesforce builders such as Lightning App Builder and Experience Builder. When you delete an LWC component with an `isExposed` value of true, we recommend a two-stage process to ensure that the deleted component has no dependencies on the other items in the package. See value of true, we recommend a two-stage process to ensure that the deleted component has no dependencies on the other items in the package. See [Remove Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm) for details. for details. Considerations When Working with LWC Dynamic Imports: When installing a managed package that contains an LWC component with [dynamic imports](https://developer.salesforce.com/docs/platform/lwc/guide/js-dynamic-components.html), , [Lightning Web Security](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-enable.html) must be enabled in your org. must be enabled in your org. **Documentation:** [Lightning Web Components Developer Guide](https://developer.salesforce.com/docs/component-library/documentation/en/lwc); _Lightning Web Components Developer Guide:_ [Add Components to Managed Packages](https://developer.salesforce.com/docs/platform/lwc/guide/use-packaging-add.html); _Lightning Web Components Developer Guide:_ [Delete Components from Managed Packages](https://developer.salesforce.com/docs/platform/lwc/guide/use-packaging-delete.html) ## List View ListView allows you to see a filtered list of records, such as contacts, accounts, or custom objects. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except View Unique Name | | Neither Package Developer or Subscriber Can Edit | View Unique Name | ### More Information **Feature Name:** Metadata Name: ListView; Component Type in 1GP Package Manager UI: List View **Considerations When Packaging** If a subscriber removes a packaged listview from their production org, that listview is deprecated, but not deleted. If that subscriber org later creates a sandbox org, and upgrades the package in the sandbox org, the removed listview persists in the sandbox org. To remove the listview from the sandbox, package subscribers can click ![List View Controls](https://developer.salesforce.com/media/shared/settings_120.png) and select and select **Delete**. . **Relationship to Other Components** List views associated with queues can’t be included in a managed package or an unlocked package. **Documentation:** _Metadata API Developer Guide:_ [ListView](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_listview.htm) ## Live Chat Sensitive Data Rule Represents a rule for masking or deleting data of a specified pattern. Written as a regular expression (regex). Use this object to mask or delete data of specified patterns, such as credit card, social security, or phone and account numbers. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes, Supported in 1GP Packages only | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: LiveChatSensitiveDataRule; Component Type in 1GP Package Manager UI: Sensitive Data Rules **Documentation:** _Metadata API Developer Guide:_ [LiveChatSensitiveDataRule](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_livechatsensitivedatarule.htm) ## Loyalty Program Setup Represents the configuration of a loyalty program process including its parameters and rules. Program processes determine how new transaction journals are processed. When new transaction journals meet the criteria and conditions for a program process, actions that are set up in the process are triggered for the transaction journals. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------- | | Only Package Developer Can Edit | Loyalty Program Process records | | Both Package Developer and Subscriber Can Edit | Label, Description, Status | | Neither Package Developer or Subscriber Can Edit | API Name, URL | ### More Information **Feature Name:** Metadata Name: LoyaltyProgramSetup; Component Type in 1GP Package Manager UI: Loyalty Program Setup **Use Case:** Promotion setup allows loyalty program managers to create loyalty program processes. **License Requirements:** Loyalty Management permission set license **Documentation:** _Salesforce Help:_ [Create Processes with Promotion Setup](https://help.salesforce.com/s/articleView?id=https://help.salesforce.com/s/articleView?id=xcloud.promotion_setup.htm&type=5) ## Managed Content Type Represents the definition of custom content types for use with Salesforce CMS. Custom content types are displayed as forms with defined fields. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Content, Description, Labels | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ManagedContentType **Use Case:** Share or distribute custom content types for use in enhanced workspaces in Salesforce CMS. **Considerations When Packaging** Installed content types are available only to enhanced CMS workspaces. To refer to an installed content type when using Connect REST API, you must use the content type’s fully qualified name. Installed content types are available only to enhanced CMS workspace resources. **Documentation:** _Metadata API Developer Guide_: [ManagedContentType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_managedcontenttype.htm); _Connect REST API Developer Guide_: [Enhanced CMS Workspaces Resources](https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_managed_content_enhanced_resources.htm); _CMS Developer Guide_: [Create Custom Content Type Sample](https://developer.salesforce.com/docs/platform/cms/guide/cms-dev-create-custom-content-type-sample.html) ## Marketing App Extension Represents an integration with a third-party app or service that generates prospect external activity. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | DeveloperName, MasterLabel, Description | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MarketingAppExtension; Component Type in 1GP Package Manager UI: Marketing App Extension **Use Case:** Partners and ISVs can provide integrations with third-parties so Account Engagement customers can enhance their automations. **Considerations When Packaging** Marketing app extensions require an associated action type component to function. The related component activity type isn’t supported for packaging. **License Requirements** This feature is available in Plus, Advanced, or Premium editions of Account Engagement. To work with marketing app extensions, users must be a Salesforce admin or have the [required permissions to access Marketing Setup](https://help.salesforce.com/s/articleView?id=mktg.pardot_admin_marketing_admin.htm&type=5). . **Usage Limits** The number of active extensions, activities, and actions the end user can have at one time depends on their edition of Account Engagement. - Plus—10 active extensions, with 10 active activities and 10 active actions per active extension - Advanced—20 active extensions, with 20 active activities and 20 active actions per active extension - Premium—30 active extensions, with 30 active activities and 30 active actions per active extension For more on limits, see For more on limits, see [Considerations for Working with Marketing App Extensions.](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensions_considerations.htm&type=5) **Post Install Steps:** To receive data, the extension must be activated for automations and have a business unit assignment. **Relationship to Other Components:** The extension requires an associated action type component to function. **Documentation** This component is part of Account Engagement’s extensibility feature set. - _Salesforce Help:_ [Automate Data Sharing with Third-Party Apps](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensibility_parent.htm&type=5) - _Developer Guide:_ [Work with Extensibility Features](https://developer.salesforce.com/docs/marketing/pardot/guide/extensibility-features-overview.html) ## Marketing App Extension Activity Represents an Activity Type, which is a prospect activity that occurs in a third-party app and can be used in Account Engagement automations. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | MasterLabel, Description | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | DeveloperName, EndpointUrl, MarketingAppExtension | ### More Information **Feature Name:** Metadata Name: MarketingAppExtActivity; Component Type in 1GP Package Manager UI: Marketing App Extension **Use Case:** Partners and ISVs can use Activities to submit external prospect engagement data to Marketing Cloud Account Engagement. **Considerations When Packaging** This component is included when the parent component [MarketingAppExtension](#marketing-app-extension) is added to a package. The related component MarketingAppExtActivity isn’t supported for packaging. is added to a package. The related component MarketingAppExtActivity isn’t supported for packaging. **License Requirements** This feature is available in Plus, Advanced, or Premium editions of Account Engagement. To work with marketing app extensions and related components, users must be a Salesforce admin or have the [required permissions to access Marketing Setup](https://help.salesforce.com/s/articleView?id=mktg.pardot_admin_marketing_admin.htm&type=5). . **Usage Limits** The number of active extensions, activities, and actions the end user can have at one time depends on their edition of Account Engagement. - Plus—10 active activities per active extension - Advanced—20 active activities per active extension - Premium—30 active activities per active extension For more information, see For more information, see [Considerations for Working with Marketing App Extensions.](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensions_considerations.htm&type=5) **Post Install Steps:** To receive data, the activity and its related extension must be activated for automations. **Relationship to Other Components** This component is a child of the [MarketingAppExtension](#marketing-app-extension) component. Activities interact with Marketing Cloud Account Engagement features that support external activities. For more information, see component. Activities interact with Marketing Cloud Account Engagement features that support external activities. For more information, see [Capture External Prospect Activity](https://help.salesforce.com/s/articleView?id=mktg.pardot_external_activity_parent.htm&type=5). . **Documentation** This component is part of Account Engagement’s extensibility feature set. - _Salesforce Help:_ [Automate Data Sharing with Third-Party Apps](https://help.salesforce.com/s/articleView?id=mktg.pardot_extensibility_parent.htm&type=5) - _Developer Guide:_ [Work with Extensibility Features](https://developer.salesforce.com/docs/marketing/pardot/guide/extensibility-features-overview.html) ## Market Segment Definition Represents the field values for MarketSegmentDefinition. MarketSegmentDefinition is used to store the exportable metadata of a segment, such as segment criteria and other attributes. Developers can create segment definition packages, pass segment definition in the form of data build tool (DBT), and publish it on AgentExchange for subscriber organizations to install and instantiate these segments. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------- | | Only Package Developer Can Edit | Yes, applicable for all properties. | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MarketSegmentDefinition; Component Type in 1GP Package Manager UI: Market Segment Definition **Documentation:** [REQUIRED] ## MktCalculatedInsightsObjectDef Represents Calculated Insight definition such as expression. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------- | | Only Package Developer Can Edit | BuilderExpression, CalculatedInsightCreationType, Description, Expression, Label | | Both Package Developer and Subscriber Can Edit | CalculatedInsightObjectDefinitionStatus, Description | | Neither Package Developer or Subscriber Can Edit | DeveloperName | ### More Information **Feature Name:** Metadata Name: MktCalcInsightObjectDef; Component Type in 1GP Package Manager UI: MktCalcInsightObjectDef. **Use Case:** Defines CDP calculated insight for easy creation on subscriber organizations. **Considerations When Packaging** To package this component, first add it to a data kit. For more information about data kits, see [Data Kits](https://help.salesforce.com/s/articleView?id=data.c360_a_data_package_kits.htm&type=5) in in _Salesforce Help_. . **License Requirements:** You need Customer 360 Audiences Corporate (cdpPsl) licenses on both package developer org and subscriber org. **Post Install Steps** User has to go to the **Calculated Insights** object home in Customer Data Platform, click object home in Customer Data Platform, click **New action** and select and select **Create from a Package**. . **Relationship to Other Components** Calculated Insight Component is tied to the Data Model Object component. The Calculated Insight component must have Data Model Object dependencies available on the subscriber organization that are used in the Calculated Insight. **Documentation:** _Metadata API Developer Guide:_ [MktCalcInsightObjectDef](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_mktcalcinsightobjectdef.htm) ## MktDataConnection Represents the connection information of an external connector that can ingest data to Data Cloud, read data from the source, or write data to the source in Data Cloud. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | masterLabel, Parameters, Credentials | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: MktDataConnection; Component Type in 1GP Package Manager UI: Data Connection **Use Case:** To reuse connection parameters. **Considerations When Packaging** Connection credentials are excluded from the package. Available parameters are defined in Connector Metadata which is exposed from Connect API. **License Requirements** Data Cloud must be provisioned. For more information, see [Data Cloud: Access and Provisioning.](https://help.salesforce.com/s/articleView?id=000396444&type=1) **Usage Limits:** The number of connections per connector type can be up to 200. **Post Install Steps:** After you create the connection, it will be in INACTIVE state, you must manually activate the connection. **Relationship to Other Components:** Must be used with Data Stream and Activation. **Documentation:** Salesforce Help: [Third-Party Data Cloud Connectors](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-data-cloud-integrations.html) ## MktDataTranObject An entity that is used to deliver (aka transport) information from the source to a target (target will be called a landing entity).This can be the schema of a file, API, Event, or other means of transporting data, such as SubscriberFile1.csv, or SubscriberCDCEvent. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DataSource, DataSourceObject, DeveloperName, ObjectCategory, Status | | Both Package Developer and Subscriber Can Edit | DataConnector | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name** Metadata Name: MktDataTranObject Component Type in 1GP Package Manager UI: It's not a top-level component, it can only be spidered in when customer selects some other component. You won't be able to add this component directly to the package. **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [MktDataTranObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_mktdatatranobject.htm) ## Named Credential Represents a named credential, which specifies the URL of a callout endpoint and its required authentication parameters in one definition. A named credential can be specified as an endpoint to simplify the setup of authenticated callouts. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** In addition to these properties, the Description, ParameterName, ParameterValue, and SequenceNumber properties have the same editability as the NamedCredentialParameters they’re included in. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label, NamedCredentialType, Legacy Named Credentials only (deprecated and unsupported in future releases) | | Both Package Developer and Subscriber Can Edit | CalloutOptions, NamedCredentialParameters, Legacy Named Credentials only (deprecated and unsupported in future releases) | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: NamedCredential **Considerations When Packaging** Certificates aren’t packageable. If a certificate needs access to an external system, an administrator must upload one to the subscriber org and reference it in the named credential. **Relationship to Other Components** You must package NamedCredential with the associated ExternalCredential component. The named credential defines a callout endpoint and an HTTP transport protocol, while the external credential represents the details of how Salesforce authenticates to an external system via an authentication protocol. Each named credential must be mapped to at least one external credential. **Legacy Named Credentials** **important:** In Winter ’23, Salesforce introduced an improved named credential that is extensible and customizable. We strongly recommend that you use this preferred credential instead of legacy named credentials. For information on extensible, customizable named credentials, see [Named Credentials and External Credentials](https://help.salesforce.com/s/articleView?id=nc_named_creds_and_ext_creds.htm). Legacy named credentials are deprecated and will be discontinued in a future release. After installing a named credential from a managed or unmanaged package, the subscriber must reauthenticate to the external system. - For password authentication, the subscriber reenters the password in the named credential definition. - For OAuth, the subscriber updates the callback URL in the client configuration for the authentication provider and then reauthenticates by selecting **Start Authentication Flow on Save** on the named credential. **Documentation:** _Salesforce Help_: [Named Credentials](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5); _Named Credentials Developer Guide:_ [Named Credentials Packaging Guide](https://developer.salesforce.com/docs/platform/named-credentials/guide/nc-packaging-dev-guide.html); _Metadata API Developer Guide:_ [NamedCredential](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_namedcredential.htm) ## Object Source Target Map Contains the object-level mappings between the source and the target objects. The source and target objects can be an MktDataLakeObject or an MktDataModelObject. For example, an Email source object can be mapped to the ContactPointEmail object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | CreationType, DeveloperName, MasterLabel, ParentObject, SequenceNbr, SourceObject, TargetObject | | Both Package Developer and Subscriber Can Edit | LastDataChangeStatusDateTime, LastDataChangeStatusErrorCode, Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name** Metadata Name: ObjectSourceTargetMap Component Type in 1GP Package Manager UI: It's not a top-level component, it can only be spidered in when customer selects some other component. You won't be able to add this component directly to the package. **License Requirements:** Data Cloud must be provisioned. **Documentation:** _Metadata API Developer Guide:_ [ObjectSourceTargetMap](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_objectsourcetargetmap.htm) ## Object Integration Provider Definition Mapping Maps structured, logical data nodes in a context definition to actual Salesforce object fields or external data sources ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ## OcrSampleDocument Represents the details of a sample document or a document type that's used as a reference while extracting and mapping information from a customer form. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** OcrSampleDocument; Component Type in 1GP Package Manager UI: OcrSampleDocument **Use Case:** Migrate sample documents created with the Intelligent Form Reader or Intelligent Document Reader feature. **Considerations When Packaging:** If you update the package by deleting OcrSampleDocumentFields associated with the OCRTemplate, the OcrSampleDocumentFields are not deleted. **License Requirements:** AWSTextract1000LimitAddOn-1 for the Intelligent Form Reader feature or IntelligentDocumentReaderAddOn-1 for the Intelligent Document Reader feature. **Relationship to Other Components:** DocumentType, ContentAsset, and OcrTemplate (Optional) **Documentation:** _Metadata API Developer Guide:_ [OcrSampleDocument](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_ocrsampledocument.htm) ## OcrTemplate Represents the details of the mapping between a form and a Salesforce object using Intelligent Form Reader. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** OcrTemplate; Component Type in 1GP Package Manager UI: OcrTemplate **Use Case:** Migrate Mappings created with the Intelligent Form Reader or Intelligent Document Reader feature. **Considerations When Packaging** OcrTemplate has a dependency on OcrSampleDocument. Before deploying the package, make sure to either include OcrSampleDocument in the package or deploy a package that contains OcrSampleDocument. **License Requirements:** AWSTextract1000LimitAddOn-1 for the Intelligent Form Reader feature or IntelligentDocumentReaderAddOn-1 for the Intelligent Document Reader feature. **Relationship to Other Components:** DocumentType and OcrSampleDocument **Documentation:** _Metadata API Developer Guide:_ [OcrTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_ocrtemplate.htm) ## Outbound Network Connection Represents a private connection between a Salesforce org and a third-party data service. The connection is outbound because the callouts are going out of Salesforce. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** You can only delete connections that are in an unprovisioned state. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. **note:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Connection Type, Developer Name, Description, Master Label, Region, Service Name | | Both Package Developer and Subscriber Can Edit | Status | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: OutboundNetworkConnection; Component Type in 1GP Package Manager UI: Outbound Network Connection **Considerations When Packaging** - Packaged connections are installed as unprovisioned. Alert subscribers about how to provision connections after package installation. - If a developer changes the Region or Service Name of a packaged connection that is subscriber-provisioned, the upgrade fails for the subscriber. Alert subscribers about tearing down the connection before you update the Region or Service Name fields. As a best practice, avoid changing the Region or Service Name of a packaged connection unless necessary. - If you package a Named Credential that references an Outbound Network Connection, the referenced Outbound Network Connection component is automatically added to the package. **License Requirements:** This feature is available with the Private Connect license. **Documentation:** _Salesforce Help:_ [Secure Cross-Cloud Integrations with Private Connect](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5); _Salesforce Help:_ [Establish an Outbound Connection with AWS](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_outbound_aws.htm&type=5) ## Page Layout Represents the metadata associated with a page layout. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Page Layout Name | | Neither Package Developer or Subscriber Can Edit | Page Layout Name | ### More Information **Feature Name:** Metadata Name: Layout **Considerations** The page layout of the person uploading a package is the layout used for Group and Professional Edition orgs and becomes the default page layout for Enterprise, Unlimited, Performance, and Developer Edition orgs. Package page layouts alongside complimentary record types if the layout is being installed on an existing object. Otherwise, manually apply the installed page layouts to profiles. If a page layout and a record type are created as a result of installing a package, the uploading user’s page layout assignment for that record type is assigned to that record type for all profiles in the subscriber org, unless a profile is mapped during an install or upgrade. **Documentation:** _Metadata API Developer Guide:_ [Layout](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_layouts.htm) ## Path Assistant Represents Path records. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | IsActive field | | Neither Package Developer or Subscriber Can Edit | SobjectType, SobjectProcessField, and RecordType | ### More Information **Feature Name:** Metadata Name: PathAssistant; Component Type in 1GP Package Manager UI: Path Assistant **Documentation:** _Metadata API Developer Guide:_ [PathAssistant](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_pathassistant.htm) ## Payment Gateway Provider Represents the metadata associated with a payment gateway provider. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | All fields | ### More Information **Feature Name:** Metadata Name: PaymentGatewayProvider **License Requirements** Salesforce Order Management, B2B Commerce, or B2C Commerce (for B2B2C Commerce) licenses are required. These licenses enable the Payment Platform org permission required to use payments objects. **Documentation:** _Salesforce Help:_ [Processing Payments with Payment Gateways](https://help.salesforce.com/s/articleView?id=sales.blng_payment_gateways.htm&type=5) ## Permission Set Represents a set of permissions that's used to grant more access to one or more users without changing their profile or reassigning profiles. You can use permission sets to grant access but not to deny access. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Label, Custom object permissions, Custom field permissions, Apex class access settings, Visualforce page access settings | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: PermissionSet; Component Type in 1GP Package Manager UI: Permission Set **Documentation:** _Metadata API Developer Guide:_ [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm) ## Permission Set Groups Represents a group of permission sets and the permissions within them. Use permission set groups to organize permissions based on job functions or tasks. Then, you can package the groups as needed. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Permission Set Group Components (Developer can add and remove while Subscriber can add) | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PermissionSetGroup; Component Type in 1GP Package Manager UI: Permission Set Group **Considerations When Packaging** Don't assume that a subscriber's permission set group is the same as what the developer has specified. Although developers can define the permission set group and what permission sets can go into it, subscribers can add additional permission sets or mute permissions. **Relationship to Other Components:** This feature can only be used in conjunction with Permission Sets. **Documentation:** _Salesforce Help:_ [Permission Set Groups](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups.htm&type=5) ## Platform Cache Represents a partition in the Platform Cache. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------- | | Only Package Developer Can Edit | Master Label, Description, Default Partition | | Both Package Developer and Subscriber Can Edit | Organization Capacity, Trial Capacity | | Neither Package Developer or Subscriber Can Edit | Developer Name | ### More Information **Feature Name:** Metadata Name: PlatformCachePartition; Component Type in 1GP Package Manager UI: Platform Cache Partition **Documentation:** [Set Up a Platform Cache Partition with Provider Free Capacity](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/data_platform_cache_setup_provider_capacity.htm); _Metadata API Developer Guide:_ [PlatformCachePartition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformcachepartition.htm); _Apex Developer Guide:_ [Platform Cache Partitions](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_partition_setup.htm) ## Platform Event Channel Represents a channel that you can subscribe to in order to receive a stream of events. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: PlatformEventChannel; Component Type in 1GP Package Manager UI: Platform Event Channel **Documentation:** _Metadata API Developer Guide:_ [PlatformEventChannel](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformeventchannel.htm) ## Platform Event Channel Member Represents an entity selected for Change Data Capture notifications on a standard or custom channel, or a platform event selected on a custom channel. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: PlatformEventChannelMember; Component Type in 1GP Package Manager UI: Platform Event Channel Member **Considerations When Packaging** - As of Winter ’22, installing a managed package that contains Change Data Capture entity selections no longer causes an installation error. Before Winter ’22, installing a managed package that contained Change Data Capture entity selections that were over the default allocation caused package installation errors. - To package Change Data Capture entity selections, create a custom channel through the PlatformEventChannel metadata type. Then add entity selections to the custom channel through the PlatformEventChannelMember metadata type. **Documentation:** _Metadata API Developer Guide:_ [PlatformEventChannelMember](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_platformeventchannelmember.htm) ## Platform Event Subscriber Configuration Represents configuration settings for a platform event Apex trigger, including the batch size, the trigger’s running user, and parallel subscription settings. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No. PlatformEventSubscriberConfig is tied to an Apex trigger. If the package developer removes the Apex trigger, PlatformEventSubscriberConfig is also removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | batchSize, numPartitions, partitionKey, platformEventConsumer | | Both Package Developer and Subscriber Can Edit | user | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PlatformEventSubscriberConfig; Component Type in 1GP Package Manager UI: Platform Event Subscriber Configuration **Use Case:** Override the default running user and batch size of a platform event Apex trigger. **Relationship to Other Components:** PlatformEventSubscriberConfig is tied to an Apex trigger. **Documentation:** _Platform Events Developer Guide_: [Configure the User and Batch Size for Your Platform Event Trigger](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_trigger_config.htm); _Platform Events Developer Guide_: [Platform Event Processing at Scale with Parallel Subscriptions for Apex Triggers](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_ps.htm) ## Pricing Action Parameters Represents a pricing action associated to a context definition and a pricing procedure. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Pricing Action Parameters Name | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PricingActionParameters; Component Type in 1GP Package Manager UI: PricingActionParameters **License Requirements:** Salesforce Pricing permissions **Relationship to Other Components:** All the components that pricing depends on are packaged along with the Pricing Action Parameters component. **Documentation:** _Salesforce Help:_ [Pricing Action Parameters in Salesforce Pricing](https://help.salesforce.com/s/articleView?id=ind.pricing_pricing_action_parameters.htm&type=5) ## Pricing Recipe Represents one out of various data models or sets of entities of a particular cloud that'll be consumed by the pricing data store during design and run time. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Recipe Name | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: PricingRecipe; Component Type in 1GP Package Manager UI: PricingRecipe **Considerations When Packaging** There are two prerequisites currently. All the associated contexts aren’t exported. For decision tables, while exporting, column additions made to the associated objects aren’t refreshed during export. **License Requirements:** Salesforce Pricing permissions **Relationship to Other Components:** All the components that pricing is dependent on are packaged along with the pricing recipe. **Documentation:** _Salesforce Help:_ [Pricing Recipes](https://help.salesforce.com/s/articleView?language=en_US&id=sf.pricing_pricing_recipes.htm) ## Procedure Output Resolution Represents the pricing resolution for an pricing element determined using strategy name and formula. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------- | | Only Package Developer Can Edit | Active Checkbox | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ProcedureOutputResolution; Component Type in 1GP Package Manager UI: ProcedureOutputResolution **Use Case:** To determine the best price for a product if a pricing rule produces multiple outcomes. **License Requirements:** Salesforce Pricing permissions **Documentation:** _Salesforce Help:_ [Procedure Output Resolution](https://help.salesforce.com/s/articleView?id=ind.pricing_procedure_output_resolution.htm&type=5) ## Process Use Flow instead. See [Flow](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_flow) ## Process Flow Migration Represents a process's migrated criteria and the resulting migrated flow. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Description, Label, Name | ### More Information **Feature Name:** Metadata Name: ProcessFlowMigration; Component Type in 1GP Package Manager UI: Process Flow Migration **Use Case** Include this component only if you’ve used Migrate to Flow tool and wish to have pending Scheduled Actions from migrated Processes converted into pending Flow Scheduled Paths in subscriber orgs. This occurs after the migrated Flow is activated in the subscriber org. **Considerations When Packaging** When packaging a Flow that was migrated from a Process, this component is added automatically. When adding a Flow that was migrated from a Process to a change set, this component would need to be added manually. **Relationship to Other Components** Flows **Documentation:** _Salesforce Help:_ [Migrate Processes and Workflows to Flow](https://help.salesforce.com/s/articleView?id=platform.flow_migrate_to_flow.htm&type=5) ## Product Attribute Set Represents the ProductAttribute information being used as and attribute such as color_c, size_c . ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Description, Master Label | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ProductAttributeSet **License Requirements:** A B2B Commerce or D2C Commerce license and access to Commerce objects is required. **Usage Limits:** An org can have a maximum of 100 product attribute sets.; For each product attribute set, you can have a maximum of five associated product attribute set items. **Documentation:** _Salesforce Help:_ [Product Variations and Attributes](https://help.salesforce.com/s/articleView?id=commerce.comm_var_att_intro.htm&type=5); _Metadata API Developer Guide:_ [ProductAttributeSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_productattributeset.htm) ## Product Specification Type Represents the type of product specification provided by the user to make the product terminology unique to an industry. A product specification type is associated with a product specification record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------ | | Only Package Developer Can Edit | Label, Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ProductSpecificationType; Component Type in 1GP Package Manager UI: ProductSpecificationType **License Requirements** Only Salesforce Admins can set up the product specification type. To create and edit product specification type, the Product Catalog Management Designer permission set is required. To view product specification type, the Product Catalog Management Viewer permission set is required. **Documentation:** _Salesforce Help:_ [Product Specification](https://help.salesforce.com/s/articleView?id=ind.product_catalog_product_specification.htm&type=5); _Salesforce Help:_ [Create Product Specification Type and Product Specification Record Type](https://help.salesforce.com/s/articleView?id=ind.product_catalog_create_product_specification_type_and_product_specification_record_type.htm&type=5) ## Product Specification Record Type Represents the relationship between industry-specific product specifications and the product record type. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------- | | Only Package Developer Can Edit | Label, Record Type, Product Specification Type | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name, Is Commercial | ### More Information **Feature Name:** Metadata Name: ProductSpecificationRecType; Component Type in 1GP Package Manager UI: ProductSpecificationRecType **License Requirements** Only Salesforce admins can set up the product specification record type. To create and edit product specification record type, the Product Catalog Management Designer permission set is required. To view product specification record type, the Product Catalog Management Viewer permission set is required. **Documentation:** _Salesforce Help:_ [Product Specification](https://help.salesforce.com/s/articleView?id=ind.product_catalog_product_specification.htm&type=5); _Salesforce Help:_ [Create Product Specification Type and Product Specification Record Type](https://help.salesforce.com/s/articleView?id=ind.product_catalog_create_product_specification_type_and_product_specification_record_type.htm&type=5) ## Prompts (In-App Guidance) Represents the metadata related to in-app guidance, which includes prompts and walkthroughs. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: Prompt; Component Type in 1GP Package Manager UI: Prompt **Considerations When Packaging** For 2GP packages, ensure that the scratch org definition file includes the `GuidanceHubAllowed` and `Enablement` features. See [Build Your Own Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) in the _Salesforce DX Developer Guide_. **License Requirements:** Enablement Admin permission set and Enablement permission set license are required. **Documentation:** _Metadata API Developer Guide:_ [Prompt](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_prompt.htm); _Salesforce Help:_ [Guidelines for In-App Guidance in Managed Packages](https://help.salesforce.com/s/articleView?id=sales.customhelp_iag_packages.htm&type=5) ## Quick Action Represents a specified create or update quick action for an object that then becomes available in the Chatter publisher. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | Field Overrides | | Both Package Developer and Subscriber Can Edit | All attributes except Field Overrides | | Neither Package Developer or Subscriber Can Edit | None | **note:** You can only modify managed package quick action layouts in Salesforce Setup. You can't make changes using Metadata API. ### More Information **Feature Name:** Metadata Name: QuickAction; Component Type in 1GP Package Manager UI: Quick Action **Documentation:** _Salesforce Help:_ [Quick Actions](https://help.salesforce.com/s/articleView?id=platform.actions_overview.htm&type=5) ## Recommendation Strategy Represents a recommendation strategy. Recommendation strategies are applications, similar to data flows, that determine a set of recommendations to be delivered to the client through data retrieval, branching, and logic operations. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | Yes, except templates | ### More Information **Feature Name:** Metadata Name: RecommendationStrategy; Component Type in 1GP Package Manager UI: Recommendation Strategy **Use Case** You can use this component to create personalized recommendations for end users. A recommendation displays contextually in Salesforce and prompts the end user to accept or reject the suggestion. When an end user accepts or rejects the recommendation, Salesforce automates a process, such as creating or updating a record. **Considerations When Packaging:** When you package a recommendation strategy, you must manually add object dependencies, such as recommendation, recommendationReaction, and flow. **Usage Limits:** An admin must select an object dependency for Recommendation and RecommendationReaction because object dependencies aren't added automatically. **Documentation:** _Salesforce Help:_ [Einstein Next Best Action](https://help.salesforce.com/s/articleView?id=platform.einstein_next_best_action.htm&type=5) ## Record Action Deployment Represents configuration settings for the Actions & Recommendations, Action Launcher, and Bulk Action Panel components. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Channel Configurations, Deployment Contexts, HasGuidedActions, HasRecommendations, Label, Recommendations, SelectableItems, ShouldLaunchActionOnReject | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: RecordActionDeployment; Component Type in 1GP Package Manager UI: RecordAction Deployment **Considerations When Packaging:** If the record action deployment component uses flows, quick actions, objects, or Next Best Action recommendations, include them in the package too. **Documentation:** _Metadata API Developer Guide:_ [RecordActionDeployment](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_recordactiondeployment.htm); _Salesforce Help:_ [Create an Actions & Recommendations Deployment](https://help.salesforce.com/s/articleView?id=service.console_lex_guided_action_deployment.htm&type=5) ## Record Alert Data Source Expression Set Definition Represents information about the data source for a record alert and the association with an expression set definition. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | ExpressionSetDefinition, ExpressionSetObject, IsActive, RecordAlertDataSource | | Neither Package Developer or Subscriber Can Edit | FullName, Metadata | ### More Information **RecAlrtDataSrcExpSetDef:** Metadata Name: RecAlrtDataSrcExpSetDef; Component Type in 1GP Package Manager UI: RecAlrtDataSrcExpSetDef **Documentation:** [RecAlrtDataSrcExpSetDef](https://developer.salesforce.com/docs/atlas.en-us.financial_services_cloud_object_reference.meta/financial_services_cloud_object_reference/sforce_api_objects_recalrtdatasrcexpsetdef.htm) in in _Financial Services Cloud Developer Guide_.. ## Record Type Represents the metadata associated with a record type. Record types let you offer different business processes, picklist values, and page layouts to different users. Use this metadata type to create, update, or delete record type definitions for a custom object. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------ | | Only Package Developer Can Edit | Description, Record Type Label | | Both Package Developer and Subscriber Can Edit | Active, Business Process | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: RecordType; Component Type in 1GP Package Manager UI: Record Type **Considerations When Packaging** - If record types are included in the package, the subscriber’s org must support record types to install the package. - When a new picklist value is installed, it’s associated with all installed record types according to the mappings specified by the developer. A subscriber can change this association. - Referencing an object’s record type field in a report’s criteria—for example, Account Record Type—causes a dependency. - Summarizing by an object’s record type field in a report’s criteria—for example, Account Record Type—causes a dependency. - If an object’s record type field is included as a column in a report, and the subscriber’s org isn’t using record types on the object or doesn’t support record types, the column is dropped during installation. - If you install a custom report type that includes an object’s record type field as a column, that column is dropped if the org doesn’t support record types or the object doesn’t have record types defined. **Documentation:** _Metadata API Developer Guide:_ [RecordType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_recordtype.htm) ## RedirectWhitelistUrl Represents a trusted URL that’s excluded from redirection restrictions when the redirectionWarning or redirectBlockModeEnabled field on the SessionSettings Metadata type is set to true. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Url | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RedirectWhitelistUrl; Component Type in 1GP Package Manager UI: RedirectWhitelistUrl **Use Case** Customers can use a Salesforce security setting to specify what happens when a user clicks a hyperlink that redirects to an untrusted URL outside the salesforce.com domain. The customer can choose to block these redirections or alert the user that the link is taking them outside the Salesforce domain. The URLs in RedirectWhiteListURL are considered trusted for the purpose of that security setting. If the Experience Cloud site pages, Lightning Experience pages, or custom Visualforce pages in your package include hyperlinks to URLs outside the salesforce.com domain, use RedirectWhitelistURL to ensure that users can access those hyperlinks. **Considerations When Packaging** When you include a RedirectWhitelistURL in a package, the URLs are trusted for redirections across Salesforce. Because this component modifies the security of the org, we don’t recommend that you include RedirectWhitelistURL in packages. Instead, instruct customers to use the Trusted URLs for Redirects Setup page or the RedirectWhitelistURL Metadata API type to add the URLs to their allowlist as part of activating your package. If you choose to include RedirectWhitelistURL components in your package, disclose this change prominently in your package documentation to ensure that your customers are aware of the security modification. **Usage Limits:** The RedirectWhiteListURL component is available in API version 48.0 and later. **Relationship to Other Components:** This component can be used only in conjunction with an Aura or Lightning Web Runtime (LWR) page for an Experience Cloud site, a [Lightning Page](#lightning-page), or a , or a [Visualforce Page](#visualforce-page).. **Documentation:** _Metadata API Developer Guide_: [RedirectWhitelistUrl](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_redirectwhitelisturl.htm); Salesforce Help: [Manage Redirections to External URLs](https://help.salesforce.com/s/articleView?id=xcloud.security_external_redirects.htm&type=5); _Metadata API Developer Guide_: [SecuritySettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_securitysettings.htm)]] ## Referenced Dashboard Represents the ReferencedDashboard object in CRM Analytics. A referenced dashboard stores information about an externally referenced dashboard. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Embed URL, Template Asset Source Name, Visibility | ### More Information **Feature Name:** Metadata Name: ReferencedDashboard **License Requirements:** Enables Tableau Dashboards in CRM Analytics ## Registered External Service Represents a registered external service, which provides an extension or integration. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RegisteredExternalService; Component Type in 1GP Package Manager UI: RegisteredExternalService **Documentation:** _Object Reference for the Salesforce Platform:_ [RegisteredExternalService](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_registeredexternalservice.htm) ## RelationshipGraphDefinition Represents a definition of a graph that you can configure in your organization to traverse object hierarchies and record details, giving you a glimpse of how your business works. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All properties | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: RelationshipGraphDefinition; Component Type in 1GP Package Manager UI: RelationshipGraphDefinition **Documentation:** _Metadata API Developer Guide:_ [RelationshipGraphDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_relationshipgraphdefinition.htm) ## Remote Site Setting Represents a remote site setting. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Remote Site Name | | Neither Package Developer or Subscriber Can Edit | Remote Site Name | ### More Information **Feature Name:** Metadata Name: RemoteSiteSettings **Documentation:** _Metadata API Developer Guide:_ [RemoteSiteSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_remotesitesetting.htm) ## Report Represents a custom report. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | No | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes except Report Unique Name | | Neither Package Developer or Subscriber Can Edit | Report Unique Name | ### More Information **Feature Name:** Metadata Name: Report; Component Type in 1GP Package Manager UI: Report **Considerations When Packaging** If a report includes elements that can’t be packaged, those elements are dropped or downgraded, or the package creation fails. For example: - Hierarchy drill-downs are dropped from activity and opportunities reports. - Filters on unpackageable fields are automatically dropped (for example, in filters on standard object record types). - Package upload fails if a report includes filter logic on an unpackageable field (for example, in filters on standard object record types). - Lookup values on the Select Campaign field of standard campaign reports are dropped. - Reports are dropped from packages if they’ve been moved to a private folder or to the Unfiled Public Reports folder. - When a package is installed into an org that doesn’t have Chart Analytics 2.0: - Combination charts are downgraded instead of dropped. For example, a combination vertical column chart with a line added is downgraded to a simple vertical column chart. A combination bar chart with more bars is downgraded to a simple bar chart. - Unsupported chart types, such as donut and funnel, are dropped. **Documentation:** _Metadata API Developer Guide:_ [Report](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_report.htm) ## Report Type Represents the metadata associated with a custom report type. Custom report types allow you to build a framework from which users can create and customize reports. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 2GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------- | | Only Package Developer Can Edit | All attributes except Development Status and Report Type Name | | Both Package Developer and Subscriber Can Edit | Development Status | | Neither Package Developer or Subscriber Can Edit | Report Type Name | ### More Information **Feature Name:** Metadata Name: ReportType; Component Type in 1GP Package Manager UI: Custom Report Type **Considerations When Packaging** A developer can edit a custom report type in a managed package after it’s released, and can add new fields. Subscribers automatically receive these changes when they install a new version of the managed package. However, developers can’t remove objects from the report type after the package is released. If you delete a field in a custom report type that’s part of a managed package, and the deleted field is part of bucketing or used in grouping, an error message appears. **Documentation:** _Metadata API Developer’s Guide:_ [ReportType](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_reporttype.htm) ## ServiceProcess Represents a process created in Service Process Studio and its associated attributes. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | All other fields | | Both Package Developer and Subscriber Can Edit | Status, Description, ServiceProcessAttribute, ServiceProcessDependency, ServiceProcessItemGroup | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **ServiceProcess:** Metadata Name: ServiceProcess; Component Type in 1GP Package Manager UI: ServiceProcess **Documentation:**[ServiceProcess](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_serviceprocess.htm) in _Metadata API Developer Guide_.. ## Slack App (Beta) Represents a Slack app. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | AppKey, AppToken, ClientKey, ClientSecret, SigningSecret, BotScopes, UserScopes, Config, IntegrationUser, DefaultUser | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SlackApp; Component Type in 1GP Package Manager UI: Slack App **Use Case:** Represents configuration of a Slack application **License Requirements:** Connect to Slack Permission **Relationship to Other Components:** Slack apps reference handlers (Apex classes) and view definition components. **Documentation:** [Apex SDK for Slack Developer Guide](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/overview) ## Service Catalog Category Represents the grouping of individual catalog items in Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | ParentCategory | | Both Package Developer and Subscriber Can Edit | SortOrder, IsActive, Image | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogCategory; Component Type in 1GP Package Manager UI: Service Catalog Category **Use Case:** Group your service catalog items together by associating them with a catalog category. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Post Install Steps:** Categories appear in the Service Catalog user UI only if they contain active items. **Documentation:** _Salesforce Help:_ [Create a Catalog Category](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_category.htm&type=5) ## Service Catalog Filter Criteria Represents an eligibility rule that determines if a Service Catalog user has access to a catalog item. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------- | | Only Package Developer Can Edit | All fields | | Both Package Developer and Subscriber Can Edit | All fields | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogFilterCriteria; Component Type in 1GP Package Manager UI: Service Catalog Item Definition **Use Case:** Use the filter criteria to filter on catalog items. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Relationship to Other Components:** Service catalog filter criteria are related to a catalog item definition. **Documentation:** _Salesforce Help:_ [Create a Catalog Category](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_category.htm&type=5) ## Service Catalog Item Definition Represents the entity associated with a specific, individual service available in the Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------- | | Only Package Developer Can Edit | Flow | | Both Package Developer and Subscriber Can Edit | Status, Description, InternalNotes, Image, IsFeatured, IsPublic | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogItemDef; Component Type in 1GP Package Manager UI: Service Catalog Item Definition **Use Case:** Create a service catalog item that employees can request in the Service Catalog user UI. **Considerations When Packaging:** Subscribers can't change properties stored in the catalog item fulfillment flow unless they make a clone of the item and its related flow. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Usage Limits:** The org can have only 1000 SvcCatalogItemDefs, including those items installed from a managed package. **Post Install Steps:** If the item was installed in draft mode, it must be activated before employees can see it in the Service Catalog user UI. **Relationship to Other Components:** SvcCatalogItemDef requires a relationship with a catalog category. **Documentation:** _Salesforce Help:_ [Create a Catalog Item](https://help.salesforce.com/s/articleView?id=service.esc_create_a_catalog_item.htm&type=5) ## Service Catalog Fulfillment Flow Represents the flow associated with a specific catalog item in the Service Catalog. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------- | | Only Package Developer Can Edit | Description, Flow, Icon | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | FullName | ### More Information **Feature Name:** Metadata Name: SvcCatalogFulfillmentFlow; Component Type in 1GP Package Manager UI: Service Catalog Fulfillment Flow **Use Case** Make a screen flow available in the Service Catalog builder. You can also use SvcCatalogFulfillmentFlow metadata to describe the flow and its inputs in the builder, enabling a clicks-not-code experience for providing inputs to the flow. **License Requirements:** Service Catalog Add-On License; Service Catalog Builder Permission Set **Post Install Steps:** Fulfillment flows appear in the Service Catalog builder only if the underlying screen flow is active in the org. **Relationship to Other Components:** SvcCatalogFulfillmentFlow must be related to a FlowDefinition.; SvcCatalogFulfillmentFlow can have related SvcCatalogFulfillFlowItem records. **Documentation:** _Salesforce Help:_ [Catalog Item Fulfillment Flows](https://help.salesforce.com/s/articleView?id=service.esc_catalog_item_fulfillment_flows.htm&type=5) ## Stationary Asset Environmental Source Record Type Configuration Represents the setup object that contains the mapping between the Stationary Asset Environmental Source record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: StnryAssetEnvSrcCnfg; Component Type in 1GP Package Manager UI: Stationary Asset Environmental Source Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new stationary asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Create a Stationary Asset Environmental Source Record](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_create_building_asset.htm&type=5) ## Static Resource Represents a static resource file, often a code library in a ZIP file. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------- | | Only Package Developer Can Edit | Description, File | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: StaticResource; Component Type in 1GP Package Manager UI: Static Resource **Documentation:** _Metadata API Developer Guide:_ [StaticResource](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_staticresource.htm) ## Streaming App Data Connector Represents the connection information specific to Web and Mobile Connectors. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | AppIdentifier, DataConnectorType, StreamingAppDataConnectorType | ### More Information **Feature Name:** Metadata Name: StreamingAppDataConnector **Use Case** The StreamingAppDataConnector is included in a package when you add a data stream (DataStreamDefinition). You need this component if you want to package a web or mobile data stream. **Post Install Steps** The package doesn't contain any connection information. The package subscriber must create the connection in their subscriber org and then select that connection when they deploy the data kit. **Documentation:** _Data Cloud Reference Guide_: [Capture Web Interactions](https://developer.salesforce.com/docs/atlas.en-us.c360a_api.meta/c360a_api/c360a_api_salesforce_interactions_web_sdk.htm); _Data Cloud Reference Guide_: [Integrate your Mobile Applications](https://developer.salesforce.com/docs/atlas.en-us.c360a_api.meta/c360a_api/c360a_api_engagement_mobile_sdk.htm) ## Sustainability UOM Represents information about the additional unit of measure values defined by a customer. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SustainabilityUom; Component Type in 1GP Package Manager UI: Sustainability Unit of Measure **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create Custom Units of Measure](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_create_custom_unitsofmeasure.htm&type=5) ## Sustainability UOM Conversion Represents information about the unit of measure conversion for the additional fuel types defined by a customer. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: SustnUomConversion; Component Type in 1GP Package Manager UI: Sustainability Unit of Measure Conversion **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Create a Unit of Measure Conversion for a Custom Fuel Type](https://help.salesforce.com/s/articleView?id=ind.netzero_admin_create_unitofmeasure_conversion_for_custom_fuel_type.htm&type=5) ## Timeline Object Definition Represents the container that stores the details of a timeline configuration. You can use this resource with Salesforce objects to see their records' related events in a linear time-sorted view. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------- | | Only Package Developer Can Edit | Label, FullName, Definition, IsActive | | Both Package Developer and Subscriber Can Edit | Label, FullName, Definition, IsActive | | Neither Package Developer or Subscriber Can Edit | BaseObject | ### More Information **Feature Name:** Metadata Name: TimelineObjectDefinition; Component Type in 1GP Package Manager UI: Timeline Object Definition **Use Case:** Provides out-of-the-box Timeline object definitions. **License Requirements** Industries Health Cloud or any other License that has Timeline Permission enabled in them. **Legacy Component:** There’s a legacy Timeline component in the Health Cloud Package which is being deprecated in favor of this component. **Documentation:** _Health Cloud Developer Guide_: [TimelineObjectDefinition](https://developer.salesforce.com/docs/atlas.en-us.health_cloud_object_reference.meta/health_cloud_object_reference/meta_timelineobjectdefinition.htm) ## Timesheet Template Represents a template for creating time sheets in Field Service. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP packages only. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### More Information **Feature Name:** Metadata Name: TimesheetTemplate ## Transaction Processing Type Represents the processing constraint settings for a transaction processing request. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | All attributes | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: TransactionProcessingType; Component Type in 1GP Package Manager UI: Transaction Processing Type **Consideration When Uninstalling** TransactionProcessingType records associated with the package are deleted from the org upon uninstallation. If sales transactions, such as quotes or orders, reference these records, recreate them with the same DeveloperName. Otherwise, those sales transaction records become corrupt. **Documentation:** [TransactionProcessingType](https://developer.salesforce.com/docs/atlas.en-us.revenue_lifecycle_management_dev_guide.meta/revenue_lifecycle_management_dev_guide/tooling_api_objects_transactionprocessingtype.htm) ## Translation Add translations to your managed packages. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: Translation **Relationship to Other Components** When you add this component to a first-generation managed package, the [Custom Object Translation](#custom-object-translation) component is automatically added to your package. component is automatically added to your package. For details on how subscribers can override translations after installing a package, see [Override Translations in Second-Generation Managed Packages and Unlocked Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/entering_translated_terms_in_packages.htm) in the Salesforce DX Developer Guide. ### Considerations When Packaging (Beta) Enable Language Extension Packages in Dev Hub to create language extension packages that contain translations of components in other packages. **note:** This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms. Language extension packages can only contain translations: Translations and CustomObjectTranslations. If a base package includes components that can’t be translated, those components aren’t included when you create a language extension package. To remove translations delivered by a package extension, uninstall the base package and all related extensions, then reinstall the base package and any other desired extensions. Otherwise, translations delivered by the extension remain until you uninstall all packages with that namespace. ## UI Bundle Represents the UI of a Multi-Framework app that's built with a supported frontend framework, such as React or Angular, and runs on the Salesforce platform. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | Yes | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### Considerations When Packaging - Managed and unlocked packages are supported for internal, employee-facing (B2E) apps only. External-facing (B2B and B2C) apps are unsupported. - Package UIBundle with its related CustomApplication metadata. Combined with the assigned permission set or profile, CustomApplication controls the app visibility in the App Launcher. - You can include the app's access permission set in the package so that subscriber admins can grant users access after install. A Multi-Framework app requires both app visibility and the API Enabled user permission. - Before you submit a managed package to AppExchange for a security review, enable sourcemap emission in your build and run the Salesforce Code Analyzer with the `uibundle` rule selector. Unlocked packages don't go through Security Review and don't require these steps. See the _Salesforce Multi-Framework Developer Guide_ for more information. ### More Information **Metadata Name:** UIBundle **Use Case:** Distribute internal, employee-facing (B2E) Multi-Framework apps created with React or Angular as a native Salesforce app. For example, you can package a React field-service console once and install it across many client orgs. **Post Install Steps:** After installing the package, assign the app's ` Access` permission set (or a profile that grants app visibility and the API Enabled user permission) to the users who need the app. Until then, the app installs but doesn't appear in the App Launcher. **Documentation:** For guidance on packaging a Multi-Framework app, see [Package Your App for Distribution](https://developer.salesforce.com/docs/platform/multiframework/guide/mfw-packaging.html) in the _Salesforce Multi-Framework Developer Guide_. ## UI Object Relation Config Represents the admin-created configuration of the object relation UI component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------- | | Only Package Developer Can Edit | Reference Name, Developer Name, IsActive | | Both Package Developer and Subscriber Can Edit | IsActive | | Neither Package Developer or Subscriber Can Edit | ContextObject | ### More Information **Feature Name:** Metadata Name: UIObjectRelationConfig; Component Type in 1GP Package Manager UI: UI Object Relation Configuration **Use Case:** Provides out-of-the-box relationship card configuration in Health Cloud. **License Requirements:** Industries Health Cloud, Industries Insurance, or Industries Automotive licenses **Documentation:** _Salesforce Help_: [Set Up Provider Relationship Cards to Show Practitioner Information](https://help.salesforce.com/s/articleView?id=ind.admin_provider_cards.htm&type=5) ## User Access Policy Represents a user access policy. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | To confirm whether this component is available in managed 1GP, managed 2GP, or both package types, see [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html). **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Only Package Developer Can Edit | Description, Name, Label, User Criteria Filters, Actions | | Both Package Developer and Subscriber Can Edit | Order (only subscriber editable), Status (only subscriber editable), Trigger Type (only subscriber editable) | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: UserAccessPolicy; Component Type in 1GP Package Manager UI: User Access Policy **Usage Limits** User access policies have their status set to Design when installed and can be activated by the subscriber. Subscribers can have up to 200 active policies at one time. **Post Install Steps:** The subscriber can activate user access policies so that they run automatically when a user record matching the policy’s user criteria is created, updated, or both. **Documentation:** _Metadata API Developer Guide:_ [UserAccessPolicy](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_useraccesspolicy.htm); _Salesforce Help:_ [User Access Policies](https://help.salesforce.com/s/articleView?id=platform.perm_user_access_policies.htm&type=5) ## Validation Rule Represents a validation rule, which is used to verify that the data a user enters in a record is valid and can be saved. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------------- | | Only Package Developer Can Edit | Description, Error Condition Formula, Error Location, Error Message | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Rule Name | ### More Information **Feature Name:** Metadata Name: ValidationRule; Component Type in 1GP Package Manager UI: Validation Rule **Considerations When Packaging:** For custom objects that are packaged, any associated validation rules are implicitly packaged as well. **Documentation:** _Metadata API Developer Guide:_ [ValidationRule](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_validationformulas.htm) ## Vehicle Asset Emissions Source Record Type Configuration Represents the setup object that contains the mapping between the Vehicle Asset Emissions Source record type and internal enums. You can primarily use this object for calculations across different record types. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------- | | Only Package Developer Can Edit | All attributes | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: VehicleAssetEmssnSrcCnfg; Component Type in 1GP Package Manager UI: Vehicle Asset Emissions Source Record Type Configuration **Use Case:** You can use this component to build on top of the current Net Zero Cloud data model and carbon accounting capability to create new vehicle asset types for end users. **License Requirements** - Net Zero Cloud Growth license or Net Zero Cloud Starter license - Net Zero Cloud Manager permissions set **Post Install Steps** Enable these org settings: - Net Zero Cloud - Manage Carbon Accounting **Documentation** - _Salesforce Help:_ [Set Up Record Types for Net Zero Cloud](https://help.salesforce.com/s/articleView?id=ind.netzero_setup_record_types.htm&type=5) - _Salesforce Help:_ [Create a Vehicle Asset Emissions Source Record](https://help.salesforce.com/s/articleView?id=ind.netzero_manager_create_vehicle_asset.htm&type=5) ## View Definition (Beta) Represents a view definition on a Slack app. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | TargetType, Content, Description | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | None | ### More Information **Feature Name:** Metadata Name: ViewDefinition; Component Type in 1GP Package Manager UI: View Definition **Use Case:** Represents a view within a Slack application **License Requirements:** Connect to Slack Permission **Relationship to Other Components:** View definitions are referenced by Slack apps. **Documentation:** [Apex SDK for Slack Developer Guide](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/overview) ## Virtual Visit Config Represents an external video provider configuration, which relays events from Salesforce to the provider. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Only Package Developer Can Edit | ComprehendServiceType, ExperienceCloudSiteUrl, ExternalRoleIdentifier, Label, MessagingRegion, NamedCredential, StorageBucketName, UsageType, VideoCallApptTypeValue, VideoControlRegion, VisitRegion | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: VirtualVisitConfig **Documentation:** _Salesforce Help_: [Virtual Care](https://help.salesforce.com/s/articleView?id=ind.admin_virtual_care.htm&type=5) ## Visualforce Component Represents a Visualforce component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | Yes | If a developer removes a public Visualforce component from a new version of your 1GP managed package, the component is removed from the subscriber’s org upon upgrade. If the Visualforce component is global, it remains in the subscriber org until the administrator deletes it. For 2GP packages, Visualforce components are hard deleted, and only components that aren’t marked as global can be removed from a package. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexComponent **Documentation:** [Visualforce Components](https://help.salesforce.com/s/articleView?id=platform.pages_custom_components.htm&type=5) ## Visualforce Page Represents a Visualforce page. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in 1GP and 2GP packages. | | Component Has IP Protection | No | If a developer removes a public Visualforce component from a new version of your package, the component is removed from the subscriber’s org upon upgrade. If the Visualforce component is global, it remains in the subscriber org until the administrator deletes it. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | API Version, Description, Label, Markup | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: ApexPage; Component Type in 1GP Package Manager UI: Visualforce Page ## Wave Analytic Asset Collection A collection of CRM Analytics assets. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Folder, Items, Label | | Both Package Developer and Subscriber Can Edit | Color, Description, Shares | | Neither Package Developer or Subscriber Can Edit | Collection Type | ### More Information **Feature Name:** Metadata Name: WaveAnalyticAssetCollection; Component Type in 1GP Package Manager UI: Wave Analytic Asset Collection **Use Case:** Represents a collection of CRM Analytics assets. **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics **Documentation:** _Salesforce Help_: [Curate and Share Insights with Collections](https://help.salesforce.com/s/articleView?id=analytics.bi_home_collections&type=5) ## Wave Application A CRM Analytics application. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Asset Icon, Description, Shares | | Neither Package Developer or Subscriber Can Edit | Folder, Template Origin, Template Version | ### More Information **Feature Name:** Metadata Name: WaveApplication **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Component A CRM Analytics dashboard component. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveComponent **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dataflow A CRM Analytics data prep dataflow. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Dataflow Type | ### More Information **Feature Name:** Metadata Name: WaveDataflow **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dashboard A CRM Analytics dashboard. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Date Version, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveDashboard **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Dataset A CRM Analytics dataset. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description | | Neither Package Developer or Subscriber Can Edit | Application, Template Asset Source Name, Type | ### More Information **Feature Name:** Metadata Name: WaveDataset **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Lens A CRM Analytics lens. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description, Visualization Type | | Neither Package Developer or Subscriber Can Edit | Application, Datasets, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: WaveLens **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Recipe A CRM Analytics data prep recipe. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Description, Security Predicate, Target Dataset Alias | | Neither Package Developer or Subscriber Can Edit | Application, Dataflow, Format, Template Asset Source Name | ### More Information **Feature Name:** Metadata Name: Wave Recipe **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Template Bundle A CRM Analytics template bundle. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Asset Icon, Description | | Neither Package Developer or Subscriber Can Edit | Asset Version, Template Type | ### More Information **Feature Name:** Metadata Name: WaveTemplateBundle **Considerations When Packaging** Analytics assets are installed in subscriber orgs via Analytics Templates using the WaveTemplateBundle. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Wave Xmd The extended metadata for CRM Analytics dataset fields and their formatting for dashboards and lenses. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | Yes | | Package Developer Can Remove Component From Package | Yes | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------------------------- | | Only Package Developer Can Edit | Label | | Both Package Developer and Subscriber Can Edit | Dates, Dimensions, Measures, Organizations, Wave Visualization | | Neither Package Developer or Subscriber Can Edit | Application, Dataset, Dataset Connector, Dataset Fully Qualified Name, Origin, Type | ### More Information **Feature Name:** Metadata Name: WaveXmd **Considerations When Packaging** Analytics assets should be installed in subscriber orgs via Analytics Templates. The template framework supports the data sync and orchestration needed for visualization assets, along with customizations for each org. For more information, see the [Analytics Templates Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.bi_dev_guide_wave_templates.meta/bi_dev_guide_wave_templates/bi_templatesdev_intro_wave_templates.htm). . **License Requirements:** Manage CRM Analytics ## Web Store Template Represents a configuration for creating commerce stores. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | No | | Component Has IP Protection | No | ### More Information **Feature Name:** Metadata Name: WebStoreTemplate **Documentation:** _Metadata API Developer Guide:_ [WebStoreTemplate](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_webstoretemplate.htm) ## Workflow Alert WorkflowAlert represents an email alert associated with a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | ---------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------------------------- | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Additional Emails, Email Template, From Email Address, Recipients | | Neither Package Developer or Subscriber Can Edit | Description | ### More Information **Feature Name:** Metadata Name: Workflow - Salesforce prevents you from uploading workflow alerts that have a public group, partner user, or role recipient. Change the recipient to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - You can package workflow rules and associated workflow actions, such as email alerts and field updates. However, any time-based triggers aren’t included in the package. Notify your installers to set up any time-based triggers that are essential to your app. - References to a specific user in workflow actions, such as the email recipient of a workflow email alert, are replaced by the user installing the package. Sometimes workflow actions referencing roles, public groups, account team, opportunity team, or case team roles aren’t uploaded. - References to an org-wide address, such as the From email address of a workflow email alert, are reset to Current User during installation. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Field Update WorkflowFieldUpdate represents a workflow field update. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | --------------------------------------- | | Only Package Developer Can Edit | Description, Field Value, Formula Value | | Both Package Developer and Subscriber Can Edit | Lookup | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Field Update - Salesforce prevents you from uploading workflow field updates that change an Owner field to a queue. Change the updated field value to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. - You can package workflow rules and associated workflow actions, such as email alerts and field updates. However, any time-based triggers aren’t included in the package. Notify your installers to set up any time-based triggers that are essential to your app. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Knowledge Publish WorkflowKnowledgePublish represents Salesforce Knowledge article publishing actions and information. ### Component Manageability Rules Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------- | | Packageable In: | First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes, if protected | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | -------------------------------- | | Only Package Developer Can Edit | Action, Description, Unique Name | | Both Package Developer and Subscriber Can Edit | None | | Neither Package Developer or Subscriber Can Edit | Object Name | ### More Information **Feature Name:** Metadata Name: WorkflowKnowledgePublish; Component Type in 1GP Package Manager UI: Knowledge Action **Considerations When Packaging** WorkflowKnowledgePublish can only be installed in Salesforce Classic orgs with Knowledge enabled. WorkflowKnowledgePublish includes the article type `*__kav`, which is not supported by Lightning Knowledge. If you try to install WorkflowKnowledgePublish into an org with Lightning Knowledge enabled, this message is displayed: When Lightning Knowledge is enabled, you can’t add an article type. **License Requirements:** Salesforce Classic orgs with Knowledge enabled can use this package. **Documentation:** _Salesforce Help_: [Create Workflow Actions for Knowledge](https://help.salesforce.com/s/articleView?id=service.knowledge_actions_create.htm&type=5) ## Workflow Outbound Message WorkflowOutboundMessage represents an outbound message associated with a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ---------------------------------------------------------- | | Only Package Developer Can Edit | Description, Endpoint URL, Fields to Send, Send Session ID | | Both Package Developer and Subscriber Can Edit | User to Send As | | Neither Package Developer or Subscriber Can Edit | Name | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Outbound Message Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. ## Workflow Rule This metadata type represents a workflow rule. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | --------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. | | Component Has IP Protection | No | **note:** When a package developer removes this component from a package, the component remains in a subscriber’s org after they install the upgraded package. The admin of the subscriber’s org can then delete the component, if desired. Removing components from managed 1GP or 2GP packages requires approval from Salesforce. To request access to the component removal feature, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/partnerSupport). For more details on 2GP component removal, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ----------------------------------------------- | | Only Package Developer Can Edit | Description, Evaluation Criteria, Rule Criteria | | Both Package Developer and Subscriber Can Edit | Active | | Neither Package Developer or Subscriber Can Edit | Rule Name | ### More Information - Feature Name: Metadata Name: Workflow Component Type in 1GP Package Manager UI: Workflow Rule * Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. * Developers can associate or disassociate workflow actions with a workflow rule at any time. These changes, including disassociation, are reflected in the subscriber’s org upon install. In managed packages, a subscriber can’t disassociate workflow actions from a workflow rule if it was associated by the developer. * On install, all workflow rules newly created in the installed or upgraded package, have the same activation status as in the uploaded package. * You can't package workflow rules with time triggers. ## Workflow Task This metadata type references an assigned workflow task. ### Component Manageability Rules **note:** When creating a new package or package version, use the Flow component instead of Workflow components. If your managed package already includes Workflow components, come up with a plan to migrate to use Flow. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and promoted to the released state. | Rule | Value | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Packageable In: | Second-Generation Managed Packages (2GP), First-Generation Managed Packages (1GP) | | Component Is Updated During Package Upgrade | Yes | | Subscriber Can Delete Component From Org | No | | Package Developer Can Remove Component From Package | Yes. Supported in both 1GP and 2GP packages. Both protected and non-protected components can be removed. | | Component Has IP Protection | No | ### Editable Properties Certain properties on metadata components are editable after the managed package is installed. | Category | Properties | | ------------------------------------------------ | ------------------------------------------------------------ | | Only Package Developer Can Edit | None | | Both Package Developer and Subscriber Can Edit | Assign To, Comments, Due Date, Priority, Record Type, Status | | Neither Package Developer or Subscriber Can Edit | Subject | ### More Information **Feature Name:** Metadata Name: Workflow; Component Type in 1GP Package Manager UI: Workflow Task - Salesforce prevents you from uploading workflow tasks that are assigned to a role. Change the Assigned To field to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. - This component can be marked as protected. For more details, see [Protected Components](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) in the _First-Generation Managed Packaging Developer Guide_. # Components Available in Unmanaged Packages Not all components can be packaged for distribution. ## Packaged Explicitly or Implicitly Components can be added either explicitly or implicitly. Explicit components must be included directly in the package, while implicit components are automatically added. For example, if you create a custom field on a standard object, you must explicitly add the custom field to your package. However, if you create a custom object and add a custom field to it, the field is implicitly added to the package when you add the custom object. - **Explicitly**: The component must be manually added to the package. - **Implicitly**: The component is automatically added to the package when another dependent component, usually a custom object, is added. ## Automatic Renaming Salesforce can resolve naming conflicts automatically on install. - **No**: If a naming conflict occurs the install is blocked. - **Yes**: If a naming conflict occurs Salesforce can optionally change the name of the component being installed. | Component | Packaged Explicitly or Implicitly | Automatic Renaming | | ----------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------ | | **Apex Class** | Explicitly | No | | **Apex Sharing Reason** | Implicitly. On an extension: Explicitly | No | | **Apex Sharing Recalculation** | Implicitly | No | | **Apex Trigger** | On a standard or extension object: Explicitly. On an object in the package: Implicitly | No | | **Application** | Explicitly | No | | **Custom Button or Link** | On a standard object: Explicitly. On a custom object: Implicitly | No | | **Custom Field** | On a standard object: Explicitly. On a custom object: Implicitly | No | | **Custom Label** | Implicitly | No | | **Custom Object** | Explicitly | No | | **Custom Permission** | Implicitly. With required custom permissions: Explicitly | No | | **Custom Report Type** | Explicitly | No | | **Custom Setting** | Explicitly | No | | **Dashboard** | Explicitly. In a folder: Implicitly | Yes | | **Document:sup[\*]** (10 MB limit) | Explicitly. In a folder: Implicitly | Yes | | **Email Template** (Classic) | Explicitly. In a folder: Implicitly | Yes | | **External Data Source** | Explicitly. Referenced by an external object: Implicitly. Assigned by a permission set: Implicitly | No | | **Flow Definition** | Implicitly | No | | **Folder** | Explicitly | Yes | | **Home Page Component** | Explicitly | No | | **Home Page Layout** | Explicitly | No | | **Inbound Network Connection** | Explicitly | No | | **Letterhead** | Explicitly | Yes | | **Lightning Application** | Explicitly | No | | **Lightning Component** | Explicitly | No | | **Lightning Event** | Explicitly | No | | **Lightning Interface** | Explicitly | No | | **Lightning Page** | Explicitly | No | | **List View** | On a standard object: Explicitly. On a custom object: Implicitly | Yes | | **Named Credential** | Explicitly | No | | **Outbound Network Connection** | Explicitly | No | | **Page Layout** | On a standard object: Explicitly. On a custom object: Implicitly | No | | **Record Type** | On a standard object: Explicitly. On a custom object: Implicitly | No | | **Report** | Explicitly. In a folder: Implicitly | Yes | | **Reporting Snapshot** | Explicitly | Yes | | **S-Control:sup[\*]** (10 MB limit) | Explicitly | No | | **Static Resource** | Explicitly | No | | **Tab** | Explicitly | No | | **Translation** | Explicitly | No | | **Validation Rule** | On a standard object: Explicitly. On a custom object: Implicitly | No | | **Visualforce Component** | Explicitly | No | | **Visualforce Page** | Explicitly | No | | **Workflow Email Alert** | Explicitly | No | | **Workflow Field Update** | Explicitly | No | | **Workflow Outbound Message** | Explicitly | No | | **Workflow Rule** | Explicitly | No | | **Workflow Task** | Explicitly | No | :sup[\*]The combined size of S-Controls and documents must be less than 10 MB. # Configure Default Package Versions for API Calls You can specify the default package versions for enterprise API and partner API calls. | Availability | | ----------------------------------------------------------------------------------------- | | Available in: Salesforce Classic | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer**, Editions | | User Permissions Needed | | | ---------------------------------------------------- | --------------------- | | To configure default package versions for API calls: | Customize Application | A package version is a number that identifies the set of components uploaded in a package. The version number has the format _majorNumber.minorNumber.patchNumber_ (for example, 2.1.3). The major and minor numbers increase to a chosen value during every major release. The _patchNumber_ is generated and updated only for a patch release. Publishers can use package versions to evolve the components in their managed packages gracefully by releasing subsequent package versions without breaking existing customer integrations using the package. Default package versions for API calls provide fallback settings if package versions aren’t provided by an API call. Many API clients don’t include package version information, so the default settings maintain existing behavior for these clients. You can specify the default package versions for enterprise API and partner API calls. The enterprise WSDL is for customers who want to build an integration with their Salesforce organization only. It’s strongly typed, which means that calls operate on objects and fields with specific data types, such as `int` and `string`. The partner WSDL is for customers, partners, and ISVs who want to build an integration that can work across multiple Salesforce organizations, regardless of their custom objects or fields. It is loosely typed, which means that calls operate on name-value pairs of field names and values instead of specific data types. You must associate the enterprise WSDL with specific package versions to maintain existing behavior for clients. There are options for setting the package version bindings for an API call from client applications using either the enterprise or partner WSDL. The package version information for API calls issued from a client application based on the enterprise WSDL is determined by the first match in the following settings. 1. The PackageVersionHeader SOAP header. 2. The SOAP endpoint contains a URL with a format of `_serverName_/services/Soap/c/_api_version/ID_` where _api_version_ is the version of the API, such as 67.0, and _ID_ encodes your package version selections when the enterprise WSDL was generated. 3. The default enterprise package version settings. The partner WSDL is more flexible as it’s used for integration with multiple organizations. If you choose the Not Specified option for a package version when configuring the default partner package versions, the behavior is defined by the latest installed package version. This means that behavior of package components, such as an Apex trigger, could change when a package is upgraded and that change would immediately impact the integration. Subscribers may want to select a specific version for an installed package for all partner API calls from client applications to ensure that subsequent installations of package versions don’t affect their existing integrations. The package version information for partner API calls is determined by the first match in the following settings. 1. The PackageVersionHeader SOAP header. 2. An API call from a Visualforce page uses the package versions set for the Visualforce page. 3. The default partner package version settings. To configure default package versions for API calls: 1. From Setup, enter `API` in the Quick Find box, then select **API**. 2. Click **Configure Enterprise Package Version Settings** or **Configure Partner Package Version Settings**. These links are only available if you have at least one managed package installed in your organization. 3. Select a Package Version for each of your installed managed packages. If you’re unsure which package version to select, you should leave the default selection. 4. Click **Save**. **note:** Installing a new version of a package in your organization doesn’t affect the current default settings. # Configure Permissions for the License Management App Determine who needs access to the License Management App (LMA), and set object permissions. Consider using a permission set to assign user permissions. ## Before You Begin Ensure that you: - Install the LMA. - Connect your packaging org (for 1GP) or your Dev Hub org (for 2GP) to the AgentExchange Partner Console. - Associate your package with the LMA. 1. Set object permissions for the license, package, and package version custom objects. | Custom Object | Object Permissions | | --------------- | ------------------------------------------------------------------------------------------------------------------------ | | License | To view license records, assign READ permissions. To modify license records, assign READ and EDIT permissions. | | Package | To view package records, assign READ permissions. To modify package records, assign READ and EDIT permissions. | | Package Version | To view package version records, assign READ permissions. We recommend leaving all package version records as read-only. | 2. Set field-level security in user profiles or permission sets. | Custom Object | Field-Level Permissions | | --------------- | -------------------------- | | License | Make all fields read-only. | | Package | Make all fields read-only. | | Package Version | Make all fields read-only. | 3. Add related lists to page layouts. | To enable... | Add the Licenses related list to the... | | ----------------------------------------------------------------------- | --------------------------------------- | | License managers to view the licenses associated with a particular lead | Lead page layout | | LMA users to view the licenses associated with a particular account | Account page layout | | LMA users to view the licenses associated with a particular contact | Contact page layout | - **[Assign Permissions to the Subscriber Support Console](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-subscriber-org-permissions.md)** Create a permission set to provide users access to the Subscriber Support Console. # Configure the Environment Hub Enable the Environment Hub in your org, and then configure it to give other users access. If you’re an ISV partner, the Environment Hub is already installed in your Partner Business Org. ## Before You Begin | User Permissions Needed |   | | -------------------------------------------- | ---------------------- | | To set up and configure the Environment Hub: | Manage Environment Hub | ## Steps 1. To open a case to enable the Environment Hub in your org, contact Salesforce Customer Support. If you’re an ISV partner, you can skip this step. 2. Log in to the org where the Environment Hub is enabled. 3. Assign users access to features in the Environment Hub by creating or updating a permission set or profile. Be sure to assign users the Salesforce or Salesforce Platform license. | Permission Set | Profile | Environment Hub Settings | | ------------------ | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | N/A | Custom App Settings | Enabled for Lightning Experience by default. Enable the Environment Hub custom app setting to make it available in the App Menu in Salesforce Classic. | | System Permissions | Administrative Permissions | Enable “Manage Environment Hub” to allow users to:
  • Create orgs for development, testing, and trials.
  • Configure SSO for member orgs.
| | System Permissions | General User Permissions | To allow users to connect existing orgs to the Environment Hub:
  • “Connect Organization to Environment Hub”
  • “View Setup and Configuration”
  • “View Roles and Role Hierarchy” (required when enabling View Setup and Configuration)
| | Object Settings | Standard Object Permissions |

Grant object permissions based on the required level of access for the Environment Hub user.

Hub Members object:
  • ”Tab Settings”—Visible
  • ”Read”—View existing Hub Member records.
  • ”Create”—This permission has no impact on the ability to create Hub Member records because record creation is handled either by connecting an existing org or creating an org from the Environment Hub.
  • ”Edit”—Edit fields on existing Hub Member records.
  • ”Delete”—Disconnect an org from the Environment Hub and delete its corresponding Hub Member record and Service Provider record (if SSO was enabled for the member).
  • ”View All”—Read all Hub Member records, regardless of who created them.
  • ”Modify All”—Read, edit, and delete all Hub Member records, regardless of who created them.
Hub Invitations object:
  • If you enable the “Connect Organization to Environment Hub” permission, enable “Create”, “Read”, “Edit”, and “Delete” for Hub Invitations.
Signup Requests object:
  • If you enable the “Manage Environment Hub” permission, enable “Create” and “Read” for Signup Requests to allow users to create orgs. Optionally, enable “Delete” to allow users to remove orgs from the hub.
| | Service Providers | Service Provider Access |

When configuring the Environment Hub in a new org, this section is empty.

If you enable single sign-on (SSO) in a member org, new entries appear in this section. Entries appear in the format `Service Provider [Organization ID]`, where Organization ID is the ID of the member org. Users who don’t have access to the service provider sometimes see this message when attempting to log in via SSO: `User ‘[UserID]’ does not have access to sp ‘[Service Provider ID]’.`

| | # Connect a Trialforce Template to the AgentExchange Partner Console After you create or update a Trialforce template, connect it to the AgentExchange Partner Console so that it’s available to add to your AgentExchange listing. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing** | **Technologies** | **Trial Templates**. 3. Click **Connect Technology** | **Trial Template**. 4. Click **Connect Org**, and then enter the login credentials for the organization that contains the Trialforce template. ## Next Steps After the org is connected, the related trial templates appear in the Partner Console and you can add them to your listings. # Connect an Org to the Environment Hub You can connect existing Salesforce orgs to the Environment Hub, allowing you to manage all your development, test, and trial environments (except scratch orgs) from one location. When you connect an org to the hub, related orgs are automatically discovered so you don’t have to manually connect them. ## Before You Begin | User Permissions Needed |   | | --------------------------------------------------------------- | --------------------------------------- | | To connect or disconnect an org to or from the Environment Hub: | Connect Organization to Environment Hub | The following types of related orgs are automatically discovered. - For any organization, all sandbox orgs created from it - For a managed 1GP packaging org, all its related patch orgs - For a Trialforce Management Org, all Trialforce Source Orgs created from it - For an org with the License Management App (LMA) installed, any release org with a managed package registered in the LMA **note:** You can't connect a sandbox org to the Environment Hub directly. If you want to connect a sandbox, first connect the org used to create the sandbox to the Environment Hub. Then, refresh the sandbox org. The refresh automatically adds it as a hub member. ## Steps 1. From the App Launcher, select **Environment Hub**, and then select **Connect Org**. 2. Enter the admin username for the org that you want to connect and, optionally, a short description. If your hub has many members, a description makes it easier to find the org later. 3. By default, single sign-on (SSO) is enabled for the org you connected. To disable SSO, deselect **Auto-enable SSO for this org**. 4. Select **Connect Org** again. 5. In the pop-up window, enter the org’s admin username and password. If you don’t see the pop-up, temporarily disable your browser’s ad blocking software and try again. 6. Select **Log In**, and then select **Allow**. This process creates a connected app to allow connections to the org. If you can't log in and select Allow, check if the Environment Hub org has a connected app called "Environment org". If you don't see this connected app, contact Salesforce Support. ## Next Steps To disconnect an org, locate the record for the org in the Environments Hub tab, and select **Remove** from the dropdown menu on the far right. Orgs removed from the Environment Hub aren’t deleted, so you can still access the org after you remove it. # Connect to Your License Management App Data Create an SFDC_Local connection to your License Management App (LMA) data. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Connect**. 3. Click **Connect to Data**. 4. Click **SFDC_LOCAL**. 5. Click **Account**. 6. Click **Continue**. 7. Select all fields. 8. Click **Continue**. 9. Click **Save**. 10. Repeat steps 2 through 8 to connect to these objects. - **Lead** - **sfLma**License**c** - **sfLma**Package**c** - **sfLma**Package_Version**c** 11. Next to Account, click the down arrow. 12. Click **Run Data Sync**. 13. Repeat step 11 for these objects in your Connect window. - **Lead** - **sfLma**License**c** - **sfLma**Package**c** - **sfLma**Package_Version**c** # Connect Your Orgs, Solutions, and Trials to the AgentExchange Partner Console Before you create an AgentExchange listing, connect the Salesforce orgs that you need to run your AgentExchange business to the Partner Console. Then connect the solutions and trials that you plan to list. # Connect Your Partner Business Org to the AgentExchange Partner Console A Partner Business Org (PBO) is an org preinstalled with the tools that you use to run your AgentExchange business. Connect your PBO to the Partner Console so that you’re ready to set up licensing for your managed packages and create listings for your solutions. For most ISV partners, the PBO is the org where the License Management App (LMA), Channel Order App (COA), and Environment Hub are installed. If those tools are installed in an org other than your PBO, connect that org instead. 1. Go to the Partner Console See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Technologies** | **Solutions**. 3. Click **Connect Technology**. 4. Click **Connect Org**. 5. Enter the login credentials for your PBO or for the org that contains your LMA, COA, and Environment Hub. 6. Click **Log In**. After a successful login, you can complete business tasks in the Partner Console, such as set default license settings for your managed packages. **See Also** - [Set Default Licensing for Your Managed Package](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-publish-manage.md) # Connect Your Solution to the AgentExchange Partner Console To add a solution to an AgentExchange listing, first connect the solution to the Partner Console. When you connect a solution, the information you're prompted to enter depends on the type of solution. To connect a Salesforce managed package, provide the login credentials for the Dev Hub or packaging org that contains the package. To connect an API solution, provide the API name. For other solution types, such as Tableau Accelerators, provide the solution name and URL. 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Technologies** | **Solutions** 3. Click **Connect Technology**. 4. If you want to connect a Salesforce managed package, click **Packaged Solution** | **Salesforce Platform Package**. 1. Click **Connect Org**. 2. Enter the login credentials for the Dev Hub or packaging org that contains your managed package. 3. Click **Connect Org**. 5. If you want to connect an API solution, click **Packaged Solution** | **API**. 1. Select an API type. 2. Enter the API name. 3. Click **Connect Solution**. 6. If you want to connect a Quip app, B2C Commerce cartridge, or Tableau Accelerator, click **Packaged Solution**. 1. Select the packaged-solution type. 2. Enter the solution name and URL. 3. Click **Connect Solution**. The solution is added to the list on the Solutions tab in the Partner Console. When you create a listing, you can link the solution to the listing. # Connect Your Trial Template to the AgentExchange Partner Console If you plan to offer trials of your solution on your AgentExchange listing, connect the Salesforce org that contains your Trialforce template to the Partner Console. After the org is connected, the trial templates in that org are available in the Partner Console, and you can add them to your listings. To connect the Salesforce Org that contains your Trialforce template, follow the instructions in [Connect a Trialforce Template to the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/package-associate-apo.md). **See Also** - [Deliver Trials on AgentExchange with Trialforce](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-setup-overview.md) # Connected Apps A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions. For example, when you log in to your Salesforce mobile app and see your data from your Salesforce org, you’re using a connected app. **note:** Connected apps creation is restricted as of Spring ‘26. You can continue to use existing connected apps during and after Spring ‘26. However, we recommend using [external client apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm) instead. If you must continue creating connected apps, contact Salesforce Support. See [New connected apps can no longer be created in Spring ‘26](https://help.salesforce.com/s/articleView?id=005228017&type=1) for more details. By capturing metadata about an external app, a connected app tells Salesforce which authentication protocol—SAML, OAuth, and OpenID Connect—the external app uses, and where the external app runs. Salesforce can then grant the external app access to its data, and attach policies that define access restrictions, such as when the app’s access expires. Salesforce can also audit connected app usage. To learn more about how to use, configure, and manage connected apps, see the following topics in _Salesforce Help_: - [Connected App Use Cases](https://help.salesforce.com/articleView?id=connected_app_about.htm) - [Create a Connected App](https://help.salesforce.com/articleView?id=connected_app_create.htm) - [Edit a Connected App](https://help.salesforce.com/articleView?id=connected_app_edit_parent.htm) - [Manage Access to a Connected App](https://help.salesforce.com/articleView?id=connected_app_manage.htm) ## More Resources Here are some additional resources to help you navigate connected apps: - _Salesforce Help_: [Connected Apps](https://help.salesforce.com/articleView?id=connected_app_overview.htm) - _Salesforce Help_: [Authorize Apps with OAuth](https://help.salesforce.com/articleView?id=remoteaccess_authenticate.htm) - _Trailhead_: [Build Integrations Using Connected Apps](https://trailhead.salesforce.com/en/content/learn/trails/build-integrations-using-connected-apps) # Considerations for Custom Interactions Easily create and log custom interactions on your managed package using Apex. As subscribers interact with your package and your Apex code is executed, the custom interactions that you defined are logged. Retrieve your custom interactions in your package's AgentExchange App Analytics usage logs and usage summaries. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | As an ISV partner, the complex features that you develop in your managed packages could involve multiple actions on different objects, callouts to Apex functions, and much more. It can be difficult to interpret how your subscribers interacted with specific packaged components via your downloaded App Analytics package usage logs and summaries. To provide you with more clarity about your subscribers’ events in custom ways and at different granularity levels, create custom interactions in your managed packages using Apex. With Apex custom interactions, you can discover: - Which app feature a user interacted with - How users flowed through a specific user journey - Which UI components a user interacted with Keep these considerations in mind: - A custom interaction can appear for a given user request up to 50 times. This limit avoids flooding the logs due to large loops. - We recommend that you don’t call `IsvPartners.AppAnalytics.logCustomInteraction` from inside a loop. - If the `IsvPartners.AppAnalytics.logCustomInteraction` method is called from a running Apex test, no AgentExchange App Analytics package usage log or package usage summary data is produced. - **[Log Custom Interactions](#log-custom-interactions)** Create and log custom interactions with your managed package using Apex. ## Log Custom Interactions Create and log custom interactions with your managed package using Apex. 1. In your packaged Apex code, include Apex enums that are associated with the events that you want to log as custom interactions. 2. In your Apex code, invoke `IsvPartners.AppAnalytics.logCustomInteraction`, using the enums that you created. 3. Test your code by running it in your development environment and checking your debug logs to be certain that the custom interactions you created are being logged. Ensure that your debug log levels for `Apex Code` are set to `FINE`. 4. After you’re finished with your implementation, publish a new version of your managed package. 5. After subscribers install your package, retrieve your package usage logs and package usage summaries. Filter your package usage log data on `custom_entity_type` by CustomInteractionLabel, and on `log_record_type` by CustomInteraction. Or filter your package usage summary data on `custom_entity_type` by CustomInteractionLabel. 6. Analyze your custom interaction data. ## Example Let’s suppose you have a Lightning Web Component (LWC). Your LWC provides a list of related contacts for each Account record, uses a table layout, and is wired to an Apex class. You add a new card layout to your LWC. To track how well users are adopting this new layout, you log an interaction when a user switches between layouts. ![An example Lightning Web Component in table format showing these columns: Name, Title, Email, and Phone, plus Table and Card buttons](https://developer.salesforce.com/media/pkg2_dev/app_analytics_custom_interactions_example.png) In your code, include Apex enums and invoke `IsvPartners.AppAnalytics.logCustomInteraction`. Your LWC HTML code: ```nolang ``` Your LWC JavaScript code: ```nolang import { LightningElement, wire, api } from "lwc"; import { getRelatedListRecords } from "lightning/uiRelatedListApi"; import logInteraction from "@salesforce/apex/LogContactListInteraction.log"; export default class ContactList extends LightningElement { @api recordId; error; records; displayTable = true; displayCard = false; columns = [ { label: "Name", fieldName: "name" }, { label: "Title", fieldName: "title" }, { label: "Email", fieldName: "email", type: "email" }, { label: "Phone", fieldName: "phone", type: "phone" } ]; @wire(getRelatedListRecords, { parentRecordId: "$recordId", relatedListId: "Contacts", fields: [ "Contact.Name", "Contact.Id", "Contact.Phone", "Contact.Email", "Contact.Title" ], sortBy: ["Contact.Name"] }) contactList({ error, data }) { if (data) { this.records = data.records.map((item) => { return { name: item.fields.Name.value, id: item.fields.Id.value, title: item.fields.Title.value, email: item.fields.Email.value, phone: item.fields.Phone.value }; }); this.error = undefined; } else if (error) { this.error = error; this.records = undefined; } } handleClick(event) { if (event.target.label.toLowerCase() === "table") { this.displayTable = true; this.displayCard = false; logInteraction({ type: "table" }); } else if (event.target.label.toLowerCase() === "card") { this.displayTable = false; this.displayCard = true; logInteraction({ type: "card" }); } } get cardVariant() { return this.displayCard === true ? "brand" : ""; } get tableVariant() { return this.displayTable === true ? "brand" : ""; } } ``` Your Apex class: ```nolang public class LogContactListInteraction { public Enum ContactListLayouts { TABLE, CARD } @AuraEnabled public static void log(String type) { try { IsvPartners.AppAnalytics.logCustomInteraction(getInteractionLabel(type)); } catch (Exception e) { throw new AuraHandledException(e.getMessage()); } } private static ContactListLayouts getInteractionLabel(String type) { if (type.toLowerCase() == 'table') { return ContactListLayouts.TABLE; } else if (type.toLowerCase() == 'card') { return ContactListLayouts.CARD; } return null; } } ``` Next, you test your code. With your Apex code debug log level set to `FINE`, confirm that the custom interactions are logged by finding events in your debug logs called `APP_ANALYTICS_FINE`, `APP_ANALYTICS_WARN`, or `APP_ANALYTICS_ERROR`. ```nolang APP_ANALYTICS_FINE [External]IsvPartners.AppAnalytics.logCustomInteraction was called, but not from an installed managed package. This means that the code is ready to be packaged. ``` # Considerations for Feature Management Keep these considerations in mind when working with feature parameters. - After a feature parameter is included in a promoted and released package version, we recommend that you only edit the value field located in LMO-to-subscriber junction objects. Modifying or deleting other fields or records related to feature parameters, including the data flow direction, may cause the FMA to stop operating correctly. - Don’t use the LMO to create or delete feature parameters. - When you update LMO-to-subscriber values in your LMO, the values in your subscribers’ orgs are updated asynchronously. This process can take several minutes. - When you publish a push upgrade to your managed package, feature parameters in your LMO and your subscribers’ orgs are updated asynchronously. Creating and updating the junction object records can take several minutes. - When the Apex code in your package updates subscriber-to-LMO values in your subscriber’s org, the changes can take up to 24 hours to reach your LMO. # Considerations for Package Migrations Review these limits and considerations for converting and migrating packages. 1. Packages converted before June 15, 2025 can’t be promoted or migrated. Instead, run the convert command on your latest package version, and move forward with that package version. 2. The daily package conversion limit is the same as your Dev Hub org’s scratch org allocation. See [Scratch Org Allocations for Salesforce Partners](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/isv_partner_scratch_org_allocations.htm) for details. 3. The convert command may fail on your first attempt to convert a package. If this happens, retry again in a few minutes. This issue is most likely to occur if you create a new package for testing purposes, and immediately try to convert that package version. 4. The package conversion process performs limited validation when creating the managed 2GP package version. 1. In some instances the limited validation could mask issues that would otherwise result in package conversion failure. 2. You can expect to see cryptic error messages in certain scenarios. Please share those error messages with us so we can improve them. 5. During migration, the managed 1GP package version installed in the target org has the same version number as the managed 2GP migration package version. 6. Only package versions created using API version 57 (Spring ’23) or above, can be converted. To promote a package version, it must have been created using API version 64 (Summer ’25) or later. 7. Large packages containing 20,000+ metadata files aren’t supported at this time. 8. Packages containing Data Cloud metadata can’t be converted. 9. After you convert a managed 1GP package to 2GP, you can’t transfer the converted package to another Dev Hub org. # Considerations for Promoting Packages with Dependencies If your company is developing a package that has a package dependency, ask yourself these questions before promoting (releasing) a new package version. Are you: - Developing the base and extension package in parallel? - Specifying skip validation when creating new package versions? - Using the keywords LATEST or RELEASED when specifying the package dependency? If you answered no to all these questions, your package doesn't have any tricky dependency scenarios and you can promote it when it's ready. If you answered yes to any of these questions, keep reading. ## Specifying Skip Validation When you create a package version and specify [skip validation](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver.htm), the version is created without validating dependencies, package ancestors, or metadata. If you develop your base package using skip validation, test your extension package using either a stable and previously promoted version of the base package, or a non-skip validated base package version. Most importantly, if you’re developing a version of your base package and extension package in parallel, ensure that you: - First promote the base package version. - Then specify the promoted package version in the dependency section of your extension package using the keyword RELEASED. - Finally, create the extension package version. After testing the extension package version, you then promote it. This process ensures that the extension package version that you promote to the released state has as its dependency the promoted base package version. ## Using the Keyword LATEST or RELEASED A keyword is a variable that you can use to specify a package version number. The keyword LATEST maps to the most recently created package version, which might not be the same as the promoted and released package version. The keyword RELEASED maps to the promoted and released package version. For example: If you create versions 1.0.0.1, 1.0.0.2, and 1.0.0.3, and promote version 1.0.0.2, then 1.0.0.RELEASED = 1.0.0.2, but 1.0.0.LATEST = 1.0.0.3. ## Example Your company created a base package called PkgBase, and an extension package called PkgExtn. PkgBase is under active development, and the development team is creating versions that specify `--skip-validation`. PkgExtn version 2.3 is under active development and references its dependency on PkgBase by using the following definition in the `sfdx-project.json`. ```nolang { "path": "pkg-extension", "default": false, "package": "PkgExtn", "versionName": "v 2.3", "versionDescription": "Winter 2025", "versionNumber": "2.3.0.NEXT", "dependencies": [ { "package": "PkgBase", "versionNumber": "1.1.0.LATEST" }, ``` Before promoting version 2.3 of PkgExtn, you must test it using the promoted version 1.1.0 of PkgBase. Update the PkgExtn dependency section of your `sfdx-project.json` and change the dependency from 1.1.0.LATEST to 1.1.0.RELEASED. If the tests succeed, then create a new version of PkgExtn and ensure it works as expected with the promoted base package version. **See Also** - [Create and Update Versions of a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver.htm) - [Get Ready to Promote and Release a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_get_ready_promote.htm) - [Create Dependencies Between Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_dependencies.htm) - [Second-Generation Managed Packaging Keywords](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_keywords.htm) # Considerations for the Environment Hub in Lightning Experience Be aware of these considerations when creating and managing orgs in the Environment Hub. |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions| - List View Limitations - : You can’t filter hub members by org expiration date when creating or updating list views in Lightning Experience. If you have an existing list view that includes org expiration date in its filter criteria, that list view won’t work in Lightning Experience. To filter hub members by org expiration date, switch to Salesforce Classic and then use the list view. # Considerations for Trialforce Templates Learn the considerations for creating and using Trialforce templates, which are approximate snapshots of your Trialforce Source Organization (TSO). |Required Editions| |-----------------| |Available in: Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Developer**, **Professional**, and **Enterprise** Edition| - You can create Trialforce templates only if the TSO is a trial org. - You can create a template only if your TSO is less than or equal to 1 GB. - Before you create a template, make sure that the TSO admin has a license for the solution that’s installed in the TSO. - You can create up to 10 Trialforce templates per TSO. In Setup for Trialforce, you [create a Trialforce template](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-creating-template.md) by clicking the **New Trialforce Template** button. If the button is unavailable, delete templates before creating new ones. If you require more than 10 templates, contact Salesforce Partner Support. - For security reasons, Personally Identifiable Information (PII) on the User Object, such as that in the address fields, is scrubbed from templates. PII in custom objects and fields isn’t modified. - Due to data security reasons, if your TSO was converted from a trial org to an active org, you can’t use it to create a Trialforce template. To see if the TSO is a trial org, in Setup, find and select **Company Information**. Under User Licenses, if the licenses have an expiration date, the TSO is a trial org. - If the TSO is converted to an active, paying org, then you can no longer use any associated Trialforce templates to create trial orgs. - When you create a TSO, Salesforce sets the default trial length to 10 days for trial orgs created from a Trialforce template. To get help with the default trial length, or to change the trial length associated with a template, contact Salesforce Customer Support. # Contact Salesforce Partner Support to Enable Specific Packaging Features Certain packaging features can only be enabled by Salesforce Partner Support. To log a case for Salesforce Partner Support, follow these steps. 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click the question icon and then click **Log a Case for Help**. 3. Complete the Subject and Description fields 1. After you enter a Description, a section called **Pick a different product & topic** will display. 4. For topic, select **AppExchange & Managed Packages**. For Feature Management App enablement, select **ISV Technology Request**. 5. Provide any other required details, and then click **Create Case**. # Convert Unmanaged Packages to Managed | User Permissions Needed | | | -------------------------------- | --------------------------- | | To configure namespace settings: | Customize Application | | To create packages: | Create AppExchange Packages | | To upload packages: | Upload AppExchange Packages | Before you convert an existing package to managed, alert any current installers that they must save their data: 1. Export all the data from the previous, unmanaged version of the package. 2. Uninstall the unmanaged package. 3. Install the new managed version of the package. 4. Import all the exported data into the new managed package. **note:** Note to installers: if you have made customizations to an installation of an unmanaged package, make a list of these customizations before uninstalling since you may want to implement them again. To convert an unmanaged package into a managed package: 1. [Register a namespace](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/register_namespace_prefix.htm). 2. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 3. Edit the package that you want to make managed, then select **Managed**. # Convert Your Managed 1GP Package to 2GP Before you convert your managed 1GP package version, ensure your development environment is set up. ## Before You Begin You need the latest version of Salesforce CLI installed, and the [Dev Hub and second-generation managed packaging](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_enable_devhub.htm) enabled in your PBO (Partner Business Org). **note:** After you convert a package, it’s associated with your Dev Hub org. You can’t transfer the converted package to another Dev Hub org, and the association between the Dev Hub org and your package can’t be changed. This means any subsequent conversions you initiate for this package must be associated with the Dev Hub org you specify the first time you convert a particular package. Package Conversion Steps 1. Run `sf update` to ensure you have the latest Salesforce CLI. 2. From your command line, navigate to the directory in which you plan to create your Salesforce DX project directory. 3. Create a Salesforce DX project. For example: `sf project generate --name myconvertedpkg`. 4. Authorize to your Dev Hub org. `sf org login web --set-default-dev-hub` 5. Link the namespace of your managed 1GP to the Dev Hub in your Partner Business Org (PBO). 1. Log in to your Dev Hub org. 2. Follow the steps listed in [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_reg_namespace.htm). 6. If your package depends on standard value sets, create a seed metadata file. Then in step 7, when you run `sf package convert`, include the `—-seed-metadata` flag. For details on setting up a seed metadata file, see [Picklist Value Errors](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_troubleshoot_errors.htm). 7. If your package has tests that depend on unpackaged metadata, add an unpackaged metadata directory to your `sfdx-project.json` file. To learn more about `sfdx-project.json` file, see [Project Configuration File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm). Example: ```nolang "packageDirectories": [ { "path": "force-app", "package": "TV_unl", "versionName": "ver 2.1", "default": true, "unpackagedMetadata": { "path": "my-unpackaged-directory" } }, ] ``` 8. From the command line, navigate to the directory on your computer that contains your Salesforce DX project, then convert your package. Example: ```nolang sf package convert --installation-key mdpTest --package 033xxx --wait 20 ``` To locate your 033 package ID, log in to your 1GP packaging org. From Setup, enter `Package Manager` in the Quick Find box, and then select **Package Manager**. Select the name of your managed package. After you navigate to the Package Detail page, inspect the URL in your browser’s address bar. The 15-character string in the URL that begins with 033 is your package ID. If the package version you're converting is a patch version, you must include the `--patch-version` flag when you run the `package convert` command. Package versions follow a major.minor.patch.build number format. Any package version number that contains a non-zero patch number is a patch version. For example, 1.1.2 is a patch version, but 1.1.0 isn’t. Before converting a patch version you must first convert the major.minor version of that package. Using the above example, you must convert package version 1.1.0 before converting patch version 1.1.2. ## Next Steps What’s an Installation Key? In the CLI command shown in step 7, an installation key with the value of `mpdTest` is specified. An installation key is a security key. By including this flag with the package conversion command, you’re setting a password and requiring that password whenever anyone installs the converted 2GP package. If you prefer not to require an installation key, specify `--installation-key-bypass` when you convert your package. Congrats, Your Package is Converted After you’ve completed steps 1-7, your 1GP package is converted to 2GP. You can test your package in a scratch org. The converted package is a beta version. Before you migrate the package you must promote it to a managed-released version. See [Get Ready to Promote and Release a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_get_ready_promote.htm) for details. **note:** In a scratch org, you don’t need to promote the package version to migrate it. To promote a package version to released, you must use the `--code-coverage` flag when converting the package version. The package must also meet the code coverage requirements. **note:** When you use the `--code-coverage` flag, you must have the required permission sets defined in the `sfdx-project.json` file, so that the Apex tests can run successfully. For more information, see the Permission Sets for Code Coverage section in [Troubleshoot Package Conversion Failures](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-troubleshoot-errors.md). If the source 1GP package version has passed the AgentExchange security review, then you don’t need to request a new security review for the 2GP-converted version. The 2GP-converted version inherits the listing readiness of the source 1GP package version. See [Listing Readiness for Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_listing_readiness.htm) in the _ISVforce Guide_ for more information. Keep in mind that after you migrate subscribers to 2GP, all future upgrades to that package version for that subscriber must use a 2GP package version. To fully transition your package development from your 1GP packaging org to a 2GP, CLI-based development model, see [Complete the Move to 2GP Package Development](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-move-to-2gp-workflow.md). - **[View Details about Your Converted 2GP Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-view-conversion-details.md)** So you’ve converted your 1GP package to a 2GP package. You can use one of two Salesforce CLI commands to retrieve details about your 2GP packages. - **[Specify Dependencies on Unpackageable Metadata](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-unpackageable-md.md)** It’s possible that the managed 1GP package you’re converting includes tests or references to unpackageable metadata. - **[Test Your Converted Managed 2GP Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-testing.md)** Before you migrate your first subscribers, we strongly recommend you install your newly converted managed 2GP package into a new scratch org and test its functionality. If you prefer, you can also install the converted package in a sandbox, or developer edition org. # Create a Beta Package for First-Generation Managed Packages Follow this procedure to create and upload a beta package through the UI. (You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the _Tooling API Developer Guide_.) | User Permissions Needed | | | ----------------------- | --------------------------- | | To create packages: | Create AppExchange Packages | | To upload packages: | Upload AppExchange Packages | **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). 1. Create a package: 1. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 2. Click **New**. 3. Enter a name for your package. You can use a different name than what appears on AgentExchange. 4. From the dropdown menu, select the default language of all component labels in the package. 5. Optionally, choose a custom link from the Configure Custom Link field to display configuration information to installers of your app. You can select a predefined custom link to a URL or s-control that you’ve created for your home page layouts; see the [Configure Option](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/develop-documentation.md). The custom link displays as a **Configure** link within Salesforce on AgentExchange Downloads page and app detail page of the installer's organization. 6. Optionally, in the Notify on Apex Error field, enter the username of the person to notify if an uncaught exception occurs in the Apex code. If you don’t specify a username, all uncaught exceptions generate an email notification that is sent to Salesforce. This option is only available for managed packages. **note:** Apex can only be packaged from Developer, Enterprise, Unlimited, and Performance Edition organizations. 7. Optionally, in the Notify on Packaging Error field, enter the email address of the person who receives an email notification if an error occurs when a subscriber’s attempt to install, upgrade, or uninstall a packaged app fails. This field appears only if packaging error notifications are enabled. To enable notifications, contact your Salesforce representative. 8. Optionally, enter a description that describes the package. You can change this description before you upload it to AgentExchange. 9. Optionally, specify a post install script. You can run an Apex script in the subscriber organization after the package is installed or upgraded. For more information, see [Running Apex on Package Install or Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script.md). 10. Optionally, specify an uninstall script. You can run an Apex script in the subscriber organization after the package is uninstalled. For more information, see [Running Apex on Package Uninstall](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script.md). 11. Click **Save**. 2. Optionally, change the API access privileges. By default, API access is set to Unrestricted, but you can change this setting to further restrict API access of the components in the package. 3. Add the necessary components for your app. 1. Click **Add Components**. 2. From the dropdown list, choose the type of component. 3. Select the components you want to add. 4. Click **Add To Package**. 5. Repeat these steps until you added all the components you want in your package. **note:** Some related components are automatically included in the package even though they don’t display in the Package Components list. For example, when you add a custom object to a package, its custom fields, page layouts, and relationships with standard objects are automatically included. For a complete list of components, see [Components Automatically Added to First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-components-auto-added.md). 4. Optionally, click **View Dependencies** and review a list of components that rely on other components, permissions, or preferences within the package. To return to the Package detail page, click **Done**. 5. Click **Upload**. 6. On the Upload Package page, do the following: 1. Enter a Version Name, such as Spring ’22. The version name is the marketing name for a specific release of a package and allows you to create a more descriptive title for the version than just a number. 2. Enter a Version Number, such as 1.0. For more information on versions, see [Update Your First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-upgrading.md). 3. Select a Release Type of Managed - Beta. 4. (Optional) Enter and confirm a password to share the package privately with anyone who has the password. Don't enter a password if you want to make the package available to anyone on AgentExchange and share your package publicly. 5. Salesforce automatically selects the requirements it finds. In addition, select any other required components from the Package Requirements and Object Requirements sections to notify installers of any requirements for this package. 6. Click **Upload**. After your package has uploaded successfully, you receive an email with an installation link. # 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. ## Before You Begin 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. ```nolang sf org login web --set-default me@example.com ``` 2. Create the beta version of the package. ```nolang sf 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. ## Next Steps 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. **note:** 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. **See Also** - [_Salesforce CLI Command Reference_](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference) # Create a Branded Login Page Customers typically log in to your app using the traditional `login.salesforce.com` site. A branded login page enables you to customize this domain and parts of this login page so you can provide a branded experience for your customers. ## Before You Begin |Required Editions| |-----------------| |Available in: Salesforce Classic| |Available in: **Developer** Edition| |User Permissions Needed| | |-----------------------|--| |To manage Trialforce:|Customize Application| Your custom login site includes your text and company logo, and mobile-friendly versions of your login site as well. ## Steps 1. Log in to your Trialforce Management Organization. 2. From Setup, enter `Login Site` in the Quick Find box, then select **Login Site**. 3. Click **Set Up Login Site**. 4. Select a subdomain for your login site by providing a name in the field provided. Usually, the subdomain is the name of your company. **note:** A login domain ends with `.cloudforce.com`, so if your company name is “mycompany,” your login domain is `mycompany.cloudforce.com`. 5. Check the availability of the domain and then accept the terms of use. 6. Click **Save and Launch Editor**. 7. Use the Login Brand Editor to change how your login page looks. For additional help using the editor, click **Help for this Page**. 8. Click **Save and Close**. 9. If you're ready to make these changes available to your TSO, click **Publish**. If you decide to publish later, your changes are saved and you can edit the subdomain if you change your mind. After you publish the Login page, you can't edit the subdomain. # Create a Company Profile for Your AgentExchange Business A polished, accurate company profile helps build customer trust in your AgentExchange solution or consulting service. In your profile, tell customers what makes your brand stand out and include information such as your website and phone number. Customers browsing your AgentExchange listings see this information in the Provider Details section. 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Home** | **Overview** | **Company Info**. 3. Enter your company’s information. 4. Save your changes. # Create a Custom Object Creates Per Day Recipe This recipe produces a unique count of how many times per day a custom object was created. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Select **Charts**. 3. Click **Column** and leave Bar Length as **Count of Rows**. 4. Under Bars, click **+** and search for **timestamp_DMY**. 5. Select **Year-Month-Day**. 6. Click **Filters**. 7. Click **+**. 8. Select **custom_entity_type** equals **CustomObject**. 9. Click **Apply**. 10. Click **+**. 11. Select **operation_type** Equals **INSERT**. 12. Click **Apply**. 13. Click **Data**. 14. Under Trellis, click **+**. 15. Select **custom_entity**. 16. Click **Save**. 17. Name your lens `Custom Object Creates Per Day`. 18. Select your PartnerIntelligence app. 19. Click **Save**. ## Example ![A sample Custom Object Creates Per Day CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_cou_creates.png) SAQL: ```nolang q = load "DailyAggregation"; q = filter q by 'custom_entity_type' == "CustomObject"; q = filter q by 'operation_type' == "INSERT"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Month', 'timestamp_derived_DAY_formula_Day', 'custom_entity'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Month' + "~~~" + 'timestamp_derived_DAY_formula_Day' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day', 'custom_entity' as 'custom_entity', count() as 'count'; q = order q by ('timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day' asc, 'custom_entity' asc); q = limit q 2000; ``` # Create a Custom Object Reads Per Day Recipe This recipe produces a unique count of how many times per day a custom object was read. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Select **Charts**. 3. Click **Column** and leave Bar Length as **Count of Rows**. 4. Under Bars, click **+** and search for **timestamp_DMY**. 5. Select **Year-Month-Day**. 6. Click **Filters**. 7. Click **+**. 8. Select **custom_entity_type** Equals **CustomObject** 9. Click **Apply**. 10. Click **+**. 11. Select **operation_type** Equals **READ**. 12. Click **Apply**. 13. Click **Data**. 14. Under Trellis, click **+**. 15. Select **custom_entity**. 16. Click **Save**. 17. Name your lens `Custom Object Reads Per Day`. 18. Select your PartnerIntelligence app. 19. Click **Save**. ## Example ![A sample Custom Object Reads Per Day CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_cou_reads.png) SAQL: ```nolang q = load "DailyAggregation"; q = filter q by 'custom_entity_type' == "CustomObject"; q = filter q by 'operation_type' == "READ"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Month', 'timestamp_derived_DAY_formula_Day', 'custom_entity'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Month' + "~~~" + 'timestamp_derived_DAY_formula_Day' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day', 'custom_entity' as 'custom_entity', count() as 'count'; q = order q by ('timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day' asc, 'custom_entity' asc); q = limit q 2000; ``` # Create a Custom Object Updates Per Day Recipe This recipe produces a unique count of how many times per day a custom object was created. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Select **Charts**. 3. Click **Column** and leave Bar Length as **Count of Rows**. 4. Under Bars, click **+** and select **timestamp_DMY**. 5. Select **Year-Month-Day**. 6. Click the **Filters** tab. 7. Click **+**. 8. Select **custom_entity_type** Equals **CustomObject** 9. Click **Apply**. 10. Click **+**. 11. Select **operation_type** Equals **UPDATE**. 12. Click **Apply**. 13. Click the **Data** tab. 14. Under Trellis, click **+**. 15. Select **custom_entity**. 16. Click **Save**. 17. Name your lens `Custom Object Creates Per Day`. 18. Select your PartnerIntelligence app. 19. Click **Save**. ## Example ![A sample Custom Object Updates Per Day CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_cou_updates.png) SAQL: ```nolang q = load "DailyAggregation"; q = filter q by 'custom_entity_type' == "CustomObject"; q = filter q by 'operation_type' == "UPDATE"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Month', 'timestamp_derived_DAY_formula_Day', 'custom_entity'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Month' + "~~~" + 'timestamp_derived_DAY_formula_Day' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day', 'custom_entity' as 'custom_entity', count() as 'count'; q = order q by ('timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day' asc, 'custom_entity' asc); q = limit q 2000; ``` # Create a Daily Unique Users Recipe This recipe produces a unique count of users by day. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Under Bar Length, click **Count of Rows**. 3. Click **Unique**. 4. Select **user_id_token**. 5. Select **Charts**. 6. Click **Column**. 7. Under Bars, click **+** and search for `timestamp_DMY`. 8. Select **Year-Month-Day**. 9. Click **Save**. 10. Name your lens `Daily Unique Users`. 11. Select your PartnerIntelligence app. 12. Click **Save**. ## Example ![A sample Daily Unique Users CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_csm_dailyuu.png) SAQL: ```nolang q = load "DailyAggregation"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Month', 'timestamp_derived_DAY_formula_Day'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Month' + "~~~" + 'timestamp_derived_DAY_formula_Day' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day', unique('user_id_token') as 'unique_user_id_token'; q = order q by 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month~~~timestamp_derived_DAY_formula_Day' asc; q = limit q 2000; ``` # Create a First-Generation Managed Package Using a UI If your goal is to build an app and distribute it on AgentExchange, you use managed packages to do both. Packaging is the container that you fill with metadata, and it holds the set of related features, customizations, and schema that make up your app. A package can include many different metadata components, and you can package a single component, an app, or library. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). | User Permissions Needed | | | ----------------------- | --------------------------- | | To create packages: | Create AppExchange Packages | 1. From Setup, in the Quick Find box, enter `Package Manager`, and then select **Package Manager**. 2. Click **New**. 3. Enter a name for your package. You can use a different name than what appears on AgentExchange. 4. From the dropdown menu, select the default language of all component labels in the package. 5. (Optional) Choose a custom link from the Configure Custom Link field to display configuration information to installers of your app. You can select a predefined custom link to a URL that you’ve created for your home page layouts; see the [Configure Option](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/develop-documentation.md). The custom link appears as a **Configure** link within Salesforce on AgentExchange Downloads page and app detail page of the installer's organization. 6. (Optional) In the Notify on Apex Error field, enter the username of the person to notify if an uncaught exception occurs in the Apex code. If you don’t specify a username, all uncaught exceptions generate an email notification that is sent to Salesforce. This option is only available for managed packages. 7. (Optional) In the Notify on Packaging Error field, enter the email address of the person who receives an email notification if an error occurs when a subscriber’s attempt to install, upgrade, or uninstall a packaged app fails. This field appears only if packaging error notifications are enabled. To enable notifications, [contact Salesforce Partner Support](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/pkg2_feature_enablement.htm). 8. (Optional) Enter a description that describes the package. You can change this description before you upload it to AgentExchange. 9. (Optional) Specify a post install script. You can run an Apex script in the subscriber organization after the package is installed or upgraded. For more information, see [Running Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script.md). 10. (Optional) Specify an uninstall script. You can run an Apex script in the subscriber organization after the package is uninstalled. For more information, see [Running Apex on Package Uninstall](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script.md). 11. Save your work. - **[What Are Beta Versions of Managed Packages?](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-about-beta-packages.md)** A beta package is an early version of a managed package. The purpose of a beta package is to allow the developer to test their application in different Salesforce orgs and to share the app with a pilot set of users for evaluation and feedback. - **[Create a Beta Package for First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-upload-beta.md)** Follow this procedure to create and upload a beta package through the UI. (You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the *Tooling API Developer Guide*.) - **[Create and Upload a First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/uploading-packages.md)** Use the following procedure to create and upload a managed package through the UI. You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the *Tooling API Developer Guide*. - **[Publish Extensions to Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/publish-extensions.md)** An extension is any package, component, or set of components that adds to the functionality of a managed package. An extension requires that the base managed package is installed in the org. For example, if you have built a recruiting app, an extension to this app can include a component for performing background checks on candidates. - **[View Package Details in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/isv-viewing-package-details.md)** From Setup, enter `Packages` in the Quick Find box, then select **Packages**. Click the name of a package to view its details, including added components, whether it’s a managed package, whether the package has been uploaded, and so on. - **[Notifications for Package Errors](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-notification.md)** Accurately track failed package installations, upgrades, and uninstallations in subscriber orgs with the Notifications for Package Errors feature. Proactively address issues with managed and unmanaged packages and provide support to subscribers so that they can successfully install and upgrade your apps. # Create a First-Generation Managed Package using Salesforce DX If you’re an ISV, you want to build a managed package. A managed package is a bundle of components that make up an application or piece of functionality. A managed package is a great way to release an app for sale and to support licensing your features. You can protect intellectual property because the source code of many components isn’t available through the package. You can also roll out upgrades to the package. When you’re working with your production org, you create a .zip file of metadata components and deploy them through Metadata API. The .zip file contains: - A package manifest (`package.xml`) that lists what to retrieve or deploy - One or more XML components organized into folders If you don’t have the packaged source already in the source format, you can retrieve it from the org and convert it using the CLI. - **[Enable Dev Hub and Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/second-generation/sfdx-pkg-enable-devhub.md)** The Dev Hub lets you create and manage second-generation managed packages and scratch orgs. Your Dev Hub is the designated place to find and manage all your managed 2GP packages, scratch orgs, and namespaces. - **[Limited Access License for Package Developers](https://developer.salesforce.com/docs/platform/second-generation/sfdx-pkg-slalf-pkg-dev.md)** The Salesforce Limited Access - Free is designed for users whose role is to build customizations or applications. This license provides access to the Dev Hub, development tools, and environments. In the production org, this license restricts access to standard and custom objects. Partner Business Orgs (PBO) include 100 Salesforce Limited Access - Free user licenses. - **[Add a Limited Access User to Your Dev Hub Org](https://developer.salesforce.com/docs/platform/second-generation/sfdx-pkg-add-free-license-user.md)** Provide your developers access to the Dev Hub and Salesforce DX development tools by adding a user with Salesforce Limited Access - Free license and the Limited Access user profile in your Dev Hub org. Then create and assign them a permission set to the required Dev Hub objects. - **[Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/platform/second-generation/sfdx-dev-reg-namespace.md)** To use a namespace with a scratch org, you must link the Developer Edition org where the namespace is registered to a Dev Hub org. - **[Scratch Orgs and Package Development](https://developer.salesforce.com/docs/platform/second-generation/dev-hub-intro.md)** Scratch orgs are temporary Salesforce orgs intended for development and automation. They enable source-driven deployments of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with various features and preferences. - **[Build and Release Your App with Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack.md)** If you developed and tested your app, you’re well on your way to releasing it. Luckily, when it’s time to build and release an app as a managed package, you’ve got options. You can package an app you developed from scratch. If you’re experimenting, you can also build a sample app from Salesforce and emulate the release process. - **[Packaging Checklist](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-package-checklist.md)** Ready to deploy your packaging metadata and start creating a package? Take a few minutes to verify that you covered the items in this checklist, and you’re good to go. - **[Deploy the Package Metadata to the Packaging Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-deploy.md)** Before you deploy the package metadata into your packaging org, you convert from source format to metadata format. - **[Create a Beta Version of Your App](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-beta.md)** Test your app in a scratch org, or share the app for evaluation by creating a beta version. - **[Install the Package in a Target Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-install.md)** After you create a package with the CLI, install the package in a target org. You can install the package in any org you can authenticate, including a scratch org. - **[Create a Managed Package Version of Your App](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-create.md)** After your testing is done, your app is almost ready to be published in your enterprise or on AgentExchange. Generate a new managed package version in your Dev Hub org. - **[View Information About a Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-viewinfo.md)** View the details about a specific package version, including its metadata package ID, package name, release state, and build number. # Create a Managed Package Version of Your App After your testing is done, your app is almost ready to be published in your enterprise or on AgentExchange. Generate a new managed package version in your Dev Hub org. ## Before You Begin Ensure that you’ve authorized the packaging org and can view the existing package versions. ```nolang sf org login web --instance-url https://test.salesforce.com --set-default org_alias ``` View the existing package versions for a specific package to get the ID for the version you want to install. ```nolang sf package1 version list --package-id 033... ``` To view details for all packages in the packaging org, run the command with no parameters. More than one beta package can use the same version number. However, you can use each version number for only one _managed_ package version. You can specify major or minor version numbers. You can also include URLs for a post-installation script and release notes. Before you create a managed package, make sure that you’ve configured your developer settings, including the namespace prefix. **note:** After you create a managed package version, you can’t change some attributes of Salesforce components used in the package. See: [Components Available in Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm) for information on editable components. 1. Create the managed package. Include the `--managed-released` parameter. ```nolang sf package1 version create --package-id 033xx00000007oi --name ”Spring 22” --description ”Spring 22 Release” --version 3.2 --managed-released ``` You can use other options, like `--wait` to specify the number of minutes to wait. To protect the package with an installation key, include a value for `--installation-key`. Then, you or a subscriber must supply the key before you can install the package in a target org. After the managed package version is created, you can retrieve the new package version ID using `sf package1 version list`. # Create a Monthly Unique Users Recipe This recipe produces a unique count of users by month. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Under Bar Length, click **Count of Rows**. 3. Click **Unique**. 4. Select **user_id_token**. 5. Select **Charts**. 6. Click **Column**. 7. Under Bars, click **+** and search for **timestamp_DMY**. 8. Select **Year-Month**. 9. Click **Save**. 10. Name your lens `Monthly Unique Users`. 11. Select your PartnerIntelligence app. 12. Click Save. ## Example ![A sample Monthly Unique Users CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_csm_monthlyuu.png) SAQL: ```nolang q = load "DailyAggregation"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Month'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Month' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month', unique('user_id_token') as 'unique_user_id_token'; q = order q by 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Month' asc; q = limit q 2000; ``` # Create a Package Version Based on a Scratch Org Snapshot If the dependent package your base package requires is stable, you can reduce the end-to-end package version creation time by creating a scratch org snapshot. ## Before You Begin If you haven’t reviewed [When to Use Scratch Org Snapshots in Package Development](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-when-use-snapshot.md), review that topic before continuing. There’s more than one workflow you can follow when creating a package version based on a scratch org snapshot. You can start by creating a scratch org, you can build your own scratch org definition file, or you can choose to use org shape to create a new scratch org. Whichever path you choose, after the scratch org is created, you install all the dependent packages into it, and then take a snapshot of the scratch org. Sample Workflow This workflow uses an org shape to create the initial scratch org where you’ll install the stable dependent packages, and then create a scratch org snapshot to create a package version. 1. Create the org shape. ```nolang sf org create shape --target-org source-org1 ``` 2. Create a scratch org definition file that indicates the shape’s source org. ```nolang { "orgName": "Salesforce", "sourceOrg": "00DB1230400Ifx5" } ``` 3. Create a scratch org using the org shape. ```nolang sf org create scratch --duration-days 30 --no-namespace --no-ancestors --definition-file config/scratch-def-with-shape-id.json --alias dev1-with-shape ``` If your default Dev Hub org isn’t the one that owns the org shape, indicate it on the command line. 4. Install the dependent packages. ```nolang sf package install --package 04txx --target-org dev1-with-shape ``` 5. Create a snapshot of the scratch org. ```nolang sf org create snapshot --name dhsnapshot --source-org dev1-with-shape --target-dev-hub dev-hub ``` 6. Create a new scratch org definition file and specify the snapshot name, then save the file. ```nolang { "orgName": "Salesforce", "snapshot": "dhsnapshot" } ``` 7. Create a package version using the org snapshot. This command is specifying the scratch org definition file that contains the snapshot information in it. ```nolang sf package version create --package hc-ext1 --code-coverage --installation-key-bypass --async-validation --definition-file scratch-def-with-snapshot-id.json ``` **See Also** - [When to Use Scratch Org Snapshots in Package Development](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-when-use-snapshot.md) - [_Salesforce DX Developer Guide_: Create Org Shapes](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_create.htm) # Create a Second-Generation Managed Package A package is a top-level container that holds important details about the app or package: the package name, description, and associated namespace. When you’re ready to test or share your package, use the `sf package create` Salesforce CLI command to create a package. To create a package, change to the project directory in the CLI. The package name you enter becomes the package alias, and is automatically added to the project file. You can choose to designate an active Dev Hub org user to receive email notifications for Apex gacks, and install, upgrade, or uninstall failures associated with your packages. For definitions of each parameter shown here, see [sf package create](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_create_unified) in the Salesforce CLI Reference Guide. ```nolang sf package create --name "Expenser App" --package-type Managed \ --path "expenser-main" --target-dev-hub my-hub --error-notification-username \ me@devhub.org ``` The package details you supply when you create a package are automatically added to your `sfdx-project.json` [project configuration file](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm). ## Metadata Limits in Second-Generation Managed Packages | Metadata in package | Limit | | ------------------------ | ------------ | | Number of Metadata Files | 10,000 files | | Total Metadata File Size | 600 MB | ## Update Details about a Package To update the name or description of an existing package, use this command. ```nolang sf package update --package "Expense App" --name "Expense Manager App" \ --description "The Winter ’21 release is packed with an exciting set of features." \ --error-notification-username me2@devhub.org ``` **note:** You can’t change the package namespace or package type after you create the package. After you promote at least one package version to the released state, you can also use the `sf package update` CLI command to recommend a specific version of the package to your subscribers. See [Recommend a Specific Package Version to Your Subscribers](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-recommended-version.md) for more information. # Create a Test Drive Org with Environment Hub Use Environment Hub and a preconfigured Trialforce template to create a test drive org. The Trialforce template is managed by Salesforce and handles several test drive configuration steps for you. After the org is provisioned, set a password for the admin user. Later on, you log in to the test drive org with the admin user to install your solution and perform additional configuration. You also use the admin user to create a read-only evaluation user, which gives customers the opportunity to explore the test drive org without needing login credentials. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure Environment Hub:|Manage Environment Hub| ## Steps 1. Log in to your Partner Business Org (PBO). 2. Go to Environment Hub. 3. Click **Create Org**. 4. For Purpose, select **Test Drive/Demo**. 5. For Create Using, select Trialforce Template ID. 6. For Trialforce Template ID, enter `0TTKe000000oNwz`. 7. Provide a name for the org. 8. Provide a first name, last name, and username for the org’s admin user. 9. Agree to the terms and conditions, and then click **Create**. In a few minutes, we email you login instructions for the test drive org. 10. Follow the login instructions, and set a password for the admin user. # Create a Trialforce Source Org with a Trialforce Management Org Use a Trialforce Management Org (TMO) to create a Trialforce Source Org (TSO). After you create the TSO, install your package there. Then configure the TSO as you want customers to experience it. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To manage Trialforce:|Customize Application| Available in: Salesforce Classic only. Before you install your solution in a TSO, associate the solution with your License Management App (LMA). If you don’t complete this step first, the trial orgs provisioned from the TSO don’t generate leads or licenses in the LMA. ## Steps 1. Log in to your TMO. 2. If necessary, **Switch to Salesforce Classic**. 3. From Setup, in the Quick Find box, enter `Source Organizations`, and then select **Source Organizations**. 4. Click **New**. 5. Enter a new username and email address for the admin account. 6. Enter a name for the TSO. 7. Optionally, specify the custom branding by choosing a branded email set or login site. 8. Click **Create**. You receive an email with the login details for the TSO. 9. Log in to the TSO and install your solution. 10. Add sample records, custom profiles, new users, or other configurations that help illustrate your solution’s business value. 11. Verify that the TSO admin has a license for the solution that’s installed in the TSO. ## Next Steps After you finish configuring the TSO, you’re ready to create a Trialforce template. # Create a Trialforce Source Org with Environment Hub Use the Environment Hub in a Partner Business Org (PBO) to create a Trialforce Source Org (TSO). After you create the TSO, install your package. Then configure the TSO as you want customers to experience it. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and manage Environment Hub:|Manage Environment Hub| Before you install a solution in your TSO, associate the solution with your License Management App (LMA). If you don’t complete this step first, the trial orgs provisioned from the TSO don’t generate leads or licenses in the LMA. ## Steps 1. Log in to your PBO. 2. Go to Environment Hub. 3. Click **Create Org**. 4. For Purpose, select **Trialforce Source Organization**. If you don’t see Trialforce Source Organization in the list, make sure you’re logged in to a Partner Business Org. 5. For Create Using, select **Standard Edition**. 6. Select **Professional TSO** or **Enterprise TSO**. 7. Provide an org name. 8. Optionally, enter a unique name for your My Domain. 9. Enter a username and email address for the admin account. 10. Enter a name for the TSO. 11. Acknowledge that you read the Main Services Agreement. 12. Click **Create**. The TSO now appears in the Environment Hub, and you receive an email with login details. 13. Log in to the TSO and install your solution. 14. Add sample records, custom profiles, new users, or other configurations that help illustrate your solution’s business value. 15. Verify that the TSO admin has a license for the solution that’s installed in the TSO. ## Next Steps After you configure the TSO as you want your customers to experience it, you’re ready to create a Trialforce template. Before you create the template, ensure that the TSO admin has a license for the solution that’s installed in the TSO. # Create a Trialforce Template Create and configure Trialforce templates in Setup. A Trialforce template is an approximate snapshot of your Trialforce Source Organization (TSO) at a given instance in time. ## Before You Begin |Required Editions| |-----------------| |Available in: Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Developer**, **Professional**, and **Enterprise** Edition| |User Permissions Needed| | |-----------------------|--| |To manage Trialforce:|Modify All Data| Before you create the template, make sure to: - Review the [considerations for Trialforce templates](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-template-considerations.md). - Install your packages into the TSO. Then, configure the TSO exactly as you want your customers to experience it, with the appropriate sample data, profiles, users, and records. ## Steps 1. Contact Salesforce Partner Support to set the number of days that you want trials created from this TSO to last. **note:** You only need to contact Partner Support once for each TSO. 2. Log in to your TSO. 3. From Setup, enter Trialforce in the Quick Find box, then select **Trialforce**. 4. Click **New Trialforce Template**. 5. Enter a description for the Trialforce template. 6. In the Include setting, select **All Data and Setup** to create a Trialforce template that includes both the metadata and data saved in the org when you create the template. Or, select **Setup Only** to create a Trialforce template that includes only the metadata—and not the data—saved in the org when you create the template. 7. (Optional) To rebase any date fields relative to the creation date of a new org from the Trialforce template, select **Adjust all Dates in the Resulting Organization Relative to Organization Creation Date**. This option is relevant for templates with date field data. 8. (Optional) To exclude Chatter feeds from new orgs created from the Trialforce template, select **Don't Copy Feed Items from this Trialforce Source Org into the Resulting Organization**. 9. (Optional) To create a private Trialforce template, select **Mark this template as private so that only authorized orgs can sign up**. By default, Trialforce templates are public. 10. Save the template. 11. (Optional) If you created a private Trialforce template, enter the org IDs of the orgs authorized to sign up new orgs using the template. Then, save your changes. You can enter up to 51 org IDs, each on a separate line. ## Next Steps After your new Trialforce template is generated, you receive an email with the new template ID. Remember to generate a new template each time you make updates to your TSO, so that your trials always reflect the most recent state. In Setup, Trialforce templates can have these statuses. - In Progress: After you create a template, the template always has this status initially. The status then moves to either the Success or the Error status. - Success: The template can be used to create trial organizations. - Error: The template can’t be used because something has gone wrong and debugging is required. - Deleted: The template is no longer available for use. Deleted templates are removed during system updates. # Create a Weekly Unique Users Recipe This recipe produces a unique count of users by week. In your org in Analytics Studio in CRM Analytics: 1. In All items on the Datasets tab, select your DailyAggregation dataset. 2. Under Bar Length, click **Count of Rows**. 3. Click **Unique**. 4. Select **user_id_token**. 5. Select **Charts**. 6. Click **Column**. 7. Under Bars, click **+** and search for `timestamp_DMY`. 8. Select **Year-Week**. 9. Click **Save**. 10. Name your lens `Weekly Unique Users`. 11. Select your PartnerIntelligence app. 12. Click **Save**. ## Example ![A sample Weekly Unique Users CRM Analytics lens](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_recipe_csm_weeklyuu.png) SAQL: ```nolang q = load "DailyAggregation"; q = group q by ('timestamp_derived_DAY_formula_Year', 'timestamp_derived_DAY_formula_Week'); q = foreach q generate 'timestamp_derived_DAY_formula_Year' + "~~~" + 'timestamp_derived_DAY_formula_Week' as 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Week', unique('user_id_token') as 'unique_user_id_token'; q = order q by 'timestamp_derived_DAY_formula_Year~~~timestamp_derived_DAY_formula_Week' asc; q = limit q 2000; ``` # Create AgentExchange Listings Faster with LLM-Assisted Authoring Create a complete draft listing from your managed package in minutes. In the Partner Console, connect your managed package version and let AgentExchange generate your listing fields. Then review each suggestion, adjust the tone, edit or reset fields as needed, and submit when your listing is ready. LLM-Assisted Authoring analyzes your managed package—including metadata, schema, and Agentforce artifacts—and drafts your listing content for you to review. Every field is editable, and nothing publishes until you approve it. ## Steps 1. In the Partner Console, open a new or existing listing and click **Get Started**. 2. Connect your managed package version. Optionally, click the gear icon and provide directions for how you want AgentExchange to generate your listing. To match your brand voice, use the tone selector to select Professional, Innovative, Executive, Friendly, or Technical. 3. Click **Generate your listing**. AgentExchange generates the Title, Brief Description, Full Description, Tagline, Key Highlights, SEO Title, Supported Industries, and Target Personas. If the package has Agentforce components, descriptions of those components (agents, subagents, and actions) are generated too. Each suggestion shows the package metadata it was derived from. 4. Review each suggestion, and edit or reset fields as needed. To rephrase an individual section, click **Regenerate**. 5. When your listing is ready, submit it. **important:** You’re responsible for reviewing and approving the accuracy of your final listing before you publish it. # Create an Org from the Environment Hub You can create orgs from the Environment Hub for development, testing, and trial purposes. If you’re an ISV partner, you can also create partner edition orgs with increased limits, more storage, and other customizations to support app development. When you create an org from the Environment Hub, it becomes a hub member with a default language set by the user’s locale. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure the Environment Hub:|Manage Environment Hub| **note:** You can create up to 20 member orgs per day. To create more orgs, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com). ## Steps 1. Log in to your Partner Business Org (PBO). 2. From the App Launcher, select **Environment Hub**, then select **Create Org**. 3. Choose an org purpose. |Purpose|Lets You Create:| |-------|----------------| |Development|A Developer Edition org where you can define a namespace for second-generation package (2GP) development.| |Test/Demo|Trial versions of standard Salesforce orgs for testing and demos. These orgs are similar to the ones customers create at [www.salesforce.com/trial](https://salesforce.com/trial). When you create a Test/Demo org, you can specify a Trialforce template if you want the org to include your customizations.| |Trialforce Source Organization|Trialforce Source Organizations (TSOs) as an alternative to using a Trialforce Management Organization (TMO). Unless you need custom branding on your login page or emails, use the Environment Hub to create TSOs.| 4. Enter the required information for the org type you selected. 5. Read the Main Services Agreement, and then select the checkbox. 6. Select **Create**. ## Next Steps When your org is ready, you receive an email confirmation, and the org appears in your list of hub members. # Create and Manage Trialforce Source Orgs A Trialforce Source Organization (TSO) is used to create Trialforce templates, which are the basis of customer trial orgs. You can create a TSO with Environment Hub or a Trialforce Management Org (TMO). In most cases, either method is fine, with two exceptions. If you plan to brand your emails or login page, use a TMO. To create a Professional Edition TSO, use the Environment Hub. If your TSO is about to expire, request an extension. **See Also** - [Create a Trialforce Template](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-creating-template.md) # Create and Register Your Namespace for Second-Generation Managed Packages With second-generation managed packaging (managed 2GP), you can share a single namespace with multiple packages. Since sharing of code is much easier if your package shares the same namespace, we recommend that you use a single namespace for all of your managed 2GP packages. To create a namespace: 1. Sign up for a new Developer Edition org. 2. In Setup, enter `Package Manager` in the Quick Find box, and select **Package Manager**. 3. In Namespace Settings, click **Edit**. 4. Enter a namespace and select **Check Availability**. 5. (Optional) Select a package to associate with this namespace , or select **None**, then click **Review**. 6. Review your selections, and then click **Save**. To register a namespace: 1. To link the namespace that you created with your Dev Hub, use Namespace Registry. See [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_reg_namespace.htm) for details. 2. In the `sfdx-project.json` file, specify your namespace using the namespace attribute. When you create a new 2GP package, the package is associated with the namespace specified in the `sfdx-project.json` file. **See Also** - [Namespaces for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_plan_namespaces.htm) - [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm) - [Avoid Namespace Collisions in Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_namespace_collisions.htm) # Create and Upload a First-Generation Managed Package Use the following procedure to create and upload a managed package through the UI. You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the _Tooling API Developer Guide_. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). | User Permissions Needed | | | ----------------------- | --------------------------- | | To create packages: | Create AppExchange Packages | | To upload packages: | Upload AppExchange Packages | These steps assume you’ve already created a namespace and beta package. If you’re uploading a beta package for testing, see [Create and Upload a Beta Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-upload-beta.md). 1. Create a package: 1. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 2. Click **New**. 3. Enter a name for your package. You can use a different name than what appears on AgentExchange. 4. From the dropdown menu, select the default language of all component labels in the package. 5. Optionally, choose a custom link from the Configure Custom Link field to display configuration information to installers of your app. You can select a predefined custom link to a URL or s-control that you’ve created for your home page layouts; see the [Configure Option](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/develop-documentation.md). The custom link displays as a **Configure** link within Salesforce on AgentExchange Downloads page and app detail page of the installer's organization. **note:** The option to configure a custom link is available only to first-generation managed packages (1GP). This option isn't available to second-generation managed packages (2GP). 6. Optionally, in the Notify on Apex Error field, enter the username of the person to notify if an uncaught exception occurs in the Apex code. If you don’t specify a username, all uncaught exceptions generate an email notification that is sent to Salesforce. This option is only available for managed packages. **note:** Apex can only be packaged from Developer, Enterprise, Unlimited, and Performance Edition organizations. 7. Optionally, in the Notify on Packaging Error field, enter the email address of the person who receives an email notification if an error occurs when a subscriber’s attempt to install, upgrade, or uninstall a packaged app fails. This field appears only if packaging error notifications are enabled. To enable notifications, contact your Salesforce representative. 8. Optionally, enter a description that describes the package. You can change this description before you upload it to AgentExchange. 9. Optionally, specify a post install script. You can run an Apex script in the subscriber organization after the package is installed or upgraded. For more information, see [Running Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script.md). 10. Optionally, specify an uninstall script. You can run an Apex script in the subscriber organization after the package is uninstalled. For more information, see [Running Apex on Package Uninstall](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script.md). 11. Click **Save**. 2. Salesforce sets your package API access privileges to Unrestricted. You can change this setting to further restrict API access of Salesforce components in the package. For more information, see [Manage API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/editing-client-security-profile.md). 3. Add the necessary components for your app. 1. Click **Add Components**. 2. From the dropdown list, choose the type of component you want to add to your package. - At the top of the list, click a letter to display the contents of the sorted column that begin with that character. - If available, click the **Next Page** (or **Previous Page**) link to go to the next or previous set of components. - If available, click **fewer** or **more** at the bottom of the list to view a shorter or longer display list. 3. Select the components you want to add. 4. Click **Add To Package**. 5. Repeat these steps until you added all the components you want in your package. **note:** Some related components are automatically included in the package even if they don’t display in the Package Components list. For example, when you add a custom object to a package, its custom fields, page layouts, and relationships with standard objects are automatically included. When you package a joined report, each block is included in the package. Although the blocks appear in the package as reports, when you click a block, an error message indicates that you have “insufficient privileges” to view the report. This error message is expected behavior. Instead, click the name of the joined report to run it. 4. Optionally, click **View Dependencies** and review a list of components that rely on other components, permissions, or preferences within the package. An entity can include such things as an s-control, a standard or custom field, or an organization-wide setting like multicurrency. Your package can’t be installed unless the installer has the listed components enabled or installed. For more information on dependencies, see [Understanding Dependencies](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/about-dependencies.md). To return to the Package detail page, click **Done**. **note:** You can’t upload packages that contain any of the following: - Workflow rules or workflow actions (such as field updates or outbound messages) that reference record types. - Reports that reference record types on standard objects. 5. Click **Upload**. **note:** If you create a managed package to publish on AgentExchange, you must certify your application before you package it. For more information, see [Security Review](https://partners.salesforce.com/s/education/appvendors/Security_Review) on AgentExchange. 6. On the Upload Package page, do the following: 1. Enter a Version Name. As a best practice, it's useful to have a short description and the date. 2. Enter a Version Number for the upload, such as 1.0. The format is majorNumber.minorNumber. **note:** If you’re uploading a new patch version, you can't change the patch number. The version number represents a release of a package. This field is required for managed and unmanaged packages. For a managed package, the version number corresponds to a Managed - Released upload. All beta uploads use the same version number until you upload a Managed - Released package version with a new version number. For example, the following is a sequence of version numbers for a series of uploads. | Upload Sequence | Type | Version Number | Notes | | --------------- | ------------------ | -------------- | --------------------------------------------------------------------------------------------- | | First upload | Managed - Beta | 1.0 | The first Managed - Beta upload. | | Second upload | Managed - Released | 1.0 | A Managed - Released upload. The version number doesn’t change. | | Third upload | Managed - Released | 1.1 | Note the change of minor release number for the Managed - Released upload. | | Fourth upload | Managed - Beta | 2.0 | The first Managed - Beta upload for version number 2.0. Note the major version number update. | | Fifth upload | Managed - Released | 2.0 | A Managed - Released upload. The version number doesn’t change. | 3. For managed packages, select a Release Type: - Choose Managed - Released to upload an upgradeable version. After upload, some attributes of the metadata components are locked. - Choose Managed - Beta if you want to upload a version of your package to a small sampling of your audience for testing purposes. You can still change the components and upload other beta versions. **note:** Beta packages can only be installed in Developer Edition, scratch, or sandbox orgs, and thus can't be pushed to customer orgs. 4. Change the Description, if necessary. 5. (Optional) Specify a link to release notes for the package. Click **URL** and enter the details in the text field that appears. This link will be displayed during the installation process, and on the Package Details page after installation. **note:** As a best practice, point to an external URL, so you can make the information available to customers before the release, and update it independently of the package. 6. (Optional) Specify a link to post install instructions for the package. Click **URL** or **Visualforce page** and enter the details in the text field that appears. This link will be displayed on the Package Details page after installation. **note:** As a best practice, point to an external URL, so you can update the information independently of the package. 7. (Optional) Enter and confirm a password to share the package privately with anyone who has the password. Don't enter a password if you want to make the package available to anyone on AgentExchange and share your package publicly. 8. Salesforce automatically selects the requirements it finds. In addition, select any other required components from the Package Requirements and Object Requirements sections to notify installers of any requirements for this package. 9. Click **Upload**. You receive an email that includes an installation link when your package has been uploaded successfully. **note:** - When using the install URL, the old installer is displayed by default. You can customize the installation behavior by modifying the installation URL you provide your customers. - To access the new installer, append the text &newui=1 to the installation URL. - To access the new installer with the "All Users" option selected by default, append the additional text &p1=full to the installation URL. - If you uploaded from your Salesforce production org, notify installers who want to install it in a sandbox org to replace the _login.salesforce.com_ portion of the installation URL with _test.salesforce.com_.t” After your upload is complete you can do any of the following. - To revert the Managed - Released package version back to Managed - Beta, click **Revert to Beta**. **important:** The Revert to Beta option is available only for the latest released package version that is not a patch version. For example, if both package versions 1.0 and 2.0 are released, the Revert to Beta option is available only on the detail page of package version 2.0. To revert the released package version to beta, the package version can’t be installed in any orgs and it can’t be associated with a patch development org. If the package version is installed in any subscriber orgs, uninstall the package version before reverting the version to the beta state. After you revert a package version to beta, when you create a new package version, the new package version number is the highest package version number that’s in the beta state. - To change the password option, click **Change Password** link. - To prevent new installations of this package while allowing existing installations to continue operating, click **Deprecate**. **note:** You can’t deprecate the most recent version of a managed package. When you deprecate a package, remember to remove it from AgentExchange as well. - To make a deprecated version available for installation again, click **Undeprecate**. # Create and Upload an Unmanaged Package Use the following procedure to upload an unmanaged package through the UI. You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the Tooling API Developer Guide. 1. Create the package: 1. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 2. Click **New**. 3. Fill in the details of the package. 4. Click **Save**. 2. On the Components tab, click **Add**. 3. From the Component Type dropdown list, choose a component. 4. Select the component you want to add. 5. Click **Add To Package**. 6. Repeat these steps until you’ve added all the components you want in your package. 7. Click **Upload**. ## Next Steps You will receive an email that includes an installation link when your package has been uploaded successfully. Wait a few moments before clicking the installation link or distributing it to others, as it might take a few minutes for it to become active. ## Considerations for Uninstalling Unmanaged Packages If your unmanaged package has dependencies on metadata in another package, remove any dependencies before attempting to uninstall either package. ## Before You Begin If you’re working in a sandbox org, you must first remove the package dependencies in your production org. 1. Locate the unmanaged package in your production org and remove the dependencies to the package you plan to uninstall. 2. [Create or refresh your sandbox org](https://help.salesforce.com/s/articleView?id=platform.data_sandbox_create_parent.htm&type=5). 3. In your sandbox org, you can now uninstall the package that your unmanaged package previously depended on. # Create and Upload Patches in First-Generation Managed Packages Patch versions are developed and maintained in a patch development org. | Availability | | ----------------------------------- | |   | | Available in: **Developer** Edition | | User Permissions Needed | | | ---------------------------------------------------- | --------------------------- | | To push an upgrade or create a patch development org | Upload AppExchange Packages | **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). To enable patch versioning, log a case in the [Salesforce Partner Community](https://partners.salesforce.com) and request patch versioning be enabled in the org where you created the namespace for the package. Patch versioning is available only to packages that have passed AgentExchange security review. To create a patch version: 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. Click the name of your managed package. 3. On the Patch Organization tab, click **New**. 4. Select the package version that you want to create a patch for in the Patching Major Release dropdown. The release type must be Managed - Released. 5. Enter a username for a login to your patch org. 6. Enter an email address associated with your login. 7. Click **Save**. **note:** If you ever lose your login information, click **Reset** on the package detail page under Patch Development Organizations to reset the login to your patch development org. The name of the patch development org’s My Domain name is randomly generated. After you receive an email that Salesforce has created your patch development org, you can click **Login** to begin developing your patch version. Development in a patch development org is restricted. - You can’t add package components. - You can’t delete existing package components. - API and dynamic Apex access controls can’t change for the package. - No deprecation of any Apex code. - You can’t add new Apex class relationships, such as `extends`. - You can’t add Apex access modifiers, such as `virtual` or `global`. - You can’t add new web services. - You can’t add feature or component dependencies. You can remove a feature or component dependency from a patch, but after the dependency is removed and the patch version is uploaded, you can't reinstate that dependency in a new patch version. To reinstate the dependency, create a new major or minor package version. When you finish developing your patch, upload it through the UI in your patch development org. You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the _Tooling API Developer Guide_. **note:** When you upload a new package in your patch development org, the upload process is asynchronous. Because the time to process the request varies, the package isn’t available immediately after the upload. While waiting, you can run SOQL queries on the PackageUploadRequest status field to monitor the request. 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. Click the name of the package. 3. On the Upload Package page, click **Upload**. 4. Enter a Version Name. As a best practice, it's useful to have a short description and the date. 5. Notice that the Version Number has had its patchNumber incremented. 6. For managed packages, select a Release Type: - Choose Managed - Released to upload an upgradeable version. After upload, some attributes of the metadata components are locked. - Choose Managed - Beta if you want to upload a version of your package to a small sampling of your audience for testing purposes. You can still change the components and upload other beta versions. **note:** Beta packages can only be installed in Developer Edition, scratch, or sandbox orgs, and thus can't be pushed to customer orgs. 7. Change the Description, if necessary. 8. (Optional) Enter and confirm a password to share the package privately with anyone who has the password. Don't enter a password if you want to make the package available to anyone on AgentExchange and share your package publicly. 9. Salesforce automatically selects the requirements it finds. In addition, select any other required components from the Package Requirements and Object Requirements sections to notify installers of any requirements for this package. 10. Click **Upload**. To distribute your patch, you can either share the upload link or [schedule a push upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-scheduling.md). # Create Branded Emails You can customize the branding of the emails sent to subscribers of new trial organizations. ## Before You Begin | Required Editions | | ----------------------------------- | | Available in: Salesforce Classic | | Available in: **Developer** Edition | | User Permissions Needed |   | | ----------------------- | --------------------- | | To manage Trialforce: | Customize Application | ## Steps 1. Log in to your Trialforce Management Organization (TMO). 2. Verify your email-sending domain by either creating a DomainKeys Identified Mail (DKIM) key or setting up an authorized email domain. See [Determine How to Verify Your Email-Sending Domains](https://help.salesforce.com/s/articleView?id=xcloud.security_user_email_verification_domain_auth.htm&type=5) for instructions. **note:** This requirement was introduced in July 2026. If you created a branded email set before July 2026, you must retroactively verify your email-sending domain. 3. Create a branded email set. 1. From Setup, in the Quick Find box, enter `Branding`, select **Branding**, and then click **Email Sets**. 2. Click **New Email Set** or **Edit** next to an existing email set. 3. Enter a name for the email set and your company information. 4. In the Preview Emails area, click through the different types of generated emails and make sure that they read correctly. The login URL displayed in the preview is always https://login.salesforce.com even if you use a branded login page. These two processes are distinct. 5. Save your work. 6. If you’re ready to make these emails available to your Trialforce Source Organization (TSO), click **Publish**. Otherwise your changes are saved, and you can publish later. **important:** When you publish a branded email set, you can no longer delete it. You can only delete an email set if it has never been published. 4. Assign a branded email set to your TSO. 1. From Setup, in the Quick Find box, enter `Source Organizations`, and then select **Source Organizations**. 2. Click **Edit** next to your TSO. 3. Select the email set. 4. Save your work. 5. If you want to see your branded login page in action, click **Login**. **note:** To check whether a published email set has a verified email-sending domain, review the Verified Email Domain field in Setup for Branded Email Sets. For any email sets that don’t have the Verified Email Domain field checked, [verify the associated email-sending domain](https://help.salesforce.com/s/articleView?id=xcloud.security_user_email_verification_domain_auth.htm&type=5). This field is available starting Winter ’27. # Create Dependencies Between Second-Generation Managed Packages To avoid monolithic package development practices, plan to develop smaller, modular packages that group similar functionality and components. You can then define the dependencies between these packages. A package dependency is when metadata contained in one package depends on metadata contained in another package. For example, defining dependencies allow you to extend the functionality of a base package with components and metadata located in a separate package. ## How to Specify a Managed 2GP Package Dependency **note:** To understand which combination of managed 2GP and managed 1GP package dependencies are supported, see [Which Package Types Can Your Package Depend On?](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_dependency_overview.htm). To specify dependencies between managed packages associated with the same Dev Hub, use either the package version alias or a combination of the package name and the version number. Example 1: ```javascript "dependencies": [ { "package": "MyPackageName@0.1.0.1" } ] ``` Example 2: ```javascript "dependencies": [ { "package": "MyPackageName", "versionNumber": "1.0.0.RELEASED" } ] ``` To specify a dependency on a managed package that isn’t associated with your Dev Hub: ```javascript "dependencies": [ { "package": "04txxx" } ] ``` **note:** You can use the RELEASED keyword for the version number to set the dependency. To denote dependencies with package IDs instead of package aliases, use: - The `0Ho` ID if you specify the package ID along with the version number - The `04t` ID if you specify only the package version ID ## Specifying Multiple Package Dependencies If your package has more than one dependency, provide a comma-separated list of packages in the order of installation. For example, if your package depends on the package Expense Manager - Util, which in turn depends on the package External Apex Library, the package dependencies are: ```javascript "dependencies": [ { "package" : "External Apex Library - 1.0.0.4" }, { "package": "Expense Manager - Util", "versionNumber": "4.7.0.RELEASED" } ] ``` If the package has multilevel dependencies, you can optionally set the calculateTransitiveDependencies parameter to `true` in the `sfdx-project.json` file. When calculateTransitiveDependencies is `true`, you can specify the package’s direct dependencies only, and the indirect (transitive) dependencies are calculated for you. For example, if calculateTransitiveDependencies is enabled and the package depends on the package Expense Manager - Util, which in turn depends on the package External Apex Library, the package dependency is: ```javascript "dependencies": [ { "package": "Expense Manager - Util", "versionNumber": "4.7.0.RELEASED" } ] ``` ## Which Types of Dependencies Are Supported? **Circular Dependencies:** Circular dependencies among packages aren’t supported. A circular dependency occurs when pkgC depends on pkgB, pkgB depends on pkgA, and pkgA depends on pkgC. **Multi-level Dependencies** Multi-level package dependencies are supported. A multi-level dependency occurs when pkgC depends on pkgB, and pkgB depends on pkgA. ![A diagram of a multilevel dependency where PkgC depends on PkgB, and PkgB depends on PkgA.](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_multilevel_dependencies.png) By default, you list all dependencies at all levels in the `sfdx-project.json` file. To specify only the package’s direct dependencies and have the indirect (transitive) dependencies calculated for you, you can optionally set calculateTransitiveDependencies to `true` in the `sfdx-project.json` file. When calculateTransitiveDependencies is not enabled, list all dependencies in the `sfdx-project.json` file in the package installation order. In this example, pkgA must be installed first, followed by pkgB, and then pkgC. The dependencies specified for pkgC are both pkgA and pkgB. ```nolang { "packageDirectories": [ { "path": "pkgA-wsp", "default": true, "package": "pkgA", "versionName": "ver 1.3", "versionNumber": "1.3.0.NEXT", "ancestorVersion": "1.1.0.RELEASED" }, { "path": "pkgB-wsp", "default": false, "package": "pkgB", "versionName": "ver 2.3", "versionNumber": "2.3.0.NEXT", "ancestorVersion": "2.0.0.RELEASED", "dependencies": [ { "package": "pkgA@1.1.0.RELEASED" } ] }, { "path": "pkgC-wsp", "default": false, "package": "pkgC", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "dependencies": [ { "package": "pkgA@1.1.0.RELEASED" }, { "package": "pkgB@2.0.0.RELEASED" } ] } ​ ], } ``` When calculateTransitiveDependencies is set to `true`, specify each package’s direct dependencies only. In this example, pkgC depends on pkgB, pkgB depends on pkgA, and pkgC’s indirect dependency on pkgA is calculated for you. ```nolang { "packageDirectories": [ { "path": "pkgA-wsp", "default": true, "package": "pkgA", "versionName": "ver 1.3", "versionNumber": "1.3.0.NEXT", "ancestorVersion": "1.1.0.RELEASED" }, { "path": "pkgB-wsp", "default": false, "package": "pkgB", "versionName": "ver 2.3", "versionNumber": "2.3.0.NEXT", "ancestorVersion": "2.0.0.RELEASED", "dependencies": [ { "package": "pkgA@1.1.0.RELEASED" } ] }, { "path": "pkgC-wsp", "default": false, "package": "pkgC", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "calculateTransitiveDependencies": true, "dependencies": [ { "package": "pkgB@2.0.0.RELEASED" } ] } ], } ``` The specified package version number also impacts the installation of package dependencies. Before pkgB can be installed, pkgA version 1.1 or higher must first be installed. If this condition isn’t met, the installation of pkgB fails. **See Also** - [Advanced Project Configuration Parameters for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_adv_config_file.htm) - [Which Package Types Can Your Package Depend On?](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_dependency_overview.htm) - [Considerations for Promoting Packages with Dependencies](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_considerations_pkg_dependency.htm) # Create Feature Parameters for Your Second-Generation Managed Package To create a feature parameter for a 2GP managed package, create an individual XML file. Here are details on the file naming convention, folder structure, and the attributes you use when creating feature parameters. **note:** Feature parameters for managed 1GP packages are created in the packaging org’s UI, see [Create Feature Parameters in Your Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_create_feature_parameters.htm) in the _First-Generation Managed Packaging Developer Guide_ for details. A package can include up to 200 feature parameters. ## Folder Structure Feature parameters are stored as files in your Salesforce DX project folder. Under the root force-app folder, create a folder and name it featureParameters. Store your feature parameter files in the feature parameters folder. Each feature parameter you create must have its own separate file. **note:** It’s not possible to create feature parameters using a scratch org’s user interface. ## File Naming Convention The naming format for feature parameter files is `<name>.featureParameter<type>-meta.xml`. The name is the API name of the feature parameter. The type is the feature parameter type. Feature parameters can be booleans, integers, or dates. | Type | File Name Format | | ------- | ----------------------------------- | | Boolean | `.featureParameterBoolean-meta.xml` | | Date | `.featureParameterDate-meta.xml` | | Integer | `.featureParameterInteger-meta.xml` | ## Feature Parameter Attributes Feature parameters include these three fields. | Field Name | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | dataflowDirection | Indicates which direction this parameter is transferring data. Each feature parameter value gets transferred in one of two directions: from your LMO to a subscriber org (LmoToSubscriber), or from a subscriber org to your LMO (SubscriberToLmo). | | masterLabel | The label of the feature parameter. This label displays in the app. | | value | The value of the feature parameter. Booleans, integers, and dates are all valid values. Integer values can’t exceed nine digits. | **note:** After a feature parameter is included and released in the package version, the data flow direction can’t be changed. ## Examples of Feature Parameter file **AdvancedPricingEnabled.featureParameterBoolean-meta.xml** ```nolang SubscriberToLmo Advanced Pricing Enabled true ``` **NumberofLedgers.featureParameterInteger-meta.xml** ```nolang SubscriberToLmo Number of Ledgers 7 ``` **ProjectActivationDate.featureParameterDate-meta.xml** ```nolang LmoToSubscriber Date of Activation of the Project 2020-01-25 ``` # Create Feature Parameters in Your Packaging Org Create a feature parameter in your packaging org, and set its type, default value, and data flow direction. 1. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 2. In the Packages section, in the Package Name column, select your managed package. 3. On the Feature Parameters tab, click **New Boolean**, **New Integer**, or **New Date**. If the Feature Parameters tab isn’t visible, log a case with Salesforce Partner Support. 4. Give your feature parameter a developer name that meets the standard criteria for developer names. The name must be unique in your org. It can contain only alphanumeric characters and underscores, and must begin with a letter. It can’t include spaces, end with an underscore, nor contain two consecutive underscores. 5. Give the feature parameter a label. 6. Set a default value for the feature parameter. If you’re creating a Feature Parameter Boolean, you see only a checkbox for Default Value. If you want your default value to be `true`, select this checkbox. Integer values can’t exceed nine digits. 7. Set a data flow direction. To use this feature parameter to control behavior in your subscriber’s org, select **LMO to Subscriber**. To collect activation metrics from your subscriber, select **Subscriber to LMO**. Note: After the feature parameter is included in a promoted and released package version, the data flow direction can't be changed. 8. Click **Save**. # Create PSL Feature Tiers and License Management CLI with the Dreamhouse App Permission Set Licenses (PSLs) are a permission type that allow you to grant gradual, gated, and custom feature access to your customers. They give you granularity and control over your permissioning structure. The Dreamhouse Lightning Web Components Sample Application acts as a reference implementation for building Second-Generation Managed Packages (2GP) with PSLs and custom permissions. It covers how to use the Salesforce CLI license management plugin to provision and manage PSL-based feature tiers in scratch orgs. Use this guide to practice: - Structuring feature tiers using PSLs. - Gating features in Apex, LWC, and Flows using custom permissions. - Installing and configuring the license management CLI plugin. - Provisioning PSL seats for development and testing. ## Get Started With the Dreamhouse App Dreamhouse is a fully formed sample app that serves as a reference implementation for building apps on the Salesforce platform. Today, we're using it as a reference for building modular, tiered-based features that you can use in your managed packages and sell on AgentExchange. For more information about the Dreamhouse App, see [Quick Start: Explore the Dreamhouse Sample App](https://trailhead.salesforce.com/content/learn/projects/quick-start-dreamhouse-sample-app). - Find the source repository: The Go-To-Market app specific version of the Dreamhouse app with PSL support is available at [https://github.com/sf-partner-solutions/dreamhouse-psl](https://github.com/sf-partner-solutions/dreamhouse-psl). The repository is maintained by Salesforce and contains PSL tier gating, custom permissions, and CI integration references. You can use it as a starting point for practicing and creating your own implementation. - Review the package structure: | Property | Value | | ------------------- | --------------------------------------------------------------------- | | Namespace | dreamhouse | | Package | DreamhouseLWC (single package directory under force-app) | | Package Type | Second-Generation Managed Package (2GP) | | Scratch Org Feature | PartnerLicensingPlatform (enabled in config/project-scratch-def.json) | ## Understand Feature Tier Architecture The Dreamhouse app implements three feature tiers, each driven by a PSL and corresponding custom permissions. Each PSL definition is stored in permissionSetLicenseDefinitions/ metadata. When you assign a PSL to a user, they're assigned a custom permission and the code checks for the custom permission to gate access to features. You no longer need a separate permission set. | Tier | PSL Name (for CLI) | Custom Permission | Features Included | | ----------------- | ------------------ | ----------------- | ---------------------------------------------------------------------------------------- | | Starter | base | ViewProperties | View Properties (list, Property Explorer, Property Finder). Read-only access. | | Premium | premium | ViewPropertyMap | Everything in the Starter tier + Property Map component. | | Manage Properties | full | ManageProperties | View Brokers, edit Properties and Brokers, run Create Property flow, Sample Data Import. | ## Gate Features in Your Code Use these patterns when implementing PSL-based gating in your own packages. The following patterns show you how to gate features using custom permissions in Apex, LWC, and Flow. ### Pattern 1: Apex Gating Use FeatureManagement.checkPermission() to gate server-side logic. Keep in mind: - Always use the fully qualified API name: namespace\_\_PermissionName. - Return empty, null, or throw an exception when the permission is missing. - Apex gating enforces access at the data layer, not just from the UI. #### Example from Dreamhouse (PropertyController.cls) ```nolang public static List getPagedPropertyList() { if (!FeatureManagement.checkPermission('dreamhouse__ViewProperties')) { return null; // User doesn't have the Starter tier } // ... return property data } ``` ### Pattern 2: LWC Gating Import the custom permission and use it in a getter with lwc:if. Keep in mind: - Use the import syntax: @salesforce/customPermission/PermissionName. - The import returns a boolean at runtime. - Use lwc:if or lwc:else for conditional rendering. - For standard user permissions, use @salesforce/userPermission. #### Example from Dreamhouse (propertyMap.js) ```nolang import ViewPropertyMap from '@salesforce/customPermission/ViewPropertyMap'; export default class PropertyMap extends LightningElement { get isPremium() { return ViewPropertyMap; } } ``` Template (propertyMap.html): ```nolang ``` ### Pattern 3: Flow Gating Use a formula resource with $Permission and a decision element. Key points: - Use $Permission.namespace\_\_PermissionName in formula resources. - Place the permission check at the start of the flow. - Create a clear "No Access" message for the user. #### Example from Dreamhouse (Create_property.flow-meta.xml) ```nolang user_has_manage_properties Boolean $Permission.dreamhouse__ManageProperties Check_Manage_Properties no_access No Access Manage_Properties_Access_Rule user_has_manage_properties EqualTo true new_property ``` ## Install the License Management CLI Plugin Before you begin, make sure you have the [Salesforce CLI](https://developer.salesforce.com/tools/salesforcecli) installed and access to a Dev Hub org with 2GP capability in your scratch org. For more info, see [Select and Enable a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_devhub.htm). 1. Install the plugin. ```nolang sf plugins install @salesforce/plugin-license-management ``` 2. Verify installation. ```nolang sf license provision --help ``` ## Set Up Dreamhouse for Development 1. Clone the Repository. ```nolang git clone https://github.com/sf-partner-solutions/dreamhouse-psl cd dreamhouse-psl ``` 2. Authorize Your Dev Hub. If you haven't already done so, authorize your hub org and provide it with an alias. The command uses myhuborg as the example alias. ```nolang sf org login web -d -a myhuborg ``` 3. Create a Scratch Org. Create a scratch org and provide it with an alias. The command below uses dreamhouse as the example alias. The scratch org definition (config/project-scratch-def.json) must have PartnerLicensingPlatform enabled for PSL support. ```nolang sf org create scratch -d -f config/project-scratch-def.json -a dreamhouse ``` 4. Deploy the Source. Push the app to your scratch org to deploy it. ```nolang sf project deploy start ``` 5. Assign Permissions. Assign the dreamhouse permission set to the default user providing full access, or use the sf license provision CLI command to provision PSL-based tiers. Full access (no PSL, for basic development): ```nolang sf org assign permset -n dreamhouse ``` PSL-based tiers (recommended for testing feature gating): Follow the steps in Provision PSL Seats with the sf license provision to create feature gating. (Optional) Assign the Walkthroughs permission set to the default user: The Walkthroughs permission allows your user to use In-App Guidance Walkthroughs, providing a guided tour of the sample app. The permission set gets auto-created with In-App guidance activation. ```nolang sf org assign permset -n Walkthroughs ``` 6. Import Sample Data. **note:** The Sample Data Import card in the app UI is only visible to users with the ManageProperties custom permission (Manage Properties tier). ```nolang sf data tree import -p data/sample-data-plan.json ``` 7. Open the Org. ```nolang sf org open ``` Activate the Lightning Lite theme in **Setup** | **Themes and Branding**, and open the Dreamhouse app from App Launcher. ### Provision PSL Seats with the sf license provision 1. Use the sf license provision CLI command to provision PSLs within your org. ```nolang sf license provision -o [-n namespace] [-l license] [-q quantity] [-s start-date] [-e end-date] [-f definition-file] ``` 2. Provision Individual Tiers 1. Starter tier (view Properties only): ```nolang sf license provision --target-org dreamhouse --namespace dreamhouse --license base --quantity 1 ``` 2. Premium tier (adds Property Map): ```nolang sf license provision --target-org dreamhouse --namespace dreamhouse --license premium --quantity 1 ``` 3. Manage Properties tier (full access — edit, create, import): ```nolang sf license provision --target-org dreamhouse --namespace dreamhouse --license full --quantity 1 ``` ### Bulk Provision Licenses with a Definition File 1. Create a JSON file (e.g., provisionPSLs.json): ```nolang [ { "namespace": "dreamhouse", "license": "base", "quantity": 5 }, { "namespace": "dreamhouse", "license": "premium", "quantity": 3 }, { "namespace": "dreamhouse", "license": "full", "quantity": 1 } ] ``` 2. Then run: ```nolang sf license provision --target-org dreamhouse --definition-file ./provisionPSLs.json ``` ### Use --license Values The --license flag must match the short name from the PSL definition file names, NOT the human-readable label in the metadata. | Tier | --license value | Metadata label (do NOT use) | | ----------------- | --------------- | --------------------------- | | Starter | base | DreamHouse Base Access | | Premium | premium | DreamHouse Premium Access | | Manage Properties | full | DreamHouse Full Access | ## Use the CI/CD Integration Add PSL Provisioning to Your CI Pipeline. After you deploy your source to a scratch org in the CI, and before running tests, add the provisioning step. A base CI script is provided at scripts/ci.sh in the Dreamhouse repository. ### Example ```nolang # 1. Create scratch org sf org create scratch -d -f config/project-scratch-def.json -a ci-org # 2. Deploy source sf project deploy start -o ci-org # 3. Provision PSLs (before tests!) sf license provision -o ci-org -n dreamhouse -l full -q 1 # 4. Assign permission to test user (if needed) sf org assign permset -n dreamhouse -o ci-org # 5. Run tests sf apex run test -o ci-org --wait 10 ``` ## Create Your Own Package Use PSLs with custom permissions in your own packages. 1. Define your feature tiers and decide which features belong to each tier. 2. Create custom permissions, using one permission per gated feature or tier. 3. Create PSL definitions and link each PSL to the appropriate custom permissions. 4. Enable PartnerLicensingAndProvisioningPlatform and add to your scratch org definition. 5. Gate Apex methods using FeatureManagement.checkPermission(). 6. Gate LWC components and import @salesforce/customPermission/YourPermission. 7. Gate Flows using $Permission.namespace\_\_PermissionName in decisions. 8. Update CI scripts, adding the sf license provision command after you deploy, but before you run tests. 9. Test each tier and verify users see only their tier's features. 10. Document for customers by creating clear tier descriptions and provisioning instructions. ## Use the Recommended Best Practices - **Defense in depth:** Gate at both UI (LWC/Flow) and server (Apex) layers. - **Graceful degradation:** Show informative "upgrade" messages, not errors. - **Use a single package:** You can manage multiple tiers within one 2GP package. - **Namespace consistency:** Always prefix custom permissions with your namespace in code references. ## Troubleshoot Your Implementation If you encounter issues with PSL provisioning or feature gating, check: - That PartnerLicensingAndProvisioningPlatform is enabled in your scratch org definition. - That the --license value matches the definition file name, not the label. - That you're using the correct namespace prefix in permission checks. - That the user has been assigned the provisioned PSL in Setup > Users > Permission Set License Assignments. For CLI plugin issues, file a GitHub issue at: [https://github.com/salesforcecli/plugin-license-management/issues](https://github.com/salesforcecli/plugin-license-management/issues) # Create the Country-Codes Dataset To create visualizations of your country-based data in map format, you normalize the LMA country-code data to CRM Analytics country-code format. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | 1. Click [country-codes.csv](https://github.com/datasets/country-codes/blob/master/data/country-codes.csv) to download standardized country code data. 2. Right-click **Raw** and click **Save Link As**. 3. Name the file `country-codes.txt`, and save it to your desktop. 4. In Analytics Studio in CRM Analytics, click **Create**. 5. Click **Dataset**. 6. Click **CSV File**. 7. Select your `country-codes.txt` file. 8. Click **Next**. 9. Name your dataset `country-codes`. 10. Select your **PartnerIntelligence** app. 11. Click **Next**. 12. Click **Upload File**. # Create the LMAJoin CRM Analytics Recipe Create a CRM Analytics recipe that contains your License Management App (LMA) data. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. In Dataflows & Recipes on the Recipes tab, click **Create Recipe**. 3. Click **Add Input Data**. 4. Select **sfLma**License**c**, and select all columns. 5. Create a transform named `License` with these specifications. - Custom Formula: `string(Id)` - Output Type: **Text** - Length: `255` - Default Value: `blank` - Show Results In: **New Column (and Keep Original)** - Column Label: `LicenseRecordId` 6. Add a join to Lead with these specifications. - Select Input Data to Join: **Lead** - Columns to Select: **Company**, **First Name**, **Id**, **Last Name** - Join Type: **Lookup** - Join Keys: **License: Record ID = Lead ID** - API Name Prefix for Right Columns: `Lead` 7. Add a join to Account with these specifications. - Select Input Data to Join: **Account** - Columns to Select: **Name** - Join Type: **Lookup** - Join Keys: **Account Name = Account Name** - API Name Prefix for Right Columns: `Account` 8. Add a join to sfLma**Package**c with these specifications. - Select Input Data to Join: **sfLma**Package**c** - Columns to Select: `All fields` - Join Type: **Lookup** - Join Keys: **Package = Record ID** - API Name Prefix for Right Columns: `Package` 9. Create a transform between the join and `sfLma__Package__c` with these specifications. - Custom Formula: `substr(sfLma__Package_ID__c, 1, 15)` - Output Type: **Text** - Length: `255` - Default Value: none - Show Results in: **New Column (and Keep Original)** - Column Label: `PackageID15` 10. Create another join with these specifications. - Select Input Data to Join: **sfLma**Package_Verzion**c** - Columns to Select: `All fields` - Join Type: **Lookup** - Join Keys: **Package Version = Record ID** - API Name Prefix for Right Columns: `PackageVersion` 11. Create an output with these specifications. - Write To: **Dataset** - Dataset Display Label: `LMAJoin` - App Location: **PartnerIntelligence** - Sharing Source: default - Security Predicate: **Apply row-level security to the target dataset by adding a predicate filter condition** 12. Click **Apply**. 13. Click **Save**. 14. Save your recipe as `LMAJoin`. 15. Click **Save and Run**. 16. To monitor the status of your job, click **Go to Data Monitor**. ## Example When complete, your LMAJoin CRM Analytics recipe looks like this. ![The LMAJoin CRM Analytics recipe displaying nodes, transforms, joins, and output](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_tcrm_lmajoin.png) 1. [Monitor Your LMAJoin CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-lmajoin-monitor.md) CRM Analytics recipes can take a while to complete. Use these steps to monitor the status of your LMAJoin recipe. 2. [Run the LMAJoin CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-lmajoin-schedule.md) To create a reusable dataset, schedule your LMAJoin CRM Analytics recipe to run on a regular basis. We recommend daily at midnight. **See Also** **Previous topic:** [Connect to Your License Management App Data](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-lma-data.md) **Next topic:** [Create Your App Analytics Dataset](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-prepare.md) # Create Versions of a Second-Generation Managed Package A package version is a fixed snapshot of the package contents and related metadata. The package version is an installable, immutable artifact that lets you manage changes and track what’s different each time you release or deploy a specific set of changes. Before you create a package version, first verify package details, such as the package name, dependencies, and update the versionNumber parameter in the `sfdx-project.json` file. Verify that the metadata you want to change or add in the new package version is in the package’s main directory. **tip:** Review [Advanced Project Configuration Parameters for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-adv-config-file.md) for optional features that you can enable in the new package version. When you create a package version, you have three options regarding how package validations are handled. - (Default) Complete all validations of dependencies, package ancestors, and metadata before the package version is returned. - Perform validations asynchronously. - Skip validation on the package version. **note:** If you use Claude Code in your development tools, you can create a new package version by describing what you want in natural language. For example, you can enter “Create a package version for ExamplePackage.” ## Create a Managed 2GP Package Version (Default Option) Create the package version with this command. Specify the package alias or ID (0Ho). You can also include a scratch definition file that contains a list of features and settings that the metadata of the package version depends on. ```nolang sf package version create --package "Expenser App" --installation-key “HIF83kS8kS7C” \ --definition-file config/project-scratch-def.json --code-coverage --wait 10 ``` **note:** When creating a package version, specify a `--wait` time to run the command. If the package version is created within that time, the `sfdx-project.json` file is automatically updated with the package version information. If not, you must manually edit the project file. It can be a long-running process to create a package version, depending on the package size and other variables. You can easily view the status and monitor progress. ```no_highlighting sf package version create report --package-create-request-id 08cxx00000000YDAAY ``` The output shows details about the request. ```nolang === Package Version Create Request NAME VALUE ───────────────────────────── ──────────────────── Version Create Request Id 08cB00000004CBxIAM Status InProgress Package Id 0HoB00000004C9hKAE Package Version Id 05iB0000000CaaNIAS Subscriber Package Version Id 04tB0000000NOimIAG Tag git commit id 08dcfsdf Branch CreatedDate 2024-05-08 09:48 Installation URL https://login.salesforce.com/packaging/installPackage.apexp?p0=04tB0000000NOimIAG ``` You can find the request ID (08c) in the initial output of `sf package version create`. Depending on the size of the package and other variables, the create request can take several minutes. When you have more than one pending request to create package versions, you can view a list of all requests with this command. ```nolang sf package version create list --created-last-days 0 ``` Details for each request display as shown here (IDs and labels truncated). ```nolang === Package Version Create Requests [3] ID STATUS PACKAGE2 ID PKG2 VERSION ID SUB PKG2 VER ID TAG BRANCH CREATED DATE === 08c... Error 0Ho... 08c... Success 0Ho... 05i... 04t... 2024-06-22 12:07 08c... Success 0Ho... 05i... 04t... 2024-06-23 14:55 ``` ## Async Validation Async validation creates a new package version before completing package validations. If your development team is using continuous integration (CI) scripts, you can leverage async validation to get an installable artifact sooner so you can start post-package creation steps. To specify async validation, include the - -`async-validation` parameter. ```nolang sf package version create --async-validation ``` Sample Command-Line Output ```nolang Version create.... Create version status: PerformingValidations The validations for this package version are in progress, but you can now begin testing this package version. To determine whether all package validations complete successfully, run "sf package version create report --package-create-request-id 08cxx", and review the Status. Async validated package versions can be promoted only if all validations complete successfully. Successfully created the package version [08cxx. Subscriber Package Version Id: 04txx Package Installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04txx As an alternative, you can use the "sf package:install" command. ``` The command-line output provides you a package creation request ID that starts with 08c. To confirm whether all package validations complete successfully, use the 08cxx ID when and run `sf package version create report --package-create-request-id 08cxx`. Then validate that the Status is listed as Success. Async validated package versions can be promoted only if all validations complete successfully. ## Skip Validation Skips validation of dependencies, package ancestors, and metadata during package version creation. Skipping validation significantly reduces the time it takes to create a new package version, but package versions created using skip validation can’t be promoted to the released state. ```nolang sf package version create --skip-validation ``` **note:** You can't specify both skip validation and code coverage, because code coverage is calculated during validation. You also can't specify both skip validation and async validation at the same time. ## Update Details about a Managed 2GP Package Version You can update most properties of a package version from the command line. For example, you can change the package version name or description. One important exception is that you can’t change the release status. In this example, we’re adding the tag parameter and specifying the git commit ID associated with this package version. ```nolang sf package version update --package "Expenser App@1.3.0-5" --tag "git commit id 08dcfsdf" ``` After the update is complete, you’ll see output that looks like ```nolang Successfully updated the package version. 04tB0000000KPhnIAG ``` ## How Many Managed 2GP Package Versions Can I Create Per Day? Run this command to see how many package versions you can create per day and how many you have remaining. ```nolang sf limits api display ``` Look for the Package2VersionCreates entry. ```nolang NAME REMAINING MAXIMUM ───────────────────────────────────── ───────── ───────── Package2VersionCreates 23 50 ``` # Create Your AgentExchange Listing Market your solution or consulting service to Salesforce customers with a listing on AgentExchange. Use the Listing Builder in the Partner Console to create a listing that stands out to customers. # Create Your App Analytics Dataset Create a RawPackageLogFile App Analytics dataset using your `RawPackageLogFile.csv` file. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Create** and select **Dataset**. 2. Click **CSV File** and select your `RawPackageLogFile.csv` file. 3. Click **Next**. 4. Name your dataset `RawPackageLogFile` and select your **PartnerIntelligence** app. 5. Click **Next**. 6. For **event_count**, **num_fields**, **num_soql_queries**, **operation_count**, and **rows_processed** fields, change the field type from **Dimension** to **Measure** and add these specifications. - Default value: `0` - Scale: `0` - Precision: `18` 7. Search for **timestamp_derived** and make sure that its field type is **Date**. 8. Click **Upload File**. # Create Your Consultant Listing 1. In the Partner Console, click **Listings**, then click **New Listing**. 2. Select **Consultant**. 3. Choose your listing language. The language you select determines which language appears on your listing and which site your listing is published to (AgentExchange or AgentExchange Japan). If your business operates across multiple regions, create a separate listing for each language to publish to its respective site. For example, you may provide offerings in both English and Japanese practices. ## Enter Key Listing Information Fill in the information that makes up your listing’s first impression. 1. Enter a listing title. Use a concise description of your services. 2. Write a tagline. Taglines are short subtitles that appear below your title on the listing tile. 3. Write brief and full descriptions. Focus on the outcomes you deliver for customers, not just the services you offer. Describe what problems you solve, for whom, and what makes your approach different. **important:** Your description is the primary content customers use to evaluate whether to contact you. A vague or generic description reduces your chances of generating leads. ### Add More Details Provide additional information that helps customers evaluate your business. - Define the languages your firm supports. - Upload media: screenshots, demo videos, or case study documents. - Add your company logo. ### Configure the Learn More URL The **Learn More** URL is required for consultant listings. When a customer clicks Learn More on your listing, they land on this page. **warning:** The Learn More button is the only call-to-action on your consultant listing. If this URL leads to a broken page, a generic homepage, or a 404 error, you’ve shut down the customer’s evaluation path of your firm from AgentExchange. Point your Learn More URL to a dedicated landing page that gives the customer a clear next step. Example pages include: - A contact form. - A consultation scheduling link. - A request-for-proposal page. Don’t use: - Your company homepage, which forces the customer back into discovery. - A URL that returns a 404 or 503 error. - A page with no clear customer action. Audit this URL regularly. If it becomes stale, you lose leads without any notification. ### Enable Lead Collection In the **Grow Your Business** step of the listing builder, you can turn on AgentExchange lead collection. When enabled, AgentExchange captures lead information when customers click Learn More and delivers it to the Salesforce org you specify. **important:** If you choose not to enable lead collection, the endpoint website from your Learn More URL becomes your only lead pipeline from AgentExchange. Make sure that the URL points to a page where customers can take action and contact you directly. To enable lead collection: 1. In the listing builder, go to the **Grow Your Business** step. 2. Enter your 18-digit Salesforce Org ID. 3. Select the lead types you’d like to collect. 4. Go to your Salesforce Org and confirm it is configured to receive leads: - Web-to-Lead is enabled. - reCAPTCHA is turned off. - Duplicate and matching rules are set to allow leads from AgentExchange. # Create Your DailyAggregation CRM Analytics Recipe You join your raw package log file data with your License Management App (LMA) data to create the DailyAggregation CRM Analytics recipe. The recipe produces a dataset called DailyAggregation that you use to create App Analytics recipes. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Dataflows & Recipes**. 3. On the Recipes tab, click **Create Recipe**. 4. Click **Add Input Data**. 5. Select **RawPackageLogFile**. 6. Select all the columns. 7. Create an aggregate with these specifications. | Field | Aggregate By | | ------------------ | ------------ | | `event_count` | `Sum` | | `login_key` | `Unique` | | `num_fields` | `Sum` | | `num_soql_queries` | `Sum` | | `operation_count` | `Sum` | | `rows_processed` | `Sum` | | `session_key` | `Unique` | 8. In the aggregate, in Group Rows, click **+**, and select **timestamp_derived**. 1. Select **Year**, **Month**, and **Day**. 2. Click **Add**. 9. In the aggregate, in Group Rows, create a group for each of these fields. - **api_type** - **api_version** - **app_name** - **class_name** - **cloned_from_organization** - **custom_entity** - **custom_entity_type** - **entry_point** - **event** - **event_subscriber** - **http_method** - **http_status_code** - **log_record_type** - **managed_package_namespace** - **method_name** - **operation_type** - **organization_country_code** 10. Create a transform named `Create DMY Field` with this formula.`to_date(concat(timestamp_derived_DAY,"/",timestamp_derived_MONTH,"/",timestamp_derived_YEAR),"dd/MM/yyyy"))` 11. Join your RawPackageLogFile dataset to your LMAData dataset using this information. - Select Input Data to Join: **LMAData** - Columns to Select: `All fields` - Join Type: **Lookup** - Join Keys: **organization_id = Subscriber Org ID** and **package_id = PackageID15** - API Name Prefix for Right Columns: `LMAData` 12. Join your country-codes dataset to your LMAData dataset using this information. - Select Input Data to Join: **country-codes** - Columns to Select: `All fields` - Join Type: **Lookup** - Join Keys: **user_country_code = ISO3166-1-Alpha-2** - API Name Prefix for Right Columns: `UserCountry` 13. Create a transform named `Feature Name`. 1. Create as many CRM Analytics buckets as you need for your features, such as Inventory, Orders, and a catch-all bucket called Other. 2. **note:** A CRM Analytics bucket represents a category that you use to group your data. For example, say your app contains multiple features, such as an inventory tracking feature and an order processing feature. Create a CRM Analytics bucket for each feature. Each bucket contains the custom objects, pages, Lightning components, and Apex classes that pertain to that feature. You can use these buckets to create Feature Adoption App Analytics recipes Add your custom entities to the appropriate bucket. 14. Select **Output** and use these settings. - Write To: **Dataset** - Dataset Display Label: `DailyAggregation` - App Location: **PartnerIntelligence** - Sharing Source: default - Security Predicate: **Apply row-level security to the target dataset by adding a predicate filter condition** - Name: `Create Daily Aggregation Dataset` 15. Click **Apply**. 16. Click **Save**. 17. Name your recipe `DailyAggregation`. 18. Click **Save and Run**. ## Example When complete, your DailyAggregation recipe looks like this. ![The DailyAggregation CRM Analytics recipe with LMAData, country-codes, RawPackageLogFile datasets, aggregations, and transformations](https://developer.salesforce.com/media/pkg2_dev/app_analytics_cookbook_tcrm_da_recipe.png) 1. [Monitor the DailyAggregation CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-monitor.md) CRM Analytics recipes can take a while to complete. Use these steps to monitor the status of your DailyAggregation recipe. 2. [Run the DailyAggregation CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-schedule.md) To create a reusable dataset, schedule your DailyAggregation CRM Analytics recipe to run on a regular basis. We recommend daily at midnight. **See Also** **Previous topic:** [Create Your App Analytics Dataset](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-prepare.md) # CRM Analytics Asset Interactions Each record in your package usage log that has a `custom_entity_type` of `AnalyticsDashboard`, `AnalyticsLens`, or `AnalyticsRecipe` describes an interaction with your packaged CRM Analytics assets. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | ## Analytics Asset Runs To analyze a run of your CRM Analytics asset, look for a `log_record_type` of `AnalyticsAssetRun`. | Standard Data | Supplemental Data | | ------------- | ----------------- | | none | none | ## Analytics Asset Views To analyze a view of your CRM Analytics asset, look for a `log_record_type` of `AnalyticsAssetView`. | Standard Data | Supplemental Data | | ------------- | ----------------- | | none | none | ## Example Let’s look at an example package usage log record and analyze the CRM Analytics asset interaction. ```nolang { "timestamp_derived": "2022-11-22T06:19:49.820Z", "log_record_type": "AnalyticsAssetView", "request_id":"4mbhvyfahFf83tlq2Z5aAk", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=", "user_type": "Standard", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "ClaimsDashboard", "custom_entity_type": "AnalyticsDashboard", "session_key": "2l4YtFB/RmsRKVsS", "login_key": "fGV6RgVOH3ZCgl2v", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "US", "user_time_zone": "America/Los_Angeles" } ``` The packaged Analytics dashboard, `ClaimsDashboard`, was interacted with by a standard user from the subscriber org `MyCustom Inc.` Specifically, the user performed a view of `ClaimsDashboard` on 2022-11-22 at 6:19am UTC. The key data in this analysis are: | Question | Field | Value | | -------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | What |
  • `custom_entity`
  • `custom_entity_type`
  • `package_version_id`
  • `managed_package_namespace`
|
  • `ClaimsDashboard`
  • `AnalyticsDashboard`
  • `04txx0000004Idi`
  • `Acme`
| | Who |
  • `organization_id`
  • `user_id_token`
|
  • `00Dxx0000006H2l`
  • `005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=`
| | How | `log_record_type` | `AnalyticsAssetView` | | When | `timestamp_derived` | `2022-11-22T06:19:49.820Z` | **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) - [CRM Analytics Developer Center](https://developer.salesforce.com/developer-centers/crm-analytics) # CRM Analytics Recipes Set up your org to create AgentExchange App Analytics recipes by building your CRM Analytics environment. You first create a country-codes dataset. Then you create two CRM Analytics recipes to produce a dataset of your subscriber info, and an aggregate dataset of all of your daily data. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | - The first CRM Analytics recipe, LMAJoin, combines package and license data from your LMA with your accounts and leads. It produces a dataset of your subscribers. - The second CRM Analytics recipe, DailyAggregation, joins the LMAJoin dataset with your App Analytics data. It produces the DailyAggregation dataset. All your App Analytics recipes are built on top of your DailyAggregation dataset. 1. [Create the Country-Codes Dataset](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-country-codes.md) To create visualizations of your country-based data in map format, you normalize the LMA country-code data to CRM Analytics country-code format. 2. [Connect to Your License Management App Data](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-lma-data.md) Create an SFDC_Local connection to your License Management App (LMA) data. 3. [Create the LMAJoin CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-lmajoin.md) Create a CRM Analytics recipe that contains your License Management App (LMA) data. 4. [Create Your App Analytics Dataset](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-prepare.md) Create a RawPackageLogFile App Analytics dataset using your `RawPackageLogFile.csv` file. 5. [Create Your DailyAggregation CRM Analytics Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-tcrm-da-recipe-detail.md) You join your raw package log file data with your License Management App (LMA) data to create the DailyAggregation CRM Analytics recipe. The recipe produces a dataset called DailyAggregation that you use to create App Analytics recipes. **See Also** **Previous topic:** [Before You Begin](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-prework.md) **Next topic:** [App Analytics Recipes](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-intro.md) - [Explore Data and Take Action with CRM Analytics](https://help.salesforce.com/articleView?id=analytics.bi.htm&type=5) # Custom Branding for Trialforce If you use Trialforce, you can optionally set up a branded login site and emails. By applying your company’s look and feel to a login site and emails, customers are immersed in your brand from signup to log in. Apply custom branding only for non-CRM solutions. Don’t apply it to solutions that extend Salesforce CRM and require standard objects, such as Leads, Opportunities, and Cases. |Required Editions| |-----------------| |Available in: Salesforce Classic| |Available in: **Developer** Edition| |User Permissions Needed| | |-----------------------|--| |To manage Trialforce:|Customize Application| With a branded login page, you can specify your login domain and login site. - A login domain ends with `.cloudforce.com`, so if your company name is “mycompany,” your login domain is `mycompany.cloudforce.com`. - Your custom login site includes your text and company logo and a mobile-friendly version of your login site. With branded emails, you can specify fields in system-generated emails so that your company name, address, and other details are used in email correspondence. You can create multiple branded email sets for different campaigns or customer segments. Branding isn’t available for Trialforce Source Orgs created in the Environment Hub. # Custom Interactions To understand which features and UI components a subscriber interacted with and how they flow through a user journey, create custom interactions with Apex enums and the `IsvPartners.AppAnalytics.logCustomInteraction` Apex method. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | Standard Data | Supplemental Data | | ------------------------------------------------------------------------------------------------------- | ----------------- | |
  • `class_name`
  • `method_name`
  • line_number
  • `interaction_id_token`
| `api_version` | ## Successful Custom Interactions To analyze a custom interaction with your packaged components, look for a `log_record_type` of `CustomInteraction` and a `custom_entity_type` of `CustomInteractionLabel`. The `custom_entity` contains a custom interaction label that you created and that was logged. **note:** `interaction_id_token` is included only if an `interaction_id` was provided to the associated `IsvPartners.AppAnalytics.logCustomInteraction` call. `interaction_id_token` is a hashed, tokenized version of the raw interaction id that was provided. ## Unsuccessful Custom Interactions When `custom_entity_type` is equal to CustomInteractionFailure then the custom interaction couldn’t be logged. To determine the reason for the failed logging, review the reason code provided by the `custom_entity` value. | custom_entity | Message | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `LABEL_NO_NAMESPACE` | We couldn’t log the custom interaction with App Analytics. The interaction label provided to `IsvPartners.AppAnalytics.logCustomInteraction` must have a namespace. | | `LABEL_NOT_ENUM` | We couldn’t log the custom interaction with App Analytics. The interaction label provided to `IsvPartners.AppAnalytics.logCustomInteraction` must be an Apex enum. | | `LABEL_WRONG_NAMESPACE` | We couldn’t log the custom interaction with App Analytics. The interaction label provided to `IsvPartners.AppAnalytics.logCustomInteraction` must have the same namespace as the Apex code that called the method. | | `OVER_CALL_LIMIT` | `IsvPartners.AppAnalytics.logCustomInteraction` was called too many times in a single user request. This custom interaction and subsequent ones for this user request weren’t logged with App Analytics. | ## Example Let’s look at an example package usage log record and analyze a successful Apex interaction. ```nolang { "timestamp_derived": "2023-09-20T06:17:39.167Z", "log_record_type": "CustomInteraction", "request_id": "TID:7635077000004b3035", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=", "user_type": "Standard", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "MyInteractionLabels.LoginButtonClicked", "custom_entity_type": "CustomInteractionLabel", "session_key": "2l4YtFB/RmsRKVsS", "login_key": "fGV6RgVOH3ZCgl2v", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "US", "user_time_zone": "America/Los_Angeles", "class_name": "Acme.MyController", "method_name": "loginButtonCallback", "line_number": 56, "interaction_id_token": "7NDe8HM8ZgPdBL+jiOpTW3/xKTwwL30dyxmKNxtyzi8=" } ``` The `MyInteractionLabels.LoginButtonClicked` custom interaction label was logged as a custom interaction as a result of a user action from subscriber org MyCustomer Inc on 2023-09-20 at 6:17 am. Specifically, the user interaction resulted in logging a custom interaction from line number 56 of the `loginButtonCallback` method found in the `Acme.MyController` Apex class. In addition to the `InteractionLabels.LoginButtonClicked` label, an interaction ID was provided to the log call resulting in an interaction token id value of `7NDe8HM8ZgPdBL+jiOpTW3/xKTwwL30dyxmKNxtyzi8=`. The key data in this analysis are: | Question | Field | Value | | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | What |
  • `class_name`
  • `custom_entity`
  • `custom_entity_type`
  • `package_version_id`
  • `managed_package_namespace`
  • `class_name`
  • `method_name`
  • `line_number`
  • `interaction_id_token`
|
  • `Acme.MyController`
  • `MyInteractionLabels.LoginButtonClicked`
  • `CustomInteractionLabel`
  • `04txx0000004Idi`
  • `Acme`
  • `loginButtonCallback`
  • `56`
  • `7NDe8HM8ZgPdBL+jiOpTW3/xKTwwL30dyxmKNxtyzi8=`
| | Who |
  • `organization_id`
  • `user_id_token`
|
  • `00Dxx0000006H2l`
  • `005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=`
| | How | `log_record_type` | `CustomInteraction` | | When | `timestamp_derived` | `2023-09-20T06:17:39.167Z` | **See Also** - [Download Package Usage Logs, Package Usage Summaries, and Subscriber Snapshots](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-download-mp-logs.md) - [Considerations for Custom Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-interactions.md) # Custom Object and External Object Interactions When a log record in your package usage log has `custom_entity_type` equal to `CustomObject` or `ExternalObject`, it means that a user performed an action that resulted in a create, read, update, or delete (CRUD) interaction on your object. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | To determine the type and amount of CRUD that occurred on your packaged component, focus on: - `operation_type` - `operation_count` Many user actions result in CRUD, such as platform events, Apex REST API requests, or scheduled job executions. Each action is related to a `log_record_type`, and each log record has some standard fields that are always populated with data. For example, an Apex REST API request with a `log_record_type` of `ApexRestApi` always has `url`, `api_version`, `http_method`, and `http_status_code` data. Many actions produce log records with supplemental fields that are often populated. For example, an Apex REST API request sometimes has `request_status`, `referrer_uri`, and `api_type` data. ## CRUD from Apex REST API Requests To analyze an Apex REST API request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `ApexRestApi`. Then use these fields to dig into the details of the Apex REST API interaction. | Standard Data | Supplemental Data | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
  • `url`
  • `api_version`
  • `http_method`
  • `http_status_code`
|
  • `request_status`
  • `referrer_uri`
  • `api_type`
  • `rows_processed`
  • `request_size`
  • `response_size`
  • `num_fields`
| ## CRUD from Apex SOAP API Requests To analyze an Apex SOAP API request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `ApexSoap`. Then use these fields to explore the details of the Apex SOAP API interaction. | Standard Data | Supplemental Data | | -------------------------------------------------------------------------- | ----------------------------------------------------------------------- | |
  • `api_version`
  • `class_name`
  • `method_name`
|
  • `url`
  • `request_status`
  • `referrer_uri`
| ## CRUD from REST API Requests To analyze a REST API request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `RestApi`. Then use these fields to understand the details of the REST API interaction. | Standard Data | Supplemental Data | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
  • `url`
  • `api_version`
  • `http_method`
  • `http_status_code`
|
  • `request_status`
  • `referrer_uri`
  • `api_type`
  • `rows_processed`
  • `request_size`
  • `response_size`
  • `num_fields`
| ## CRUD from SOAP API Requests To analyze a SOAP API request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `API`. Then use these fields to uncover the details of the SOAP API interaction. | Standard Data | Supplemental Data | | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | |
  • `api_type`
  • `api_version`
  • `request_size`
  • `response_size`
  • `method_name`
|
  • `url`
  • `request_status`
  • `request_uri`
  • `rows_processed`
  • `num_fields`
| ## CRUD from Bulk API Requests To analyze a Bulk API request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `BulkApiV1` or `BulkApiV2`. Then use these fields to discover the details of the Bulk API interaction. | Standard Data | Supplemental Data | | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------- | |
  • `api_version`
  • `bulk_job_id`
  • `bulk_batch_id`
  • `bulk_operation`
|
  • `api_type`
  • `rows_processed`
| ## CRUD from Scheduled Job Executions To analyze a scheduled job execution that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `CronJob`. There are no additional package usage log fields to describe scheduled job executions. | Standard Data | Supplemental Data | | ------------- | ----------------- | | none | none | ## CRUD from Platform Events To analyze a platform event that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `PlatformEventConsumer`. Then use these fields to discover the details of the platform event. | Standard Data | Supplemental Data | | ------------- | -------------------------------------------------------------------------- | | none |
  • `event`
  • `event_subscriber`
  • `event_count`
| ## CRUD from Queueable Apex Executions To analyze a queueable Apex execution that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `QueuedExec`. There are no additional package usage log fields to describe Apex executions. | Standard Data | Supplemental Data | | ------------- | ----------------- | | none | none | ## CRUD from Standard User Interface Requests To analyze a user interaction that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `URI`. Then use these fields to discover the details of the user interaction. | Standard Data | Supplemental Data | | ------------- | --------------------------------------------------------- | | `url` |
  • `request_status`
  • `referrer_uri`
| ## CRUD from Visualforce Remoting Requests To analyze a Visualforce Remoting request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `VFRemoting`. Then use these fields to explore the details of the Visualforce Remoting request. | Standard Data | Supplemental Data | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | |
  • class_name
  • method_name
|
  • `url`
  • `request_status`
  • `referrer_uri`
  • `request_size`
  • `response_size`
| ## CRUD from Visualforce Requests To analyze a Visualforce request that resulted in a CRUD operation on your packaged component, look for a `log_record_type` of `VisualforceRequest`. Then use these fields to explore the details of the Visualforce request. | Standard Data | Supplemental Data | | ------------- | -------------------------------------------------------------------------------------------------------- | | `url` |
  • `request_status`
  • `referrer_uri`
  • `request_size`
  • `response_size`
| ## CRUD from All Other User Actions To analyze any other user action that results in a CRUD operation on your packaged component, look for a `log_record_type` of `UnassociatedCRUD`. There are no additional package usage log fields to describe all other interactions. | Standard Data | Supplemental Data | | ------------- | ----------------- | | none | none | ## Example Let’s look at an example package usage log record and analyze the custom or external object interaction. ```nolang { "timestamp_derived": "2022-12-15T05:47:35.945Z", "log_record_type": "VFRemoting", "request_id": "4mbhuJkvJ7Q83tlq2Z5aAk", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-rBBA92863JO8GJN3pT75gp0cG8a9z1vpH6MOti/359o=", "user_type": "Standard", "url":"uwlNmuT1+gH+xKq+xCoxiaAyOOhw8B4WLeQXAbgx+mA=", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "Insurance_Agent", "custom_entity_type": "CustomObject", "operation_type": "INSERT", "operation_count": 2, "session_key": "9/uZ+soHD+0UqKYt", "login_key": "5tjyGvX04w06xFgT", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "IN", "user_time_zone": "Asia/Kolkata", "class_name": "shwGCoJjDrkhbw+CY4TFzVxFWypN07UGvtGkexbj/y4=", "method_name": "3/UbV0E5yIW8a3c2Fb2XXjfWse1MUekEZWX44tp5TJs=" } ``` The `Insurance_Agent` packaged component of type `CustomObject` had CRUD performed as a result of a user action from the subscriber org `My Customer Inc.` Specifically, two records were inserted during a Visualforce Remoting request that the user performed at 2022-12-15 at 05:47 am UTC. The key data in this analysis are: | Question | Field | Value | | -------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | What |
  • `custom_entity`
  • `custom_entity_type`
  • `package_version_id`
  • `managed_package_namespace`
|
  • `Insurance_Agent`
  • `CustomObject`
  • `04txx0000004Idi`
  • `Acme`
| | Who |
  • `organization_id`
  • `user_id_token`
|
  • `00Dxx0000006H2l`
  • `005-rBBA92863JO8GJN3pT75gp0cG8a9z1vpH6MOti/359o=`
| | How | `log_record_type` | `VFRemoting` | | How Much |
  • `operation_type`
  • `operation_count`
|
  • `INSERT`
  • 2
| | When | `timestamp_derived` | `2022-12-15T05:47:35.945Z` | In this example, the Visualforce Remoting code isn’t owned by the package, so `url`, `class_name`, and `method_name` are tokenized. ```nolang "url": "uwlNmuT1+gH+xKq+xCoxiaAyOOhw8B4WLeQXAbgx+mA=", "class_name": "shwGCoJjDrkhbw+CY4TFzVxFWypN07UGvtGkexbj/y4=", "method_name": "3/UbV0E5yIW8a3c2Fb2XXjfWse1MUekEZWX44tp5TJs=" ``` If the Visualforce Remoting code is part of the package, you see actual values instead of tokens. **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) # Custom Object Usage Recipes Understanding how your customers use your custom objects is critical to managing the lifecycle of your managed package and its custom objects. Start by measuring custom object usage by create, read, update, and delete (CRUD) operations. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | - **[Create a Custom Object Creates Per Day Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-cou-dailycreates.md)** This recipe produces a unique count of how many times per day a custom object was created. - **[Create a Custom Object Updates Per Day Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-cou-dailyupdates.md)** This recipe produces a unique count of how many times per day a custom object was created. - **[Create a Custom Object Reads Per Day Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-cou-dailyreads.md)** This recipe produces a unique count of how many times per day a custom object was read. # Custom Profile Settings Create profiles to define how users access objects and data, and what they can do within your app. For example, profiles specify custom object permissions and the tab visibility for your app. When installing or upgrading your app, admins can associate your custom profiles with existing non-standard profiles. Permissions in your custom profile that are related to new components created as part of the install or upgrade are added to the existing profile. The security settings associated with standard objects and existing custom objects in an installer’s organization are unaffected. Consider these tips when creating custom profiles for apps you want to publish. - Give each custom profile a name that identifies the profile as belonging to the app. For example, if you’re creating a Human Resources app named “HR2GO,” a good profile name would be ”HR2GO Approving Manager.” - If your custom profiles have a hierarchy, use a name that indicates the profile’s location in the hierarchy. For example, name a senior-level manager’s profile ”HR2GO Level 2 Approving Manager.” - Avoid custom profile names that can be interpreted differently in other organizations. For example, the profile name ”HR2GO Level 2 Approving Manager” is open to less interpretation than ”Sr. Manager.” - Provide a meaningful description for each profile. The description displays to the user installing your app. Alternatively, you can use permission sets to maintain control of permission settings through the upgrade process. Permission sets contain a subset of profile access settings, including object permissions, field permissions, Apex class access, and Visualforce page access. These permissions are the same as those available on profiles. You can add a permission set as a component in a package. **note:** In packages, assigned apps and tab settings aren’t included in permission set components. # Customer Success Recipes Customer success is a relationship-focused method of ensuring that your customers achieve their desired outcomes while using your managed packages. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | To measure customer success, you can create metrics that help you understand: - Overall managed package usage - Depth of managed package usage - Growth - Length of time as a customer - Number of renewals - Number of upsells - Overall relationship As you learn more about your customers and how they use your managed packages, your list of customer success metrics expands. To analyze user behavior, we rely on user-related and CRUD (create, read, update, and delete) App Analytics data fields to calculate metrics. All user behavior calculations rely on how a unique user is defined. - An individual that has used your managed package and its components - Measured for a specified time period, such as a day, month, or year An active user can be defined as: A user who has logged some type of package usage, such as CRUD activity, page views, or Lightning interactions, during a specified time period. Segment the unique and active users by time period, such as day, month, or quarter. - **[Create a Daily Unique Users Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-csm-dailyuu.md)** This recipe produces a unique count of users by day. - **[Create a Weekly Unique Users Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-csm-weeklyuu.md)** This recipe produces a unique count of users by week. - **[Create a Monthly Unique Users Recipe](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook-recipe-csm-monthlyuu.md)** This recipe produces a unique count of users by month. # Customize Second-Generation Managed Package Installs and Uninstalls Using Scripts Customize a second-generation managed package (managed 2GP) install or upgrade by specifying an Apex post install script to run automatically after a subscriber installs or upgrades a managed 2GP package. You can also specify an Apex uninstall script to run automatically when a subscriber uninstalls a managed 2GP package. For more information, see [Run Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/apex_post_install_script.htm) and [Run Apex on Package Uninstall](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/apex_uninstall_script.htm). Specify post install and uninstall scripts in the `sfdx-project.json` file. ```nolang "packageDirectories": [ { "path": "expenser-schema", "default": true, "package": "Expense Schema", "versionName": ""ver 0.3.2"", "versionNumber": "0.3.2.NEXT", "postInstallScript": "PostInstallScript", "uninstallScript": "UninstallScript", "postInstallUrl": "https://expenser.com/post-install-instructions.html", "releaseNotesUrl": "https://expenser.com/winter-2020-release-notes.html" }, ], { "namespace": "db_exp_manager", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "47.0", "packageAliases": { "Expenser Schema": "0HoB00000004CzHKAU", "Expenser Schema@0.1.0-1": "04tB0000000719qIAA" } ``` You can also use the `--post-install-script` and the `--uninstall-script` Salesforce CLI parameters with the `sf package version create` command. The CLI parameters override the scripts specified in the `sfdx-project.json file`. **note:** Include the Apex classes for your post-install and uninstall scripts with the metadata in your package. You can designate an active Dev Hub org user to receive email notifications for Apex gacks, and install, upgrade, or uninstall failures associated with your packages. In Salesforce CLI run `sf package create --error-notification-username me@devhub.org` or `sf package update --error-notification-username me@devhub.org`. In Tooling API, use the PackageErrorUsername field on the Package2 object. # Define an SSO User Mapping You can manually define a single-sign on (SSO) user mapping between a user in the Environment Hub and a user in a member org. Before you define a user mapping, enable SSO in the hub member org. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure the Environment Hub:|Manage Environment Hub| User mappings can be many-to-one but not one-to-many. In other words, you can associate multiple users in the Environment Hub to one user in a member org. For example, if you wanted members of your QA team to log in to a test org as the same user, you could define user mappings. ## Steps 1. Log in to the Environment Hub, and then select a member org. If you don’t see any member orgs, check your list view. 2. Go to the Single Sign-On User Mappings related list, and then select **New SSO User Mapping**. 3. Enter the username of the user that you want to map in the member org, and then look up a user in the Environment Hub. 4. Select **Save**. # Delete a Second-Generation Managed Package or Package Version Use the `sf package version delete` and `sf package delete` commands to delete packages and package versions that you no longer need. To delete a package or package version, users need the Delete Second-Generation Packages user permission. Before you delete a package, first delete all associated package versions. | Package Type | Can I delete beta packages and package versions? | Can I delete released packages and package versions? | | ---------------------------------- | ------------------------------------------------ | ---------------------------------------------------- | | Second-Generation Managed Packages | Yes | No | | Unlocked Packages | Yes | Yes | **Considerations for Deleting a Package or Package Version** - Deletion is permanent. - Attempts to install a deleted package version will fail. - Before deleting, ensure that the package or package version isn’t referenced as a dependency. **Examples:** ```nolang $ sf package delete -p "Your Package Alias" ``` ```nolang $ sf package delete -p 0Ho... ``` ```nolang $ sf package version delete -p "Your Package Version Alias" ``` ```nolang $ sf package version delete -p 04t... ``` These CLI commands can’t be used with first-generation managed packages or package versions. To delete a first-generation managed package, see [View Package Details](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/isv_viewing_package_details.htm)in the _First-Generation Managed Packaging Developer Guide_. # Delete Components from First-Generation Managed Packages After you've uploaded a Managed - Released first-generation managed package, you may find that a component needs to be deleted from your packaging org. One of the following situations may occur: - The component, after it’s added to a package, can't be deleted. - The component can be deleted, but can only be undeleted from the Deleted Package Components page. - The component can be deleted, but can be undeleted from either the Deleted Package Components page or through the Recycle Bin After a package is uploaded with a component marked for deletion, the component is deleted forever. **note:** When a component is deleted, its **Name** remains within Salesforce, and you can’t create a new component that uses the deleted component’s name. The Deleted Package Components page lists the names that can no longer be used. To access the Deleted Package Components page, from Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. Select the package that the component was uploaded to, and then click **View Deleted Components**. You can retrieve components from the Recycle Bin and Deleted Package Components page any time _before_ uploading a new version of the package. To do this, click **Undelete** next to the component. You can retrieve these types of components. - Apex classes and triggers that don't have `global` access. - Visualforce components with `public` access. (If the ability to remove components has been enabled for your packaging org then these Visualforce components can’t be undeleted. As a result, they don’t show up in the Recycle Bin or the Deleted Package Components page after they’ve been deleted.) - Protected components, including: - Custom labels - Custom links (for Home page only) - Custom metadata types - Custom permissions - Custom settings - Workflow alerts - Workflow field updates - Workflow outbound messages - Workflow tasks - Workflow flow triggers The pilot program for flow trigger workflow actions is closed. If you've already enabled the pilot in your org, you can continue to create and edit flow trigger workflow actions. If you didn't enable the pilot in your org, use Flow Builder to create a record-triggered flow, or use Process Builder to launch a flow from a process. - Data components, such as Documents, Dashboards, and Reports. These components are the only types that can also be undeleted from the Recycle Bin. You can retrieve components from the Recycle Bin and Deleted Package Components page any time _before_ uploading a new version of the package. To do this, click **Undelete** next to the component. The Deleted Components displays the following information (in alphabetical order): | Attribute | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Action | If the Managed - Released package hasn't been uploaded with the component deleted, this contains an **Undelete** link that allows you to retrieve the component. | | Available in Versions | Displays the version number of the package in which a component exists. | | Name | Displays the name of the component. | | Parent Object | Displays the name of the parent object a component is associated with. For example, a custom object is the parent of a custom field. | | Type | Displays the type of the component. | # Deliver Trials on AgentExchange with Test Drives Use test drives to deliver free trials of your AgentExchange solution in read-only Salesforce orgs that include sample data. Create a test drive org in Environment Hub using a preconfigured Trialforce template. Then install your solution in the test org, configure it, and connect it to the AgentExchange Partner Console. If a test drive org expires soon, log a case to request an extension. # Deliver Trials on AgentExchange with Trialforce Use Trialforce to deliver free trials of your AgentExchange solution in Salesforce orgs that customers can keep and customize. Learn Trialforce key concepts, relationships, and best practices. Then set up Trialforce, create a Trialforce template for your solution, and add it to your AgentExchange listing. # Deploy the Package Metadata to the Packaging Org Before you deploy the package metadata into your packaging org, you convert from source format to metadata format. ## Before You Begin It’s likely that you have some files that you don’t want to convert to metadata format. Create a `.forceignore` file to indicate which files to ignore. 1. Convert from source format to the metadata format. `sf project convert source --output-dir mdapi_output_dir --package-name managed_pkg_name` Create the output directory in the root of your project, not in the package directory. If the output directory doesn’t exist, it’s created. Be sure to include the `--package-name` so that the converted metadata is added to the managed package in your packaging org. 2. Review the contents of the output directory. `ls -lR mdapi_output_dir` 3. Authenticate the packaging org, if needed. This example specifies the org with an alias called MyPackagingOrgAlias, which helps you refer to the org more easily in subsequent commands. `sf org login web --alias MyPackagingOrgAlias` You can also authenticate with an OAuth client ID: `sf org login web --client-id oauth_client_id` 4. Deploy the package metadata back to the packaging org. `sf project deploy start --metadata-dir mdapi_output_dir --target-org me@example.com` The `--target-org` is the username. Instead of the username, you can use `-u MyPackagingOrgAlias` to refer to your previously defined org alias. You can use other options, like `--wait` to specify the number of minutes to wait. Use the `--metadata-dir` parameter to provide the path to a zip file that contains your metadata. Don’t run tests at the same time as you deploy the metadata. You can run tests during the package upload process. A message displays the job ID for the deployment. 5. Check the status of the deployment. When you run `sf project deploy report`, the job ID and target username are stored, so you don’t have to specify these required parameters to check the status. These stored values are overwritten when you run `sf project deploy start` again. If you want to check the status of a different deploy operation, specify the job ID on the command line, which overrides the stored job ID. **See Also** - [_Salesforce CLI Command Reference_](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference) - [How to Exclude Source When Syncing or Converting](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/How to Exclude Source When Syncing or Convertinghttps://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_exclude_source.htm) # Designate Contacts for Your AgentExchange Business Share email addresses for the people and teams that manage the business, marketing, and technical aspects of your AgentExchange business. The email addresses that you provide are visible to Salesforce only. They don't appear on your AgentExchange listings. We email the appropriate contacts to share info that’s relevant to your AgentExchange business. Whenever possible, provide a group email address. Because group addresses aren’t tied to individual employees, you don’t have to update your AgentExchange contact information if there's a change in personnel. 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Company Info**. 3. In the Internal Contact Details section, enter email addresses for all contacts. - To provide a point of contact for AgentExchange business details, such as legal items or pricing info, enter an email address in the Business Contact field. - To provide a point of contact for news that’s relevant to your marketing team, such as updates that we’re making to AgentExchange, enter an email address in the Marketing Contact field. - To provide a point of contact for questions about the technical aspects of your solution, or if we don’t get a response after emailing your security review contact, enter an email address in the Technical Contact field. - To provide a point of contact for your solutions’ security reviews, such as a status change, or for Salesforce to notify you that a solution is due for re-review, enter an email address in the Security Review Contact field. We use this address to prepopulate the backup-contact email address in the security review wizard. 4. Save your changes. # Designing Your App to Support Multiple Editions Supporting multiple editions provides the opportunity to release richer versions of your app that can support more advanced features found in EE, UE, and PXE. There are two technologies that can be leveraged to support multiple editions. The first approach uses extension packages and the second leverages Dynamic Apex. There are benefits to both, so be sure to review both strategies before designing your app. # Determine What Packaged Component Was Accessed To analyze a package usage log record, always start with your packaged component. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In App Analytics package usage logs, the name of each packaged component is represented by the `custom_entity` field and its type is represented by the `custom_entity_type` field. Your managed package likely contains multiple packaged components. - To identify each packaged component uniquely, combine these fields. - `package_id` - `package_version_id` - `managed_package_namespace` - `custom_entity` - `custom_entity_type` # 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. **important:** You can't create packageable agent templates from agents that use Agent Script as their blueprint. Workflow for Agent Template Development ![Six squares of text showing the agent template workflow](https://developer.salesforce.com/media/pkg2_dev/pkg_agent_template_workflow.png) ## Agent and Agent Template Metadata To package an agent template, it helps to first understand the metadata types that make up an agent and an agent template. Agents are defined by these major metadata types. - Bot - BotVersion - GenAiPlannerBundle The GenAiPlannerBundle type in turn defines the agent's actions and subagents. The `agent generate template` Salesforce CLI command brings together the metadata files for these three types and generates a BotTemplate file for a specific agent (Bot and BotVersion). The command also generates a new GenAiPlannerBundle file, which is different from the original file. Specifically, the new packageable GenAiPlannerBundle file replaces references to the local version of assets (which can't be packaged) with references to their global equivalents. You then use the BotTemplate file, and the new GenAiPlannerBundle file, to package the agent template in a managed package. ![Compare the MD types for agent MD with the agent template MD types](https://developer.salesforce.com/media/pkg2_dev/pkg_agent_metadata.png) ## Create an Agent Create and test your agent. ## Before You Begin From Setup in your scratch org, enter `Agents` in the Quick Find box, and select **Agentforce Agents**. Then locate and enable the **Agentforce** setting and refresh the page. 1. Click **New Agent**, and then select an agent type. 2. Follow the guided setup steps, and then click **Create**. ## Next Steps For more guidance, see the [documentation](https://help.salesforce.com/s/articleView?id=ai.agent_setup_explore_types.htm) for the agent type you chose. For details about creating an agent, see [Set Up Your Agent](https://help.salesforce.com/s/articleView?id=ai.agent_parent_setup.htm). Agentforce-enabled scratch orgs have access to the [Agentforce Testing Center](https://help.salesforce.com/s/articleView?id=ai.agent_testing_center.htm). For more detailed information on testing your agents directly in your DX project, see [Test an Agent with Agentforce DX](https://developer.salesforce.com/docs/einstein/genai/guide/agent-dx-test.html) in the _Agentforce Developer Guide_. ## Set Up Your Salesforce DX Project and Scratch Org To set up a Salesforce DX project and scratch org, you must already have a namespace and scratch org ready to use. ## Before You Begin For guidance on obtaining a namespace or an Agentforce-enabled scratch org, see [Get Access to Scratch Orgs with Agentforce Enabled](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_scratch_orgs_agentforce.htm). **note:** To package BotTemplate metadata, you must first [enable Einstein Chatbot](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_einstein.htm) in your Dev Hub org. You must also specify this metadata in your `project-scratch-def.json` file. 1. If you’re using an existing Salesforce DX project that contains Apex classes, flows, or prompt templates for your agent, deploy them to the scratch org. ```nolang sf project deploy start --source-dir force-app --target-org MyNamespacedScratchOrg ``` 2. Open the scratch org. ```nolang sf org open ``` ## Develop Your Agentforce Package After you have built and tested your agent, you're ready to start packaging it. 1. Retrieve the relevant metadata into your Salesforce DX project. ```nolang sf project retrieve start --metadata Agent:My_Awesome_Agent –-target-org MyNamespacedScratchOrg ``` 2. Create an agent template metadata source file. In this example, we're generating an agent template from a Bot metadata file in your DX project that corresponds to the `My_Awesome_Agent` agent. A single Bot can have multiple BotVersions. Use the `--agent-version` flag to specify the version. Set the required `--source-org` flag to your scratch org. ```nolang sf agent generate template --agent-file force-app/main/default/bots/My_Awesome_Agent/My_Awesome_Agent.bot-meta.xml --agent-version 1 --source-org MyNamespacedScratchOrg ``` For more details on the `agent generate template` command, see the [Salesforce CLI Reference Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_agent_commands_unified.htm#cli_reference_agent_generate_template_unified). 3. Deploy the agent template metadata source file to your scratch org. ```nolang sf project deploy start --source-dir force-app --target-org MyNamespacedScratchOrg ``` 4. Test your agent template in your scratch org by creating an agent using the template you just deployed. Ensure that the new agent works as you expect. 5. When you're satisfied with your agent template, remove the following metadata from your package directory. 1. The GenAiPlannerBundle file that was part of your original agent. This file was used to create a new, separate GenAiPlannerBundle file for your agent template and is not necessary to package. Remove the GenAiPlannerBundle file that does not have “Template” in the name. 2. The Bot and BotVersion. Removing these metadata types prevents errors during packaging, since agents aren’t packageable. **note:** To package prompt templates, you must assign permissions in the `sfdx-project.json` file. See [Packaging Considerations for Prompt Templates](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_considerations_packaging.htm&type=5). 6. [Create a new package version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver.htm) that contains the template and all dependencies. Possible dependencies include: topics, actions, Apex classes, flows, and prompt templates. ```nolang sf package version create --package "Agentforce App" --installation-key “HIF83kS8kS7C” --definition-file config/project-scratch-def.json --code-coverage --wait 10 ``` ## Next Steps After a subscriber installs your package in their Agentforce-enabled org, they can use the Agentforce UI to create an agent from your template. ![User interface with ISV Agent Template tile](https://developer.salesforce.com/media/pkg2_dev/pkg2_agent_template_ui.png) # Develop App Documentation To help your subscribers make the most of your app, provide documentation about how to configure and customize your app. - Configure Option—You can include a **Configure** option for installers. This option can link to installation and configuration details, such as: - Provisioning the external service of a client app - Custom app settings The **Configure** option is included in your package as a custom link. You can create a custom link for your home page layouts and add it to your package. 1. Create a custom link to a URL that contains configuration information, or a Visualforce page that implements the configuration. When you create your custom link, set the display properties to Open in separate popup window so that the user returns to the same Salesforce page when done. 2. When you create the package, choose this custom link in the Configure Custom Link field of your package detail. - Data Sheet—Give installers the fundamental information they must know about your app before they install. - Customization and Enhancement Guide—Let installers know what they must customize after installation as part of their implementation. - Custom Help—You can provide custom help for your custom object records and custom fields. **note:** The option to configure a custom link is available only to first-generation managed packages (1GP). This option isn't available to second-generation managed packages (2GP). # Develop Second-Generation Managed Packages Ready to get started? Create your first second-generation managed package, and then update and create new versions of your package. - **[Create a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-pkg-base.md)** A package is a top-level container that holds important details about the app or package: the package name, description, and associated namespace. When you’re ready to test or share your package, use the `sf package create` Salesforce CLI command to create a package. - **[View Package Details for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-view-pkg-details.md)** View the details of previously created second-generation managed packages from the command line. - **[Create Versions of a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-pkg-ver.md)** A package version is a fixed snapshot of the package contents and related metadata. The package version is an installable, immutable artifact that lets you manage changes and track what’s different each time you release or deploy a specific set of changes. - **[Guidance for Package Version Numbering](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-version-guidance.md)** Use package versions to evolve your managed package, and release subsequent package versions without breaking existing package users. Every package version is a fixed snapshot of the package contents and related metadata. - **[View Details about a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-view-pkg-ver.md)** Retrieve details about second-generation managed package versions that are in progress, or have already been created. - **[Project Configuration File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-config-file.md)** The project configuration file is a blueprint for your project. The settings in the file create an outline of your managed 2GP package and determine the package attributes and package contents. - **[Get Ready to Promote and Release a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-get-ready-promote.md)** By now it’s likely that you’ve already created many different versions of your managed 2GP package and tested them. When you have a package version that you're ready to distribute, promoting the package version is the next step. - **[Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-ancestors.md)** When you create a second-generation managed package version you specify a package ancestor in your `sfdx-project.json` file. We require that the package ancestor you specify is the highest promoted package version number for that package. You can either update the ancestor version number each time you create a package version, or you can use a keyword. # 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](https://help.salesforce.com/s/articleView?id=platform.changesets.htm&type=5). - **[Create and Upload an Unmanaged Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-uploading-unmanaged.md)** Use the following procedure to upload an unmanaged package through the UI. You can also upload a package using the Tooling API. For sample code and more details, see the PackageUploadRequest object in the Tooling API Developer Guide. - **[Components Available in Unmanaged Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-unmanaged-components.md)** Not all components can be packaged for distribution. - **[Convert Unmanaged Packages to Managed](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/convert-to-managed-package.md)** # Disable SSO for a Member Org If you want Environment Hub users to reauthenticate when they log in to a member org, you can disable SSO. Disabling SSO doesn’t remove the user mappings that you’ve defined, so you can always re-enable SSO later. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure the Environment Hub:|Manage Environment Hub| ## Steps 1. Log in to the Environment Hub, and then select a member org. If you don’t see any member orgs, check your list view. 2. Select **Disable SSO**. 3. Confirm that you want to disable SSO for this org, and then select **Disable SSO** again. # Discover AgentExchange Solutions To find the rightsolution on AgentExchange, describe your business needs using natural language. With improved search capabilities, AgentExchange understands queries and provides dynamic query suggestions to speed up your research. Instead of relying on technical keywords or package names, phrase your queries as questions or goals, such as "How do I automate document generation?". The intent-first search model powered by Data 360, evaluates your needs and instantly provides dynamic suggestions as you type. To refine your results, the search results page shows inline query suggestions. **note:** While the improved search functionality helps ypu find your solution faster, the underlying search experience on AgentExchange remains the same. Use these search capabilities to find the right AgentExchange solution: **Dynamic query suggestions:** To find solutions on the AgentExchange site, type your query in the search bar and select a dynamic query suggestion from the search dropdown. **Top searches:** Click the search bar at any time to view popular, recent searches in the search dropdown. **Inline query suggestions:** To refine your search, select an inline query suggestion on the search results page. **Recent searches:** To review the details of a matching solution, click the listing card. At any time, click the search bar to view your recent search history in the search dropdown. **AI summary (Beta):** Review the AI summary that appears above your search results for a contextual overview of the solution landscape. The AI summary highlights common capabilities and themes. To refine your search further, select a relevant follow-up search suggestion under Related Searches on the search results page. When you apply filters or change the sort order, click the Updated banner indicator to view the updated AI summary. **note:** - The AI summary feature is a beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this pilot or beta service is at the Customer's sole discretion. - AI summary is available for app and solution listings only; it is not available for Slack and Consultant listings. # Download Package Usage Logs, Package Usage Summaries, and Subscriber Snapshots To request package usage logs, monthly package usage summaries, and subscriber snapshots, use the AppAnalyticsQueryRequest object. Usage logs, usage summaries, and subscriber snapshots are downloadable comma-separated value (.csv) files. ## Before You Begin To enable App Analytics on your second-generation (2GP) managed packages, follow these [instructions](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/app_analytics_enable2gp.htm). To enable App Analytics on your first-generation (1GP) managed packages, follow these [instructions](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/app_analytics_enable1gp.htm). Then determine which team members need create, read, update, and delete (CRUD) access to the AppAnalyticsQueryRequest object, and consider [creating a permission set](https://help.salesforce.com/articleView?id=perm_sets_create.htm) for them. By default, admins have the permissions required to request package usage logs and usage summaries using the AppAnalyticsQueryRequest object. In a 24-hour period, you can download up to 20 GB of AgentExchange App Analytics data. Package usage summary data is available to download for 10 years from the summary file log date. Package usage log data is available to download for 45 days from the date that the log event occurred. Subscriber snapshot data is available to download for 45 days from the snapshot date. The usage data that AgentExchange App Analytics collects depends on the org type and data type. | Data Type | Data is Collected on... | Data isn’t Collected on... | | --------------------- | ----------------------------------- | -------------------------------- | | `PackageUsageLog` | Production, sandbox, and trial orgs | Scratch orgs | | `PackageUsageSummary` | Production orgs | Sandbox, scratch, and trial orgs | | `SubscriberSnapshot` | Production org and trial orgs | Sandbox and scratch orgs | **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). 1. Log in to the License Management Org (LMO) that the package is registered to. 2. From the LMO, complete the required fields in the [AppAnalyticsQueryRequest](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_appanalyticsqueryrequest.htm) object. 3. Retrieve the App Analytics Query Request object created in the API request. The DownloadURL field populates after the request is completed. 4. Click the URL in the DownloadURL field in the App Analytics Query Request object, and download the .csv file. **note:** The download URL expires after 60 minutes. # Editable Properties After Package Promotion or Installation Certain properties on metadata components are editable after the managed package is installed. **Only Package Developer Can Edit:** The package developer can edit specific component properties. These properties are locked in the subscriber’s org. During package upgrade, the changes made by the package developer are applied in the subscriber org. For example, when you update the code in an Apex class or the custom permissions in a permission set, subscribers receive those updates during their package upgrade. **Both Subscriber and Package Developer Can Edit:** Both the subscriber and package developer can edit these component properties, but developer changes are only applied to new subscriber installs. This approach prevents a package upgrade from overwriting changes made by the subscriber. For example, the help text on a custom field, and the page layout of a custom object are editable by both the subscriber and package developer. The subscriber can modify the page layout or help text, and trust that their changes won’t be overwritten by a future package upgrade. **Neither Subscriber or Package Developer Can Edit:** After a package is promoted and released, these component properties are locked and can’t be edited by the package developer or the subscriber. For example, the API names of packaged components are locked and can’t be edited after the package version is promoted and released. # Enable a Package Subscriber to Restrict Push Upgrades In certain scenarios, a Salesforce customer may require the ability to block push upgrades of managed packages that they have installed in their org. Customized push upgrades let Salesforce Partners give customers the ability to restrict push upgrades to a specific customer org for a specific package. Setting up customized push upgrades requires both the Salesforce Partner and Salesforce Customer to complete specific enablement steps. 1. The Salesforce Partner enables customized push upgrades for a package installed in the customer org. 1. As the Salesforce Partner, log in to either your 1GP packaging org, or your Dev Hub org (for managed 2GP packages) using the system administrator account. 2. Click the gear icon and select **Developer Console**. 3. In the Developer Console, select **Debug**, and then select **Open Execute Anonymous Window**. 4. Enter the following code, but remember to replace the packageID (starts with `033`) and subscriberOrgID (starts with `00D`) text for the package ID and customer org you’re enabling. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId1 =' + pucId1); ``` Optionally, you can set the ability to block push upgrades to expire after a certain number of days. This example sets customized push upgrades to expire after 90 days. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true, 90); System.debug('pucId1 =' + pucId1); ``` If the customer wants to block push upgrades to multiple production orgs, you must specify each org ID. Here’s an example of how to enable customized push upgrades for more than one org. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId1 =' + pucId1); String pucId2 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId2 =' + pucId2); ``` 5. Click **Open Log** and then click **Execute**. 6. Click the **Debug Only** checkbox and verify that the push upgrade customization record was created. The record looks something like: `11:09:15:814 USER_DEBUG [2]|DEBUG|pucId1 =12COK000000000B` 7. Contact the Salesforce Customer and let them know that customized push upgrades is enabled on your end. **note:** Sandbox orgs automatically get the ability to block push upgrades if the parent production org has been granted the ability to block push upgrades by the Salesforce Partner. 2. After the Salesforce Partner enables customized push upgrades, the Salesforce Customer blocks push upgrades from Setup in the customer org. 1. As the Salesforce Customer, log in to your org. 2. From Setup, enter `Installed Packages` in the Quick Find box, and then select **Installed Packages**. 3. Select the package that you’ve requested to block push upgrades, and then select **Block Push Upgrades**. 4. Verify that the **Push upgrades are now blocked** checkbox is selected. ## Next Steps **note:** It’s not possible to block push upgrades on a patch version of a package. If the customer has a patch version installed, they must upgrade to a non-patch version of the package before they can block push upgrades. Salesforce Customers can resume push upgrades at any time by selecting the **Allow Push Upgrades** button. While the block is enabled, package upgrades can only be installed manually. Salesforce Partners can view and manage existing customized push upgrades by using the PushUpgradeCustomizationRepository Apex Class. If you enabled customized push upgrades for a subscriber with an expiration, you can update the expiration days by following Step 1. For Step 1d, use either the setExpirationDaysForId or setExpirationDaysForIndex method to update the expiration days. This example updates the expiration days to 100 days. ```nolang PushUpgradeCustomizationRepository.setExpirationDaysForIndex('packageID', 'subscriberOrgID', 100); System.debug('Expiration days updated successfully'); ``` This example updates the expiration days for the PushUpgradeCustomization record ID 12Cxx000000ABCDEF1 to 120 days. ```nolang PushUpgradeCustomizationRepository.setExpirationDaysForId('12Cxx000000ABCDEF1', 120); System.debug('Expiration days updated successfully'); ``` **note:** If the customer has blocked push upgrades from the subscriber org, it’s not possible to decrease the number of expiration days. # Enable a Package Subscriber to Restrict Push Upgrades In certain scenarios, a Salesforce customer may require the ability to block push upgrades of managed packages that they have installed in their org. Customized push upgrades let Salesforce Partners give customers the ability to restrict push upgrades to a specific customer org for a specific package. Setting up customized push upgrades requires both the Salesforce Partner and Salesforce Customer to complete specific enablement steps. 1. The Salesforce Partner enables customized push upgrades for a package installed in the customer org. 1. As the Salesforce Partner, log in to either your 1GP packaging org, or your Dev Hub org (for managed 2GP packages) using the system administrator account. 2. Click the gear icon and select **Developer Console**. 3. In the Developer Console, select **Debug**, and then select **Open Execute Anonymous Window**. 4. Enter the following code, but remember to replace the packageID (starts with `033`) and subscriberOrgID (starts with `00D`) text for the package ID and customer org you’re enabling. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId1 =' + pucId1); ``` Optionally, you can set the ability to block push upgrades to expire after a certain number of days. This example sets customized push upgrades to expire after 90 days. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true, 90); System.debug('pucId1 =' + pucId1); ``` If the customer wants to block push upgrades to multiple production orgs, you must specify each org ID. Here’s an example of how to enable customized push upgrades for more than one org. ```nolang String pucId1 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId1 =' + pucId1); String pucId2 = PushUpgradeCustomizationRepository.create('packageID', 'subscriberOrgID', true); System.debug('pucId2 =' + pucId2); ``` 5. Click **Open Log** and then click **Execute**. 6. Click the **Debug Only** checkbox and verify that the push upgrade customization record was created. The record looks something like: `11:09:15:814 USER_DEBUG [2]|DEBUG|pucId1 =12COK000000000B` 7. Contact the Salesforce Customer and let them know that customized push upgrades is enabled on your end. **note:** Sandbox orgs automatically get the ability to block push upgrades if the parent production org has been granted the ability to block push upgrades by the Salesforce Partner. 2. After the Salesforce Partner enables customized push upgrades, the Salesforce Customer blocks push upgrades from Setup in the customer org. 1. As the Salesforce Customer, log in to your org. 2. From Setup, enter `Installed Packages` in the Quick Find box, and then select **Installed Packages**. 3. Select the package that you’ve requested to block push upgrades, and then select **Block Push Upgrades**. 4. Verify that the **Push upgrades are now blocked** checkbox is selected. ## Next Steps Salesforce Customers can resume push upgrades at any time by selecting the **Allow Push Upgrades** button. While the block is enabled, package upgrades can only be installed manually. Salesforce Partners can view and manage existing customized push upgrades by using the PushUpgradeCustomizationRepository Apex Class. If you enabled customized push upgrades for a subscriber with an expiration, you can update the expiration days by following Step 1. For Step 1d, use either the setExpirationDaysForId or setExpirationDaysForIndex method to update the expiration days. This example updates the expiration days to 100 days. ```nolang PushUpgradeCustomizationRepository.setExpirationDaysForIndex('packageID', 'subscriberOrgID', 100); System.debug('Expiration days updated successfully'); ``` This example updates the expiration days for the PushUpgradeCustomization record ID 12Cxx000000ABCDEF1 to 120 days. ```nolang PushUpgradeCustomizationRepository.setExpirationDaysForId('12Cxx000000ABCDEF1', 120); System.debug('Expiration days updated successfully'); ``` **note:** If the customer has blocked push upgrades from the subscriber org, it’s not possible to decrease the number of expiration days. Note these considerations for customized push upgrades. - If your package is a managed 2GP and has customized push upgrades enabled, and you then [transfer the ownership of the managed 2GP](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_package_transfer.htm) from one Dev Hub to another, the new Dev Hub won’t retain the required permissions. In addition, the PushUpgradeCustomizationRepository records for blocking push upgrades won’t be retained. To continue using customized push upgrades with the new Dev Hub org, repeat Steps 1 and 2. - It’s not possible to block push upgrades on a patch version of a package. If the customer has a patch version installed, they must upgrade to a non-patch version of the package before they can block push upgrades. # Enable AgentExchange Lead Collection Collect leads when customers interact with your AgentExchange listings. ## Before You Begin Before you enable lead collection, verify that the Salesforce org that receives leads is ready. - You must receive leads in a standard Salesforce org, not a Developer Edition org. - The org where you receive leads must have Web-to-Lead enabled. - Require reCAPTCHA Verification must be disabled in your Web-to-Lead settings. |User Permissions Needed| | |-----------------------|--| |To edit AgentExchange listings:|Manage Listings| ## Steps 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. On the Listings tab, click a listing tile. 3. Click **Grow Your Business**. 4. Specify the Salesforce org where you want to receive the leads. We recommend using your partner business org so that you can manage leads and licenses from a single, convenient location. 5. Enable lead collection for one or more activities, and complete any required setup. If customers must contact you for installation instructions, select **Install the solution**. To check the installation method for this listing, go to the Link Your Solution step (1). ![A screenshot of the Installation Method section of the Link Your Solution Listing Builder step](https://developer.salesforce.com/docs/media/appexchange_installation_method.png) 6. Save your changes. **See Also** - [Installation Methods for AgentExchange Solutions](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-install-apps.md) # Enable App Analytics on Your First-Generation Managed Package Activate AgentExchange App Analytics on your first-generation (1GP) managed package to access AgentExchange App Analytics package usage logs and subscriber snapshots. Package usage summaries are available by default. ## Before You Begin | Availability | | ----------------------------------------------------------------------------------------- | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions. | | User Permissions Needed | | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | To access packages and package versions: | Read on Packages, Package Versions | | To request and retrieve AgentExchange App Analytics data: | Create, Read, Edit, Delete, View All, and Modify All on the AppAnalyticsQueryRequest object | 1. Log in to your packaging org. 2. Click the **gear icon** ![The Setup menu gear icon](https://developer.salesforce.com/media/pkg1_dev/gear.png), and select **Setup**. 3. In the Quick Find box, enter `package`, and select **Package Manager**. 4. Find your package, and click **Edit**. 5. Check **Enable AgentExchange App Analytics**. 6. Save your work. ## Next Steps For full documentation on available App Analytics data and query best practices, read [Get Started with AgentExchange App Analytics](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/app_analytics_intro_2gp.htm) in the _Second-Generation Managed Packaging Developer Guide_. # Enable App Analytics on Your Second-Generation Managed Package Activate AgentExchange App Analytics on your second-generation (2GP) managed package to access AgentExchange App Analytics package usage logs and subscriber snapshots. Package usage summaries are available by default. ## Before You Begin | Required Editions | | ----------------------------------------------------------------------------------------- | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions. | | User Permissions Needed | | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | To access packages and package versions: | Read on Packages, Package Versions | | To request and retrieve AgentExchange App Analytics data: | Create, Read, Edit, Delete, View All, and Modify All on the AppAnalyticsQueryRequest object | To ensure that you’re running the latest version of Salesforce CLI and its plug-ins, run `sf update` and `sf plugins update`. 1. Activate App Analytics on your managed 2GP package. `sf package update --package "Your Package Alias" --enable-app-analytics` To deactivate App Analytics on your managed 2GP package, run this CLI command. `sf package update --package "Your Package Alias" --no-enable-app-analytics` 2. For any additional package that you want App Analytics data for, repeat step 1. # Enable Dev Hub and Second-Generation Managed Packaging The Dev Hub lets you create and manage second-generation managed packages and scratch orgs. Your Dev Hub is the designated place to find and manage all your managed 2GP packages, scratch orgs, and namespaces. | Availability | | ------------------------------------------------------------------------------------------------ | | Available in: Salesforce Classic and Lightning Experience | | Dev Hub available in: **Developer**, **Enterprise**, **Performance**, and **Unlimited** Editions | After you enable the Dev Hub setting on a Salesforce org, that Dev Hub becomes the owner of every managed 2GP package you create. All Salesforce ISV and OEM partners should designate their Partner Business Org (PBO) as their Dev Hub org. To enable Dev Hub: 1. Log in to your Partner Business Org. 2. From Setup, enter `Dev Hub` in the Quick Find box and select **Dev Hub**. If you don't see Dev Hub in the Setup menu, make sure that your org is one of the supported editions. 3. Select **Enable Dev Hub**. After you enable Dev Hub, you can’t disable it. 4. Select **Enable Unlocked Packages and Second-Generation Managed Packages**. After you enable this setting, you can’t disable it. If you choose to use a trial or Developer Edition org as your Dev Hub, consider these factors. - When a trial or Developer Edition org expires, you lose access to all packages associated with that Dev Hub org. - You’re limited to creating up to six scratch orgs and package versions per day, with a maximum of three active scratch orgs. - Trial orgs expire on their expiration date. - Developer Edition orgs can expire due to inactivity. - If a package is associated with a non-production Dev Hub org, and that org expires or becomes inactive, the installed package can't be updated, and new attempts to install the package may fail. - If you plan to create package versions or run continuous integration jobs, it’s better to use your PBO as your Dev Hub because of higher scratch org and package version limits. The Dev Hub org instance determines where scratch orgs are created. - Scratch orgs created from a Dev Hub org in Government Cloud are created on a Government Cloud instance. - Scratch orgs created from a Dev Hub org in Public Cloud are created on a Public Cloud instance. **note:** You can’t enable Dev Hub in a sandbox. # Enable SSO for a Member Org You can enable single sign-on (SSO) to let an Environment Hub user log in to a member org without reauthenticating. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure the Environment Hub:|Manage Environment Hub| ## Steps 1. Log in to the Environment Hub, and then select a member org. If you don’t see any member orgs, check your list view. 2. Select **Enable SSO**. 3. Confirm that you want to enable SSO for this org, and then select **Enable SSO** again. # Environment Hub Best Practices Follow these guidelines and best practices when you use the Environment Hub. |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, and **Unlimited** Editions| - If you’re an admin or developer, choose the org that your team uses most frequently as your hub org. If you’re an ISV partner, the Environment Hub is already installed in your Partner Business Org. - Because each member org is a standard object (of type EnvironmentHubMember), you can modify its behavior or access it programmatically. For example, you can create custom fields, set up workflow rules, or define user mappings and enable single sign-on using the API for any member org. - Decide on a strategy for enabling SSO access based on your company’s security requirements. Then choose the SSO method (explicit mapping, Federation ID, or custom formula) that meets your needs. - SSO doesn’t work for newly added users or for user mappings defined in a sandbox org. Only add users, edit user information, or define SSO user mappings in the parent org for the sandbox. - The Environment Hub connected app is for internal use only. Don’t enable it for any profiles. Unless advised by Salesforce, don’t delete the connected app or adjust its settings. # Environment Hub FAQ Answers to common questions about the Environment Hub. |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions| **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). # Evaluate Agent Assets in Agentforce Builder Use the asset details page to evaluate the Agentforce subagents and actions. This page shows key information such as the associated app name, app provider, version, install options, and so on. ## Access the Asset Details Page From Agentforce Builder, browse AgentExchange to find subagents and actions that meet your business needs. Select a subagent or action to view its details. Evaluate its suitability by reviewing details such as the associated app, publisher information, version details, and so on. Based on the app’s installation status and your permissions, use the asset details page to: - **Install packages:** When you find a subagent or an action that you want to use, install the associated package. - **Manage installed package:** If the subagent or action belongs to an app that was installed in your org, check its installation status and other details. You can find these subagents and actions in the asset library. - **Update packages:** If a new version of your installed app is available, easily compare the versions and update your app to access the latest features. **note:** The subagents and actions pages show details of the available app version, not your installed version. - **Request installation:** If you don't have permission to install a package, notify your app provider. # Evaluate and Improve Your Consultant Listings Keep your consultant listings accurate, up to date, and performing at their best. Review your lead source codes and complete these quarterly steps to drive customer conversions. ## Lead Source Codes for Consultant Listings When a customer interacts with your listing, AgentExchange generates a lead. For more information, visit [Enable AgentExchange Lead Collection](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-enable-lead-collection.html). Each lead includes a source code that identifies the action they took. The source codes that apply to consultant listings are: - **DM**—The customer clicks the demo video tile in your media carousel. (Also applies to solution listings.) - **LM**—The customer clicks Learn More on your listing. (Consultant listings only.) ## Keep Your Listing Effective - **Audit your Learn More URL quarterly.** Confirm it resolves and leads to a conversion-oriented page. - **Keep certifications current.** Competency levels depend on active certifications in your Partner profile. - **Register project work.** Completed projects drive your Competency Level and Eligible Projects count. - **Respond to reviews.** Customer reviews and your responses are visible on the Reviews tab. - **Add media and resources.** Listings with demos, case studies, and documentation convert better than text-only listings. - **Monitor your analytics.** Use AgentExchange Marketplace Analytics to understand how customers find and interact with your listing. # Example of a Post Install Script The following sample post install script performs these actions on package install/upgrade. - If the previous version is null, that is, the package is being installed for the first time, the script: - Creates a new Account called Newco and verifies that it was created. - Creates a new instance of the custom object Survey, called Client Satisfaction Survey. - Sends an email message to the subscriber confirming installation of the package. - If the previous version is 1.0, the script creates a new instance of Survey called ”Upgrading from Version 1.0”. - If the package is an upgrade, the script creates a new instance of Survey called ”Sample Survey during Upgrade”. - If the upgrade is being pushed, the script creates a new instance of Survey called ”Sample Survey during Push”. ```apex public class PostInstallClass implements InstallHandler { global void onInstall(InstallContext context) { if(context.previousVersion() == null) { Account a = new Account(name='Newco'); insert(a); Survey__c obj = new Survey__c(name='Client Satisfaction Survey'); insert obj; User u = [Select Id, Email from User where Id =:context.installerID()];    String toAddress= u.Email; String[] toAddresses = new String[]{toAddress}; Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage(); mail.setToAddresses(toAddresses); mail.setReplyTo('support@package.dev'); mail.setSenderDisplayName('My Package Support'); mail.setSubject('Package install successful'); mail.setPlainTextBody('Thanks for installing the package.'); Messaging.sendEmail(new Messaging.Email[] { mail }); } else if(context.previousVersion().compareTo(new Version(1,0)) == 0) { Survey__c obj = new Survey__c(name='Upgrading from Version 1.0'); insert(obj); } if(context.isUpgrade()) { Survey__c obj = new Survey__c(name='Sample Survey during Upgrade'); insert obj; } if(context.isPush()) { Survey__c obj = new Survey__c(name='Sample Survey during Push'); insert obj; } } } ``` You can test a post install script using the new `testInstall` method of the `Test` class. This method takes the following arguments. - A class that implements the `InstallHandler` interface. - A `Version` object that specifies the version number of the existing package. - An optional Boolean value that is `true` if the installation is a push. The default is `false`. This sample shows how to test a post install script implemented in the `PostInstallClass` Apex class. ```apex @isTest static void testInstallScript() { PostInstallClass postinstall = new PostInstallClass(); Test.testInstall(postinstall, null); Test.testInstall(postinstall, new Version(1,0), true); List a = [Select id, name from Account where name ='Newco']; System.assertEquals(1, a.size(), 'Account not found'); } ``` # Example of an Uninstall Script This sample uninstall script performs the following actions on package uninstall. - Inserts an entry in the feed describing which user did the uninstall and in which organization - Creates and sends an email message confirming the uninstall to that user ```apex global class UninstallClass implements UninstallHandler { global void onUninstall(UninstallContext ctx) { FeedItem feedPost = new FeedItem(); feedPost.parentId = ctx.uninstallerID(); feedPost.body = 'Thank you for using our application!'; insert feedPost; User u = [Select Id, Email from User where Id =:ctx.uninstallerID()];    String toAddress= u.Email; String[] toAddresses = new String[] {toAddress}; Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage(); mail.setToAddresses(toAddresses); mail.setReplyTo('support@package.dev'); mail.setSenderDisplayName('My Package Support'); mail.setSubject('Package uninstall successful'); mail.setPlainTextBody('Thanks for uninstalling the package.'); Messaging.sendEmail(new Messaging.Email[] { mail }); } } ``` You can test an uninstall script using the `testUninstall` method of the `Test` class. This method takes as its argument a class that implements the `UninstallHandler` interface. This sample shows how to test an uninstall script implemented in the `UninstallClass` Apex class. ```apex @isTest static void testUninstallScript() { Id UninstallerId = UserInfo.getUserId(); List feedPostsBefore = [SELECT Id FROM FeedItem WHERE parentId=:UninstallerId AND CreatedDate=TODAY]; Test.testUninstall(new UninstallClass()); List feedPostsAfter = [SELECT Id FROM FeedItem WHERE parentId=:UninstallerId AND CreatedDate=TODAY]; System.assertEquals(feedPostsBefore.size() + 1, feedPostsAfter.size(), 'Post to uninstaller failed.'); } ``` # Extending the License Management App The License Management App (LMA) is a managed package that you can customize and extend. In addition to using the LMA to manage leads and licenses, many partners also integrate it into their existing business processes. The LMA includes these custom objects: - [License](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_license_details.htm) - [Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-package-details.md) - [Package Version](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-package-details.md) You can add custom fields to the objects as long as you don’t mark your custom fields as required. - **[Package and Package Version Object Fields](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-package-details.md)** The License Management App (LMA) includes a Package custom object and a Package Version custom object. These objects display details about each 1GP or 2GP package and package version you’ve listed on AgentExchange. - **[License Object Fields](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-license-details.md)** Use the License custom object to set limits on how many users in the subscriber’s org can use your app and for how long. - **[Adding Custom Automation to License Management App Objects](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-customer-success.md)** Here are some examples of how you can use the License Management App (LMA) to grow your business and retain customers. # FAQ A list of answers to frequently asked questions about installing apps from Lightning Platform AgentExchange. ## Can I uninstall packages that I installed from AgentExchange? Yes. All your installed packages are listed in the Installed Packages page. You can remove any package by clicking the **Uninstall** link next to the package name. ## Who Can Use AgentExchange? Anyone can browse and test drive AgentExchange listings. Salesforce admins and users with the Download AgentExchange Packages permission can install AgentExchange apps. To publish a listing on AgentExchange, a user needs both Create AgentExchange Packages and Upload AgentExchange Packages permissions. ## Why did my installation or upgrade fail? An installation can fail for several reasons: - The package includes custom objects that will cause your organization to exceed its limit of custom objects. - The package includes custom tabs that will cause your organization to exceed its limit of custom tabs. - The developer of the package has uploaded a more recent version of the package and has deprecated the version associated with this installation URL. Contact the publisher of the package to get the most recent installation URL. - You’re trying to install an extension to a package, and you don't have the base package installed. - The package requires that certain components are enabled in your organization, or that required features are enabled in your edition. - The package contains Apex code and you are not authorized to run Apex in your organization. - The package you’re installing has a failing Apex test. ## Can I customize AgentExchange packages? Yes, all packages are customizable. However, to ensure compatibility with future versions, some aspects of managed packages can't be changed. ## Who can use AgentExchange Packages? If you use an Enterprise, Unlimited, Performance, or Developer Edition organization, you can choose which user profiles have access to the package as part of the installation process. Packages installed in Professional and Group Edition organizations are installed with “Full Access” to all user profiles. However, regardless of Edition, all custom objects are installed in “In Development” mode which hides them from all standard users. Users must have the “Customize Application” permission to view custom objects in “In Development” mode. When you are ready to roll out the package to other users, change the custom object status to “Deployed.” ## How can I upgrade an installed package? Managed packages are completely upgradeable. Before installing a package, contact the publisher to determine if it’s managed. ## How secure are the components I install? Salesforce performs periodic security reviews of all publicly listed applications on AgentExchange. When installing third party applications with access to data, these applications may have access to other data within the organization where the package was installed. Private listings do not go through a security review and administrators should inspect the application carefully before determining whether it should be installed within their organization. ## What happens to my namespace prefix when I install a package? A namespace prefix is a globally unique identifier that you can request if you plan to create a managed package. All the components from a managed package that you install from another developer contain the developer's namespace prefix in your organization. Unmanaged packages can have a namespace prefix while they're developed in an org that contains a managed package. This namespace isn’t used outside of the development (publisher) org. If an unmanaged package is installed in an org that has no namespace, then the unmanaged components have no namespace in the subscriber org. If an unmanaged package is installed in an org that has a namespace, then the components get the namespace of the subscriber org. ## Can I reinstall an AgentExchange package after uninstalling it? Yes. You can reinstall a package in the same manner that you installed it. ## When I install a package that’s listed on AgentExchange, do custom objects, custom fields, tabs, and apps in the package count against the limits of my Salesforce edition? Your Salesforce edition is allocated a certain number of custom objects, custom fields, tabs, and other customizations. At the same time, all Salesforce orgs have a total limit on some of these items. If you install a package from AgentExchange, its custom objects, custom fields, tabs, and apps don’t count against your edition’s allocation, but they do count against the total limit of your Salesforce org. **note:** These rules apply only to managed packages that are listed on AgentExchange. If you install an unmanaged package or a managed package that’s not publicly listed on AgentExchange, its custom objects, custom fields, tabs, and apps count against the allocation for your Salesforce edition. # Feature Parameter Metadata Types and Custom Objects Feature parameters are represented as Metadata API types in your packaging org, as records of custom objects in your License Management Org, and as hidden records in your subscriber’s org. ## Feature Parameter Fields Feature parameters are represented as Metadata API types and store boolean, integer, or date values. The first time a subscriber installs your package, a FeatureParameter\_\_c record is created in your License Management Org (LMO) for each feature parameter. The feature parameter records include these fields: - FullName\_\_c - DataType\_\_c (`Boolean`, `Integer`, or `Date`) - DataFlowDirection\_\_c - Package\_\_c - IntroducedInPackageVersion\_\_c - Namespace_Prefix\_\_c ## Lifecycle of a Feature Parameter **Set Up the Feature Parameter:** Start by defining your feature parameter in the packaging org using the Feature Parameters tab on the Package detail page. Depending on how you’re using the feature parameter, you’ll also write code that enables you to check access rights or collect usage information after the parameter is set up. **Subscriber Installs Your Managed Package** When a subscriber installs or upgrades your package in their org, a FeatureParameter\_\_c record for each feature parameter is created in the LMO. If these records were created during a previous installation or upgrade, this step is skipped. During package installation, junction object records are created in both the subscriber org and your LMO. A junction object is a custom object with two master-detail relationships. In this case, the relationships are between FeatureParameter**c and License**c in the LMO. These records store the value of their associated feature parameter for that subscriber org. **Utilize Your Feature Parameters** Use the junction objects to override the feature parameters’ default values or to collect data. Depending on the value of each feature parameter’s DataFlowDirection\_\_c field, data flows to the subscriber org (from the LMO) or to the LMO (from the subscriber org). That data is stored in the junction object records. # Feature Parameter Metadata Types and Custom Objects Feature parameters are represented as Metadata API types in your package metadata, as records of custom objects in your LMO, and as hidden records in your subscriber’s org. ## Feature Parameter Fields Feature parameters are represented as Metadata API types and store boolean, integer, or date values. The first time a subscriber installs your package, a FeatureParameter\_\_c record is created in your LMO for each feature parameter. The feature parameter records include these fields: - FullName\_\_c - DataType\_\_c (`Boolean`, `Integer`, or `Date`) - DataFlowDirection\_\_c - Package\_\_c - IntroducedInPackageVersion\_\_c - Namespace_Prefix\_\_c **note:** After a feature parameter is included and released in the package version, the data flow direction can’t be changed. ## Lifecycle of a Feature Parameter **Set Up the Feature Parameter:** Start by defining your feature parameter in an XML file. [Create one XML file](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-fma-create-feature-parameters.md) for each feature parameter. Depending on how you’re using the feature parameter, you’ll also write code that enables you to check access rights or collect usage information after the parameter is set up. **Subscriber Installs Your Managed Package** When a subscriber installs or upgrades your package in their org, a FeatureParameter\_\_c record for each feature parameter is created in the LMO. If these records were created during a previous installation or upgrade, this step is skipped. During package installation, junction object records are created in both the subscriber org and your LMO. A junction object is a custom object with two master-detail relationships. In this case, the relationships are between FeatureParameter**c and License**c in the LMO. These records store the value of their associated feature parameter for the subscriber org. **Utilize Your Feature Parameters** Use the junction objects to override the feature parameters’ default values or to collect data. Depending on the value of each feature parameter’s DataFlowDirection\_\_c field, data flows to the subscriber org (from the LMO) or to the LMO (from the subscriber org). That data is stored in the junction object records. # Features in Group and Professional Editions The easiest way to determine which features and objects are available in a particular edition is by reviewing the Edition Comparison Table. You can also look up which editions support a specific feature or object by searching the online help. It’s important that you check these resources before you start designing your app to make an informed decision on which editions to target. When you’re finished building your app, we recommend that you test it by installing your package in GE and PE test orgs to ensure that everything functions properly. Review the [Edition Comparison Table](http://www.sfdcstatic.com/assets/pdf/datasheets/DS_SalesCloud_EdCompare.pdf). The following table shows the key differences between GE and PE. |Feature|Group Edition|Professional Edition| |-------|-------------|--------------------| |Assets|No|Yes| |Campaigns|No|Yes| |Contracts|No|Yes (with the Sales Cloud)| |Forecasts|No|Yes (no Opportunity Splits or Custom Field forecasts)| |Ideas|No|Yes| |Products|No|Yes| |Solutions|No|Yes| |Record types|No|Yes| |Permission sets|Yes|Yes| |Custom profiles|No|Yes| |Custom report types|No|Yes| |Workflow and approvals|No|No (See note.)| |Apex code|See note.|See note.| |Sharing rules|No|Yes (for some features)| |API|See note.|See note.| |Sites|No|No| **note:** - All listed features are available in DE. - As a partner, workflows within your application run in a Professional Edition org. However, customers can’t create their own workflows. They must purchase the feature directly from Salesforce. - A client ID allows your app to use the API for integration to composite apps. For more information, see [Using Apex in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-apex-ge-pe.md) and [API Access in Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-api-access.md). # Find PreBuilt Agentforce Assets on AgentExchange AgentExchange shows individual Agentforce assets such as subagents and actions in the Agentforce Asset library. Browse for individual subagents and actions rather than searching through applications without leaving your flow of work. To find an Agentforce subagent on AgentExchange: 1. From the App Launcher, find and select Agentforce Studio. 2. Open your agent in Agentforce Builder. 3. From Explorer, go to Subagents and then click **Add from Asset Library**. 4. Browse AgentExchange and search for the Agentforce subagents that meet your business needs. **tip:** - Filter the subagents based on business needs, industries, or Salesforce Labs. By default, there are no filters applied. - When you type a keyword in the searchbar, the results shown are automatically sorted by relevance. Otherwise, the default sort is by the recently created assets. 5. Select a subagent card to view its details. You can evaluate the subagent’s suitability by reviewing its details such as its actions, publisher information, and so on. 6. To use the subagent, install the partner application that contains it. When the app is installed, the Agentforce subagent becomes available in your org. **note:** Finding actions and MCP server tools follows a similar process. To view the list of actions and MCP server tools on AgentExchange, select an action and then click **Add from Asset Library**. Then, on the Actions modal, use the search bar to search or use the Asset Type filter to quickly switch between actions and MCP server tools. # First-Generation Managed Packages Managed packages are used by Salesforce partners to distribute and sell applications to customers. Using AgentExchange and the License Management Application (LMA), developers can sell and manage user-based licenses to their app. Managed packages are upgradeable. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). - **[Why Switch to Second-Generation Managed Packaging?](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/why-switch-2gp.md)** You’ve been using first-generation managed packages to develop your apps, so you’re probably pretty familiar with what works well, and what’s a bit more painful than you’d like. And no doubt, you’re aware that second-generation managed packages is our newer technology, but maybe you aren’t so sure why switching to second-generation managed packaging (managed 2GP) will improve your package development experience. So let’s talk about that. - **[Move to 2GP: Migrate Your Managed Packages with Ease](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/move-to-second-gen-pkg.md)** Are you still using first-generation managed packaging (1GP) for your package development work? If so, you're not alone. Many ISVs like you are looking to move to second-generation managed packaging (2GP) and take advantage of its many benefits. - **[Register a Namespace for a First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/register-namespace-prefix.md)** A namespace is a one to 15-character alphanumeric identifier that distinguishes your package and its contents from packages of other developers on AgentExchange. Namespace prefixes are case-insensitive. For example, ABC and abc aren’t recognized as unique. Your namespace must be globally unique across all Salesforce orgs. - **[Create a First-Generation Managed Package Using a UI](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/creating-packages.md)** If your goal is to build an app and distribute it on AgentExchange, you use managed packages to do both. Packaging is the container that you fill with metadata, and it holds the set of related features, customizations, and schema that make up your app. A package can include many different metadata components, and you can package a single component, an app, or library. - **[Create a First-Generation Managed Package using Salesforce DX](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/build-first-gen-dx/sfdx-dev-build-release.md)** If you’re an ISV, you want to build a managed package. A managed package is a bundle of components that make up an application or piece of functionality. A managed package is a great way to release an app for sale and to support licensing your features. You can protect intellectual property because the source code of many components isn’t available through the package. You can also roll out upgrades to the package. - **[Components Available in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/first-gen-packageable-components.md)** Each metadata component that you include in a first-generation managed package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and installed. - **[Editable Properties After Package Promotion or Installation](https://developer.salesforce.com/docs/platform/pkg1-dev/metadata-components/mdc-editable-property-definitions.md)** Certain properties on metadata components are editable after the managed package is installed. - **[Behavior of Specific Metadata in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-specific-md.md)** Learn how profiles and other metadata are handled for first-generation managed packages. - **[Package and Test Your First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-testing.md)** Learn how to package, upload, and install a beta version of your first-generation managed package as part an iterative development approach. After your beta is up and running, learn how to test, fix, extend, and uninstall the package. - **[Update Your First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-upgrading.md)** Your app is ready for an update. Learn how to fix small issues with patches and make major changes with upgrades. - **[Publish Upgrades to First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/publish-upgrades.md)** As a publisher, first ensure that your app is upgradeable by converting it to a managed package. - **[Manage Licenses for Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/lma/lma-intro.md)** Use the License Management App (LMA) to manage leads and licenses for your AgentExchange solutions. By integrating the LMA into your sales and marketing processes, you can better engage with prospects, retain existing customers, and grow your ISV business. The LMA is a managed package that is installed in all partner business orgs (PBO) and includes custom objects that track details on packages, package versions, and licenses. - **[Manage Features in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/fma/fma-manage-features.md)** Control how you release features to customers with the Feature Management App (FMA). The FMA extends the functionality of the License Management App (LMA). Use the FMA to manage features as easily as you manage licenses with the LMA. - **[AgentExchange App Analytics for First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/app-analytics-intro-1gp.md)** AgentExchange App Analytics provides usage data about how subscribers interact with your first-generation (1GP) managed packages and packaged components. You can use these details to identify attrition risks, inform feature development decisions, and improve user experience. - **[Developing and Distributing Unmanaged Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-developing-unmanaged.md)** 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. # First-Generation Managed Packaging Developer Guide Previous PDF Versions | API Version | Release | PDF | | ----------- | ---------- | -------------------------------------------------------------------------------------------- | | 68.0 | Winter '27 | [Download PDF](https://resources.docs.salesforce.com/264/latest/en-us/sfdc/pdf/pkg1_dev.pdf) | | 67.0 | Summer '26 | [Download PDF](https://resources.docs.salesforce.com/262/latest/en-us/sfdc/pdf/pkg1_dev.pdf) | | 66.0 | Spring '26 | [Download PDF](https://resources.docs.salesforce.com/260/latest/en-us/sfdc/pdf/pkg1_dev.pdf) | | 65.0 | Winter '26 | [Download PDF](https://resources.docs.salesforce.com/258/latest/en-us/sfdc/pdf/pkg1_dev.pdf) | | 64.0 | Summer '25 | [Download PDF](https://resources.docs.salesforce.com/256/latest/en-us/sfdc/pdf/pkg1_dev.pdf) | # First-Generation Managed Packaging Developer Guide Previous PDF Versions | API Version | Release | PDF | | ----------- | ---------- | -------------------------------------------------------------------------------------------- | | 68.0 | Winter '27 | [Download PDF](https://resources.docs.salesforce.com/264/latest/en-us/sfdc/pdf/pkg2_dev.pdf) | | 67.0 | Summer '26 | [Download PDF](https://resources.docs.salesforce.com/262/latest/en-us/sfdc/pdf/pkg2_dev.pdf) | | 66.0 | Spring '26 | [Download PDF](https://resources.docs.salesforce.com/260/latest/en-us/sfdc/pdf/pkg2_dev.pdf) | | 65.0 | Winter '26 | [Download PDF](https://resources.docs.salesforce.com/258/latest/en-us/sfdc/pdf/pkg2_dev.pdf) | | 64.0 | Summer '25 | [Download PDF](https://resources.docs.salesforce.com/256/latest/en-us/sfdc/pdf/pkg2_dev.pdf) | # Frequently Used Packaging Operations for Second-Generation Managed Packages For a complete list of Salesforce CLI packaging commands, see: [Salesforce Command Line Reference Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm). | Salesforce CLI command | What it Does | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `sf package create` | Creates a package. When you create a package, you specify its package type and name, among other things. | | `sf package version create` | Creates a package version. | | `sf package install` | Installs a package version in a scratch, sandbox, or production org. | | `sf package uninstall` | Removes a package that has been installed in an org. This process deletes the metadata and data associated with the package. | | `sf package version promote` | Changes the state of the package version from beta to the managed-released state. | | `sf org create scratch` | Creates a scratch org. | | `sf org open` | Opens an org in the browser. | # Gaps Between First-Generation and Second-Generation Managed Packaging The following functionality is supported in first-generation managed packaging, and not yet supported in second-generation managed packaging. We’re working to address these feature gaps. - Package versions can’t be deprecated. - [Apex VersionProvider](https://help.salesforce.com/articleView?id=code_version_settings_apex.htm) isn’t supported. - A default language for labels in packages can’t be specified. See the [Metadata Coverage Report](https://developer.salesforce.com/docs/success/metadata-coverage-report/references/coverage-report/metadata-coverage-report.html), for the latest information on supported metadata types. # Generate an Enterprise WSDL with Managed Packages If you’re downloading an enterprise WSDL and you have first-generation managed packages installed in your org, you must take an extra step to select the version of each installed package to include in the generated WSDL. | Availability | | ----------------------------------------------------------------------------------------- | | Available in: Salesforce Classic | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer**, Editions | | User Permissions Needed | | | ----------------------- | --------------------- | | To download a WSDL: | Customize Application | The enterprise WSDL is strongly typed, which means that it contains objects and fields with specific data types, such as `int` and `string`. A package version is a number that identifies the set of components uploaded in a package. The version number has the format _majorNumber.minorNumber.patchNumber_ (for example, 2.1.3). The major and minor numbers increase to a chosen value during every major release. The _patchNumber_ is generated and updated only for a patch release. Publishers can use package versions to evolve the components in their managed packages gracefully by releasing subsequent package versions without breaking existing customer integrations using the package. A subscriber can select a package version for each installed managed package to allow their API client to continue to function with specific, known behavior even when they install subsequent versions of a package. Each package version can have variations in the composition of its objects and fields, so you must select a specific version when you generate the strongly typed WSDL. **note:** This is only available to first-generation managed packages. To download an enterprise WSDL when you have managed packages installed: 1. From Setup, enter `API` in the Quick Find box, then select **API**. 2. Click **Generate Enterprise WSDL**. 3. Select the Package Version for each of your installed managed packages. If you’re unsure which package version to select, you should leave the default, which is the latest package version. 4. Click **Generate**. 5. Use the **File** menu in your browser to save the WSDL to your computer. 6. On your computer, import the local copy of the WSDL document into your development environment. ## Next Steps Note the following in your generated enterprise WSDL: - Each of your managed package version selections is included in a comment at the top of the WSDL. - The generated WSDL contains the objects and fields in your organization, including those available in the selected versions of each installed package. If a field or object is added in a later package version, you must generate the enterprise WSDL with that package version to work with the object or field in your API integration. - The SOAP endpoint at the end of the WSDL contains a URL with a format of `_serverName_/services/Soap/c/_api_version/ID_` where _api_version_ is the version of the API, such as 52.0, and _ID_ encodes your package version selections when you communicate with Salesforce. You can also select the default package versions for the enterprise WSDL without downloading a WSDL from the API page in Setup. Default package versions for API calls provide fallback settings if package versions aren’t provided by an API call. Many API clients don’t include package version information, so the default settings maintain existing behavior for these clients. # Get Access to Agentforce in Your 1GP Packaging Org Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. ## Before You Begin To enable Agentforce Extensibility for ISVs on a 1GP packaging org, you must log a case with [Salesforce Partner Support](https://partners.salesforce.com/). In the case details, list your packaging org ID and request Agentforce Extensibility for ISVs be provisioned. Only 1GP development orgs created from Environment Hub can have Agentforce provisioned. | Feature Name | Component Type in Package Manager | Available in … | More Information | | ---------------- | --------------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agent Actions | Generative AI Function Definition | Managed 2GP and Managed 1GP | [Agent Action](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaifunction) | | Agent Topics | Generative AI Plugin Definition | Managed 2GP and Managed 1GP | [Agent Topic](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaiplugin) | | Prompt Templates | Generative AI Prompt Template | Managed 2GP and Managed 1GP | [Generative AI Prompt Template](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaiprompttemplate) | **See Also** - [Get Access to Scratch Orgs That Have Agentforce](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_scratch_orgs_agentforce.htm) - [_Salesforce Help_: Considerations for Packaging Prompt Templates](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_considerations_packaging.htm) - [_Trailhead_: Quick Start: Build Your First Agent with Agentforce](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce) - [_Salesforce Help_: Agentforce: Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5) - [_Salesforce Help_: The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm&type=5) - [_Salesforce Help_: Customize Your Agents with Topics and Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_topics_actions.htm&type=5) - [_Salesforce Help_: Considerations for Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_considerations.htm&type=5) - [_Salesforce Help_: AI Project Success](https://help.salesforce.com/s/articleView?id=ai.generative_ai_plan_project.htm&type=5) # Get Access to Scratch Orgs That Have Agentforce Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. Start your journey with Agentforce by testing it in a scratch org. If you don’t already have a Partner Business Org (PBO), join the [Salesforce Partner Community](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_partner_join.htm) and [request a PBO](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_partner_request_pbo.htm). If you’re new to creating scratch orgs, follow these steps to complete the one-time Dev Hub setup in your PBO. The Dev Hub is a feature within an org that lets you create and manage scratch orgs, second-generation managed packages (2GP), and namespaces. - [Enable the Dev Hub and 2GP](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_enable_devhub.htm) - [Create a Developer Edition](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/environment_hub_manage_create_org.htm) org using Environment Hub - [Create a namespace](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) in the Developer Edition org - [Link that namespace](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_reg_namespace.htm) from your PBO. Linking the namespace lets you create 2GP packages that use that namespace. - [Authorize the Dev Hub org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm). - [Create a Salesforce DX Project](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_create_new.htm). To create a scratch org with Agentforce and Prompt Builder enabled, use this sample `project-scratch-def.json` file (or simply add the feature and setting shown in this sample to your existing scratch org definition file). ```nolang { "orgName": "GenAI Scratch Org", "edition": "Partner Developer", "features": ["Einstein1AIPlatform"], "settings": { "einsteinGptSettings" : { "enableEinsteinGptPlatform" : true } } } ``` To create a scratch org with the Einstein1AIPlatform feature, the scratch org you create can be a Partner Developer, Partner Enterprise, Developer, or Enterprise edition. To create a scratch org, run this Salesforce CLI command. Update the definition-file name, alias, and target-dev-hub alias as needed. ```nolang sf org create scratch --definition-file config/my-agentforce-project-scratch-def.json --alias MyNamespacedScratchOrg --set-default --target-dev-hub MyDevHubOrg ``` ## Scratch Orgs with both Agentforce and Data Cloud For some use cases such as prompt templates that use RAG, Retrievers, or BYO LLM, a scratch org that has both GenAI and Data Cloud functionality enabled is required. Only include Data Cloud if it’s required. Specifying Data Cloud in a scratch org significantly increases the time it takes for a scratch org creation to complete. **note:** Including Data Cloud in a scratch org has a prerequisite. You must first open a case in the Salesforce Partner Community to request for your PBO Dev Hub org to be granted permission to create Data Cloud scratch orgs. This request is only granted to PBO orgs. ```nolang { "orgName": "GenAI & Data Cloud Scratch Org", "edition": "Partner Developer", "features": ["CustomerDataPlatform", "CustomerDataPlatformLite","Einstein1AIPlatform"], "settings": { "einsteinGptSettings" : { "enableEinsteinGptPlatform" : true }, "customerDataPlatformSettings": { "enableCustomerDataPlatform": true } } } ``` ## Set up Agentforce in your Scratch Org After your scratch org is created, follow these steps to start developing with Agentforce. - [Create Agents](https://help.salesforce.com/s/articleView?id=sf.copilot_setup_enable.htm) manually in the scratch org. - To use prompt templates with your Agent Actions, [assign prompt template permissions](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_enable.htm&type=5). **See Also** - [Get Access to Agentforce in Your 1GP Packaging Org](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging1_agentforce_access.htm) - [_Trailhead_: Quick Start: Build Your First Agent with Agentforce](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce) - [_Salesforce Help_: Agentforce Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5) - [_Salesforce Help_: The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm&type=5) - [_Salesforce Help_: Customize Your Agents with Topics and Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_topics_actions.htm&type=5) - [_Salesforce Help_: Considerations for Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_considerations.htm&type=5) - [_Salesforce Help_: AI Project Success](https://help.salesforce.com/s/articleView?id=ai.generative_ai_plan_project.htm&type=5) # Get Access to Scratch Orgs That Have Agentforce Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. Start your journey with Agentforce by testing it in a scratch org. If you don’t already have a Partner Business Org (PBO), join the [Salesforce Partner Community](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_partner_join.htm) and [request a PBO](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_partner_request_pbo.htm). If you’re new to creating scratch orgs, follow these steps to complete the one-time Dev Hub setup in your PBO. The Dev Hub is a feature within an org that lets you create and manage scratch orgs, second-generation managed packages (2GP), and namespaces. - [Enable the Dev Hub and 2GP](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_enable_devhub.htm) - [Create a Developer Edition](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/environment_hub_manage_create_org.htm) org using Environment Hub - [Create a namespace](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) in the Developer Edition org - [Link that namespace](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_reg_namespace.htm) from your PBO. Linking the namespace lets you create 2GP packages that use that namespace. - [Authorize the Dev Hub org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm). - [Create a Salesforce DX Project](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_create_new.htm). To create a scratch org with Agentforce and Prompt Builder enabled, use this sample `project-scratch-def.json` file (or simply add the feature and setting shown in this sample to your existing scratch org definition file). ```nolang { "orgName": "GenAI Scratch Org", "edition": "Partner Developer", "features": ["Einstein1AIPlatform"], "settings": { "einsteinGptSettings" : { "enableEinsteinGptPlatform" : true } } } ``` To create a scratch org with the Einstein1AIPlatform feature, the scratch org you create can be a Partner Developer, Partner Enterprise, Developer, or Enterprise edition. To create a scratch org, run this Salesforce CLI command. Update the definition-file name, alias, and target-dev-hub alias as needed. ```nolang sf org create scratch --definition-file config/my-agentforce-project-scratch-def.json --alias MyNamespacedScratchOrg --set-default --target-dev-hub MyDevHubOrg ``` ## Scratch Orgs with both Agentforce and Data Cloud For some use cases such as prompt templates that use RAG, Retrievers, or BYO LLM, a scratch org that has both GenAI and Data Cloud functionality enabled is required. Only include Data Cloud if it’s required. Specifying Data Cloud in a scratch org significantly increases the time it takes for a scratch org creation to complete. **note:** Including Data Cloud in a scratch org has a prerequisite. You must first open a case in the Salesforce Partner Community to request for your PBO Dev Hub org to be granted permission to create Data Cloud scratch orgs. This request is only granted to PBO orgs. ```nolang { "orgName": "GenAI & Data Cloud Scratch Org", "edition": "Partner Developer", "features": ["CustomerDataPlatform", "CustomerDataPlatformLite","Einstein1AIPlatform"], "settings": { "einsteinGptSettings" : { "enableEinsteinGptPlatform" : true }, "customerDataPlatformSettings": { "enableCustomerDataPlatform": true } } } ``` ## Set up Agentforce in your Scratch Org After your scratch org is created, follow these steps to start developing with Agentforce. - [Create Agents](https://help.salesforce.com/s/articleView?id=sf.copilot_setup_enable.htm) manually in the scratch org. - To use prompt templates with your Agent Actions, [assign prompt template permissions](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_enable.htm&type=5). **See Also** - [Packageable Agentforce Metadata](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_packageable_agentforce_md.htm) - [_Trailhead_: Quick Start: Build Your First Agent with Agentforce](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce) - [_Salesforce Help_: Agentforce: Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5) - [_Agentforce Developer Guide_](https://developer.salesforce.com/docs/einstein/genai/guide/get-started.html) - [_Salesforce Help_: The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm&type=5) - [_Salesforce Help_: Customize Your Agents with Topics and Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_topics_actions.htm&type=5) - [_Salesforce Help_: Considerations for Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_considerations.htm&type=5) - [_Salesforce Help_: AI Project Success](https://help.salesforce.com/s/articleView?id=ai.generative_ai_plan_project.htm&type=5) # Get Help with Prerequisites If you need help with setting up your solution, you can request a consultation with a Platform Expert. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com). 2. Click the question icon ![AgentExchange Support question mark](https://developer.salesforce.com/media/pkg2_dev/appex_support_question_mark.png) and then click **Log a Case for Help**. 3. Provide any required details, and then click **Create Case**. # Get Ready to Distribute on AgentExchange Before you list a solution or consulting service on AgentExchange, complete the prerequisite tasks. First, sign up for the ISV Partner Program. Next, verify that you have a Partner Business Org. Then, get familiar with the resources and documentation that can help you navigate the partner journey efficiently. # Get Ready to Promote and Release a Second-Generation Managed Package Version By now it’s likely that you’ve already created many different versions of your managed 2GP package and tested them. When you have a package version that you're ready to distribute, promoting the package version is the next step. Each package version you create is a beta version, unless you promote it to the managed-released state. Beta versions can be installed in only scratch orgs and sandboxes. After you install a beta version into an org, you can’t later upgrade that installed beta version. Keep this in mind when you select which org to install and test your beta package version. If you use this sandbox as part of your release pipeline, then using a disposable scratch org is a better option to test your beta package. A beta package version must pass a 75% code coverage requirement before it can be promoted. To learn more, see [Code Coverage for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_code_coverage.htm). To promote a package version to the released state, run the `sf package version promote` Salesforce CLI command. For step-by-step instructions on promoting a package version, see [Release a Second Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver_promote.htm). After a package version is promoted, you can install it in either a production org or development orgs, and can be distributed to your customers. For every minor package version, you can promote only one beta version. For example, if you create several beta versions of package version 2.3, only one of those versions can be promoted. After promoting package version 2.3, start your new development using version number 2.4. After a package version is promoted to the released state, you can't reverse the promotion. If you discover you don’t want to distribute a version you promoted, you can’t reverse that version back to the beta state. To ensure that that version isn’t inadvertently shared and installed in a customer org, we recommend you use the `sf package version update` Salesforce CLI command and set the installation key to something cryptic and difficult to guess. **See Also** - [Considerations for Promoting Packages with Dependencies](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_considerations_pkg_dependency.htm) - [Release a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver_promote.htm) - [Code Coverage for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_code_coverage.htm) # Get Started with AgentExchange App Analytics AgentExchange App Analytics provides usage data about how subscribers interact with your AgentExchange managed packages and packaged components. You can use these details to identify attrition risks, inform feature development decisions, and improve user experience. **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). Usage data from [Government Cloud and Government Cloud Plus](https://www.salesforce.com/solutions/industries/government1/products/government-cloud/) orgs isn’t available in App Analytics. App Analytics is available for first- and second-generation (1GP and 2GP) managed packages that passed security review and are registered to a License Management App. Usage data is provided as package usage logs, monthly package usage summaries, or subscriber snapshots. All usage data is available as downloadable comma-separated value (.csv) files. To view the data in dashboard or visualization format, use [CRM Analytics](https://help.salesforce.com/articleView?id=bi_explorer.htm) or a third-party analytics tool. In a 24-hour period, you can download a maximum 20 GB of AgentExchange App Analytics data. - **[App Analytics Use Cases](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-use-cases.md)** To achieve your business objectives, use App Analytics across your teams. Read this guide to understand common use cases and how to map App Analytics data to sample product features. - **[Enable App Analytics on Your Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-enable-2gp.md)** Activate AgentExchange App Analytics on your second-generation (2GP) managed package to access AgentExchange App Analytics package usage logs and subscriber snapshots. Package usage summaries are available by default. - **[Download Package Usage Logs, Package Usage Summaries, and Subscriber Snapshots](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-download-mp-logs.md)** To request package usage logs, monthly package usage summaries, and subscriber snapshots, use the AppAnalyticsQueryRequest object. Usage logs, usage summaries, and subscriber snapshots are downloadable comma-separated value (.csv) files. - **[Considerations for Custom Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-custom-interactions.md)** Easily create and log custom interactions on your managed package using Apex. As subscribers interact with your package and your Apex code is executed, the custom interactions that you defined are logged. Retrieve your custom interactions in your package's AgentExchange App Analytics usage logs and usage summaries. - **[AgentExchange App Analytics Best Practices](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-best-practices.md)** To plan and maximize your AgentExchange App Analytics query strategy, follow our best practices. First, use file compression to reduce your data results file size. Second, schedule and automate your regular App Analytics queries. Third, plan, schedule, and automate catch-up queries to supplement your regular query data. - **[Package Usage Summaries](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-managed-package-usage-summaries.md)** Package usage summaries provide high-level metrics by calendar month. Discover how many users access your package and which operations they perform. - **[Package Usage Logs](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-managed-package-log-files.md)** Analyze adoption and user behavior, then make informed feature development decisions based on data from package usage logs. AgentExchange App Analytics tracks UI, API-based, Lightning-based, and Apex operations, and it logs each CRUD operation on components and custom objects in packages. Events from sandbox and trial orgs are tracked in package usage logs. Events from scratch orgs aren’t tracked. - **[Subscriber Snapshots](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-subscriber-snapshots.md)** Subscriber snapshots give you a point-in-time summary of subscriber activity. Use subscriber snapshots to see usage trends by org and package. - **[Test Custom Integrations](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-test-custom-integrations.md)** To test your custom integrations in a nonproduction environment, use AgentExchange App Analytics Simulation Mode. Submit an App Analytics query request and receive sample usage data. - **[AgentExchange App Analytics Developer Cookbook](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-cookbook/app-analytics-cookbook-intro.md)** Delve deeper into your AgentExchange App Analytics managed package usage data by creating key performance indicators (KPIs). First, complete some prerequisites and retrieve your App Analytics data. Next, prepare your CRM Analytics environment. Finally, to build your KPIs, complete App Analytics recipes. # Get Started with the AgentExchange Go-To-Market App Now that you understand what the Go-To-Market (GTM) app is and how it works, it’s time to learn how to use it. We cover the main steps, from creating your account to receiving payouts. To see the GTM app in your Partner Business org (PBO), submit your interest to Salesforce. Our partner team reviews your application and contacts you to get started. | User Permissions Needed |   | | ------------------------------------------------------------------ | -------------------------------------------- | | The view and configure the AgentExchange Go-To-Market App: | View AgentExchange Go-To-Market App | | To read and create offers from the AgentExchange Go-To-Market App: | Manage AgentExchange Go-To-Market App Offers | **important:** You must include the permissions in a permission set and assign it to users. To do so, follow the steps in [Create Permission Sets](https://help.salesforce.com/s/articleView?id=platform.perm_sets_create.htm&type=5). To have users who manage offers, but can't create them, include only the Manage AgentExchange Go-To-Market App Offers perm in their permission set. If a user should be able to create offers, add both permissions to their permission set. ## Onboard to the AgentExchange Go-To-Market App Before you can see the Go-To-Market (GTM) app in your PBO, submit your interest and receive approval. 1. Confirm your eligibility: Check to make sure that you meet the criteria listed in Prerequisites and you've reviewed the [Prerequisites and Considerations](https://developer.salesforce.com/docs/platform/isvforce/guide/partner-marketplace-considerations-prerequisites.md). 2. Submit your interest: Contact your Partner Account Manager (PAM) or contact Salesforce Customer Support. 3. Wait for confirmation: Our team will review your submission and follow up with next steps and onboarding details. ## Locate the Go-To-Market App To start, access the Go-To-Market (GTM) app in your Partner Business org (PBO). The app contains the tools that you must configure your products, create offers, and view invoices and payouts. From the App Launcher, enter `Go-To-Market App` in the search box and select **AgentExchange Go-To-Market App**. ## Create and Connect Your Stripe Account Salesforce uses Stripe to facilitate payment processing within the Go-To-Market (GTM) app. The app requires a Stripe account to use specifically with the GTM app. Stripe handles invoicing, payment processing, and automated payouts for transactions that occur within the app. ### Step 1: Create Your Stripe Account 1. From Setup, in the Quick Find box, enter `AgentExchange Go-To-Market App`, and select it. 2. From the GTM app, next to Create a Stripe Account, click **Create a Stripe Account** to go to Stripe. 3. Stripe creates your automatically. You can see a success confirmation message at the top of the page. To create a Stripe account for use with the GTM app, agree to Stripe’s terms of service. ### Step 2: Connect Your Stripe Account 1. Next to Connect the Stripe Account, click **Manage Connection**. 2. You’re automatically redirected to Stripe’s onboarding setup page. Enter your email address and phone number. 3. Verify your information with the code provided. 4. Fill in your business type details. 5. Fill in your business tax information and essential details. 6. Fill in your personal details. 7. Select an institution where Stripe sends your payments. 8. Enter your W-9 form information. 9. Click **Submit**. 10. Verify that your information is correct and then click **Agree and Submit**. Your Stripe account for the GTM app is ready to go. If you have trouble or questions, check out the [Stripe documentation](https://docs.stripe.com/connect/custom/hosted-onboarding) for more information. ### Step 3: Manage Your Go-To-Market App Account You can view and edit the company and personal information that you used to create your Stripe account from the Account Management tab. Account Management is where you find all your business details, including business type, address, phone number, public details, and account representation. ## Create and Connect Products Products form the foundation of your GTM app configuration. Every offer and order references a product created in your Partner Business org (PBO). Create products and map them to managed package licenses for Partner Applications approved for distribution through the GTM app. To create products, make sure that the corresponding Partner Application is approved for distribution via the GTM app and listed as a product in your Partner Product Catalog. ### Create Products Create a Partner Provision Product (PPP) record for each item you plan to sell through the GTM app. 1. From the GTM app, go to the Products tab. 2. Click **New**. 3. Enter a product name. We suggest a customer-friendly name, as this label is the product name that appears on the customer facing invoice. 4. Select and associate a Partner Product Catalog. This list includes products that you currently have contracted with Salesforce for distribution via the GTM app. 5. Save your product. After saving, the Partner Provision Product becomes available for mapping package licenses. ### Map Package Licenses to Products Each product maps to the corresponding license in your managed package. Mapping makes automated provisioning possible when a customer purchases your product. To map a partner product license: 1. From the Products tab, select a product. 2. Go to the Related tab. 3. In the Partner Product Licenses section, select **New**. 4. The product you selected in step one auto-populates. 5. Enter the Package License ID, for packaged licenses, or the Permission Set ID, for permission set licenses. 6. Save your changes. Map all partner product licenses that you want to include for provisioning in the managed package. ## Create and Send Offers After you create products and map them to licenses in the Go-To-Market (GTM) app, you can begin creating offers to send to customers. An offer represents the terms that a customer reviews and accepts within their Salesforce org. When a customer accepts an offer, Salesforce automatically generates an order and issues an invoice on your behalf. There are two offer types, initial and add-on. Initial offers represent a new offer and contract terms, whereas add-ons represent an addition to an existing offer. **note:** Currently, the GTM app supports: - Net-new customers sales - 12-month contract terms by default, with 24-month and 36-month multi-year terms available for enabled partners. - NET30 payment terms - Upfront annual billing ### Create an Initial Offer Use the Offers tab to create offers, configure pricing, and send offers to customers for review. 1. From the GTM app, go to the Offers tab. 2. Click New. 3. Search for and select your customer. The offer type fills automatically. If you have an existing offer out to the customer, the type is **Add-On**. If not, the type is **Initial**. 4. Enter the offer details that you previously negotiated with the customer. 1. Select an opportunity, if applicable. 2. Select your Partner Term Set. 3. For Contract Term, enter `12`. If multi-year contract terms are enabled for your account, you can also select `24` or `36`. Multi-year terms aren't available by default. Work with your PAM to have them enabled for your account. 4. Enter the Service Start Date. This is the date that the service starts if the customer accepts the offer. 5. Enter the Valid Until date, which indicates the date the offer expires. 6. Enter your Partner PO Number and Customer PO Number, if applicable. **note:** Billing frequency depends on contract length. 12-month contracts bill upfront. 24-month and 36-month multi-year contracts bill annually, once per year over the term. 5. Enter the terms and conditions for the offer. 6. Enter the customer details. 7. Enter the Customer Org ID where your licenses apply. 8. Enter the Offer Recipient Email Address and a separate Billing Email Address, if applicable. Both email address fields receive an email with the sent offer. The Recipient Email Address field indicates the person either approving or rejecting the offer. Use the Billing Email Address to send a copy of the offer to the person responsible for accounting, typically in the finance department. This email also receives the Stripe invoice. 9. Click **Save**. The offer remains in draft status until you add products and send it. ### Create an Add-On Offer Use add-ons to sell more licenses or entirely new products to your existing GTM app customers, mid-contract. When you create an add-on offer, the system ties it to your customer's existing order and populates the end date to match the initial contract. The subtotal is calculated automatically and prorated based on the add-on start date and the initial order end date. 1. From the GTM app, go to the Partner Offers tab. 2. Click New. 3. Select your customer. When the system detects an existing order, the offer type defaults to Add-On and pulls information from the initial contract. You can edit: 1. Partner PO Number 2. Customer PO Number 3. Order Start Date 4. Valid Until Date 5. Opportunity 6. Email Recipient 4. Click **Save**. The offer remains in draft status until you add products and send it. ### Create a Renewal Offer Create a renewal offer to keep your customer relationship active before it lapses. A renewal offer replaces the customer's current contract: it pre-populates with the customer's full current entitlement, the initial order and all add-ons, so you adjust products, quantities, pricing, and contract terms instead of rebuilding the contract from scratch. When the customer accepts, Salesforce invoices the customer one day before the contract anniversary date, and provisioning runs automatically on the anniversary date. **note:** A renewal offer is a complete cancel-and-replace action. Include every product and license that the customer keeps going forward. The system de-provisions any product left off the renewal offer. On the new service start date, Salesforce calculates the net license delta for the account and provisions or de-provisions licenses to match. 1. From the GTM app, go to the Partner Offers tab. 2. Click **New**. 3. Select your customer. When the system detects an existing contract, set the offer type to Renewal. The offer pre-populates with the customer's current entitlement. 4. Review the pre-populated offer items. Edit products, quantities, and unit prices. 5. Update the remaining offer details as needed, including the contract term, Partner PO Number, Customer PO Number, Valid Until Date, and Offer Recipient Email Address. You can't change the Service Start Date on a renewal offer. It's automatically set to the contract anniversary date. 6. Click **Save**. The offer remains in draft status until you add products and send it. After you add products (see Add Products to an Offer), review the summary of changes. This summary highlights the product, quantity, and pricing changes between the customer's current contract and the renewal offer. Confirm the changes before you click **Send to Customer**. #### Example A customer's current contract includes 10 licenses for Product A and 5 licenses for Product B. Their renewal offer includes only 10 licenses for Product A. When the customer accepts, Salesforce de-provisions the 5 Product B licenses on the new service start date. #### Enable Renewal Expiration Notifications For new and existing partners, the partner order expiration notifications are disabled by default. Because these notifications are flow templates, you must clone a template before you can activate it. To enable the notifications: 1. From Setup, enter Flows in the Quick Find box, and select Flows. 2. Locate the Go-To-Market renewal partner order expiration flow template and open it. 3. Select Save As New Flow. 4. Open the cloned flow, enter a name and label for the flow, and then click **Activate**. ### Add Products to an Offer 1. From your offer, go to the Related tab. 2. From Partner Offer Items, click **New**. 3. Search for and select a Partner Provision Product (PPP). 4. Enter a product quantity and unit price per month. 5. Optionally, enter a Partner PO Number. 6. Click **Save**. 7. Repeat steps two through six to add more products. #### Example If you’re adding products to an add-on offer, you can increase the amount of an existing product or select a new item. If you add products, they are in addition to the products previously sold. For example, if the initial order included 10 licenses for Product A, and you add 15 licenses for Product A to an add-on order, your customer now has 25 licenses for Product A. ### Review and Send Offers Before sending the offer to your customer, carefully review all details. After an offer is sent via the GTM app, it can’t be edited or withdrawn during the offer period. It’s important to validate everything up front, before you click send. 1. Carefully review: 1. Product quantities and unit prices 2. The contract start date 3. Billing and offer recipient email addresses 4. Total offer amount 5. Included products 2. Ask your customer: 1. To follow the steps outlined in [Receive Private Offers from AgentExchange Partners](https://developer.salesforce.com/docs/atlas.en-us.appExchangeInstallGuide.meta/appExchangeInstallGuide/appexchange_install_private_offers.htm). 2. To check that the email addresses entered for the Offer Recipient and Billing Email Address fields have user records in the customer’s org. Those user records must have the Manage Billing user permission. 3. If they qualify for tax exempt status. If yes, ask if they’ve provided Salesforce with a tax exemption certificate in the past or confirm that they’ve done so before accepting the offer. Tax exemptions can’t be applied after the customer accepts the offer. 3. When the offer is ready and reviewed, click **Send to Customer**. The customer receives an email directing them to their Salesforce org, where they can accept or reject the offer. After you send the offer, the status moves to sent and you can’t edit the offer. ### Manage Offers The Partner Offers tab provides a place to view and manage all existing offers. The list view shows key details such as status, customer information, and contract terms. This view helps you monitor which offers are awaiting customer action and which were accepted and converted into orders. To get a more detailed view, including products and pricing, and customer contract information, select an offer and select the Offer Details tab. #### Offer Statuses As your offer moves through the cycle, you can track its progress via the status field. Each status indicates a different offer state and can be helpful for understanding both current and historical offer information. | Status | Description | Use | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Draft | New offer created and still editable. | Make edits before sending your offer. When an offer moves to a status other than draft, it can’t be edited. | | Sent | Offer sent to the customer and waiting for customer action. | If the status is sent, the customer hasn’t acted. Watch for this change to see when a customer responds to the offer. | | Withdrawn | Offer withdrawn from consideration before customer responds. | If the customer hasn’t responded by accepting or rejecting an offer, it can be withdrawn. Withdrawing the offer means that the customer can’t respond and the offer is void. Withdrawal can’t be reversed. If you want to continue the transaction, you must create a new offer. | | Accepted | The customer accepts the offer and a corresponding order is created. | Now, your offer becomes an order and continues its journey through the lifecycle. | | Rejected | The customer rejects the offer. | The rejected status provides historical visibility. | | Error | There’s a problem related to the offer. Example error causes:
  • Salesforce couldn’t send the offer
  • The customer hasn’t opted in to receive offers
  • Validation errors
| The error status provides insight into issues that occur with an offer. Customers or partner can address some errors, Salesforce must address others. | | Expired | The offer expired before the customer responded. | The expired status provides historical visibility. | | Void | The offer is void and neither the customer or the partner can take action on it. | The void status is an automated process used by Salesforce to nullify an offer. | ## View and Track Orders To view your orders, go to the Orders tab. From there you can see a list of your orders, including the provisioning status, timeline, and order subtotal. You can select an Order ID to open the record and see a comprehensive view of the order details. From the Related tab, you can find a list of the products included in the order and order transactions. ### Partner Order Statuses Similar to offers, you can track order progress via the status field. | Status | Description | Use Case | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | New | Salesforce creates an order in the GTM app, but the order hasn’t fully synced into Salesforce’s internal systems. | Use this status to see when a customer accepts an offer. | | Processing | The order is in Salesforce’s internal systems for further processing and activation. | Provides visibility into successful order activation. | | Activated | Salesforce processes and activates the order. On the start date, Salesforce provisions the order and, within a day of the start date, sends an invoice. | Provides visibility into successful order activation. | | Error | There’s a problem related to the order. Example error causes:
  • Salesforce couldn’t process the offer
  • Validation errors
| The error status provides insight into issues that occur with an order. The partner can address some errors, Salesforce must address others. | | Expired | Order end date is in the past. | Provides historical context for past orders. | # Get Started with the Environment Hub Configure the Environment Hub so that users at your company can access the app to create and manage member orgs. Then connect existing orgs to the hub and create SSO user mappings. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, and **Unlimited** Editions| # Get Started with the License Management App To start managing leads and licenses with the License Management App (LMA), complete these installation and configuration steps. | Availability | | ------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, and **Unlimited** Editions | - **[Install the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-install-app.md)** The License Management App (LMA) is a managed package that is installed in all partner business orgs. The org that the LMA is installed in is called the License Management Org (LMO). - **[Associate a Package with the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-associate-package.md)** To receive lead and license records for your package, you connect your License Management Org (LMO), your package, and the Salesforce Partner Console. Your LMO is the Salesforce org where the License Management App (LMA) is installed. - **[Configure Permissions for the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-configure-app.md)** Determine who needs access to the License Management App (LMA), and set object permissions. Consider using a permission set to assign user permissions. # Get To Know the AgentExchange Listing Builder To create or edit an AgentExchange listing, use the Listing Builder in the Partner Console. Before you start building, get to know the sections of the Listing Builder and the tasks you can complete in each section. ![A screenshot of the Listing Builder showing the list of sections](https://developer.salesforce.com/docs/media/appexchange_listing_builder_sections.png) This table describes the Listing Builder sections, including what you do in each and which listing types they're used for. | Section | What you do: | Available on these listing types: | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------- | | Fill In the Basics | Give your listing a title and provide a brief description that quickly tells the customer how they can benefit from your offering. Select any required Salesforce products that customers need and any compatible products that can enhance their experience with your offering. | Solution and consultant listings | | Set Pricing | Set your pricing model, payment management, and collection strategy. After completing your pricing and payment strategies, submit your listing for approval. | Solution listings only | | Add Details | Provide additional details to describe your offering and to help users find your listing through AgentExchange’s search and filtering features. You can also enter the terms and conditions that apply to your listing. If you have a logo to represent your listing or your company, you can add it in the Include Visuals section. | Solution and consultant listings | | Link Your Solution | Select the solution to link to this listing. You can link a solution undergoing security review, but you can't publish on AgentExchange until it passes. Then, select the installation methods. | Solution listings only | | Grow Your Business | Configure your AgentExchange listings to collect leads and deliver them to your Salesforce org. Specific customer interactions, such as watching your listing’s demo video or downloading a trial, can trigger lead collection. See [AgentExchange Leads](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-leads.md). | Solution and consultant listings | | Listing Status and Listing Summary | View the status for each step in the publishing process. If you’re missing information or an error is detected, a warning icon highlights the incomplete section. When all sections are completed, you can publish your listing to AgentExchange. You can also remove published listings from AgentExchange. | Solution and consultant listings | # Get Your AgentExchange Listing Approved Before you can publish your AgentExchange listing, Salesforce must make sure that it complies with our partner brand guidelines and partner program policies. After you complete your solution’s Fill in the Basics and Price Your Solution steps in the Partner Console, you can submit your listing for approval. ![The AgentExchange Listing Builder Get Approved step with an Approval Status banner, and Submit, Back, and Next buttons](https://developer.salesforce.com/docs/media/ready_to_submit.png) We review the info that you submit. After we approve your listing, its approval status is updated automatically. ![The Get Approved section with a listing Approval Status: Congratulations! Your listing is approved. Keep up the great work. Continue editing your listing. message, and Back and Next buttons](https://developer.salesforce.com/docs/media/approved_state.png) ## Sign the Required Partner Application Distribution Agreement After your listing is approved, you must sign a Partner Application Distribution Agreement (PADA) before it can be published. - If your listing uses AgentExchange Checkout, you must sign a clickthrough PADA. See [Sign the Partner Application Distribution Agreement](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-listing-approvals-sign-agreement.md). - If your listing is a Paid solution that doesn't use Checkout, or if you’re listing a Freemium or Paid Add-On Required solution, you must sign a PADA offline, outside of the Partner Console. Check with your account manager for details. ## Resubmit for Approval After Editing Your Listing What happens if you want to edit your listing after you’ve submitted it for approval? It depends on what you edited and on your listing’s specifications. If you change your solution’s listing in one of these ways, save your edits and then resubmit your listing for approval. - Pricing model from Free to another pricing model - Pricing model from another pricing model to Free - Payment management from Checkout to non-Checkout - Payment management from non-Checkout to Checkout - Pricing plan units ## Resubmit for Approval After Initial Non-Approval Sometimes your listing isn’t approved on the first try. Edit your listing and go to the ‘Get Approved’ step to see specific feedback that you must fix. After you update your listing, return to ‘Get Approved’ and click Resubmit. ![The AgentExchange Listing Builder Get Approved step with a highlight on Resubmit, and with an Approval Status message and Back and Next buttons](https://developer.salesforce.com/docs/media/resubmit.png) **See Also** - [*Trailhead: AgentExchange Publishing for Partners*](https://trailhead.salesforce.com/content/learn/modules/appexchange-partners-publishing) # Go-To-Market App Transaction Lifecycle Before you begin configuring products or creating offers, it’s important to understand the sequence of events that occur during a transaction. The lifecycle explains what you can expect from creating an offer, to billing, provisioning, payment collection, and payouts. Here’s a visual example of the transaction flow. A transaction consists of two primary processes, the offer and the order. The offer phase ends when a customer accepts an offer, which is when the order phase begins. We outline each stage individually to help you anticipate the sequence of events, the actions that Salesforce automates, and the tasks that require partner or customer involvement. - Offer lifecycle: Tracks the offer from creation to customer acceptance. The process includes: - Offer creation - Sending the offer to a customer - Customer acceptance - Converting the offer into an order - Order lifecycle: Tracks the order from creation to partner payout. The process includes: - The transition from offer to order - Provisioning - Invoicing - Payment settlement - Payouts ## Offer Lifecycle The offer serves as the source of truth for downstream processes. |Offer Stage|Description| |-----------|-----------| |Draft offer|The partners define pricing, product quantities, order start date, and included items.| |Send offer|The partner sends the finalized offer to the customer. The customer receives an email notification and can view the offer on the Your Account page.| |Customer decision|The customer reviews and either accepts or rejects the offer.| |Order conversion|When accepted, the offer status changes to Converted, and Salesforce creates a corresponding Partner Order. The order record drives billing and provisioning and includes applicable tax.| ## Order Lifecycle After a customer accepts an offer, Salesforce automates the steps required to fulfill, bill, and report on the transaction. The Partner Order serves as the operational record that ties provisioning and billing together.
StageDescription
Order creationSalesforce creates a Partner Order record with the contracted products and quantities. The Partner Order record is based on the Partner Offer record and is read-only.
Provisioning

The provisioning engine uses fields on the Partner Order record to determine what products to provision, when provisioning begins, and where to allocate licenses. The provisioning status is available on the order record.

Example:

When the Service Order Start Date is equal to today and the Partner Service Order Status has a status of Activated, the engine provisions the licenses to the specified org.

InvoicingSalesforce automatically generates and sends the customer invoice, reflecting the products and pricing defined in the offer.

  • The invoice includes applicable sales tax based on the shipping address of the customer.

  • On the date specified in the Order Start Date field, Salesforce sends the invoice to the customer. The Billing Lead Time field, or prebill days, is one day.

Payment CollectionStripe collects customer payment on Salesforce’s behalf.
Partner PayoutAfter payment settles, Stripe, after deducting the Salesforce percentage net revenue (PNR) specified in the partner’s agreement with Salesforce, remits the partner’s revenue to the partner’s account, on behalf of Salesforce.
 # Grow Your AgentExchange Business Grow your AgentExchange business with listing best practices. Collect leads when customers interact with your listing. Learn how AgentExchange search works. Optimize your listing to boost its search ranking. # Guidance for Package Version Numbering Use package versions to evolve your managed package, and release subsequent package versions without breaking existing package users. Every package version is a fixed snapshot of the package contents and related metadata. While the format for package version number is predetermined, how you determine a version number, and whether you enforce uniqueness on package version numbers is left to package developers. The format for package version numbers is MAJOR.MINOR.PATCH.BUILD. Every package version has both a version number that you determine (for example, 2.2.0.1), and a unique [subscriber package version ID](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_plan_pkg_types_pkg_ids.htm) (starts with 04t) that is auto-assigned when you create the package version. Before you promote a particular MAJOR.MINOR.PATCH package version, it’s possible to create multiple package versions that have unique 04t IDs, but all share the same version number, for example 2.2.0.1. There are a few approaches you can take to ensure each package version number is unique. Keep reading to learn more, but let’s start by learning how to specify a package version number. ## How Do I Specify the Package Version Number? The `versionNumber` attribute in your `sfdx-project.json` [project configuration file](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm) determines the version number that is assigned the next time you create a managed 2GP version. Before creating a new package version, you must manually increment this attribute in the project file. If you don't increment the versionNumber, then you can wind up with multiple package versions with the same version number, but unique subscriber package version IDs (starts with 04t). ```nolang { "namespace": "exp-mgr", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "61.0", "packageDirectories": [ { "path": "util", "default": true, "package": "Expense Manager - Util", "versionName": "Summer ‘24", "versionDescription": "Summer 2024 Expense Manager Util Package", "versionNumber": "2.2.0.1", "definitionFile": "config/scratch-org-def.json" }, ``` ## Use the Keyword NEXT to Enforce Unique Build Numbers As best practice, don’t create multiple package versions that have the same MAJOR.MINOR.PATCH.BUILD version number. An easy way to ensure the build portion of your version number is unique is to use the keyword `NEXT` when you set the version number in your `sfdx-project.json` file. This way, you don’t have to manually increment the version number when you want to create a new package version. ```nolang { "namespace": "exp-mgr", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "61.0", "packageDirectories": [ { "path": "util", "default": true, "package": "Expense Manager - Util", "versionName": "Summer ‘24", "versionDescription": "Summer 2024 Expense Manager Util Package", "versionNumber": "2.2.0.NEXT", "definitionFile": "config/scratch-org-def.json" }, ``` ## Use the CLI Flag to Override a Package Version Number You can also override the version number listed in your project file, by using the `--version-number` flag when you create a new package version. ```nolang sf package version create -p "my2gp" -–version-number 2.2.0.NEXT ``` By using the keyword NEXT with the `--version-number` flag in the CLI, you ensure the build portion of the version number is unique. **note:** Keep in mind, the `--version-number` flag doesn't update your `sfdx-project.json`. To keep the VersionNumber in the project file current, update it manually. ## What Happens to Version Numbering After You Promote a Package Version? After you promote a package version with a specific MAJOR.MINOR.PATCH version you can’t continue to create package versions that use that same MAJOR.MINOR.PATCH version number. If you attempt to do so, you receive an error message. ## How Do I Determine Whether to Use a New Major, Minor, or Patch Version? While there are restrictions on what changes are allowed in a [patch version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_patch_version.htm), determining what qualifies as a major or minor change is largely up to you. When introducing major changes, increase the major version number, and increase the minor version number when making smaller improvements. # Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs Occasionally, you want to include custom permissions or custom objects in a package but not show them to your subscribers. For example, if you're piloting a feature for a few select orgs, and want to hide custom permissions and custom objects related to the pilot feature. **note:** Check with your company’s legal team before releasing hidden functionality. To hide custom objects when creating your package, set the value of their Visibility field to `Protected`. After you've set the visibility to Protected, you can later update it to Unprotected. To change the visibility of an object, use the [CustomObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) Metadata API and update the `visibility` field. To hide custom permissions when creating your package, from Setup, enter `Custom Permissions` in the Quick Find box. Select **Custom Permissions** | **_Your Custom Permission_** | **Edit**. Enable **Protected Component**, and then click **Save**. After your package is installed, use the `System.FeatureManagement.changeProtection()` Apex method to hide and unhide custom objects and permissions. **note:** After you’ve released unprotected objects to subscribers, you can’t change the visibility to `Protected`. **To hide custom permissions in released packages:** - `System.FeatureManagement.changeProtection('YourCustomPermissionName', 'CustomPermission', 'Protected');` **To unhide custom permissions and custom objects in released packages:** - `System.FeatureManagement.changeProtection('YourCustomPermissionName', 'CustomPermission', 'Unprotected');` - `System.FeatureManagement.changeProtection('YourCustomObjectName__c', 'CustomObject', 'Unprotected');` **See Also** - [Protected Components in Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_protected_components.htm) - [_Metadata API Developer Guide_: CustomObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) - [_Apex Reference Guide_: Feature Management Methods, changeProtection](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm#apex_System_FeatureManagement_changeProtection) # Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs Occasionally, you want to include custom permissions or custom objects in a package but not show them to your subscribers. For example, if you're piloting a feature for a few select orgs, and want to hide custom permissions and custom objects related to the pilot feature. **note:** Check with your company’s legal team before releasing hidden functionality. To hide custom objects when creating your package, set the value of their Visibility field to `Protected`. After you've set the visibility to Protected, you can later update it to Unprotected. To change the visibility of an object, use the [CustomObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) Metadata API and update the `visibility` field. To hide custom permissions when creating your package, from Setup, enter `Custom Permissions` in the Quick Find box. Select **Custom Permissions** | **_Your Custom Permission_** | **Edit**. Enable **Protected Component**, and then click **Save**. After your package is installed, use the `System.FeatureManagement.changeProtection()` Apex method to hide and unhide custom objects and permissions. **note:** After you’ve released unprotected objects to subscribers, you can’t change the visibility to `Protected`. **To hide custom permissions in released packages:** - `System.FeatureManagement.changeProtection('YourCustomPermissionName', 'CustomPermission', 'Protected');` **To unhide custom permissions and custom objects in released packages:** - `System.FeatureManagement.changeProtection('YourCustomPermissionName', 'CustomPermission', 'Unprotected');` - `System.FeatureManagement.changeProtection('YourCustomObjectName__c', 'CustomObject', 'Unprotected');` **See Also** - [Protected Components in Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg1_dev/packaging_protected_components.htm) - [_Metadata API Developer Guide_: customObject](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/customobject.htm) - [_Apex Reference Guide_: Feature Management Methods, changeProtection](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_FeatureManagement.htm#apex_System_FeatureManagement_changeProtection) # How Does a Post Install Script Work? A post install script is an Apex class that implements the `InstallHandler` interface. This interface has a single method called `onInstall` that specifies the actions to be performed on installation. ```apex global interface InstallHandler { void onInstall(InstallContext context) } ``` The `onInstall` method takes a context object as its argument, which provides the following information. - The org ID of the organization in which the installation takes place. - The user ID of the user who initiated the installation. - The version number of the previously installed package (specified using the `Version` class). This is always a three-part number, such as 1.2.0. - Whether the installation is an upgrade - Whether the installation is a push The context argument is an object whose type is the `InstallContext` interface. This interface is automatically implemented by the system. The following definition of the `InstallContext` interface shows the methods you can call on the context argument. ```apex global interface InstallContext {  ID organizationId(); ID installerId(); Boolean isUpgrade(); Boolean isPush();  Version previousVersion(); } ``` **Version Methods and Class** You can use the methods in the `System.Version` class to get the version of a managed package and to compare package versions. A package version is a number that identifies the set of components in a package. The version number has the format _majorNumber.minorNumber.patchNumber_ (for example, 2.1.3). The major and minor numbers increase to a chosen value during every non-patch release. Major and minor number increases always use a patch number of 0. The following are instance methods for the `System.Version` class. | Method | Arguments | Return Type | Description | | ----------- | ------------------------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `compareTo` | System.Version _version_ | Integer | Compares the current version with the specified version and returns one of the following values: zero if the current package version is equal to the specified package version, an Integer value greater than zero if the current package version is greater than the specified package version, or an Integer value less than zero if the current package version is less than the specified package version. If a two-part version is being compared to a three-part version, the patch number is ignored and the comparison is based only on the major and minor numbers. | | `major` | | Integer | Returns the major package version of the calling code. | | `minor` | | Integer | Returns the minor package version of the calling code. | | `patch` | | Integer | Returns the patch package version of the calling code or `null` if there’s no patch version. | The `System` class contains two methods that you can use to specify conditional logic, so different package versions exhibit different behavior. - `System.requestVersion`: Returns a two-part version that contains the major and minor version numbers of a package.Using this method, you can determine the version of an installed instance of your package from which the calling code is referencing your package. Based on the version that the calling code has, you can customize the behavior of your package code. - `System.runAs(System.Version)`: Changes the current package version to the package version specified in the argument. When a subscriber has installed multiple versions of your package and writes code that references Apex classes or triggers in your package, they must select the version they’re referencing. You can execute different code paths in your package’s Apex code based on the version setting of the calling Apex code making the reference. You can determine the calling code’s package version setting by calling the `System.requestVersion` method in the package code. # How Does AgentExchange App Analytics Data Flow? As your customers use your managed packages, they produce data. Their usage data is collected daily in our data lake from each Salesforce instance. Usage data arrives to our data lake throughout the day. From time to time, there can be data arrival delays. Also, data builds and timestamps vary by data type. For these reasons, to optimize your data retrieval, plan out your AgentExchange App Analytics query strategy. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | Because Salesforce instances and your subscribers are located around the world, the time of data collection varies by region. EU (EMEA) data arrives first, then North America (NA) data. Data from Asia Pacific (AP) instances arrives last. Our AgentExchange App Analytics jobs run on local instance times on a non-peak schedule. Depending on when you query for your data and where your customers are located, sometimes you retrieve 100% of your data at one time. Other times you must issue more queries to retrieve it all. ![Your managed package and customer data flows into the Salesforce Data Lake and into an App Analytics query request.](https://developer.salesforce.com/media/pkg2_dev/app_analytics_data_flow.png) Data delivery to and arrival in our data lake also depends on factors that can affect a given instance, such as the health of the instance or technical dependencies. Ordinarily you can expect all your org data to arrive in the data lake by `23:00` Coordinated Universal Time (UTC) the day after it was recorded. However, occasionally, there can be delays. Each AgentExchange App Analytics data type is also compiled at different times. | Data Type | Build Information | Example | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Subscriber Snapshots |
  • Snapshots use data collected at approximately `01:00` instance local time.
  • Snapshots are generated nightly at approximately `03:00` instance local time.
  • All timestamps are normalized to `00:00 UTC`of that day.
| For the March 1, 2021 snapshot:
  • All records have this timestamp: `2021-03-01T00:00:00Z`.
  • All data normally arrives by March 2, 2021 `23:00 UTC.`
| | Package Usage Summaries |
  • Summaries use data collected for an entire month.
  • Summaries are built monthly.
  • All timestamps are normalized to `00:00 UTC` on the last day of the month.
| For the March 2021 summary available on April 1, 2021:
  • All records have this timestamp: `2021-03-31T00:00:00Z`.
  • All data normally arrives by April 1, 2021 `23:00 UTC`.
  • In this example, we recommend that you query for your summary data on April 3, 2021 or later. We recommend a 2-day query delay to ensure that all of your subscriber data from all worldwide instances finished processing.
| | Package Usage Logs |
  • Usage logs use data from the previous day.
  • Usage logs are generated nightly at approximately `05:00` instance local time.
| For the March 1, 2021 log file:
  • All records have precise timestamps associated with when that log event occurred.
  • All data normally arrives by March 2, 2021 `23:00 UTC.`
| # How Does AgentExchange Search Work? Search is one of the most popular ways that Salesforce customers find solutions on AgentExchange. Learn how keyword relevance, semantic meaning, and trust score influence the search results that customers see. Then apply tips to help customers discover your listing when they search for a solution to a business problem. **note:** The AgentExchange team continues to work to improve the search functionality, and partners can expect future updates that will introduce new features and refine existing ones. These updates may impact factors such as listings' rankings and trust scores. To align with the evolving search criteria, stay informed, and regularly review and optimize your listings. ## What Influences AgentExchange Search Results? When someone searches AgentExchange, three factors influence the results they see. Keyword relevance is the most important factor, followed by semantic meaning, and trust score. ![An illustration of a search bar and the three factors that influence search results, which are keyword relevance, semantic meaning, and trust score.](https://developer.salesforce.com/docs/media/appexchange_search_factors.png) ## Keyword Relevance Keyword relevance considers how closely customers’ search terms align with text on your listing. The more that the search terms align with your listing text, the higher its keyword relevance. Title, brief description, highlights, and publisher name are weighed more heavily than other listing text. For example, a customer visits AgentExchange to find an app for administering feedback surveys. Their search includes the terms "feedback" and "surveys". AgentExchange listings that include these words have a higher keyword relevance than listings that don’t. ## Semantic Meaning Semantic relevance uses Salesforce Data 360's vector search capabilities and returns results that are semantically related to a query. It uses natural language processing and machine learning to understand customer queries and how the words are connected. It finds listings that match the customers' business needs even if they use different words. For example, a customer searches for tools to create contracts in real time while negotiating with users over the phone. Instead of requiring the customer to know specific terms like "CLM" or "telephony integration", the semantic search engine understands the business needs. It recognizes that the customer needs contract lifecycle management solutions with real-time communication features and shows relevant apps. ## Trust Score Every app on AgentExchange has a trust score that reflects its quality and reliability. This score helps customers identify well-maintained solutions. Higher trust scores mean more reliable apps that other users recommend. Trust score combines customer feedback with active publisher support. Apps with positive feedback earn higher scores. The score also reflects how actively publishers maintain their solutions, including recent updates and new version releases. ## How Can I Make My Listing Easy to Find When Customers Search AgentExchange? Use these tips to make your listing stand out in the AgentExchange search results. |Factor|Tips| |------|----| |Keyword Relevance|
  • Identify the business problems that your offering solves and include keywords that cover the relevant business needs your listing covers. When you incorporate keywords into your listing, focus on the title, tagline, and brief description.
  • Avoid keyword stuffing. If you pack your listing with too many or unrelated keywords, it’s difficult for customers to understand the value it provides. Plus, it negatively affects the machine learning algorithms.
  • Review the keywords that drive your listing activity by using Marketplace Analytics visualizations. These visualizations help you determine the keywords that are associated with the highest number of tile, video, and demo views. To gauge engagement, regularly review your analytics and improve your offering.
| |Semantic Meaning|
  • In the details of your listing, use descriptive text that reflects how customers search for solutions. Semantic search aims to understand the intent behind search queries and helps customers discover solutions even if they don't use exact keywords.
| |Engagement|
  • Encourage customers to rate and review the app to boost its trust score, as higher ratings contribute to better rankings.
  • Include screenshots, graphic tiles, a video, and a demo to attract more trials of your app. It leads to increased engagement if your listing’s media resonates with the target audience.
| Maintaining a strong search position is a marathon, not a sprint. All search factors work together, and can change over time. Periodically review your listing’s keywords, content, and analytics so that they contribute to machine learning. Make updates to those factors that you control. **See Also** - [Collect AgentExchange Leads](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-leads-intro.md) # How Does an Uninstall Script Work? An uninstall script is an Apex class that implements the `UninstallHandler` interface. This interface has a single method called `onUninstall` that specifies the actions to be performed on uninstall. ```apex global interface UninstallHandler { void onUninstall(UninstallContext context) } ``` The `onUninstall` method takes a context object as its argument, which provides the following information. - The org ID of the organization in which the uninstall takes place. - The user ID of the user who initiated the uninstall. The context argument is an object whose type is the `UninstallContext` interface. This interface is automatically implemented by the system. The following definition of the `UninstallContext` interface shows the methods you can call on the context argument. ```apex global interface UninstallContext {  ID organizationId(); ID uninstallerId(); } ``` # How is locale determined for the orgs I create in the Environment Hub? Your Salesforce user locale determines the default locale of orgs that you create. For example, if your user locale is set to `English (United Kingdom)`, that is the default locale for the orgs you create. In this way, the orgs you create are already customized for the regions where they reside. # How Manageability Rules and Ancestry Impact Upgrades for Second-Generation Managed Packages Before you dive in and create your first second-generation managed package (managed 2GP), it’s important to understand these concepts, and how they affect each other. - Manageability Rules - Package Ancestry - Package Upgrades ## Manageability Rules Each metadata component that you include in a managed 2GP package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is installed in a subscriber’s org. Manageability rules apply at both the component level and at the component attribute level. For example, manageability rules determine whether you or the subscriber can delete a custom field, and more specifically whether either of you can edit the Field Label, Default Value, or other attributes of the custom field. For all first- and second-generation managed packages, we enforce manageability rules during package version creation. If you attempt to make a change that would break a manageability rule for one of the metadata components in your package, your package version creation fails. ## Package Ancestry Second-generation managed packaging offers a flexible linear package versioning model by letting you break your linear versioning and abandon a package version you no longer want to build upon. We call these versioning decisions package ancestry. When you create a package version, you must also specify which package version is the ancestor. In this quick glance at a package ancestry tree, version 1.2 and 1.5 have been abandoned. To dig deeper into this topic, see [Package Ancestors](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_package_ancestor_intro.htm). ![Visualization of a package ancestry tree](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_ancestry_nodes.png) ## How Manageability Rules and Ancestry Impact Package Upgrades Both manageability rules and package ancestry impact package upgrades. During package upgrade we enforce the manageability rule for each new and changed component in your package version. Depending on what you changed when you created the new package version, some metadata is added to the org during package upgrade, other metadata is modified or deleted, and some changes aren’t applied at all. For example, page layouts don’t get updated during package upgrade, so if you change a page layout, only new customers receive your modified page layout. When existing subscribers upgrade their package, they won’t receive that change. Conversely, changes to Apex code or the formula in a formula field are updated during a package upgrade. Package ancestry determines the package upgrade path. This is a complex topic, and we have topics that go deeper into this subject. At a high level the package version you designate as the ancestor determines whether a subscriber can upgrade to that version. Subscribers can upgrade from one package version to another only if the ancestry tree is followed. To learn more, see [Understanding Package Upgrades with Ancestry](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_upgrades.htm). **See Also** - [Package Ancestors for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_package_ancestor_intro.htm) - [Understanding Package Upgrades with Ancestry](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_upgrades.htm) # How Scratch Orgs Fit in the Package Development Workflow Scratch orgs are an essential tool in both developing and testing the app you want to package. Scratch orgs also help with continuous integration (CI) processes to automate package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version into the scratch org, runs Apex tests, and emails the test results to the release manager. ## Develop Your Package in a Scratch Org When developing a package, it’s preferable to use a namespaced scratch org. A namespaced scratch org prepends scratch org metadata with the package namespace. This is true for both metadata you create in the scratch org, and any metadata you deploy to the scratch org. To create a namespaced scratch org, use your Dev Hub org to create the scratch org. Before you create the scratch org: - Ensure that the namespace you plan to use is already [associated with your Dev Hub org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm). - Specify the namespace in your `sfdx-project.json` file. - Create a [scratch org definition file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) and include any features, settings, or limits that your org needs. When you create a scratch org both the namespace and ancestry information listed in `sfdx-project.json` file are pulled into the scratch org. The ancestry information, specified as `ancestorId` or `ancestorVersion` in your `sfdx-project.json` file, seeds the scratch org with manageability rules, and later warns you if you attempt to change metadata in a way that's incompatible with the specified ancestor version. This way, you learn of issues during development instead of during the creation of the next package version. To create a namespaced scratch org that includes ancestor information in the scratch org, run this CLI command. ```nolang sf org create scratch --target-dev-hub MyHub --definition-file config/project-scratch-def.json ``` If you don’t want the ancestor and manageability rules seeded into the scratch org, include the `--no-ancestors` flag when you create the scratch org. When you are ready to create a new package version, see [Create Versions of a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver.htm). ## Test Your Package in a Scratch Org When testing your package, create a scratch org that doesn’t have a namespace. Use the `--no-namespace` parameter when you create the scratch org. ```nolang sf org create scratch --definition-file config/project-scratch-def.json --no-namespace --no-ancestors ``` After you create the scratch org, [install the package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_install_pkg_cli.htm) into the scratch org, and begin testing. ## Enable Data Cloud for Scratch Orgs To use Data Cloud components in scratch orgs or to add these components to a package, Data Cloud for Scratch Orgs must be enabled. Log a case with [Salesforce Partner Support](https://partners.salesforce.com/) and request that Data Cloud for Scratch Orgs be enabled on your Partner Business Org. Data Cloud for Scratch Orgs is only available to scratch orgs associated with the Dev Hub in your Partner Business Org. **See Also** - [_Salesforce DX Developer Guide_: Create Scratch Orgs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_create.htm) - [_Salesforce CLI Command Reference_: org create scratch](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_org_commands_unified.htm#cli_reference_org_create_scratch_unified) - [_Salesforce DX Developer Guide_: Select the Salesforce Release for a Scratch Org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_version_selection.htm) # How Should I Plan My App Analytics Query Strategy? Your detailed query strategy depends on the size and scope of your business and the data types that you’re querying. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | All partners can take advantage of these query strategies. - Choose a data results `FileType` value, and select a corresponding `FileCompression`. With this query strategy, you can choose `gzip` compression for `csv` files or `snappy` column compression for `parquet` files. - Create regularly scheduled, automated queries. - To sweep in late-arriving data, create catch-up queries using the `AvailableSince` field. ## Compress Your Results Files Your App Analytics query plan starts with your results file type and file compression. Data can eat up time and space, so do more with less by specifying the type of file you download. Reduce your data download time by specifying how your results file is compressed. If you don’t specify file type or file compression, your results file defaults to `csv` with no compression for backwards compatibility reasons. If you choose the `parquet` file type, your results file includes data type information for each column. We recommend that you always compress your results files. Choose from these SOAP API `AppAnalyticsQueryRequest FileType` and `FileCompression` value combinations. | FileType | FileCompression | | --------------- | ----------------------------------------------------------------------------------------------- | | `csv` (default) |
  • `none` (default when `FileType` is `csv`)
  • `gzip`
| | `parquet` |
  • `snappy` (default when `FileType` is `parquet`)
  • `gzip`
  • `none`
| **note:** When you download your App Analytics query result data, the HTTP response contains one or two important headers. The Content-Type header indicates the file type (`txt`/`csv` or `application`/`parquet`). For queries with `csv` FileType and `gzip` FileCompression, the Content-Encoding header indicates `gzip` encoding. Modern browsers often decode the `gzip`-encoded file automatically, which results in a saved, uncompressed .csv file. Regardless if the file is automatically decoded or not, its filename extension is .csv. ## Schedule and Automate Your Queries After you determine what queries to run and how often to run them, you want to schedule those queries. The easiest way is via automation. What do we mean by automation? Write code that creates query request records on your schedule, monitors them, retrieves the data, and stores your AgentExchange App Analytics data somewhere. For example, you can store the data in a custom object in your License Management Org. Your automation options include, but aren’t limited to: - Custom API integrations using REST or SOAP API calls - Salesforce DX automation using the CLI - Salesforce flows - Apex triggers For example, automate the retrieval of package usage summaries using Apex triggers. If you want to also automate the retrieval of package usage log data, look to a different storage solution that scales with the data volume the logs contain. ## Create Catch-Up Queries A catch-up query is like a broom, sweeping for data newly added to our data lake. Catch-up queries rely on you already having regular queries in place. For example, on March 2, 2021 `18:00 UTC` you run this regular query that retrieves package usage log data for March 1, 2021: ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-01T00:00:00Z EndTime=2021-03-02T00:00:00Z DataType=PackageUsageLog FileType=csv FileCompression=gzip" ``` Rerun that exact same query on March 3, 2021 `18:00 UTC`, but add the `AvailableSince` field set to the day and time you ran your original query: `2021-03-02T18:00:00Z`. This query is your ad hoc catch-up query. It retrieves any data newly added to the data lake for March 2 since you ran your regular query: ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-01T00:00:00Z EndTime=2021-03-02T00:00:00Z DataType=PackageUsageLog FileType=csv FileCompression=gzip AvailableSince=2021-03-02T18:00:00Z" ``` You can use catch-up queries in many different ways, which we discuss in more detail in the Recommendations section. When creating catch-up queries, keep these considerations in mind. - If `StartTime` is specified, the `AvailableSince` date must be later. - If `EndTime` is specified, the `AvailableSince` date must be later. - All queries must include `StartTime` or `AvailableSince` or both. - `AvailableSince` must be earlier than now. **note:** What happens when you want to create an ad hoc catch-up query, but you forgot when you ran the original query? Use Salesforce CLI and your original query’s `sObjectID` to look up the `QuerySubmittedTime`, like this: `sf data get record --sobjecttype AppAnalyticsQueryRequest --sobjectid 0XIXXXXXXXXXXXXXXX` Set your ad hoc catch-up query `AvailableSince` value to equal the `QuerySubmittedTime`. **See Also** - [Apache Parquet](https://parquet.apache.org/) - [Automate AppAnalytics - AWS Stack](https://medium.com/@kamipatel/automate-appanalytics-aws-stack-74cbebc49d2a) # How to Read App Analytics Package Usage Log Data App Analytics package usage logs contain data about how subscribers interact with your managed package. Your managed package contains packaged components, and each package usage log line describes an interaction that a user has with one of your packaged components. To understand that interaction, analyze each log line—or record—and focus on: what packaged component was accessed, who interacted with that packaged component, and how that packaged component interaction occurred. Finally, analyze the specific interaction data. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [ISV Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). Usage data from [Government Cloud and Government Cloud Plus](https://www.salesforce.com/solutions/industries/government1/products/government-cloud/) orgs isn’t available in App Analytics. - **[Determine What Packaged Component Was Accessed](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-what-component.md)** To analyze a package usage log record, always start with your packaged component. - **[Identify Who Interacted with Your Packaged Component](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-who-interacted.md)** After you identify your packaged component, identify both the subscriber org and the user who triggered the interaction. - **[Identify How a User Interacted with Your Packaged Component](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-how-user-interacts.md)** After you identify your packaged component and who interacted with it, identify how the user interacted with your packaged component. - **[Custom Object and External Object Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-custom-external-objects.md)** When a log record in your package usage log has `custom_entity_type` equal to `CustomObject` or `ExternalObject`, it means that a user performed an action that resulted in a create, read, update, or delete (CRUD) interaction on your object. - **[Lightning Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-lightning-interactions.md)** Each record in your package usage log that has a `custom_entity_type` of `LightningComponent` or `LightningPage` describes an interaction with your packaged Lightning component or page. - **[Apex Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-apex-interactions.md)** Each record in your package usage log that has a `custom_entity_type` of `ApexClass` or `ApexTrigger` describes an interaction with your packaged Apex class or trigger. - **[Visualforce Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-visualforce-interactions.md)** Each record in your package usage log that has a `custom_entity_type` of `VisualforcePage` describes an interaction with your packaged Visualforce pages. - **[CRM Analytics Asset Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-analytics-interactions.md)** Each record in your package usage log that has a `custom_entity_type` of `AnalyticsDashboard`, `AnalyticsLens`, or `AnalyticsRecipe` describes an interaction with your packaged CRM Analytics assets. - **[Custom Interactions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs-custom-interactions.md)** To understand which features and UI components a subscriber interacted with and how they flow through a user journey, create custom interactions with Apex enums and the `IsvPartners.AppAnalytics.logCustomInteraction` Apex method. **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) # How We Handle Profile Settings in Second-Generation Managed Packages During package version creation for unlocked or second-generation managed packages, the build system inspects the contents of all profiles in the DX project directory, not just the directory specified in the path, and preserves only the profile settings that are directly related to the metadata in the package. The profile itself, and any profile settings unrelated to the package’s metadata are discarded from the package. During package installation, the preserved profile settings are applied only to existing profiles in the subscriber org. The profile itself isn’t installed in the subscriber org. To control which profile settings are included, use the `scopeProfiles` parameter in the [project configuration file](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm). **note:** Packages that contain only profiles and no additional metadata aren’t allowed and fail during package version creation. | When you select… | The packaged profile settings are applied to... | This installation option is available via… | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Install for Admins Only | The System Administrator profile in the subscriber org. CRUD access to custom objects is granted automatically to the System Administration profile. | The package installer page or Salesforce CLI `sf package install` command. The default behavior for CLI-based package installs is to install for admins only. | | Install for All Users | The System Administrator profile and all cloned profiles in the subscriber org. CRUD access to custom objects is granted automatically to the System Administration profile, and all cloned profiles. [Standard profiles](https://help.salesforce.com/s/articleView?id=platform.standard_profiles.htm&type=5) can’t be modified. | The package installer page or Salesforce CLI `sf package install` command. To install for all users via the CLI, include the security type parameter. `sf package install --security-type AllUsers` | | Install for Specific Profiles | Specific profiles in the subscriber org. This selection lets the person installing your package determine how to map the profile settings you packaged to specific profiles in their org. | The package installer page. Not available for CLI-based package installations. | To test the behavior of your packaged profile, install your package in a scratch org. 1. From Setup, enter `Profile` in the Quick Find box, and then locate and inspect the profiles you selected during package installation. 2. Check whether your profile settings have been applied to that profile. Repeat this step for any other profile you expect to contain your profile settings. Don’t look for the profile name you created; we apply profile settings to existing profiles in the subscriber org. Whenever possible, use package permission sets instead of profile settings. Subscribers who install your package can easily assign your permission set to their users. **note:** During a push upgrade, some profile settings related to Apex classes and field-level security aren’t automatically assigned to the System Admin profile. To ensure that user access is set up correctly after a push upgrade, communicate with your customer. Make sure they review and update their profile settings after a push upgrade. # Identify How a User Interacted with Your Packaged Component After you identify your packaged component and who interacted with it, identify how the user interacted with your packaged component. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | - Identify how the user interacted with your packaged component with `log_record_type`. Other common fields associated with each interaction are: - `request_id` - `timestamp_derived` # Identify Who Interacted with Your Packaged Component After you identify your packaged component, identify both the subscriber org and the user who triggered the interaction. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | - Identify the subscriber org with the `organization_id`. Some standard fields are always populated and provide you with info about the subscriber org. Some supplemental fields, when populated, add detail about that org. This table describes the subscriber org fields. | Standard Fields | Supplemental Fields | | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
  • `organization_name`
  • `organization_status`
  • `organization_edition`
  • `organization_type`
|
  • `organization_country_code`
  • `organization_language_locale`
  • `organization_time_zone`
  • `organization_instance`
  • `cloned_from_organization_id`
| - Use the `user_id_token` to identify and describe the user associated with the interaction. This hashed token represents the ID of the user who accessed the package. The ID persists, even if a user’s details change, across any packages that the user interacts with. These supplemental fields, when populated, can provide you with more data about the user. - `user_type` - `user_agent` - `user_country_code` - `user_time_zone` - `session_key` - `login_key` Because `user_id_token` can represent many different usage situations, we don’t recommend using App Analytics for auditing customer license usage. # Install a Managed Package During the development and testing cycle, you might need to periodically install and uninstall packages before you install the next beta. Follow these steps to install a package. ## Pre-Installation 1. In a browser, type in the installation URL you received when you uploaded the package. 2. Enter your username and password for the Salesforce organization in which you want to install the package, and then click **Log In**. 3. If the package is password-protected, enter the password you received from the publisher. ## Default Installation Click **Install**. You’ll see a message that describes the progress and a confirmation message after the installation is complete. ## Custom Installation Follow these steps if you need to modify the default settings, as an administrator. 1. Choose one or more of these options, as appropriate. - Click **View Components**. You see an overlay with a list of components in the package. For managed packages, the screen also contains a list of connected apps (trusted applications that are granted access to a user's Salesforce data after the user and the application are verified). To confirm that the components and any connected apps shown are acceptable, review the list and then close the overlay. **note:** Some package items, such as validation rules, record types, or custom settings don’t appear in the Package Components list but are included in the package and installed with the other items. If there are no items in the Package Components list, it’s likely that the package contains only minor changes. - If the package contains a remote site setting, you must approve access to websites outside of Salesforce. The dialog box lists all the websites that the package communicates with. We recommend that a website uses SSL (secure sockets layer) for transmitting data. After you verify that the websites are safe, select **Yes, grant access to these third-party websites** and click **Continue**, or click **Cancel** to cancel the installation of the package. **note:** By installing remote site settings, you’re allowing the package to transmit data to and from a third-party website. Before using the package, contact the publisher to understand what data is transmitted and how it's used. If you have an internal security contact, ask the contact to review the application so that you understand its impact before use. - Click **API Access**. You see an overlay with a list of the API access settings that package components have been granted. Review the settings to verify they’re acceptable, and then close the overlay to return to the installer screen. - In Enterprise, Performance, Unlimited, and Developer Editions, choose one of the following security options. **note:** This option is visible only in specific types of installations. For example, in Group and Professional Editions, or if the package doesn’t contain a custom object, Salesforce skips this option, which gives all users full access. **Install for Admins Only** Specifies the following settings on the installing administrator’s profile and any profile with the "Customize Application" permission. - Object permissions—Read, Create, Edit, Delete, View All Records, and Modify All Records enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package developer - Page layout settings—determined by the package developer - Record Type settings—determined by the package developer After installation, if you have Enterprise, Performance, Unlimited, or Developer Edition, set the appropriate user and object permissions on custom profiles as needed. **Install for All Users** Specifies the following settings on all internal custom profiles. - Object permissions— Read, Create, Edit, and Delete enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package developer - Page layout settings—determined by the package developer - Record Type settings—copied from admin profile **note:** The Customer Portal User, Customer Portal Manager, High Volume Customer Portal, Authenticated Website, Partner User, and standard profiles receive no access. **Install for Specific Profiles...** Lets you determine package access for all custom profiles in your org. You can set each profile to have full access or no access for the new package and all its components. - Full Access—Specifies the following settings for each profile. - Object permissionsRead, Create, Edit, and Delete enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—enabled - Page layout settings—determined by the package developer - Record Type settings—determined by the package developer - No Access—Page layout and Record Type settings are determined by the package developer. All other settings are hidden or disabled. If the package developer has included settings for custom profiles, you can incorporate the settings of the publisher’s custom profiles into your profiles without affecting your settings. Choose the name of the profile settings in the dropdown list next to the profile that you’re applying them to. The current settings in that profile remain intact. Alternatively, click **Set All** next to an access level to give this setting to all user profiles. 2. Click **Install**. You’ll see a message that describes the progress and a confirmation message after the installation is complete. ## Post-Installation Steps If the package includes post-installation instructions, they’re displayed after the installation is completed. Review and follow the instructions provided. In addition, before you deploy the package to your users, make any necessary changes for your implementation. Depending on the contents of the package, some of the following customization steps are required. - If the package includes permission sets, assign the included permission sets to your users who need them. In managed packages, you can't edit permission sets that are included in the package, but subsequent upgrades happen automatically. If you clone a permission set that comes with a managed package or create your own, you can edit the permission set, but subsequent upgrades won't affect it. - If you’re reinstalling a package and need to reimport the package data by using the export file that you received after uninstalling, see [Import Package Data](https://help.salesforce.com/s/articleView?id=xcloud.distribution_reimport_package_data.htm&type=5). - If you installed a managed package, click **Manage Licenses** to assign licenses to users. **note:** You can’t assign licenses in Lightning Experience. To assign a license, switch to Salesforce Classic. - Configure components in the package as required. # Install and Set Up the Feature Management App in Your License Management Org Install the FMA in your LMO. Then add the Feature Parameters tab to your default view, and adjust your page layout for licenses to display related lists for your feature parameters. 1. To request access to the FMA, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com). For product, specify **Partner Programs & Benefits**. For topic, specify **ISV Technology Request**. The FMA extends the License Management App, so be sure to install the LMA before requesting access to the FMA. 2. To install the FMA, follow the instructions in your welcome email. 3. Add the Feature Parameters tab to your default view. For details, see [Customize My Tabs](https://help.salesforce.com/articleView?id=user_userdisplay_tabs.htm) in Salesforce Help. 4. Update your page layout for licenses. 1. Navigate to a license record’s detail page. 2. Click **Edit Layout**. 3. In the Related Lists section of the License Page Layout Editor, add these lists. - Feature Parameter Booleans - Feature Parameter Dates - Feature Parameter Integers 4. For each related list, add these columns. - Data Flow Direction - Feature Parameter Name - Full Name - Master Label - Value # Install and Uninstall Second-Generation Managed Packages Use a disposable scratch org to test your second-generation managed packages (managed 2GP). You can install or uninstall a managed 2GP package using a Salesforce CLI command, or from the Setup page. Because you can't upgrade a beta package version, be sure you don't install it in a sandbox that you use in your release pipeline, such as UAT or staging. - **[Use the CLI to Install a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-install-pkg-cli.md)** If you’re working with the Salesforce CLI, you can use the `sf package install` command to install packages in a scratch org or target subscriber org. - **[Use a URL to Install a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-install-pkg-ui.md)** Install a second-generation managed package from a browser. - **[Install Notifications for Unauthorized Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/pd-packaging-install-notification.md)** When you distribute a managed package that ISV Partner Program hasn’t authorized, we notify customers during the installation process. The notification is removed after the package is approved. - **[Upgrade a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-install-pkg-upgrade.md)** A package upgrade occurs when you install a new package version into an org that has a previous version of that package installed. - **[Resolve Apex Test Failures](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/resolving-test-failures.md)** Package installs or upgrades may fail for not passing Apex test coverage. However, some of these failures can be ignored. For example, a developer might write an Apex test that makes assumptions about a subscriber's data. - **[Run Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/pd-apex-post-install-script.md)** App developers can specify an Apex script to run automatically after a subscriber installs or upgrades a managed package. This script makes it possible to customize the package install or upgrade, based on details of the subscriber’s organization. For instance, you can use the script to populate custom settings, create sample data, send an email to the installer, notify an external system, or kick off a batch operation to populate a new field across a large set of data. For simplicity, you can only specify one post install script. It must be an Apex class that is a member of the package. - **[Customize Second-Generation Managed Package Installs and Uninstalls Using Scripts](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-customize-installs.md)** Customize a second-generation managed package (managed 2GP) install or upgrade by specifying an Apex post install script to run automatically after a subscriber installs or upgrades a managed 2GP package. You can also specify an Apex uninstall script to run automatically when a subscriber uninstalls a managed 2GP package. - **[Sample Script for Installing Second-Generation Managed Packages with Dependencies](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-install-pkg-sample-script.md)** Use this sample script as a basis to create your own script to install second-generation managed packages with dependencies. This script contains a query that finds dependent packages and installs them in the correct dependency order. - **[Uninstall a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-installed-pkgs-uninstall.md)** You can uninstall a second-generation managed package from an org using Salesforce CLI or from the Setup UI. When you uninstall second-generation managed packages, all components in the package, including any deprecated components that were previously associated with the package, are deleted from the org. # Install and Update Agent Assets from AgentExchange Apps on AgentExchange contain the subagents, actions, MCP server tools, or MCP servers that extend what your agents can do. Install an app to add its assets to your org, then add them to an agent in Agentforce Builder. Update an installed app to get its latest version. ## Install an App 1. From the App Launcher, find and select **Agentforce Studio**. 2. Open your agent in Agentforce Builder. 3. From Explorer, go to **Subagents**, and then click **Add from Asset Library**. 4. Browse AgentExchange, and then select a subagent card to view its details. 5. On the asset details page, confirm the publisher and version before you install. 6. Click **Install App for All Users**. A progress strip tracks the install's status in the background so you can keep working on your agent. If you install several apps at once, each one is tracked separately. A notification confirms when installation finishes and lets you know that the app's assets are ready to use. **note:** For a free AgentExchange app in a non-production org, if you don't have the Download AgentExchange Packages permission and Install Request Approvers is turned on, enter a reason in **Business Justification**, and then click **Send Request**. If Install Request Approvers isn't turned on, users who can't install an app don't see **Send Request**. For an app that isn't installed, they see **I'm Interested** instead. 7. When installation finishes, click **Go to Library** to find related subagents and actions in the Asset Library. Then select the asset that you want to add to your agent. ## Update an Installed App 1. From the Asset Library, open the installed app's details page. When an update is available, the heading reads **Update your app to an available version**, and the page shows **Your Version** and **Available Version** so you can compare them. 2. Click **Update Package**. Monitor the update in the installation progress area. **note:** For a free AgentExchange app in a non-production org, if you don't have the Download AgentExchange Packages permission and Install Request Approvers is turned on, enter a reason in **Business Justification**, and then click **Send Request**. A designated approver receives the request and can update the app for you. You can continue using the installed subagent, action, MCP server, or MCP server tool with the current app version until the update completes. ## Other Ways to Install You can also install apps associated with actions, MCP server tools, and MCP servers. The entry point and asset details heading depend on the asset type. | Asset Type | Entry Point | Heading on the Asset Details Page | | --------------- | ----------------------------------------------------- | -------------------------------------------- | | Subagent | Explorer > **Subagents** > **Add from Asset Library** | Install this app to use this subagent | | Action | Explorer > **Actions** > **Add from Asset Library** | Install this app to use this action | | MCP server tool | Explorer > **Actions** > **Add from Asset Library** | Install this app to use this MCP server tool | | MCP server | Agentforce Registry | Install this app to use this MCP server | # Install First-Generation Managed Packages Using Metadata API You can install, upgrade, and uninstall managed packages using the Metadata API, instead of the user interface. Automating these repeated tasks can help you can work more efficiently and speed up application development. To install, upgrade, or uninstall a package, use the standard Metadata API deploy() call with the InstalledPackage metadata type. The following operations are supported. - Deploying an InstalledPackage installs the package in the deploying organization. - Deploying a newer version of a currently installed package upgrades the package. - Deploying an InstalledPackage using a manifest called destructiveChanges.xml, instead of package.xml, uninstalls it from the organization. To specify whether all users, or only admins, can access the package you’re installing, use the securityType field on the InstalledPackage metadata type. The default value is `AllUsers`. This field is available in API version 57.0 and later. **note:** InstalledPackage must be the only metadata type specified in the manifest file. The following is a typical project manifest (package.xml) for installing a package. The manifest must not contain a fullName or namespacePrefix element. ```xml *  InstalledPackage   28.0 ``` The package is specified in a file called `MyNamespace`.`installedPackage`, where `MyNamespace` is the namespace prefix of the package. The file must be in a directory called `installedPackages`, and its contents must have this format. ```xml 1.0 optional_password AdminsOnly ``` The securityType field is optional. If it’s not specified, the default security type is AllUsers. InstalledPackage in API version 43.0 and later must include the `activateRSS` field set to either of these values. **true:** Keep the isActive state of any Remote Site Settings(RSS) or Content Security Policies(CSP) in the package. **false:** Override the isActive state of any RSS or CSP in the package and set it to `false`. The default value is `false`. **note:** Regardless of what activateRSS is set to, a retrieve of InstalledPackage always returns ``. Therefore, before you deploy a package, inspect the information you’ve retrieved from InstalledPackage and set activateRSS to the desired value. To uninstall a package, deploy this destructiveChanges.xml manifest file in addition to the package.xml file. ```xml MyNamespace InstalledPackage   ``` Retrieving an InstalledPackage, using the retrieve() call creates an XML representation of the package installed in an org. If the installed package has a password or security type specified, that information isn’t retrieved. Deploying the retrieved file in a different org installs the package in that organization. For more information on the deploy() and retrieve() commands, see the [_Metadata API Developer’s Guide_](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/). # Install Notifications for Unauthorized Managed Packages When you distribute a managed package that ISV Partner Program hasn’t authorized, we notify customers during the installation process. The notification is removed after the package is approved. ![A view of the unauthorized package notification and acknowledgement checkbox during the installation process.](https://developer.salesforce.com/media/shared/package_install_notification.png) The notification appears when customers configure the package installation settings (1). Before customers install the package, they must confirm that they understand that the package isn’t authorized for distribution (2). The notification displays when a managed package: - Has never been through security review or is under review - Didn’t pass the security review - Isn’t authorized by ISV Partner Program for another reason If the ISV Partner Program approves the package, it’s authorized for distribution, and the notification is removed. When you publish a new version of the package, it’s automatically authorized for distribution. For information about the ISV Partner Program and its requirements, visit the [Salesforce Partner Community](https://partners.salesforce.com/s/education/general/Partner_Program). # Install Notifications for Unauthorized Managed Packages When you distribute a managed package that ISV Partner Program hasn’t authorized, we notify customers during the installation process. The notification is removed after the package is approved. ![A view of the unauthorized package notification and acknowledgement checkbox during the installation process.](https://developer.salesforce.com/media/shared/package_install_notification.png) The notification appears when customers configure the package installation settings (1). Before customers install the package, they must confirm that they understand that the package isn’t authorized for distribution (2). The notification displays when a managed package: - Has never been through security review or is under review - Didn’t pass the security review - Isn’t authorized by ISV Partner Program for another reason If the ISV Partner Program approves the package, it’s authorized for distribution, and the notification is removed. When you publish a new version of the package, it’s automatically authorized for distribution. For information about the ISV Partner Program and its requirements, visit the [Salesforce Partner Community](https://partners.salesforce.com/s/education/general/Partner_Program). # Install the License Management App The License Management App (LMA) is a managed package that is installed in all partner business orgs. The org that the LMA is installed in is called the License Management Org (LMO). ## Before You Begin | User Permissions Needed | | | ----------------------- | ----------------------------- | | To install packages: | Download AppExchange Packages | We strongly recommend that you use your partner business org (PBO) as your LMO. However, you can choose to install the LMA in another production org. Consider installing the LMA in an org that your company is already using to manage sales, billing, and marketing. Commercial use of the LMA is prohibited in Developer and Partner Developer Edition orgs. Installing the LMA in a Developer Edition org is allowed only if you’re building integrations with the LMA and need an environment only for development and testing purposes. You can install the LMA in Enterprise, Unlimited, or Performance Edition production orgs. It’s not possible to have Slack or the Declarative Lookup Rollup Summary (DLRS) package installed in the same org as the LMA. If the org in which you plan to install the LMA has either Slack or the DLRS package installed, uninstall them before you install the LMA. Alternatively, install the LMA in a different org. **note:** To confirm whether your PBO already has the LMA installed, skip to step 4. 1. To install the LMA in an org other than your PBO, log a case in the [Partner Community](https://partners.salesforce.com). After we review the case, you receive an email with an installation URL. 2. Log in to the org where you want to install the LMA, and then go to the installation URL included in the email. 3. Choose which users can access the LMA, and then click **Install**. 4. To confirm that the LMA is installed, open the App Launcher. If the installation was successful, the License Management App appears in the list of available apps. # Install the Package in a Target Org After you create a package with the CLI, install the package in a target org. You can install the package in any org you can authenticate, including a scratch org. ## Before You Begin If you want to create a scratch org and set it as the `defaultusername` org, run this command from the project directory. ```nolang sf org create scratch -definition-file config/project-scratch-def.json ``` To locate the ID of the package version to install, run `sf package1 version list`. ```nolang METADATAPACKAGEVERSIONID METADATAPACKAGEID NAME VERSION RELEASESTATE BUILDNUMBER ──────────────────────── ────────────────── ──── ─────── ──────────── ─────────── 04txx000000069oAAA 033xx00000007coAAA r00 1.0.0 Released 1 04txx000000069tAAA 033xx00000007coAAA r01 1.1.0 Released 1 04txx000000069uAAA 033xx00000007coAAA r02 1.2.0 Released 1 04txx000000069yAAA 033xx00000007coAAA r03 1.3.0 Released 1 04txx000000069zAAA 033xx00000007coAAA r04 1.4.0 Released 1 ``` You can then copy the package version ID you want to install. For example, the ID 04txx000000069zAAA is for version 1.4.0. 1. Install the package. You supply the package alias or version ID, which starts with 04t, in the required `--package` parameter. ```nolang sf package install --package 04txx000000069zAAA ``` If you’ve set a default target org, the package is installed there. You can specify a different target org with the `--target-org` parameter. If the package is protected by an installation key, supply the key with the `--installation-key` parameter. ## Next Steps To uninstall a package, open the target org and choose **Setup**. On the Installed Packages page, locate the package and choose **Uninstall**. # Installation and Review Email Notifications Salesforce emails customers who install your AgentExchange solution to request that they review your listing. When customers post reviews or comments on your listing, we notify interested parties. ## Installation Notification Emails Salesforce emails your customers 30 days after they install your solution. The email thanks customers and encourages them to share their experiences with others by writing a review. We send emails only when: - The customer has a valid email address. - The customer hasn’t already received a notification. - The customer hasn’t yet posted a review. ## Customer Review Notification Emails When customers post reviews and comments on your AgentExchange listings, Salesforce emails parties who are likely to be interested. The type of email notification depends on the recipient’s role in the conversation (provider, author, or commenter). |Type of Email Notification|Sent To|Details| |--------------------------|-------|-------| |New Review on Your Listing|You, the provider|Sent whenever someone posts a review on AgentExchange. The email is sent to the address provided in the listing’s Customer Reviews Contact field. We recommend periodically checking that the email address is up to date. Edit the listing, click **Fill in the Basics**, and check the email address shown in the Customer Reviews Contact field.| |New Comment on Your Review|The review author|Sent only if someone other than the review author comments on the review and if the author opted to receive email notifications on their profile. If the author replies to the notification, the reply is posted as a new comment on the review.| |Also Commented on the Review|The people who commented on the review|Sent to people who commented on a review, aren’t the review author or the author of the comment, and opted to receive email notifications on their profiles. At most, one email notification is sent to each commenter for each new comment. If the person replies to the notification, the reply is posted as a new comment on the review.| |New Comment on the Review of Your Listing|You, the provider|Sent whenever someone posts a new comment on a review of your listing. The email is sent to the address provided in the listing’s Customer Reviews Contact field. We recommend periodically checking that the email address is up to date. Edit the listing, click **Fill in the Basics**, and check the email address shown in the Customer Reviews Contact field.| # Installation Methods for AgentExchange Solutions The easier it is for prospects to install your AgentExchange solution, the more likely it is that they become paying customers. When you create your listing in the Partner Console, you’re prompted to select an installation method. Offer the method that gives prospects the best experience. The installation method options vary based on listing type. For managed-package listings, there are three options (1). ![A screenshot of the installation method options](https://developer.salesforce.com/docs/media/appexchange_link_solution_installation_method.png) |Method|When to choose this method| |------|--------------------------| |Install from your AgentExchange listing|
  • This method is required for components and recommended for apps.
  • If your solution is a managed package, this method provides the simplest installation experience. Customers can install your solution in their Salesforce sandbox or production environment through the AgentExchange installation sequence without your assistance.
  • API solutions can’t be installed directly from AgentExchange.
| |Install from your website|
  • If your solution is a downloadable client or needs additional information to be installed, this method is the best.
  • After users click **Get It Now** on your listing and agree to the terms and conditions, they’re directed to your website to complete the installation process. Make sure that you provide clear download instructions and perform the required setup or configuration.
  • Solutions are not downloaded to a user's device. Instead, they run on the Salesforce cloud infrastructure and download to the user's workspace.
| |Contact you for install instructions|
  • If the installation or selection process requires your assistance, you must choose this method.
  • After agreeing to terms and conditions, the customer is notified that you’ll be in touch shortly to help with the installation. Make sure that your company has the resources to assist potential customers.
  • When a customer contacts you for instructions, we generate a lead. If you select this method, you must specify where you want to receive these leads. Follow the instructions in [Enable AgentExchange Lead Collection](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-enable-lead-collection.md).
| |Install from a Tableau Exchange listing|
  • If your solution is a Tableau Accelerator, you must use this method.
  • Accelerators listed on AgentExchange have corresponding listings on Tableau Exchange. AgentExchange customers who choose to install your Accelerator are redirected to the installation flow on Tableau Exchange.
| # Installing Packages Installing an AgentExchange solution in your Salesforce org is straightforward. You install the solution as an unmanaged or managed package, and then you configure it for your environment and users. ## Before You Begin | Required Editions | | --------------------------------------------------------------------------------------------------------------------- | | Available in: **Group**, **Professional**, **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | User Permissions Needed |   | | ----------------------- | ------------------------------- | | To install packages: | Download AgentExchange Packages | **warning:** If the solution is in a managed package, you can’t change certain Salesforce components after you install them. Managed packages also have a namespace prefix that is prepended to all uniquely named components, such as custom fields. For more information on namespace prefixes, see Register a Namespace Prefix. ## Steps Only one person in your organization can install or upload a package at a time. 1. Go to [AgentExchange](https://agentexchange.salesforce.com/). 2. Browse or search for a solution. 3. Click **Get It Now** on the solution’s listing page. If the listing doesn’t have a **Get It Now** option, it's a partner app that you can download and use outside of Salesforce. For more information, contact the publisher. 4. Choose a production environment. **note:** **Get It Now** supports package installation in production environments only. To install a package in a sandbox environment, select the **Try It** option. 5. Enter any requested information, agree to the terms and conditions, and then click **Confirm and Install**. 6. Enter the requested information. 7. If the package is password-protected, enter the password you received from the publisher. 8. Review the package items, and click **Continue**. To install a new version of a managed package, review the list of new items included in the upgraded package. **note:** Some package items, such as validation rules or record types, don't display in the Package Item list but are included in the package and install with the other items. If there are no items in the Package Items list, the package contains only minor changes not recorded in the Package Items list. 9. Review the API access that package components have been granted to ensure that they’re acceptable and, if they are, click **Next**. If they aren’t, click **Cancel**. For more information, see About API and Dynamic Apex Access in Packages in Salesforce Help. 10. When installing unmanaged packages, you can select Resolve Naming Conflicts Automatically. When this option is selected, Salesforce changes the name of the component in the package being installed. 11. In Enterprise, Unlimited, Performance, and Developer Editions, choose a security option, and click **Next**. - Install for Admins Only - : Specifies the following settings on the installing administrator’s profile and any profile with the Customize Application permission. - Object permissions—Read, Create, Edit, Delete, View All Records, and Modify All Records enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package creator - Page layout settings—determined by the package creator - Record Type settings—determined by the package creator After installation, if you have Enterprise, Performance, Unlimited, or Developer Editions, set the appropriate user and object permissions on custom profiles as needed. - Install for All Users - : Specifies the following settings on all internal custom profiles. - Object permissions—Read, Create, Edit, and Delete enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package creator - Page layout settings—determined by the package creator - Record Type settings—copied from admin profile The Customer Portal User, Customer Portal Manager, High Volume Customer Portal, Authenticated Website, Partner User, and standard profiles receive no access. - Install for Specific Profiles - : Enables you to choose the usage access for all custom profiles in your organization. You can set each profile to have full access or no access for the new package and all its components. - Full Access—Specifies the following settings for each profile. - Object permissions—Read, Create, Edit, Delete, View All Records, and Modify All Records enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package creator - Page layout settings—determined by the package creator - Record Type settings—determined by the package creator - No Access—Specifies the same settings as Full Access, _except_ all object permissions are disabled. If the publisher included settings for custom profiles, other options are available. You can incorporate publisher’s custom profile settings into your profiles without affecting your settings. Choose the name of the profile settings in the dropdown list next to the profile to which you want to apply them. The current settings in that profile remain intact. Alternatively, to give this setting to all user profiles, click **Set All** next to an access level. **note:** Depending on the type of installation, it’s possible this option doesn’t appear. For example, in Group and Professional Editions, or if the package doesn’t contain a custom object, Salesforce skips this option, which gives all users full access. 12. In Enterprise, Unlimited, Performance, and Developer Editions, if you chose **Select security settings**, select the level of access to give users in each profile, and click **Next**. Standard options are: - Full Access—Specifies the following settings for each profile. - Object permissions—Read, Create, Edit, Delete, View All Records, and Modify All Records enabled - Field-level security—set to visible and editable for all fields - Apex classes—enabled - Visualforce pages—enabled - App settings—enabled - Tab settings—determined by the package creator - Page layout settings—determined by the package creator - Record Type settings—determined by the package creator - No Access—Specifies the same settings as Full Access, _except_ all object permissions are disabled. If the publisher included settings for custom profiles, other options are available. You can incorporate the publisher’s custom profile settings into your profiles without affecting your settings. Choose the name of the profile settings in the dropdown list next to the profile to which you want to apply them. The current settings in that profile remain intact. Alternatively, to give this setting to all user profiles, click **Set All** next to an access level. 13. To install all the components in the package you selected, click **Install**. **note:** During installation, Salesforce automatically resolves any references to package components from the source organization. For example, if a custom link in the package refers to a document, the Salesforce Help ID for the document is different after you install it. Salesforce automatically alters the installed custom link to refer to the new ID in your organization. Salesforce also checks and verifies any dependencies. An installer’s organization must meet all dependency requirements listed on the Show Dependencies page or else the installation fails. For example, the installer's organization must have divisions enabled to install a package that references divisions. For more information on package dependencies, see Understanding Dependencies in Salesforce Help. When you install a component that contains an Apex script, all unit tests for your organization are run, including the unit tests contained in the new package. If a unit test relies on a component that is initially installed as inactive, such as a workflow rule, this unit test can fail. You can select to install regardless of unit test failures. For reasons why Salesforce can prevent an install, see Why did my installation or upgrade fail? in Salesforce Help. 14. Click **OK**. 15. Configure your package. For more information, see Configuring Installed Packages in Salesforce Help. 16. If the package includes permission sets, assign the included permission sets to your users who need them. In managed packages, you can't edit permission sets that are included in the package, but subsequent upgrades happen automatically. If you clone a permission set that comes with a managed package or create your own, you can make changes to the permission set, but subsequent upgrades don't affect it. 17. If you’re reinstalling a package, see Importing Package Data in Salesforce Help to reimport the package data using the export file you received after uninstalling. 18. If you installed a managed package, click **Manage Licenses** to assign licenses to users. For more information, see Managing Licenses for Installed Packages in Salesforce Help. # ISVforce Guide Previous PDF Versions | API Version | Release | PDF | | ----------- | ---------- | --- | | 67.0 | Summer '26 | [Download PDF](https://resources.docs.salesforce.com/262/latest/en-us/sfdc/pdf/salesforce_packaging_guide.pdf) | | 66.0 | Spring '26 | [Download PDF](https://resources.docs.salesforce.com/260/latest/en-us/sfdc/pdf/salesforce_packaging_guide.pdf) | | 65.0 | Winter '26 | [Download PDF](https://resources.docs.salesforce.com/258/latest/en-us/sfdc/pdf/salesforce_packaging_guide.pdf) | | 64.0 | Summer '25 | [Download PDF](https://resources.docs.salesforce.com/256/latest/en-us/sfdc/pdf/salesforce_packaging_guide.pdf) | # ISVforce Guide: Build and Distribute AgentExchange Solutions AgentExchange is a trusted marketplace of proven agents, apps, integrations, and experts that help Salesforce’s more than 150,000 customers turn business goals into outcomes, faster. As an AgentExchange partner, you’re able to sell to these businesses, which are some of the world’s most recognized companies with high expectations for customer success. They are always looking for new solutions and services to move their business forward. AgentExchange supports two categories of partners on AgentExchange: - **Solutions (ISV path)** – Create and distribute packaged apps, components, Agentforce solutions, MCP servers, flows, integrations, or OEM solutions that customers install and connect into their Salesforce orgs. - **Consulting Services (Consulting path)** – Provide professional services, implementation expertise, and advisory offerings that customers engage through the marketplace. To get started, complete all the activities in the first section, Get Ready to Distribute on AgentExchange. The steps there, such as signing up for the ISV Partner Program and getting a Partner Business Org are prerequisites for all partners. From there, learn to plan, build, distribute, sell, and support solutions and services for the AgentExchange marketplace. All the information you need is right here. - [Get Ready to Distribute on AgentExchange](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-partner-start.md) - [Use Managed Packages to Develop Your AgentExchange Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/managed-packaging-intro.md) - [Manage Orgs with Environment Hub](https://developer.salesforce.com/docs/platform/isvforce/guide/environment-hub-intro.md) - [Architectural Considerations for Group and Professional Editions](https://developer.salesforce.com/docs/platform/isvforce/guide/dev-packages-for-pe-ge.md) - [Security Requirements for ISV Partners and AgentExchange Solutions](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-create-secure-solution.md) - [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-guidelines.md) - [Manage Your AgentExchange Listings](https://developer.salesforce.com/docs/platform/isvforce/guide/packaging-distributing.md) - [AgentExchange Go-To-Market App Guide](https://developer.salesforce.com/docs/platform/isvforce/guide/partner-marketplace-intro.md) - [Sell on AgentExchange with Checkout](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-checkout-sell.md) - [Report Orders to Salesforce with the Channel Order App](https://developer.salesforce.com/docs/platform/isvforce/guide/coa-intro.md) - [Provide Free Trials of Your AgentExchange Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce.md) - [OEM User License Guide](https://developer.salesforce.com/docs/platform/isvforce/guide/oem-user-license-comparison.md) - [List Your Consulting Services on AgentExchange](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-list-consulting-services.md) # Join the Salesforce Partner Community AgentExchange solutions and consulting services are built by official Salesforce partners. To start your partnership journey, join the Salesforce Partner Community. ## Before You Begin Your business goals shape how we partner with you. Before you join the Salesforce Partner Community, learn about [AgentExchange ISV](https://1.appexchange.com/partnerprogram) and [Consulting](https://1.salesforce-partners.com/consultingpartner) partnerships. **tip:** We recommend that you create a separate username for the Partner Community even if you have an existing Salesforce username. This approach gives you immediate access to your Partner Business Org (PBO), which contains tools for setting up and managing your business. ## Steps 1. Go to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Become a Salesforce Partner**. 3. Click **Get a Salesforce User Name**, and fill in the required fields. 4. Click **Create Username**. We send a confirmation email asking you to verify your account and set a password. 5. Set a password for your account, and then click **I have my Salesforce User Name - Join the Partner Community.** 6. Log in to the Partner Community, and then finish the remaining setup tasks. # Key Concepts in Second-Generation Managed Packaging Let’s look at some key high-level concepts in second-generation managed packaging (managed 2GP). | What’s the difference between… | Details | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An app, a package, and metadata? | An app is a set of features that you’re developing for your customers. Metadata is the technical representation of Salesforce features like custom objects, Apex classes, and Lightning pages. An app is composed of a set of metadata. A package is the container for your app’s Salesforce metadata. Packages are used to distribute the app that you build. When a package is installed in an org, the app’s metadata is deployed to the org. | | A package and package version? | Your app, and thus your package, evolves over time. Whenever you change, add, or remove the metadata in your package, you create a new package version. Each package version is an immutable artifact, a static snapshot of your metadata at a specific point in time. So while your package evolves continuously, you take snapshots of it when it's in a stable state in the form of a package version. Technically speaking, when we say “Install a package,” we really mean install a specific package version. | | A package install and package upgrade? | A package install refers to the first time a version of the package is installed in an org. When a package is installed, the metadata associated with the package is deployed into the org. A package upgrade refers to the installation of a new package version in an org that already has a previous version of the package installed. During a package upgrade, metadata changes are deployed. An upgrade can include deploying new metadata, modifying existing metadata, or deleting or deprecating metadata. At any given point in time, an org can only ever have one version of a package installed in that org. | | Is it possible to... | Details | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Push a package upgrade? | Yes. Push upgrades enable you to upgrade packages installed in subscriber orgs, without asking customers to install the upgrade themselves. For more details, see [Push a Package Upgrade](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/push_upgrade_intro_2GP.htm). | | Uninstall a package? | Yes. When you uninstall managed 2GP packages, all components in the package and any associated data is deleted from the org. Before uninstalling a package, review these [considerations](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_installed_pkgs_uninstall.htm). | | Delete a package or package version? | Yes. If you haven’t promoted or distributed a specific package or package version, you can delete the package or package version from your Dev Hub org. For more details, see [Delete a Managed 2GP Package or Package Version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_package_deletion.htm). | # Know Your Orgs for Second-Generation Managed Packages Some of the orgs that you use with second-generation managed packaging (managed 2GP) have a unique purpose. ## Choose Your Dev Hub Org Use the Dev Hub org for these purposes. - As owner of all second-generation managed packages - To link your namespaces - To authorize and run your `sf package` Salesforce CLI commands We recommend that your Partner Business Org is also your Dev Hub org. For important considerations about your Dev Hub org, see [Enable Dev Hub and Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-enable-devhub.md). **note:** The Dev Hub org against which you run the `sf package create` command becomes the owner of the package. If the Dev Hub org expires or is deleted, packages owned by that Dev Hub: - Can’t be transferred to a different Dev Hub - Stop working and new package versions can’t be created ## Namespace Org The primary purpose of the namespace org is to acquire a namespace for your managed 2GP package. After you create a namespace org and specify the namespace in it, open the Dev Hub org and link the namespace org to the Dev Hub org. ## Other Orgs When you work with managed 2GP packages, you also use these orgs: - Scratch orgs to develop and test your packages. - A target or installation org in which you install the package. **See Also** - [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm) - [Scratch Org Allocations for Partners](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/isv_partner_scratch_org_allocations.htm) - [_Salesforce DX Developer Guide:_ Scratch Orgs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm) # Large-Sized Partners Large partners have large subscriber bases and many managed packages. A large partner’s total daily data usage is more than 20 GB. Sometimes a large partner’s data from just one managed package is larger than the 20-GB daily limit. Also, large partners often must create a smaller time range for each query to complete in under the 15-minute processing time limit. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | Large partners frequently create one query per managed package per 12, 6, or 1-hour increments throughout a 24-hour period. How frequently you schedule your queries really depends on your data volume. We recommend that you use a combination of queries and multiple catch-up queries for all data types | Data Type | How to Get Started | How to Schedule Catch-Up Queries | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscriber Snapshots | One daily query per package. |
  • One daily query per package.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to 30 days ago.
  • Omit `EndTime`.
  • Each day advance `StartTime` and `AvailableSince` by 1 day.
| | Package Usage Summaries | One daily query per package. |
  • One daily catch-up query per package.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to the first of the previous month.
  • Omit `EndTime`.
  • Each day advance `AvailableSince` by 1 day.
  • Each month advance `StartTime` to the first of the previous month.
| | Package Usage Logs |
  • To retrieve all your data, create multiple segmented daily, automated App Analytics queries spread throughout the day.
  • Break up your requests by managed package and by time increments throughout the day.
| Create two levels of catch-up queries per day.
  • Create one catch-up query per package that sweeps data from 2 days ago.
  • Create a second catch-up query that sweeps data from 3 to 30 days ago.
  • Each day advance `StartTime`, `EndTime`, and `AvailableSince` by 1 day.
| ## Example Your customers use your package on all Salesforce instances around the world, and your managed packages produce significant amounts of data. You schedule queries to run at the same time, each covering a 12-hour period, and you create a layered catch-up query plan to capture data from all instances. In this example, we show two of your dozens of managed packages. - On March 31 at `18:00 UTC`, run your regular package usage log queries. Package 1 ```nolang sf data create record data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00 EndTime=2021-03-30T12:00:00 DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T12:00:00 EndTime=2021-03-31T00:00:00 DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00 EndTime=2021-03-30T12:00:00 DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T12:00:00 EndTime=2021-03-31T00:00:00 DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` - On April 1 at `18:00 UTC`, run your regular and catch-up package usage log queries. ![Package log file regular and catch-up queries timeline on April 1.](https://developer.salesforce.com/media/pkg2_dev/app_analytics_catchup_large_today.png) A. Package Usage Log Regular Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-03-31T12:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T12:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-03-31T12:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T12:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` B. Package Usage Log 2 Days Ago Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-03-31T18:00:00Z" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-03-31T18:00:00Z" ``` C. Package Usage Log From 3 to 30 Days Ago Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-01T00:00:00Z EndTime=2021-03-30T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-03-31T18:00:00Z" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-01T00:00:00Z EndTime=2021-03-30T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-03-31T18:00:00Z" ``` - On April 2 onwards, run your regular and your catch-up package usage log queries, advancing the dates by 1 day. ![Package log file regular and catch-up queries timeline on April 2.](https://developer.salesforce.com/media/pkg2_dev/app_analytics_catchup_large_tomorrow.png) A. Package Usage Log Regular Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T00:00:00Z EndTime=2021-04-01T12:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T12:00:00Z EndTime=2021-04-02T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T00:00:00Z EndTime=2021-04-01T12:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T12:00:00Z EndTime=2021-04-02T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy" ``` B. Package Usage Log 2 Days Ago Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-04-01T18:00:00Z” ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-04-01T18:00:00Z" ``` C. Package Usage Log From 3 to 30 Days Ago Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-02T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-04-01T18:00:00Z" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-02T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=parquet FileCompression=snappy AvailableSince=2020-04-01T18:00:00Z" ``` # Lead and License Records in the License Management App Each time a customer installs your managed package, the License Management App (LMA) creates lead and license records. The key objects in the LMA are Package, Lead, and License. - Package—The LMA includes a Package custom object and a Package Version custom object. These objects display details about each 1GP or 2GP package and package version you’ve listed on AgentExchange. - Lead —The Lead standard object gives you details about who installed your package, such as the installer’s name, company, and email address. Lead records created by the LMA are just like the ones you use elsewhere in Salesforce, except the lead source is Package Installation. You can manually convert leads into accounts and contacts. When you convert a lead, the license record links to the converted account or contact. - License—The License custom object gives you control over how many users in the customer’s org can access your package and for how long. Each license record links to a lead record and a package record. To understand which actions you must take and which actions the LMA handles for you, review this table. | Action | Who Takes This Step | | -------------------------------------------------------------------------------------------------- | -------------------- | | Your package is installed by a new subscriber. | Customer or prospect | | A lead record is created with the customer’s name, company, and email address. | LMA | | A license record is created according to the values you specified when you registered the package. | LMA | | The lead record is converted to account and contact records. (Optional) | You (ISV partner) | | Account and contact records are associated with the license record. | LMA | **note:** Lead [assignment rules](https://help.salesforce.com/s/articleView?id=service.customize_leadrules.htm) aren't triggered for leads created by the LMA. # Leads and Licenses Aren’t Being Created in the License Management App When a customer installs your package, leads and license records are created. If these records aren’t being created, review these configurations in the License Management Org (LMO). If you resolve your issue using one of these recommendations, your missing licenses appear in the LMA within a few days. ## Did the customer complete the package installation? When a customer clicks **Get it Now** on your AgentExchange listing, Salesforce counts this selection as an installation. However, the customer can cancel the installation before it’s completed, or the installation could have failed. If the installation doesn’t finish, a license isn’t created. ## Is State and Country picklist validation enabled? To avoid state and country picklist-related lead failures, you have two options. Use the standard picklist integration values, or add duplicate states and countries to your picklists. **Standard picklist integration values** To implement this option, use the Salesforce standard state and country picklists in your org, and leave the integration values as-is. We recommend this option for most partners. With this option, AgentExchange leads propagate to your org with full state and country names, and the names match integration values in the standard picklists. **Add duplicate states and countries to your picklists.** Implement this option if you have a requirement to use the two-letter state or country abbreviations in your org. For example, you display abbreviations in the user interface or use them to integrate with other systems. Add duplicate states and countries to your picklists with different integration values. Set one value to the two-letter state or country abbreviation. Set the other value to the full state or country name. Make only the two-letter abbreviation picklist entries visible. With this option, AgentExchange leads propagate to your org with full state and country names, which match the full name integration values in your org. You also have two-letter integration values to use as needed. ## Does the lead or license object have a trigger? Don’t use `before_create` or `before_update` triggers on leads and licenses. Instead, use `after_` triggers, or remove all triggers. If a trigger fails, it can block license creation. ## Does the lead or license record have a required custom field? If yes, remove the requirement. The LMA doesn’t populate a required custom field, so it can prevent licenses or leads from being created. ## Is the lead manager a valid, active user? If not, the LMA can’t create leads and licenses. ## Does the lead or license record have a validation rule? Validation rules often block the creation of LMA lead or license records because the required field isn’t there. ## Does the lead or license have a workflow rule? Workflow rules sometimes prevent leads and licenses from being created. Remove the workflow rule. ## Was the lead converted to an account? When leads are converted to accounts, they’re no longer leads. ## Are you using standard duplicate rules for leads? When a customer installs your package, the LMA checks for existing leads and contacts. If an existing contact matches the customer who installed your package, a lead record isn’t created. To complete these checks, the LMA applies [standard lead duplicate rules](https://help.salesforce.com/articleView?id=duplicate_rules_standard_lead_rule.htm) and [matching rules](https://help.salesforce.com/articleView?id=matching_rules_standard_contact_rule.htm). If you prefer to have the LMA associate every license with a lead regardless of whether there’s an existing contact match, [customize the standard duplicate rule for leads](https://help.salesforce.com/articleView?id=duplicate_prevention_map_of_tasks.htm) and remove the matching rule for contacts. # License Object Fields Use the License custom object to set limits on how many users in the subscriber’s org can use your app and for how long. The License Management App (LMA) creates a license record every time your package is installed in an org. For example, if a subscriber installs two of your 1GP packages and three of your 2GP packages, you have five license records for that subscriber in your LMA. If you deliver a 2GP app that is composed of multiple packages, a unique license record is created for each package in the app. You can allocate up to 99,000,000 seats per subscriber license. To view details about a license record, select the **Licenses** tab in the LMA, and then select and open the license record. License records are automatically created and contain critical information for tracking licenses. Do not directly edit the license record. Instead, use the [Modify License](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_edit_license.htm) tool to change the expiration date, license status, and the number of licensed seats. | License Custom Object Fields | Description | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account | A lookup field to the account record for a converted lead. | | Contact | A lookup field to the contact record for a converted lead. | | Created By | License records are always created by the LMA. | | Expiration Date | Displays the expiration date or `Does not expire` (default). | | Install Date | The date the subscriber installed this package version. | | Instance | The Salesforce instance where the subscriber’s org resides. | | Lead | The lead record that the LMA created when the package was installed. A lead represents the user who owns the license. If you convert the lead into an opportunity, the lead name is retained but the lead record no longer exists. | | License Name | An auto-generated number that represents an instance of a license. License names are in the format of L-00001, and each new license is incremented by one. | | Licensed Seats | Displays the number of licenses or `Site License` (default). When a package is installed in a sandbox org, `Site License` is the default. If a free trial package is installed in a sandbox org, the `Site License` is applied. | | License Status | The type of license: Active, Suspended, Trial, or Uninstalled. | | License Type | This is a legacy field and can be ignored. | | Org Edition | The edition of the subscriber’s org. | | Org Expiration Date | Applies only if the subscriber installs your package in a trial org. Indicates the date when the trial org expires. It isn’t related to the package license expiration. | | Org Status | The status of the subscriber’s org: Active, Free, or Trial. | | Owner | The LMA owns all license records. Don’t edit this field. | | Package Version | A lookup field that links to the package version associated with this license. | | Package Version Number | The version number in major.minor.patch format. For example, 3.1.0. | | Sandbox | Indicates whether the license is for a package installed in a sandbox org. | | Subscriber Org ID | The 15-character ID representing the subscriber’s org. | | Used Licenses | Displays the number of users who have a license to the package. This field is blank if a customer uninstalled the package, or if Licensed Seats is set to Site License. | # Lightning Interactions Each record in your package usage log that has a `custom_entity_type` of `LightningComponent` or `LightningPage` describes an interaction with your packaged Lightning component or page. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | ## Lightning User Interaction **note:** We’re continually improving the recording of Lightning interaction data in package usage logs. Many interactions with your packaged Lightning component or page are available in AgentExchange App Analytics, but not all. To determine which interactions we capture for your specific package, compare your packaged components to your App Analytics package usage logs. When a user interacts with your `LightningPage` or `LightningComponent` packaged component, a `log_record_type` of `LightningInteraction` is created. Some standard fields are always populated with data. For example, a Lightning component interaction always has `app_name` and `ui_event_source` data. Lightning interactions have supplemental fields that are often populated. For example, a Lightning interaction sometimes also has `page_app_name` and `page_context` data. | Standard Data | Supplemental Data | | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | |
  • `app_name`
  • `ui_event_source`
  • `ui_event_type`
  • `target_ui_element`
  • `parent_ui_element`
|
  • `page_app_name`
  • `page_context`
  • `related_list`
  • `page_url`
| ## Lightning Page View When a user views your Lightning page, a `log_record_type` of `LightningPageView` is created. Some standard fields are always populated with data. For example, a Lightning page view always has `app_name` and `page_app_name` data. Lightning page views have supplemental fields that are often populated. For example, a Lightning page view sometimes also has `page_entity_type` and `prevpage_url` data. | Standard Data | Supplemental Data | | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | |
  • `app_name`
  • `page_app_name`
  • `page_context`
  • `page_url`
|
  • `page_entity_type`
  • `prevpage_url`
  • `related_list`
| ## Example Let’s look at an example package usage log record and analyze the Lightning interaction. ```nolang { "timestamp_derived": "2022-11-22T06:17:39.167Z", "log_record_type": "LightningInteraction", "request_id": "TID:7635077000004b3035", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=", "user_type": "Standard", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "Acme__Insurance_Agents", "custom_entity_type": "LightningPage", "session_key": "2l4YtFB/RmsRKVsS", "login_key": "fGV6RgVOH3ZCgl2v", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "US", "user_time_zone": "America/Los_Angeles", "app_name": "one:one", "page_app_name": "Insurance_App", "page_context": "app_flexipage:lwcAppFlexipageWrapper", "ui_event_source": "click", "ui_event_type": "user", "ui_event_sequence_num": "10", "target_ui_element": "setup-app-nav-menu-item-link", "parent_ui_element": "global-setup", "page_url": "/lightning/n/Acme__Insurance_Agents" } ``` The `Acme_Insurance_Agents` Lightning page was interacted with as a result of a user action from subscriber org `MyCustomer Inc`. Specifically, a Lightning interaction took place on the page on 2022-11-22 at 6:17 am. The key data in this analysis are: | Question | Field | Value | | -------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | What |
  • `custom_entity`
  • `custom_entity_type`
  • `package_version_id`
  • `managed_package_namespace`
|
  • `Acme_Insurance_Agents`
  • `LightningPage`
  • `04txx0000004Idi`
  • `Acme`
| | Who |
  • `organization_id`
  • `user_id_token`
|
  • `00Dxx0000006H2l`
  • `005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=`
| | How | `log_record_type` | `LightningInteraction` | | When | `timestamp_derived` | `2022-11-22T06:17:39.167Z` | **note:** Lightning interaction data is captured on an event by event basis. **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) - [Lightning Interaction Event Type](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_eventlogfile_lightninginteraction.htm) - [Lightning Page View Event Type](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_eventlogfile_lightningpageview.htm) # Limited Access License for Package Developers The Salesforce Limited Access - Free is designed for users whose role is to build customizations or applications. This license provides access to the Dev Hub, development tools, and environments. In the production org, this license restricts access to standard and custom objects. Partner Business Orgs (PBO) include 100 Salesforce Limited Access - Free user licenses. If the Salesforce Limited Access - Free license isn’t already enabled in your PBO, log a case with [Salesforce Partner Support](https://partners.salesforce.com) to request up to 100 licenses. A Salesforce admin can upgrade a Salesforce Limited Access - Free license to a standard Salesforce license at any time. Certain developer features aren’t available with the Salesforce Limited Access - Free license. - To provide the ability to create and manage org shapes, assign the Salesforce user license. The Salesforce Limited Access - Free license isn’t supported at this time. - Users with the Salesforce Limited Access - Free license and View All Records permissions can create scratch orgs using an existing org shape. - Users with the Salesforce Limited Access - Free license and View All Records permissions can view scratch org snapshots created by users other than themselves. - The Salesforce Limited Access - Free license doesn’t provide access to some Salesforce CLI commands, such as `sf limits api display`. - Contact your Salesforce admin for API limits information. If your developers need broader access, consider assigning the Salesforce license. For details, see [Standard User Licenses](https://help.salesforce.com/s/articleView?id=platform.users_license_types_available.htm&type=5) in _Salesforce Help_. # Limits for Group and Professional Editions All Salesforce editions have limits that restrict the number of apps, objects, and tabs that can be used. For details on the limits for various editions, see the [Edition Limits Table](https://help.salesforce.com/articleView?id=overview_limits_general.htm). For partners who are enrolled in the ISV Program, any managed package publicly posted on the AgentExchange no longer counts against the apps/objects/tabs limits for your Salesforce Edition. This effectively means that ISV partners no longer have to worry about package installation failures because of apps/objects/tabs limits being exceeded. This feature is automatically enabled after your app passes the security review. # Link a Namespace to a Dev Hub Org To use a namespace with a scratch org, you must link the Developer Edition org where the namespace is registered to a Dev Hub org. ## Before You Begin Complete these tasks before you link a namespace. - If you don’t have an org with a registered namespace, create a Developer Edition org that is separate from the Dev Hub or scratch orgs. If you already have an org with a registered namespace, you’re good to go. - In the Developer Edition org, create and register the namespace. **important:** Choose namespaces carefully. If you’re trying out this feature or need a namespace for testing purposes, choose a disposable namespace. Don’t choose a namespace that you want to use in the future for a production org or some other real use case. After you associate a namespace with an org, you can't change it or reuse it. 1. Log in to your Dev Hub org as the System Administrator or as a user with the Salesforce DX Namespace Registry permissions. **tip:** Make sure your browser allows pop-ups from your Dev Hub org. 1. From the App Launcher menu, select **Namespace Registries**. 2. Click **Link Namespace**. 2. In the window that pops up, log in to the Developer Edition org in which your namespace is registered using the org's System Administrator's credentials. You can’t link orgs without a namespace: sandboxes, scratch orgs, patch orgs, and branch orgs require a namespace to be linked to the Namespace Registry. ## Next Steps To view all the namespaces linked to the Namespace Registry, select the **All Namespace Registries** list view. # Link a Namespace to a Dev Hub Org To use a namespace with a scratch org, you must link the Developer Edition org where the namespace is registered to a Dev Hub org. ## Before You Begin Complete these tasks before you link a namespace. - If you don’t have an org with a registered namespace, create a Developer Edition org that is separate from the Dev Hub or scratch orgs. If you already have an org with a registered namespace, you’re good to go. - In the Developer Edition org, create and register the namespace. **important:** Choose namespaces carefully. If you’re trying out this feature or need a namespace for testing purposes, choose a disposable namespace. Don’t choose a namespace that you want to use in the future for a production org or some other real use case. After you associate a namespace with an org, you can't change it or reuse it. 1. Log in to your Dev Hub org as the System Administrator or as a user with the Salesforce DX Namespace Registry permissions. **tip:** Make sure your browser allows pop-ups from your Dev Hub org. 1. From the App Launcher menu, select **Namespace Registries**. 2. Click **Link Namespace**. 2. In the window that pops up, log in to the Developer Edition org in which your namespace is registered using the org's System Administrator's credentials. You can’t link orgs without a namespace: sandboxes, scratch orgs, patch orgs, and branch orgs require a namespace to be linked to the Namespace Registry. ## Next Steps To view all the namespaces linked to the Namespace Registry, select the **All Namespace Registries** list view. # Link a Solution to Your AgentExchange Listing Your listing is a tool for marketing and distributing your solution to customers. Search your connected solutions and select the one that you want to add to your listing on AgentExchange. ## Before You Begin Before you can link a solution to an AgentExchange listing, you must first connect the solution to the AgentExchange Partner Console. **note:** You can link a solution to multiple listings. However, doing so can impact your listing’s ranking on AgentExchange. The metrics that Salesforce uses to rank solutions, such as page views, are diluted across multiple listings. ## Steps 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Listings**. 3. To link a solution to an existing listing, select the listing. To link a solution to a new listing, click **New Listing**, then select a listing type and language. 4. Click **Link Your Solution**. 5. Search connected solutions. 6. Select a solution. 7. If prompted, select a solution version. The solution is automatically linked to the listing. **See Also** - [Connect Your Solution to the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-connect-solution.md) - [AgentExchange Solution Types](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-solution-types.md) # List Your Consulting Services on AgentExchange When you create a consultant listing on AgentExchange, you’re creating your firm’s public profile. This is where customers evaluate your track record, including competencies, achievements, certifications, and reviews. This topic walks you through the listing creation process specific to Consulting Partners. If you provide implementation, advisory, training, or managed services, start here. ## Before You Begin To create a consultant listing, you need: - A Salesforce Partner Community account - Access to the AgentExchange Partner Console While a Partner Community account and lead collection can be configured using any Salesforce org, we recommend using a Partner Business Org (PBO). Unlike trial or standard orgs, a PBO doesn’t expire, so you don’t lose access to your listing management or lead data. It’s also useful to have a dedicated org to track all partner activity. If you haven’t joined the Partner program yet, see [Get Ready to Distribute on AgentExchange](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-partner-start.md). ## Understand How Consultant Listings Differ from Solution Listings Consultant listings work differently from package-based solution listings in a few important ways. - **No security review required.** Your listing doesn’t include a managed package, so there’s no code to review. - **No approval process.** You can publish your listing immediately. No one reviews it before it goes live. - **One call-to-action (CTA) button.** Customers see a single Learn More button, not Get It Now or Try It. - **Competencies tab.** Your listing displays verified competencies, certifications, and CSAT scores pulled from your Partner program activity. # Make Your AgentExchange Listing Private If you no longer want your AgentExchange listing to be publicly available, make it private. After you make a listing private, customers can’t discover it by browsing or searching AgentExchange. Customers who have the listing URL can still access private listings directly. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Listings**. 3. Select the listing that you want to make private. 4. Click **Listing Summary**. If you don’t see the Listing Summary menu item, your listing isn’t publicly available on AgentExchange. You can make a listing private only if it’s publicly available. 5. Under Settings, click **Make Private**. 6. To confirm the action, enter `PRIVATE`, and then click **Make private**. # Manage API and Dynamic Apex Access in Packages API Access is a package setting that controls the dynamic Apex and API access that package components have to standard and custom objects. The setting displays for both the developer and installer on the package detail page. | User Permissions Needed | | | ---------------------------------------------------------------------------------------------- | ----------------------------- | | To edit API and dynamic Apex access for a package you’ve created or installed: | Create AppExchange packages | | To accept or reject package API and dynamic Apex access for a package as part of installation: | Download AppExchange packages | - The developer of an AgentExchange package can restrict API access for a package before uploading it to AgentExchange. After it’s restricted, the package components receive Apex and API sessions that are restricted to the custom objects in the package. The developer can also enable access to specific standard objects, and any custom objects in other packages that this package depends on. - The installer of a package can accept or reject package access privileges when installing the package to their organization. - After installation, an administrator can change Apex and API access for a package at any time. The installer can also enable access on additional objects such as custom objects created in the installer's organization or objects installed by unrelated packages. ## Setting API and Dynamic Apex Access in Packages To change package access privileges in a package you or someone in your organization has created: 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. Select a package. 3. The API Access field displays the current setting, Restricted or Unrestricted, and a link to either **Enable Restrictions** or **Disable Restrictions**. If Read, Create, Edit, and Delete access aren’t selected in the API access setting for objects, users don’t have access to those objects from the package components, even if the user has the Modify All Data and View All Data permissions. Use the API Access field to: - **Enable Restrictions**— This option is available only if the current setting is Unrestricted. Select this option if you want to specify the dynamic Apex and API access that package components have to standard objects in the installer's organization. When you select this option, the Extended Object Permissions list is displayed. To enable access for each object in the list, select the Read, Create, Edit, or Delete checkboxes. This selection is disabled in some situations. Click **Save** when finished. For more information about choosing the Restricted option, including information about when it’s disabled, see [Considerations for API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/about-client-security-profile.md). - **Disable Restrictions**—This option is available only if the current setting is Restricted. Select this option if you don’t want to restrict the Apex and API access privileges that the components in the package have to standard and custom objects. This option gives all the components in the package the same API access as the user who is logged in. For example, if a user can access accounts, an Apex class in the package that accesses accounts would succeed when triggered by that user. - **Restricted**—Click this link if you already restricted API access and wish to edit the restrictions. ## Accepting or Rejecting API and Dynamic Apex Access Privileges during Installation To accept or reject the API and dynamic Apex access privileges for a package you’re installing: - Start the installation process on AgentExchange. - In **Approve API Access**, either accept by clicking **Next**, or reject by clicking **Cancel**. Complete the installation steps if you haven’t canceled. ## Changing API and Dynamic Apex Access Privileges After Installation To edit the package API and dynamic Apex access privileges after you’ve installed a package: 1. From Setup, enter `Installed Packages` in the Quick Find box, then select **Installed Packages**. 2. Click the name of the package you wish to edit. 3. The API Access field displays the current setting, Restricted or Unrestricted, and a link to either **Enable Restrictions** or **Disable Restrictions**. If Read, Create, Edit, and Delete access aren’t selected in the API access setting for objects, users don’t have access to those objects from the package components, even if the user has the Modify All Data and View All Data permissions. Use the API Access field to: - **Enable Restrictions**— This option is available only if the current setting is Unrestricted. Select this option if you want to specify the dynamic Apex and API access that package components have to standard objects in the installer's organization. When you select this option, the Extended Object Permissions list is displayed. To enable access for each object in the list, select the Read, Create, Edit, or Delete checkboxes. This selection is disabled in some situations. Click **Save** when finished. For more information about choosing the Restricted option, including information about when it’s disabled, see [Considerations for API and Dynamic Apex Access in Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/about-client-security-profile.md). - **Disable Restrictions**—This option is available only if the current setting is Restricted. Select this option if you don’t want to restrict the Apex and API access privileges that the components in the package have to standard and custom objects. This option gives all the components in the package the same API access as the user who is logged in. For example, if a user can access accounts, an Apex class in the package that accesses accounts would succeed when triggered by that user. - **Restricted**—Click this link if you have already restricted API access and wish to edit the restrictions. # Manage Features in First-Generation Managed Packages Control how you release features to customers with the Feature Management App (FMA). The FMA extends the functionality of the License Management App (LMA). Use the FMA to manage features as easily as you manage licenses with the LMA. Here at Salesforce, we sometimes run pilot programs, like the one we ran when we introduced Feature Management. Sometimes we dark-launch features to see how they work in production before sharing them with you. Sometimes we make features available to select orgs for limited-time trials. And sometimes we want to track activation metrics for those features. With feature parameters, we’re extending this functionality to you. Install the FMA in your License Management Org (LMO). The FMA extends the License Management App, and like the LMA, it’s a managed package. - **[Feature Parameter Metadata Types and Custom Objects](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-types-objects.md)** Feature parameters are represented as Metadata API types in your packaging org, as records of custom objects in your License Management Org, and as hidden records in your subscriber’s org. - **[Set Up Feature Parameters](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-feature-parameters-setup.md)** Set up the Feature Management App in your License Management Org, define feature parameters, and add them to your package. - **[Use LMO-to-Subscriber Feature Parameters to Enable and Disable Features](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-lmo-to-subscriber.md)** Feature parameters with a data flow direction value of `LMO to Subscriber` are writable at your end and read-only in your subscriber’s org. These feature parameters serve as permissions or limits. Use LMO-to-subscriber feature parameters to enable or disable new features or to control how many of a given resource your subscriber can use. Or, enable features for a limited trial period. Assign values to LMO-to-subscriber feature parameters by updating junction object records in your LMO, and then check those values in your code. - **[Track Preferences and Activation Metrics with Subscriber-to-LMO Feature Parameters](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-subscriber-to-lmo.md)** Use subscriber-to-LMO feature parameters to track feature activation in your subscriber’s org. Parameter values are assigned on the subscriber’s end and then sent to your LMO. To collect the values, update the feature parameters in your subscriber’s org using Apex code. Check with your legal team before obtaining activation metrics from your customers. Use activation metrics to collect only aggregated data regarding feature activation. - **[Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-hide-custom-objects-permissions.md)** Occasionally, you want to include custom permissions or custom objects in a package but not show them to your subscribers. For example, if you're piloting a feature for a few select orgs, and want to hide custom permissions and custom objects related to the pilot feature. - **[Best Practices for Feature Management](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-best-practices.md)** Here are some best practices when working with feature parameters. - **[Considerations for Feature Management](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-considerations.md)** Keep these considerations in mind when working with feature parameters. # Manage Features in Second-Generation Managed Packages Take the License Management App (LMA) a step further by extending it with the Feature Management App (FMA). Here at Salesforce, we sometimes run pilot programs, like the one we ran when we introduced Feature Management. Sometimes we dark-launch features to see how they work in production before sharing them with you. Sometimes we make features available to select orgs for limited-time trials. And sometimes we want to track activation metrics for those features. With feature parameters, we’re extending this functionality to you. Install the FMA in your License Management Org (LMO). The FMA extends the License Management App, and like the LMA, it’s a managed package. - **[Feature Parameter Metadata Types and Custom Objects](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-fma-types-objects.md)** Feature parameters are represented as Metadata API types in your package metadata, as records of custom objects in your LMO, and as hidden records in your subscriber’s org. - **[Set Up Feature Parameters](https://developer.salesforce.com/docs/platform/fma/pd-fma-feature-parameters-setup.md)** Set up the Feature Management App in your License Management Org, define feature parameters, and add them to your package. - **[Use LMO-to-Subscriber Feature Parameters to Enable and Disable Features](https://developer.salesforce.com/docs/platform/fma/pd-fma-lmo-to-subscriber.md)** Feature parameters with a data flow direction value of `LMO to Subscriber` are writable at your end and read-only in your subscriber’s org. These feature parameters serve as permissions or limits. Use LMO-to-subscriber feature parameters to enable or disable new features or to control how many of a given resource your subscriber can use. Or, enable features for a limited trial period. Assign values to LMO-to-subscriber feature parameters by updating junction object records in your LMO, and then check those values in your code. - **[Track Preferences and Activation Metrics with Subscriber-to-LMO Feature Parameters](https://developer.salesforce.com/docs/platform/fma/pd-fma-subscriber-to-lmo.md)** Use subscriber-to-LMO feature parameters to track feature activation in your subscriber’s org. Parameter values are assigned on the subscriber’s end and then sent to your LMO. To collect the values, update the feature parameters in your subscriber’s org using Apex code. Check with your legal team before obtaining activation metrics from your customers. Use activation metrics to collect only aggregated data regarding feature activation. - **[Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs](https://developer.salesforce.com/docs/platform/fma/pd-fma-hide-custom-objects-permissions.md)** Occasionally, you want to include custom permissions or custom objects in a package but not show them to your subscribers. For example, if you're piloting a feature for a few select orgs, and want to hide custom permissions and custom objects related to the pilot feature. - **[Best Practices for Feature Management](https://developer.salesforce.com/docs/platform/fma/fma-best-practices.md)** Here are some best practices when working with feature parameters. - **[Considerations for Feature Management](https://developer.salesforce.com/docs/platform/fma/fma-considerations.md)** Keep these considerations in mind when working with feature parameters. # Manage Install Request Approvers Designate users who can install AgentExchange apps for requesters in your org. When Install Request Approvers is on, Agentforce Builder users who can't install an app can send an install request instead. ## Approver List You can designate up to 100 approvers. While Install Request Approvers is on, keep at least one approver on the list. New approvers must be active and have the Download AgentExchange Packages permission. If an existing approver becomes inactive or loses the permission, they remain on the list but no longer receive requests. ## Access Install Request Approvers In Setup, the navigation item is **Install Request Approvers**, and the Setup page title is **Install App Request Approvers**. The page heading indicates whether Install Request Approvers is on. # Manage Licenses for Managed Packages Use the License Management App (LMA) to manage leads and licenses for your AgentExchange solutions. By integrating the LMA into your sales and marketing processes, you can better engage with prospects, retain existing customers, and grow your ISV business. The LMA is a managed package that is installed in all partner business orgs (PBO) and includes custom objects that track details on packages, package versions, and licenses. | Availability | | ------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, and **Unlimited** Editions | | I need to... | Permissions | For details, see... | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Configure the LMA | System Admin profile | [Get Started with the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-setup.md) | | Bill subscribers or monitor license expiration | Object Permissions: Read | [Lead and License Records in the LMA](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_terms_relationships.htm) | | Convert trial subscriptions into paying customers | Object Permissions: Edit | [Modify a License Record](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_edit_license.htm) | | Customize the LMO | Object Permissions: Edit | [Extend the LMA](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_extend.htm) | | Provision licenses to a subscriber | Object Permissions: Edit | [Modify a License Record](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_edit_license.htm) | | Support subscribers with technical issues | Various permissions (see [Assign Permissions to the Subscriber Support Console](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-subscriber-org-permissions.md) for details) | [Troubleshoot Subscriber Issues](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_subscriber_support_overview.htm) | **note:** The LMA is available only in English. The LMA is available to eligible Salesforce partners. For more information on the Partner Program, including eligibility requirements, visit [https://partners.salesforce.com](https://partners.salesforce.com). - **[Get Started with the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-setup.md)** To start managing leads and licenses with the License Management App (LMA), complete these installation and configuration steps. - **[Lead and License Records in the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-terms-relationships.md)** Each time a customer installs your managed package, the License Management App (LMA) creates lead and license records. - **[Modify a License Record](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-edit-license.md)** You can change a customer’s access to your offering by modifying a license record using the License Management App (LMA). For example, you can increase or decrease the number of seats included with a license or change the expiration date. - **[Refresh Licenses for a Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-refresh-licenses.md)** To sync all license records for a package across all subscriber installations, you refresh the license. Refreshing the license can also resolve discrepancies between the number of licenses in a subscriber’s org and the number displayed in the License Management App (LMA). Refreshing is required when you move the LMA to a different org. - **[Extending the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-extend.md)** The License Management App (LMA) is a managed package that you can customize and extend. In addition to using the LMA to manage leads and licenses, many partners also integrate it into their existing business processes. - **[Move the License Management App to Another Salesforce Org](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-change-org.md)** You can move an LMA to a different org, but your package and license records don’t automatically move with it. You must manually relink your packages and refresh the licenses. - **[Troubleshoot the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-troubleshoot.md)** If you’re experiencing issues with the License Management App, review these troubleshooting tips. - **[Best Practices for the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-best-practices.md)** Follow these best practices when you use the License Management App (LMA). - **[Troubleshoot Subscriber Issues](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-subscriber-support-overview.md)** Use the Subscriber Support Console to access information about your subscribers. Subscribers can also grant you login access to troubleshoot issues directly within your app. After you’re granted access, you can log in to the subscriber’s org and view their configuration and data to troubleshoot and resolve issues. # Manage Orgs in the Environment Hub You can manage all your existing Salesforce orgs from one location by connecting them to the Environment Hub. You can also create orgs using Salesforce templates for development, testing, and trial purposes. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, and **Unlimited** Editions| # Manage Orgs with Environment Hub The Environment Hub lets you connect, create, view, and log in to Salesforce orgs from one location. If your company has multiple environments for development, testing, and trials, the Environment Hub lets you streamline your approach to org management. |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, and **Unlimited** Editions| **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). From the Environment Hub, you can: - Connect existing orgs to the hub with automatic discovery of related orgs. - Create standard and partner edition orgs for development, testing, and trials. - View and filter hub members according to criteria that you choose, like edition, creation date, instance, origin, and SSO status. - Create single sign-on (SSO) user mappings for easy login access to hub members. Each hub member org corresponds to an EnvironmentHubMember object. EnvironmentHubMember is a standard object, similar to Accounts or Contacts, so you can use the platform to extend or modify the Environment Hub programmatically. For example, you can create custom fields, set up workflow rules, or define user mappings and enable SSO using the API for any hub member org. # Manage Scratch Orgs from the Dev Hub Org You can view and delete your scratch orgs and their associated requests from the Dev Hub org. ## Before You Begin In the Dev Hub org, the ActiveScratchOrg standard object represents the scratch orgs that are currently in use. The ScratchOrgInfo standard object represents the requests that were used to create scratch orgs and provides historical context. 1. Log in to the Dev Hub org as the System Administrator or as a user with the Salesforce DX permissions. 2. From the App Launcher, select **Active Scratch Orgs** to see a list of all active scratch orgs. To view more details about a scratch org, click the link in the Number column. 3. To delete an active scratch org from the Active Scratch Orgs list view, choose **Delete** from the dropdown. Deleting an active scratch org doesn’t delete the request (ScratchOrgInfo) that created it, but it does free up a scratch org so that it doesn’t count against your allocations. 4. To view the requests that created the scratch orgs, select **Scratch Org Infos** from the App Launcher. To view more details about a request, click the link in the Number column. The details of a scratch org request include whether it's active, expired, or deleted. 5. To delete the request that was used to create a scratch org, choose **Delete** from the dropdown. Deleting the request (ScratchOrgInfo) also deletes the active scratch org. # Manage Scratch Orgs from the Dev Hub Org You can view and delete your scratch orgs and their associated requests from the Dev Hub org. ## Before You Begin In the Dev Hub org, the ActiveScratchOrg standard object represents the scratch orgs that are currently in use. The ScratchOrgInfo standard object represents the requests that were used to create scratch orgs and provides historical context. 1. Log in to the Dev Hub org as the System Administrator or as a user with the Salesforce DX permissions. 2. From the App Launcher, select **Active Scratch Orgs** to see a list of all active scratch orgs. To view more details about a scratch org, click the link in the Number column. 3. To delete an active scratch org from the Active Scratch Orgs list view, choose **Delete** from the dropdown. Deleting an active scratch org doesn’t delete the request (ScratchOrgInfo) that created it, but it does free up a scratch org so that it doesn’t count against your allocations. 4. To view the requests that created the scratch orgs, select **Scratch Org Infos** from the App Launcher. To view more details about a request, click the link in the Number column. The details of a scratch org request include whether it's active, expired, or deleted. 5. To delete the request that was used to create a scratch org, choose **Delete** from the dropdown. Deleting the request (ScratchOrgInfo) also deletes the active scratch org. # Manage Versions of First-Generation Managed Packages After you upload a package to AgentExchange, you can still manage it from the Package Manager page. | User Permissions Needed | | | ----------------------- | --------------------------- | | To upload packages: | Upload AppExchange Packages | **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). To manage your versions: 1. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 2. Select the package that contains the app or components you uploaded. 3. Select the version number listed in the Versions tab. - To change the password option, click **Change Password** link. - To prevent new installations of this package while allowing existing installations to continue operating, click **Deprecate**. **note:** You can’t deprecate the most recent version of a managed package. - To make a deprecated version available for installation again, click **Undeprecate**. - To view the package installation URL, see **Installation URL**. Installation URLs contain the 04t package ID for the package version. # Manage Your AgentExchange Listings Create listings for the solutions you distribute on AgentExchange. Set up a company profile for your AgentExchange business. Connect your Salesforce business and development orgs, solutions, and trials to the Partner Console. Configure default license settings for your managed packages. Collect leads when customers interact with your listings. Track listing performance and package usage with analytics. # Manage Your Published Listings Update the listings that are live on AgentExchange. Link a different solution to your listing. Change the visibility of your listing to private. # 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. See [MCP for Agentforce](https://help.salesforce.com/s/articleView?id=ai.agent_mcp.htm&type=5) in _Salesforce Help_ for more information on MCP servers for Agentforce. ## MCP for Agentforce Metadata Components The underlying MCP server definition comprises four packageable metadata types. | Feature Name | Metadata Name | Available In | More Information | | ----------------------------- | --------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | External Credential | ExternalCredential | Managed 2GP and Managed 1GP | Contains the named principal and authentication parameters required for the MCP connection. | | External Service Registration | ExternalServiceRegistration | Managed 2GP and Managed 1GP | Defines the registration provider and schema type specifically as ModelContextProtocol. | | Named Credential | NamedCredential | Managed 2GP and Managed 1GP | Manages the callout endpoint details for your MCP server. | | Permission Set | PermissionSet | Managed 2GP and Managed 1GP | Grants your users access to the necessary External Credential Principal and Read access to the User External Credential object. | When you create an MCP server registration through Agentforce Registry in Setup, the components follow the correct naming conventions and the dependencies between them are established. **note:** These components aren’t packageable at this time. - MCP tool actions, which are agent actions that reference server tools. - Agentforce Gateway policies, which set governance rules, define usage limits, and control access to MCP tools and other APIs. ## Set Up Your Salesforce DX Project and Scratch Org Depending on your use case, you can package the MCP server registration either as a component of an Agentforce extension package or as a standalone managed package. To work with Agentforce as an MCP client, configure your Salesforce DX project and provision a scratch org with the Chatbot and Einstein1AIPlatform features enabled. 1. Update your project configuration file (`sfdx-project.json`) to use API version 66.0 or greater and set your namespace. 2. Update your scratch org definition file (`project-scratch-def.json`) to include the required Chatbot and Einstein1AIPlatform features. **note:** Scratch orgs are the primary means by which partners develop MCP server registration metadata. ```json { "orgName": "Appy Industries", "edition": "Partner Developer", "features": ["Chatbot", "Einstein1AIPlatform"], "settings": { "botSettings": { "enableBots": true } } } ``` ## Create and Retrieve the MCP Server Registration Register the MCP server in Agentforce Registry, and then retrieve the MCP server metadata. 1. Create an MCP server registration by following the instructions in [Register a Third-Party MCP Server in Agentforce Registry](https://help.salesforce.com/s/articleView?id=ai.agent_mcp_connect_register.htm&type=5) in _Salesforce Help_. **note:** To configure an MCP server using an authentication type other than OAuth 2.0 Client Credential Flow, enter your MCP server endpoint URL and select **No Auth** for the Authentication Method. If your MCP server supports unauthenticated `tool/list` requests, you can configure the required authentication method later. If your MCP server requires authenticated `tool/list` requests, follow the instructions in the Example Metadata for Establishing an MCP Server Registration section. 2. After you register the MCP server, retrieve the MCP server metadata by running the `project retrieve start` Salesforce CLI command. ```nolang sf project retrieve start \ --metadata "ExternalCredential:{MCP_SERVER_NAME}" \ --metadata "ExternalServiceRegistration:{MCP_SERVER_NAME}" \ --metadata "NamedCredential:{MCP_SERVER_NAME}" \ --metadata "PermissionSet:{MCP_SERVER_NAME}_Perm_Set" \ --target-org {ORG_ALIAS} ``` ## Deploy and Activate the MCP Server Deploy the MCP server metadata and assign the MCP permission set by using Salesforce CLI commands. Then, activate the MCP server in Setup. 1. Deploy the MCP server metadata by running the `project deploy start` CLI command with the metadata that you retrieved. ```nolang sf project deploy start \ --metadata "ExternalCredential:{MCP_SERVER_NAME}" \ --metadata "ExternalServiceRegistration:{MCP_SERVER_NAME}" \ --metadata "NamedCredential:{MCP_SERVER_NAME}" \ --metadata "PermissionSet:{MCP_SERVER_NAME}_Perm_Set" \ --target-org {ORG_ALIAS} ``` 2. Assign the MCP server permission set by running the `org assign permset` CLI command. ```nolang sf org assign permset --name {MCP_SERVER_NAME}_Perm_Set --target-org {ORG_ALIAS} ``` 3. Activate the MCP server through Setup. **note:** These steps are specific to the OAuth 2.0 Client Credentials Flow authorization type. Depending on your MCP server authentication method, your specific configuration can differ. 1. From Setup, in the Quick Find box, enter `Agentforce Registry`, and then select **MCP Servers**. 2. Click the name of the MCP server that you deployed. The Connection Status is **disconnected**. 3. Under Authentication Details, click the Named Credential listed for your MCP server. 4. On the Named Credential page, click the External Credential. 5. On the External Credential page, scroll down to the Principals section, which displays one principal with a parameter name of MCPAuthentication. Click the **Actions** drop-down menu, and then select **Edit**. 6. Enter the Client ID and Client Secret. Then, click **Save**. 7. Navigate back to the MCP Servers page in Setup. Select your MCP server and confirm that the Connection Status is now **Active**. 8. Click the **Tools** tab, and then click **Manage Tools**. Select the tools to activate in the org, and then save your changes. 9. From Setup, in the Quick Find box, enter `Agentforce Assets`, and then select **Agentforce Assets**. 10. Click the **Actions** tab to view the newly created MCP tool actions, which are indicated by an orange icon (![An orange icon with two white arrows inside pointing left and right.](https://developer.salesforce.com/media/pkg2_dev/agent_mcp_tool_action_icon.png)). ## Example Metadata for Establishing an MCP Server Registration As an alternative way to establish an MCP server registration in an org, you can manually generate metadata to include in your Salesforce DX project. We recommend manually generating metadata if you’re configuring an authorization type other than the OAuth 2.0 Client Credentials Flow authorization type and your MCP server requires authenticated `tool/list` requests. In the metadata examples, replace these placeholder values with the values for your package or MCP server. **note:** When you replace the placeholder values, make sure to also remove the brackets. For example, replace `{NAMESPACE}` with `astro__`. - `NAMESPACE`: Package namespace, if applicable. Include double underscores after your namespace. For example: `astro__` - `MCP_SERVER_NAME`: Name of your MCP service, which contains only alphanumeric characters. Make sure to enter the MCP service name in both the file names and within the files. - `MCP_SERVER_URL`: Endpoint for your MCP server. `externalCredentials/{MCP_SERVER_NAME}.externalCredential-meta.xml` ```xml Custom DefaultGroup Custom AuthProtocolVariant NoAuthentication MCPAuthentication MCPAuthentication NamedPrincipal 1 ``` `externalServiceRegistrations/{MCP_SERVER_NAME}.externalServiceRegistration-meta.xml` ```xml {NAMESPACE}{MCP_SERVER_NAME} {MCP_SERVER_NAME} ModelContextProtocol {"serverDescriptor":{"protocolVersion":"2025-06-18","serverInfo":{"name":"{MCP_SERVER_NAME}","version":"1.0.0"}},"tools":[],"resources":[]} ModelContextProtocol {"protocolVersion":"2025-06-18","serverInfo":{"name":"{MCP_SERVER_NAME}","version":"1.0.0"},"instructions":null} Incomplete 8 ``` `namedCredentials/{MCP_SERVER_NAME}.namedCredential-meta.xml` ```nolang true true Enabled true Url Url https://{MCP_SERVER_URL} {NAMESPACE}{MCP_SERVER_NAME} ExternalCredential Authentication SecuredEndpoint ``` `permissionsets/{MCP_SERVER_NAME}_Perm_Set.permissionset-meta.xml` ```nolang Perm set for MCP Server 'MCP_SERVER_NAME' true {NAMESPACE}{MCP_SERVER_NAME}-MCPAuthentication false false false false true false UserExternalCredential false false ``` # Medium-Sized Partners Medium-sized partners have bigger subscriber bases and about six managed packages. A medium-sized partner’s total daily usage data across all managed packages is at or just over 20 GB. Also, this partner’s queries approach or hit the 15-minute processing time limit. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | We recommend that after you run your regular queries one time, use catch-up queries as your main queries for subscriber snapshots and package usage summaries. Use a combination of daily queries and catch-up queries for package usage logs. | Data Type | How to Get Started | How to Schedule Catch-Up Queries | | ----------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscriber Snapshots | An initial query to retrieve data from when App Analytics was enabled for your managed packages. |
  • One daily query.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to 30 days ago.
  • Omit `EndTime`.
  • Each day advance `StartTime` and `AvailableSince` by 1 day.
| | Package Usage Summaries | An initial query to retrieve data from when App Analytics was enabled for your managed packages. |
  • One daily catch-up query.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to the first of the previous month.
  • Omit `EndTime`.
  • Each day advance `AvailableSince` by 1 day.
  • Each month advance `StartTime` to the first of the previous month.
| | Package Usage Logs | One regular daily query per package. |
  • One daily catch-up query per package.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to 30 days ago.
  • Set `EndTime` equal to the `StartTime` of your regular query.
  • Each day advance `StartTime`, `EndTime`, and `AvailableSince` by 1 day.
| ## Example Half of your customers use your package on an NA or EU instance, so you run your regular queries at `18:00 UTC`. The other half of your customers are on an AP instance, so you create catch-up queries to ensure that you capture data from around the world. - On March 31 at `18:00 UTC`, run your regular package usage log queries for each of your packages. Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=csv FileCompression=gzip" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-30T00:00:00Z EndTime=2021-03-31T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=csv FileCompression=gzip" ``` - On April 1 at `18:00 UTC` onwards, run regular and catch-up package usage log queries. ![Package log file regular and catch-up queries timelline on April 1.](https://developer.salesforce.com/media/pkg2_dev/app_analytics_catchup_medium_today.png) A. Regular Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=csv FileCompression=gzip" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-31T00:00:00Z EndTime=2021-04-01T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=csv FileCompression=gzip" ``` B. Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-01T00:00:00Z EndTime=2021-03-31T00:00:00Z AvailableSince=2021-03-31T18:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=csv FileCompression=gzip" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=021-03-01T00:00:00Z EndTime=2021-03-31T00:00:00Z AvailableSince=2021-03-31T18:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=csv FileCompression=gzip" ``` - On April 2, repeat the same queries that you ran on April 1, but advance the queries by a day. ![Package log file regular and catch-up queries timeline on April 2.](https://developer.salesforce.com/media/pkg2_dev/app_analytics_catchup_medium_tomorrow.png) A. Regular Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T00:00:00Z EndTime=2021-04-02T00:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=csv FileCompression=gzip" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-04-01T00:00:00Z EndTime=2021-04-02T00:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=csv FileCompression=gzip" ``` B. Catch-Up Queries Package 1 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2021-03-02T00:00:00Z EndTime=2021-04-01T00:00:00Z AvailableSince=2021-04-01T18:00:00Z DataType=PackageUsageLog PackageIds=0336XXXXXXXXXX FileType=csv FileCompression=gzip" ``` Package 2 ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "StartTime=2020-03-02T00:00:00Z EndTime=2021-04-01T00:00:00Z AvailableSince=2021-04-01T18:00:00Z DataType=PackageUsageLog PackageIds=0337XXXXXXXXXX FileType=csv FileCompression=gzip" ``` # Metadata Access in Apex Code Use the `Metadata` namespace in Apex to access metadata in your package. Your package may need to retrieve or modify metadata during installation or update. The `Metadata` namespace in Apex provides classes that represent metadata types, as well as classes that let you retrieve and deploy metadata components to the subscriber org. These considerations apply to metadata in Apex: - You can create, retrieve, and update metadata components in Apex code, but you can’t delete components. - You can currently access records of custom metadata types and page layouts in Apex. - Managed packages not approved by Salesforce can’t access metadata in the subscriber org, unless the subscriber org enables the **Allow metadata deploy by Apex from non-certified Apex package version** org preference. Use this org preference when doing test or beta releases of your managed packages. If your package accesses metadata during installation or update, or contains a custom setup interface that accesses metadata, you must notify the user. For installs that access metadata, notify the user in the description of your package. The notice should let customers know that your package has the ability to modify the subscriber org’s metadata. You can write your own notice, or use this sample: `This package can access and change metadata outside its namespace in the Salesforce org where it’s installed.` Salesforce verifies the notice during the security review. For more information, see [Metadata](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_metadata.htm) in the _Apex Developer Guide_. # Migrate Existing Orders to the Go-To-Market App Transition to the AgentExchange Go-To-Market (GTM) app to modernize your selling lifecycle and move away from manual processes toward a unified, automated experience. By migrating existing Channel Order app (COA) customers to the GTM app, partners can significantly reduce operational overhead through automated provisioning, payment collection, and payouts. As you begin transitioning customers to the GTM app, keep these considerations in mind. - Net-new orders that meet [requirements](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/partner_marketplace_considerations_prerequisites.htm) must be conducted through the GTM app. - **Net-new is product-level, not partner-level**: Partners can sell to existing customers via the GTM app as long as it's a net-new product that the customer hasn't purchased before. **Example**: If a customer purchased App A offline, with the partner submitting an order through COA, the customer can buy App B through the AgentExchange GTM app. - **Offline contracts can't be expanded through the GTM app**: If a customer purchased app A offline, with the order submitted through COA, they can’t add more app A licenses in the GTM app during an active contract period. Extra licenses for that subscription must be processed through the original offline channel. After the contract expiration date, the customer can migrate to the GTM app. - **Add-ons are only supported for GTM app purchases**: After a customer purchases a product in the GTM app, they can expand that subscription in the GTM app with add-ons. Add-ons can include extra licenses and new products. You can't extend purchases made offline via the GTM app until you migrate the contract. - **Contracted apps only**: Partners can only sell apps they're contracted to transact through the AgentExchange GTM app. Not all apps in a partner's portfolio may be eligible. Use this table to determine whether your desired application migration process is possible. |Customer Status|Original Purchase Type|Application Migration Process|Purchase Type in GTM App|Supported in GTM App| |---------------|----------------------|-----------------------------|------------------------|--------------------| |Net-new customer|Initial order through GTM app|New contracted app in GTM*|Initial purchase|Supported| |Existing customer|Purchased offline, order submitted via COA|Cancel existing COA contract and create app contract in GTM|Initial purchase|Supported| |Existing customer|Purchased offline, order submitted via COA|Keep existing COA contract and add new licenses in GTM|Add-on|Not supported| |Existing customer|Purchased offline, order submitted via COA|Keep existing COA app and migrate to GTM upon contract renewal|Migrate to GTM with a new service order at the time of renewal|Supported| |Existing GTM customer|Purchased in GTM|Keep existing GTM order and add extra licenses|Add-on (additional licenses)|Supported| |Existing GTM customer|Purchased in GTM|Keep existing GTM order and add additional products|Add-on (new product)|Supported| *Contracted app: Any app the partner is contracted to sell through the AgentExchange GTM app. ## Transition an Existing Customer from COA to the Go-To-Market App Move an existing Channel Order App (COA) customer to the GTM App before they renew their Partner Application contract. You can't use the GTM App to distribute the same application to a customer until their active COA service order and licenses expire. 1. Cancel the COA order. 1. From your PBO, go to the COA. 2. Submit a cancellation order for the customer's active service order in the Channel Order App. Cancellations must be done at least 7 days before the renewal date. For more information about canceling a contract, see [Channel Order Application FAQ—Order Accuracy & Tracking](https://help.salesforce.com/s/articleView?id=000395544&type=1#:~:text=How%20do%20I%20terminate%20a%20contract%3F). 2. Go to the GTM app. 1. Create a customer record. 2. Create an initial offer. 3. After your cancellation order in COA has activated, create and send an offer to the customer. 4. Set the service start date. **important:** To make sure that your customers don't experience a lapse in their licenses, set the service start date to match the the expiration date of the service order you canceled in step one. # Migrate Your Subscribers from 1GP to 2GP Are you ready to migrate your converted package? To migrate a package you install the converted 2GP package into a subscriber org that already has the managed 1GP package version installed. Package migration requires that the major and minor version of the subscriber's installed package, match the major and minor version of 2GP you’re installing. After a package is migrated there’s no change to the metadata or customer data associated with the package. If your package has dependencies on other packages, the order in which you migrate the base and dependent packages is important. For more details, see [Plan Your Package Migration](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_planning.htm). ## Bulk Migrate Multiple Subscribers (Beta) To migrate multiple subscribers that all have the same package version installed, use the Salesforce CLI command to schedule a push upgrade and specify the `--migrate-to-2gp` flag. Remember the major.minor.patch version of the package you're migrating, must be identical to the major.minor.patch version installed in a subscriber org. The subscriber package version ID (starts with 04t) that you specify when migrating a package version, must be the ID for the converted 2GP package version, not the ID for the original 1GP package version. Example: ```nolang sf package push-upgrade schedule --migrate-to-2gp --package 04txyz --start-time "2024-12-06T21:00:00" --org-file upgrade-orgs.csv ``` Push upgrades for package migrations have a daily limit. Currently, you can use push upgrades to migrate 5 subscriber orgs per day. **note:** Push migrations is a beta service that is subject to the Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the [Product Terms Directory](https://ptd.salesforce.com/). Use of this beta service is at the Customer's sole discretion. Before migrating customers using push upgrades, please review these [best practices](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/push_upgrade_best_practices.htm). In particular, we strongly recommend that you work with your subscribers and follow a staggered approach, starting by migrating sandboxes first, before carrying out migrations in production. **note:** Before migrating customers using push upgrades, please review these best practices. In particular, we strongly recommend that you work with your subscribers and follow a staggered approach, starting by migrating sandboxes first, before carrying out migrations in production. ## Manually Migrate One Subscriber If you have subscribers who don't allow push upgrades to their org, they can manually upgrade to the 2GP package. Provide them with the package installation URL and they can migrate the package. ## Push Upgrade History and Org Migrations From time to time, Salesforce migrates production orgs from one instance to another. If your Dev Hub org is scheduled for an org migration, it's crucial to back up your historical data related to push upgrades and 2GP migrations, as this data won't be retained post-migration. # Modify a License Record You can change a customer’s access to your offering by modifying a license record using the License Management App (LMA). For example, you can increase or decrease the number of seats included with a license or change the expiration date. **note:** You can't use the LMA to modify licenses provisioned through AgentExchange Checkout. To modify licenses provisioned through Checkout, have your customers follow the instructions in [Add or Remove Licenses from an AgentExchange Checkout Subscription](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_checkout_update_seats.htm). 1. In the LMA, locate the license. 2. Click **Modify License**. When the LMA is installed, the Edit button doesn’t appear on the license page layout, and the Modify License button is included instead. This setup is intentional. You must edit license records on the Modified License page, don't attempt to edit license records directly. 3. Update the field values as needed. | Field | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Expiration | Enter the last day that the customer can access your package, or select **Does not expire**. | | Seats | Enter the number of licensed seats, or select **Site License** to make your package available to all users in the customer’s org. You can allocate up to 99,000,000 seats. | | Status | Select a value from the dropdown. **Trial**—Lets the customer try your offering for up to 90 days. After the trial license converts to an active license, it can’t return to a trial state. **Active**—Lets the customer use your package according to the license agreement. **Suspended**—Prohibits the customer from accessing your offering. When your offering is uninstalled, its status is set to Uninstalled, and the license can’t be edited. | 4. Click **Save**. # Modifying Custom Fields after a Package Is Released The following changes are allowed to custom fields in a package, after it’s released. | Availability | | ----------------------------------- | | Available in: **Developer** Edition | - The length of a text field can be increased or decreased. - The number of digits to the left or right of the decimal point in a number field can be increased or decreased. - A required field can be made non-required and vice versa. If a default value was required for a field, that restriction can be removed and vice versa. # Monitor the DailyAggregation CRM Analytics Recipe CRM Analytics recipes can take a while to complete. Use these steps to monitor the status of your DailyAggregation recipe. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Monitor**. 3. On the Jobs tab, locate your DailyAggregation job. 4. When your job is Successful, click **Data** to view your completed DailyAggregation dataset. # Monitor Your LMAJoin CRM Analytics Recipe CRM Analytics recipes can take a while to complete. Use these steps to monitor the status of your LMAJoin recipe. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both **Salesforce Classic** and **Lightning Experience** | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Monitor**. 3. On the Jobs tab, locate your LMAJoin job. 4. When your job is Successful, click **Data** to view your completed LMAJoin dataset. # Move the License Management App to Another Salesforce Org You can move an LMA to a different org, but your package and license records don’t automatically move with it. You must manually relink your packages and refresh the licenses. ## Before You Begin | User Permissions Needed | | | -------------------------------------------- | ----------------------------- | | To install packages: | Download AppExchange Packages | | To manage licenses in the Partner Community: | Manage Listings | It’s not possible to have Slack or the Declarative Lookup Rollup Summary (DLRS) package installed in the same org as the LMA. If the org in which you plan to install the LMA has either Slack or the DLRS package installed, uninstall them before you install the LMA. Alternatively, install the LMA in a different org. 1. To remove the association between the LMA and the org where it’s currently installed, log a case with [Salesforce Partner Support](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_integrationproviderdef.htm). 2. [Install the LMA in the new org](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-install-app.md). 3. [Associate your packages with the new org](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-associate-package.md). 4. [Refresh licenses for your packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-refresh-licenses.md). # Move to 2GP Package Development After you thoroughly test converted packages and migrations, complete your move to 2GP development. - **[Test Converted Packages and Subscriber Migrations](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-test-conversions-migrations.md)** When you complete your move to 2GP development, you can no longer create any new major or minor 1GP versions of that package. Before you make this transition, it’s critical that you thoroughly test packages converted to 2GP and the migration of subscribers to 2GP. - **[Complete the Move to 2GP Package Development](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-move-to-2gp-workflow.md)** To fully transition to 2GP package development, you retrieve the source files for your package’s latest converted version. Then, you confirm in Setup for your packaging org that you’re ready to develop and distribute your package solely using 2GP packaging. # Move to 2GP: Migrate Your Managed Packages with Ease Are you still using first-generation managed packaging (1GP) for your package development work? If so, you're not alone. Many ISVs like you are looking to move to second-generation managed packaging (2GP) and take advantage of its many benefits. If you don't have customers who are still using 1GP packages you created, you can skip this chapter and move straight to learning how to build new [2GP packages](https://trailhead.salesforce.com/content/learn/modules/second-generation-managed-packages). Package migration involves two main steps: converting an existing 1GP package into a 2GP package, and then migrating the 2GP package into a subscriber org. Package migration won't change your package's metadata, or disrrupt any subscriber data associated with your package. - **[About Package Conversion and Package Migration](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-get-started.md)** There are two main stages involved in package migrations. It starts with package conversion and ends with package migration. - **[Three Phases of Package Migration Development](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-three-stages.md)** As you move from 1GP development to 2GP development, you’ll move through three phases. - **[Plan Your Package Migration](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-planning.md)** Are you ready to move your subscribers to 2GP? The speed and ease of your package migration depend on a few key factors. - **[Before You Begin Package Migrations](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-prerequistes.md)** If you’ve never created or worked with managed 2GP packages, scratch orgs, or Salesforce CLI, take some time to learn more about Salesforce DX and second-generation managed packages. - **[Convert Your Managed 1GP Package to 2GP](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-conversion-workflow.md)** Before you convert your managed 1GP package version, ensure your development environment is set up. - **[Migrate Your Subscribers from 1GP to 2GP](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-pkg-migration-workflow.md)** Are you ready to migrate your converted package? To migrate a package you install the converted 2GP package into a subscriber org that already has the managed 1GP package version installed. Package migration requires that the major and minor version of the subscriber's installed package, match the major and minor version of 2GP you’re installing. - **[Move to 2GP Package Development](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-move-to-2gp.md)** After you thoroughly test converted packages and migrations, complete your move to 2GP development. - **[Considerations for Package Migrations](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migrations-known-limitations.md)** Review these limits and considerations for converting and migrating packages. - **[Troubleshoot Package Conversion Failures](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-troubleshoot-errors.md)** Here are some possible error scenarios that can occur when you convert a package. # 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. Considerations for Apex Accessibility Across Packages - You can’t use the `@NamespaceAccessible` annotation for an `@AuraEnabled` Apex method or an `@InvocableMethod` Apex method. - You can add or remove the `@NamespaceAccessible` annotation at any time, even on managed and released Apex code. Make sure that you don’t have dependent packages relying on the functionality of the annotation before adding or removing it. - When adding or removing `@NamespaceAccessible` Apex from a package, consider the impact to customers with installed versions of other packages that reference this package’s annotation. Before pushing a package upgrade, ensure that no customer is running a package version that would fail to fully compile when the upgrade is pushed. - If a public interface is declared as `@NamespaceAccessible`, then all interface members inherit the annotation. Individual interface members can’t be annotated with `@NamespaceAccessible`. - If a public or protected variable or method is declared as `@NamespaceAccessible`, its defining class must be either global or public with the `@NamespaceAccessible` annotation. - If a public or protected inner class is declared as `@NamespaceAccessible`, its enclosing class must be either global or public with the `@NamespaceAccessible` annotation. This example shows an Apex class marked with the `@NamespaceAccessible` annotation. The class is accessible to other packages within the same namespace. The first constructor is also visible within the namespace, but the second constructor isn’t. ```apex // A namespace-visible Apex class @NamespaceAccessible public class MyClass { private Boolean bypassFLS; // A namespace-visible constructor that only allows secure use @NamespaceAccessible public MyClass() { bypassFLS = false; } // A package private constructor that allows use in trusted contexts, // but only internal to the package public MyClass (Boolean bypassFLS) { this.bypassFLS = bypassFLS; } @NamespaceAccessible protected Boolean getBypassFLS() { return bypassFLS; } } ``` **See Also** - [Namespaces for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_plan_namespaces.htm) - [Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) - [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm) # Namespaces for Second-Generation Managed Packages A namespace is a 1–15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer’s org. A namespace is assigned to a second-generation managed package (managed 2GP) at the time that it’s created, and can’t be changed. When you specify a package namespace, every component added to a package has the namespace prefixed to the component API name. Let’s say you have a custom object called Insurance_Agent with the API name,`Insurance_Agent__c`. If you add this component to a package associated with the Acme namespace, the API name becomes `Acme__Insurance_Agent__c`. **important:** When creating a namespace, use something that’s useful and informative to users. However, don’t name a namespace after a person (for example, by using a person's name, nickname, or private information). When you work with namespaces, keep these considerations in mind. - You can develop more than one managed 2GP package and associate the packages with the same namespace. But a single managed 2GP package can't be associated with more than one namespace. - If you work with more than one namespace, we recommend that you set up one project for each namespace. - It's beneficial for managed 2GP packages to share the same namespace, but it's not required. Carefully consider your package and namespace strategy. After a namespace is associated with a managed 2GP, the association can't be changed. - There are scenarios where you may prefer to keep a managed 2GP package isolated from other managed 2GP packages you're developing. For example, if you’re developing a product that you intend to sell or spin off, having a unique namespace for that package enables you to transfer the namespace with the package. **See Also** - [Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) - [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_reg_namespace.htm) - [Avoid Namespace Collisions in Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_namespace_collisions.htm) # Navigate Learning Resources for Salesforce Partners Reach milestones and accomplish goals on your Salesforce partner journey faster with curated resources from Trailhead, the Partner Community, and more. |I want to:|Recommended resources| |----------|---------------------| |Learn the fundamentals of building an AgentExchange ISV business.|Trailhead: [Grow Your Business as an ISV Partner](https://trailhead.salesforce.com/content/learn/trails/isv_business_beginner)| |Learn the fundamentals of building a Salesforce consulting practice.|Trailhead: [Build Your Practice as a Consulting Partner](https://trailhead.salesforce.com/content/learn/trails/consulting_partner)| |Get hands-on practice with AgentExchange ISV tools and technologies, such as second generation managed packages.|Trailhead: [Build Apps as an ISV Partner](https://trailhead.salesforce.com/content/learn/trails/isv_developer_beginner)| |Discover tools and best practices for building secure solutions.|Salesforce Developers: [Security Developer Center](https://developer.salesforce.com/developer-centers/security)| |Ask questions and get help when I’m stuck|Salesforce Partner Community: [Questions & Answers Community Group](https://partners.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F9300000001tcz)| |Stay informed about changes and updates to the Salesforce Partner Program|Salesforce Partner Community: Official: [ISV Partner Program Community Group](https://partners.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F9300000009Pda)| # Notifications for Package Errors Accurately track failed package installations, upgrades, and uninstallations in subscriber orgs with the Notifications for Package Errors feature. Proactively address issues with managed and unmanaged packages and provide support to subscribers so that they can successfully install and upgrade your apps. You can choose to send a notification to an email address in your org when a subscriber’s attempt to install, upgrade, or uninstall a packaged app fails. To enable this feature, contact your Salesforce representative. Errors can happen with these package operations: - Installation - Upgrade - Push upgrade - Uninstallation When an installation fails, an email is sent to the specified address with the following details: - Reason for the failure - Subscriber org information - Metadata of the package that wasn’t installed properly - Who attempted to install the package This example email is for a package installation that failed because the base package wasn’t installed before the subscriber tried to install an extension. ```nolang On Mon, Jul 13, 2022 at 11:51 AM, NO REPLY wrote: The install of your package failed. Here are the details: Error Message: 00DD00000007uJp: VALIDATION_FAILED [DB 0710 DE1 Pkg1 1.2: A required package is missing: Package "DB 0710 DE1 Pkg1", Version 1.2 or later must be installed first.] Date/Time of Occurrence = Mon Jul 13 18:51:20 GMT 2015 Subscriber Org Name = DB 071015 EE 1 Subscriber Org ID = 00DD00000007uJp Subscriber Org Status = TRIAL Subscriber Org Edition = Enterprise Edition Package Name = DB 0710 DE2 Pkg1 Package ID = 033D000000060EE Package Namespace = DB_0710_DE2 Package Type = MANAGED Package Version Name = 1.2 Package Version Number = 1.2 Package Version Id = 04tD00000006QoF Installer Name = Admin User Installer Email Address = db@salesforce.com ``` - **[Set the Notification Email Address](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-notification-set.md)** Specify which address to email when a package installation, upgrade, or uninstallation fails. # OEM User License Guide Learn about the license types that are available to OEM partners. ## License Types and Availability These licenses are available for resale to new and existing OEM partners. Licenses that OEM partners sell can only be used to access the partner solution. Internal User Licenses: - Force.com Platform Embedded—A contractually restricted Salesforce Platform user license. - Force.com Platform Embedded Starter—A contractually restricted Salesforce Platform Starter license that provides access to only 10 objects. - Force.com Platform Embedded Admin—A contractually restricted Salesforce admin license that’s required on all initial orders. It’s used to configure and administer the OEM application. This license prohibits providing access to or use of any CRM functionality. Prohibitions include, but aren’t limited to, create, read, update, and delete (CRUD) on Leads, Opportunities, Cases, Solutions, Forecasts, and Campaigns. - Force.com Platform Embedded Partner Admin—A contractually restricted Enterprise Edition Salesforce admin license. Partner Admin User subscriptions can be used only by partners to configure and administer OEM apps. This license prohibits providing access to or use of any CRM functionality. Customers can’t use this license. - Integration User License—An API-only user license; no customization for OEM partners. See [Give Integration Users API-Only Access](https://help.salesforce.com/s/articleView?id=platform.integration_user.htm&type=5) - Financial Service Cloud Embedded Starter—A contractually and technically restricted Enterprise Edition version of the Financial Services Cloud–Sales & Service product. This license includes the features of Force.com Platform Embedded and part of the Financial Services Cloud data model.  - Identity for Employees—An Identity Only license that provides single sign-on (SSO) and identity provider features for customers who manage identity and access rules for apps via Salesforce. External User Licenses: These licenses can be assigned to external users only. - Commerce Portal—Custom digital experiences to engage any external stakeholder, including Brand Engagement and Customer Loyalty. - Customer Community—Business-to-consumer experiences well suited for communities with large numbers of external users who need access to Salesforce Knowledge. - Customer Community Plus—Similar to the Customer Community license with more storage, access to reports and dashboards, and advanced sharing. - Partner Community—Business-to-business experiences for users who need access to sales data, where the OEM partner’s solution allows access to Sales objects. Partner Community licenses can’t be used with person accounts. These tables list object access, user permissions and features, and org limits for the Internal User license. For external user licenses limits and CRUD access information, refer to [Experience Cloud User Licenses](https://help.salesforce.com/s/articleView?id=platform.users_license_types_communities.htm&type=5). These symbols are used in the tables. - ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png)—Included in license - $—Available as an add-on for a fee - C—Create access to the object - R—Read access to the object - U—Update access to the object - D —Delete access to the object **important:** Success plans aren’t included or amended in any OEM subscription. To learn more about success plans, go to [Salesforce Agreements and Terms](https://www.salesforce.com/company/legal/agreements/). ## Objects | Object Accessed | Force.com Platform Embedded and Force.com Platform Embedded Starter\*\*\* | Financial Services Cloud Embedded Starter | | ---------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------- | | Accounts | CRUD | CRUD | | Activities | CRUD | CRUD | | Addresses | R | R\*\* | | Assets | CRUD | CRUD | | Authorization Forms | CRUD | CRUD | | Authorization Form Consents | CRUD | CRUD | | Authorization Form Data Uses | CRUD | CRUD | | Authorization Form Texts | CRUD | CRUD | | Background Operations | R | R\*\* | | Business Brands | CRUD | CRUD | | Calendar | CRUD | CRUD | | Communication Subscriptions | CRUD | CRUD | | Communication Subscription Channel Types | CRUD | CRUD | | Communication Subscription Consents | CRUD | CRUD | | Communication Subscription Timings | CRUD | CRUD | | Contacts | CRUD | CRUD | | Contact Point Addresses | CRUD | CRUD | | Contact Point Consents | CRUD | CRUD | | Contact Point Emails | CRUD | CRUD | | Contact Point Phones | CRUD | CRUD | | Contact Point Type Consents | CRUD | CRUD | | Content | CRUD | CRUD | | Contracts\* | CRUD | CRUD | | Customers | CRUD | CRUD | | Data Use Legal Bases | CRUD | CRUD | | Data Use Purposes | CRUD | CRUD | | Documents | CRUD | CRUD | | Endorsements | CRUD | CRUD | | Events | CRUD | CRUD | | Ideas | CR | CR\*\* | | Individual | CRUD | CRUD | | Knowledge | R | R | | Locations | R | R\*\* | | Orders\* | CRUD | CRUD | | Person Account | CRUD | CRUD | | Party Consents | CRUD | CRUD | | Push Topics | CRUD | CRUD | | Sellers | CRUD | CRUD | | Skills | CRUD | CRUD | | Skill Users | CRUD | CRUD | | Social Posts | CRUD | CRUD | | Streaming Channels | CRUD | CRUD | | Tasks | CRUD | CRUD | | User External Credentials | CRUD | CRUD | | Products & Price Books | CRUD | CRUD | | ISV Custom Object | CRUD | CRUD | \* With the Orders Platform permission set license (PSL), available to OEM partners only, administrators can give the users who have Salesforce Platform user licenses access to Contracts, Products, Price Books, and Orders. Orders functionality is automatically available to all licenses except the Salesforce Platform licenses, which explicitly require the new PSL to grant access. \*\* CRUD access is contractually limited to align with Force.com Platform Embedded. \*\*\* Force.com Platform Embedded Starter is restricted to 10 identified objects. ## Financial Services Cloud-Only Objects Review access permissions for objects available only in the Financial Services Cloud Embedded Starter license. | Object Accessed | Financial Services Cloud Embedded Starter | | ----------------------------- | ----------------------------------------- | | Account-Account Relation | CRUD | | Alerts | CRUD | | Assets & Liabilities | CRUD | | Billing Statement | CRUD | | Business Milestone | CRUD | | Card | CRUD | | Contract-Contact Relation | CRUD | | Financial Account | CRUD | | Financial Account Role | CRUD | | Financial Account Transaction | CRUD | | Financial Goal | CRUD | | Financial Holding | CRUD | | Identity Document | CRUD | | Life Event | CRUD | | Person Life Event | CRUD | | Revenue | CRUD | | Securities | CRUD | ## User Features | User Feature | Force.com Platform Embedded Starter | Force.com Platform Embedded | Financial Services Cloud Embedded Starter | | ------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | | Console | $ | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Analytics (CRM Analytics) | $ | $ | $ | | Create Knowledge Articles | $ | $ | $ | | Salesforce Mobile App | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Offline | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Flows and Process Builder | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Approval Process | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Original Territory Management\* | — | — | — | | Enterprise Territory Management | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | \* Original Territory Management was retired for all customers in the Summer ’21 release. Users can’t access the original territory management feature or its underlying data. We encourage you to migrate to Enterprise Territory Management. For more information, refer to the [Original Territory Management Module Retirement](https://help.salesforce.com/s/articleView?id=000318370&type=1) article. ## User Permissions | User Permission | Force.com Platform Embedded Starter | Force.com Platform Embedded | Financial Services Cloud Embedded Starter | | -------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | | Account Teams | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Advanced Sharing | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Chatter | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Custom Profiles | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Custom Permission Sets | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Einstein Search | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Customize Reports | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Customize Dashboards | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | View Dashboards\* | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Identity | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Org Allows Custom Profiles and Page Layouts | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Org Allows Record Types | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Send Email | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Submit Workflow Approvals | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Unlimited Next Best Action Strategy Executions\*\* | $ | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | ![Check indicates included](https://developer.salesforce.com/docs/media/checkmark02.png) | | Custom Tabs Limit | 25 | 25 | 25 | | Custom Objects Limit | 10\*\*\*\* | 400\*\*\* | 400\*\*\* | \* To view a dashboard, the running user of a dashboard must be a Salesforce Platform user. Dashboards using the Salesforce Platform administrator as the running user aren’t viewable by other Salesforce Platform license types. \*\* Next Best Action requests made by users with this permission aren’t counted against the monthly entitlement. \*\*\* The limit of 400 custom objects applies to the primary solution offering. End users can create and access up to 10 more custom objects. These custom objects must be within the scope of, and used only with the partner solution. \*\*\*\* The limit of 10 objects includes what's in the primary solution offering. Contractual restriction only. ## Org-Level Allocations Solutions sold for installation in a trial org include either an Enterprise Edition or an Unlimited Edition (UE) org. This depends on the license ordered via the Channel Order App (COA). By default, partners get Enterprise Edition licenses. Unlimited Edition licenses have higher technical limits for developing robust solutions. To request an Unlimited Edition license, contact your Partner Account Manager (PAM). Learn more about org-level allocations. - [Salesforce Enterprise Edition Allocations](https://help.salesforce.com/s/articleView?id=xcloud.overview_limits_enterprise.htm&type=5) - [Salesforce Unlimited Edition Allocations](https://help.salesforce.com/s/articleView?id=xcloud.overview_limits_unlimited.htm&type=5) - [Sandbox Licenses and Storage Limits by Type](https://help.salesforce.com/s/articleView?id=platform.data_sandbox_environments.htm&type=5) Solutions sold for use in a Shared Org don’t include incremental org-level allocations such as additional sandboxes. Any per-user increases to org limits, such as API call limits, are added to the customer’s existing allowances. With solutions sold for use in a UE Shared Org, partners order Enterprise Edition products through COA catalogs. The Partner Operations team then provisions the appropriate Force.com Platform Embedded UE license on behalf of the partner. The provisioned license is subject to the partner’s service order contractual terms. UE license allocations govern per-user storage and API limits. ## Storage Limits | Additional Org Limits (Added Per User) | Force.com Platform Embedded Starter | Force.com Platform Embedded | Financial Services Cloud Embedded Starter | | -------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Data Storage | 20 MB |
  • Enterprise Edition: 20 MB
  • Unlimited Edition: 120 MB
|
  • Enterprise Edition: 20 MB
  • Unlimited Edition: 120 MB
| | File Storage | 2 GB | 2 GB | 2 GB | Each Enterprise Edition or Unlimited Edition org is allocated a minimum of 10 GB, which is the base data storage allocation for an Enterprise Edition org. For example, an Enterprise Edition org with 20 Force.com Platform Embedded users at 20 MB per user receives 400 MB plus 10 GB, or 10.4-GB total data storage. An Enterprise Edition org with 100 Force.com Platform Embedded users with 100 users receives 12 GB because 100 users multiplied by 20 MB per user is 2 GB. **note:** If your customer has an existing Enterprise Edition org, they aren't granted an additional 10 GB of data storage when they buy your solution. Their org already includes the 10 GB of data storage as part of the base allocation. For file storage, each Force.com Platform Embedded org is allocated a per-user limit multiplied by the number of users in the org plus a per-org allocation of 10 GB. For example, a Force.com Platform Embedded org with 600 users receives 1,210 GB of file storage, or 2 GB per user multiplied by 600 users plus 10 GB. For data and file storage limits for other Salesforce editions, refer to [Data and File Storage Allocations](https://help.salesforce.com/s/articleView?id=xcloud.overview_storage.htm&type=5) and [Salesforce File Storage Allocations](https://help.salesforce.com/s/articleView?id=experience.files_storage.htm&type=5). ## API Limits Limits are enforced against the aggregate of all API calls made to the org in a 24-hour period. Limits aren’t on a per-user basis. When an org exceeds a limit, all users in the org can be temporarily blocked from making calls. Calls are blocked until usage for the preceding 24 hours drops below the limit. For Enterprise Edition org API limits, including API limits with External User licenses, refer to [API Request Limits and Allocations](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm). | Salesforce Edition | API Requests (Calls) Per License Type Per 24-Hour Period | Total Requests (Calls) Per 24-Hour Period | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Enterprise Edition |
  • Force.com Platform Embedded: 1,000
  • Force.com Platform Embedded Starter: 200
  • Financial Services Cloud Embedded Starter: 1,000
| 100,000 + (number of licenses x calls per license type) + purchased API call add-ons | | Unlimited Edition |
  • Force.com Platform Embedded: 5,000
  • Force.com Platform Embedded Starter: 200
  • Financial Services Cloud Embedded Starter: 5,000
| 100,000 + (number of licenses x calls per license type) + purchased API call add-ons | ## Considerations for Government Cloud Plus Customers Keep these considerations in mind when you work with Government Cloud Plus customers. - If you sell to a Government Cloud Plus customer, additional fees and restrictions apply. For details, contact your Partner Account Manager (PAM). - Only Services that are included in the Government Cloud Plus Products list can be resold to Government Cloud Plus Customers. This list is updated from time to time and is available on the Salesforce [Salesforce Legal](https://www.salesforce.com/company/legal/) page. - To identify a Government Cloud Plus customer, check the Salesforce instance where their org resides. The instance is listed on the customer’s license record in the License Management App (LMA). After you determine the instance where their org resides, compare it with the [Government Cloud Plus instances](https://help.salesforce.com/s/articleView?id=000386297&type=1) on Salesforce Help. ## Legacy License Types These licenses aren’t available to new partners, but can be resold by existing partners who have already contracted to resell them. These licenses can be assigned to external users only. - ISV Portal—An Authenticated Website license with basic data sharing options. Manual sharing to user and participation in sharing groups aren’t permitted. Users can only log in via Salesforce Platform Sites. An ISV Portal license is best used when projected user volumes exceed 100,000. - ISV Portal with Sharing—A Customer Portal Manage Custom license with full sharing capabilities. Users can log in only via Salesforce Platform Sites. This license is best used when projected user volumes are under 100,000 and granular security access is required. **See Also** - [Experience Cloud User Licenses](https://help.salesforce.com/s/articleView?id=platform.users_license_types_communities.htm&type=5) - [Original Territory Management Retirement](https://help.salesforce.com/articleView?id=000273181&type=1&language=en_US) - [Data and File Storage Allocations](https://help.salesforce.com/articleView?id=xcloud.overview_storage.htm&type=5) - [Salesforce File Storage Allocations](https://help.salesforce.com/s/articleView?id=experience.files_storage.htm&type=5) - [API Request Limits and Allocations](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) # 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. Before you begin, create a custom flow connector using MuleSoft Connector Builder, and then export the connector as a JAR file (.jar). See [Creating Connectors](https://docs.mulesoft.com/connector-builder/creating-connectors) and [Packaging Connectors](https://docs.mulesoft.com/connector-builder/packaging-connectors) in _Mulesoft Documentation_. Follow these steps to package a custom flow connector as a managed 2GP. Include only one connector per managed package, without any other app content. ## Create a Salesforce DX Project In your local development environment, create a new Salesforce DX project by running the `sf project generate` Salesforce CLI command. ```nolang sf project generate --name my-connector-project cd my-connector-project ``` ## Add Connector Metadata Create the required directory structure and files for your custom flow connector. In `force-app/main/default`, create the `integArtifactDefs` directory. Then, in `integArtifactDefs`, create these folders and files. - **A folder for the connector**: The folder’s name must match the developerName of the connector’s JAR file (.jar) file. To find the developerName, open the JAR file that you exported from Mulesoft Connector Builder, locate the `flow-connector.ic` file within it, and then search for `developerName`. For example, if `flow-connector.ic` defines developerName as `MyConnector`, name your folder `MyConnector`. **note:** Salesforce uses the folder name as the connector’s developer name in the org only when the name matches the JAR file’s internal definition. - **The metadata file**: In the folder for the connector, create the metadata file and add the folder name to its file name. For example, if the folder for the connector is named `MyConnector`, then name the metadata file `MyConnector-meta.xml`. - **A subfolder for the JAR file**: In the folder for the connector, create a subfolder for the JAR file. The name of this subfolder must be a version number, and it must match the version defined in the connector’s JAR file. To find the version number, open the JAR file, locate the `flow-connector.ic` file within it, and then search for `version`. For example, if `flow-connector.ic` defines version as `1.0.0`, name the subfolder `1.0.0`. Add the JAR file to this subfolder. The resulting directory structure looks like this: ```nolang force-app/main/default/integArtifactDefs/ └── MyConnector/ ├── MyConnector-meta.xml └── 1.0.0/ └── my-connector.jar ``` Then, in the metadata file (`MyConnector-meta.xml`), structure the metadata like this: ```xml Connects Salesforce Flow to MySystem My Connector com.example.myconnector MyConnectorIcon true ``` **note:** Don’t add a \ element to the metadata. Salesforce derives the connector’s developer name from the folder name under `integArtifactDefs`. This table describes each field in the metadata file. | Field | Required | Description | | ----------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | displayName | Yes | The name of the connector that customers see in Flow Builder and Setup. | | description | Yes | A short description of what the connector does. | | groupId | Yes | A unique group identifier in reverse-DNS format (for example, `com.example.myconnector`). Must match the groupId value defined in your connector’s JAR (`flow-connector.ic`). | | isGlobal | Yes for packaging | Must be `true` for the connector to be packaged in a 2GP managed package and made available in subscriber orgs that install your package. Package-private connectors aren’t supported yet. See the following important note. | | iconName | No | The name of a static resource (SVG) used as the connector’s icon. See the Add an Icon section. | **important:** Setting isGlobal to `true` makes the connector globally available in every subscriber org that installs your package. Any flow, Apex class, or component in that org can reference and invoke the connector. Customers may build flows that depend on the connector’s exact surface—its operations, parameters, and response shapes. Changes you make in future package versions may render those flows inoperable. Salesforce blocks subscriber upgrades when we detect backward-incompatible changes on minor or patch versions. Even so, review every change against the customer’s perspective before shipping. The platform can’t catch every semantic change. ## Add an Icon (Optional) Give your connector a custom icon that appears in Flow Builder and Setup. 1. Create an SVG icon. 48×48 px is the size used for standard connectors. 2. Add the icon as a static resource. In `force-app/main/default/staticresources/`, create these two files with matching names. - `<IconName>.svg` — the SVG file. - `<IconName>.resource-meta.xml` — the metadata file. Set contentType to `image/svg+xml`. 3. Set iconName in your connector metadata file (`MyConnector-meta.xml`) to the static resource name (without the .svg extension). The match is case-sensitive. **note:** The static resource must exist in the org before the `IntegArtifactDef` is deployed. Otherwise, the iconName reference doesn't resolve. ## Define the Managed Package Update the project configuration file and create the package definition in your Dev Hub. Add a new package entry to the project configuration file (`sfdx-project.json`). In this example, replace the placeholder values with the values for your managed package. ```json { "packageAliases": { "MyConnectorPackage": "0Hoxx0000004ABCDE" }, "packageDirectories": [ { "path": "force-app", "package": "MyConnectorPackage", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "default": true } ] } ``` Then, create the package definition in your Dev Hub by running the `sf package create` CLI command. ```nolang sf package create \ --name "MyConnectorPackage" \ --package-type Managed \ --path force-app ``` ## Create a Package Version Before you create a package version, add the ExternalConnectivity feature to the scratch org definition file (`config/project-scratch-def.json`). ```json { "features": ["ExternalConnectivity"] } ``` For other scratch org configuration options, see [Scratch Org Features](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file_config_values.htm) in the _Salesforce DX Developer Guide_. Then, create a package version by running the `sf package version create` CLI command. **note:** Replace \ with a password that you share with subscribers via your AgentExchange listing. The password gates package installs. ```nolang sf package version create \ --package "MyConnectorPackage" \ --installation-key \ --code-coverage \ --definition-file config/project-scratch-def.json \ --wait 60 ``` When the command finishes, it returns a package version ID (starting with 04t). Use this ID to install the managed package in test orgs and to associate it with your AgentExchange listing. When you’re ready to move forward with listing your managed package on AgentExchange, make sure to verify the package’s listing readiness first. See [Check If Your Package Version Is Ready to List on AgentExchange](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_check_listing_readiness.htm) in the _ISVforce Guide_. # Package Agentforce Metadata Components Bring the power of conversational AI to your apps with Agentforce. Before you add Agentforce metadata to your package: - Review the setup steps in [Get Access to Scratch Orgs That Have Agentforce](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_scratch_orgs_agentforce.htm). - Create your agent’s actions and topics in the Agentforce Asset Library. See [Create a Custom Agent Action](https://help.salesforce.com/s/articleView?id=ai.copilot_actions_custom.htm) and [Create a Custom Topic](https://help.salesforce.com/s/articleView?id=ai.copilot_topics_add_custom.htm) for instructions. Any agent action or topic that will be packaged must be in the Agentforce Asset Library. | Feature Name | Metadata Name | Available in … | More Information | | ---------------- | ------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agent Actions | GenAiFunction | Managed 2GP and Managed 1GP | [Agent Action](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaifunction) | | Agent Topics | GenAiPlugin | Managed 2GP and Managed 1GP | [Agent Topic](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaiplugin) | | Prompt Templates | GenAiPromptTemplate | Managed 2GP and Managed 1GP | [Prompt Template](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaiprompttemplate) | | Agent Templates | BotTemplate, GenAiPlannerBundle | Managed 2GP and Managed 1GP | [Bot Template](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_bot_template), [Gen AI Planner Bundle](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm#mdc_genaiplannerbundle) | **See Also** - [Get Access to Scratch Orgs That Have Agentforce](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_scratch_orgs_agentforce.htm) - [_Salesforce Help_: Considerations for Packaging Prompt Templates](https://help.salesforce.com/s/articleView?id=ai.prompt_builder_considerations_packaging.htm) - [_Trailhead_: Quick Start: Build Your First Agent with Agentforce](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce) - [_Salesforce Help_: Agentforce: Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_intro.htm&type=5) - [_Agentforce Developer Guide_](https://developer.salesforce.com/docs/einstein/genai/guide/get-started.html) - [_Salesforce Help_: The Building Blocks of Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_building_blocks.htm&type=5) - [_Salesforce Help_: Customize Your Agents with Topics and Actions](https://help.salesforce.com/s/articleView?id=ai.copilot_topics_actions.htm&type=5) - [_Salesforce Help_: Considerations for Agents](https://help.salesforce.com/s/articleView?id=ai.copilot_considerations.htm&type=5) - [_Salesforce Help_: AI Project Success](https://help.salesforce.com/s/articleView?id=ai.generative_ai_plan_project.htm&type=5) # Package Ancestors for Second-Generation Managed Packages Second-generation managed packaging (managed 2GP) offers a flexible package versioning model that lets you break your linear versioning and abandon a package version you no longer want to build upon. We call these versioning decisions _package ancestry_. **note:** Only package versions that have been promoted to the managed-released state can be specified as a package ancestor. When package versioning is linear, the package version number (formatted as major.minor.patch.build) always increments to an increasing number. For example, looking at just the major and minor version numbers, linear versioning looks something like 1.0 → 1.1 → 1.2 → 2.0. The next package version created in this linear versioning example must be higher than 2.0. ## How Managed 2GP Package Versioning Affects Package Upgrades Before we dig into package ancestry and how managed 2GP lets you break your linear versioning, let’s clarify how package versioning impacts package upgrades. Let’s use our previous example of a package version history that looks like this, 1.0 → 1.1 → 1.2 → 2.0. A customer could install version 1.0 and upgrade through each of the subsequent package versions, or they could skip versions and upgrade from 1.0 to 2.0. As long as they upgrade from a lower package version number to a higher package version number, the package upgrade succeeds. But what if during your development process you create a package version that you don’t want to build upon? Managed 2GP lets you break free from linear versioning and select a different package version to build upon. Say your team creates version 1.0, then 1.1, then 1.2 and oops! 1.2 made a mess of 1.1. Not a problem. When you create a package version, you specify which package version is the ancestor. So you abandon 1.2, and make 1.1 the ancestor of 1.3. And this process can be repeated. For example, the illustration shows how to abandon 1.5, and build 1.6 off 1.4. ![Visualization of a versioning tree with three branches](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_ancestry_nodes.png) This more complex and tree-like versioning has the added benefit of making it possible for two or more development teams to do parallel package development. ## With Great Power Comes Great Responsibility The flexibility to break from linear versioning is powerful. But remember that if abandoned versions like 1.2 and 1.5 are installed in customer orgs, those customers no longer have an upgrade path. Packages can only upgrade along the ancestry line. For example, you can upgrade from version 1.1 to 1.7, but not from version 1.5 to 1.7. ## Patch Versions and Package Ancestry You can’t specify a [patch version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_patch_version.htm), such as 1.0.2, as a direct ancestor of a non-patch version. Instead, use the [keyword](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_keywords.htm) `“ancestorVersion" : "HIGHEST”`, or specify a non-patch version as the ancestor. Installed patch versions inherit the upgrade path of the non-patch version with the same major and minor number. For example, patch version 1.0.3 has the same upgrade path as 1.0.0. - **[Understanding Package Upgrades with Ancestry](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-upgrades.md)** Review how package ancestry impacts which package version upgrades are allowed. - **[View Package Ancestry](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-view-ancestors.md)** Use Salesforce CLI commands to quickly confirm your package’s ancestor, or to create a visualization of the package ancestry tree. **See Also** - [Understanding Package Upgrades with Ancestry](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_upgrades.htm) - [View Package Ancestry](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_view_ancestors.htm) - [Namespace-Based Visibility for Apex Classes in Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_namespace_visibility.htm) # Package and Package Version Object Fields The License Management App (LMA) includes a Package custom object and a Package Version custom object. These objects display details about each 1GP or 2GP package and package version you’ve listed on AgentExchange. To view details about a package record, from the LMA, select the **Packages** tab, and then select the package name. You can view package versions in the Package Version related list. **note:** The LMA creates the package records, which contain critical information for tracking your licenses and packages. Treat these fields as read-only and ensure that your object permissions protect package records. | Package Custom Object Fields | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Developer Name | The name of the org that owns the package. For 1GP, the org name is the packaging org. For 2GP, it’s the Dev Hub org. | | Developer Org ID | The 18-character ID of the org that owns the package. For 1GP, the org ID is the packaging org ID. For 2GP, it’s the Dev Hub org ID. | | Last License Refresh | The date when the License Refresh tool was last run. | | Latest Version | The most recent package version you’ve released. | | Lead Manager | The owner of the lead records that the LMA creates when a customer installs your package. | | Next Available Refresh | The date when the License Refresh tool can be run again. | | Owner | The LMA owns all package records. | | Package ID | The 18-character ID that identifies the package. This ID starts with 033. | | Package Name | The name you specified when you created the package. | | Package Version Object Fields | Description | | ----------------------------- | ------------------------------------------------------------------- | | Package | The package name and links to the package record’s detail page. | | Package Version Name | The name you specified when you created the package version. | | Release Date | The date you created this package version. | | Version Number | The version number in major.minor.patch format. For example, 3.1.0. | | Version ID | The 18-character ID of this package version. | # Package and Test Your First-Generation Managed Package Learn how to package, upload, and install a beta version of your first-generation managed package as part an iterative development approach. After your beta is up and running, learn how to test, fix, extend, and uninstall the package. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). - **[Install a Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-install.md)** During the development and testing cycle, you might need to periodically install and uninstall packages before you install the next beta. Follow these steps to install a package. - **[Install First-Generation Managed Packages Using Metadata API](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-api-introduction.md)** You can install, upgrade, and uninstall managed packages using the Metadata API, instead of the user interface. Automating these repeated tasks can help you can work more efficiently and speed up application development. - **[Component Availability After Deployment](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-component-availability.md)** Many components have an **Is Deployed** attribute that controls whether they’re available for end users. After installation, all components are immediately available if they were available in the developer's organization. - **[Install Notifications for Unauthorized Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-install-notification.md)** When you distribute a managed package that ISV Partner Program hasn’t authorized, we notify customers during the installation process. The notification is removed after the package is approved. - **[Resolve Apex Test Failures](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/resolving-test-failures.md)** Package installs or upgrades may fail for not passing Apex test coverage. However, some of these failures can be ignored. For example, a developer might write an Apex test that makes assumptions about a subscriber's data. - **[Run Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script.md)** App developers can specify an Apex script to run automatically after a subscriber installs or upgrades a managed package. This script makes it possible to customize the package install or upgrade, based on details of the subscriber’s organization. For instance, you can use the script to populate custom settings, create sample data, send an email to the installer, notify an external system, or kick off a batch operation to populate a new field across a large set of data. For simplicity, you can only specify one post install script. It must be an Apex class that is a member of the package. - **[Run Apex on Package Uninstall](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script.md)** App developers can specify an Apex script to run automatically after a subscriber uninstalls a managed package. This script makes it possible to perform cleanup and notification tasks based on details of the subscriber’s organization. For simplicity, you can only specify one uninstall script. It must be an Apex class that is a member of the package. - **[Uninstall a First-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-uninstall.md)** You can uninstall a first-generation managed package from an org using the Setup UI. When you uninstall a first-generation managed package, all components in the package, including any deprecated components that were previously associated with the package, are deleted from the org. # Package Connected Apps in Second-Generation Managed Packaging Add a connected app to a second-generation managed package. ## Before You Begin **note:** Consider using External Client Apps instead. External Client Apps are the new and improved generation of connected apps. For details, see [Package External Client Apps In Second-Generation Managed Packages](https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_external_client_app.htm&release=250). If the namespace for the connected app becomes corrupted, create an external client app to replace the connected app. External client apps can be packaged in [first-generation managed packages](https://help.salesforce.com/s/articleView?id=xcloud.package_external_client_app_with_1gp.htm) or [second-generation managed packages](https://help.salesforce.com/s/articleView?id=xcloud.configure_packageable_external_client_apps.htm). Prerequisites: [Create a connected app](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_connected_app.htm). 1. Create a first-generation managed package (1GP) and add the connected app. It’s fine if the connected app is the only component in the package. Use the same namespace as the 2GP package for the 1GP package. Take note of the version number of the connected app; you’ll use this number later. 2. From your packaging org, upload the 1GP package to create a package version. 3. Promote the 1GP version to the released state. Promoting the 1GP version allows the connected app to be included in a second-generation managed package. You don’t need to install the 1GP version into an org. 4. Navigate to the source for your connected app, or pull the source from the org where the connected app is being developed. 5. Create a source `.xml` file in your 2GP directory and reference the connected app you want to include. See the _Sample Source File_ section. 6. Create a second-generation managed package and add in the source code for the connected app. Add the source code manually. You can’t use `sf project retrieve start` or the `retrieve()` Metadata API call to add the source code. ## Sample Source File ```nolang db_0110_ns4__A_Connected_App 1.0 ``` The developerName is the combination of your namespace (db_0110_ns4) and the name of your connected app (A_Connected_App). The version specified in the source file is the version number of the connected app. Use decimal formatting when specifying the version number. The version number must match the version number of the connected app before it was added to the 1GP managed package. **note:** When you add a connected app to a 1GP package, and upload the package, the version number of the connected app is auto incremented. For example, when version 4.0 of a connected app is added to a 1GP package, the package version increments the version number of the connected app from 4.0 to 5.0. When creating the source file for your 2GP package, specify the version number of the connected app before it was uploaded into a 1GP package, in this case, 4.0. # 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. ## Enable Data Cloud for Scratch Orgs To create scratch orgs or package Data Cloud components, you must have Dev Hub enabled in your Partner Business Org. Then, you can request that Data Cloud for Scratch Orgs be enabled by logging a case with [Salesforce Partner Support](https://partners.salesforce.com). Data Cloud for Scratch Orgs is only available to scratch orgs associated with the Dev Hub in your Partner Business Org. ## Create Dedicated Data Cloud Packages When creating a managed package with Data Cloud metadata, you must isolate the Data Cloud metadata from the other Salesforce metadata by creating separate packages that contain only Data Cloud metadata. Then create package dependencies between your dedicated Data Cloud package and any related packages. ## Add Data Cloud Metadata to a Data Kit When packaging Data Cloud metadata, you must add the metadata to a data kit, and then add the data kit to the managed package. Data kits streamline the package creation and installation process. For more details, see [Packages and Data Kits](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/packages-data-kits.html) in the _Data Cloud Developer Guide_. ## Data Cloud One Companion Connected Orgs Packages can’t be installed on orgs that are connected to Data Cloud as Data Cloud One companion orgs. When Data Cloud customers install a managed package containing Data Cloud metadata, they must install the package in their Data Cloud home org. For customers using Data Cloud One, any package installed into data spaces shared with a companion org are automatically installed into the companion org. Companion orgs automatically receive package updates when the package in the home org is upgraded. These package-related actions can’t be initiated in companion connected orgs, and must instead be initiated in the Data Cloud One home org. - Installing a managed package - Uninstalling a managed package - Deleting package metadata - Receiving a package push upgrade **See Also** - [_Data Cloud Developer Guide_: Get Started with Data Cloud Development](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/get-started.html) - [_Data Cloud Developer Guide_: Workflow for Data Cloud Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/data-cloud-2gp-workflow.html) - [_Data Cloud Developer Guide_: Metadata Components for Data Cloud Cheat Sheet](https://developer.salesforce.com/docs/platform/data-cloud-dev/guide/component-cheatsheet.html) - [_Salesforce Help_: Connect Salesforce CRM Orgs to Data Cloud](https://help.salesforce.com/s/articleView?id=data.c360_a_connect_salesforce_orgs.htm&type=5) # Package Dependencies in First-Generation Managed Packages Package dependencies are created when a component references another component, permission, or preference that is required for the component to be valid. | Availability | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AgentExchange packages and Visualforce are available in: **Group**, **Professional**, **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | Apex available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | User Permissions Needed | | | --------------------------------- | --------------------------- | | To upload packages: | Upload AppExchange Packages | | To view Visualforce dependencies: | Developer Mode | **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). Packages, Apex classes, Apex triggers, Visualforce components, and Visualforce pages can have dependencies on components within an org. These dependencies are recorded on the Show Dependencies page. Dependencies are important for packaging because any dependency in a component of a package is considered a dependency of the package as a whole. **note:** An installer’s organization must meet all dependency requirements listed on the Show Dependencies page or else the installation fails. For example, the installer's org must have divisions enabled to install a package that references divisions. Dependencies are important for Apex classes or triggers. Any component on which a class or trigger depends must be included with the class or trigger when the code is deployed or packaged. In addition to dependencies, the operational scope is also displayed on the Show Dependencies page. The operational scope is a table that lists any data manipulation language (DML) operations (such as `insert` or `merge`) that Apex executes on a specified object. The operational scope can be used when installing an application to determine the full extent of the application’s database operations. To view the dependencies and operational scope for a package, Apex class, Apex trigger, or Visualforce page: 1. Navigate to the appropriate component from Setup. - For packages, enter `Packages` in the Quick Find box, then select **Packages**. - For Apex classes, enter `Apex Classes` in the Quick Find box, then select **Apex Classes**. - For Apex triggers, from the management settings for the appropriate object, go to Triggers. - For Visualforce pages, enter `Visualforce Pages` in the Quick Find box, then select **Visualforce Pages**. 2. Select the name of the component. 3. Click **View Dependencies** for a package, or **Show Dependencies** for all other components, to see a list of objects that depend upon the selected component. If a list of dependent objects displays, click **Fields** to access the field-level detail of the operational scope. The field-level detail includes information, such as whether Apex updates a field. For more information, see [Field Operational Scope](https://help.salesforce.com/articleView?id=field_operational_scope.htm). Packages, Apex code, and Visualforce pages can depend many components, including but not limited to: - Custom field definitions - Validation formulas - Reports - Record types - Apex - Visualforce pages and components For example, if a Visualforce page includes a reference to a multicurrency field, such as `{!contract.ISO_code}`, that Visualforce page has a dependency on multicurrency. If a package contains this Visualforce page, it also has a dependency on multicurrency. Any organization that wants to install this package must have multicurrency enabled. # Package IDs When you work with packages using the CLI, the package IDs refer either to a unique package or a unique package version. The relationship of package version to package is one-to-many. | ID Example | Description | Used Where | | --------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 033xx00000007oi | Metadata Package ID | Generated when you create a package. A single package can have one or more associated package version IDs. The package ID remains the same, whether it has a corresponding beta or released package version. | | 04tA000000081MX | Metadata Package Version ID | Generated when you create a package version. | # Package IDs and Aliases for Second-Generation Managed Packages During the package lifecycle, packages and package versions are identified by an ID or package alias. When you create a second-generation managed package or package version, Salesforce CLI creates a package alias based on the package name, and stores that name in the packageAliases section of the `sfdx-project.json` file. When you run CLI commands or write scripts to automate packaging workflows, it’s often easier to reference the package alias, instead of the package ID or package version ID. Package aliases are stored in the `sfdx-project.json` file as name-value pairs, in which the name is the alias and the value is the ID. You can modify package aliases for existing packages and package versions in the project file. At the command line, you also see IDs for things like package members (a component in a package) and requests (like a `sf package version create` request). **note:** As a shortcut, the documentation sometimes refers to an ID by its three-character prefix. For example, a package version ID always starts with `04t`. Here are the most commonly used IDs. | ID Example | Short ID Name | Description | | ------------------ | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 033J0000dAb27uxVRE | Subscriber Package ID | Use this ID when contacting Salesforce for packaging or security review support. To locate this ID for your package, run `sf package list --verbose` against the Dev Hub that owns the package. | | 04t6A0000004eytQAA | Subscriber Package Version ID | Use this ID to install a package version. Returned by `sf package version create`. | | 0Hoxx00000000CqCAI | Package ID | Use this ID on the command line to create a package version. Or enter it into the `sfdx-project.json` file and use the directory name. Generated by `sf package create`. | | 08cxx00000000BEAAY | Version Creation Request ID | Use this ID to view the status and monitor progress for a specific request to create a package version such as `sf package version create report` | # Package Installation Key for Second-Generation Managed Packages To ensure the security of the metadata in your second-generation managed package, you must specify an installation key when creating a package version. Package creators provide the key to authorized subscribers so they can install the package. Package installers provide the key during installation, whether installing the package from the CLI or from a browser. An installation key is the first step during installation. The key ensures that no package information, such as the name or components, is disclosed until the correct installation key is supplied. To set the installation key, add the `--installation-key` parameter to the command when you create the package version. This command creates a package and protects it with the installation key. ```nolang sf package version create --package "Expense Manager" --installation-key "JSB7s8vXU93fI" ``` Supply the installation key when you install the package version in the target org. ```nolang sf package install --package "Expense Manager" --installation-key "JSB7s8vXU93fI” ``` ## Change the Installation Key for an Existing Package Version You can change the installation key for an existing package version with the `sf package version update` command. ```nolang sf package version update --package "Expense Manager@1.2.0-4" --installation-key “HIF83kS8kS7C” ``` ## Create a Package Version Without an Installation Key If you don’t require security measures to protect your package metadata, you can create a package version without an installation key. ```nolang sf package version create --package "Expense Manager" --installation-key-bypass ``` ## Check Whether a Package Version Requires an Installation Key To determine whether a package version requires an installation key, use the `sf package version list` CLI command. # Package Usage Logs Analyze adoption and user behavior, then make informed feature development decisions based on data from package usage logs. AgentExchange App Analytics tracks UI, API-based, Lightning-based, and Apex operations, and it logs each CRUD operation on components and custom objects in packages. Events from sandbox and trial orgs are tracked in package usage logs. Events from scratch orgs aren’t tracked. **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). - **[How to Read App Analytics Package Usage Log Data](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-read-logs/app-analytics-read-logs-intro.md)** App Analytics package usage logs contain data about how subscribers interact with your managed package. Your managed package contains packaged components, and each package usage log line describes an interaction that a user has with one of your packaged components. To understand that interaction, analyze each log line—or record—and focus on: what packaged component was accessed, who interacted with that packaged component, and how that packaged component interaction occurred. Finally, analyze the specific interaction data. - **[Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-custom-object-logs.md)** Make informed development decisions based on package usage log data. Analyze adoption, user behavior, company information, and Lightning app and page usage data. Package usage logs list activity during a 24-hour period, between 12:00 AM and 11:59 PM UTC. # Package Usage Logs Schema Make informed development decisions based on package usage log data. Analyze adoption, user behavior, company information, and Lightning app and page usage data. Package usage logs list activity during a 24-hour period, between 12:00 AM and 11:59 PM UTC. | Field | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | api_type | The type of API request. Examples:
  • `BULK_API`
  • `E`: SOAP Enterprise
  • `P`: SOAP Partner
  • `REST`
| | api_version | The version of the API that’s used. Example: `45.0`. | | app_name | The name of the Lightning application the user accessed. Examples:
  • `one:one`
  • `FieldServiceApp`
  • `Chatter`
| | bulk_batch_id | The batch ID for the Bulk API job. | | bulk_job_id | The ID for the Bulk API job. | | bulk_operation | The operation for the Bulk API job. Examples:
  • `delete`
  • `hardDelete`
  • `insert`
  • `query`
  • `queryAll`
  • `update`
  • `upsert`
| | class_name | The name of the Apex class. Examples:
  • `Help_HomeController`
  • `ROAppController_v2`
  • `FSL`
| | cloned_from_organization_id | The ID of the org from which this subscriber org was cloned. Applies to sandbox orgs only. Example: `00Dxx0000000000` | | custom_entity | The developer name of the component or custom object. | | custom_entity_type | The type of component or custom object that the user viewed or manipulated. Examples:
  • `AnalyticsDashboard`
  • `AnalyticsLens`
  • `AnalyticsRecipe`
  • `ApexClass`
  • `ApexTrigger`
  • `CustomInteractionFailure`
  • `CustomInteractionLabel`
  • `CustomObject`
  • `ExternalObject`
  • `LightningComponent`
  • `LightningPage`
  • `VisualforcePage`
| | entry_point | The entry point of the executed Apex event.
  • `GeneralCloner.cloneAndInsertRecords`
  • `VF- /apex/CloneUser`
| | event | The name or ID of the platform event. Examples:
  • `/event/011xx0000005akx`
  • `SomeCustomEvent`
| | event_count | The number of platform events consumed by the subscriber. Example: `2`. | | event_subscriber | The ID of the platform event subscriber. Example: `01qxx0000004Coy`. | | http_method | The type of HTTP request method. Example: `GET`. | | http_status_code | The HTTP response status code. Example: `404`. | | interaction_id_token | A hashed token representing the interaction ID provided when the custom interaction was logged. In compliance with privacy regulations, Salesforce can’t store an actual user interaction ID. | | line_number | The line number in the Apex file. | | login_key | The hashed string that ties together all events in a given user’s login session. The session starts with a login event and ends with either a logout event or the session expiring. All log lines with the same login key occurred during the same user login session. | | log_record_type | Type of log record. Examples:
  • `AnalyticsAssetView`
  • `AnalyticsAssetRun`
  • `API`
  • `ApexExecution`
  • `ApexRestApi`
  • `ApexSoap`
  • `ApexUnexpectedException`
  • `BulkApiV1`
  • `BulkApiV2`
  • `CronJob`
  • `CustomInteraction`
  • `LightningInteraction`
  • `LightningPageView`
  • `PlatformEventConsumer`
  • `QueuedExec`
  • `RestApi`
  • `UnassociatedCRUD`
  • `URI`
  • `VFRemoting`
  • `VisualforceRequest`
A `log_record_type` value of `UnassociatedCRUD` is assigned when a create, read, update, or delete (CRUD) event occurs on a custom object that isn’t associated with a log record type that App Analytics captures or that is associated with unknown log records. | | managed_package_namespace | Namespace of the package. | | method_name | The name of the Apex method. Examples:
  • `getUserAccessLevelBean`
  • `getCurrentDocumentsRates`
  • `getAdditionalHelpTemplate`
| | num_fields | The number of fields accessed by the user in this transaction. | | num_soql_queries | The number of SOQL queries completed during the executed Apex event. | | operation_count | The definition of `operation_count` depends on the `operation_type` performed.
  • When `operation_type` is `INSERT`, `READ`,`UPDATE`, or `DELETE`, `operation_count` is the number of records associated with the `custom_entity` affected by the operation in this transaction.
  • When `operation_type` is `SOQL_QUERY`, `operation_count` is the number of SOQL queries associated with the `custom_entity` performed in this transaction.
  • When `operation_type` is `SOSL_QUERY`, `operation_count` is the number of SOSL queries associated with the `custom_entity` performed in this transaction.
| | operation_type | The operation performed on the component or custom object. Examples:
  • `INSERT`
  • `READ`
  • `UPDATE`
  • `DELETE`
  • `SOSL_QUERY`
  • `SOQL_QUERY`
| | organization_country_code | The ISO-3166 two-character country code corresponding to the subscriber org’s address at the time of sign-up. Examples:
  • `US`
  • `CA`
  • `FR`
| | organization_edition | The name of the Salesforce edition the subscriber org is using. Examples:
  • `Developer Edition`
  • `Enterprise Edition`
  • `Unlimited Edition`
| | organization_id | The 15-character ID of the subscriber org. | | organization_instance | The name of the subscriber org’s instance. Examples:
  • `AP2`
  • `EU7`
  • `NA44`
| | organization_language_locale | The 2–5 character code that represents the language and locale ISO-639 code of the subscriber org. This code controls the language for the labels displayed in an application. Examples:
  • `de-DE`
  • `en-US`
  • `fr-CA`
| | organization_name | The name of the subscriber org. Example: `Acme, Inc.` | | organization_status | The paid status of the subscriber org. Examples:
  • `Active`
  • `Demo`
  • `Free`
  • `Trial`
| | organization_time_zone | The default time zone of the subscriber org. Examples:
  • `America/New York`
  • `America/Los Angeles`
  • `Europe/Paris`
| | organization_type | The subscriber org environment type. Examples:
  • `Production`
  • `Sandbox`
| | package_id | The ID of the package. | | package_version_id | The ID of the package version. | | page_app_name | The internal name of the Lightning application that the user accessed from the App Launcher. Examples:
  • `LightningSales`
  • `Chatter`
| | page_context | The context of the Lightning page where the event occurred. Example: `clients:cardContainer`. | | page_entity_type | The Lightning entity type of the event. Examples:
  • `Contact`
  • `Task`
| | page_url | The relative URL of the top-level Lightning Experience or Salesforce mobile app page that the user accessed. The page can contain one or more Lightning components. Multiple record IDs can be associated with page_url. Example: `/sObject/0064100000JXITSASS/view` | | parent_ui_element | The parent scope of the Lightning page element where the event occurred. Example: `ChatterFeed`. | | prevpage_url | The relative URL of the previous Lightning Experience or Salesforce mobile app page that the user opened. Example: `/sObject/0064100000` | | quiddity | The type of outer execution associated with the executed Apex event. Examples:
  • `A`: `QueryLocator` Batch Apex
  • `B`: Bulk API and Bulk API 2.0
  • `BA`: Batch Apex
  • `C`: Scheduled Apex
  • `E`: Inbound Email Service
  • `F`: Future
  • `H`: Apex REST
  • `I`: Invocable Action
  • `K`: Quick Action
  • `L`: Lightning
  • `M`: Remote Action
  • `Q`: Queuable
  • `R`: Synchronous Uncategorized
  • `S`: Serial Batch Apex
  • `TA`: Tests Async
  • `TD`: Tests Deployment
  • `TS`: Tests Synchronous
  • `V`: Visualforce
  • `W`: SOAP Webservices
  • `X`: Execute Anonymous
| | referrer_uri | The referring URI from the HTTP request. URIs are redacted in these ways.
  • Query strings are removed.
  • User IDs display as hashed tokens.
  • Subscriber-created URIs, such as VisualForce pages, are removed.
| | related_list | A section of a record or other detail page that lists items related to that record. Examples:
  • Open Activities
  • Stage History
| | request_id | The ID of the HTTP request made to the server by the browser. If multiple log lines have the same request ID, they all occurred as part of the same user interaction. | | request_size | The size of the callout request body in bytes. | | request_status | The status of the HTTP request for the page or action that accesses a component or custom object in a package. Examples:
  • `A` = Auth Error
  • `F` = Failure
  • `N` = 404 error
  • `R` = Redirect
  • `S` = Success
  • `U` = Undefined
| | response_size | The size of the callout response in bytes. | | rows_processed | The number of rows that were processed in the request. | | session_key | The HTTP session ID for the HTTP request to access a component or custom object in a package. The session ID is hashed. | | stack_trace | The stack trace associated with the Apex exception. | | target_ui_element | The Lightning target page element where the event occurred. Examples:
  • `label body truncate`
  • `tabitem-link`
| | timestamp_derived | The access time of a component or custom object in a package in ISO8601-compatible format (YYYY-MM-DDTHH:MM:SS.sssZ). Example: `2018-07-27T11:32:59.555Z`. | | ui_event_sequence_num | An auto-incremented sequence number of the current Lightning event since the session started. | | ui_event_source | The user action on the Lightning record or records. This value indicates whether the user’s action was on a single record or multiple records. For example, `read` indicates that one record was read, such as on a record detail page. In contrast, `reads` indicates that multiple records were read, such as in a list view. Examples:
  • `click`
  • `create`
  • `delete`
  • `hover`
  • `read`
  • `update`
| | ui_event_type | The type of Lightning event. Examples:
  • `crud`
  • `system`
  • `user`
| | url | The redacted URL of the request to access a component or custom object in a package. URLs are redacted in these ways.
  • Query strings are removed.
  • User IDs display as hashed tokens.
  • Subscriber-created URIs, such as VisualForce pages, are removed.
For Lightning-based URLs, only `/aura` is displayed. For Visualforce-based URLs that aren’t pages owned by the managed package, either `/apex` or `/apexrest` is displayed. | | user_agent | The browser and operating system of the device used to make the request. Examples:
  • Mozilla/5.0 (iPhone; CPU iPhone // 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/69.0.3497.105 Mobile/15E148 Safari/605.1
  • Mozilla/5.0 (Linux; Android 8.0.0; SM-G960F Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.84 Mobile Safari/537.36
| | user_country_code | The default ISO-3166 two-character country code of the user. Examples:
  • `CA`
  • `FR`
  • `US`
| | user_id_token | The hashed token representing the ID of the user who accessed the package. The ID persists, even if a user’s details change. The token also persists across any packages that the user interacts with. The user ID token starts with the prefix 005-. In compliance with privacy regulations, our systems can’t access the actual user ID. Likewise, the hashed token can’t be linked to the user ID. | | user_time_zone | The default time zone of the user. Example: `America/New_York`. | | user_type | The user license category of the user accessing Salesforce services through the UI or API. Examples:
  • `Guest`
  • `Partner`
  • `Standard`
| # Package Usage Summaries Package usage summaries provide high-level metrics by calendar month. Discover how many users access your package and which operations they perform. **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). AgentExchange App Analytics tracks UI, API-based, Lightning-based, and Apex operations and logs each CRUD operation on components and custom objects in packages. Events from sandbox, scratch, and trial orgs aren’t tracked in package usage summaries. Partners and subscribers can access package usage data. Usage summaries become available at the beginning of the subsequent month. For example, you can get the usage summary for May at the beginning of June. - ISV Partners can request monthly usage summaries using the AppAnalyticsQueryRequest in SOAP API from the license management org that owns the package. - Subscribers can download usage summaries from Setup for any package that they installed that passed security review. - **[Package Usage Summary Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-custom-object-summaries.md)** Use the package usage summary to discover how many users access your package and which operations they perform. # Package Usage Summary Schema Use the package usage summary to discover how many users access your package and which operations they perform. Package usage summaries contain aggregate data derived from related [package usage logs](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-custom-object-logs.md). ISV partners have access to package usage summaries by default, and they can activate access to package usage logs and subscriber snapshots. Subscribers only have access to package usage summaries. | Field | Description | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | custom_entity | The developer name of the component or custom object. | | custom_entity_type | The type of component or custom object that the user viewed or manipulated. Examples:
  • `AnalyticsDashboard`
  • `AnalyticsLens`
  • `ApexClass`
  • `ApexTrigger`
  • `CustomInteractionLabel`
  • `CustomInteractionFailure`
  • `CustomObject`
  • `ExternalObject`
  • `LightningPage`
  • `LightningComponent`
  • `VisualforcePage`
| | managed_package_namespace | Namespace of the package. | | month | The month that this usage summary applies to in YYYY-MM format. Example: `2019-03`. | | num_creates | The number of new records created from the package. | | num_deletes | The number of deleted records associated with the package. | | num_events | The number of log records associated with a `custom_entity`. | | num_reads | The aggregate number of records associated with the `custom_entity` that was read. The definition of `num_reads` changed with the Spring ’23 release. Some data from February 2023 and all data dated January 2023 and earlier used this previous `num_reads` definition: the aggregate number of records associated with the package that were read, plus the number of `SOSL` and `SOQL` queries performed on the entity. | | num_updates | The number of records associated with the package that were updated. | | num_views | The number of times the component or page has been viewed. | | organization_edition | The name of the Salesforce edition that the subscriber org is using. Examples:
  • `Developer Edition`
  • `Enterprise Edition`
  • `Unlimited Edition`
| | organization_id | The 15-character ID of the subscriber org. | | organization_name | The name of the subscriber org. Example: `Acme, Inc.` | | organization_status | The paid status of the subscriber org. Examples:
  • `Active`
  • `Demo`
  • `Free`
  • `Trial`
| | package_id | The ID of the package. | | user_id_token | The hashed token representing the ID of the user who accessed the package. The token persists over time, even if a user’s details change. The token also persists across any packages that the user interacts with. The user ID token starts with the prefix 005-. In compliance with privacy regulations, our systems can’t access the actual user ID. Likewise, the hashed token can’t be linked to the user ID. | | user_type | The user license category of the user accessing Salesforce services through the UI or API. Examples:
  • `Guest`
  • `Partner`
  • `Standard`
| **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-custom-object-logs.md) # Package Versions in First-Generation Managed Packages A package version is a number that identifies the set of components uploaded in a package. The version number has the format _majorNumber.minorNumber.patchNumber_ (for example, 2.1.3). **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). Version numbers depend on the package release type, which identifies the way packages are distributed. There are two kinds: **Major Release** A major release denotes a Managed - Released package. During these releases, the major and minor numbers of a package version increase to a chosen value. **Patch Release** A patch release is only for patch versions of a package. During these releases, the patch number of a package version increments. The following table shows a sequence of version numbers for a series of uploads: | Upload Sequence | Type | Version Number | Notes | | --------------- | ------------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | First upload | Managed - Beta | 1.0 | The first Managed - Beta upload. | | Second upload | Managed - Released | 1.0 | A Managed - Released upload. The version number doesn’t change. | | Third upload | Managed - Released | 1.1 | Note the change of the minor release number for this Managed - Released upload. If you’re uploading a new patch version, you can't change the patch number. | | Fourth upload | Managed - Beta | 2.0 | The first Managed - Beta upload for version number 2.0. Note the major version number update. | | Fifth upload | Managed - Released | 2.0 | A Managed - Released upload. The version number doesn’t change. | When an existing subscriber installs a new package version, there’s still only one instance of each component in the package, but the components can emulate older versions. For example, a subscriber can use a managed package that contains an Apex class. If the publisher decides to deprecate a method in the Apex class and release a new package version, the subscriber still sees only one instance of the Apex class after installing the new version. However, this Apex class can still emulate the previous version for any code that references the deprecated method in the older version. Package developers can use conditional logic in Apex classes and triggers to exhibit different behavior for different versions. Conditional logic lets the package developer support existing behavior in classes and triggers in previous package versions while evolving the code. When you’re developing client applications using the API, you can specify the version of each package that you use in your integrations. # Packaging Checklist Ready to deploy your packaging metadata and start creating a package? Take a few minutes to verify that you covered the items in this checklist, and you’re good to go. 1. Link the namespace of each package you want to work with to the Dev Hub org. 2. Copy the metadata of the package from your version control system to a local project. 3. Update the config files, if needed. For example, to work with managed packages, sfdx-project.json must include the namespace. ```nolang "namespace": "acme_example", ``` 4. (Optional) Create an alias for each org you want to work with. If you haven’t yet created an alias for each org, consider doing that now. Using aliases is an easy way to switch between orgs when you’re working in the CLI. 5. Authenticate the Dev Hub org. 6. Create a scratch org. A scratch org is different than a sandbox org. You specify the org shape using project-scratch.json. To create a scratch org and set it as the `defaultusername` org, run this command from the project directory. ```nolang sf org create scratch --definition-file config/project-scratch-def.json ``` 7. Push source to the scratch org. 8. Update source in the scratch org as needed. 9. Pull the source from the scratch org if you used declarative tools to make changes there. With these steps complete, you’re ready to deploy your package metadata to the packaging org. # Partner Payouts Overview Payouts refer to the net revenue that partners receive from settled customer payments. Stripe, on behalf of Salesforce, consolidates settled revenue for all customer orders into a single, daily payout. That means Stripe rounds up all your customer payments and deposits the net revenue into your account. If on a given day, you haven’t received payments or a submitted payment hasn’t settled yet, you won’t receive a payout. When customer payments are processed and settled by Stripe, Stripe initiates the payout to your selected bank account on the same day. You can track the status of your payouts in the GTM app, from the Payouts tab, when Stripe initiates a payout. The GTM app also provides information about the related invoices for a given payout event. ## Example Salesforce fees are deducted from the total payout, and are visible at the order and payout levels in your GTM app. This diagram explains what you can expect from the basic flow. Keep in mind that these numbers are for example purposes only and don’t reflect actual prices or percentages. ![Revenue breakdown for Partner Marketplace payouts.](https://developer.salesforce.com/docs/media/partner_marketplace_revenue.png) Let’s say that you and your customer negotiate a price of $100. In this scenario, the customer invoice lists $100 as the product price and the revenue engine adds $10 in tax. Stripe receives the entire payment amount, and then divides the payment into the net partner revenue and Salesforce payment. The net partner revenue goes to the partner, as explained in the Revenue Breakdown section of your invoice. ## View Your Revenue Breakdown To see a detailed view of customer payment information, find it in the Revenue Breakdown section of your invoice. 1. From the Invoices tab, select an invoice number. 2. Select the **Details** tab and find the Revenue Breakdown section. We use the diagram above to illustrate an example breakdown. 1. Subtotal: The total negotiated value of the products or services in the offer, excluding any taxes, for the billing period of the invoice. Example: $100 2. Customer Sales Tax: The sales tax amount charged to the customer, calculated according to the customer's location and regulations. Example: $10 3. Invoice Total: The final amount the customer is billed and pays, including the subtotal plus the applicable customer sales tax. Example: $110 4. Salesforce Revenue Share: The revenue share retained by Salesforce, calculated as a set Percentage of Net Revenue (PNR). Example: $15 5. Partner Revenue Share: The remaining portion of the subtotal, minus the Salesforce revenue share. Example: $85 6. Revenue Share Sales Tax: The sales tax the partner owes for the Salesforce revenue share. Example:$1 7. Total Received by Salesforce: The total funds Stripe transfers to Salesforce following Customer payment, which is made up of the Salesforce revenue share, the customer sales tax, and the revenue share sales tax. Example: $26 # Pass the AgentExchange Security Review [Effective Date: August 9, 2023] At Salesforce, nothing is more important than the trust of our customers. Trust requires security. Learn how to prepare for and pass the AgentExchange security review. To distribute managed packages, Salesforce Platform API solutions, or Marketing Cloud Engagement API solutions on AgentExchange, they must pass our security review. **note:** The description of the AgentExchange Security Review in this section and the links herein is current as of the listed effective date. SFDC may update or modify the AgentExchange Security Review from time to time in its sole discretion, with or without notice. **important:** Partner Applications, which includes managed packages, Salesforce Platform API solutions, Marketing Cloud Engagement API solutions, and other solutions referred to herein, are Non-SFDC Applications as defined in Salesforce’s Main Services Agreement (available at [https://www.salesforce.com/company/legal/agreements](https://www.salesforce.com/company/legal/agreements) or successor URL). Notwithstanding any security review of a Partner Application, Salesforce makes no guarantees regarding the quality or security of any Partner Application and Customers are responsible for evaluating the quality, security, and functionality of Partner Applications. # Patch Versions for Second-Generation Managed Packages Patch versions are a way to fix small issues with your second-generation managed package without introducing major feature changes. Customers who are using an older version of your package can install a patch and not be forced to upgrade to a new major package version. Package versions follow a major.minor.patch.build number format. Any package version number that contains a non-zero patch number is a patch version. For example, 1.1.2.5 is a patch version, but 1.1.0.4 isn’t. Patch versions are intended for small changes like a fixing a bug. You can’t: - Add package components. - Delete existing package components. - Change the API and dynamic Apex access controls. - Deprecate any Apex code. - Add new Apex class relationships, such as extends. - Add Apex access modifiers, such as virtual or global. - Add features, settings, package dependencies, or web services. - Change a component from protected to global. - Change the visibility of CustomSettings or CustomMetadataType from protected to public. When creating a patch version, you must specify the package ancestor. The major and minor numbers of the patch version and the package ancestor must match. And the specified package ancestor must be managed-released. You can specify another patch version as the package ancestor of a patch version. But you can’t specify a patch version as a direct ancestor of a non-patch version. Instead, use the [keyword](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_keywords.htm) `“ancestorVersion" : "HIGHEST”`, or specify a non-patch version as the ancestor. Installed patch versions inherit the upgrade path of the non-patch version with the same major and minor number. For example, patch version 1.0.3 has the same upgrade path as 1.0.0. See [Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-ancestors.md) for more information about how to specify a package ancestor. When you create a patch version, the patch automatically inherits the features and settings defined in the package ancestor’s scratch org definition file. To create a patch, follow the same steps as you do when you create a package version, and increment the patch number. **note:** To enable patch versioning, log a case with [Salesforce Partner Support](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pkg2-feature-enablement.md) and request that patch versioning be enabled in the org where you created the namespace for this package. Patch versioning is available to only to packages that have passed AgentExchange security review. **See Also** - [Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_ancestors.htm) - [Second-Generation Managed Packaging Keywords](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_config_keywords.htm) # Permission Set Groups You can organize permission sets into groups and include them in first and second-generation managed packages. Permission set groups can be updated when you upgrade the package. Keep these considerations in mind when you organize permission sets into groups to include in your managed packages: **important:** You can't include object permissions for standard objects in managed packages. During package installation, all object permissions for standard objects are ignored, and aren't installed in the org. Also: - You can’t add permission sets constrained by a permission set license to managed or unmanaged packages. - You can only package permissions for metadata that’s included in your package. - You can add or remove permission sets in permission set groups as part of a package upgrade. Subscribers can also modify the permission set groups by muting permissions or adding or removing local permissions sets. Subscribers can't remove included permission sets from the permission set groups in the managed package. **See Also** - [_Salesforce Help_: Create a Permission Set Group](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups_create.htm&type=5) - [_Salesforce Help_: Permission Set Groups Considerations](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups_considerations.htm&type=5) # Permission Set Groups You can organize permission sets into groups and include them in first and second-generation managed packages. Permission set groups can be updated when you upgrade the package. Keep these considerations in mind when you organize permission sets into groups to include in your managed packages: **important:** You can't include object permissions for standard objects in managed packages. During package installation, all object permissions for standard objects are ignored, and aren't installed in the org. Also: - You can’t add permission sets constrained by a permission set license to managed or unmanaged packages. - You can only package permissions for metadata that’s included in your package. - You can add or remove permission sets in permission set groups as part of a package upgrade. Subscribers can also modify the permission set groups by muting permissions or adding or removing local permissions sets. Subscribers can't remove included permission sets from the permission set groups in the managed package. **See Also** - [_Salesforce Help_: Create a Permission Set Group](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups_create.htm&type=5) - [_Salesforce Help_: Permission Set Group Considerations](https://help.salesforce.com/s/articleView?id=platform.perm_set_groups_considerations.htm&type=5) # 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. **important:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Availability | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | Permission sets are available in: **Contact Manager**, **Professional**, **Group**, **Enterprise**, **Performance**, **Unlimited**, **Developer**, and **Database.com** Editions | | Behavior | Permission Sets | Profile Settings | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What permissions and settings are included? | Assigned custom apps, custom object permissions, external object permissions, custom field permissions, custom metadata types permissions, custom permissions, custom settings permissions, custom tab visibility settings, Apex class access, Visualforce page access, external data source access, and record types. Although permission sets include standard tab visibility settings, these settings can’t be packaged as permission set components. If a permission set includes an assigned custom app, it’s possible that a subscriber can delete the app. In that case, when the package is later upgraded, the assigned custom app is removed from the permission set. | Assigned custom apps, assigned connected apps, tab settings, page layout assignments, record type assignments, custom field permissions, custom metadata type permissions, custom object permissions, custom permissions, custom settings permissions, external object permissions, Apex class access, Visualforce page access, and external data source access | | Can they be upgraded in managed packages? | Yes. | Profile settings are applied to existing profiles in the subscriber’s org on install or upgrade. Only permissions related to new components created as part of the install or upgrade are applied. | | Can subscribers edit them? | No. | Yes. | | Can you clone or create them? | Yes. However, if a subscriber clones a permission set or creates one that’s based on a packaged permission set, it isn’t updated in subsequent upgrades. Only the permission sets included in a package are upgraded. | Yes. Subscribers can clone any profile that includes permissions and settings related to packaged components. | | Do they include standard object permissions? | No. Also, you can’t include object permissions for a custom object in a master-detail relationship where the master is a standard object. | No. | | Do they include user permissions? | No. | No. | | Are they included in the installation wizard? | No. Subscribers must assign permission sets after installation. | Yes. Profile settings are applied to existing profiles in the subscriber’s org on install or upgrade. Only permissions related to new components created as part of the install or upgrade are applied. Affected components (listed with the developerName) can include new Fields (CustomField), Objects (CustomObject), Tabs (CustomTab), Apps (CustomApplication), Apex classes (ApexClass), Apex pages (ApexPage), Layouts (Layout), Record types (RecordType), Custom permissions (CustomPermission), Custom settings (CustomSetting), and Custom metadata types (CustomMetadata). | | What are the user license requirements? | A permission set is only installed if the subscriber org has at least one user license that matches the permission set. For example, permission sets with the Salesforce Platform user license aren’t installed in an org that has no Salesforce Platform user licenses. If a subscriber later acquires a license, the subscriber must reinstall the package to get the permission sets associated with the newly acquired license. Permission sets with no user license are always installed. If you assign a permission set that doesn’t include a user license, the user’s existing license must allow its enabled settings and permissions. Otherwise, the assignment fails. | None. In a subscriber org, the installation overrides the profile settings, not their user licenses. | | How are they assigned to users? | Subscribers must assign packaged permission sets after installing the package. | Profile settings are applied to existing profiles. | | Can permission sets in an extension package grant access to objects installed in a base package? | A permission set in the extension package can't modify access permissions for either the parent objects in the base package or the associated child objects in the extension package. | Same behavior as for permission sets. | ## Best Practices - If users need access to apps, standard tabs, page layouts, and record types, don't use permission sets as the sole permission-granting model for your app. - Create packaged permission sets that grant access to the custom components in a package, but not standard Salesforce components. # 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. **important:** Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations. | Availability | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | Permission sets are available in: **Contact Manager**, **Professional**, **Group**, **Enterprise**, **Performance**, **Unlimited**, **Developer**, and **Database.com** Editions | | Behavior | Permission Sets | Profile Settings | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What permissions and settings are included? | Assigned custom apps, custom object permissions, external object permissions, custom field permissions, custom metadata types permissions, custom permissions, custom settings permissions, custom tab visibility settings, Apex class access, Visualforce page access, external data source access, and record types. Although permission sets include standard tab visibility settings, these settings can’t be packaged as permission set components. If a permission set includes an assigned custom app, it’s possible that a subscriber can delete the app. In that case, when the package is later upgraded, the assigned custom app is removed from the permission set. | Assigned custom apps, assigned connected apps, tab settings, page layout assignments, record type assignments, custom field permissions, custom metadata type permissions, custom object permissions, custom permissions, custom settings permissions, external object permissions, Apex class access, Visualforce page access, and external data source access | | Can they be upgraded in managed packages? | Yes. | Profile settings are applied to existing profiles in the subscriber’s org on install or upgrade. Only permissions related to new components created as part of the install or upgrade are applied. | | Can subscribers edit them? | No. | Yes. | | Can you clone or create them? | Yes. However, if a subscriber clones a permission set or creates one that’s based on a packaged permission set, it isn’t updated in subsequent upgrades. Only the permission sets included in a package are upgraded. | Yes. Subscribers can clone any profile that includes permissions and settings related to packaged components. | | Do they include standard object permissions? | No. Also, you can’t include object permissions for a custom object in a master-detail relationship where the master is a standard object. | No. | | Do they include user permissions? | No. | No. | | Are they included in the installation wizard? | No. Subscribers must assign permission sets after installation. | Yes. Profile settings are applied to existing profiles in the subscriber’s org on install or upgrade. Only permissions related to new components created as part of the install or upgrade are applied. Affected components (listed with the developerName) can include new Fields (CustomField), Objects (CustomObject), Tabs (CustomTab), Apps (CustomApplication), Apex classes (ApexClass), Apex pages (ApexPage), Layouts (Layout), Record types (RecordType), Custom permissions (CustomPermission), Custom settings (CustomSetting), and Custom metadata types (CustomMetadata). | | What are the user license requirements? | A permission set is only installed if the subscriber org has at least one user license that matches the permission set. For example, permission sets with the Salesforce Platform user license aren’t installed in an org that has no Salesforce Platform user licenses. If a subscriber later acquires a license, the subscriber must reinstall the package to get the permission sets associated with the newly acquired license. Permission sets with no user license are always installed. If you assign a permission set that doesn’t include a user license, the user’s existing license must allow its enabled settings and permissions. Otherwise, the assignment fails. | None. In a subscriber org, the installation overrides the profile settings, not their user licenses. | | How are they assigned to users? | Subscribers must assign packaged permission sets after installing the package. | Profile settings are applied to existing profiles. | | Can permission sets in an extension package grant access to objects installed in a base package? | A permission set in the extension package can't modify access permissions for either the parent objects in the base package or the associated child objects in the extension package. | Same behavior as for permission sets. | ## Best Practices - If users need access to apps, standard tabs, page layouts, and record types, don't use permission sets as the sole permission-granting model for your app. - Create packaged permission sets that grant access to the custom components in a package, but not standard Salesforce components. - **[Permission Set Groups](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pd-packaging-permission-set-groups.md)** You can organize permission sets into groups and include them in first and second-generation managed packages. Permission set groups can be updated when you upgrade the package. - **[Custom Profile Settings](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/packaging-creating-custom-profile.md)** Create profiles to define how users access objects and data, and what they can do within your app. For example, profiles specify custom object permissions and the tab visibility for your app. When installing or upgrading your app, admins can associate your custom profiles with existing non-standard profiles. Permissions in your custom profile that are related to new components created as part of the install or upgrade are added to the existing profile. The security settings associated with standard objects and existing custom objects in an installer’s organization are unaffected. - **[How We Handle Profile Settings in Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/second-generation/sfdx-dev-dev2gp-profiles.md)** During package version creation for unlocked or second-generation managed packages, the build system inspects the contents of all profiles in the DX project directory, not just the directory specified in the path, and preserves only the profile settings that are directly related to the metadata in the package. The profile itself, and any profile settings unrelated to the package’s metadata are discarded from the package. # Plan the Release of First-Generation Managed Packages Releasing a managed package is similar to releasing any other program in software development. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). After you release a package by publishing it on AgentExchange, anyone can install it. So, plan your release carefully. Review the states defined in the following table to familiarize yourself with the release process. Salesforce automatically applies the appropriate state to your package and components depending on the upload settings you choose and where it is in the release process. | State | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Managed - Beta | The package or component was created in the current Salesforce org and is managed, but it isn’t released because of one of these reasons: it hasn’t been uploaded, or it has been uploaded with the Managed - Beta option selected. This option prevents it from being published, publicly available on AgentExchange. The developer can still edit any component but the installer isn’t able to depending on which components were packaged. Don’t install a Managed - Beta package over a Managed - Released package. If you do, the package is no longer upgradeable and your only option is to uninstall and reinstall it. | | Managed - Released | The package or component was created in the current Salesforce org and is managed. It’s also uploaded with the Managed - Released option selected, indicating that it can be published on AgentExchange and is publicly available. After you’ve moved a package to this state, some properties of the components can’t be editable. This type of release is considered a major release. | | Patch | If you must provide a minor upgrade to a managed package, consider creating a patch instead of a new major release. A patch enables a developer to change the functionality of existing components in a managed package. Subscribers experience no visible changes to the package. This type of release is considered a patch release. | | Managed - Installed | The package or component was installed from another Salesforce org but is managed. | | Unmanaged (Legacy) | The package hasn’t been converted into a managed package. | A developer can refine the functionality in a managed package over time, uploading and releasing new versions as the requirements evolve. Updates can involve redesigning some of the components in the managed package. Developers can delete some, but not all, types of components in a Managed - Released package when upgrading it. # Plan Your Package Migration Are you ready to move your subscribers to 2GP? The speed and ease of your package migration depend on a few key factors. Before you start, think about your current situation: - How many 1GP packages do you own? - How many subscribers are using them? - Are your subscribers all using the same major and minor version of your package, or are you supporting multiple package versions? - Do your packages depend on other packages? Be sure to review the [Considerations for Package Migrations](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migrations_known_limitations.htm) and the prerequisites listed in [Before you Begin Package Migrations](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_prerequistes.htm). ## Supporting Multiple Versions of a Package? If you currently have subscribers using multiple versions of your package, think through how to upgrade your subscribers using lower versions of your 1GP package. When you migrate a package, the 1GP package version installed on a subscriber org must match the major.minor.patch version of the converted 2GP package you migrate to that org. When you run the Salesforce CLI package conversion command, the latest major.minor managed-released package version is converted. If you’re able to get your subscribers all updated to the same package version, you only need to convert that one package version (for example version 6.0), and then you could bulk migrate all subscribers to version 6.0 of the converted 2GP package. Package migration is significantly easier if you aren’t having to convert and migrate several versions of the same package. But if upgrading all subscribers to the same package version isn’t possible for you, make sure to create an upgrade path for subscribers using lower package versions. One way to do that is to convert each 1GP package version that you promote to the managed-released state. | **Package Version** | Package Built After 6/15/25? | Can package version be converted to 2GP? | | ------------------- | ---------------------------- | ---------------------------------------------------------- | | 1.0 | No | No | | 1.1 | No | No | | 1.2 | No | No | | 1.3 | Yes | Yes. If it’s converted before creating 1.4, otherwise, no. | | 1.4 | Yes | Yes. If it’s converted before creating 1.5, otherwise, no. | | 1.5 | Yes | Yes. If it’s converted before creating 1.6, otherwise, no. | | 1.6 | Yes | Yes. If it’s converted before creating 1.7, otherwise, no. | If you convert package version 1.3 before you create version 1.4, then subscribers using versions 1.0-1.2 can be upgraded to 1.3 and migrated to 2GP. Even if you aren’t ready to migrate subscribers, simply having the converted 1.3 package version gives subscribers using version 1.3 and lower an upgrade path in the future. Without the converted version 1.3, subscribers must to upgrade to version 1.4 or whatever converted versions are available. If your subscribers are using a 1GP major.minor package version that hasn’t been converted, you must first upgrade them to a 1GP package version that has been converted. ## Migrating Packages with Dependencies If the package you plan to convert depends on other packages, the order in which you migrate your package might be significant. As you may already know, a 1GP package can't depend on a 2GP package. ![Graphic illustration of package dependencies](https://developer.salesforce.com/media/pkg1_dev/migration_dependencies_graphic.png) This limitation impacts the order in which you migrate a package with dependencies. Because 1GP packages can’t depend on 2GP packages, when you migrate a 1GP package with dependencies, we recommend migrating the packages in a particular order starting with the leaf package. ![Graphic displays the best order for migrating packages with dependencies](https://developer.salesforce.com/media/pkg1_dev/migration_dependency_flow.png) In this example of a three-level package dependency, you migrate the leaf package, followed by the extension package, and end with migrating the base package. It’s possible to migrate the base package first, but this creates added complexity as 1GP extension packages can't depend on a base 2GP package. Therefore, our recommendation is to start migrating with leaf packages and then make your way down to the base package. # Prepare to Distribute Your Second-Generation Managed Package Before you release a version of your second-generation managed package, ensure that you understand the code coverage requirements, release logistics, and how to publish your app on AgentExchange. - **[Code Coverage for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-code-coverage.md)** Before you can release and distribute a second-generation managed package version on AgentExchange, the Apex code must meet a minimum 75% code coverage requirement. And every Apex Trigger in a package needs test coverage. - **[Package Installation Key for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-installkey.md)** To ensure the security of the metadata in your second-generation managed package, you must specify an installation key when creating a package version. Package creators provide the key to authorized subscribers so they can install the package. Package installers provide the key during installation, whether installing the package from the CLI or from a browser. An installation key is the first step during installation. The key ensures that no package information, such as the name or components, is disclosed until the correct installation key is supplied. - **[Release a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-pkg-ver-promote.md)** Each new second-generation managed package version is marked as beta when created. As you develop your package, you may create several package versions before you create a version that is ready to be released and distributed. Only released package versions can be listed on AgentExchange and installed in customer orgs. - **[Share Release Notes and Post-Install Instructions for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-release-note-urls.md)** Share details with your subscribers about what’s new and changed in a released second-generation managed package. - **[Publishing Your App on AgentExchange](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-publish-appexchange.md)** If you’ve published a first-generation managed package, you’ll notice the process for publishing a second-generation managed package (managed 2GP) is different. After you link your Dev Hub org to the AgentExchange partner console, all your released managed 2GP package versions are visible in the partner console. - **[Recommend a Specific Package Version to Your Subscribers](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-recommended-version.md)** You can choose to recommend that your subscribers upgrade to a specific, released version of your package. # Prepare to Install an AgentExchange Package Before you install an AgentExchange package, verify that it's compatible with your Salesforce implementation by checking the technical requirements. Optionally, determine if the package supports automatic upgrades. ## Verify Technical Requirements Every package has technical requirements, such as the Salesforce editions that it supports. To verify that a package is compatible with your implementation, go to the More Details tab on its AgentExchange listing. Then, review the details in the Compatibility and App Details sections. ## Determine if the Package Supports Upgrades If you prefer a solution that receives automatic upgrades, choose a managed package. Unmanaged packages aren’t upgradeable. # Prepare to List Your Solution on AgentExchange Create a company profile and share contact information for your AgentExchange business. Connect your partner orgs and solutions to the Partner Console. Set up licenses for the managed packages that you distribute on AgentExchange. # Prepare Your Test Drive Org Prepare your test drive org by installing your solution and configuring the evaluation user. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To install your solution and customize your test drive org:|Customize Application| Secure your test drive org by: - Removing any sensitive data from your test drive org. - Ensuring that each password you specify for the admin and evaluation test accounts is unique. - Setting up multi-factor authentication for admin account logins. - Deleting the test drive org if you disable test drives on a listing. When your potential customers click **Test Drive** on your AgentExchange listing, they’re automatically logged in to your listing’s test drive org. To facilitate this login process from behind the scenes, set up an evaluation user. ## Steps 1. Log in to your test drive org. 2. Install your solution. 3. In Setup → Users, edit the **Eval Test** user. 1. Confirm that the **Test Drive Eval Profile** is assigned. 2. For email address, use your email with `+evaluser` appended. Example: `johndoe+evaluser@example.com`. 3. Wait for an email confirmation. 4. Reset the Eval Test user password. 4. Complete any additional configuration that the evaluation user requires. For example, enable read-only access to your solution’s custom Apex classes or Lightning components. 5. Double-check that the evaluation user has only the access they need, including read-only access to your test drive org and minimal access to objects. ## Next Steps Next, connect your fully configured test drive org to your AgentExchange listing. # Prerequisites and Considerations There are a few prerequisites and considerations to review before setting up the Go-To-Market (GTM) app. ## Prerequisites - Be an existing ISVForce Salesforce partner who is enrolled in the AgentExchange Partner Program. - Have a seat-based managed package that is associated with your Salesforce org. - Set up USD as a currency in your Partner Business org. Private offers contain currency fields, which must be in USD. - Execute a Partner Application Distribution Agreement (PADA), or update your existing distribution agreement, with Salesforce that incorporates the [AgentExchange Go-To-Market App Terms](https://www.salesforce.com/company/legal/partner-agreements/). ## Considerations - US Customers: The GTM app is available to US-based customers only. - New Customers: The GTM app can only be used to transact with customers that are new to the partner. You can’t sell new products to existing customers. - Seat-based: Only seat-based managed packages, native to the Salesforce Platform, are supported in the GTM app. Layered and consumption-based pricing options aren’t supported. - Permission set licenses requirements: Permission set licenses (PSL) are only supported in second-generation packaging (2GP) managed packages. - Contracts: 12-month contracts are required. To prevent issues, make sure that the customer has an active Salesforce contract for more than 12 months, or intends to renew the contract for the underlying required Salesforce product. - Payment terms: - The default and supported payment term is NET30. - Invoices are sent to the customer one day before the order start date. - Payment for the entire value of the order is due upfront. - ACH debit is the supported payment method. - Renewals, cancelations, refunds: Customer orders don't automatically renew. Offer and order cancellations, and partner-initiated refunds to customers, aren't supported currently. # Project Configuration File for a Second-Generation Managed Package The project configuration file is a blueprint for your project. The settings in the file create an outline of your managed 2GP package and determine the package attributes and package contents. Here are some of the parameters you can specify in the project configuration file. For additional parameters, see [Advanced Project Configuration Parameters for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-adv-config-file.md). | Name | Details | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ancestorId | **Required?** It depends on whether you’ve already promoted a package version of this package. If yes, you must specify either the ancestorId or ancestorVersion. If no, this parameter isn’t required. **Default if Not Specified:** None. The ID of the immediate parent in the package ancestry tree of the package version you’re creating. The `ancestorId` requires the 04t of the package version, or an alias to the package version. When specifying ancestors, you can use either `ancestorId` or `ancestorVersion`. For more information, see [Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-ancestors.md). | | ancestorVersion | **Required?** It depends on whether you’ve already promoted a package version of this package. If yes, you must specify either the ancestorId or ancestorVersion. If no, this parameter isn’t required. **Default if Not Specified:** None. The version number of the immediate parent in the package ancestry tree of the package version you’re creating. Specify the ancestor version using the format of major.minor.patch.build. When specifying ancestors, you can use either `ancestorId` or `ancestorVersion`. For more information, see [Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-ancestors.md). | | default | **Required?** Yes, if you’ve specified more than one package directory **Default if Not Specified:** true Indicates the default package directory. When metadata is retrieved from a development org (scratch org or source-tracked sandbox) using `sf project retrieve`, it's placed in the default package directory. There can be only one package directory in which the default is set to true. | | definitionFile | **Required?** No **Default if Not Specified:** None. A reference to an external `.json` file used to specify the features and org settings required for the metadata of your package, such as the scratch org definition. | | namespace | **Required?** Yes **Default if Not Specified:** None. A 1–15 character alphanumeric identifier that distinguishes your package and its contents from packages of other developers. | | package | **Required?** Yes **Default if Not Specified:** None. The package name is specified in the project json file. | | packageAliases | **Required?** No **Default if Not Specified:** Salesforce CLI updates this file with the aliases when you create a package or package version. You can also manually update this section for existing packages or package versions. You can use the alias instead of the cryptic package ID when running CLI `sf package` commands. | | path | **Required?** Yes **Default if Not Specified:** None. Specify the location that contains the package metadata in the --path attribute of `sf package create` Salesforce CLI command. | | seedMetadata | **Required?** No **Default if Not Specified:** None. Specify the path to your seedMetadata directory. Seed metadata is available to standard value sets only. If your package depends on standard value sets, you can specify a seed metadata directory that contains the value sets. | | versionDescription | **Required?** No **Default if Not Specified:** None | | versionName | **Required?** No **Default if Not Specified:** If not specified, the CLI uses versionNumber as the version name. | | versionNumber | **Required?** Yes **Default if Not Specified:** None. The versionNumber field sets the version number that is assigned the next time you create a 2GP version. Version numbers are formatted as MAJOR.MINOR.PATCH.BUILD. For example, 1.2.1.8. To avoid creating multiple package versions with the same MAJOR.MINOR.PATCH.BUILD number, you must increment the versionNumber before creating a new package version. To automatically increment the build number to the next available build for the package, use the keyword NEXT (1.2.1.NEXT). Alternatively, when you create a new package version, you can set the version number using the `--versionNumber` flag in the CLI. For more details, see [Guidance for Version Numbering](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_version_guidance.htm). | Example ancestorId: ```nolang "ancestorId": "Expenser Logic@0.1.0-1" ``` Example ancestorVersion: ```nolang "ancestorVersion": "0.1.0.1" ``` Example definitionFile: ```nolang "definitionFile": "config/project-scratch-def.json", ``` Example seedMetadata: ```nolang "packageDirectories": [ { "seedMetadata": { "path": "my-unpackaged-seed-directory" } }, ] ``` When you specify a parameter using Salesforce CLI, it overrides the value listed in the project definition file. The Salesforce DX project definition file is a JSON file is located in the root directory of your project. Use the `sf project generate` CLI command to generate a project file that you can build upon. Here’s how the parameters in `packageDirectories` appear. ```javascript { "namespace": "exp-mgr", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "61.0", "packageDirectories": [ { "path": "util", "default": true, "package": "Expense Manager - Util", "versionName": "Summer ‘24", "versionDescription": "Welcome to Summer 2024 Release of Expense Manager Util Package", "versionNumber": "4.7.0.NEXT", "definitionFile": "config/scratch-org-def.json" }, { "path": "exp-core", "default": false, "package": "Expense Manager", "versionName": "v 3.2", "versionDescription": "Summer 2024 Release", "versionNumber": "3.2.0.NEXT", "ancestorVersion": "3.0.0.7", "definitionFile": "config/scratch-org-def.json", "dependencies": [ { "package": "Expense Manager - Util", "versionNumber": "4.7.0.LATEST" }, { "package" : "External Apex Library - 1.0.0.4" } ] } ], "packageAliases": { "Expense Manager - Util": "0HoB00000004CFpKAM", "External Apex Library@1.0.0.4": "04tB0000000IB1EIAW", "Expense Manager": "0HoB00000004CFuKAM"} } ``` ## What If I Don’t Want My Salesforce DX Project Automatically Updated? In some circumstances, you don’t want to have automatic updates to the `sfdx-project.json` file. When you require more control, use these environment variables to suppress automatic updates to the project file. | For This Command | Set This Environment Variable to True | | ------------------------- | ---------------------------------------------------------- | | sf package create | SFDX_PROJECT_AUTOUPDATE_DISABLE_FOR_PACKAGE_CREATE | | sf package version create | SFDX_PROJECT_AUTOUPDATE_DISABLE_FOR_PACKAGE_VERSION_CREATE | **See Also** - [Advanced Project Configuration Parameters for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_adv_config_file.htm) # 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. **See Also** - [Hide Custom Objects and Custom Permissions in Your Subscribers' Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/fma_hide_custom_objects_permissions.htm) # 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. **See Also** - [Hide Custom Objects and Custom Permissions in Your Subscribers' Orgs](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg2_dev/fma_hide_custom_objects_permissions.htm) # 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. To protect your intellectual property, consider the following: - Only publish package components that are your intellectual property and that you have the rights to share. - After your components are available on AgentExchange, you can’t recall them from anyone who has installed them. - The information in the components that you package and publish might be visible to customers. Use caution when adding your code to a formula, Visualforce page, or other component that you can’t hide in your app. - The code contained in an Apex class, trigger, Lightning, or Visualforce component that’s part of a managed package is obfuscated and can’t be viewed in an installing org. The only exceptions are methods declared as global. You can view global method signatures in an installing org. In addition, License Management Org users with the View and Debug Managed Apex permission can view their packages’ obfuscated Apex classes when logged in to subscriber orgs via the Subscriber Support Console. - If a custom setting is contained in a managed package, and the Visibility is specified as Protected, the custom setting isn’t contained in the list of components for the package on the subscriber’s org. All data for the custom setting is hidden from the subscriber. # Provide Free Trials of Your AgentExchange Solution Increase customer conversion by offering free trials of your AgentExchange solution. Explore trial options, and determine the best type for your solution. **note:** This feature is available to eligible partners. For more information on the Partner Program, including eligibility requirements, visit [https://partners.salesforce.com](https://partners.salesforce.com). # Provide Free Trials on Your AgentExchange Listing Using a Trialforce Template To enable free trials on your AgentExchange listing, add one of the Trialforce templates that you connected to the AgentExchange Partner Console. Optionally, enable lead collection to receive leads when customers start trials using the Trialforce template. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**, and then select a listing. 4. Click **Grow Your Business**. 5. For Free Trials, click the search field and select a connected Trialforce template. 6. Optionally, collect leads when customers start trials. 1. For Leads, specify the ID of the org where Web-to-Lead is enabled. 2. Select the checkbox for free trials. 7. Click **Done**. # Provide Test Drives on Your AgentExchange Listing To make test drives available on your AgentExchange listing, go to the AgentExchange Partner Console and connect your test drive org to the listing. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**, and then select a listing. 4. Click **Grow Your Business**. 5. In Test Drives, toggle on **Offer test drives**. 6. Provide your test drive org ID and your evaluation user’s username and password (1).![The Partner Console Grow Your Business step with a highlight on Test Drives Org ID, Username, and Password](https://developer.salesforce.com/docs/media/appexchange_test_drive.png) ## Next Steps View your live listing on AgentExchange, and make sure that your test drive is functioning the way you expect it to. # Proxy User Has Deactivated Message in the LMA If you’re editing a license and see a “proxy user has deactivated” message, it's possible that the subscriber org is locked, deleted, or disabled. If you attempt to contact the subscriber and they aren't responsive, consider deleting the license record. # Publish Extensions to Managed Packages An extension is any package, component, or set of components that adds to the functionality of a managed package. An extension requires that the base managed package is installed in the org. For example, if you have built a recruiting app, an extension to this app can include a component for performing background checks on candidates. | Availability | | --------------------------------------------------------------------------------------------------------------------- | | Available in: **Group**, **Professional**, **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | | User Permissions Needed | | | ----------------------- | --------------------------- | | To create packages: | Create AppExchange Packages | | To upload packages: | Upload AppExchange Packages | **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). The community of developers, users, and visionaries building and publishing apps on AgentExchange is part of what makes Salesforce Platform such a rich development platform. Use this community to build extensions to other apps and encourage them to build extensions to your apps. When working with both first-generation (1GP) and second-generation (2GP) managed packages, only certain combinations of packages are supported. See: [Which Package Types Can Your Package Depend On?](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_dependency_overview.htm) To publish extensions to a managed package: 1. Install the base package in the Salesforce org that you plan to use to upload the extension. 2. Build your extension components. **note:** To build an extension, install the base package and include a dependency to that base package in your package. The extension attribute automatically becomes active. 3. Create a package and add your extension components. Salesforce automatically includes some related components. 4. Upload the new package that contains the extension components. 5. Proceed with the publishing process as usual. For information on creating a test drive or registering and publishing your app, go to [Salesforce Partner Community](https://partners.salesforce.com). **note:** Packages can’t be upgraded to Managed - Beta if they’re used within the same org as an extension. # Publish Upgrades to First-Generation Managed Packages As a publisher, first ensure that your app is upgradeable by converting it to a managed package. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). | User Permissions Needed | | | -------------------------------- | --------------------------- | | To configure namespace settings: | Customize Application | | To create packages: | Create AppExchange Packages | | To upload packages: | Upload AppExchange Packages | Any changes you make to the components in a managed package are automatically included in subsequent uploads of that package, with one exception. When you upgrade a package, changes to the API access are ignored even if the developer specified them. These changes are ignored so that the administrator installing the upgrade has full control. Installers must carefully examine the changes in package access in each upgrade during installation and note all acceptable changes. Then, because those changes are ignored, the admin must manually apply any acceptable changes after installing an upgrade. 1. From Setup, enter `Package Manager` in the Quick Find box, then select **Package Manager**. 2. Select the package from the list of available packages. 3. View the list of package components. Changes you have made to components in this package are automatically included in this list. If the changes reference additional components, those components are automatically included as well. To add new components, click **Add** to add them to the package manually. 4. Click **Upload** and upload it as usual. After you upload a new version of your Managed - Released package, you can click **Deprecate** so installers can’t install an older version. Deprecation prevents new installations of older versions without affecting existing installations. You can’t deprecate the most recent version of a managed package upload. 5. When you receive an email with the link to the upload on AgentExchange, notify your installed users that the new version is ready. To distribute this information, use the list of installed users from the License Management Application (LMA). The License Management Application (LMA) automatically stores the version number that your installers have in their organizations. - **[Plan the Release of First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/determine-managed-package-state.md)** Releasing a managed package is similar to releasing any other program in software development. - **[Remove Components from First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-managed-component-deletion.md)** Remove metadata components such as Apex classes that you no longer want in your first-generation managed packages. - **[Delete Components from First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/viewing-deleted-components.md)** After you've uploaded a Managed - Released first-generation managed package, you may find that a component needs to be deleted from your packaging org. - **[Modifying Custom Fields after a Package Is Released](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/modifying-custom-fields.md)** The following changes are allowed to custom fields in a package, after it’s released. - **[Manage Versions of First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/managing-uploads.md)** After you upload a package to AgentExchange, you can still manage it from the Package Manager page. - **[View Unused Components in a Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/unused-package-components.md)** View components no longer being used in the current version of a package. - **[Push Package Upgrades to Subscribers](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-intro.md)** A push upgrade is a method of automatically upgrading your customers to a newer version of your package. This feature can be used to ensure that all your customers are on the same or latest version of your package. You can push an upgrade to any number of organizations that have installed your managed package. # Publish Your Consultant Listing When you’re ready, click **Publish**. Your listing goes live immediately. **important:** Consultant listings have no approval gate. You can publish with zero competencies, zero reviews, zero certifications, and minimal content. Technically, nothing stops you, but publishing in this state creates a poor first impression. Leverage your Partner Program Dashboard ahead of publishing your listing to verify what data appears for competencies and certifications. ## Publish-Readiness Checklist Before you click Publish, confirm you’ve completed: - Add a professional full description of at least 200 words, focused on customer outcomes. - Enter a functioning, action-oriented Learn More URL. - Turn on lead collection or a verified landing page at your Learn More URL. - Add at least one media item, like a screenshot or video. - Include at least one Customer Resource asset, like case studies, customer testimonials, or whitepapers. - Define languages. - Register project work in the Partner Community so your competencies populate. - Update team certifications in the Partner Community. Finally, fill in key fields in your Company Info profile, such as Company Name, Logo, Description, Website URL, Year Founded, and Number of Employees. These values also appear on the listing page. # Publishing Your App on AgentExchange If you’ve published a first-generation managed package, you’ll notice the process for publishing a second-generation managed package (managed 2GP) is different. After you link your Dev Hub org to the AgentExchange partner console, all your released managed 2GP package versions are visible in the partner console. To list an app on AgentExchange, it must pass the AgentExchange security review. For more information, see [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm) in the ISVforce Guide. ## Link Dev Hub to the AgentExchange Partner Console - Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). - Select the **Publishing** tab - Click **Technologies** - Click **Org** - Click **Connect Technology**, and **Org** - Click **Connect Org** and **Allow**, and enter the login credentials for your Dev Hub org. ## Register Your Managed 2GP Package - From the Solutions tab, locate the package version you want to register, and click **Register Package**. Registering a package links the package to your [license management app](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_manage_licenses.htm). - Enter the login credentials for the Dev Hub org associated with the package in the modal window. - Set the default license behavior for the package, including trial length, and number of seats included with the license, and click **Save**. Packages that share a namespace can be associated with the same License Management Org (LMO), or you can associate the packages with different LMOs. **See Also** - [_ISVforce Guide_: Create or Edit Your AgentExchange Listing](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_publish_listings.htm) - [_ISVforce Guide_: Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm) # Push a Package Upgrade for Second-Generation Managed Packages Push upgrades enable you to upgrade second-generation managed packages installed in subscriber orgs, without asking customers to install the upgrade themselves. You can choose which orgs receive a push upgrade, what version the package is upgraded to, and when you want the upgrade to occur. Push upgrades are helpful if you need to push a change for a hot bug fix. Use Salesforce CLI or SOAP API to initiate the push upgrade, track the status of each job, and review error messages if any push upgrades fail. The push upgrade feature is only available to first- and second-generation managed packages that have passed the AgentExchange security review. The CLI push upgrade commands are available to second-generation managed packages and unlocked packages. To enable push upgrades for your managed package, log a case with [Salesforce Partner Support](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pkg2-feature-enablement.md). For details on the security review process, see [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm) in the _ISVforce Guide_. | **Package Type** | **Push Upgrade using CLI?** | **Push Upgrade using API?** | **Push Upgrade using UI?** | | ---------------- | --------------------------- | --------------------------- | -------------------------- | | 2GP | Yes | Yes | No | | 1GP | No | Yes | Yes | | Unlocked | Yes | Yes | No | ## Push Upgrade Considerations for Second-Generation Managed Packages - You can push upgrades to packages that have passed AgentExchange security review only. - The same manageability rules for package version upgrades are applicable to push upgrades. - When a push upgrade is installed, the Apex in package is compiled. - Push upgrades can be used even if the package version requires a password. - **[Schedule a Push Upgrade Using CLI](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-cli.md)** Use Salesforce CLI commands to schedule, abort, or view details about your push upgrade requests. Push upgrades let you upgrade second-generation managed packages installed in subscriber orgs, without asking customers to install the upgrade themselves. - **[Schedule a Push Upgrade Using SOAP API for First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-use-api.md)** After you’ve created an updated version of your package, you can automatically deploy it to customers using a push upgrade. - **[Enable a Package Subscriber to Restrict Push Upgrades](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-customized.md)** In certain scenarios, a Salesforce customer may require the ability to block push upgrades of managed packages that they have installed in their org. Customized push upgrades let Salesforce Partners give customers the ability to restrict push upgrades to a specific customer org for a specific package. - **[Assign Access to New and Changed Features in First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/push-upgrade-assigning-access.md)** Determine how to provide existing non-admin users access to new and changed features. By default, any new components included in the push upgrade package version are assigned only to admins. - **[Sample Post Install Script for a Push Upgrade](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/push-upgrade-post-install-script.md)** Automate the assignment of new components to existing users of a package for first- and second-generation managed packages. - **[Push Upgrade Best Practices](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/push-upgrade-best-practices.md)** Push Upgrade is one of the most powerful features we provide to our partners. Pushing an upgrade without proper planning and preparation can result in significant customer satisfaction issues. Here are some best practices to consider. # Push Package Upgrades to Subscribers A push upgrade is a method of automatically upgrading your customers to a newer version of your package. This feature can be used to ensure that all your customers are on the same or latest version of your package. You can push an upgrade to any number of organizations that have installed your managed package. A package subscriber doesn’t need to do anything to receive the push upgrade. The only indication a subscriber receives after a successful push upgrade is that the package’s Version Number on the Package Detail page has a higher value. The developer initiating the push resolves upgrades that fail. Use the Push Upgrade Exclusion List to exclude specific subscriber orgs from a push upgrade. You can specify up to 500 comma-separated org IDs. Push upgrades minimize the potential risks and support costs of having multiple subscribers running different versions of your app. You can also automate many post-upgrade configuration steps, further simplifying the upgrade process for your customers. The push upgrade feature is only available to first- and second-generation managed packages that have passed the AgentExchange security review. To enable push upgrades for your managed package, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com/). For details on the security review process, see [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm) in the _ISVforce Guide_. - **[Push Upgrades](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-push-about.md)** - **[Push Upgrade Best Practices](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-best-practices.md)** Push Upgrade is one of the most powerful features we provide to our partners. Pushing an upgrade without proper planning and preparation can result in significant customer satisfaction issues. Here are some best practices to consider. - **[Assign Access to New and Changed Features in First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-assigning-access.md)** Determine how to provide existing non-admin users access to new and changed features. By default, any new components included in the push upgrade package version are assigned only to admins. - **[Sample Post Install Script for a Push Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-post-install-script.md)** Automate the assignment of new components to existing users of a package for first- and second-generation managed packages. - **[Scheduling Push Upgrades](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-scheduling.md)** After you’ve created an updated version of your package, you can automatically deploy it to customers using a push upgrade. - **[Enable a Package Subscriber to Restrict Push Upgrades](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-customized.md)** In certain scenarios, a Salesforce customer may require the ability to block push upgrades of managed packages that they have installed in their org. Customized push upgrades let Salesforce Partners give customers the ability to restrict push upgrades to a specific customer org for a specific package. # Push Upgrade Best Practices Push Upgrade is one of the most powerful features we provide to our partners. Pushing an upgrade without proper planning and preparation can result in significant customer satisfaction issues. Here are some best practices to consider. ## Plan, Test, and Communicate - Share an upgrade timeline plan with your customers so they know when you’ll upgrade, and how often. - Plan when you want to push upgrades to your customers’ orgs. Keep in mind that most customers don’t want changes around their month-end, quarter-end, and year-end or audit cycles. Do your customers have other critical time periods when they don’t want any changes to their org? For example, there might be certain times when they don’t have staff available to verify changes or perform any required post-installation steps. - Schedule push upgrades during your customers’ off-peak hours, such as late evening and night. Have you considered time zone issues? Do you have customers outside the United States who have different off-peak hours? You can schedule push upgrades to any number of customer organizations at a time. Consider grouping organizations by time zone, if business hours vary widely across your customer base. - Don’t schedule push upgrades close to Salesforce-planned maintenance windows. In most cases, it might be better to wait 3-4 weeks after a major Salesforce release before you push major upgrades. - Test, test, and test! Since you’re pushing changes to the organization instead of the customer pulling in changes, there’s a higher bar to ensure the new version of your app works well in all customer configurations. ## Stagger Your Push Upgrades - Don’t push changes to all customers at once. It’s important to ensure that you have sufficient resources to handle support cases if there are issues. Also, it’s important that you discover possible issues before your entire customer base is affected. - Push to your own test organizations first to confirm that the push happens seamlessly. Log in to your test organization after the push upgrade and test to see that everything works as expected. - When applicable, push to the sandbox organizations of your customers first before pushing to their production organizations. Give them a week or more to test, validate, and fix in the sandbox environment before you push to their production organizations. - Push upgrades to small batches of customer production organizations initially. For example, if you have 1,000 customers, push upgrades to 50 or 100 customers at a time, at least the first few times. After you have confidence in the results, you can upgrade customers in larger batches. ## Focus on Customer Trust - You’re responsible for ensuring that your customers’ organizations aren’t adversely affected by your upgrade. Avoid making changes to the package, such as changes to validation rules or formula fields, that might break external integrations made by the customer. If for some reason you do, test and communicate well in advance. Please keep in mind that you can impact customer data, not just metadata, by pushing an upgrade that has bugs. - Write an Apex test on install to do basic sanity testing to confirm that the upgraded app works as expected. - If you’re enhancing an existing feature, use a post-install script to automatically assign new components to existing users using permission sets. - If you’re adding a new feature, don’t auto-assign the feature to existing users. Communicate and work with the admins of the customer org so they can determine who should have access to the new feature, and the timing of the rollout. # Push Upgrades Overview of Push Upgrade Steps - Upgrade your managed package installed in a customer organization from version X to version Y - Select one, many, or all customer organizations to upgrade and select a particular version to upgrade to - Schedule the upgrade to start at a particular date and time - View progress of upgrades, abort upgrades in progress, or view the result of a push upgrade - In conjunction with push, you can use a post-install Apex script to automate post-upgrade configurations that your customers have previously performed manually **note:** When you push an upgrade, you’re making changes to a subscriber’s org without explicit consent. Therefore, it’s important to plan ahead and exercise caution. You can also exclude specific subscriber orgs from a push upgrade by entering the org IDs, separated by a comma, in the Push Upgrade Exclusion List. Pushing a major upgrade entails a higher degree of risk as it can impact existing functionality in a subscriber’s organization. This is because new components in the upgraded package might not be available to existing users of the package, or could overwrite users’ customizations. As the app developer, it’s your responsibility to protect users from any adverse impact due to upgrading. We strongly recommend you consider all potential consequences of the upgrade and take appropriate steps to prevent any problems. When pushing a major upgrade, we recommend that you divide changes in your package into two categories: 1. Enhancements to existing features that users already have access to—Use a post install Apex script to automatically assign the relevant components to existing users. This ensures all current users of the package can continue using it without explicit action by administrators. 2. New features you’re introducing—Don’t use a post install Apex script to auto-assign components. This ensures your subscribers have the opportunity to decide if and when to use the new features. Here are some additional guidelines to keep in mind when planning a push upgrade. - Avoid changes to validation rules, formula fields, and errors thrown from Apex triggers, as they may negatively impact subscribers’ integrations. - Don’t make visible changes to a package in a patch. This is because other than a change in the package version number, subscribers aren't notified of push upgrades. - Test your upgraded package in multiple environments, replicating all relevant features of your customers’ organizations, including editions, customizations, other installed packages, and permission sets. - Schedule push upgrades at your customers’ off-peak hours and outside of Salesforce’s major release windows, to minimize potential subscriber impact. - Notify your subscribers in advance about the timing of the upgrade, its potential consequences, and any steps they need to take. # Receive Private Offers from AgentExchange Partners Customers can receive tailored pricing and contract terms by opting into private offers directly within their Salesforce org. This streamlined procurement process replaces fragmented email chains with a unified purchasing experience through the Your Account page. Users can review, accept, or reject customized offers sent by third-party partners to speed up solution deployment. After you accept the offer, automated billing and provisioning then ensure immediate access to the purchased software. ## Before You Begin | User Permissions Needed |   | | ---------------------------------------------- | ------------------------------ | | To receive, review, and accept Private Offers: | Manage Billing User permission | **note:** Only specific partners use the Private Offers. If a partner offers the service, you either see a Request Private Offer button on their AgentExchange listing or they can send you a private offer directly. ## Receive Private Offers To receive private offers from partners: 1. From Setup, in the Quick Find box, enter `Offers Marketplace`, and select it. 2. Select **Opt-in to Partner Offers and Agree to Terms and Conditions** to turn on Private Offers. 3. Agree to the terms to allow third-party negotiations within Salesforce. ## Request Private Offers To request private offers from a partner listing: 1. From an AgentExchange listing, select **Request Private Offer**. 2. Fill in your contact information and details about your request. 3. Select **Request Offer**. 4. You receive an email with the offer and links to respond when it's ready. ## Manage Offers To manage private offers in your Salesforce org: 1. After you opt in, go to the Your Account page. 2. Select the Partner Offers tile. 3. From the Partner Offers tab, select the offer you want to manage. 4. From the Offer Detail page, you can view all the offer details, including negotiated pricing, start and end dates, and contract terms. 5. Select Accept or Reject to respond to the offer. 6. After you accept the offer, Salesforce generates an order that appears in the partner and Salesforce systems. You receive your product licenses and an invoice, as outlined in the offer. You can continue to access offer details from the Your Account page. ## Enable Renewal Expiration Notifications For new and existing customers, the subscriber order expiration notifications are disabled by default. Because these notifications are flow templates, you must clone a template before you can activate it. To enable the notifications: 1. From Setup, enter **Flows** in the Quick Find box, and then select it. 2. Locate the Go-To-Market renewal subscriber order expiration flow template and open it. 3. Select **Save As New Flow**. 4. Open the cloned flow, enter a name and label for the flow, and then click **Activate**. # Recommend a Specific Package Version to Your Subscribers You can choose to recommend that your subscribers upgrade to a specific, released version of your package. When you set a package version as the recommended version, your subscribers see an **Upgrade to Recommended Version** option on the Installed Packages page in their org. ![The Upgrade to Recommended Version link on a subscriber's Installed Package page](https://developer.salesforce.com/media/pkg2_dev/pkg2_recommended_version.png) To set a package’s recommended version, run the `sf package update` CLI command and specify the package version in the `--recommended-version-id` flag. This example sets `PackageA@1.0` as the recommended version. ```nolang sf package update --package 0Ho.. --target-dev-hub devhub@example.com --recommended-version-id PackageA@1.0 ``` Keep in mind these requirements and considerations for setting a recommended version: - You can set one recommended version per package. - Only released package versions can be set as the recommended version. - The recommended version is not required to be the latest, released version of a package. - When you update the recommended version, the new version that you set must be a descendant of the previous version in the [package ancestry](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_package_ancestor_intro.htm). If the package versions don’t share an ancestry tree, you’ll get an error when you try to update the package’s recommended version. To bypass this error, you can use the `sf package update` CLI command’s `--skip-ancestor-check` flag. **See Also** - [Release a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-pkg-ver-promote.md) - [_Salesforce CLI Command Reference_: package update](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_update_unified) # Recommendations Your query strategy varies based on your business size and scope. Also, your query strategy must adapt as your business grows. To stay current, follow our App Analytics query recommendations for small, medium, and large-sized partners. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | **note:** In the unlikely event of data delays, we regenerate data for log events that happened up to 30 days in the past. To ensure that you consistently retrieve the most complete data, we recommend that you schedule catch-up queries that look back 30 days. - **[Small-Sized Partners](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-recommendations-small.md)** Small-sized partners have manageable subscriber bases and one or two managed packages. A small partner’s total daily usage data across all managed packages is 5 GB or less. Also, small partner’s queries complete well under the 15-minute processing time limit. - **[Medium-Sized Partners](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-recommendations-medium.md)** Medium-sized partners have bigger subscriber bases and about six managed packages. A medium-sized partner’s total daily usage data across all managed packages is at or just over 20 GB. Also, this partner’s queries approach or hit the 15-minute processing time limit. - **[Large-Sized Partners](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/app-analytics-recommendations-large.md)** Large partners have large subscriber bases and many managed packages. A large partner’s total daily data usage is more than 20 GB. Sometimes a large partner’s data from just one managed package is larger than the 20-GB daily limit. Also, large partners often must create a smaller time range for each query to complete in under the 15-minute processing time limit. # Refresh Licenses for a Managed Package To sync all license records for a package across all subscriber installations, you refresh the license. Refreshing the license can also resolve discrepancies between the number of licenses in a subscriber’s org and the number displayed in the License Management App (LMA). Refreshing is required when you move the LMA to a different org. **note:** For each package, you can refresh licenses only one time per week. 1. From the LMA, select the **Packages** tab. 2. Open the package record. 3. Click **Refresh Licenses**. In Lightning Experience, Refresh Licenses is located in the dropdown menu. # Register a Namespace for a First-Generation Managed Package A namespace is a one to 15-character alphanumeric identifier that distinguishes your package and its contents from packages of other developers on AgentExchange. Namespace prefixes are case-insensitive. For example, ABC and abc aren’t recognized as unique. Your namespace must be globally unique across all Salesforce orgs. **note:** Building a new app? Have you considered using second-generation managed packages? Flexible versioning and the ability to share a namespace across packages are just two reasons why developers love creating second-generation managed packages. We think you’d love it, too. To learn more, see: [Why Switch to Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm), and [Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_comparison.htm). **note:** When creating a namespace, use something that’s useful and informative to users. However, don’t name a namespace after a person (for example, by using a person's name, nickname, or private information.) Salesforce automatically prepends your namespace, followed by two underscores (”\_\_”), to all unique component names in your Salesforce org. A unique package component is one that requires a name that no other component has within Salesforce, such as custom objects, custom fields, custom links, and validation rules. For example, if your namespace is abc and your managed package contains a custom object with the API name, Expense**c, use the API name abc**Expense\_\_c to access this object using the API. The namespace is displayed on all component detail pages. Your namespace must: - Begin with a letter - Contain one to 15 alphanumeric characters - Not contain two consecutive underscores For example, `myNp123` and `my_np` are valid namespaces, but `123Company` and `my__np` aren’t. To register a namespace: 1. From Setup, enter `Package Manager` in the Quick Find box and select **Package Manager**. 2. In the Namespace Settings panel, click **Edit**. **note:** After you’ve configured your namespace settings, this button is hidden. 3. Enter the namespace you want to register. 4. To determine if the namespace is already in use, click **Check Availability**. 5. If the namespace prefix that you entered isn’t available, repeat the previous two steps. 6. Click **Review**. 7. Click **Save**. # Release a Second-Generation Managed Package Each new second-generation managed package version is marked as beta when created. As you develop your package, you may create several package versions before you create a version that is ready to be released and distributed. Only released package versions can be listed on AgentExchange and installed in customer orgs. Before you promote the package version, ensure that the user permission, **Promote a package version to released**, is enabled in the Dev Hub org associated with the package. Consider creating a permission set with this user permission, and then assign the permission set to the appropriate user profiles. When you’re ready to release, use `sf package version promote`. ```nolang sf package version promote --package "Expense Manager@1.3.0-7" ``` If the command is successful, a confirmation message appears. ```nolang Successfully promoted the package version, ID: 04tB0000000719qIAA to released. ``` After the update succeeds, view the package details. ```nolang sf package version report --package "Expense Manager@1.3.0.7" ``` Confirm that the value of the Released property is `true`. ```nolang === Package Version NAME VALUE ────────────────────────────── ─────────────────── Name ver 1.0 Alias Expense Manager-1.0.0.5 Package Version Id 05iB0000000CaahIAC Package Id 0HoB0000000CabmKAC Subscriber Package Version Id 04tB0000000NPbBIAW Version 1.0.0.5 Description update version Branch Tag git commit id 08dcfsdf Released true Created Date 2021-05-08 09:48 Installation URL https://login.salesforce.com/packaging/installPackage.apexp?p0=04tB0000000NPbBIAW ``` You can promote and release only one time for each package version number, and you can’t undo this change. # Remove Approvers Remove users from the Install Request Approvers list when they no longer need to install AgentExchange apps on behalf of requesters. To remove approvers: 1. From Setup, go to **Install Request Approvers**. 2. Select one or more approvers, and then click **Remove selected approvers**. Or, on a row, open the row actions menu and select **Remove approver**. 3. Confirm the removal. Removed users stop receiving email and in-app notifications for new app install requests. **note:** You can't remove all the approvers while Install Request Approvers is on. Keep at least one approver on the list, or turn off the feature. To add approvers, see Add Approvers. To stop routing install requests to approvers, see [Turn Off Install Request Approvers](https://developer.salesforce.com/docs/platform/appexchange-install-guide/guide/agentexchange-agentforce-turn-off-install-approvers.md). # Remove Components from First-Generation Managed Packages Remove metadata components such as Apex classes that you no longer want in your first-generation managed packages. After a managed package has been promoted to the Managed-Released state, only certain components can be removed. To confirm whether a specific component can be removed, see [Components Available in Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/packaging_packageable_components.htm) in the Second-Generation Managed Packaging Developer Guide. **Impact of Component Removal in Subscriber Orgs** During package upgrade only certain component types are hard deleted and removed from the subscriber org. Most metadata components that were removed in a package version, will remain in the subscriber org after package upgrade, and marked as deprecated. When a package is upgraded in the subscriber org, the Setup Audit Trail logs which components were removed. Admins of a subscriber org can delete deprecated metadata. To enable component deletion in your packaging org, log a case with [Salesforce Partner Support.](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/pkg2_feature_enablement.htm) Before you remove a component, ensure that there aren’t any dependencies on the metadata you plan to remove. If any component in the package depends on or references the component you're removing, the package version creation operation fails. After you remove a component or field, you can't access the component, or any customizations that depend on the removed component. When you delete a component, you also permanently delete the data that exists in that component. Delete tracked history data is also deleted, and integrations that rely on the component, such as assignment or escalation rules, are changed. After you delete a component in a managed package, you can’t restore it or create another component with the same name. **note:** In a managed package, the API names of fields must be unique and can’t be reused even after you delete the component. This restriction prevents conflicts during package installation and upgrade. Data and metadata are never deleted in a subscriber org without specific action by the customer. When a subscriber upgrades to the new package version, the deleted components are still available in the subscriber’s org. The components are displayed in the Unused Components section of the Package Details page. This section ensures that subscribers have the opportunity to export data and modify custom integrations involving those components before explicitly deleting them. For example, before deleting custom objects or fields, customers can preserve a record of their data from Setup by entering `Data Export` in the Quick Find box and then selecting **Data Export**. **note:** Educate your customers about the potential impact of deleted components. Consider listing all custom components that you’ve deleted and specifying any actions needed in the Release Notes for your upgraded package. These restrictions apply when deleting managed components. - If a component is referenced by any other metadata, such as workflow rules, validation rules, or Apex classes, you can’t delete it. - You can’t delete a custom object if it includes Apex Sharing Reason, Apex Sharing Recalculation, Related Lookup Filter, Compact Layout, or Action. - Salesforce doesn’t recommend deleting a custom field that is referenced by a custom report type in the same package. This type of deletion causes an error when installing the upgraded package. - When you delete a field that is used for bucketing or grouping in a custom report type that is part of a managed package, you receive an error message. - When you remove a connected app that is a component of a package, the app remains available until you update the package with a new version. But if you delete the connected app, it’s permanently deleted. Any version of the package that contains the deleted connected app is invalidated and can’t be installed. You can update a version of the package that _doesn’t_ contain the connected app as a component. Never delete a connected app that Salesforce distributes, such as the Salesforce app. You can delete managed components either declaratively from the user interface or programmatically using Metadata API. With Metadata API, specify the components that you want to delete in a `destructiveChanges.xml` manifest file and then use the standard `deploy()` call. The process is identical to deleting components that aren’t managed. For more information, see the [Metadata API Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/) . ## Removing Public Apex Classes and Public Visualforce Components Because the behavior of managed package components differs from public Apex classes and public Visualforce components, you use a two-stage process to delete Visualforce pages, global Visualforce components, and global Lightning components from a managed package. When you upgrade a package in a subscriber org, the Visualforce pages, global Visualforce components, and Lightning components that you deleted aren’t removed. Although a Delete button or link is available to org administrators, many orgs continue using the obsolete pages and components. However, public Apex classes and public Visualforce components are deleted as part of the upgrade process. If you delete pages and components without performing this two-stage procedure, Salesforce can’t warn you when later deletions of public classes and components break your subscribers’ obsolete pages and components. If you’re deleting these types of components, perform this two-stage process in the order presented. - - A Visualforce page or global Visualforce component that refers to or uses public Apex classes or public Visualforce components - An Aura component with global access - A Lightning web component with an `isExposed` value of `true` 1. Stage one: Remove references. 1. Edit the global component that you want to delete. - For Visualforce, edit your Visualforce page or global Visualforce component to remove all references to public Apex classes or public Visualforce components. - For Lightning components, edit the global Lightning component to remove all references to other Lightning components. 2. Upload your new package version. 3. Push the stage-one upgrade to your subscribers. 2. Stage two: Delete your obsolete pages or components. 1. Delete your Visualforce page, global Visualforce component, or global Lightning component. 2. Optionally, delete other related components and classes. 3. Upload your new package version. 4. Push the stage-two upgrade to your subscribers. # Remove Metadata Components from Second-Generation Managed Packages Remove metadata components such as Apex classes that you no longer want in your second-generation managed packages. ## Impact of Component Removal in Subscriber Orgs During a package upgrade, only certain component types are hard deleted and removed from the subscriber org. Most metadata components that were removed from a package version remain in the subscriber org after package upgrade and are marked as deprecated. When a package is upgraded in the subscriber org, the Setup Audit Trail logs which components were removed. Admins of a subscriber org can delete deprecated metadata. If the subscriber uninstalls the package, deprecated metadata that was previously associated with the package is deleted. You can remove these metadata components from second-generation managed packages. | Metadata Component | Upon Package Upgrade, the Metadata Component is ... | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Analytic Snapshot | Marked as deprecated | | Apex Class (excluding global Apex classes) | Hard deleted | | Apex Trigger | Hard deleted | | Aura Component | Marked as deprecated | | Compact Layout | Marked as deprecated | | Custom Application | Marked as deprecated | | Custom Application Component | Marked as deprecated | | Custom Field | Marked as deprecated | | Custom Labels | Marked as deprecated | | Custom Metadata Type Records | Marked as deprecated, if visible to the subscriber org; otherwise, hard deleted. | | Custom Object | Marked as deprecated | | Custom Permission | Marked as deprecated | | Custom Tab | Marked as deprecated | | Dashboard | Marked as deprecated | | Dashboard Folder | Marked as deprecated | | Document | Marked as deprecated | | External Auth Identity Provider | Marked as deprecated | | External Client App Header | Hard deleted | | External Client App Settings | Hard deleted | | External Credential | Marked as deprecated | | External Services | Marked as deprecated | | Field Set | Marked as deprecated | | Flow | Marked as deprecated | | Lightning Page | Marked as deprecated | | Lightning Web Component | Marked as deprecated | | List View | Marked as deprecated | | Named Credential | Marked as deprecated | | Page Layout | Marked as deprecated | | Permission Set | Marked as deprecated | | Platform Event Channel | Hard deleted | | Platform Event Channel Member | Hard deleted | | Profile | Marked as deprecated | | Quick Action | Marked as deprecated | | Record Type | Marked as deprecated | | Remote Site Setting | Marked as deprecated | | Report | Marked as deprecated | | Report Folder | Marked as deprecated | | Report Type | Marked as deprecated | | Sharing Reason | Marked as deprecated | | Static Resource | Marked as deprecated | | Validation Rule | Marked as deprecated | | Visualforce Component (excluding global components) | Hard deleted | | Visualforce Page | Marked as deprecated | | WebLink (Custom Button or Custom Link) | Marked as deprecated | | Workflow Email Alert, Workflow Field Update, Workflow Outbound Message, Workflow Rule, Workflow Task | Marked as deprecated | ## How to Remove Metadata Components To request access to this feature, log a case with [Salesforce Partner Support](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pkg2-feature-enablement.md). After your request is approved, remove the metadata component’s source file from your Salesforce DX project, and create a package version. Test the new package version to ensure it’s working properly without the removed metadata. ## Before You Remove Metadata Components from Second-Generation Managed Packages To ensure you can successfully remove metadata components from a second-generation managed package, keep these details in mind. - Request access to the feature, if you haven’t already. - Familiarize yourself with the list of metadata components that can be removed. - Ensure that there aren’t dependencies on the metadata you plan to remove. If any component in the package depends on or references the component you're removing, the package version creation operation fails. After you remove a component, you can't access any customizations that depend on the removed component. ## Remove Metadata Dependencies Within a Package If there are dependencies to the metadata component you plan to remove, resolve the dependency before removing the metadata component. For example, before deleting a custom field that is referenced in a page layout, edit the page layout and remove the reference to the custom field. Then remove the custom field from your source file, and create a package version. Some scenarios require a two-step approach to component removal. For example, let's say you plan to remove a Visualforce page that contains a Visualforce component and replace it with a Lightning page that contains a Lightning component. Removing both the Visualforce page and Visualforce component in a single upgrade could cause issues for your subscribers. These issues occur because Visualforce components are deleted, and Visualforce pages are deprecated during package upgrade. To avoid issues for your subscribers in this example, remove the reference to the Visualforce component from the Visualforce page, create a package version, and push the upgrade. Then remove the Visualforce page from your package version, and push this upgrade to subscribers. ## Remove Dependencies Located in Other Packages Before you remove a metadata component, first remove all references to the metadata, including references in other packages that depend on that metadata component. For example, if you’re removing a public Apex class, ensure your other packages aren’t referencing that class using the Apex `@namespaceAccessible` annotation. In this section, PackageA refers to the package in which you plan to remove a metadata component. And PackageB is any package that depends on the metadata you’re removing from PackageA. If you have references to the metadata component or Apex class in PackageB, follow these steps: 1. Remove the reference to the metadata component from PackageB. 2. Create a version of PackageB. 3. Push the new version of PackageB to your subscribers. 4. Repeat these steps if any other packages include a reference to the metadata you plan to remove from PackageA. After you've removed all references to the metadata component, remove the metadata component’s source file from the Salesforce DX project of PackageA. Then create a version of PackageA. Before pushing this upgrade to subscribers, test the new package version to ensure it’s working properly. - **[What to Consider Before Removing Metadata Components](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-md-removal-considerations.md)** In most cases, removing metadata components from a second-generation managed package marks the component as deprecated and doesn’t hard delete the component from the subscriber org. This approach to component removal ensures that package upgrades don’t disrupt a subscriber’s org. # Report Orders to Salesforce with the Channel Order App Create, manage, and submit orders to Salesforce with the Channel Order App (COA). If you’re an OEM partner, you can use the COA to provision Salesforce licenses and for revenue sharing. If you’re an ISV partner, you can use the COA for revenue sharing. If you use AgentExchange Checkout to manage customer payments, don’t use the COA. Revenue for partners who use Checkout is automatically reported to Salesforce when customers purchase your AgentExchange solution. The COA is preinstalled in your Partner Business Org, but before you use it, you must complete the training offered by the Partner Operations team. Acquire your Partner Business Org, pass the solution security review, and then sign up for COA training. To sign up, log a support case in the [Salesforce Partner Community](https://partners.salesforce.com). For product, specify **ISV Billing & Order Support**. For topic, specify **Channel Order App Setup & Product Catalog Support**. **note:** Submit orders based on the sales and licensing of your solutions to customers, as required by your partner agreement. # Request a Salesforce Partner Business Org If you didn’t receive a Partner Business Org (PBO) when you joined the Salesforce Partner Community, log a case to request one. If you created a separate username when you joined the Partner Community, skip this step. Your PBO was automatically provisioned for you when you joined. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click the account switcher and verify that your partner account is selected. 3. Click **?**, and then click **Log a Case for Help**. 4. Fill in the required fields. 1. For Subject, enter `Requesting Partner Business Org (PBO)`. 2. For Description, note that you’re a Salesforce partner and you’re requesting a PBO. 3. When prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **Demo & Partner Business Orgs**. 6. Select an instance type and severity level. 5. Click **Create Case**. ## Next Steps We review the case and contact you with next steps. # Request a Trialforce Management Org A Trialforce Management Org (TMO) is the starting point for creating trials with Trialforce. To request your TMO, log a case. ## Before You Begin To receive a TMO, you must be a qualified ISV partner and your solution must pass the AgentExchange security review. **note:** The TMO is separate from your Partner Business Org. ## Steps 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. Fill in the required details. 1. For Subject, enter `Trialforce Management Org (TMO) Request`. 2. For Description, specify that you’re a Salesforce partner and you’re requesting your TMO. 3. When prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **ISV Technology Request**. 6. For Org ID, enter the org ID of the org to use as the TMO, which is often a namespaced Developer Edition org. 7. Select an instance type and severity level. 4. Click **Create a Case**. ## Next Steps We review the case and contact you if we need more information. # Request an API Token for Your Solution An API token is required for an AgentExchange solution to authenticate and authorize API requests. You can request an API token for your managed package after it passes the AgentExchange security review. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. Fill in the required details. 1. For Subject, enter `API Token Request`. 2. For Description, mention that you're a Salesforce partner and that you're requesting an API token for your AgentExchange solution. 3. When you're prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **ISV Technology Request**. 6. Enter the ID of your Dev Hub or packaging org. 7. Select an instance type and severity level. 4. Click **Create a Case**. ## Next Steps We review the case and contact you if we need more information. # Request an API Token for Your Solution An API token is required for an AgentExchange solution to authenticate and authorize API requests. You can request an API token for your managed package after it passes the AgentExchange security review. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. Fill in the required details. 1. For Subject, enter `API Token Request`. 2. For Description, mention that you're a Salesforce partner and that you're requesting an API token for your AgentExchange solution. 3. When you're prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **ISV Technology Request**. 6. Enter the ID of your Dev Hub or packaging org. 7. Select an instance type and severity level. 4. Click **Create a Case**. ## Next Steps We review the case and contact you if we need more information. # Request an Extension for a Test Drive Org Test drive orgs expire after 1 year. To prevent a test drive from expiring, log a support case to request an extension. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. Fill in the required details. 1. For Subject, enter `Test Drive Org Extension`. 2. For Description, note that you’re a Salesforce partner and you’re requesting an extension for an expiring test drive. 3. When prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **Trial Org Extensions**. 6. Provide the ID of your test drive org. 7. Select an instance type and severity level. 4. Click **Create a Case**. ## Next Steps We review the case and contact you if we need more information. # Request an Extension for a Trialforce Source Org Trialforce Source Orgs (TSOs) expire after 1 year. To prevent a TSO from expiring, log a support case to request an extension. TSOs that are Developer Edition orgs expire if you don’t log in to them at least once every 180 days. See Salesforce Help: [Developer Org Expiration](https://help.salesforce.com/s/articleView?id=xcloud.admin_de_org_expiration.htm&type=5) for details. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. Fill in the required details. 1. For Subject, enter `Trialforce Source (TSO) Org Extension`. 2. For Description, note that you’re a Salesforce partner and you’re requesting an extension for an expiring TSO. 3. When prompted to select a product, click **Pick a different product / topic**. 4. For Product, select **Partner Programs & Benefits**. 5. For Topic, select **Trial Org Extensions**. 6. Provide the ID of your TSO. 7. Select an instance type and severity level. 4. Click **Create a Case**. ## Next Steps We review the case and contact you if we need more information. # Resolve Apex Test Failures Package installs or upgrades may fail for not passing Apex test coverage. However, some of these failures can be ignored. For example, a developer might write an Apex test that makes assumptions about a subscriber's data. If your install fails due to an Apex test failure, check for the following: - Make sure that you’re staging all necessary data required for your Apex test, instead of relying on subscriber data that exists. - If a subscriber creates a validation rule, required field, or trigger on an object referenced by your package, your test might fail if it performs DML on this object. If this object is created only for testing purposes and never at runtime, and the creation fails due to these conflicts, you might be safe to ignore the error and continue the test. Otherwise, contact the customer and determine the impact. # Run Apex on Package Install/Upgrade App developers can specify an Apex script to run automatically after a subscriber installs or upgrades a managed package. This script makes it possible to customize the package install or upgrade, based on details of the subscriber’s organization. For instance, you can use the script to populate custom settings, create sample data, send an email to the installer, notify an external system, or kick off a batch operation to populate a new field across a large set of data. For simplicity, you can only specify one post install script. It must be an Apex class that is a member of the package. The post install script is invoked after tests have been run, and is subject to default governor limits. It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo. You can only see this user at runtime, not while running tests. If the script fails, the install/upgrade is aborted. Any errors in the script are emailed to the user specified in the **Notify on Apex Error** field of the package. If no user is specified, the install/upgrade details are unavailable. The post install script has the following additional properties. - It can initiate batch, scheduled, and future jobs. - It can’t access Session IDs. - It can only perform callouts using an async operation. The callout occurs after the script is run and the install is complete and committed. - It can’t call another Apex class in the package if that Apex class uses the `with sharing` or `inherit sharing` keyword. These keywords can prevent the package from successfully installing. To learn more, see the [Apex Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm). **note:** You can’t run a post install script in a new trial organization provisioned using Trialforce. The script only runs when a subscriber installs your package in an existing organization. - **[How Does a Post Install Script Work?](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script-intro.md)** A post install script is an Apex class that implements the `InstallHandler` interface. - **[Example of a Post Install Script](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script-create.md)** - **[Specifying a Post Install Script](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script-specify.md)** After you’ve created and tested the post install script, you can specify it in the **Post Install Script** lookup field on the Package Detail page. In subsequent patch releases, you can change the contents of the script but not the Apex class. # Run Apex on Package Install/Upgrade App developers can specify an Apex script to run automatically after a subscriber installs or upgrades a managed package. This script makes it possible to customize the package install or upgrade, based on details of the subscriber’s organization. For instance, you can use the script to populate custom settings, create sample data, send an email to the installer, notify an external system, or kick off a batch operation to populate a new field across a large set of data. For simplicity, you can only specify one post install script. It must be an Apex class that is a member of the package. The post install script is invoked after tests have been run, and is subject to default governor limits. It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo. You can only see this user at runtime, not while running tests. If the script fails, the install/upgrade is aborted. Any errors in the script are emailed to the user specified in the **Notify on Apex Error** field of the package. If no user is specified, the install/upgrade details are unavailable. The post install script has the following additional properties. - It can initiate batch, scheduled, and future jobs. - It can’t access Session IDs. - It can only perform callouts using an async operation. The callout occurs after the script is run and the install is complete and committed. - It can’t call another Apex class in the package if that Apex class uses the `with sharing` or `inherit sharing` keyword. These keywords can prevent the package from successfully installing. To learn more, see the [Apex Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm). **note:** You can’t run a post install script in a new trial organization provisioned using Trialforce. The script only runs when a subscriber installs your package in an existing organization. - **[How Does a Post Install Script Work?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/apex-post-install-script-intro.md)** A post install script is an Apex class that implements the `InstallHandler` interface. - **[Example of a Post Install Script](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/apex-post-install-script-create.md)** - **[Specifying a Post Install Script](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pd-apex-post-install-script-specify.md)** After you’ve created and tested the post install script, you can specify it in the **Post Install Script** lookup field on the Package Detail page. In subsequent patch releases, you can change the contents of the script but not the Apex class. # Run Apex on Package Uninstall App developers can specify an Apex script to run automatically after a subscriber uninstalls a managed package. This script makes it possible to perform cleanup and notification tasks based on details of the subscriber’s organization. For simplicity, you can only specify one uninstall script. It must be an Apex class that is a member of the package. The uninstall script is subject to default governor limits. It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo. You can only see this user at runtime, not while running tests. If the script fails, the uninstall continues but none of the changes performed by the script are committed. Any errors in the script are emailed to the user specified in the **Notify on Apex Error** field of the package. If no user is specified, the uninstall details are unavailable. The uninstall script has the following restrictions. You can’t use it to initiate batch, scheduled, and future jobs, to access Session IDs, or to perform callouts. - **[How Does an Uninstall Script Work?](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script-intro.md)** An uninstall script is an Apex class that implements the `UninstallHandler` interface. This interface has a single method called `onUninstall` that specifies the actions to be performed on uninstall. - **[Example of an Uninstall Script](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script-create.md)** This sample uninstall script performs the following actions on package uninstall. - **[Specifying an Uninstall Script](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script-specify.md)** After you’ve created and tested the uninstall script and included it as a member of your package, you can specify it in the **Uninstall Script** lookup field on the Package Detail page. # Run the DailyAggregation CRM Analytics Recipe To create a reusable dataset, schedule your DailyAggregation CRM Analytics recipe to run on a regular basis. We recommend daily at midnight. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Dataflows & Recipes**. 3. Click the **Recipes** tab. 4. Next to your DailyAggregation CRM Analytics recipe, click the arrow. 5. Click **Schedule**, and set up your schedule. # Run the LMAJoin CRM Analytics Recipe To create a reusable dataset, schedule your LMAJoin CRM Analytics recipe to run on a regular basis. We recommend daily at midnight. ## Before You Begin | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | In your org in Analytics Studio in CRM Analytics: 1. Click **Data Manager**. 2. Click **Dataflows & Recipes**. 3. Click the **Recipes** tab. 4. Next to your LMAJoin CRM Analytics recipe, click the arrow. 5. Click **Schedule**, and set up your schedule. # Salesforce AI Skill for Post-Install Configuration Use the `dx-pkg-post-install-configure` AI Skill to automate the post-install configuration for any Salesforce managed package. AI Skills are packaged instruction sets that give AI coding clients specialized knowledge for building on the Salesforce platform. Skills are available from the [forcedotcom/sf-skills repository](https://github.com/forcedotcom/sf-skills) in GitHub. For more information, see [Use AI Skills for Salesforce Development ](https://developer.salesforce.com/docs/platform/salesforce-skills-plugins/guide/overview.html) in _Salesforce Development Plugin for Claude Code_. The [dx-pkg-post-install-configure](https://github.com/forcedotcom/sf-skills/tree/main/skills/dx-pkg-post-install-configure) skill automates the post-install configuration for any managed package. The post-install configuration can include: - Permission sets - Object or field permissions - Page layouts - Visualforce page access - Tab settings **note:** Before you use the `dx-pkg-post-install-configure` skill, you must have the following: - A fully authenticated org with active Salesforce admin permissions. - Salesforce-hosted Model Context Protocol (MCP) servers enabled. The `sf-object-all` MCP server is required. `sf-metadata` MCP servers are optional. - The target package already installed in the org. - Post-installation documentation that the agent can access. Sample prompts: - “I’ve just installed ExamplePackage. Configure its permission sets.” - “Set up ExamplePackage.” - “I've installed a managed package called \`ExamplePackage\`. Run the post-install setup for me.” # Salesforce AI Skills for Trialforce Use AI Skills to manage your Trialforce orgs directly from your AI coding client. AI Skills are packaged instruction sets that give AI coding clients specialized knowledge for building on the Salesforce platform. Skills are available from the [forcedotcom/sf-skills repository](https://github.com/forcedotcom/sf-skills) in GitHub. See [AI Skills](https://developer.salesforce.com/docs/platform/salesforce-skills-plugins/guide/overview.html) in the _Salesforce Development Plugin Guide_ for more information. [**dx-org-trial-expiration-check**](https://github.com/forcedotcom/sf-skills/tree/main/skills/dx-org-trial-expiration-check) Check when trial orgs, Developer Edition orgs, or scratch orgs expire or if they have already expired. Generate structured output (JSON or CSV) to create alerts or cron jobs for orgs that are about to expire. Get guidance on how to back up an org before it expires. Ask how to extend a trial. Sample prompts: - “When does my trial org expire?" - "Is my trial still active or has it expired?" - "Which of my orgs are expiring soon?" - "Set up a cron job for expiring orgs." - "Back up my org before it expires." - "How do I renew my Developer Edition org?” [**platform-trial-org-create**](https://github.com/forcedotcom/sf-skills/tree/main/skills/platform-trial-org-create) Create a Salesforce trial org, Developer Edition org, or Trialforce org. **note:** If you have [Environment Hub configured](https://developer.salesforce.com/docs/platform/isvforce/guide/environment-hub-intro.html) and have the required permissions and licenses, this skill can also help you create a Partner Developer Edition org. Sample prompts: - “Create a trial org.” - “Spin up a Developer Edition org.” - “Provision a trial org from a Trialforce template.” - “Check my trial org sign-up status.” # Salesforce Partner Business Org A Salesforce Partner Business Org (PBO) contains tools to set up and manage your ISV or OEM business, or your consulting practice. This internal-use production org comes with two Sales & Service Cloud Enterprise Edition licenses and pre installed tools. Your PBO is provisioned when you join the Salesforce Partner Community.
PBO ToolOverview
Channel Order App (COA)

The COA is the app that OEM and ISV partners use to create, manage, and submit customer orders to Salesforce. OEM partners can use the COA to provision Salesforce licenses and for revenue sharing. ISV partners can use the COA for revenue sharing.

The COA is pre installed in PBOs, but additional setup is required to access it.

See Also

Checkout Management App (CMA)

The CMA is a companion app to use with AgentExchange Checkout, AgentExchange’s integrated payment platform. With Checkout, customers can buy solutions directly from AgentExchange listings with a credit card or bank transfer. The CMA has a dashboard that shows Checkout data so partners can monitor key performance indicators, such as solution revenue and subscription status. The CMA also features customizable email notifications. Partners can automate emails to customers and team members.

Checkout and the CMA are available to ISV partners that distribute solutions in managed packages and are based in the United States, United Kingdom, or a European Union country. They aren’t available to OEM partners.

The CMA is pre installed in PBOs.

See Also

Dev Hub

A Dev Hub is where partners create and manage scratch orgs, second-generation managed packages, and namespaces. All Salesforce ISV and OEM partners should designate their PBO as their Dev Hub org.

Dev Hub is disabled in newly provisioned PBOs. Enable Dev Hub in Setup.

See Also

Environment HubThe Environment Hub is used to connect, create, view, and log in to Salesforce orgs from one location. If your company has multiple environments for development, testing, and trials, the Environment Hub streamlines org management. The Environment Hub is the only way that ISV partners can create Partner Developer Edition orgs (PDEs). A PDE has a higher API call limit, more storage, and a greater number of licenses available than a Developer Edition org. ISVs use PDEs for managed package development and packaging.

The Environment Hub app is pre installed in PBOs.

See Also

License Management App (LMA)

The LMA is a managed package that helps partners manage leads and licenses for their AgentExchange solutions. It includes custom objects for tracking package details, package versions, and licenses. Additionally, it features the Subscriber Support Console, a tool partners use to troubleshoot issues directly within subscriber organizations. The org that the LMA is installed in is called the License Management Org (LMO).

The LMA is pre installed in PBOs.

See Also

Feature Management App (FMA)

The FMA, a managed package that extends the LMA, allows partners to control the release of features to customers. For example, dark-launch a feature to see how it works in production before a full release, or offer limited-time trials to specific orgs. The FMA also gives partners the ability to track activation metrics for these features.

The FMA isn’t pre installed in PBOs.

See Also

 # Sample Design Scenarios for Group and Professional Editions Here are some scenarios to help you understand when and how to build for Group and Professional Editions. - Scenario 1: You want to build an app that uses record types - : Since record types aren’t available in Group Edition, decide if you want to support this edition. Assuming you do, you can build a base-managed package that doesn’t include record types. After uploading this managed package in a released state, you can install it into another Developer Edition org to start building the extension. Your extension can add record types that your Professional, Enterprise, Unlimited, and Performance Edition customers can install and use. - Scenario 2: You want to build an app with 80 custom objects - : Typically this scenario presents a problem for Group and Professional Edition orgs because of their custom objects limit. However, if you make your app available on the AgentExchange, it doesn’t count toward custom objects, tabs, and apps limits. So even if your app has 80 custom objects, it installs and works in Group and Professional Edition orgs. - Scenario 3: You want to build an app that makes Apex callouts to a web service - : Apex doesn’t normally run in Group and Professional Editions. If you get your managed package authorized during the security review, your Apex executes as expected. For this scenario, you build your Apex callout to invoke your external service and then include this class in your package. - Scenario 4: You want to build an app that uses Campaigns - : Campaigns are supported by default in Group Edition. For this scenario, you have two options. - Option 1 - Build a based-managed package that doesn’t reference Campaigns. in it’s complete, upload, and install it into another Developer Edition org. Build the Campaign functionality as an extension package. Now your Group Edition customers can install the base, while the rest can also install the extension to get extra features. - Option 2 - This option requires only one package if you use Dynamic Apex as the only reference to Campaigns (as described earlier) and do not include a custom field on the Campaign. Your app can then be installed in Group Edition orgs and higher. If Campaigns is in your customer’s edition, then your Dynamic Apex can manipulate Campaigns as expected. - Scenario 5: You want to build a composite app where your receive inbound API calls - : You have a separate hosted app that you want to integrate with Salesforce, so you must make API calls to Group and Professional Edition customers. Such calls aren’t possible by default. However, if you’re an eligible partner, request a special API token that allows your SOAP calls to integrate with Group and Professional Edition orgs. Be sure to embed the Client ID in the SOAP header of your external code. # Sample Post Install Script for a Push Upgrade Automate the assignment of new components to existing users of a package for first- and second-generation managed packages. **note:** Post-install scripts can be used with first and second-generation managed packages only. For more information on writing a post-install Apex script, see [Run Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/apex-post-install-script.md). In this sample script, the package upgrade contains new Visualforce pages and a new permission set that grants access to those pages. The script performs the following actions. - Gets the Id of the Visualforce pages in the old version of the package - Gets the permission sets that have access to those pages - Gets the list of profiles associated with these permission sets - Gets the list of users who have those profiles assigned - Assigns the permission set in the new package to those users ```apex global class PostInstallClass implements InstallHandler { global void onInstall(InstallContext context) { //Get the Id of the Visualforce pages List pagesList = [SELECT Id FROM ApexPage WHERE NamespacePrefix = 'TestPackage' AND Name = 'vfpage1']; //Get the permission sets that have access to those pages List setupEntityAccessList = [SELECT Id, ParentId, SetupEntityId, SetupEntityType FROM SetupEntityAccess WHERE SetupEntityId IN :pagesList]; Set PermissionSetList = new Set (); for (SetupEntityAccess sea : setupEntityAccessList) { PermissionSetList.add(sea.ParentId); } List PermissionSetWithProfileIdList = [SELECT id, Name, IsOwnedByProfile, Profile.Name, ProfileId FROM PermissionSet WHERE IsOwnedByProfile = true AND Id IN :PermissionSetList]; //Get the list of profiles associated with those permission sets Set ProfileList = new Set (); for (PermissionSet per : PermissionSetWithProfileIdList) { ProfileList.add(per.ProfileId); } //Get the list of users who have those profiles assigned List UserList = [SELECT id FROM User where ProfileId IN :ProfileList]; //Assign the permission set in the new package to those users List PermissionSetToAssignList = [SELECT id, Name FROM PermissionSet WHERE Name='TestPermSet' AND NamespacePrefix = 'TestPackage']; PermissionSet PermissionSetToAssign = PermissionSetToAssignList[0]; List PermissionSetAssignmentList = new List(); for (User us : UserList) { PermissionSetAssignment psa = new PermissionSetAssignment(); psa.PermissionSetId = PermissionSetToAssign.id; psa.AssigneeId = us.id; PermissionSetAssignmentList.add(psa); } insert PermissionSetAssignmentList; } } ``` ```apex // Test for the post install class @isTest private class PostInstallClassTest { @isTest public static void test() { PostInstallClass myClass = new PostInstallClass(); Test.testInstall(myClass, null); } } ``` # Sample Script for Installing Second-Generation Managed Packages with Dependencies Use this sample script as a basis to create your own script to install second-generation managed packages with dependencies. This script contains a query that finds dependent packages and installs them in the correct dependency order. ## Sample Script **note:** Be sure to replace the package version ID and scratch org user name with your own specific details. ```nolang #!/bin/bash # The execution of this script stops if a command or pipeline has an error. # For example, failure to install a dependent package will cause the script # to stop execution. set -e # Specify a package version id (starts with 04t) # If you know the package alias but not the id, use sf package version list to find it. PACKAGE=04tB0000000NmnHIAS # Specify the user name of the subscriber org. USER_NAME=test-bvdfz3m9tqdf@example.com # Specify the timeout in minutes for package installation. WAIT_TIME=15 echo "Retrieving dependencies for package Id: "$PACKAGE # Execute soql query to retrieve package dependencies in json format. RESULT_JSON=`sf data query -u $USER_NAME -t -q "SELECT Dependencies FROM SubscriberPackageVersion WHERE Id='$PACKAGE'" --json` # Parse the json string using python to test whether the result json contains a list of ids or not. DEPENDENCIES=`echo $RESULT_JSON | python -c 'import sys, json; print json.load(sys.stdin)["result"]["records"][0]["Dependencies"]'` # If the parsed dependencies is None, the package has no dependencies. Otherwise, parse the result into a list of ids. # Then loop through the ids to install each of the dependent packages. if [[ "$DEPENDENCIES" != 'None' ]]; then DEPENDENCIES=`echo $RESULT_JSON | python -c ' import sys, json ids = json.load(sys.stdin)["result"]["records"][0]["Dependencies"]["ids"] dependencies = [] for id in ids: dependencies.append(id["subscriberPackageVersionId"]) print " ".join(dependencies) '` echo "The package you are installing depends on these packages (in correct dependency order): "$DEPENDENCIES for id in $DEPENDENCIES do echo "Installing dependent package: "$id sf package install --package $id -u $USER_NAME -w $WAIT_TIME --publish-wait 10 done else echo "The package has no dependencies" fi # After processing the dependencies, proceed to install the specified package. echo "Installing package: "$PACKAGE sf package install --package $PACKAGE -u $USER_NAME -w $WAIT_TIME --publish-wait 10 exit 0; ``` # Schedule a Push Upgrade Using CLI Use Salesforce CLI commands to schedule, abort, or view details about your push upgrade requests. Push upgrades let you upgrade second-generation managed packages installed in subscriber orgs, without asking customers to install the upgrade themselves. The push upgrade feature is available to unlocked packages and second-generation managed packages only. To push a package upgrade for a second-generation managed package, that package must have already passed the AgentExchange security review. Push upgrades for unlocked packages are enabled by default. To enable push upgrades for your second-generation managed package, log a case with Salesforce Partner Support. To initiate a push upgrade for an unlocked or second-generation managed package, the Create and Update Second-Generation Packages user permission is required. There are several aspects to scheduling a push upgrade for a package. At a high-level these include: - Identifying the subscriber orgs and the org IDs that you want to upgrade - Scheduling the push upgrade - Tracking the progress and completion of the push upgrade In some scenarios you may also need to abort a scheduled push upgrade, or analyze errors that occurred. Let’s review each of these steps in more detail. **note:** Partners can also grant select customers the ability to block push upgrades by setting up customized push upgrades. See [Enable a Package Subscriber to Restrict Push Upgrades](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-customized.md) for more information. ## Determine the Orgs to Be Upgraded There isn't a dedicated `push-upgrade` CLI command for this action, instead let's look at how to use the CLI `data query` command. Push upgrades must be done in the context of the Dev Hub org that owns the package. To confirm the set of packages owned by a specific Dev Hub org, run the [`package list`](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_list_unified) command. Then [authorize to the Dev Hub org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_org_commands_unified.htm#cli_reference_org_login_web_unified) that is the owner of the package are upgrading. ```nolang sf org login web --set-default-dev-hub ``` If you're preparing to push a package upgrade, we assume your development environment is set up, if you aren't certain, review [Set Up Your Development Environment](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_pkg_dev_environment.htm). Here are three example queries you can use to retrieve a list of subscriber orgs that are eligible for a package upgrade. To review the possible fields that can be queried, see [PackageSubscriber](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagesubscriber.htm) in the _Object Reference for the Salesforce Platform_. Each query requires either a subscriber package ID (starts with 033), or a subscriber package version ID (starts with 04t). To retrieve the subsciber package ID, use the [package list](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_list_unified) command and specify the `--verbose` flag. To retrieve the subscriber package version ID, use the [package version list](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_version_list_unified) command. Query Example 1: Compile a list of all orgs that have a specific package installed. This query requires the subscriber package ID (starts with 033). ```nolang sf data query --target-org myDevHub --query "SELECT OrgKey, OrgName, OrgType, InstanceName, MetadataPackageId, MetadataPackageVersionId FROM PackageSubscriber WHERE MetadataPackageId = '033xxxxxxxxxxxxxxx'" --result-format json ``` If you copy and paste this query, update the target org and the subscriber package ID, before running the command. The target org is the Dev Hub org that owns the package. Specify either the username or alias for the Dev Hub org. Query Example 2: Compile a list of orgs that have a specific package version installed, and pipe that output to a CSV file. ```nolang sf data query --target-org myDevHub --query "SELECT OrgKey, OrgName, OrgType FROM PackageSubscriber WHERE MetadataPackageVersionId = '04t…'" --result-format csv ``` If you copy and paste this query, update the target org and the subscriber package version ID, before running the command. The target org is the Dev Hub org that owns the package. Specify either the username or alias for the Dev Hub org. This query returns as CSV file that you can use when scheduling the push upgrade. Before specifying the file in the `package push-upgrade schedule` command, remove the first line of the CSV file. The CSV file can contain one org ID per line only. Query Example 3: Compile a list of all orgs that have a package version lower than version 2.7 installed. This query requires two separate steps. **note:** A single package has both a package ID (starts with 0Ho) and a subscriber package ID (starts with 033). For part one of this two-part query, you must specify the 0Ho ID. If you run the `package list` command with the `--verbose` flag, you can determine both the 033 and 0Ho ID for a package. For more details on package IDs, see [Package IDs and Aliases for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_plan_pkg_types_pkg_ids.htm). First, query the [Package2Version](https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/tooling_api_objects_package2version.htm) object to find all versions of your package that are numerically lower than the specified version (2.7). ```nolang sf data query --target-org admin@packaging.com --use-tooling-api --query "SELECT SubscriberPackageVersionId FROM Package2Version WHERE Package2Id = '0HoPACKAGEIDxxxx' AND (MajorVersion < 2 OR (MajorVersion = 2 AND MinorVersion < 7))" ``` If you copy and paste this query, update the target org, the Package ID (starts with 0Ho), and the major and minor version before running the command. The target org is the Dev Hub org that owns the package. Specify either the username or alias for the Dev Hub org. Note the SubscriberPackageVersionId values (starts with 04t) returned by this query. Next, query the [PackageSubscriber](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagesubscriber.htm) object using the subscriber package version IDs (starts with 04t) from the previous step. ```nolang sf data query --target-org myDevHub --query "SELECT OrgKey FROM PackageSubscriber WHERE MetadataPackageVersionId IN ('04tID1', '04tID2', '04tID_etc')" --result-format csv >out.txt ``` If you copy and paste this query, update the target org and the subscriber package version IDs (starts with 04t) before running the command. The target org is the Dev Hub org that owns the package. Specify either the username or alias for the Dev Hub org. If you created a CSV file in this step and plan to use the file to schedule your push upgrade, you must remove the first line of the file so that it contains a list of org IDs only. ## Schedule a Package Push Upgrade After you have the org IDs for the subscribers you're upgrading, you can schedule the push upgrade. Review these examples of the flags you might include with the `package push-upgrade schedule` command. For more details on this command, see the [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_push-upgrade_schedule_unified). When scheduling a push upgrade you have a choice about how to specify the orgs you want upgraded. You can use either flag: - `--org-file` and provide a CSV file of all the orgs to be upgraded, or - `--org-list` and specify a comma-separated list of org IDs in the command line when you run the push upgrade CLI command If using a org file, it must contain one org ID per line only. Examples for package push-upgrade schedule Schedule a push upgrade that initiates at a specified time with a list of org IDs: ```nolang sf package push-upgrade schedule --package 04txyz --start-time "2024-12-06T21:00:00" --org-list 00DAxx, 00DBx ``` Schedule a push upgrade that initiates as soon as possible using a list of orgs in a CSV file: ```nolang sf package push-upgrade schedule --package 04txyz --org-file upgrade-orgs.csv ``` **note:** If you don't specify the `--start-time` flag, the push upgrade begins as soon as resources are available. When specfiying a start time, schedule during off peak hours. Specify start time in UTC. ## Retrieve Details about Scheduled Package Push Upgrades Use the `package push-upgrade list` or `package push-upgrade report` commands to retrieve details about push upgrades that have been scheduled or completed for a package. Examples for `package push-upgrade list`: List all package push upgrade requests for a specified package: ```nolang sf package push-upgrade list --package 033xyz --target-dev-hub myDevHub ``` List all package push upgrade requests for a specified package scheduled in the last 30 days: ```nolang sf package push-upgrade list --package 033xyz --scheduled-last-days 30 --target-dev-hub myDevHub ``` List all package push upgrade requests with a status of Failed. This status occurs if the push upgrade fails for one or more orgs. ```nolang sf package push-upgrade list --package 033xyz –-status Failed ``` List all package push upgrade requests with a status of Succeeded: ```nolang sf package push-upgrade list --package 033xyz –-status Succeeded ``` Generate a report about a specific push upgrade request: ```nolang sf package push-upgrade report --push-request-id 0DVxyz --target-dev-hub myDevHub ``` The `package push-upgrade list` command displays these fields: push request ID, package version ID, package version number, status of the push upgrade request, push upgrade request scheduled start date and time, the number of orgs scheduled for push upgrade, the number of orgs that were successfully upgraded, the number of orgs that failed to be upgraded, and push upgrade request created date and time. The `package push-upgrade report` command provides additional information, including error details. ## Cancel a Pending Package Push Upgrade Request If your push upgrade request has a status of either Created or Pending you can cancel the push upgrade by running the `package push-upgrade abort` command. To retrieve the status of your push upgrade request, run either `package push-upgrade list` or `package push-upgrade report`. To cancel a specified push upgrade request: ```nolang sf package push-upgrade abort --push-request-id 0DVxyz ``` ## Retrieve Error Messages for a Package Push Upgrade There isn't a dedicated push upgrade CLI command for this retrieving error message, instead let's look at how to use the CLI `data query` command. Use this example query to retrieve error messages stored in the [PackagePushError](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagepusherror.htm) object. Example: ```nolang sf data query --query "SELECT Id, PackagePushJobId, PackagePushJob.SubscriberOrganizationKey, ErrorDetails, ErrorMessage, ErrorSeverity, ErrorTitle, ErrorType FROM PackagePushError WHERE PackagePushJob.PackagePushRequestId='$PUSH_REQUEST_ID'" --target-org myDevHub ``` # Schedule a Push Upgrade Using SOAP API for First- and Second-Generation Managed Packages After you’ve created an updated version of your package, you can automatically deploy it to customers using a push upgrade. ## Before You Begin **note:** Partners can also grant select customers the ability to block push upgrades by setting up customized push upgrades. See [Enable a Package Subscriber to Restrict Push Upgrades](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-customized.md) for more information. For code samples and more detailed steps, see SOAP API object documentation linked in each step. 1. Authenticate to your [Dev Hub org](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_login.htm). 2. Query [MetadataPackage](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_metadatapackage.htm) to verify package details. 3. Query [MetadataPackageVersion](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_metadatapackageversion.htm) to verify the package version to use for the push upgrade. 4. Query [PackageSubscriber](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagesubscriber.htm) to retrieve details about subscriber orgs such as the org ID and installed package version. To retrieve information about more than 2,000 subscribers, use SOAP API [`queryMore()`](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_querymore.htm) call. 5. Create a [PackagePushRequest](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagepushrequest.htm) object. Specify the `PackageVersionId` and `ScheduledStartTime` (optional). If you omit the `ScheduledStartTime`, the push begins when you set the PackagePushRequest's status to `Pending`. 6. Create a [PackagePushJob](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagepushjob.htm) for each subscriber and associate it with the `PackagePushRequest` you created in the previous step. 7. Schedule the push upgrade by changing the status of the `PackagePushRequest` to `Pending`. ## Next Steps **note:** Scheduled push upgrades begin as soon as resources are available on the Salesforce instance, which is either at or after the start time you specify. In certain scenarios, the push upgrade could start a few hours after the scheduled start time. # Scheduling Push Upgrades After you’ve created an updated version of your package, you can automatically deploy it to customers using a push upgrade. | User Permissions Needed | | | ----------------------- | --------------------------- | | To push an upgrade: | Upload AppExchange Packages | 1. Push the upgrade to your own orgs so you can run tests and fix any bugs before upgrading subscribers. 2. When you’re ready and have coordinated with your customers on their change management process, push to a small number of customer organizations. Try sandbox organizations first, if possible. 3. After you’re comfortable with the initial results, push to your wider customer base, based on your agreements with each customer. 4. Deprecate the previous version of your package in your main development organization. Replace the version on AgentExchange if necessary, and update your Trialforce setup. 5. If your upgrade was a patch, after you’ve successfully distributed the upgrade to subscriber organizations, reintegrate those changes into your main development organization. For more information about combining patches in the main development organization, see [Working with Patch Versions](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-patches-about.md). **note:** Partners can also grant select customers the ability to block push upgrades by setting up customized push upgrades. See [Enable a Package Subscriber to Restrict Push Upgrades](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-customized.md) for more information. ## Schedule a Push Upgrade Using the UI **note:** Only first-generation managed packages can schedule a push upgrade using the UI. To schedule a push upgrade for unlocked and second-generation managed packages, use the [PackagePushRequest](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_packagepushrequest.htm) in the _Salesforce Object Reference_. 1. Log in to your main development org (not the patch org you used to upload the new version). 2. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 3. Click the name of the managed package whose upgrade you want to push. 4. On the package detail page, click the **Versions** tab, and then click **Push Upgrades**. 5. Click **Schedule Push Upgrades**. 6. Select a package version to push from the **Patch Version** dropdown list. **note:** Beta versions aren’t eligible for push. 7. For the scheduled start date, enter when you want the push upgrade to begin. **note:** Scheduled push upgrades begin as soon as resources are available on the Salesforce instance, which is either at or after the start time you specify. In certain scenarios, the push upgrade could start a few hours after the scheduled start time. 8. In the Select Target Organizations section, select the orgs to receive your push upgrade. If an org already received a push upgrade for the selected package version, it doesn’t appear in this list. You can select orgs by: - Entering a term that filters based on an org’s name or ID. Names can match by partial string, but IDs must match exactly. - Choosing between production and sandbox orgs from the **Organizations** dropdown list. - Choosing orgs that have already installed a particular version. - Clicking individual orgs or the **Select All** and **Deselect All** checkboxes. This section lists the following information about the org (in alphabetical order): |Field|Description| |-----|-----------| |Current Version|The current package version an organization has installed.| |Organization ID|The ID of the org.| |Organization Name|The name of the org. To view the upgrade history for the org, click the org name.| |Primary Contact|The name of the user who installed the package.| 9. Click **Schedule**. While a push upgrade is in progress, you can click Abort to stop it. ## Schedule a Push Upgrade Using the Enterprise API 1. Authenticate to your main development org (not the patch org you used to upload the new version). 2. Determine the package version you want to upgrade subscribers to by querying the MetadataPackageVersion object. 3. Gather the list of subscriber orgs that are eligible to be upgraded by querying the PackageSubscriber object. **note:** If you’re retrieving more than 2,000 subscribers, use SOAP API [`queryMore()`](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_querymore.htm) call. 4. Create a PackagePushRequest object. PackagePushRequest objects take a PackageVersionId and, optionally, a ScheduledStartTime parameter to specify when the push begins. If you omit the ScheduledStartTime, the push begins when you set the PackagePushRequest's status to `Pending`. 5. Create a PackagePushJob for each eligible subscriber and associate it with the PackagePushRequest you created in the previous step. 6. Schedule the push upgrade by changing the status of the PackagePushRequest to `Pending`. 7. Check the status of the PackagePushRequest and PackagePushJob objects by querying the Status fields. If the status is either Created or Pending, you can abort the push upgrade by changing the status of the PackagePushRequest to Canceled. You can’t abort a push upgrade that has a status of Canceled, Succeeded, Failed, or In Progress. **note:** If you’re pushing the upgrade to more than 2,000 subscribers, use the [Bulk_API](https://developer.salesforce.com/page/Bulk_API) to process the job in batches. For sample code and more details, see _SOAP API Developer Guide_. # Scratch Org Allocations for Salesforce Partners To ensure optimal performance, Salesforce partners are allocated a set number of scratch orgs in their Partner Business Org (PBO). These allocations determine how many scratch orgs you can create daily, and how many can be active at a given point. By default, Salesforce deletes scratch orgs and their associated ActiveScratchOrg records from your Dev Hub when a scratch org expires. All partners get 100 Salesforce Limited Access - Free user licenses. ## Active PBOs - 150 active - 300 daily ## Trial PBOs - 20 active - 40 daily ## Scratch Org Snapshot Allocations The number of snapshots you can create (active and daily) is the same as the active scratch org allocation. ## Package Version Creation Limits The maximum number of package versions you can create per day is equal to the daily allocated scratch orgs. For example, if you’re allocated 300 daily scratch orgs, you’re also allowed to create 300 package versions per day. If you specify `--skipvalidation` when creating a package version, the maximum number of package versions you can create using [skip validation](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_skip_validation.htm) is 500 per day. # Scratch Org Definition Files vs Org Shape in Package Development The scratch org definition file is used when you create scratch orgs, and also when you create new package versions. The scratch org definition file is a blueprint for your scratch org and defines the shape of the org you want for your package development work. ## Build Your Own Scratch Definition File If you read [How Scratch Orgs Fit in the Package Development Workflow](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-how-fit-pkg-dev.md) you might recall that the CLI command for creating scratch orgs includes a flag called `--definition-file`. ```nolang sf org create scratch --target-dev-hub MyHub --definition-file config/project-scratch-def.json ``` In this example, `project-scratch-def.json` is the scratch org definition file. To learn more about what can be specified in this definition file, see [Build Your Own Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) in the _Salesforce DX Developer Guide_. Similarly the CLI `--definition-file` flag can be used when creating a new package version. ```nolang sf package version create --package "Expenser App" --definition-file config/project-scratch-def.json --code-coverage ``` When used in the `package version create` command, the scratch org definition file is used to specify the features, settings, or limits that your package requires. ## When to Use Org Shape If you're developing managed packages to distribute on AgentExchange, we expect that you know what features and settings your packages depends on, and expect you to specify these requirements in a scratch org definition file. But there are scenarios like unlocked packages, or if you're moving from 1GP to 2GP package development, where using [Org Shape for Scratch Orgs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) can be useful. During org shape creation, we capture the features, settings, edition, licenses, and limits of the specified source org. By using org shape you don’t have to manually list these items in the scratch org definition file. **note:** The source org you use for org shape can’t be a sandbox or scratch org. Later when you create a package version, specify the org ID for the source org in the scratch org definition file. ```nolang { "orgName": "Acme", "sourceOrg": "00DB1230400Ifx5" } ``` For more detailed instructions on enabling and creating org shape, review [Create a Scratch Org Based on an Org Shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) in the _Salesforce DX Developer Guide._ If you’re moving from managed 1GP package development to 2GP package development, creating an org shape of your 1GP packaging org could be useful as you begin 2GP package development. Creating an org shape of your 1GP packaging org ensures that the features required for your package metadata are specified. **See Also** - [How Scratch Orgs Fit in the Package Development Workflow](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-how-fit-pkg-dev.md) - [_Salesforce DX Developer Guide_: Build Your Own Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) - [_Salesforce DX Developer Guide_: Create a Scratch Org Based on an Org Shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) - [_Salesforce DX Developer Guide_: Create a Scratch Org Based on an Org Shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) # Scratch Orgs and Package Development Scratch orgs are temporary Salesforce orgs intended for development and automation. They enable source-driven deployments of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with various features and preferences. | Availability | | ---------------------------------------------------------------------------------------- | | Available in: Lightning Experience | | Available in: **Developer**, **Enterprise**, **Performance**, and **Unlimited** Editions | You can use a scratch org to develop the app you want to package, and you can also create scratch orgs to test out your package. Scratch orgs also help with continuous integration (CI) processes to automate package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version into the scratch org, runs Apex tests, and emails the test results to the release manager. ## Enable Data Cloud for Scratch Orgs To use Data Cloud components in scratch orgs or to add these components to a package, Data Cloud for Scratch Orgs must be enabled. Log a case with [Salesforce Partner Support](https://partners.salesforce.com/) and request that Data Cloud for Scratch Orgs be enabled on your Partner Business Org. Data Cloud for Scratch Orgs is only available to scratch orgs associated with the Dev Hub in your Partner Business Org. - **[Get Access to Scratch Orgs That Have Agentforce](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/dev2gp-scratch-orgs-agentforce.md)** Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. Start your journey with Agentforce by testing it in a scratch org. - **[Scratch Org Allocations for Salesforce Partners](https://developer.salesforce.com/docs/platform/pkg1-dev/first-generation/isv-partner-scratch-org-allocations.md)** To ensure optimal performance, Salesforce partners are allocated a set number of scratch orgs in their Partner Business Org (PBO). These allocations determine how many scratch orgs you can create daily, and how many can be active at a given point. - **[Manage Scratch Orgs from the Dev Hub Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-scratch-orgs-view-lex.md)** You can view and delete your scratch orgs and their associated requests from the Dev Hub org. - **[Supported Scratch Org Editions for Partners](https://developer.salesforce.com/docs/platform/pkg1-dev/first-generation/isv-partner-scratch-org-editions.md)** Create partner edition scratch orgs from a Dev Hub partner business org. # Scratch Orgs and Package Development Scratch orgs are temporary Salesforce orgs intended for development and automation. They enable source-driven deployments of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with various features and preferences. | Availability | | ---------------------------------------------------------------------------------------- | | Available in: Lightning Experience | | Available in: **Developer**, **Enterprise**, **Performance**, and **Unlimited** Editions | You can use a scratch org to develop the app you want to package, and you can also create scratch orgs to test out your package. Scratch orgs also help with continuous integration (CI) processes to automate package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version into the scratch org, runs Apex tests, and emails the test results to the release manager. ## Enable Data Cloud for Scratch Orgs To use Data Cloud components in scratch orgs or to add these components to a package, Data Cloud for Scratch Orgs must be enabled. Log a case with [Salesforce Partner Support](https://partners.salesforce.com/) and request that Data Cloud for Scratch Orgs be enabled on your Partner Business Org. Data Cloud for Scratch Orgs is only available to scratch orgs associated with the Dev Hub in your Partner Business Org. - **[How Scratch Orgs Fit in the Package Development Workflow](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-how-fit-pkg-dev.md)** Scratch orgs are an essential tool in both developing and testing the app you want to package. Scratch orgs also help with continuous integration (CI) processes to automate package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version into the scratch org, runs Apex tests, and emails the test results to the release manager. - **[Scratch Org Definition Files vs Org Shape in Package Development](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-orgshape-vs-def-file.md)** The scratch org definition file is used when you create scratch orgs, and also when you create new package versions. The scratch org definition file is a blueprint for your scratch org and defines the shape of the org you want for your package development work. - **[When to Use Scratch Org Snapshots in Package Development](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-when-use-snapshot.md)** If the managed 2GP or unlocked package that you’re building depends on one or more large packages, it can take a long time for the package version creation CLI command to complete. Let’s talk about why that occurs, and how scratch org snapshots can dramatically reduce how long it takes to create a new package version. - **[Create a Package Version Based on a Scratch Org Snapshot](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-pkg-snapshot.md)** If the dependent package your base package requires is stable, you can reduce the end-to-end package version creation time by creating a scratch org snapshot. - **[Get Access to Scratch Orgs That Have Agentforce](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pd-dev2gp-scratch-orgs-agentforce.md)** Agentforce is a set of tools to create and customize AI agents that are deeply and securely integrated with customers' data and apps. Agentforce brings together humans with agents to transform the way work gets done. Start your journey with Agentforce by testing it in a scratch org. - **[Scratch Org Allocations for Salesforce Partners](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/isv-partner-scratch-org-allocations.md)** To ensure optimal performance, Salesforce partners are allocated a set number of scratch orgs in their Partner Business Org (PBO). These allocations determine how many scratch orgs you can create daily, and how many can be active at a given point. - **[Manage Scratch Orgs from the Dev Hub Org](https://developer.salesforce.com/docs/platform/pkg2-dev/sfdx-dev/scratch-orgs/sfdx-dev-scratch-orgs-view-lex.md)** You can view and delete your scratch orgs and their associated requests from the Dev Hub org. - **[Supported Scratch Org Editions for Partners](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/isv-partner-scratch-org-editions.md)** Create partner edition scratch orgs from a Dev Hub partner business org. # Second-Generation Managed Packages Second-generation managed packaging (managed 2GP) ushers in a new way for ISV partners to develop, distribute, and manage their apps and metadata. You can use managed 2GP packaging to organize your source, build small modular packages, integrate with your version control system, and better utilize your custom Apex code. With version control being the source of truth, there are no packaging or patch orgs. You can execute all packaging operations via Salesforce CLI, or automate them using scripts. Submit second-generation managed packages for security review, and list them on AgentExchange. Use managed 2GP to create new managed packages. You can’t currently migrate a first-generation managed package to a second-generation managed package. Another great way to learn about second-generation managed packages, is by taking the [Second-Generation Managed Packages](https://trailhead.salesforce.com/content/learn/modules/second-generation-managed-packages) Trailhead module. **note:** Second-generation managed packaging addresses the specific needs of ISV partners. If you’re a customer or system integrator and you don’t plan to distribute a package to multiple customers, unlocked packaging is the preferred tool. You can use unlocked packages to organize your existing metadata, package an app or extension, or package new metadata. See [Unlocked Packages](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) for more information. - **[What’s a Second-Generation Managed Package?](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-pkg-whats-a-package.md)** If your goal is to build an app and distribute it on AgentExchange, you’ll use managed packages to do both. Packaging is the container that you fill with metadata, and it holds the set of related features, customizations, and schema that make up your app. A package can include many different metadata components, and you can package a single component, an app, or library. - **[Set Up Your Development Environment](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-dev-environment.md)** Second-generation managed packaging uses Salesforce DX developer tools. Ensure that you have the required tools and orgs installed and enabled. - **[Before You Create Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-before.md)** When you use second-generation managed packaging, to be sure that you set it up correctly, verify the following. - **[Scratch Orgs and Package Development](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pd-dev-hub-intro.md)** Scratch orgs are temporary Salesforce orgs intended for development and automation. They enable source-driven deployments of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with various features and preferences. - **[Workflow for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-workflow.md)** You can create and install a second-generation managed package (managed 2GP) directly from the command line. - **[Components Available in Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/packaging-packageable-components.md)** Each metadata component that you include in a second-generation managed package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and installed. - **[Editable Properties After Package Promotion or Installation](https://developer.salesforce.com/docs/platform/pkg2-dev/metadata-components/mdc-editable-property-definitions.md)** Certain properties on metadata components are editable after the managed package is installed. - **[Behavior of Specific Metadata in Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-specific-md-details.md)** Learn how profiles and namespace visibility are handled for second-generation managed packages. - **[Develop Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev-2gp-developing-2gp-packages.md)** Ready to get started? Create your first second-generation managed package, and then update and create new versions of your package. - **[Install and Uninstall Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-install-upgrade.md)** Use a disposable scratch org to test your second-generation managed packages (managed 2GP). You can install or uninstall a managed 2GP package using a Salesforce CLI command, or from the Setup page. Because you can't upgrade a beta package version, be sure you don't install it in a sandbox that you use in your release pipeline, such as UAT or staging. - **[Prepare to Distribute Your Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-distribute-package.md)** Before you release a version of your second-generation managed package, ensure that you understand the code coverage requirements, release logistics, and how to publish your app on AgentExchange. - **[Push a Package Upgrade for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/push-upgrade-intro-2gp.md)** Push upgrades enable you to upgrade second-generation managed packages installed in subscriber orgs, without asking customers to install the upgrade themselves. You can choose which orgs receive a push upgrade, what version the package is upgraded to, and when you want the upgrade to occur. Push upgrades are helpful if you need to push a change for a hot bug fix. - **[Advanced Features for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-advanced-topics.md)** After you're comfortable with creating second-generation managed packages, learn about these advanced features to customize your package development processes. - **[Best Practices for Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-best-practices.md)** We suggest that you follow these best practices when working with second-generation managed packages. - **[Manage Licenses for Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/lma/lma-intro.md)** Use the License Management App (LMA) to manage leads and licenses for your AgentExchange solutions. By integrating the LMA into your sales and marketing processes, you can better engage with prospects, retain existing customers, and grow your ISV business. The LMA is a managed package that is installed in all partner business orgs (PBO) and includes custom objects that track details on packages, package versions, and licenses. - **[Manage Features in Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-fma/sfdx-dev-dev2gp-fma-manage-features.md)** Take the License Management App (LMA) a step further by extending it with the Feature Management App (FMA). - **[Get Started with AgentExchange App Analytics](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/appexchange/app-analytics/app-analytics-intro-2gp.md)** AgentExchange App Analytics provides usage data about how subscribers interact with your AgentExchange managed packages and packaged components. You can use these details to identify attrition risks, inform feature development decisions, and improve user experience. - **[Gaps Between First-Generation and Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-known-limitations.md)** The following functionality is supported in first-generation managed packaging, and not yet supported in second-generation managed packaging. We’re working to address these feature gaps. # Second-Generation Managed Packaging Keywords A keyword is a variable that you can use to specify a package version number. You can use keywords to automatically increment the value of the package build numbers, ancestor version numbers, set the package dependency to the latest version, or the latest released and promoted version. | Use the Keyword | Example | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | LATEST to specify the latest version of the package dependency when you create a package version. | See the example after this table. | | NEXT to increment the build number to the next available for the package version. If you don’t use NEXT, and you also forget to update the version number in your `sfdx-project.json` file, the new package version uses the same number as the previous package version. Although we don’t enforce uniqueness on package version numbers, every package version is assigned a unique subscriber package version ID (starts with 04t). | See the example after this table. | | RELEASED to specify the latest promoted and released version of the package dependency when you create a package version. | See the example after this table. | | HIGHEST to automatically set the package ancestor to the highest promoted and released package version number. Use only with ancestor version or ancestor ID. | See the example after this table. | | NONE in the ancestor version or ancestor ID field. Ancestry defines package upgrade paths. If the package ancestor is set to NONE, an existing customer can’t upgrade to that package version. | See the example after this table. | Example using LATEST: ```nolang "dependencies": [ { "package": "MyPackageName", "versionNumber": "0.1.0.LATEST" } ] ``` Example using NEXT: ```nolang "versionNumber": "1.2.0.NEXT" ``` Example using RELEASED: ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "2.1.0.RELEASED" } ] ``` Example using HIGHEST: ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorVersion": "HIGHEST" }, ``` Example using NONE: ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorVersion": "NONE" }, ``` # Security Policy Requirements Requirements: Before you list your solution on AgentExchange, you must have a security program that demonstrates your company’s commitment to security. Also, to help customers evaluate the quality of your solution, you must share your program info with them. Recommendations: We recommend including these elements in your program. ## Designate a Security Expert Protecting your solution from security threats is easier when you integrate security considerations into all stages of development. One of the best ways to ensure that your solution follows security guidelines is to designate a security expert on your development team. Have your entire development team collaborate with the security expert through all stages of development: design, implementation, and testing. Postponing security considerations until the final stages of development increases the likelihood that your team unknowingly propagates security violations as they code. Regular collaboration prevents needless accumulation of security violations and helps avoid delays in preparing a successful AgentExchange security review submission. ## Implement a Security Policy Build a corporate security policy that details how your company protects customer assets, such as user data. Inform the customer of the activities that they can do to help secure the solution from end to end. ## List Services and Artifacts List the services and artifacts included in your solution such as web and mobile solutions, web services, APIs, and SDKs. ## Inventory Third-Party Libraries Keep an inventory of the third-party libraries and the versions that are required for your solution to operate correctly. ## Create Architecture Diagrams Provide architecture diagrams that display data touch points, information flows, authentication, authorizations, and other security controls. ## List Certifications Share all applicable certification reports such as: - HIPAA: Health Insurance Portability and Accountability Act - PCI DSS: Payment Card Industry Data Security Standards - SOC 2: System and Organization Controls 2 criteria for managing customer data - ISO27001: Information security management ## Get a Third-Party Audit Have an independent third party conduct a security audit. Share the summary with your customers. ## Document Security-Assurance Activities Document company-level security-assurance activities including: - Software development lifecycle (SDLC) methodology - Vulnerability management - Remediation service-level agreements (SLAs) - Supplier and dependency security program - Security-awareness training - Security breach response procedures ## List Sensitive Data List all sensitive data that your solution processes or stores such as payment instrument data, personal data, and health data. ## Disclose Data Storage Locations and Providers If your solution stores or processes regulated data, such as personally identifiable data and health data, disclose a list of data storage locations. Identify countries and providers such as Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP). ## Identify Third-Party Data Sharing Provide a list of third-party suppliers that you share customer data with. ## Provide Security Contact Information for Salesforce All ISV partners must designate security leadership contacts in the [Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.html) and update these contacts whenever necessary to maintain accuracy and completeness. When you log in to the console, you’re prompted to provide contact information for your security leadership team, including names, email addresses, and phone numbers. Every six months, the console prompts you to review and confirm that these contacts are still accurate. We recommend using a distribution list or shared inbox to ensure continuity if team members change. To make sure you get our emails, avoid generic email usernames for your distribution lists. For example, security@example.com might get flagged as spam. A username like security+example@example.com is more likely to be delivered. For details, see [Role-Based Email Addresses](https://help.salesforce.com/s/articleView?id=mktg.pardot_admin_role_based_email_address.htm&type=5). Salesforce uses this information only for security incident response and related communications. This information isn’t posted publicly and is separate from the public contact info in the Share Contact Info section. To make updates to your security contacts at any time, go to Company Info in the Partner Console. ## Complete Security Review for Private Listings Apps or agents from AgentExchange must pass the [Salesforce security review](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-manage.html) to be installed. After your app is approved, the installation buttons are turned on automatically. Customers who try to install before the security review see a message explaining that installation is blocked until the security review is finished. This requirement only affects installation from AgentExchange listing pages. Preview functionality for your marketing team remains available. ## Share Contact Info Publish contact information so that it’s easy for customers to get support and report security incidents. # Security Requirements for ISV Partners and AgentExchange Solutions [Effective Date: August 9, 2023] As a Salesforce Partner, you’re responsible for implementing and maintaining a comprehensive security program and maintaining the security of all applications that you list on AgentExchange or distribute under the ISV Partner Program. **note:** These Security Requirements for ISV Partners and AgentExchange Solutions (“Requirements”) are current as of the listed effective date and remain in effect until or unless they’re superseded at this same or redirected URL by a version with a later effective date. SFDC updates or modifies these Requirements from time to time in its sole discretion, with or without notice. These Requirements are subject to and made part of the ISV Partner Program Policies and Salesforce Partner Program Agreement (“SPPA”) at [https://www.salesforce.com/company/legal/agreements/](https://www.salesforce.com/company/legal/agreements/). Capitalized terms not defined in these Requirements have the meaning given to them in the SPPA. **important:** Partner Applications, which includes managed packages, Salesforce Platform API solutions, Marketing Cloud Engagement API solutions, and other solutions referred to herein, are Non-SFDC Applications as defined in Salesforce’s Main Services Agreement (available at [https://www.salesforce.com/company/legal/agreements](https://www.salesforce.com/company/legal/agreements) or successor URL). Notwithstanding any security review of a Partner Application, Salesforce makes no guarantees regarding the quality or security of any Partner Application and Customers are responsible for evaluating the quality, security, and functionality of Partner Applications. As a condition of your participation in the ISV Partner Program, you must adhere to the security requirements outlined in this document. These requirements include general requirements applicable to all ISV Partners and Partner Applications, and additional requirements that are specific to Partner Applications that use or connect with specific technology or are intended for use in specific industries. In these requirements, Partner Applications are also referred to as “solutions.” When you create or edit an AgentExchange listing, you’re required to confirm that you complied with these requirements. The security requirements in this document aren’t exhaustive. We encourage Partners to follow all applicable industry security standards. ## General AgentExchange Requirements - All Partners must comply with the requirements described in [Security Policy Requirements](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-security-policy-requirements.md). - All Partner Applications must comply with the requirements described in [Prevent Secure Coding Violations](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-prevent-violations.md). - All Partner Applications must pass a Salesforce Security Review and Assessment where required under the ISV Partner Program Policies. ## B2C Commerce Solution Security Requirements If your Partner Application is a B2C Commerce Cartridge or Headless Integration, you must also follow the requirements described in [Secure Your B2C Commerce Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-b2c-commerce.md). These B2C Commerce specific requirements are in addition to the General AgentExchange Requirements. ## Tableau Accelerator Security Requirements If your Partner Application is a Tableau Accelerator, you must also follow the requirements described in [Secure Your Tableau Accelerator](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-tableau.md). These Tableau specific requirements are in addition to the General AgentExchange Requirements. ## Agentforce Security Requirements If your Partner Application is an Agentforce solution, you must also follow the requirements described in [Secure Your Agentforce Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-agentforce.md). These Agentforce specific requirements are in addition to the General AgentExchange Requirements. ## Connected App and External Client App Security Requirements If your Partner Application includes a Connected App and/or an External Client App (ECA), you must also follow the requirements described in [Secure Your Connected Apps and External Client Apps](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-ac-eca.md). These Connect App and ECA specific requirements are in addition to the General AgentExchange Requirements. ## Security Requirements Topics - [Security Policy Requirements](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-security-policy-requirements.md) - [Prevent Secure Coding Violations](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-prevent-violations.md) - [Secure Your B2C Commerce Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-b2c-commerce.md) - [Secure Your Tableau Accelerator](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-tableau.md) - [Secure Your Agentforce Solution](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-agentforce.md) - [Secure Your Connected Apps and External Client Apps](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-ac-eca.md) - [Secure Your Flow Connectors](https://developer.salesforce.com/docs/platform/isvforce/guide/secure-code-secure-your-flow-connectors.md) # Select an AgentExchange Listing Type Get started on your listing by selecting a listing type in the Partner Console. Your selection is used to customize the guided prompts and instructions in Listing Builder, the tool you use to create and edit your AgentExchange listings. It also determines if your listing appears on AgentExchange, the Salesforce marketplace for Agentforce solutions. ## Before You Begin To determine the correct listing type for your solution, review [AgentExchange Solution Types](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-solution-types.md). You can create three different types of listings: Packaged Solution, API, and Consultant listings. ![A screenshot of the first page where you select a listing type](https://developer.salesforce.com/docs/media/publish_bootstrapper_listing_type.png) ## Steps 1. Go to the Partner Console See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Listings**. 3. Click **New Listing**. 4. Select a listing type. Make sure you select the correct type. You can't change the listing type after it’s created. - To list a Salesforce managed package, select **Packaged Solution** | **Salesforce Platform Package**, then select a Platform package type: Salesforce App, Bolt Solution, Flow Solution, Lightning Component, or Agentforce Solution. If you select Agentforce Solution, your listing will appear on AgentExchange and [AgentExchange](https://agentexchange.salesforce.com/). - To list a B2C Commerce cartridge, select **Packaged Solution** | **B2C Commerce Cartridge**. - To list a Tableau Accelerator, select **Packaged Solution** | **Tableau Accelerator**. - To list an API solution, select **API**, then select an API type: Salesforce Platform API, Marketing Cloud Engagement API, or Headless Integration for B2C Commerce. - To create a listing for your consulting company, select **Consultant**. 5. Select a language. If you plan to publish the listing on [AgentExchange](https://appexchange.salesforce.com), select **English**. If you plan to publish on [AgentExchange Japan](https://appexchangejp.salesforce.com), select **Japanese**. ## Next Steps After you select a language, your listing is created, the Listing Builder launches, and you can edit your listing. **See Also** - [List Your Consulting Services on AgentExchange](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-list-consulting-services.md) # Select Business Needs for Your AgentExchange Solution When you create an AgentExchange listing for your solution, you select up to 3 categories called business needs. Business needs describe what your solution does or the challenge that it solves. Learn how business needs help customers discover AgentExchange solutions. Then review guidance for selecting business needs. ## Business Need Categories and Subcategories Business needs are divided into categories and subcategories. Categories align with general business processes or tasks. Examples include sales, service, and marketing. Each category contains one or more subcategories. Subcategories align with specific business processes or tasks that relate to the category. For example, in the sales category, there are subcategories for forecasting and contract management. In the AgentExchange Partner Console, you can select up to 3 business needs per AgentExchange listing. You can choose categories, subcategories, or some combination of the two. Your category and subcategory selections are independent. Selecting a category doesn’t add the related subcategories to your listing. Similarly, selecting a subcategory doesn’t add the related category to your listing. ## Example Appy’s Maps is a data visualization solution that customers can use to view Salesforce CRM data on open-source maps. Sarah, a marketing specialist at Appy’s Maps, chooses three business needs. Two business needs are subcategories: Sales Intelligence and Geolocation. The other business need is a category: Analytics (1). Category and subcategory selections are independent, so the subcategories related to Analytics remain deselected (2). ![The Business Needs combobox in the Partner Console with the Analytics category selected and related subcategories deselected.](https://developer.salesforce.com/docs/media/business_need_relationships.png) ## AgentExchange Listings and Business Needs Business needs appear as badges in the summary area of AgentExchange listings. These badges help customers understand whether a solution is likely to help them solve their challenge. They’re especially useful to customers who arrive at listings from sources outside AgentExchange, such as advertisements or third-party searches. ## Example Luis is a Salesforce consultant who’s designing a Sales Cloud implementation for a client. He plans to include a geolocation app in the implementation. He performs a Google search and sees the Appy’s Maps AgentExchange listing in the top results. When he visits the listing, he sees that Geolocation (1) is listed as a business need, and he’s impressed by the solution overview video. He contacts Appy’s Maps to arrange a live demo. ![The Appy's Maps listing with a callout on the Geolocation business need.](https://developer.salesforce.com/docs/media/business_needs_listing.png) ## AgentExchange Search and Business Needs Business needs are also available as filters for AgentExchange search results. These filters help customers focus on solutions that are relevant to the challenge they’re solving. When a customer applies a business need filter, its effect on search results depends on whether the filter is a category or subcategory. If the customer applies a subcategory filter, AgentExchange shows only the solutions that are tagged with that subcategory. If the customer applies a category filter, AgentExchange shows solutions that include the category and all of the related subcategories. ## Example Luis wants to benchmark Appy’s Maps against competing solutions. He performs a keyword search on AgentExchange and applies filters to narrow the results. He applies the Sales Cloud filter because he’s designing a Sales Cloud implementation. Then, he applies the Geolocation business need filter. Geolocation is a subcategory, so AgentExchange shows only the solutions tagged with Geolocation in the results. Luis identifies two alternatives to Appy’s Maps with this filter combination, but he hopes to find a few more. To widen the focus, he removes the Geolocation filter and applies the Analytics filter (1). Analytics is a category, so AgentExchange shows solutions tagged with Analytics along with the related subcategories, including Dashboards & Reports and Data Visualization. From these results, Luis identifies two more solutions to benchmark. ![The Business Need filter area of the AgentExchange search results page with a callout to the Analytics filter value.](https://developer.salesforce.com/docs/media/business_needs_search.png) ## Tips for Selecting Business Needs As you consider the business needs for your listing, follow these tips. |Tip|Details| |---|-------| |Talk to prospects and customers.|To understand the business needs of your target market, talk to your prospects and customers. When you speak to them, ask about:
  • Their top business goals or challenges
  • How they discovered your solution
  • Whether the business needs on your listing feel accurate
| |Experiment, then monitor the results.|You can update your listing’s business needs at any time. Try experimenting with different combinations of categories and subcategories. Take note of when you applied the changes, and then monitor the impact using AgentExchange Marketplace Analytics.| |If you can’t find a subcategory match, select the most closely related category.|The categories and subcategories in the Partner Console cover many, but not all, common business needs. If your solution addresses a business need that isn’t available in the Partner Console, choose the most closely related category. For example, if your solution assists with a specific process in the sales cycle, choose Sales.| # Sell on AgentExchange with Checkout Accept credit card payments and bank transfers directly from your listing with AgentExchange Checkout. Transform your sales and revenue data into insights and actions with the Checkout Management App. # Set Default Licensing for Your Managed Package If you set up the License Management App (LMA) and register your managed package, you receive a license record each time a customer installs your AgentExchange solution. You can use licenses to track who's using your solution and for how long. ## Before You Begin Before you register a package version, make sure that: - Your solution is in a managed package. - You installed the LMA. In most cases, the LMA is installed in your Partner Business Org. - You connected the org that has the LMA to the AgentExchange Partner Console. ## Steps 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Technologies** | **Solutions**. 3. Click a solution name to show the related versions. 4. Locate the package version that you want to register. 5. Confirm that you see Unregistered Package (1) in the Licenses column (2). **tip:** If you don’t see a Licenses column, it most likely means that the solution isn’t a managed package. You can register only managed packages. 6. Click **Register Package** (3). If the Register Package link is missing and you instead see Edit Licenses (4), the package is already registered and you’re done. ![A list of solutions on the Partner Console's Solutions tab with numbered callouts on the Licenses column ](https://developer.salesforce.com/docs/media/appexchange_register_licenses.png) 7. Follow the prompts to log in to the org where the LMA is installed. Provide a username and a password with a security token appended. For example, if the password is ABC and the token is 123, enter `ABC123`. Don’t remember your token? [Reset your security token](https://help.salesforce.com/articleView?id=user_security_token.htm&type=5). 8. Edit the default license settings. 1. Select whether your default license is **Free Trial** or **Active**. For a Free Trial license, enter a number up to 90 for the number of trial days. 2. Select whether your license is applied **Per seat** or **Site-wide**. For a per-seat license, enter the number of seats to assign to the license. 3. Save your changes. **See Also** - [*Second-Generation Managed Packaging Developer Guide:* Manage Licenses for Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_intro.htm) - [*Salesforce Help:* Reset Your Security Token](https://help.salesforce.com/articleView?id=user_security_token.htm&type=5) - [Connect Your Partner Business Org to the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-publish-organizations.md) # Set the Notification Email Address Specify which address to email when a package installation, upgrade, or uninstallation fails. Notifications are sent only for package versions that are uploaded after the address is added. For example, if you upload package version 1.0 and then set the notification address, notifications aren’t sent for failures related to version 1.0. Notifications start when version 2.0 is uploaded. Also, you can’t change or remove the notification email address for the package after it’s been uploaded. 1. To enable this feature, contact your Salesforce representative. 2. From Setup, enter `Packages` in the Quick Find box, then select **Packages**. 3. Click the package name, and then click **Edit** on the package detail page. 4. Enter the email address to send notifications to, and click **Save**. ![Notification Setting in a Partner Org](https://developer.salesforce.com/media/pkg1_dev/isvforce_partner_notifications_email.png "Notifications for Package Errors Configured in a Partner Org") # 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. Follow the steps here to allocate the Provider Free capacity to a Platform Cache partition before adding it to your managed package. **note:** If a Platform Cache partition is already part of your managed package, you can choose to edit the existing partition and allocate the Provider Free capacity to it. Create a partition from the Platform Cache page and then set it up to use the Provider Free capacity 1. From Setup, in the Quick Find box, enter `Platform Cache`, and then select **Platform Cache**. As the Provider Free capacity is automatically enabled in all Developer edition orgs, the Org’s Capacity Breakdown donut chart shows the Provider Free capacity. 2. Click **New Platform Cache Partition**. 3. In the Label box, enter a name for the partition. The name can contain alphanumeric characters only and must be unique in your org. 4. In the Description box, enter an optional description for the partition. 5. In the Capacity section, allocate separate capacities for session cache and org cache from the available Provider Free capacity. 6. Save the new Platform Cache partition. ## Result You can add this new Platform Cache partition to your managed package. When a security-reviewed managed package with Platform Cache partition is installed on the subscriber org, the Provider Free capacity is allocated and automatically made available to the installed partition. The managed package can start using the Platform Cache partition; no post-install script or manual allocation is required. **note:** If the managed package is not AgentExchange-certified and security-reviewed, the Provider Free capacity resets to zero and will not be allocated to the installed Platform Cache partition. When a Platform Cache partition with Provider Free capacity is installed in a subscriber org, the Provider Free capacity allocated is non-editable. The provider free capacity of one installed partition can’t be used for any other partition. **tip:** After you install a Platform Cache partition with Provider Free capacity, you can edit the partition and make additional allocations from the available platform cache capacity of the org. # Set Up Feature Parameters Set up the Feature Management App in your License Management Org, define feature parameters, and add them to your package. - **[Install and Set Up the Feature Management App in Your License Management Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-install.md)** Install the FMA in your LMO. Then add the Feature Parameters tab to your default view, and adjust your page layout for licenses to display related lists for your feature parameters. - **[Create Feature Parameters in Your Packaging Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-create-feature-parameters.md)** Create a feature parameter in your packaging org, and set its type, default value, and data flow direction. - **[Add Feature Parameters to Your Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-add-feature-parameters-to-package.md)** After you’ve created some feature parameters, you can add them to a managed package as components and reference them in your code. Feature parameters aren’t available in unmanaged packages. # Set Up Feature Parameters Set up the Feature Management App in your License Management Org, define feature parameters, and add them to your package. - **[Install and Set Up the Feature Management App in Your License Management Org](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/fma-install.md)** Install the FMA in your LMO. Then add the Feature Parameters tab to your default view, and adjust your page layout for licenses to display related lists for your feature parameters. - **[Create Feature Parameters for Your Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/second-generation/sfdx-fma/sfdx-dev-dev2gp-fma-create-feature-parameters.md)** To create a feature parameter for a 2GP managed package, create an individual XML file. Here are details on the file naming convention, folder structure, and the attributes you use when creating feature parameters. # Set Up Your Development Environment Second-generation managed packaging uses Salesforce DX developer tools. Ensure that you have the required tools and orgs installed and enabled. You use these tools for managed 2GP package development. - [Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm), a rich set of commands to execute different packaging operations like package creation and package install - A source control system of your choosing - A Dev Hub org - [Salesforce Extension for Visual Studio Code](https://developer.salesforce.com/tools/vscode/en/vscode-desktop/install) (optional), an IDE designed to facilitate the development of Salesforce components ## Use the Dev Hub to Keep Track of Package Development Your Dev Hub is the designated place to find and manage all your managed 2GP packages, scratch orgs, and namespaces. After you enable the Dev Hub setting on a Salesforce org, that Dev Hub becomes the owner of every managed 2GP package you create. All Salesforce ISV and OEM partners should designate their Partner Business Org as their Dev Hub org. A Partner Business Org (PBO) is the production org where Salesforce Partners run their business. - **[Enable Dev Hub and Second-Generation Managed Packaging](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-enable-devhub.md)** The Dev Hub lets you create and manage second-generation managed packages and scratch orgs. Your Dev Hub is the designated place to find and manage all your managed 2GP packages, scratch orgs, and namespaces. - **[Limited Access License for Package Developers](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-slalf-pkg-dev.md)** The Salesforce Limited Access - Free is designed for users whose role is to build customizations or applications. This license provides access to the Dev Hub, development tools, and environments. In the production org, this license restricts access to standard and custom objects. Partner Business Orgs (PBO) include 100 Salesforce Limited Access - Free user licenses. - **[Add a Limited Access User to Your Dev Hub Org](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-add-free-license-user.md)** Provide your developers access to the Dev Hub and Salesforce DX development tools by adding a user with Salesforce Limited Access - Free license and the Limited Access user profile in your Dev Hub org. Then create and assign them a permission set to the required Dev Hub objects. - **[Assign Second-Generation Managed Packaging User Permissions](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-pkg-user-permission.md)** To create second-generation managed packages and scratch orgs, developers require access to the Dev Hub org. We recommend enabling the Dev Hub in your Partner Business Org (PBO). A Salesforce admin can create a permission set to grant appropriate permissions to the required Dev Hub objects and system permission. # Share Release Notes and Post-Install Instructions for Second-Generation Managed Packages Share details with your subscribers about what’s new and changed in a released second-generation managed package. You can specify a release notes URL to display on the package detail page in the subscriber’s org. And you can share instructions about using your package by specifying a post install URL. The release notes and post install URLs display on the Installed Packages page in Setup, after a successful package installation. For subscribers who install packages using an installation URL, the package installer page displays a link to release notes. And subscribers are redirected to your post install URL following a successful package installation or upgrade. Specify the `postInstallUrl` and `releaseNotesUrl` attributes in the `packageDirectories` section for the package. ```nolang "packageDirectories": [ { "path": "expenser-schema", "default": true, "package": "Expense Schema", "versionName": ""ver 0.3.2"", "versionNumber": "0.3.2.NEXT", "postInstallScript": "PostInstallScript", "uninstallScript": "UninstallScript", "postInstallUrl": "https://expenser.com/post-install-instructions.html", "releaseNotesUrl": "https://expenser.com/winter-2020-release-notes.html" }, ], { "namespace": "db_exp_manager", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "47.0", "packageAliases": { "Expenser Schema": "0HoB00000004CzHKAU", "Expenser Schema@0.1.0-1": "04tB0000000719qIAA" } ``` You can also use the `--post-install-url` and the `--release-notes-url` Salesforce CLI parameters with the `sf package version create` command. The CLI parameters override the URLs specified in the `sfdx-project.json` file. # Show Accessibility Details on Your AgentExchange Listing If you built your AgentExchange solution with accessibility in mind, tell customers by adding the Accessible Solution badge to your listing. When you add the badge to your listing, you also provide a link to your solution’s accessibility conformance report. For example, you can link to a copy of a Web Content Accessibility Guidelines (WCAG) 2.1 report. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**. 4. Select an existing listing, or create one. 5. Click **Fill in the Basics**. 6. For Equality, select the **Accessible solution** option, and then provide the URL of your accessibility conformance report. 7. Click **Save & Exit**. ## Next Steps After you publish your listing, the Accessible Solution badge (1) appears on the More Details tab in the Supported Features section. When a customer clicks **View Report** (2), AgentExchange opens your accessibility conformance report in a new browser tab. ![The More Details tab on an AgentExchange listing with a callout on the Accessible Solution badge and another callout on the View Report link](https://developer.salesforce.com/docs/media/appexchange_publish_accessibility_badge.png) # Show Diverse-Owned Business Details on Your AgentExchange Listing If your company is at least 51% owned or operated by members of one or more of these groups—women, veterans, minorities, person(s) with disability(ies), and the LGTBQ community—tell customers by adding the diverse-owned badge to your listing. When you add the badge to your listing, you also provide a link to your company’s certification, such as a National Minority Supplier Development Council (NSMDC) certificate. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**. 4. Select an existing listing, or create one. 5. Click **Fill in the Basics**. 6. For Equality, select the **Diverse-owned business** option, and then provide the URL of your certification. 7. Click **Save & Exit**. ## Next Steps After you publish your listing, the Diverse-owned badge (1) appears on the Overview tab in the Social Impact section. When a customer clicks **View Certification** (2), your certificate opens in a new browser tab. ![The Overview tab on an AgentExchange listing with a callout on the Diverse-Owned Business badge and another callout on the View Certification link](https://developer.salesforce.com/docs/media/appexchange_publish_diverse_owned_badge.png) # Show Pledge 1% Details on Your AgentExchange Listing If your company is a member of the Pledge 1% movement, let customers know by adding the Pledge 1% badge to your listing. Pledge 1% members commit to giving a percentage of their product, profit, equity, or time to nonprofit causes or charities. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To create or update AgentExchange listings:|Manage Listings| Pledge 1% is a global movement that encourages and enables companies of all sizes and stages to give back. To learn more and join the movement, go to the [Pledge 1% website](https://pledge1percent.org/). ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**. 4. Select an existing listing, or create one. 5. Click **Fill in the Basics**. 6. For Philanthropy, select **Pledge 1% participant**. 7. Click **Save & Exit**. ## Next Steps After you publish your listing, the Pledge 1% badge (1) appears on the Overview tab in the Social Impact section. ![The Overview tab on an AgentExchange listing with a callout on the Pledge 1% badge](https://developer.salesforce.com/docs/media/appexchange_publish_pledge_1percent_badge.png) # Showcase Your Competencies AgentExchange displays a **Competencies** tab on your consultant listing. This tab shows customers your verified skills across industries and products. ## What Customers See The Competencies tab displays your data in two views, Industry and Product, with these columns: - **Competency Level**—Your achievement, Expert or Accredited, calculated by the Partner Program. - **Eligible Projects**—Number of eligible projects in this competency area. - **Average CSAT**—Customer satisfaction scores from completed engagements. - **Certifications**—Number of individual certifications held by your team’s certified professionals in this area. ## How Competencies Are Calculated You don’t enter competency data manually. The Partner Program calculates it based on: - Registered project work you’ve completed and verified. - Certifications held by your team members. - Customer satisfaction scores from completed project surveys. To review the data displayed on your listing, log in to the Salesforce Partner Community and check your Partner Program dashboard. If something looks wrong, contact your Partner Account Manager (PAM). **note:** Displaying competency calculations transparently is a legal requirement. You have the right to understand how your data is calculated and presented to customers. # Sign the Partner Application Distribution Agreement If your solution uses AgentExchange Checkout as its payment management system, you must read and digitally sign the clickthrough Partner Application Distribution Agreement. ## Before You Begin This process assumes that your solution’s listing has been approved. If your solution uses AgentExchange Checkout as its payment management system, follow these instructions. ## Steps 1. To launch the Partner Application Distribution Agreement (PADA), click **Sign Agreement**. ![The AgentExchange Listing Builder Get Approved step with an Approval Status banner, and Submit, Back, and Next buttons](https://developer.salesforce.com/docs/media/sign_agreement.png) 2. Read and complete the PADA. 1. Select the checkbox that states that you’re authorized to sign this agreement. 2. Select the checkbox that indicates that you accept the agreement. 3. To finish digitally signing the agreement, click **Agree**. # Single Sign-on in the Environment Hub Developing, testing, and deploying apps means switching between multiple Salesforce environments and providing login credentials each time. Single sign-on (SSO) simplifies this process by letting an Environment Hub user log in to member orgs without reauthenticating. You can set up SSO by defining user mappings manually, using Federation IDs, or creating a formula. |Required Editions| |-----------------| |Available in: both Salesforce Classic ([not available in all orgs](https://help.salesforce.com/s/articleView?id=xcloud.overview_edition_lex_only.htm&type=5)) and Lightning Experience| |Available in: **Enterprise**, **Performance**, and **Unlimited** Editions| The Environment Hub supports these SSO methods for matching users. |SSO Method|Description| |----------|-----------| |Mapped Users|Match users in the Environment Hub to users in a member org manually. Mapped Users is the default method for SSO user mappings defined from the member detail page.| |Federation ID|Match users who have the same Federation ID in both the Environment Hub and a member org.| |User Name Formula|Match users in the Environment Hub and a member org according to a formula that you define.| If you specify multiple SSO methods, they’re evaluated in this order: (1) Mapped Users, (2) Federation ID, and (3) User Name Formula. The first method that results in a match is used to log in the user, and the other methods are ignored. If a matching user can’t be identified, the Environment Hub directs the user to the standard Salesforce login page. **note:** SSO doesn’t work for newly added users or for user mappings defined in a sandbox org. Only add users, edit user information, or define SSO user mappings in the parent org for the sandbox. # Small-Sized Partners Small-sized partners have manageable subscriber bases and one or two managed packages. A small partner’s total daily usage data across all managed packages is 5 GB or less. Also, small partner’s queries complete well under the 15-minute processing time limit. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | Given how manageable smaller partners’ data is, after you run your regular queries one time, we recommend that you run a daily catch-up query as your main query. Sweep in all data for all your managed packages for the last 30 days. | Data Type | How to Get Started | How to Schedule Catch-Up Queries | | ----------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscriber Snapshots | An initial query to retrieve data from when App Analytics was enabled for your managed package. |
  • One daily catch-up query.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to 30 days ago.
  • Omit `EndTime`.
  • Each day advance `StartTime` and `AvailableSince` by 1 day.
| | Package Usage Summaries | An initial query to retrieve data from when App Analytics was enabled for your managed package. |
  • One daily catch-up query.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to the first of the previous month.
  • Omit `EndTime`.
  • Each day advance `AvailableSince` by 1 day.
  • Each month advance `StartTime` to the first of the previous month.
| | Package Usage Logs | An initial query to retrieve data from when App Analytics was enabled for your managed package. |
  • One daily catch-up query.
  • Set `AvailableSince` to the day and time your last regular query ran.
  • Set `StartTime` to 30 days ago.
  • Omit `EndTime`.
  • Each day advance `StartTime` and `AvailableSince` by 1 day.
| ## Example Most of your customers use your package on an NA or EU instance, so you run your queries at `18:00 UTC`. You have a couple customers on an AP instance, so you create catch-up queries to ensure that you capture data from around the world. - On March 31 at `18:00 UTC`, run your regular queries. Subscriber Snapshot ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=SubscriberSnapshot FileType=csv FileCompression=gzip StartTime=2020-03-30T00:00:00Z EndTime=2020-03-31T00:00:00Z" ``` Package Usage Summary ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageSummary FileType=csv FileCompression=gzip StartTime=2020-02-01T00:00:00Z EndTime=2020-03-01T00:00:00Z" ``` Package Usage Log ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageLog FileType=csv FileCompression=gzip StartTime=2020-03-30T00:00:00Z EndTime=2020-03-31T00:00:00Z" ``` - On April 1 at `18:00 UTC` run these three catch-up queries. Subscriber Snapshot Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=SubscriberSnapshot FileType=csv FileCompression=gzip StartTime=2020-03-02T00:00:00Z AvailableSince=2020-03-31T18:00:00Z" ``` Package Usage Summary Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageSummary FileType=csv FileCompression=gzip StartTime=2020-03-01T00:00:00Z AvailableSince=2020-03-31T18:00:00Z" ``` Package Usage Log Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageLog FileType=csv FileCompression=gzip StartTime=2020-03-02T00:00:00Z AvailableSince=2020-03-31T18:00:00Z" ``` - On April 2 at `18:00 UTC`, run the same catch-up queries, but advance the subscriber snapshot and package usage log `AvailableSince` and `StartTime` date by 1 day each. Advance the package usage summary `AvailableSince` by 1 day. Subscriber Snapshot Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=SubscriberSnapshot FileType=csv FileCompression=gzip StartTime=2020-03-03T00:00:00Z AvailableSince=2020-04-01T18:00:00Z" ``` Package Usage Summary Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageSummary FileType=csv FileCompression=gzip StartTime=2020-03-01T00:00:00Z AvailableSince=2020-04-01T18:00:00Z" ``` Package Usage Log Catch-Up Query ```nolang sf data create record --sobjecttype AppAnalyticsQueryRequest --values "DataType=PackageUsageLog FileType=csv FileCompression=gzip StartTime=2020-03-03T00:00:00Z AvailableSince=2020-04-01T18:00:00Z" ``` # Specify a Package Ancestor in the Project File for a Second-Generation Managed Package When you create a second-generation managed package version you specify a package ancestor in your `sfdx-project.json` file. We require that the package ancestor you specify is the highest promoted package version number for that package. You can either update the ancestor version number each time you create a package version, or you can use a keyword. Here are three different ways to set the package ancestor. ## Use the HIGHEST Keyword (Recommended) Use the keyword HIGHEST with either the `ancestorId` or `ancestorVersion` attribute in the `sfdx-project.json` file. This keyword automatically sets the ancestor to the highest promoted package version number. ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorVersion": "HIGHEST" }, ``` This keyword makes it easy to set your package ancestor to use linear versioning, until you have a reason to break from linear versioning. ## Use the Ancestor Version Attribute Set the `ancestorVersion` attribute in the `sfdx-project.json` file to the package version’s major.minor.patch number. This approach requires you to update the ancestor version number every time the major, minor, or patch value changes. ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorVersion": “4.6.0” }, ``` ## Use the Ancestor ID Attribute Set the `ancestorId` attribute in the `sfdx-project.json` file to either the 04t ID or the package version’s alias. This approach requires you to update the ancestor version number every time you create a package version. ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorId": "04tB0000000cWwnIAE" }, ``` ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorId": "expense-manager@4.6.0.1" }, ``` **note:** Only package versions that have been promoted to managed-released state, can be listed as an ancestor. ## Override Linear Package Ancestry Behavior To break from linear package versioning, specify a package ancestor that isn’t the highest promoted package version and use the Salesforce CLI parameter `--skip-ancestor-check` when you create a package version. ```nolang sf package version create --package "Expenser App" --skip-ancestor-check ``` The CLI parameter indicates that you’re intentionally choosing to specify a package version that isn’t the highest promoted package version. You can choose to not specify a package ancestor by using the keyword, NONE, with either the `ancestorId` or `ancestorVersion` attribute in the `sfdx-project.json` file. ```nolang "packageDirectories": [ { "path": "util", "package": "Expense Manager - Util", "versionNumber": "4.7.0.NEXT", "ancestorVersion": "NONE" }, ``` Because package ancestors determine package upgrade paths, existing customers can’t upgrade to a package version that is created without a specified ancestor. Use NONE if you don’t plan to promote the package version you’re creating. If you’ve already promoted a previous package version, and you set the ancestor to NONE on a new package version associated with the same package, include `--skip-ancestor-check` when you create that package version. When you create your first package version, you can also set the ancestor to NONE and specify `--skip-ancestor-check`. ## What to Remember about Package Ancestry - Package ancestry determines whether existing packages can be upgraded to newer package versions. If you’re breaking from linear versioning, or plan to abandon a package version that is installed in customer orgs, consider how your existing customers will be impacted, and whether an upgrade path is available to them. - If you abandon a package version, delete the version using the Salesforce CLI command `sf package version delete`. If you aren’t able to delete the package version, then update the package version’s installation key so the abandoned package version can’t be inadvertently installed. Use `sf package version update` to update the installation key. # Specify AgentExchange Listing Fundamentals Create a listing that helps customers determine whether your solution or service fits their requirements. Describe key differentiators. Identify specifications and features. Add AI details to your Agentforce listings. Use business needs to make it easier for customers find your AgentExchange solution listing. Let customers know how your AgentExchange business drives positive social change. # Specify Dependencies on Unpackageable Metadata It’s possible that the managed 1GP package you’re converting includes tests or references to unpackageable metadata. To ensure your package conversion is successful, references to unpackageable metadata must be specified in your [project configuration file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev2gp_config_file.htm). If you followed the steps in [Convert Your Managed 1GP Package to 2GP](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_conversion_workflow.htm), you created a Salesforce DX project in step three. When you create a Salesforce DX project, the project configuration file (`sfdx-project.json`) is automatically created. If you think you may have these kinds of references, review [Specify Unpackaged Metadata for Package Version Creation Tests](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_unpackaged_md.htm) and [Reference Standard Value Sets by Specifying a Seed Metadata Directory.](https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_standard_value_sets.htm&release=244&type=5) In [Migrating Your Subscribers from 1GP to 2GP](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_pkg_migration_workflow.htm), we share when in the conversion workflow to specify unpackageable metadata. # Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages For scenarios where you require metadata that isn’t part of your second-generation managed package, but is necessary for Apex test runs, you can specify the path containing unpackaged metadata in the `sfdx-project.json` file. The unpackaged metadata isn’t included in the package and isn’t installed in subscriber orgs. ## Specify Unpackaged Metadata for Package Version Creation Tests Specify the path to the unpackaged metadata in your `sfdx-project.json` file. In this example, metadata in the `my-unpackaged-directory` is available for test runs during the package version creation of the TV_unl package. ```nolang "packageDirectories": [ { "path": "force-app", "package": "TV_unl", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "default": true, "unpackagedMetadata": { "path": "my-unpackaged-directory" } }, ] ``` The `unpackagedMetadata` attribute is intended for metadata that isn’t part of your package. You can’t include the same metadata in both an unpackaged directory and a packaged directory. ## Manage Apex Access for Package Version Creation Tests Sometimes the Apex tests that you write require a user to have certain permission sets or permission set licenses. Use the `apexTestAccess` setting to assign permission sets and permission set licenses to the user in whose context your Apex tests get run at package version creation. ```nolang "packageDirectories": [ { "path": "force-app", "package": "TV_unl", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "default": true, "unpackagedMetadata": { "path": "my-unpackaged-directory" }, "apexTestAccess": { "permissionSets": [ "Permission_Set_1", "Permission_Set_2" ], "permissionSetLicenses": [ "SalesConsoleUser" ] } }, ] ``` **note:** To assign user licenses, use the [runAs Method](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_tools_runas.htm). User licenses can't be assigned in the `sfdx-project.json` file. # Specifying a Post Install Script After you’ve created and tested the post install script, you can specify it in the **Post Install Script** lookup field on the Package Detail page. In subsequent patch releases, you can change the contents of the script but not the Apex class. The class selection is also available via the Metadata API as `Package.postInstallClass`. This is represented in package.xml as a `foo` element. # Specifying a Post Install Script After you’ve created and tested the post install script, you can specify it in the **Post Install Script** lookup field on the Package Detail page. In subsequent patch releases, you can change the contents of the script but not the Apex class. The class selection is also available via the Metadata API as `Package.postInstallClass`. This is represented in package.xml as a `foo` element. **See Also** - [Customize Second-Generation Managed Package Installs and Uninstalls Using Scripts](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_customize_installs.htm) # Specifying an Uninstall Script After you’ve created and tested the uninstall script and included it as a member of your package, you can specify it in the **Uninstall Script** lookup field on the Package Detail page. In subsequent patch releases, you can change the contents of the script but not the Apex class. The class selection is also available via the Metadata API as `Package.uninstallClass`. This is represented in package.xml as an `foo` element. # Submit Your AgentExchange Listing for Approval Before you can publish your listing, we must make sure that it complies with our partner brand guidelines and partner program policies. In the AgentExchange Partner Console, provide some basic information, set up your solution pricing, and then submit your listing for approval. ## Before You Begin This process assumes that you have an AgentExchange listing in progress in the Partner Console. It also assumes that you’ve completed the Fill in the Basics and Price Your Solution steps. ## Steps 1. From your listing in the Partner Console, click **Set Pricing**. 2. Click **Get Approved**. 3. Click **Submit** (1). ![The Get Approved Listing Builder step with Submit (1), Next, and Back buttons](https://developer.salesforce.com/docs/media/ready_to_submit1.png) 4. Click **Save & Submit** (2). ![The Save listing and submit for approval? window with Cancel and Save & Submit buttons](https://developer.salesforce.com/docs/media/save_submit2.png) Your listing is in review. To check its approval status, return to your listing’s Get Approved step. 5. In the meantime, to continue working on your listing, click **Next** (3). ![The AgentExchange Listing Builder Get Approved step with an Approval Status banner, and Submit, Back, and Next buttons](https://developer.salesforce.com/docs/media/ready_to_submit3.png) ## Next Steps If your solution uses AgentExchange Checkout as its payment management system, you must read and digitally sign a clickthrough Partner Application Distribution Agreement. If your listing is a Paid solution that doesn't use Checkout, or if you’re listing a Freemium or Paid Add-On Required solution, contact your Account Manager to sign a PADA offline, outside of the Partner Console. **See Also** - [Get To Know the AgentExchange Listing Builder](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-listing-builder-overview.md) # Subscriber Snapshots Subscriber snapshots give you a point-in-time summary of subscriber activity. Use subscriber snapshots to see usage trends by org and package. **note:** AgentExchange App Analytics is subject to certain usage restrictions, as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). AgentExchange App Analytics takes a daily snapshot of org, package, and custom entity data. Snapshots are captured daily at 00:00 UTC and become available for download immediately. You request a date and time, or range of dates and times, and you receive one snapshot per valid date and time requested. For example, if on April 7, 2023 you request a date and time range of `StartTime=2023-04-04T00:00:00Z EndTime=2020-04-07T00:00:00Z`, you receive three snapshots, one for each completed day. | Field | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | attribute_name | Represents a characteristic of a custom entity, managed package, package version, or org. Example: `UsersWithMFA` | | attribute_value | A string that represents a characteristic or measure of an `attribute_name`. Examples:
  • `0.570`
  • `1.000`
  • `Acme, Inc.`
  • `Active`
  • `Deprecated`
| | count | Total records for the custom entity in that org on the specified snapshot date. | | custom_entity | The developer name of the component or custom object. Examples:
  • `Amount`
  • `Travel_Expense`
| | date | The subscriber snapshot date requested, in `YYYY-MM-DDT00:00:00Z` format. Each point-in-time snapshot is captured at `00:00 UTC` on the date specified. Example: `2023-04-04T00:00:00Z` | | managed_package_namespace | Namespace of the package. Example: `sfdx_isv_pkg001` | | organization_edition | The name of the Salesforce edition the subscriber org is using. Examples:
  • `Developer Edition`
  • `Enterprise Edition`
  • `Unlimited Edition`
| | organization_id | The 15-character ID of the subscriber org. Example: `00D4m000000Td8Y`. | | organization_name | The name of the subscriber org. Example: `My_Org`. | | organization_status | The paid status of the subscriber org. Examples:
  • `ACTIVE`
  • `DEMO`
  • `FREE`
  • `TRIAL`
| | package_id | The ID of the managed package. Example: `033xx00000000CI`. | | package_version_id | The ID of the managed package version. Example: `04t6A0000004eytQAA`. | The `attribute_name` and `attribute_value` fields are a `key-value` pair. Each pair has a specific scope. Some pairs provide org-level metadata, and others provide custom entity, managed package, or package version metadata, Interpret these two fields in tandem using the information in this table. **note:** As of Spring ’25, trial orgs aren’t included in subscriber snapshot MFA data. | attribute_name | Description | attribute_value | Scope | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `UsersWithMFA` | Represents the percentage of your unique, standard users who enabled multi-factor authentication (MFA) using one of these methods.
  • User permission sets
  • Profile permission sets
  • High-assurance session security level
The corresponding `attribute_value` is always between 0 and 1, where 0 represents 0% and 1 represents 100%. | Percent Examples:
  • 0.060
  • 0.940
| Org-level. For all packages installed into an active or demo org, the same org-level `UsersWithMFA` percent repeats on every package version row. | # Supported Scratch Org Editions for Partners Create partner edition scratch orgs from a Dev Hub partner business org. Supported partner scratch org editions include: - Partner Developer - Partner Enterprise - Partner Group - Partner Professional Indicate the partner edition in the scratch org definition file. ```nolang "edition": "Partner Enterprise", ``` If you attempt to create a partner scratch org and see this error, confirm that you’re using an active partner business org. Contact the [Partner Community](https://partners.salesforce.com/) for further assistance. ```nolang ERROR: You don't have permission to create Partner Edition organizations. To enable this functionality, please log a case in the Partner Community. ``` License limits for partner scratch orgs are similar to partner edition orgs created in Environment Hub. Get the details on the [Partner Community](https://partners.salesforce.com/s/education/general/Partner_Orgs). # Supporting Multiple Editions Using an Extension Package This approach uses a base-managed package that contains core app functionality. The base package only contains features supported in Group and Professional Editions. You then use a second managed package, or extension package, that extends and enhances the base package. The extension package adds more features supported in Enterprise, Unlimited, and Performance Editions. For example, you have a warehouse application that tracks inventory and an extension to this app includes workflow (which isn't available in Group). Your Group and Professional Edition customers can install the base warehouse application, while your other customers install the base package and then the extension package with workflow components. ![Relationship between base and extension packages](https://developer.salesforce.com/docs/media/base_extension_package.png "Using a Base and Extension Package to Support Multiple Editions") Using extension packages enables you to avoid multiple code sets and to upsell your customers. Upgrading a customer only requires installing the extension package. Here is the process for creating an extension package. 1. Create your base-managed package that uses features supported by Group and Professional Editions. 2. Install your base-managed package in a separate Developer Edition org. 3. In this org, create your extension package that includes more functionality supported in Group and Professional Editions. You can reference the base-managed package to avoid duplicating functionality. Any component that references the base-managed package automatically triggers this package to be an extension package. Since your extension package depends on your base package, it’s important to spend time designing your app and the interfaces between the packages. For example, if the extension package calls an Apex class in the base package, you must make sure that the desired Apex class is made global. It’s also important to consider the entire application life cycle. For example, If you want to add new features, include them in the appropriate package. Ensure that updates to the base package do not break the extension package. **note:** To access history information for custom objects in your extension package, work with the base package owner to enable history tracking in the org for the base package. Enabling history tracking in a base package can result in an error when you install the package and create patch orgs for the extension package. # Supporting Multiple Editions using Dynamic Apex Using dynamic Apex, dynamic SOQL, and dynamic DML, it’s possible to create one managed package for all editions you plan to support without having to use extension packages. Your app behavior can change dynamically based on the features available in your customer's edition. This is useful when designing an app with the intent to support multiple editions. Make sure that Apex, workflows, etc. in your package do not contain any strongly-typed reference to a feature that isn't supported by GE/PE. This can include adding a custom field on an unsupported standard object, such as Campaigns, or making an Apex reference to features like multi-currency or territory management. When you reference a feature in your package not supported by GE/PE, this package dependency will cause the installation to fail. Instead, if you use dynamic Apex to first check if these features are available before referencing them, you can install your managed package in GE/PE. The important piece to consider is you must code your Dynamic Apex in a way that can support both use cases. This ensures that if your customer doesn’t have a specific feature or object, your app will still function. # Take Ownership of a Second-Generation Managed Package Transferred from a Different Dev Hub You can take ownership of a second-generation managed package that is transferred from another Dev Hug org. To initiate a package transfer from your Dev Hub org, see [Transfer a Second-Generation Managed Package to a Different Dev Hub](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-package-transfer.md). **note:** For security reasons, package transfers between a Dev Hub located in Government Cloud and a Dev Hub located outside Government Cloud aren’t permitted. ## Transfers from External Customers If you’re receiving the package from another Salesforce Partner or ISV, make sure they provide the source code for the package, and an outline for the config settings needed to properly set up your Salesforce DX environment. Request all the configuration settings required to properly set up the `sfdx-project.json` file, and a complete list of features and settings that must be specified in your scratch org definition file. Also ensure that the company who is transferring the ownership of the package provides the login credentials for the namespace org they used. This information is needed to link the package namespace to your Dev Hub org. ## Receive a Package Transfer For internal transfers, skip this step. Only log the case described in [Transfer a Second-Generation Managed Package to a Different Dev Hub](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-package-transfer.md) . If you’re receiving a package from a different Salesforce Partner or ISV, start by linking the namespace of the package you are receiving to your Dev Hub org. See [Link a Namespace to a Dev Hub Org](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_reg_namespace.htm) in the _Salesforce DX Developer Guide_. Next, log a case with Salesforce Customer Support, and provide the: - Dev Hub org ID for the source org. - Subscriber package ID of the package you’re receiving. This ID begins with 033. - Dev Hub org ID for the destination org. ## After the Package Transfer Is Complete After the package transfer is complete, you’ll be notified by Salesforce Customer Support. To verify that the transferred package is associated with your Dev Hub, run `sf package list`. ## Impact of Package Transfers on Package IDs | ID Type | ID starts with | After package transfer is complete … | | ----------------------------- | -------------- | ------------------------------------------------------------- | | Subscriber Package ID | 033 | This ID remains the same. | | Subscriber Package Version ID | 04t | This ID remains the same. | | Package ID | 0Ho | The transferred package receives a new and unique package ID. | ## Update Your Package Project File Open and review the contents of the `sfdx-project.json` file that you received from the original package owner. Open and review the contents of any scratch org definition files that you received from the original package owner. Definition files help in setting up your scratch orgs during development. Use the `-–definition-file` parameter to specify a definition file when you create a new package version. If the package directories section lists additional packages that weren’t transferred to you, remove those references from the `sfdx-project.json` file. Next, review the package alias section of the `sfdx-project.json` file, and remove any references to package aliases that aren’t associated with the package that was transferred. Update the package alias of the transferred package to specify its 0Ho package ID. ## Before You Create a New Package Version Similar to how you go about creating any new package versions, you must update the `sfdx-project.json` file, and update the version number and ancestor ID. We recommend you set the ancestor ID to HIGHEST. To designate a Dev Hub user to receive email notifications for unhandled Apex exceptions, and install, upgrade, or uninstall failures associated with your package, run the `sf package update` command, and use the `--error-notification-username` parameter. ## What Package History Is Transferred? Regardless of whether the package transfer occurred between two Dev Hub orgs you own, or the package was transferred externally to a Dev Hub you don’t own, we transfer the package version history. We transfer: - Package name, namespace, type, and IDs. One exception is that the transferred package gets a new 0Ho ID. - Package version info. This includes all the info that is typically displayed when you run the `sf package version list` or `sf package version report` command. We don’t transfer: - Push upgrade history. - Package version create requests. - The username of the Dev Hub user who received Apex and other types of error notifications. - Deleted package versions. ## Next Steps You’ve verified that the package is associated with your Dev Hub, you’ve updated your `sfdx-project.json` file, and perhaps you’ve even created a new package version. Congrats! There’s still a couple more items of business left to complete. 1. Register the transferred package with your License Management Org. If this is an external transfer, log a case with Salesforce Customer Support and request provide both your LMO org ID, and the 033 package ID. 2. [Publish Your Package on AgentExchange](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_publish_appexchange.htm) # Target a Specific Release for Your Second-Generation Managed Packages During Salesforce Release Transitions During major Salesforce release transitions, you can specify `preview` or `previous` when creating a package version. Specifying the release version for a package allows you to test upcoming features, run regression tests, and support customers regardless of which Salesforce release their org is on. Previously, you could only create package versions that matched the Salesforce release your Dev Hub org was on. To create a package version based on a preview or previous Salesforce release version, create a scratch org definition file that includes either: ```nolang { "release": "previous" } ``` or ```nolang { "release": "preview" } ``` In the `sfdx-project.json` file, set the `sourceApiVersion` to correspond with the release version of the package version you’re creating. If you are targeting a previous release, any `sourceApiVersion` value below the current release is accepted. Then when you create your package version, specify the scratch org definition file. ```nolang sf package version create --package pkgA --definition-file config/project-scratch-def.json ``` Preview start date is when sandbox instances are upgraded. Preview end date is when all instances are on the GA release. | Release Version | Preview Start Date | Preview End Date | | --------------- | ------------------ | ----------------- | | Winter ’27 | August 30, 2026 | October 10, 2026 | | Spring ’27 | January 10, 2027 | February 20, 2027 | | Summer ’27 | May 9, 2027 | June 12, 2027 | # 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. The [Enable New Order Save Behavior](https://help.salesforce.com/s/articleView?id=sales.new_order_save_behavior_setup.htm&type=5) setting helps Salesforce correctly evaluate custom application logic on records associated with the Order object. If you create any type of package that includes the Order object, the installed package sometimes doesn’t work. If a subscriber org relies on a different order save behavior than their installed packages, the installed packages sometimes don’t work. To ensure the expected behavior, test Enable New Order Save Behavior with your installed packages. After Enable New Order Save Behavior is selected, Salesforce evaluates and runs these customizations whenever an update to an order item record changes the parent order record. - Order and order item validation rules - Order and order item Apex triggers and classes - Order and order item flows and processes ## Next Steps **note:** Enable New Order Save Behavior affects all package types: unlocked, unmanaged, first-generation managed package (1GP), and second-generation managed package (2GP). You can install packages that support old Order Save Behavior on subscriber orgs where New Order Save Behavior is enabled. However, you must verify that your package works with the new order save behavior. After you verify that your package works with the new order save behavior and that all your packages associated with your Dev Hub org work with the new order save behavior, you can choose to enable the update in your Dev Hub org. We recommend that you support both the new and old order save behavior during your testing. Test Unmanaged and First-Generation Managed Packages - From Setup, in the Quick Find box, enter `Release Updates`, and select **Release Updates**. Locate the Enable New Order Save Behavior tile, and select **Enable Test Run**. - Test the impact of the new behavior when an order or order item is edited. Review any custom application logic such as validation rules, Apex triggers and classes, workflow rules, flows, and processes. - To show that your package is compatible with both new and old order save conditions, from Setup, in the Quick Find box, enter `Package`. Select the package that you tested and select **Upload**. - Locate the Package Requirements section and disable **New Order Save Behavior**. When this setting is disabled and the release update is enabled, subscriber orgs using either the new or old order save behavior can install your package. Test Unlocked and Second-Generation Managed Packages - After creating a scratch org, enable the Release Update in it. From Setup, in the Quick Find box, enter `Release Updates`, and then select **Release Updates**. Locate the Enable New Order Save Behavior tile, and select **Enable Test Run**. - Test the impact of the new behavior when an order or order item is edited. Review any custom application logic such as validation rules, Apex triggers and classes, workflow rules, flows, and processes. When you’re ready to create a package version, specify the order save behavior in the definition file. | To Specify | Set Features in Scratch Org Definition File To | | ------------------------------- | ---------------------------------------------- | | Old Order Save Behavior | See the example after this table. | | New Order Save Behavior | See the example after this table. | | New and Old Order Save Behavior | See the example after this table. | Example: Old Order Save Behavior ```nolang { "features": [], "settings": { "orderSettings": { "enableOrders": true } } } ``` Example: New Order Save Behavior ```nolang { "features": ["OrderSaveLogicEnabled"], "settings": { "orderSettings": { "enableOrders": true } } } ``` Example: New and Old Order Save Behavior ```nolang { "features": ["OrderSaveBehaviorBoth"], "settings": { "orderSettings": { "enableOrders": true } } } ``` # Test Converted Packages and Subscriber Migrations When you complete your move to 2GP development, you can no longer create any new major or minor 1GP versions of that package. Before you make this transition, it’s critical that you thoroughly test packages converted to 2GP and the migration of subscribers to 2GP. Test these scenarios before you complete the move to 2GP. - Create 2GP-converted versions for the minimum number of packages necessary to migrate subscribers to 2GP. - In test orgs, install the 2GP-converted package versions. Then, test the converted packages thoroughly. - Install the corresponding 1GP versions of your packages in your test orgs. Then, migrate these test orgs to 2GP using both manual installs and push upgrades. - When you’re comfortable with converting packages and testing migrations, we recommend that you migrate a significant portion of subscribers before completing your move to 2GP package development. After you complete your move to 2GP, any unmigrated subscribers must migrate to 2GP to continue receiving version updates. # Test Custom Integrations To test your custom integrations in a nonproduction environment, use AgentExchange App Analytics Simulation Mode. Submit an App Analytics query request and receive sample usage data. ## Before You Begin | User Permissions Needed | | | -------------------------- | -------------- | | To enable simulation mode: | ModifyMetadata | **note:** AgentExchange App Analytics is subject to certain usage restrictions as described in the [AgentExchange Program Policies](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/alliance-agreements-and-terms/salesforce-partner-program-policies.pdf). To receive sample usage data, enable simulation mode, then submit a query request that includes a simulation mode package ID. 1. Enable simulation mode in your test org using the Metadata API [AppAnalyticsSettings](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_appanalyticssettings.htm) `enableSimulationMode` org preference. 2. To simulate package usage log, usage summary, or subscriber snapshot downloads, complete the required fields in your SOAP API [AppAnalyticsQueryRequest](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_appanalyticsqueryrequest.htm). Include `DataType`, and leave `OrganizationIDs` blank. For `PackageIDs`, include at least one simulation mode package ID that matches the scenario you’re testing. | Package Dataset | Simulation Mode Package ID | Description | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Small Dataset | `033xx00SIMsmall` | Contains a small amount of data. For use with all query types. Use this package ID to download data for any query-allowed timespan. | | Large Dataset | `033xx00SIMlarge` | Contains a large amount of data for two org IDs (`00Dxx00SIM00foo` and `00Dxx00SIM00bar`). For use only with package usage log queries. | | Empty Dataset | Use any other 15-character package ID prefixed with `033xx00SIM`. Examples:
  • `033xx00SIMempty`
  • `033xx00SIM44444`
| Contains no data. For use with all query types. Use one of these package IDs to return an empty dataset. | 3. Submit your query. 4. Check your API request. 1. If successful, retrieve the App Analytics Query Request object created in the API request. The `DownloadURL` field populates when the request is completed. 2. If you get an error, edit your query. Use a smaller time window, such as a 14 days, or specify one org ID. Then resubmit your query. 5. Download the comma-separated value (.csv) file containing sample usage data from the DownloadURL field in the App Analytics Query Request object. ## Result **important:** When simulation mode is enabled, you can only access our sample usage data. Disable simulation mode to access your production data. # Test Your Converted Managed 2GP Package Before you migrate your first subscribers, we strongly recommend you install your newly converted managed 2GP package into a new scratch org and test its functionality. If you prefer, you can also install the converted package in a sandbox, or developer edition org. 1. Create a scratch org. When creating your scratch org, be sure to include a scratch org definition file that includes any Salesforce features that your package depends on. ```nolang sf org create scratch --target-dev-hub MyHub --definition-file config/project-scratch-def.json ``` 2. Migrate the converted package. To verify the 04t ID of the converted package, run `sf package version list` and review the command output. Then run the package install command and specify the 04t ID. In this scenario, the package version is being migrated, not installed. Example: ```nolang sf package install --package 04t... ``` Next, explore your package and test its functionality. Make sure everything is operating as expected. Note that the converted package is a beta version. ## Next Steps During phase one you can convert your 1GP package, install the converted package in a scratch org, and try out package migration by using packages that are installed in scratch orgs. By testing these steps in a scratch org first, you can understand how package migration works, before migrating packages used by active customers. # Three Phases of Package Migration Development As you move from 1GP development to 2GP development, you’ll move through three phases. - Phase One: Plan for and test package migration - Phase Two: Transition from 1GP to 2GP - Phase Three: Fully transitioned to 2GP package development Here's a quick comparison of the three phases. | Phase | New package versions are built using 1GP? | Convert Packages? | Migrate Packages? | New package versions built using 2GP? | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Phase 1: Plan and Test | Yes. Use 1GP to create and distribute packages. | Only for testing. When converting packages for testing only, you don’t need to promote the converted version. | Migrate in scratch orgs or test environments only. | No. | | Phase 2: Transition from 1GP to 2GP | Yes. In phase two, even if you have migrated a subscriber. All new innovation to your package is built using 1GP. | Yes. You can begin the conversion process with the latest version of your package. For previously converted packages, you can also convert specific patch versions as needed. Remember, a crucial step before updating your subscribers is to promote your converted package version to the released state. | Yes. Use the push upgrade CLI to migrate subscribers to 2GP. Migration is a one-time operation per subscriber and package. In phase two, after package migration, you upgrade subscribers using push upgrades to a converted version of your package. | No. Even if you have migrated some or all subscribers to a 2GP package version. During phase two any major, minor, or patch updates to this package must be built using 1GP. If you make updates to the 1GP package, upload it to the managed-released state, then convert that package version, and use push upgrades to upgrade subscriber orgs. | | Phase 3: Fully Transitioned from 1GP to 2GP | No. In this phase all innovation to your package is built using 2GP. | Before moving to phase three you must convert your latest package version. After a package has moved to phase three, you can no longer convert any new major, minor package versions. | At this stage, most of your subscribers are migrated to 2GP, but you can continue migrating lagging subscribers. | Yes | ## Phase One: Plan for and Test Package Migration In phase one, you’re developing, distributing, and releasing package upgrades using 1GP packaging. While you continue package development using 1GP, it’s a good time to learn how package migrations work, and plan out how to migrate. See [Plan Your Package Migration](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_planning.htm) for more details. During phase one you can convert your 1GP package, test the package in a scratch org, and try migrating packages installed in scratch orgs or sandboxes. During package conversion, your original managed 1GP package isn’t altered. After a package conversion completes, you have both your original managed 1GP package version, and a new managed 2GP package version. Because your original 1GP isn’t altered, you can continue developing that 1GP package using its associated packaging org. If your subscribers aren’t all using the same version of your package, phase one is a great time to get everyone upgraded to the same 1GP version of your package. Let's look at why this is recommended. The package conversion command automatically selects and converts the latest major.minor package version. (We’ll cover patch versions in a later section). To migrate subscribers using a lower major.minor package version, you must upgrade them to either your latest 1GP package version, or to a previously converted 1GP version. When you migrate a package, the 1GP package version installed on a subscriber org must match the major.minor.patch version of the converted 2GP package you migrate to that org. If you’re able to get your subscribers all updated to the same package version, you only need to convert that one package version (for example version 6.0), and then you could choose to bulk migrate all subscribers to version 6.0 of the converted 2GP package. Before moving to phase two, ensure you understand how migration works, including some best practices. - Review: [Plan Your Migration](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_planning.htm) - Review: [Before you Begin Package Migration](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_prerequistes.htm) - Review: [Considerations for Package Migration](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migrations_known_limitations.htm) - Try package conversion and package migration in a test environment ## Phase Two: Transition from 1GP to 2GP Phase two is a transition time. In phase two you will convert your package, promote it to the released state, and start migrating your subscribers. The package conversion CLI command converts your latest major.minor released version of your package. To ultimately migrate all subscribers and move to phase three, any subscribers not using your latest package version must be upgraded to either your latest package version, or upgraded to a previously converted version, before they can be migrated. If you’ve already tested package conversion and migration, you understand how to run those CLI commands. The thing to note about phase two is that after you migrate subscribers to your 2GP package, you’ll continue to use 1GP for new package innovation. After you create a new 1GP package version, you convert that package version, promote it, and push upgrade the new converted 2GP to your subscribers. Package migration is a one-time per package and subscriber operation, but during phase two you’ll likely convert additional versions of your 1GP package and use those new converted versions to upgrade previously migrated subscribers. ## Phase Three: Fully Transitioned to 2GP Package Development In phase three, you confirm in Setup for your packaging org that you’re ready to develop and distribute your package solely using 2GP packaging. When you confirm that you’re ready to move to 2GP, the packaging org for your package is blocked from creating any new major or minor 1GP versions of that package. See [Complete the Move to 2GP Package Development](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/migration-move-to-2gp-workflow.md) for instructions. You can continue to create 1GP patch versions for versions prior to moving to 2GP development. For example, if you moved package version 6.0.0 to 2GP development, you can create patch version 5.0.1 or 4.1.1 using 1GP, but you can’t create patch version 6.0.1 or later using 1GP. # Track Preferences and Activation Metrics with Subscriber-to-LMO Feature Parameters Use subscriber-to-LMO feature parameters to track feature activation in your subscriber’s org. Parameter values are assigned on the subscriber’s end and then sent to your LMO. To collect the values, update the feature parameters in your subscriber’s org using Apex code. Check with your legal team before obtaining activation metrics from your customers. Use activation metrics to collect only aggregated data regarding feature activation. - `System.FeatureManagement.setPackageBooleanValue('YourBooleanFeatureParameter', booleanValue);` - `System.FeatureManagement.setPackageDateValue('YourDateFeatureParameter', datetimeValue);` - `System.FeatureManagement.setPackageIntegerValue('YourIntegerFeatureParameter', integerValue);` **note:** The Value\_\_c field on subscriber-to-LMO feature parameters is editable in your LMO. But don’t change it. The changes don’t propagate to your subscriber’s org, so your values will be out of sync. You can view the value of a subscriber-to-LMO feature parameter from the [Subscriber Support Console](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_subscriber_support_overview.htm). **See Also** - [_Apex Reference Guide_: FeatureManagement Class](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_System_FeatureManagement.htm) # Track Preferences and Activation Metrics with Subscriber-to-LMO Feature Parameters Use subscriber-to-LMO feature parameters to track feature activation in your subscriber’s org. Parameter values are assigned on the subscriber’s end and then sent to your LMO. To collect the values, update the feature parameters in your subscriber’s org using Apex code. Check with your legal team before obtaining activation metrics from your customers. Use activation metrics to collect only aggregated data regarding feature activation. - `System.FeatureManagement.setPackageBooleanValue('YourBooleanFeatureParameter', booleanValue);` - `System.FeatureManagement.setPackageDateValue('YourDateFeatureParameter', datetimeValue);` - `System.FeatureManagement.setPackageIntegerValue('YourIntegerFeatureParameter', integerValue);` **note:** The Value\_\_c field on subscriber-to-LMO feature parameters is editable in your LMO. But don’t change it. The changes don’t propagate to your subscriber’s org, so your values will be out of sync. You can view the value of a subscriber-to-LMO feature parameter from the [Subscriber Support Console](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/lma_subscriber_support_overview.htm). # Transfer a Second-Generation Managed Package to a Different Dev Hub You can transfer the ownership of a second-generation managed package (managed 2GP) from one Dev Hub org to another. These transfers can occur either internally between two Dev Hub orgs your company owns, or you can transfer a package externally to another Salesforce Partner or ISV. This change provides a way to sell a managed 2GP package to a different company. **note:** Package transfers are only available for managed 2GP packages that have passed AgentExchange security review. If your managed 2GP package hasn’t passed security review, consider creating a new managed 2GP package using your preferred Dev Hub. A managed 2GP package that has been converted from a first-generation managed package (1GP) can’t be transferred to another Dev Hub org. When you convert a package to 2GP, the association between the package and the Dev Hub org can’t be changed. The package transfer feature is also available to unlocked packages. Dev Hub orgs aren’t used with managed 1GP packages or unmanaged packages, so this feature doesn’t apply to those package types. ## Request a Package Transfer to a Different Dev Hub Start by logging a case with Salesforce Customer Support, and provide the following details. Subject: Managed 2GP Package Transfer to a different Dev Hub Description: In the description, list: - Subscriber package ID of the package you’re transferring. This ID starts with 033. To verify the 033 ID of your package, run the `sf package list` command with the `-–verbose` flag on the source Dev Hub org. - Dev Hub org ID for the source org. - Dev Hub org ID for the destination org. The destination Dev Hub org can’t be a Developer Edition org or a trial org. - Namespace of the package being transferred. - Details about whether this package transfer is internal or external. An external transfer occurs when you transfer a package to a Salesforce Partner or ISV who doesn’t work at your company. - Acknowledge that you’ve reviewed and completed the steps listed in the Prepare to Transfer Your Package section, including linking your namespace to the destination Dev Hub, and clearing your Apex Error Notification User. If you’re transferring more than one package, file a separate case for each package. After your case has been reviewed and approved, someone from Salesforce Customer Support will contact you to arrange a time to initiate the package transfer. **note:** For security reasons, package transfers between a Dev Hub located in Government Cloud and a Dev Hub located outside Government Cloud aren’t permitted. ## Package Transfers to External Customers If you’re transferring a package to another Salesforce Partner or ISV, provide: - The source code and config settings needed to properly set up their Salesforce DX environment. All config settings needed to properly set up the `sfdx-project.json` file, and a complete list of features and settings that must be specified in their scratch org definition file. - The login credentials to the namespace org. This information is required to link the package namespace to their Dev Hub org. ## Prepare to Transfer Your Package Here’s how you can help ensure a smooth package transfer. - Keep the namespace linked to the source Dev Hub. Before the package transfer, the [namespace must be linked](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) to both the source and destination Dev Hub orgs. - Before the package transfer process is initiated, ensure all push upgrades or package version creation processes have completed. - Delete package versions that are no longer needed. - If specified, clear the package’s Error Notification User using the `sf package update --error-notification-username=` command. If you’re transferring the package to a Dev Hub org that you own, you can set the Error Notification User to a user in the destination Dev Hub after the package transfer is complete. Note: Specifying `--error-notification-username=` with no value after the equals sign clears any previously set username. ## During the Package Transfer Process All push upgrades or package version creation processes must be complete before the package transfer process is initiated. Salesforce Customer Support will alert you about the date the package transfer will occur. ## After the Package Transfer Is Complete Run `sf package list` and verify that the package is no longer associated with your Dev Hub. If the transferred package is still visible in your CLI output, and the recipient of the package transfer indicates the package transfer succeeded, log a case with Salesforce Customer Support to remove the association of the package with your Dev Hub org. Next, unpublish your existing AgentExchange listing for this package. ## Impact of Package Transfers on Package IDs | ID Type | ID starts with | After package transfer is complete … | | ----------------------------- | -------------- | ------------------------------------------------------------- | | Subscriber Package ID | 033 | This ID remains the same. | | Subscriber Package Version ID | 04t | This ID remains the same. | | Package ID | 0Ho | The transferred package receives a new and unique package ID. | ## Update Your Package Project File Before you create new packages or package versions on your Dev Hub, update your `sfdx-project.json` file and remove all references to the transferred package from the package directory and package alias sections. If you have packages in your Dev Hub that depend on the package that you’re transferring, update the package dependency section in your `sfdx-project.json` file to explicitly specify the 04t ID of the transferred package that you depend on. For example, if you transferred pkgA to a different Dev Hub, and your `sfdx-project.json` file lists the package dependency like this. ```nolang "dependencies": [ { "package": "pkgA" "versionNumber": "2.0.0.LATEST" } ] ``` Update the dependency to either specify the 04t ID of pkgA. ```nolang "dependencies": [ { "package": "04tB0000000UzH5IAK" } ] ``` Or specify the dependency using a package alias. ```nolang "dependencies": [ { "package": "pkgA2.0.0-1" } "packageAliases": { "pkgA2.0.0-1": "04tB0000000UzH5IAK" } ] ``` ## What Package History Is Transferred? When a package is transferred, all package versions, and all lines of ancestry are transferred. Customer upgrade paths aren’t affected. Regardless of whether the package transfer occurred between two Dev Hub orgs you own, or the package was transferred externally to a Dev Hub you don’t own, we transfer the package version history. We transfer: - Package name, namespace, type, and IDs. One exception is that the transferred package gets a new 0Ho ID. - Package version info. This includes all the info that is typically displayed when you run the `sf package version list` or `sf package version report` command. We don’t transfer: - Push upgrade history. - Package version create requests. - The username of the Dev Hub user who received Apex and other types of error notifications. This optional user is set using `--error-notification-username`. - Deleted package versions. Package versions that were deleted prior to the transfer are no longer recoverable or visible through Salesforce CLI commands. - **[Take Ownership of a Second-Generation Managed Package Transferred from a Different Dev Hub](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-receive-package-transfer.md)** You can take ownership of a second-generation managed package that is transferred from another Dev Hug org. # Trialforce Best Practices Apply these best practices to create trial experiences that engage prospects and increase conversion. - To tailor trials to specific audiences, create multiple Trialforce Source Organizations (TSOs). For example, create a unique TSO for each of the industry verticals that you serve. - To bring trials to life, add sample data to TSOs. **note:** Trialforce replaces data that appears to be 15- or 18-character Salesforce IDs. Avoid specifying IDs within strings in object fields, JavaScript, or files. - Apply custom branding to your trial signup form, login page, and emails. - After you set up Trialforce, test the signup experience to confirm that everything works as expected. Testing also helps you identify areas where you can improve the signup process. - When you release a new version of your solution, update the related Trialforce template. # Trialforce Key Concepts and Relationships A Trialforce setup consists of a Trialforce management org, Trialforce source orgs, and Trialforce templates. Before you set up Trialforce, learn how these parts work together to deliver trials of your AgentExchange solution. ## Key Concepts - Trialforce Management Organization - : A Trialforce management org (TMO) is the starting point for creating trials with Trialforce. You perform these tasks in your TMO. - Create one or more Trialforce source orgs. - Define templates for custom branding. - Trialforce Source Organization - : A Trialforce source org (TSO) is used to create Trialforce templates, which are used to provision trial orgs. You perform these tasks in your TSO. - Install your solution, and add sample data. - Configure the TSO as you want customers to experience it. - Optionally, specify custom branding using templates. - Create one or more Trialforce templates. - Trialforce Template - : A Trialforce template is an approximate snapshot, not exact copy, of your TSO. The template defines the trial org that’s provisioned when a customer signs up for a trial. Trialforce templates are also used to generate trial orgs using the SignupRequest API and create demo orgs from the Environment Hub. You create a template after you install and configure a solution in your TSO. You can create Trialforce templates only if the TSO is a trial org. ## Relationships Between Trialforce Org Types The TMO, TSOs, and Trialforce templates have a hierarchical relationship. ![Trialforce hierarchy diagram showing the relationships between organizations used to set up Trialforce.](https://developer.salesforce.com/docs/media/trialforce_hierarchy.png) The TMO sits at the top of the hierarchy. You can create multiple TSOs from the same TMO. Likewise, you can create multiple Trialforce templates from the same TSO. After you add a Trialforce template to your AgentExchange listing, the template is used to provision trial orgs for customers. We recommend that you have one TMO for your company, one TSO for each solution that you offer, and one Trialforce template for each solution version. This configuration makes it easier to maintain and update your trials. Each time you change something, such as the version, its branding, or a configuration detail in the trial org, you change only one level in the hierarchy. Let’s explore these relationships in an example. ## Example Your company offers two solutions, Appy’s e-Signatures and Codey’s Maps. From your TMO, you create two TSOs—one for Appy’s e-Signatures and another for Codey’s Maps. Using the Appy’s e-Signatures TSO, you create a Trialforce template and connect it to the related AgentExchange listing. You repeat the process for Codey’s Maps. Sometime later, you add a feature to Codey’s Maps and create a new solution version. In the existing Codey’s Map’s TSO, you install the latest solution version and create an updated Trialforce template. Then you update the Codey’s Maps listing with the new Trialforce template so that customers can experience the feature. ## Trial Delivery Options with Trialforce After you configure your TMO, TSO, and Trialforce template, you choose how to provide trials to prospective customers. - AgentExchange: Customers start trials on your AgentExchange listing. This approach has the fewest configuration steps and is the fastest way to deliver a trial. - SignupRequest API: Customers start trials from your website using a branded signup form. This approach allows for advanced customization and gives you full control of the signup process. # Troubleshoot AgentExchange Leads You enabled lead collection for your AgentExchange listing. However, the lead count in your org is different than you expect. Learn how lead routing rules, reCAPTCHA verification, and other settings determine what leads AgentExchange sends to your Salesforce org. ## Custom Lead Routing Rules Typically, you set up custom lead routing rules to prevent duplicate or unwanted leads from reaching your sales team. For example, an employee at your company watches your AgentExchange listing’s demo video. When prompted for contact information, they enter a company email address. AgentExchange records this interaction as a lead. From a sales perspective, it’s an unwanted lead. To prevent leads from users with your company’s email address from propagating to your Salesforce org, you can create a custom lead routing rule.See [Guidelines for Assignment Rules](https://help.salesforce.com/s/articleView?id=service.customize_leadrules.htm&type=5). ## Customer Contact Preferences Customer can choose to share their contact info with, and allow contact from, AgentExchange providers. AgentExchange sends only leads to your Salesforce org for customers who allow provider contact. ## Web-to-Lead reCAPTCHA To receive AgentExchange leads in your Salesforce org, disable Require reCAPTCHA Verification in your org’s Web-to-Lead settings. If reCAPTCHA is enabled, AgentExchange leads aren’t sent to your org. ![Web-to-Lead Setup page with an orange circle around the Require reCaptcha Verification label and checkbox](https://developer.salesforce.com/docs/media/web-to-lead-setup.png) ## State and Country/Territory Picklists AgentExchange sends leads to your org via Web-to-Lead. Users provide contact info for the lead by completing the AgentExchange Web-to-Lead form. They’re required to select a country or territory from a picklist. The selected country or territory is saved as a text value. For example, a user selects Japan. The saved value is the full name of the country, Japan. The AgentExchange lead is sent to your org with country set to Japan. In orgs with state and country/territory picklists enabled, you can optionally populate these picklists with predefined, standard state and country lists that Salesforce provides. You can also edit country names and integration values, also known as developer names. The Web-to-Lead form uses the integration values from the state and country/territory picklists. For AgentExchange lead creation to succeed, the integration value for a country/territory in your org must match the value captured on the AgentExchange Web-to-Lead form. In our example, they must both be Japan. ![The country and territory details configuration page in a Salesforce org showing that both the name and integration value are set to Japan](https://developer.salesforce.com/docs/media/country-territory-details-edit.png) Changing country/territory names doesn’t affect AgentExchange lead creation, but changing integration values does. Don’t change integration values. The country or territory sent in an AgentExchange lead must match an integration value in your org. If there’s no match, lead creation fails. The same issue occurs with state picklists. To avoid state and country/territory picklist-related lead failures, you have two options. Use the standard picklist integration values, or add duplicate states and countries/territories to your picklists. - Use Standard Picklist Integration Values To implement this option, use the Salesforce standard state and country/territory picklists in your org, and leave the integration values as-is. We recommend this option for most partners. With this option, AgentExchange leads propagate to your org with full state and country/territory names. The names match integration values in the standard picklists. - Add Duplicate States and Countries/Territories to Your Picklists Implement this option if you require two-letter state or country/territory abbreviations in your org. For example, you show abbreviations in the user interface, or use them to integrate with other systems. Add duplicate states and countries/territories to your picklists with different integration values. Set one value to the two-letter state or country/territory abbreviation. Set the other value to the full state or country/territory name. Make only the two-letter abbreviation picklist entries visible. With this option, AgentExchange leads propagate to your org with full state and country/territory names, which match the full name integration values in your org. You also have two-letter integration values to use as needed. ## Duplicate Rules If your org uses duplicate rules, review your duplicate rule settings to ensure they don't inadvertently prevent incoming leads from being captured. When a duplicate rule blocks a lead, Salesforce doesn't send a notification, and the lead is lost. To resolve this problem, configure a bypass for AgentExchange Leads: 1. From Setup, enter `Duplicate Rules` in the Quick Find box, then select **Duplicate Rules**. 2. Find the duplicate rule on the Lead object, usually Standard Lead Duplicate Rule or a custom alternative, and click **Edit**. 3. Set Action On Create to **Allow**. 4. Next to Action On Edit, deselect the **Alert** checkbox. If enabled, lead creation fails. 5. Under Conditions, set a filter logic: - Field is Lead: Lead Source - Operator is Starts with - Value is SFDC- 6. Set the rule's Order to the lowest available number to ensure it runs before your other blocking duplicate rules. 7. Click **Save**. With this in place, AgentExchange leads are created even when they match existing records, while your other duplicate rules continue to operate normally for leads from other sources. For more information, see [Standard Lead Duplicate Rule](https://help.salesforce.com/s/articleView?id=sales.duplicate_rules_standard_lead_rule.htm&type=5). ## Lead Capture Timing After you enable lead capture for an AgentExchange listing, the configuration can take up to 10 minutes to sync. If a customer submits a request during this time, the lead isn't created. To avoid this, turn on lead capture before you publish your listing. **See Also** - [Leads](https://help.salesforce.com/s/articleView?id=sales.leads_def.htm&type=5) - [Standard Countries for Address Picklists](https://help.salesforce.com/articleView?id=admin_state_country_picklists_standard_countries.htm) - [Integration Values for State and Country Picklists](https://help.salesforce.com/articleView?id=admin_state_country_picklists_integ_values.htm) - [Leads](https://help.salesforce.com/s/articleView?id=sales.leads_def.htm&type=5&language=en_US) - [Standard Countries for Address Picklists](https://help.salesforce.com/articleView?id=admin_state_country_picklists_standard_countries.htm&language=en_US) - [Integration Values for State and Country Picklists](https://help.salesforce.com/articleView?id=admin_state_country_picklists_integ_values.htm&language=en_US) # Troubleshoot Package Conversion Failures Here are some possible error scenarios that can occur when you convert a package. ## API Version Salesforce API version 57 is the minimum API version required for converting a package from first-generation packaging (1GP) to second-generation packaging (2GP). If you encounter errors during conversion, first make sure that the package version you’re converting was created using Salesforce API version 57 or later. If your package is using a lower API version, create a 1GP package version using the latest API version, then try the conversion process again. ## RecordType Errors If the package you’re converting contains a RecordType, you must specify it under object settings in a scratch org definition file. For example, ```nolang "objectSettings": { "Contact": { "defaultRecordType": "default" } } ``` Then specify the scratch org definition file when you run the package conversion CLI command. ```nolang sf package convert -p 033xx0000004Jx3 –-definition-file config/project-scratch-def.json ``` ## Org Shape Errors An [org shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) is a stored representation of a source org’s baseline setup. In the conversion process, the org shape is used to create the 2GP version of the 1GP package. When you convert a 1GP package to 2GP, and you have not previously set up an org shape for the source 1GP packaging org, we create an org shape for you so that we’re using a replica of your 1GP packaging org’s baseline setup. To learn more about org shapes, see [Create and Manage Org Shapes](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_create_shape.htm) and [Troubleshoot Org Shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_limitations.htm). If you already have an org shape set up for your 1GP packaging org, we use your existing org shape in the conversion process. When you have an existing org shape, you can sometimes experience org shape issues in the conversion process. If you encounter an org shape error when you run the `sf package convert` command, [delete the packaging org’s existing org shape and then recreate the org shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_create_shape.htm). Then, try the conversion process again. If you continue to experience org shape errors, contact Salesforce Partner Support for help. ## Permission Sets for Code Coverage When you use the `sf package convert` command with the `--code-coverage` flag, the conversion process runs the packaged Apex tests to validate the code coverage. If the permission sets required to run the tests aren’t defined, the package conversion can fail. To resolve this issue, add the required permission sets to the `sfdx-project.json` file. Make sure that the package name is also in the `sfdx-project.json` file, so that the permission sets can be identified. This example `sfdx-project.json` file adds the `SampleAccess` apexTestAccess permission set. ```nolang { "packageDirectories": [ { "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "path": "", "default": true, "package": "", "versionDescription": "", "apexTestAccess": { "permissionSets": [ "SampleAccess" ], "permissionSetLicenses": [] } } ], "namespace": "", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "63.0", "packageAliases": { "": "" } } ``` After you update the `sfdx-project.json` file, try the conversion process again. ## Picklist Value Errors If your package references a custom picklist value that isn’t included in Salesforce’s StandardValueSet, a picklist error occurs during package conversion. ## Before You Begin For more details on Standard Value Sets, [StandardValueSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_standardvalueset.htm) in _Metadata API Developer Guide_. To resolve this error, follow these steps. 1. Create a package.xml file that follows this example. Replace the example AccountType value with the object identified in the error you received. Update the version field to the current Salesforce API version ```nolang AccountType StandardValueSet 64.0 ``` 2. Authenticate to your packaging org. The required picklist values should be present in your packaging org 3. Run the project retrieve Salesforce CLI command. Replace the variables for org alias and path, with the actual values you need. ```nolang sf project retrieve start --manifest package.xml --target-org –-output-dir ``` After the retrieve command completes, a new file is created in your force-app/main/default/standardValueSets directory. The name of the file will be AccountType.standardValueSet-meta.xml, where AccountType is the object you specified in your package.xml file. 4. Create a parent and child folder in your project root New parent folder: seed-metadata/ New child folder: standardValueSets/ **note:** Only standardValueSet metadata type is allowed in the seed-metadata folder 5. Move the \.standardValueSet-meta.xml file into the seedmetadata/standardValueSets/ directory you created. 6. Run the package conversion CLI command and specify the `--seed-metadata` flag and the path to your seed metadata file. sf package convert --package \<033xxxx\> --seed-metadata=\ ## Next Steps If you package encounter new errors for other picklist values, repeat these steps. # Troubleshoot the License Management App If you’re experiencing issues with the License Management App, review these troubleshooting tips. | Availability | | ------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, and **Unlimited** Editions | - **[Leads and Licenses Aren’t Being Created in the License Management App](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-troubleshoot-no-leads-licenses.md)** When a customer installs your package, leads and license records are created. If these records aren’t being created, review these configurations in the License Management Org (LMO). If you resolve your issue using one of these recommendations, your missing licenses appear in the LMA within a few days. - **[Proxy User Has Deactivated Message in the LMA](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/lma-troubleshoot-proxy-user.md)** If you’re editing a license and see a “proxy user has deactivated” message, it's possible that the subscriber org is locked, deleted, or disabled. # Turn Off Install Request Approvers Turn off Install Request Approvers to stop sending new install requests to approvers. To turn off Install Request Approvers: 1. From Setup, go to **Install Request Approvers**. 2. Turn off Install Request Approvers. The confirmation dialog title is **Turn off Install Request Approvers?** 3. Click **Turn Off** to confirm. Approvers no longer receive new requests. Salesforce preserves the approver list so that it's available if you turn the feature on again. **note:** When Install Request Approvers is off, Agentforce Builder users who can't install an app don't see the request form. For an app that isn't installed, they see **I'm Interested** instead. For information about sending an install request, see [Install and Update Agent Assets from AgentExchange](https://developer.salesforce.com/docs/platform/appexchange-install-guide/guide/agentexchange-agentforce-install-update-assets.md). # Turn On Install Request Approvers Turn on Install Request Approvers so that Agentforce Builder users who can't install an app can send an install request to a designated approver. To turn on Install Request Approvers: 1. From Setup, in the Quick Find box, enter `Install Request Approvers`, and then select **Install Request Approvers**. The Setup page title reads **Install App Request Approvers**. 2. Turn on Install Request Approvers. If the approver list is empty, Salesforce automatically adds you as the first approver. The page heading changes to Manage App Install Request Approvers after you turn on the feature. To add more approvers, see [Add Approvers](https://developer.salesforce.com/docs/platform/appexchange-install-guide/guide/agentexchange-agentforce-add-install-approvers.md). # Unauthorized Managed Packages To participate in the AgentExchange Partner Program, Salesforce’s partners must meet certain standards and submit their AgentExchange products for security review. When you install a managed package that the AgentExchange Partner Program hasn’t authorized for distribution, we notify you during installation. ![A view of the pre-installation notification that appears for unauthorized managed packages.](https://developer.salesforce.com/docs/media/shared/package_install_notification.png) The notification appears when you configure the package installation settings (1). Before you install the package, you must confirm that you understand that the package isn’t authorized for distribution (2). For information about the AgentExchange Partner Program and its requirements, visit the [Salesforce Partner Community](https://partners.salesforce.com/s/education/general/Partner_Program). For information about non-Salesforce providers, see our [Main Services Agreement](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/salesforce_MSA.pdf). # Understand Licensing in the Go-To-Market App When licensing products from the Go-To-Market (GTM) app, you can choose between two primary models, traditional package licenses and permission set licensing (PSL). To help understand which model best suits your business, let’s explore the differences between the two types. ## Traditional Package Licensing Traditional package licenses are the standard mechanism associated with first-generation (1GP) and second-generation (2GP) managed packages. When a user is assigned a package license, they are granted broad access to your app. All seats within a subscriber org are treated equally and reside in a single pool. This licensing model is ideal if: - You want a simpler, single-tier access control strategy. - You require seat utilization visibility in your Partner Business Org (PBO). Keep in mind that access control granularity only exists at the package level. Without technical enforcement for specific features, you must rely on contractual agreements and your customer's manual administration to make sure users only access the features they purchased. ## Permission Set Licensing Permission Set Licenses (PSLs) represent a modernized, feature-based licensing model designed specifically for 2GP packages. Rather than granting blanket access, PSLs allow you to programmatically gate functionality and create modular, tiered access models within a single managed package. PSLs embed access controls directly into the package using custom permissions and custom object CRUD. This allows you to sell different levels of access at different price points, and restrict access based on the assignee's user license type. This licensing model is ideal if: - Your product strategy requires feature-level access control and flexible pricing tiers. - You want automated technical enforcement of your apps and services. - You’re building new 2GP packages. - You’re comfortable designing feature gating using custom permissions. # Understand Permission Set Licenses Permission set licenses (PSLs) allow you to create tiered licensing models with custom permissions that you can distribute in your packages. The PSLs available for the Go-To-Market (GTM) app extend the Salesforce Permission Set License type. Using PSLs, you can define PSLDs within your packages, provision them to subscribers, and allow subscriber admins to administer package access. Partner PSLDs are defined in second generation package (2GP) metadata and are surfaced in subscriber orgs upon package install. Subscriber admins assign partner defined PSLs the same way they assign [Salesforce PSLs](https://help.salesforce.com/s/articleView?id=platform.users_permissionset_licenses_overview.htm&language=en_US&type=5). ## Prerequisites and Restrictions PSLs can be added in net new packages. You can't publish a package version with permission set license definitions (PSLD) if the previous version does not have PSLs. - The package must be 2GP. - Only US-based subscribers are able to purchase PSLs. - PSLs can be sold to paid production orgs, not sandboxes. ## Permission Set License Definition Metadata Type and Usage For detailed information, see [PermissionSetLicenseDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionsetlicensedefinition.htm). ## Example Permission Set License Definitions The following examples show different approaches to creating PSLDs. - **Base.permissionSetLicenseDefinition-meta.xml** Use this example to create a PSL that allows access to the unlicensed components of the package, using \Namespace\. In addition to allowing component access, this PSL allows users to receive read access to the Widget__c custom object, which requires a license to access. You can only assign this PSL to internal users. ```nolang Widget__c true false false false Namespace 10 30 ${internal} ``` - **Widget.permissionSetLicenseDefintion-meta.xml** Use this PSL to give assigned users full CRUD access to the Widget__c custom object. Since component access is none, it does not allow access to the unlicensed components in the package namespace and requires namespace access to be assigned. The assigned user must have a PSL with component access. ```nolang Widget__c true true true true None 10 30 ${internal} ``` - **BikeCard.permissionSetLicenseDefinition-meta.xml** Similar to the Widget PermissionSetLicenseDefinition, this example doesn't allow full component access to the package. It allows the user to be assigned the ViewBikeCard custom permission. ```nolang ViewBikeCard None 10 30 ${internal} ``` ## Component Access Namespace component access works like PackageLicense with a key difference: it allows access to unlicensed components in the entire namespace. In order for users to have any package access or be assigned PSLs in the package the user must have a PSL with component access assigned to them. For PSL-licensed packages, PackageLicenses can't be used to grant package access and aren't created for subscribers. A PSL with Namespace component access replaces the PackageLicense. PSLs with component access of "None" allow access to only licensed components in the namespace that the PSL references explicitly. ## Licensed and Unlicensed Components PSL-based packages can specify certain custom permissions and custom objects as "Licensed". This means that for a user to receive access to that component, they must have a license assigned that explicitly allows access. Namespace component access within a PSL isn't sufficient for receiving access to licensed components. Licensed components must be explicitly included in a PermissionSetLicenseDefintion for a user to receive access to those components. For example, BikeCard.permissionSetLicenseDefintion-meta.xml allows users to get full CRUD access to the licensed ViewBikeCard custom permission if they have the PSL assigned. The base component access license doesn't grant access to ViewBikeCard since ViewBikeCard is specified as requiring a license in the permission metadata. ## Using Licensed and Unlicensed Permissions We recommend flagging custom permissions and custom objects as Requires License if you want to monetize them separately from other parts of your package or they represent a premium feature in your package. Anything you want to include in your base tier should remain unlicensed, which means that having the base Component Access PSL grants access to those components. If you have an object or permission that represents a premium feature in your package, you can sell your base PSLs with component access but put your premium components in a separate PSL to monetize separately. ## Custom PSL Categories The `userLicenseRestrictions` field in a PSLD uses predefined categories to control which types of users can be assigned a given PSL. Categories map to the underlying user licenses in a subscriber org, and fall into two broad groups: internal users (those who log in directly to the Salesforce org) and external users (those who access the org through Experience Cloud sites). By setting `userLicenseRestrictions` on a PSLD, you can precisely scope each tier of your licensing model. For example, you can limit a PSL to internal platform users only, or make a separate PSL available exclusively to partner community members. This ensures that the right features reach the right audience without granting unintended access across user types. | Name | Description | API Name | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | All Internal Users | All users who can log in to the Salesforce org. Doesn't include Experience Cloud users. | \${internal} | | Internal Platform Users | Internal users who are able to log in to the Salesforce org with basic platform access. Includes Salesforce Platform, which is often sold by ISV partners as an OEM user license. | \${platform} | | All External Customer and Partner Members | All users who access Experience Cloud sites with a member-based user license. | \${communities} | | All External Customer and Partner Logins | All users who access Experience Cloud sites with a login-based user license. | \${communitiesLogin} | | External Customer Members | Users who access business-to-consumer Experience Cloud sites with a standard member-based user license. Includes Customer Community and Customer Community Plus. | \${customerCommunities} | | External Customer Logins | Users who access business-to-consumer Experience Cloud sites with a standard login-based user license. Includes Customer Community Login and Customer Community Plus Login. | \${customerCommunitiesLogin} | | External Partner Members | Users who access business-to-business Experience Cloud sites with a partner member-based user license. Includes Partner Community and Channel Account. | \${partnerCommunity} | | External Partner Logins | Users who access business-to-business Experience Cloud sites with a partner login-based user license. Includes Partner Community Login. | \${partnerCommunityLogin} | ## How Many PSLs Should My Package Contain? Your package namespace needs at least one PSLD, which is a component access PSL. We also recommend including PSLDs that represent tiers of access to the package. Beyond that, keep in mind that subscriber admins must assign permission set licenses to users, so including many granular PSLs may cause overhead for subscribers to use your package. ## Updating PermissionSetLicenseDefinition After Release The behavior of manageability rules fall into three categories: - **Allowed** - the change is allowed and is applied on package upgrade - **Blocked** - the change is disallowed and blocked at the time of package version creation - **Allowed but not applied on upgrade** - the change is allowed but not applied during package upgrade for existing subscribers **Allowed:** - Adding new licensed permissions or objects to a PSLD - Adding a new PSLD - Modifying the label of a PermissionSetLicenseDefinition - Adding a new CRUD piece for a custom object in a PSLD. For example: adding update when read was already in place - Modifying the UserLicenseRestrictions in a PermissionSetLicenseDefintion **Blocked:** - Modifications to ComponentAccess - Removing a PermissionSetLicenseDefintion from package metadata - Renaming a PermissionSetLicenseDefintion, label updates are allowed - Making a previously unlicensed object or permission licensed **Allowed but not applied on upgrade:** - Removing custom objects from a PSLD - Removing custom permissions from a PSLD ## Developer Setup and Packaging Prerequisites Scratch orgs used to build or test PSL packages must enable the PartnerLicensingAndProvisioningPlatform feature in project-scratch-def.json. Without it, creating a licensed custom permission fails when the package version is created because you don't have permission to create licensed custom permissions. ## How PSLDs Surface in the PBO for Product Mapping Once a package version containing PermissionSetLicenseDefinitions is released and the package has completed the AgentExchange Security Review, the PSLDs automatically surface in the partner's PBO on the Partner Permission Set License object. No manual other step is required to move a PSLD from the package into the PBO. ## Provisioning and Testing PSLs To provision licenses from the CLI, using the [sf license provision command](https://developer.salesforce.com/docs/platform/isvforce/guide/cli-reference-unified.md), install the license management plugin: [github.com/salesforcecli/plugin-license-management](https://github.com/salesforcecli/plugin-license-management). The provision commands aren't included in the base CLI and don't appear in the command list without it. PSL provisioning requires a namespaced scratch org in order to provision the PSLs. **See Also** - [Permission Set License](https://help.salesforce.com/s/articleView?id=platform.users_permissionset_licenses_overview.htm&language=en_US&type=5) - [PermissionSetLicenseDefinition](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionsetlicensedefinition.htm) - [License Management Plugin](https://github.com/salesforcecli/plugin-license-management) # Understanding Package Upgrades with Ancestry Review how package ancestry impacts which package version upgrades are allowed. Refer to this table and the package ancestry tree to understand whether your subscribers can upgrade between these 2GP package versions. **Example Package Ancestry Tree** ![Graphic of a package ancestry tree](https://developer.salesforce.com/media/pkg2_dev/pkg2_ancestry_upgrades.png) | Upgrade From | Upgrade To | Will This Package Upgrade Succeed? | | ------------ | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1.1 | 1.7 | Yes | | 1.3.2 | 1.3.4 | Yes. Both 1.3.2 and 1.3.4 are patch versions within the same major and minor version. You’re allowed to upgrade between patch versions that share the same major and minor version. | | 1.3.1 | 1.7 | Yes. 1.3.1 is a patch version. Because upgrading from 1.3 to 1.7 is allowed, you can also upgrade from 1.3.x to 1.7. | | 1.2 | 1.3 | No. These two versions don’t share an ancestry path. | | 1.5 | 1.7 | No. These two versions don’t share an ancestry path. | | 1.4 | 1.3.3 | No. Downgrading an installed package isn’t allowed. | | 1.0 | 1.8 | Yes | # Undertand Invoices and Payouts From the Invoices and Payouts tabs, you can see all of the payment documentation generated by Stripe and get a full picture of the related deadlines. To understand how payouts and invoices are created and tracked, let’s look at a larger view of the lifecycle. The diagram shows how Salesforce moves you and your customer through the process. After an offer is accepted and an order is generated, licenses are automatically provisioned and your customer can start using your products. From there, Stripe generates an invoice, sends it to your customer, and the invoice status is set to Pending. You can see the invoice and its status from the Invoices tab. ![Overview of the Partner Marketplace order to payout lifecycle.](https://developer.salesforce.com/docs/media/partner_marketplace_payouts.png) Your customer receives the invoice via email and navigates to Stripe to pay their balance. When the balance is settled, the invoice status moves to Paid. The customer payment is divided into the various buckets, including applicable taxes, the Salesforce revenue share, and partner net proceeds. # Uninstall a First-Generation Managed Package You can uninstall a first-generation managed package from an org using the Setup UI. When you uninstall a first-generation managed package, all components in the package, including any deprecated components that were previously associated with the package, are deleted from the org. 1. From Setup, enter `Installed Packages` in the Quick Find box, then select **Installed Packages**. 2. Click **Uninstall** next to the package that you want to remove. 3. Determine whether to save and export a copy of the package’s data, and then select the corresponding radio button. 4. Select **Yes, I want to uninstall** and click **Uninstall**. When you uninstall packages, consider the following: - If you’re uninstalling a package that includes a custom object, all components on that custom object are also deleted. Deleted items include custom fields, validation rules, custom buttons, and links, workflow rules, and approval processes. - You can’t uninstall a package whenever a component not included in the uninstall references any component in the package. For example: - When an installed package includes any component on a standard object that another component references, Salesforce prevents you from uninstalling the package. An example is a package that includes a custom user field with a workflow rule that gets triggered when the value of that field is a specific value. Uninstalling the package would prevent your workflow from working. - When you’ve installed two unrelated packages that each include a custom object and one custom object component references a component in the other, you can’t uninstall the package. An example is if you install an expense report app that includes a custom user field and create a validation rule on another installed custom object that references that custom user field. However, uninstalling the expense report app prevents the validation rule from working. - When an installed folder contains components you added after installation, Salesforce prevents you from uninstalling the package. - When an installed letterhead is used for an email template you added after installation, Salesforce prevents you from uninstalling the package. - When an installed package includes a custom field that’s referenced by Einstein Prediction Builder or Case Classification, Salesforce prevents you from uninstalling the package. Before uninstalling the package, edit the prediction in Prediction Builder or Case Classification so that it no longer references the custom field. - You can’t uninstall a package that removes all active business and person account record types. Activate at least one other business or person account record type, and try again. - You can’t uninstall a package if a background job is updating a field added by the package, such as an update to a roll-up summary field. Wait until the background job finishes, and try again. # Uninstall a Second-Generation Managed Package You can uninstall a second-generation managed package from an org using Salesforce CLI or from the Setup UI. When you uninstall second-generation managed packages, all components in the package, including any deprecated components that were previously associated with the package, are deleted from the org. To use the CLI to uninstall a package from the target org, authorize the Dev Hub org and run this command. ```nolang sf package uninstall --package "Expense Manager@2.3.0-5" ``` You can also uninstall a package from the web browser. Open the Salesforce org where you installed the package. ```nolang sf org open -u me@my.org ``` Then uninstall the package. 1. From Setup, enter `Installed Packages` in the Quick Find box, then select **Installed Packages**. 2. Click **Uninstall** next to the package that you want to remove. 3. Determine whether to save and export a copy of the package’s data, and then select the corresponding radio button. 4. Select **Yes, I want to uninstall** and click **Uninstall**. ## Considerations on Uninstalling Packages - If you’re uninstalling a package that includes a custom object, all components on that custom object are also deleted. Deleted items include custom fields, validation rules, custom buttons, and links, and approval processes. - You can’t uninstall a package whenever a component not included in the uninstall references any component in the package. For example: - When an installed package includes any component on a standard object that another component references, Salesforce prevents you from uninstalling the package. An example is a package that includes a custom user field with a workflow rule that gets triggered when the value of that field is a specific value. Uninstalling the package would prevent your workflow from working. - When you’ve installed two unrelated packages that each include a custom object and one custom object component references a component in the other, you can’t uninstall the package. An example is if you install an expense report app that includes a custom user field and create a validation rule on another installed custom object that references that custom user field. However, uninstalling the expense report app prevents the validation rule from working. - When an installed folder contains components you added after installation, Salesforce prevents you from uninstalling the package. - When an installed letterhead is used for an email template you added after installation, Salesforce prevents you from uninstalling the package. - When an installed package includes a custom field that’s referenced by Einstein Prediction Builder or Case Classification, Salesforce prevents you from uninstalling the package. Before uninstalling the package, edit the prediction in Prediction Builder or Case Classification so that it no longer references the custom field. - You can’t uninstall a package that removes all active business and person account record types. Activate at least one other business or person account record type, and try again. - You can’t uninstall a package if a background job is updating a field added by the package, such as an update to a roll-up summary field. Wait until the background job finishes, and try again. **See Also** - [_Salesforce CLI Command Reference_ package uninstall](https://developer.salesforce.com/docs/atlas.en-us.250.0.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_uninstall_unified) # Update the Solution in Your AgentExchange Listing If you revise a published solution, update your AgentExchange listing so that new customers get access to the latest version. If the solution is subject to security review, you can link the new version to your public listing before you submit the version for security review. However, in some cases, you can’t publish the updated listing until the new version passes. ## Before You Begin Before you update a managed-package solution, [check the listing-readiness status](https://developer.salesforce.com/docs/platform/isvforce/guide/security-review-check-listing-readiness.md) of the new package version. If the status is `Ready to List`, you can publish the updated listing without submitting the new version for security review. If the status is `Security Review Required`, you can’t publish until the version passes security review. ## Steps 1. Log in to the [Salesforce Partner Community](https://partners.salesforce.com/). 2. Click **Publishing**. 3. Click **Listings**. 4. Click the listing that you want to update. 5. Click **Link Your Solution**. 6. Locate the version of the solution that you want to associate with your listing. 7. Click **Listing Status**. 8. Click **Publish**. Congratulations! Your new version is available on AgentExchange. To help safeguard against the latest vulnerabilities, we conduct periodic security re-reviews of AgentExchange solutions. If the new version shows significant change, we’ll likely contact you to arrange a re-review of the new version. # Update Your First-Generation Managed Package Your app is ready for an update. Learn how to fix small issues with patches and make major changes with upgrades. - **[Package Versions in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/dev-package-versions-overview.md)** A package version is a number that identifies the set of components uploaded in a package. The version number has the format _majorNumber.minorNumber.patchNumber_ (for example, 2.1.3). - **[Create and Upload Patches in First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/patches-creating.md)** Patch versions are developed and maintained in a patch development org. - **[Work with Patch Versions](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-patches-about.md)** A patch version enables a developer to change the functionality of existing components in a managed package. Subscribers experience no visible changes to the package. Patches are minor upgrades to a Managed - Released package and only used for fixing bugs or other errors. - **[Versioning Apex Code](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-behavior-apex.md)** When subscribers install multiple versions of your package and write code that references Apex classes or triggers in your package, they must specify the version that they’re referencing. - **[Apex Deprecation Effects for Subscribers](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-effects-subscribers.md)** Explore how deprecation of an Apex method impacts subscribers that install your managed package. # Update Your Trialforce Template If you update your solution or custom branding, update your Trialforce template to reflect the changes. If you use SignupRequest API to deliver trials, log a case to approve the new template. If you deliver trials using AgentExchange only, skip this step. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To manage Trialforce:|Modify All Data| |To create or update AgentExchange listings:|Manage Listings| ## Steps 1. Install your updated managed package or extension package into your Trialforce Source Org (TSO). 2. Update your TSO. For example, add fresh sample data or update the custom branding. 3. Create an updated Trialforce template. 4. If you deliver trials on AgentExchange, add the updated template to your listing in the AgentExchange Partner Console. 5. If you use SignupRequest API to deliver trials, log a case to approve the new template. 1. Log in to [Salesforce Help](https://help.salesforce.com/s/) with the username that you used to register for the Salesforce Partner Community. 2. Click **?**, and then click **Log a Case for Help**. 3. For Subject, enter `Requesting Trialforce Template Approval`. 4. For Description, note that you’re a Salesforce partner and you’re requesting your TMO. Include your TSO ID, the updated Trialforce template ID, and the org to use for creating signups. 5. When prompted to select a product, click **Pick a different product / topic**. 6. For Product, select **Partner Programs & Benefits**. 7. For Topic, select **ISV Technology Request**. 8. Select an instance type and severity level. 9. Click **Create a Case**. **See Also** - [Create and Manage Trialforce Source Orgs](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-create-source-organization.md) - [Create a Trialforce Template](https://developer.salesforce.com/docs/platform/isvforce/guide/trialforce-creating-template.md) - [Provide Free Trials on Your AgentExchange Listing Using a Trialforce Template](https://developer.salesforce.com/docs/platform/isvforce/guide/free-trial-appexchange-trialforce.md) # Upgrade a Second-Generation Managed Package Version A package upgrade occurs when you install a new package version into an org that has a previous version of that package installed. When you perform a package upgrade, here’s what to expect for metadata changes. - Metadata introduced in the new version is installed as part of the upgrade. - Metadata modified in the new version is updated as part of the upgrade. - Metadata removed in the new version is either deprecated or deleted as part of the upgrade. To upgrade a package, use the package install CLI command ```nolang sf package install --package 04t... --target-org me@example.com ``` For more examples and details about this command, see [package install](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_install_unified) in the _Salesforce CLI Command Reference_. Beta packages aren’t upgradeable. To install a new beta package or released version, first uninstall the beta package. To upgrade a package version, the new version must be a direct descendent of the package version installed in your org. See [Specify a Package Ancestor in the Project File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-config-ancestors.md) for more information. **See Also** - [_Salesforce CLI Command Reference_ package install](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_install_unified) # Use a Federation ID or Formula for SSO You can match an Environment Hub user with a user in a member org using a Federation ID or a user name formula. For either method, enable SSO in the hub member org first. ## Before You Begin |User Permissions Needed| | |-----------------------|--| |To set up and configure the Environment Hub:|Manage Environment Hub| ## Steps 1. Log in to the Environment Hub, and then select a member org. If you don’t see any member orgs, check your list view. 2. Go to SSO Settings, and then choose a method. | Method | Steps | | ------ | ----- | | **SSO Method 2 - Federation ID**
Match users who have the same Federation ID in both the Environment Hub and a member org. | Select the checkbox. | | **SSO Method 3 - User Name Formula**
Match users in the Environment Hub and a member org according to a formula that you define. | Select the checkbox, and then define a formula. For example, to match the first part of the username (the part before the “@” sign) with an explicit domain name, enter:
`LEFT($User.Username, FIND(“@”, $User.Username)) & (“mydev.org”)` | 3. Select **Save**. # Use a URL to Install a Second-Generation Managed Package Install a second-generation managed package from a browser. If you create packages from the CLI, you can derive an installation URL for the package by adding the subscriber package ID to your Dev Hub URL. You can use this URL to test different deployment or installation scenarios. For example, if the package version has the subscriber package ID, 04tB00000009oZ3JBI, add the ID as the value of apvId. `https://_MyDomainName_.lightning.force.com/packagingSetupUI/ipLanding.app?apvId=04tB00000009oZ3JBI` Anyone with the URL and a valid login to a Salesforce org can install the package. To install the package: 1. In a browser, enter the installation URL. 2. Enter your username and password for the Salesforce org in which you want to install the package, and then click **Login**. 3. If the package is protected by an installation key, enter the installation key. 4. For a default installation, click **Install**. A message describes the progress. You receive a confirmation message when the installation is complete. **See Also** - [_Salesforce Help:_ Determine Which Users Can Access a Package](https://help.salesforce.com/s/articleView?id=xcloud.pkg_subscriber_determine_access.htm&type=5) # Use Branches in Second-Generation Managed Packaging Development teams who use branches in their source control system (SCS), often build package versions based on the metadata in a particular branch of code. To identify which branch in your SCS a package version is based on, tag your package version with a branch name using `--branch` attribute in this Salesforce CLI command. `sf package version create --branch featureA` You can specify any alphanumeric value up to 240 characters as the branch name. You can also specify the branch name in the package directories section of the `sfdx-project.json` file. ```nolang "packageDirectories": [ { "path": "util", "default": true, "package": "pkgA", "versionName": "Spring ‘21", "versionNumber": "4.7.0.NEXT", "branch": "featureA" }] ``` When you specify a branch, the package alias for that package version is automatically appended with the branch name. You can view the package alias in the `sfdx.project.json` file. ```nolang "packageAliases": { "pkgA@1.0.0.4-featureA":"04tB0000000IB1EIAW"} ``` Keep in mind that version numbers increment within each branch, and not across branches. For example, you could have two or more beta package versions with the version number 1.3.0.1. | Branch Name | Package Version Alias | | ------------- | --------------------- | | featureA | pkgA@1.3.0-1-featureA | | featureB | pkgA@1.3.0-1-featureB | | Not specified | pkgA@1.3.0-1 | Although more than one beta package version can have the same version number, there can be only one promoted and released package version for a given major.minor.patch package version. ## Package Dependencies and Branches By default, your package can have dependencies on other packages in the same branch. For package dependencies based on packages in other branches, explicitly set the branch attribute in the `sfdx.project.json` file. | To specify a package dependency | Use this format | | ----------------------------------------------------------------------------------------- | --------------------------------- | | Using the branch attribute | See the example after this table. | | Using the most recent promoted and released version of package | See the example after this table. | | If your package has an associated branch, but the dependent package doesn’t have a branch | See the example after this table. | | Using the package alias | See the example after this table. | Example: Using the branch attribute ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "1.3.0.LATEST", "branch": "featureC" }] ``` Example: Using the most recent promoted and released version of package ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "2.1.0.RELEASED" }] ``` Example: Dependent package has no branch ```nolang "dependencies": [ { "package": "pkgB", "versionNumber": "1.3.0.LATEST", "branch": "" }] ``` Example: Using the package alias ```nolang "dependencies": [ { "package": "pkgB@2.1.0-1-featureC" }] ``` # Use LMO-to-Subscriber Feature Parameters to Enable and Disable Features Feature parameters with a data flow direction value of `LMO to Subscriber` are writable at your end and read-only in your subscriber’s org. These feature parameters serve as permissions or limits. Use LMO-to-subscriber feature parameters to enable or disable new features or to control how many of a given resource your subscriber can use. Or, enable features for a limited trial period. Assign values to LMO-to-subscriber feature parameters by updating junction object records in your LMO, and then check those values in your code. - **[Assign Override Values in Your LMO](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-assign-override-values.md)** To override the default value of a feature parameter in a subscriber’s org, update the appropriate junction object record in your LMO. - **[Check LMO-to-Subscriber Values in Your Code](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/fma-check-lmo-to-subscriber-values.md)** You can reference feature parameters in your code, just like you’d reference any other custom object. # Use LMO-to-Subscriber Feature Parameters to Enable and Disable Features Feature parameters with a data flow direction value of `LMO to Subscriber` are writable at your end and read-only in your subscriber’s org. These feature parameters serve as permissions or limits. Use LMO-to-subscriber feature parameters to enable or disable new features or to control how many of a given resource your subscriber can use. Or, enable features for a limited trial period. Assign values to LMO-to-subscriber feature parameters by updating junction object records in your LMO, and then check those values in your code. - **[Assign Override Values in Your LMO](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/fma-assign-override-values.md)** To override the default value of a feature parameter in a subscriber’s org, update the appropriate junction object record in your LMO. - **[Check LMO-to-Subscriber Values in Your Code](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/pd-fma-check-lmo-to-subscriber-values.md)** You can reference feature parameters in your code, just like you’d reference any other custom object. # Use Managed Packages to Develop Your AgentExchange Solution Managed packages are the tool that Salesforce partners use to create business apps, and distribute their apps to customers via AgentExchange. The suite of capabilities offered by managed packages helps you distribute, license, pilot features, troubleshoot, and monetize your offerings. A package is a container for an app that you plan to sell and distribute to Salesforce customers. You create a package, then add the features, customizations, and schema that comprise your app. Examples of metadata components you might package are: - Apex classes and triggers - Custom fields on standard objects - Custom metadata types - Custom objects - Flows - Lightning pages - Page layouts Your package can include many different metadata components, or you can package a single component, such as a flow. Salesforce offers second-generation managed packaging (managed 2GP) and first-generation managed packaging (managed 1GP). Going forward we recommend that everyone use managed 2GPs to create new apps. For details on the advantages of using second-generation managed packaging, see [Why Switch to Second-Generation Managed Packaging?](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/why_switch_2GP.htm) **See Also** - [*Second-Generation Managed Packaging Developer Guide*](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp.htm) - [*First-Generation Managed Packaging Developer Guide*](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/sharing_apps.htm) # Use Permission Set Licenses to Sell Tier-Based Products Permission set licenses (PSL) help you monetize specific features and easily create flexible pricing tiers for your second-generation managed packages. By building access controls directly into your app, you make sure that customers only access the exact features they purchase. The Go-To-Market (GTM) app automatically delivers the correct feature-based licenses to your subscribers, which save you valuable time and safely protects your revenue. To implement and sell feature-based product tiers, use permission set licenses (PSLs) in the GTM app. ## Step 1: Understand Packaging Prerequisites. 1. Build your app as a new package, using Second-Generation Packaging (2GP). If you’re currently using First-Generation Packaging (1GP), migrate your package to 2GP. PSLs can’t be added to a released package. 2. Don’t rely on upgrade paths. Package upgrades aren’t supported. 3. Determine your licensing strategy. You can choose between foundational PSLs and optional PSLs. 4. Test your PSL behavior in a scratch org. ## Step 2: Define Your Access Controls. 1. Embed your access controls directly within your managed package. 2. Create custom permissions and configure object-level CRUD access. 3. Associate custom permissions with your PSLs to technically enforce specific pricing tiers. ## Step 3: Configure Partner Product Licenses (PPLs) 1. Access the products from the GTM app. 2. Connect your Dev Hub to locate and configure your PPLs, which represent the underlying PSLs within your package. ## Step 4: Map Licenses to Sellable Products 1. Create Partner Provision Products (PPPs) to represent the specific tiers or features you want to sell. 2. Map your technical PPLs and their associated quantities directly to these PPPs. This step bridges your technical package configuration with your commercial catalog. ## Step 5: Create and Send Private Offers 1. When negotiating a deal, create a private offer and select the specific PPPs that match the customer's feature tier. 2. Specify the quantities and pricing. 3. Send the offer directly to the customer's org. ## Step 6: Use Automated Provisioning. When the customer accepts your offer and the order reaches its start date, the GTM app automation takes over. The system delivers the correct PSLs to the subscriber’s org, eliminating manual license management and granting the customer access to the features they purchased. # Use the CLI to Install a Second-Generation Managed Package If you’re working with the Salesforce CLI, you can use the `sf package install` command to install packages in a scratch org or target subscriber org. Before you install a second-generation managed package (managed 2GP) in a scratch org, run this command to list all the packages and locate the ID or package alias. ```nolang sf package version list ``` Identify the version you want to install. Enter this command, supplying the package alias or package ID (starts with 04t). ```nolang sf package install --package "Expense Manager@1.2.0-12" --target-org jdoe@example.com ``` By default, the package install command provides admins access to the installed package. To provide access to all users, specify `--security-type AllUsers` when you run the package install command. If you’ve already set the scratch org with a default username, enter just the package version ID. ```nolang sf package install --package "Expense Manager@1.2.0-12" ``` **note:** If you’ve defined an alias (with the `-a` parameter), you can specify the alias instead of the username for `--target-org`. The CLI displays status messages regarding the installation. ```nolang Waiting for the subscriber package version install request to get processed. Status = InProgress Successfully installed the subscriber package version: 04txx0000000FIuAAM. ``` ## Control Managed 2GP Package Installation Timeouts When you issue a `sf package install` command, it takes a few minutes for a package version to become available in the target org and for installation to complete. To allow sufficient time for a successful install, use these parameters that represent mutually exclusive timers. - `--publish-wait` defines the maximum number of minutes that the command waits for the package version to be available in the target org. The default is 0. If the package is not available in the target org in this time frame, the install is terminated. Setting `--publish-wait` is useful when you create a new package version and then immediately try to install it to target orgs. **note:** If `--publish-wait` is set to 0, the package installation immediately fails, unless the package version is already available in the target org. - `--wait` defines the maximum number of minutes that the command waits for the installation to complete after the package is available. The default is 0. When the --wait interval ends, the install command completes, but the installation continues until it either fails or succeeds. You can poll the status of the installation using `sf package install report`. **note:** The `--wait` timer takes effect after the time specified by `--publish-wait` has elapsed. If the `--publish-wait` interval times out before the package is available in the target org, the `--wait` interval never starts. For example, consider a package called Expense Manager that takes five minutes to become available on the target org, and 11 minutes to install. The following command has `publish-wait` set to three minutes and `wait` set to 10 minutes. Because Expense Manager requires more time than the set `publish-wait` interval, the installation is aborted at the end of the three-minute `publish-wait` interval. ```nolang sf package install --package "Expense Manager@1.2.0-12" --publish-wait 3 --wait 10 ``` The following command has `publish-wait` set to six minutes and `wait` set to 10 minutes. If not already available, Expense Manager takes five minutes to become available on the target org. The clock then starts ticking for the 10-minute `wait` time. At the end of 10 minutes, the command completes because the `wait` time interval has elapsed, although the installation is not yet complete. At this point, `sf package install report` indicates that the installation is in progress. After one more minute, the installation completes and `sf package install report` indicates a successful installation. ```nolang sf package install --package "Expense Manager@1.2.0-12" --publish-wait 6 --wait 10 ``` **See Also** - [_Salesforce CLI Command Reference_ package install](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_package_commands_unified.htm#cli_reference_package_install_unified) - [_Salesforce Help:_ Determine Which Users Can Access a Package](https://help.salesforce.com/s/articleView?id=xcloud.pkg_subscriber_determine_access.htm&type=5) # Using Apex in Group and Professional Editions Your app can contain business logic such as classes, triggers, email services, etc. written in Apex. As a general rule, Apex is not supported in GE/PE, so it will not run in these editions. However, Apex developed as part of an ISV app and included in a managed package can run in GE/PE, even though those editions do not support Apex by default. You must be an eligible partner with Salesforce and your app has to pass the security review. The appropriate permissions will automatically be enabled after you pass the security review. Here are some important considerations for using Apex in GE/PE. - GE/PE customers can’t create or modify Apex in your app; they can only run the existing Apex. - Your Apex code should not depend on features and functionality that exist only in DE, EE, UE, or PXE, or your app will fail to install. - Make sure to use REST if you plan to expose an Apex method as a Web service. Apex classes that have been exposed as a SOAP Web service can’t be invoked from an external web app in GE/PE. - Using Apex to make Web service callouts is allowed in GE/PE. For instance, if you’re planning to make a Web service callout to an external Web service, as long as the managed package is authorized, these classes will function in GE/PE. # Verify Access to Your Salesforce Partner Business Org As a Salesforce partner, you’re eligible for a Partner Business Org (PBO). Your PBO contains tools for setting up and managing an ISV business or consulting practice. Before you start building your solution or practice, verify that you can access your PBO. 1. [Log in to Salesforce](https://login.salesforce.com/) with the username and password that you created when you joined the Partner Community. 2. Click the App Launcher. 3. In the Quick Find box, enter `Environment Hub`, and then click **Environment Hub**. 4. If you’re redirected to the Environment Hub app, you verified your PBO access. If the Environment Hub app isn’t available in the Quick Find box, log a case on [Salesforce Help](https://help.salesforce.com) to request a PBO. ## Next Steps To learn more about your PBO, register for Get to Know Your Partner Business Organization (PBO) Tools on the [Salesforce Partner Learning Camp](https://partnerlearningcamp.salesforce.com/s/learner-dashboard) (login required). # Versioning Apex Code When subscribers install multiple versions of your package and write code that references Apex classes or triggers in your package, they must specify the version that they’re referencing. Within the Apex code that is being referenced in your package, you can conditionally execute different code paths based on the version setting of the calling Apex code that is making the reference. The package version setting of the calling code can be determined within the package code by calling the `System.requestVersion` method. In this way, package developers can determine the request context and specify different behavior for different versions of the package. The following sample shows different behavior in a trigger for different package versions: ```apex_code trigger oppValidation on Opportunity (before insert, before update) { for (Opportunity opp : Trigger.new){ // Add a new validation to the package // Applies to versions of the managed package greater than 1.0 if (System.requestVersion().compareTo(new Version(1,0)) > 0) { if (opp.Probability >= 50 && opp.Description == null) { opp.addError('All deals over 50% require a description'); } } // Validation applies to all versions of the managed package. if (opp.IsWon == true && opp.LeadSource == null) { opp.addError('A lead source must be provided for all Closed Won deals'); } } } ``` To compare different versions of your Apex classes, click the **Class Definition** tab when viewing the class details. For more information about the `System.requestVersion` method, see the [Apex Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_version.htm). # View All Package Versions in the Org View the details about all package versions in the org. 1. From the project directory, run the `list` command. `sf package1 version list` The output is similar to this example. When you view the package versions, the list shows a single package for multiple package versions. ```nolang METADATAPACKAGEVERSIONID METADATAPACKAGEID NAME VERSION RELEASESTATE BUILDNUMBER ──────────────────────── ────────────────── ──── ─────── ──────────── ─────────── 04txx000000069oAAA 033xx00000007coAAA r00 1.0.0 Released 1 04txx000000069tAAA 033xx00000007coAAA r01 1.1.0 Released 1 04txx000000069uAAA 033xx00000007coAAA r02 1.2.0 Released 1 04txx000000069yAAA 033xx00000007coAAA r03 1.3.0 Released 1 04txx000000069zAAA 033xx00000007coAAA r04 1.4.0 Released 1 ``` **See Also** - [_Salesforce CLI Command Reference_](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference) # View Details about a Second-Generation Managed Package Version Retrieve details about second-generation managed package versions that are in progress, or have already been created. ## View Status and Progress Details for a Managed 2GP Package Version Depending on the package size and other variables, creating a package version can be a long-running process. You can easily view the status and monitor progress using this report command. ```no_highlighting sf package version create report --package-create-request-id 08cxx00000000YDAAY ``` The output shows details about the request. ```nolang === Package Version Create Request NAME VALUE ───────────────────────────── ──────────────────── Version Create Request Id 08cB00000004CBxIAM Status InProgress Package Id 0HoB00000004C9hKAE Package Version Id 05iB0000000CaaNIAS Subscriber Package Version Id 04tB0000000NOimIAG Tag git commit id 08dcfsdf Branch CreatedDate 2018-05-08 09:48 Installation URL https://login.salesforce.com/packaging/installPackage.apexp?p0=04tB0000000NOimIAG ``` You can find the request ID (08c) in the initial output of `sf package version create`. If you have more than one pending request to create package versions, you can view a list of all requests with this command. ```nolang sf package version create list --created-last-days 0 ``` Details for each request display as shown here (IDs and labels truncated). ```nolang === Package Version Create Requests [3] ID STATUS PACKAGE2 ID PKG2 VERSION ID SUB PKG2 VER ID TAG BRANCH CREATED DATE === 08c... Error 0Ho... 08c... Success 0Ho... 05i... 04t... 2022-06-22 12:07 08c... Success 0Ho... 05i... 04t... 2022-06-23 14:55 ``` ## Retrieve List of all Package Versions Associated with a Dev Hub Org To display a list of all package versions in the Dev Hub org, use this command. ```nolang sf package version list --target-dev-hub my-hub ``` You can view the namespace, version name, and other details in the output. ```nolang Package Name Namespace Version Sub Pkg Ver Id Alias Installation Key Released ─────────────── ─────────────── ─────── ─────────────────── ──────────────────────── ───────────────── ─────── Expenser Schema db_exp_manager 0.1.0.1 04tB0000000719qIAA Expenser Schema@0.1.0-1 false true Expenser Schema db_exp_manager 0.2.0.1 04tB000000071AjIAI Expenser Schema@0.2.0-1 false true Expenser Schema db_exp_manager 0.3.0.1 04tB000000071AtIAI Expenser Schema@0.3.0-1 false false Expenser Schema db_exp_manager 0.3.0.2 04tB000000071AyIAI Expenser Schema@0.3.0-2 false true Expenser Schema db_exp_manager 0.3.1.1 04tB0000000KGU6IAO Expenser Schema@0.3.1-1 false false Expenser Schema db_exp_manager 0.3.1.2 04tB0000000KGUBIA4 Expenser Schema@0.3.1-2 false true Expenser Schema db_exp_manager 0.3.2.1 04tB0000000KGUQIA4 Expenser Schema@0.3.2-1 false true Expenser Logic db_exp_manager 0.1.0.1 04tB0000000719vIAA Expenser Logic@0.1.0-1 false true Expenser App db_exp_manager 0.1.0.1 04tB000000071A0IAI Expenser App@0.1.0-1 false true ``` To view details about a specific package, include `--package` parameter when you run `sf package version list`. To show expanded details, use `--verbose` The verbose parameter displays these additional details. - Ancestor - Ancestor Version - Branch - Build Duration in Seconds - Code Coverage - Code Coverage Met - Created By - Created Date - Description - Installation URL - Language - Managed Metadata Removed - Metadata File Size - Number of Metadata Files - Package ID - Package Version ID - Release Version - Tag - Validation Skipped - WasTransferred # View Details about Your Converted 2GP Package So you’ve converted your 1GP package to a 2GP package. You can use one of two Salesforce CLI commands to retrieve details about your 2GP packages. To see details about the new managed 2GP package, run: ```nolang sf package list --verbose ``` In the verbose command output, there's a column labeled Converted From Package Id. When that field is populated it indicates that the package was originally created using 1GP, and has been converted to 2GP. The 033 ID that displays in that column maps to the original 1GP package. To see details about the new managed 2GP package version, run: ```nolang sf package version list ``` If the value in the Released column of the command output is `false`, this indicates that the package is a beta package version, and you must promote the package to the managed-released state before you migrate the package. See [Get Ready to Promote and Release a Second-Generation Managed Package Version](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_get_ready_promote.htm). The package convert command creates a new managed 2GP package, and a new managed 2GP package version, and both are now associated with your Dev Hub org. The association between the Dev Hub org and your package can’t be changed. And you can't associate the package with a second, separate Dev Hub org. This means any subsequent package conversions you initiate for this package, must be associated with the Dev Hub org you specified the first time you converted a particular package. # View Information About a Package View the details about a specific package version, including its metadata package ID, package name, release state, and build number. 1. From the project directory, run this command, supplying a package version ID. `sf package1 version display -i 04txx000000069yAAA` The output is similar to this example. ```nolang METADATAPACKAGEVERSIONID METADATAPACKAGEID NAME VERSION RELEASESTATE BUILDNUMBER ──────────────────────── ────────────────── ──── ─────── ──────────── ─────────── 04txx000000069yAAA 033xx00000007coAAA r03 1.3.0 Released 1 04txx000000069yAAA 033xx00000011coAAA r03 1.4.0 Released 1 ``` - **[View All Package Versions in the Org](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-man-pack-viewinfo-all-pack.md)** View the details about all package versions in the org. - **[Package IDs](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/sfdx-dev-build-package-ids.md)** When you work with packages using the CLI, the package IDs refer either to a unique package or a unique package version. **See Also** - [_Salesforce CLI Command Reference_](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference) # View Package Ancestry Use Salesforce CLI commands to quickly confirm your package’s ancestor, or to create a visualization of the package ancestry tree. ## View Package Ancestor Details in Salesforce CLI Use the `sf package version report` or `sf package version list` command to view the name and version number of the package ancestor. Output from `sf package version report` command. ![Output from package:version:list command](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_cli_report.png) Output from `sf package version list` command. ![Output from package:version:report command](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_cli_list.png) ## Visualize Package Ancestry Use the `displayancestry` CLI command to create visualizations of your package or package version’s ancestry tree. You can view the visualization in Salesforce CLI or use the dot-code parameter to generate output that can be used in graph visualization software. Use `sf package version displayancestry` to quickly visualize your package ancestry and understand the possible package upgrade paths. ![Graphic tree visualization for package:version:create](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_ancestry.png) ![Graphic tree visualization for package:create](https://developer.salesforce.com/media/pkg2_dev/sfdx_packaging_package_version_ancestry.png) To generate dotcode output, specify `sf package version displayancestry --dot-code`. # View Package Details for a Second-Generation Managed Package View the details of previously created second-generation managed packages from the command line. To display a list of all packages in the Dev Hub org, use this command. ```nolang sf package list --target-dev-hub my-hub ``` You can view the namespace, package name, ID, and other details in the output. ```nolang Namespace Prefix Name Id Alias Description Type ─────────────── ──────────────── ────────────────── ──────────── ─────────── ─────── db_exp_manager Expenser App 0HoB00000004CzRKAU Expenser App Managed db_exp_manager Expenser Logic 0HoB00000004CzMKAU Expenser Logic Managed db_exp_manager Expenser Schema 0HoB00000004CzHKAU Expenser Schema Managed ``` Include optional parameters to filter the list results based on the modification date, creation date, and to order by specific fields or package IDs. To limit the details, use `--concise`. To show expanded details, use `--verbose` The verbose parameter displays these additional details. - Created By - Error Notification Username - Subscriber Package ID # View Package Details in First-Generation Managed Packages From Setup, enter `Packages` in the Quick Find box, then select **Packages**. Click the name of a package to view its details, including added components, whether it’s a managed package, whether the package has been uploaded, and so on. From the package detail page: - To change the package name, the custom link that displays when users click Configure, or the description, click **Edit**. - To delete the package, click **Delete**. This action doesn’t delete the components contained in the package, but the components are no longer bundled together within this package. - To upload the package, click **Upload**. You’re notified by email when the upload is complete. - You can enable, disable, or change the dynamic Apex and API access that components in the package have to standard objects in the installing org by using the links next to API Access. ## View Package Details For package developers, the package detail section displays these attributes (in alphabetical order). | Attribute | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | API Access | The type of access that the API and dynamic Apex that package components have. The default is **Unrestricted**, which means that all package components that access the API have the same access as the user who is logged in. Click **Enable Restrictions** or **Disable Restrictions** to change the API and dynamic Apex access permissions for a package. | | Created By | The name of the developer that created this package, including the date and time. | | Description | A description of the package. | | Language | The language used for the labels on components. The default value is your user language. | | Last Modified By | The name of the last user to modify this package, including the date and time. | | Notify on Apex Error | The username of the person who receives email notifications when an exception occurs in Apex that isn’t caught by the code. If you don’t specify a username, all uncaught exceptions send an email notification to Salesforce. Available only for managed packages. Apex can be packaged only from Developer, Enterprise, Unlimited, and Performance Edition orgs. | | Notify on Packaging Error | The email address of the person who receives email notifications if an error occurs when a subscriber’s attempt to install, upgrade, or uninstall a packaged app fails. This field appears only if packaging error notifications are enabled. To enable notifications, contact your Salesforce representative. | | Package Name | The name of the package, provided by the publisher. | | Push Upgrade Exclusion List | A comma-separated list of org IDs to exclude when you push a package upgrade to subscribers. | | Post Install Script | The Apex code that runs after this package is installed or upgraded. For more information, see [Run Apex on Package Install/Upgrade](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-post-install-script.md). | | Type | Indicates whether it’s a managed or unmanaged package. | | Uninstall Script | The Apex code that runs after this package is uninstalled. For more information, see [Run Apex on Package Uninstall](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/apex-uninstall-script.md). | ## View Package Components The Components tab lists each package component contained in the package, including the name and type of each component. **note:** Some related components are automatically included in the package even though they aren’t displayed in the Package Components list. For example, when you add a custom object to a package, its custom fields, page layouts, and relationships with standard objects are included. For a list of components that Salesforce automatically includes, see [Components Automatically Added](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-components-auto-added.md). Package components frequently depend on other components that aren’t always added to the package explicitly. Each time you change a package, Salesforce checks for dependencies and displays the components as package members. Package Manager checks for dependencies and shows the component relationship to the package in the Include By column of the Package Details. When your package contains 1,000 or more components, you can decide when to refresh the components list in the Package Details and avoid a long wait while this page loads. The components list refreshes automatically for packages with less than 1,000 components. Click **Refresh Components** if the package has new or changed components, and wait for the list to refresh. Click **View Dependencies** to review a list of components that rely on other components, permissions, or preferences within the package. An entity can include such things as a standard or custom field, or an organization-wide setting like multicurrency. Your package can’t be installed unless the installer has the listed components enabled or installed. Click **Back to Package** to return to the Package detail page. Click **View Deleted Components** to see which components were deleted from the package across all its versions. ## View Version History For package developers, the Versions tab lists all the previous uploads of a package. To manage an uploaded package version, click the version number of a listed upload. For more information, see [Manage Versions of First-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/managing-uploads.md). To [automatically upgrade subscribers to a specific version](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/push-upgrade-scheduling.md), click **Push Upgrades**. Orgs entered in the Push Upgrade Exclusion List are omitted from the upgrade. The orgs can still install the upgrade when you publish the new version. **note:** Push Upgrades is available for patches and major upgrades. Salesforce Partners can request Push Major Upgrade functionality. Log a support case in the [Salesforce Partner Community](https://partners.salesforce.com). The versions table displays the package attributes (in alphabetical order). | Attribute | Description | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Action | Lists the actions you can perform on the package. The possible actions are **Deprecate**—Deprecates a package version. Users can no longer download or install this package. However, existing installations continue to work. **Undeprecate**—Enables a previously deprecated package version to be installed again. | | Status | The status of the package. The possible statuses are Released (the package is Managed - Released), Beta (the package is Managed - Beta), or Deprecated (the package version is deprecated). | | Version Name | The version name for this package. The version name is the marketing name for a specific release of a package. It’s more descriptive than Version Number. | | Version Number | The version number for the latest installed package version. The format is _majorNumber.minorNumber.patchNumber_, such as 2.1.3. The version number represents a release of a package. Version Name is a more descriptive name for the release. The patchNumber is generated only when you create a patch. If there’s no patchNumber, it’s assumed to be zero (0). | ## View Patch Development Orgs Each patch is developed in a patch development org, which is the org where patch versions are developed, maintained, and uploaded. To start developing a patch, create a patch development org. [Create and Upload Patches](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/patches-creating.md) Patch development orgs permit developers to change existing components without causing incompatibilities between existing subscriber installations. Click **New** to create a patch for this package. The Patch Organizations table lists all the patch development orgs created. It lists these attributes (in alphabetical order). | Attribute | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Action | Lists the actions that you can perform on a patch development org. The possible actions are **Login**—Log in to your package version, or **Reset**—Emails a temporary password for your patch development org. | | Administrator Username | The login associated with the patch org. | | Patching Major Release | The package version number that you’re patching. | # View Unused Components in a Managed Package View components no longer being used in the current version of a package. | Availability | | ---------------------------------------------------------------------------------------- | | Available in: Salesforce Classic | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | Any component shown here that’s part of a managed package is safe to delete unless you’ve used it in custom integrations. After you've deleted an unused component, it appears in this list for 15 days. During that time, you can either undelete it to restore the component and all data stored in it, or delete the component permanently. When you undelete a custom field, some properties on the field will be lost or changed. After 15 days, the field and its data are permanently deleted. **note:** Before deleting a custom field, you can keep a record of its data. From Setup, enter `Data Export` in the Quick Find box, then select **Data Export**. The following component information is displayed (in alphabetical order): | Attribute | Description | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Action | Can be one of two options:**Undelete** or **Delete** | | Name | Displays the name of the component. | | Parent Object | Displays the name of the parent object a component is associated with. For example, a custom object is the parent of a custom field. | | Type | Displays the type of the component. | # View Your Private AgentExchange Listings You can make your listing private so it isn't discoverable on AgentExchange. Rarely, Salesforce removes a published listing from AgentExchange and tags it as private, usually because of issues discovered during a security review. Private listings don't appear on AgentExchange. View these listings in the Partner Console. 1. Go to the Partner Console. See [Access the AgentExchange Partner Console](https://developer.salesforce.com/docs/platform/isvforce/guide/appexchange-launch-partner-console.md). 2. Click **Listings**. 3. Click **Filter By**. 4. Select **Not Published** to show all your private listings, including the listings that Salesforce has removed. # Visualforce Interactions Each record in your package usage log that has a `custom_entity_type` of `VisualforcePage` describes an interaction with your packaged Visualforce pages. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | ## Visualforce Requests When a user performs an action that results in a request associated with your VisualForce page, `log_record_type` equals `VisualforceRequest`. One standard field is always populated with data: `url`. Visualforce page requests also have supplemental fields that are often populated. For example, a Visualforce page request sometimes also has `request_status` and `referrer_uri data`. Use these fields to explore the details of the Visualforce request. | Standard Data | Supplemental Data | | ------------- | ---------------------------------------------------------------------------------------------------------- | | `url` |
  • `request_status`
  • `referrer_uri`
  • `request_status`
  • `response_size`
| ## Example Let’s look at an example package usage log record and analyze the Visualforce request. ```nolang { "timestamp_derived": "2022-11-22T06:23:23.836Z", "log_record_type": "VisualforceRequest", "request_id": "4mbi9e1ZVef83tlq2Z5aAk", "organization_id": "00Dxx0000006H2l", "organization_name": "MyCustomer Inc.", "organization_status": "Demo", "organization_edition": "Enterprise Edition", "organization_country_code": "IN", "organization_language_locale": "en_US", "organization_time_zone": "Australia/Sydney", "organization_instance": "GS0", "organization_type": "Production", "user_id_token": "005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=", "user_type": "Standard", "url": "/apex/Acme__Agent_List", "package_id": "033xx0000004FqD", "package_version_id": "04txx0000004Idi", "managed_package_namespace": "Acme", "custom_entity": "/apex/Acme__Agent_List", "custom_entity_type": "VisualforcePage", "request_status": "S", "session_key": "2l4YtFB/RmsRKVsS", "login_key": "fGV6RgVOH3ZCgl2v", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/IP_ADDRESS_REMOVED Safari/537.36", "user_country_code": "US", "user_time_zone": "America/Los_Angeles", "request_size": "826", "response_size": "1830" } ``` The Acme_Agent_List packaged component of type VisualforcePage was interacted with as a result of a user action from subscriber org MyCustomer Inc on 2022-11-22 at 6:23 am. The key data in this analysis are: | Question | Field | Value | | -------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | What |
  • `custom_entity`
  • `custom_entity_type`
  • `package_version_id`
  • `managed_package_namespace`
|
  • `Acme__Agent_List`
  • `VisualforcePage`
  • `04txx0000004Idi`
  • `Acme`
| | Who |
  • `organization_id`
  • `user_id_token`
|
  • `00Dxx0000006H2l`
  • `005-9BwnBWYO5FMn4cZ1sLw7F3LmTpoe8M77GrZOZHL6xQk=`
| | How | `log_record_type` | `VisualforceRequest` | | When | `timestamp_derived` | `2022-11-22T06:23:23.836Z` | **See Also** - [Package Usage Logs Schema](https://developer.salesforce.com/docs/platform/pkg2-dev/app-analytics-custom-object-logs.md) - [Visualforce Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_intro.htm) # What Are Beta Versions of Managed Packages? A beta package is an early version of a managed package. The purpose of a beta package is to allow the developer to test their application in different Salesforce orgs and to share the app with a pilot set of users for evaluation and feedback. Before installing a beta version of a managed package, review the following notes: - Beta packages can be installed in scratch, sandbox, or Developer Edition orgs, or test orgs furnished through the Environment Hub only. - The components of a beta package are editable in the packaging org until a Managed - Released package is uploaded. - Beta versions aren't considered major releases, so the package version number doesn't change. - Beta packages aren’t upgradeable. Because developers can still edit the components of a beta package, the Managed - Released version might not be compatible with the beta package installed. To install a new beta package or released version, first, uninstall the beta package. For more information, see [Uninstall a Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-uninstall.md) and [Install a Managed Package](https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-install.md). # What Are Recipes? The AgentExchange App Analytics Developer Cookbook uses two distinct types of recipes: CRM Analytics recipes and App Analytics recipes. The CRM Analytics recipes are foundational work that you must complete before creating App Analytics recipes. App Analytics recipes build on your CRM Analytics recipe analytics environment and result in key performance indicators (KPIs). | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | You can use any reporting tool to create KPIs, but we recommend our analytics powerhouse, CRM Analytics. With CRM Analytics, you can easily integrate your License Management App (LMA) data with your App Analytics data using datasets and CRM Analytics recipes. ## CRM Analytics Recipes If you’re familiar with CRM Analytics, you’re familiar with dataflows and CRM Analytics recipes. Dataflows are great for combining data from multiple sources, while CRM Analytics recipes are great for performing transformations on a single dataset. To set up your App Analytics recipe environment, create CRM Analytics recipes that combine a country code dataset, your LMA data, and your App Analytics data. These CRM Analytics recipes are required to create App Analytics recipes. ## App Analytics Recipes App Analytics recipes are CRM Analytics lens formulas with SAQL code provided. Each App Analytics recipe results in a KPI that you can use to visualize your data on a dashboard. Some examples include Daily and Monthly Active Users, and Custom Object Reads Per Day. Complete your CRM Analytics recipes before starting with App Analytics recipes. # What Is AgentExchange? AgentExchange is a unified marketplace offering solutions, such as apps, agents, components, and consulting services. To make your own solution publicly available to potential customers, you must be a Salesforce partner. **note:** Introducing the new AgentExchange. We’ve unified AppExchange, AgentExchange, and Slack Marketplace into a single destination. Now, you can easily find, try, buy, and deploy the agents, apps, integrations, and certified experts you need to optimize your business. ## How Does AgentExchange Work? The creative power behind each AgentExchange solution is a Salesforce partner. AgentExchange gives partners a place to create and publish extensions to Salesforce and Slack. AgentExchange is also the place for Salesforce and Slack admins to find and install solutions that fit their business needs. Here’s how AgentExchange works. - Create - : A Salesforce partner initiates the process by creating an innovation that can improve a business process, such as a custom object, custom tab, or component. Partners share their customizations with other Salesforce users as a packaged AgentExchange solution. Solutions can come in many forms, including apps, AI agents, Bolt solutions, Flow solutions, Lightning data, components, and more. - Publish - : The Salesforce partner registers, packages, and publishes their solution on AgentExchange. They can also create a demo of the functionality included in their solution for others to view before installing and include a trial version. - Install - : Salesforce customers browse solutions published on AgentExchange and choose which solutions to install in their orgs. Installing a published AgentExchange solution is safe and simple. Customers can: - **Browse**—View the descriptions, reviews, and demos of solutions on AgentExchange. They select the solution that fits their needs. - **Test drive**—Review a fully functional demo of the solution as a read-only user, and plan their implementation with their admins. - **Install**—Add the solution and all its components to their Salesforce environment or Slack workspace. - **Deploy**—Immediately give their users access to the solution or customize it for a select group of users. ## Who Can Use AgentExchange? Anyone can browse and test drive AgentExchange listings. Salesforce admins, Slack admins, and users with the Download AgentExchange Packages permission can install AgentExchange apps. To publish a listing on AgentExchange, a user needs both Create AgentExchange Packages and Upload AgentExchange Packages permissions. # What kinds of orgs can I create in the Environment Hub? You can create orgs for development, testing, and trials. ISV partners can also create partner edition orgs with increased limits, more storage, and other customizations to support app development. If you’re a partner but don’t see partner edition orgs in the Environment Hub, log a support case in the Salesforce Partner Community. |Org Type|Best Used For|Expires After| |--------|-------------|-------------| |Group Edition|Testing|30 days| |Enterprise Edition|Testing|30 days| |Professional Edition|Testing|30 days| |Partner Developer Edition|Developing apps and Lightning components|Never| |Partner Group Edition|Robust testing and customer demos|1 year, unless you request an extension| |Partner Enterprise Edition|Robust testing and customer demos|1 year, unless you request an extension| |Partner Professional Edition|Robust testing and customer demos|1 year, unless you request an extension| |Trialforce Source Org|Creating Trialforce templates|1 year, unless you request an extension| |Consulting Partner Edition|Customer demos|1 year, unless you request an extension| For information on the differences across Salesforce org editions, see Salesforce Help: [Salesforce Features and Edition Allocations](https://help.salesforce.com/s/articleView?id=xcloud.overview_limits_general.htm&type=5). For information on partner editions orgs, search for Knowledge Article: Benefits of Using a Partner Development Org and Demo Environment. # What to Consider Before Removing Metadata Components In most cases, removing metadata components from a second-generation managed package marks the component as deprecated and doesn’t hard delete the component from the subscriber org. This approach to component removal ensures that package upgrades don’t disrupt a subscriber’s org. But there’s a scenario where a deprecated component can lead to a package upgrade issue. This issue only pertains to deprecated components, and no action is needed for hard deleted components. To see which components are deprecated and which are deleted, see [Remove Metadata Components from Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_remove_md_components.htm). Here’s an example scenario of how a deprecated component leads to a package upgrade issue. 1. Subscriber A installs version 1.0 of a managed package. 2. A package developer removes project\_\_c custom object, and creates package version 2.0. 3. Subscriber A upgrades from version 1.0 to version 2.0, and project**c is now marked as deprecated in their org. Any integration with project**c that the subscriber created continues to work. 4. The package developer continues to refine their app, and then releases several new versions. 5. During development of version 5.0, the package developer adds a component named project\_\_c to the package. 6. A new subscriber, Subscriber B, successfully installs version 5.0. 7. Subscriber A tries to upgrade to version 5.0, but the installation fails because the admin at Subscriber A never deleted project\_\_c from their org. 8. The package developer has two paths to unblock Subscriber A. 1. Ask Subscriber A to remove all references to project\_\_c, and then delete the component from their org. 2. Remove project\_\_c from the package and release a new package version. To prevent this kind of API name collisions in your packages, here are some best practices. ## Communicate within Your Team and Company Before you remove any metadata, assess the impact to the package and to any packages that depend on that package. If you remove metadata in one package, that action has the potential to break the functionality of a package that depends on the removed metadata. Communicate within your team and company so that other developers are aware of this change. ## Document Package Changes for Future Developers If you internally document the major changes that your package undergoes, including the name of metadata components that were removed, you can help alert future package developers about previously used API names. ## Communicate Changes with Your Subscribers Educate your customers about the potential impact from any components you remove. In the Release Notes for your upgraded package, list all components you’ve removed and notify customers of any necessary actions. # What’s a Second-Generation Managed Package? If your goal is to build an app and distribute it on AgentExchange, you’ll use managed packages to do both. Packaging is the container that you fill with metadata, and it holds the set of related features, customizations, and schema that make up your app. A package can include many different metadata components, and you can package a single component, an app, or library. Each second-generation managed package follows a distinct lifecycle. As you develop your app, you add metadata to a package, and create a new package version. While the package is continually evolving, each package version is an immutable artifact. A package version contains the set of metadata and features associated with the package version at the moment it was created. As you iterate on your package, and add, remove, or change the packaged metadata, you're likely to create many package versions along the way. You can install a package version in a scratch, sandbox, trial, developer edition, or production org. Your customers can install the package into their org and when you release a new package version, your customers can upgrade to the latest version. You can repeat the package development cycle any number of times. You can change metadata, create a package version, test the package version, and distribute it to your customers via AgentExchange. - **[Why Switch to Second-Generation Managed Packaging?](https://developer.salesforce.com/docs/platform/pkg2-dev/first-generation/pd-why-switch-2gp.md)** You’ve been using first-generation managed packages to develop your apps, so you’re probably pretty familiar with what works well, and what’s a bit more painful than you’d like. And no doubt, you’re aware that second-generation managed packages is our newer technology, but maybe you aren’t so sure why switching to second-generation managed packaging (managed 2GP) will improve your package development experience. So let’s talk about that. - **[Comparison of First- and Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-comparison.md)** If you’re familiar with first-generation managed packages (managed 1GP) and wonder how it’s different from second-generation managed packages (managed 2GP), here are some key distinctions. # When to Use Scratch Org Snapshots in Package Development If the managed 2GP or unlocked package that you’re building depends on one or more large packages, it can take a long time for the package version creation CLI command to complete. Let’s talk about why that occurs, and how scratch org snapshots can dramatically reduce how long it takes to create a new package version. When you run the `package version create` CLI command, we create a scratch org behind the scenes. That scratch org serves as a build org where we build your package. In the build org we install the dependent packages you specified, and deploy the package metadata for the package version you're creating. If your dependent packages are large, the package install time for those dependent packages extends the overall package creation time. If the dependent packages that your base package requires are stable, you can reduce the end-to-end package version creation time by creating a scratch org snapshot, and using that scratch org snapshot during package version creation. A [scratch org snapshot](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_snapshots_intro.htm) captures the state of a scratch org’s configuration so that you can use the snapshot to create scratch org replicas. A snapshot is a point-in-time copy of a scratch org that includes installed packages, features, limits, licenses, metadata, and data. If you install your dependent packages in the scratch org before you create the snapshot, and you specify the snapshot when you create a new package version, the package build process bypasses these steps. Meaning, we don't install the dependent packages into the build org, we use the snapshot instead. By not installing the dependent packages during package version creation, your package version builds in a fraction of the time. Keep in mind, the intention of scratch org snapshots in the package development cycle is to shorten the package creation time during development. When you are ready to promote and release a package, you must create a new package version that doesn’t rely on a scratch org snapshot. Package versions created using scratch org snapshots can’t be promoted to the released state. **note:** You can promote an [unlocked package](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) based on a snapshot. Only managed packages based on snapshots can’t be promoted to the released state. **See Also** - [Create a Package Version Based on a Scratch Org Snapshot](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/dev2gp-so-pkg-snapshot.md) - [_Salesforce DX Developer Guide_: Scratch Org Snapshots](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_snapshots_intro.htm) # Where Do I Go for More Information About AgentExchange App Analytics Queries? Questions are natural when you start automating your queries and planning your query strategy. To find a good solution when you have questions, review your code base and the size and skill of your development team. | Required Editions | | ---------------------------------------------------------------------------------------- | | Available in: both Salesforce Classic and Lightning Experience | | Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions | If you still need help, try these resources: - If you have an assigned ISV Partner Account Manager (PAM) or AgentExchange Technical Evangelist (TE), reach out to them. - Otherwise, go to the Partner Community and post a question to the [ISV TE Experts - Partner Intelligence](https://partners.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000HWsf) Chatter group. # Where do I install the Environment Hub? If you’re an ISV partner, the Environment Hub is already installed in your Partner Business Org. Otherwise, install the Environment Hub in an org that all your users can access, such as your CRM org. Do not install the Environment Hub in a Developer Edition org that contains your managed package. Doing so can cause problems when you upload a new package version or push an upgrade to customers. # Which Package Types Can Your Package Depend On? Both second-generation managed packaging (managed 2GP) and unlocked packaging let you easily develop small interdependent packages and share logic between them. If you design your app to rely on small modular packages, both package creation and package installation are faster, and you’re less likely to hit limits. To develop small, modular packages, you create dependencies between your packages. A package dependency is when metadata contained in one package depends on metadata contained in another package. These dependencies allow you to extend the functionality of the base package with components and metadata in a separate extension package. When working with packaging, only certain combinations of packages are supported. | | Can a Managed 1GP Depend on a ... | Can a Managed 2GP Depend on a ... | Can an Unlocked Package Depend on a ... | Can an Unmanaged Package Depend on a ... | | ----------------- | --------------------------------- | --------------------------------- | --------------------------------------- | ---------------------------------------- | | Managed 1GP | Yes | Yes | Yes | No | | Managed 2GP | No:sup[1] | Yes | Yes | No | | Unlocked package | Not recommended | Not recommended | Yes | No | | Unmanaged package | Not recommended | Not recommended | Not recommended | No | :sup[1]This dependency isn’t supported, and we block the installation of managed 2GP packages in managed 1GP packaging orgs. We can override this behavior on an individual basis. To share your scenario and request an override, log a case with [Salesforce Partner Support](https://partners.salesforce.com). We’re investigating how to support this dependency scenario more broadly. **See Also** - [Create Dependencies Between Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_dependencies.htm) - [Considerations for Promoting Packages with Dependencies](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_considerations_pkg_dependency.htm) # Which Trial Method Is Right for My AgentExchange Solution? The first step to offering trials of your AgentExchange solution is to pick a delivery method. You can provide trials on your AgentExchange listing using test drives or Trialforce orgs, or you can provide trials on your website using SignupRequest API. Learn about the differences between trial methods, and decide which options work best for your business. **tip:** Choose one trial method or several—it’s up to you! In general, the greater the variety of options, the more likely that prospects are to convert. | Trial Method | Where Are Trials Delivered? | How Does It Work? | Advantages | | ----------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Trialforce | Your AgentExchange listing | Using a Trialforce Management Org or Environment Hub, you create a Trialforce Source Org (TSO), install your solution, and add sample data. Using your TSO, you create a Trialforce template.

On AgentExchange, your prospect requests a trial. They receive login credentials for a unique trial org based on your Trialforce template. |
  • Offer flexible trial experiences using environments that prospects can keep and customize.
  • Add optional branding to your trial experiences.
| | Test Drive | Your AgentExchange listing | Using a preconfigured Trialforce template, you create a test drive org, install your solution, and add sample data.

On AgentExchange, your prospect requests a test drive. They’re directed to a read-only org that doesn’t require login credentials. |
  • Offer curated trial experiences using environments that don’t require setup or customization.
  • Give the widest range of prospects the opportunity to explore your solution, including prospects with little Salesforce experience.
  • Provide your prospects instant access to a test org
| | SignupRequest API | Your website using an HTML sign-up form | Using a Trialforce Management Org or Environment Hub, you create a Trialforce Source Org (TSO), install your solution, and add sample data. Using your TSO, you create a Trialforce template.

On your website, your prospect requests a trial. They receive login credentials for a unique trial org based on your Trialforce template. |
  • Give prospects who visit your website the ability to try your solution.
  • Offer flexible trial experiences using environments that prospects can keep and customize.
  • Add optional branding to your trial experiences.
| # Why Switch to Second-Generation Managed Packaging? You’ve been using first-generation managed packages to develop your apps, so you’re probably pretty familiar with what works well, and what’s a bit more painful than you’d like. And no doubt, you’re aware that second-generation managed packages is our newer technology, but maybe you aren’t so sure why switching to second-generation managed packaging (managed 2GP) will improve your package development experience. So let’s talk about that. ## Source-Driven Development The source-driven development model used in managed 2GP is a big shift from the org-based development used in managed 1GP. Say goodbye to packaging orgs as your source of truth. Instead, your source of truth with managed 2GP is the package metadata in your version control system. And as you develop your managed 2GP package, you create and update your package metadata in a version control system, not in an org. ## Minimal Interaction with Salesforce Orgs As you probably know well, with managed 1GP development, every package and patch version requires a unique Salesforce org, so it’s not uncommon for you to own 100s of Salesforce orgs in which your package metadata is deployed. Managing these orgs and their credentials can become a nightmare. Managed 2GP takes away the hassle of managing orgs, and instead you use a single org, the Dev Hub org, to manage all your packages. And even when you do need to connect to your Dev Hub org you’ll use Salesforce CLI (Command Line Interface) or a script to log in. By eliminating the need to manually log in and keep track of hundreds of packaging and patch orgs (and their login credentials), managed 2GP simplifies package development and promotes modern, programmatic Application Lifecycle Management (ALM). ## API- and CLI-first Model Unlike managed 1GP, which has only partial API coverage, you can perform every managed 2GP packaging operation using an API or CLI command. You can completely automate packaging operations and be more productive. Repeatable, scriptable, and track-able ALM is truly possible with managed 2GP. ## Flexible Versioning Managed 1GP packaging follows a linear versioning model that requires you to build upon the previous package version. This approach is very restrictive, and for metadata that can’t be removed from a package, you’re stuck with that metadata in your managed 1GP. Enter managed 2GP and flexible versioning. If you create a managed-released package version that you haven’t yet distributed to a customer, you can abandon that package version and select a previous package version as the ancestor you want to build upon. Flexible versioning also allows you to use branches and do parallel package development. You can iterate fast, learn from, and move on from any mistakes. ## One Namespace Shared Across Multiple Packages Managed 1GP packages require each package to have a unique namespace. This restriction can lead to a proliferation of global Apex because sharing code among packages is only possible by declaring Apex classes and methods as global. Managed 2GP changes the game by allowing multiple packages to share the same namespace. The `@namespaceAccessible` annotation then lets you share public Apex classes and methods across all packages in the same namespace. By using public Apex, you don’t increase your global Apex footprint by exposing a global API. ## Declarative Dependencies In managed 2GP packaging, you specify dependencies among packages declaratively in a `.json` file. Which as you know, is a more developer-friendly approach than how managed 1GP dependencies are declared. ## Simplified Patch Versioning Creating a patch version of a managed 2GP is as easy as creating a new major or minor package version. You use a Salesforce CLI command and specify a non-zero number for the patch version number. And that’s it! Because your version control system is the source of truth for managed 2GP, creating patch versions is straightforward. We promise you won’t miss the laborious and error-prone patch org process of managed 1GP. ## Avoid Having to Migrate Customers in the Future As you may be aware, we’re developing capabilities to migrate your managed 1GP packages to managed 2GP. However, when we launch that capability, there’s work that you have to do to migrate your managed 1GP packages and customers from 1GP to 2GP. By adopting managed 2GP today for your new packages, you avoid the hassle of migration in the future. # Why Switch to Second-Generation Managed Packaging? You’ve been using first-generation managed packages to develop your apps, so you’re probably pretty familiar with what works well, and what’s a bit more painful than you’d like. And no doubt, you’re aware that second-generation managed packages is our newer technology, but maybe you aren’t so sure why switching to second-generation managed packaging (managed 2GP) will improve your package development experience. So let’s talk about that. ## Source-Driven Development The source-driven development model used in managed 2GP is a big shift from the org-based development used in managed 1GP. Say goodbye to packaging orgs as your source of truth. Instead, your source of truth with managed 2GP is the package metadata in your version control system. And as you develop your managed 2GP package, you create and update your package metadata in a version control system, not in an org. ## Minimal Interaction with Salesforce Orgs As you probably know well, with managed 1GP development, every package and patch version requires a unique Salesforce org, so it’s not uncommon for you to own 100s of Salesforce orgs in which your package metadata is deployed. Managing these orgs and their credentials can become a nightmare. Managed 2GP takes away the hassle of managing orgs, and instead you use a single org, the Dev Hub org, to manage all your packages. And even when you do need to connect to your Dev Hub org you’ll use Salesforce CLI (Command Line Interface) or a script to log in. By eliminating the need to manually log in and keep track of hundreds of packaging and patch orgs (and their login credentials), managed 2GP simplifies package development and promotes modern, programmatic Application Lifecycle Management (ALM). ## API- and CLI-first Model Unlike managed 1GP, which has only partial API coverage, you can perform every managed 2GP packaging operation using an API or CLI command. You can completely automate packaging operations and be more productive. Repeatable, scriptable, and track-able ALM is truly possible with managed 2GP. ## Flexible Versioning Managed 1GP packaging follows a linear versioning model that requires you to build upon the previous package version. This approach is very restrictive, and for metadata that can’t be removed from a package, you’re stuck with that metadata in your managed 1GP. Enter managed 2GP and flexible versioning. If you create a managed-released package version that you haven’t yet distributed to a customer, you can abandon that package version and select a previous package version as the ancestor you want to build upon. Flexible versioning also allows you to use branches and do parallel package development. You can iterate fast, learn from, and move on from any mistakes. ## One Namespace Shared Across Multiple Packages Managed 1GP packages require each package to have a unique namespace. This restriction can lead to a proliferation of global Apex because sharing code among packages is only possible by declaring Apex classes and methods as global. Managed 2GP changes the game by allowing multiple packages to share the same namespace. The `@namespaceAccessible` annotation then lets you share public Apex classes and methods across all packages in the same namespace. By using public Apex, you don’t increase your global Apex footprint by exposing a global API. ## Declarative Dependencies In managed 2GP packaging, you specify dependencies among packages declaratively in a `.json` file. Which as you know, is a more developer-friendly approach than how managed 1GP dependencies are declared. ## Simplified Patch Versioning Creating a patch version of a managed 2GP is as easy as creating a new major or minor package version. You use a Salesforce CLI command and specify a non-zero number for the patch version number. And that’s it! Because your version control system is the source of truth for managed 2GP, creating patch versions is straightforward. We promise you won’t miss the laborious and error-prone patch org process of managed 1GP. ## Avoid Having to Migrate Customers in the Future As you may be aware, we’re developing capabilities to migrate your managed 1GP packages to managed 2GP. However, when we launch that capability, there’s work that you have to do to migrate your managed 1GP packages and customers from 1GP to 2GP. By adopting managed 2GP today for your new packages, you avoid the hassle of migration in the future. **See Also** - [Second-Generation Managed Packaging Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp.htm) # Work with Patch Versions A patch version enables a developer to change the functionality of existing components in a managed package. Subscribers experience no visible changes to the package. Patches are minor upgrades to a Managed - Released package and only used for fixing bugs or other errors. **note:** To enable patch versioning, contact [Salesforce Partner Support](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/pkg2_feature_enablement.htm) and request patch versioning be enabled in the org where you created the namespace for the package. Patch versioning is available only to packages that have passed AgentExchange security review. Subscribers can install patch upgrades just like they would any other package version. However, you can also distribute a patch by using [push upgrades](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_push_about.htm). When you create a patch, the _patchNumber_ on a package's Version Number increments by one. For example, suppose that you release a package with the version number 2.0. When you release a patch, the number changes to 2.0.1. This value can't be changed manually. ## Patch Development Organizations Every patch is developed in a patch development org, which is the org where patch versions are developed, maintained, and uploaded. To start developing a patch, create a package version. See [Create and Upload Patches in First-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/patches_creating.htm#patches_creating). Patch development orgs are necessary to permit developers to change existing components without causing incompatibilities between existing subscriber installations. A package development org can upload an unlimited number of patches. Only one patch development org can exist per major.minor release of your package. A patch development org for a package with a version number of 4.2 can only work on patches such as 4.2.1, 4.2.2, 4.2.3, and so on. It doesn’t work on version 4.1 or 4.3. ## Integrating Patch Development The following diagram illustrates the workflow of creating a patch and integrating any work into future versions:After version 2.0 is released, the developer creates a patch. The package version number in the patch development org starts at 2.0.1. As the main development org moves towards a released version of 3.0, a second patch is created for 2.0.2. Finally, the developer merges the changes between the main development org, and the patch development org, and releases the package as version 3.0. ![Flow diagram of patch uploads](https://developer.salesforce.com/media/pkg1_dev/patches_flow.png "Patch Development Workflow") Git source control is the best way to monitor your package versions. To learn about Git, complete the [Git and GitHub Basics](https://trailhead.salesforce.com/en/content/learn/modules/git-and-git-hub-basics) Trailhead module. Version control is integrated into Visual Studio Code. See [Salesforce Extensions for Visual Studio Code](https://developer.salesforce.com/tools/vscode) and [Version Control in Visual Studio Code](https://code.visualstudio.com/docs/editor/versioncontrol) for details. # Work with Services Outside of Salesforce You might want to update your Salesforce data when changes occur in another service. Likewise, you might also want to update the data in a service outside of Salesforce based on changes to your Salesforce data. For example, you might want to send a mass email to more contacts and leads than Salesforce allows. You can use an external mail service that allows users to build a recipient list of names and email addresses using the contact and lead information in your Salesforce organization. An app built on the Salesforce Platform can connect with a service outside of Salesforce in many ways. For example, you can: - create a custom link or custom formula field that passes information to an external service. - use the Platform APIs to transfer data in and out of Salesforce. - use an Apex class that contains a Web service method. **note:** Don’t store usernames and passwords within any external service. ## Provisioning a Service External to Salesforce If your app links to an external service, users who install the app must be signed up to use the service. Provide access in one of two ways: - Access by all active users in an organization with no real need to identify an individual - Access on a per user basis where identification of the individual is important The Salesforce service provides two globally unique IDs to support these options. The user ID identifies an individual and is unique across all organizations. User IDs are never reused. Likewise, the organization ID uniquely identifies the organization. Avoid using email addresses, company names, and Salesforce usernames when providing access to an external service. Usernames can change over time and email addresses and company names can be duplicated. If you’re providing access to an external service, we recommend the following: - Use Single Sign-On (SSO) techniques to identify new users when they use your service. - For each point of entry to your app, such as a custom link or web tab, include the user ID in the parameter string. Have your service examine the user ID to verify that the user ID belongs to a known user. Include a session ID in the parameter string so that your service can read back through the Lightning Platform API and validate that this user has an active session and is authenticated. - Offer the external service for any known users. For new users, display an alternative page to collect the required information. - Don’t store passwords for individual users. Besides the obvious security risks, many organizations reset passwords on a regular basis, which requires the user to update the password on your system as well. We recommend designing your external service to use the user ID and session ID to authenticate and identify users. - If your application requires asynchronous updates after a user session has expired, dedicate a distinct administrator user license for this. # Workflow for Second-Generation Managed Packages You can create and install a second-generation managed package (managed 2GP) directly from the command line. Review and complete the steps in [Before You Create Second-Generation Managed Packages](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-before.md) before starting this workflow. The basic managed 2GP workflow includes these steps. See specific topics for details about each step. 1. Create a DX project. ```nolang sf project generate --output-dir expense-manager-workspace --name expenser-app ``` 2. Authorize the Dev Hub org. ```nolang sf org login web --set-default-dev-hub ``` When you perform this step, include the `---set-default-dev-hub` option. You can then omit the Dev Hub username when running subsequent Salesforce CLI commands. **tip:** If you define an alias for each org you work with, it’s easy to switch between different orgs from the command line. You can authorize different orgs as you iterate through the package development cycle. 3. Create a scratch org and develop the app you want to package. You can use VS Code and the Setup UI in the scratch org to build and retrieve the pieces you want to include in your package. Navigate to the expenser-app directory, and then run this command. ```nolang sf org create scratch --definition-file config/project-scratch-def.json ``` 4. Verify that all package components are in the project directory where you want to create a package. If you’re trying out the exact steps and commands in this workflow, you must add at least one piece of metadata before you continue to the next step. 5. In the `sfdx-project.json` file, specify a namespace using the namespace attribute. For example: “namespace”: “exp-mgr” If you specified a namespace when you created a Salesforce DX project in step one, you can skip this step. Before adding a namespace, make sure that you’ve linked the [namespace](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-namespace.md) to your Dev Hub org. 6. From the Salesforce DX project directory, create the package. ```nolang sf package create --name "Expense Manager" --path force-app --package-type Managed ``` Your new managed 2GP package has the namespace you specified in the `sfdx-project.json` file. **important:** After you create a package, you can’t change or add a namespace, or change the Dev Hub the package is associated with. 7. Review your `sfdx-project.json` file. The CLI automatically updates the project file to include the package directory and creates an alias based on the package name. ```nolang { "packageDirectories": [ { "path": "force-app", "default": true, "package": "Expense Manager", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT" } ], "namespace": "exp-mgr", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "51.0", "packageAliases": { "Expense Manager": "0Hoxxx" } } ``` Notice the placeholder values for `versionName` and `versionNumber`. You can update these values, or indicate base packages that this package depends on. Your project file displays the `namespace` you created. Specify the features and org settings required for the metadata in your package using an external `.json` file, such as the scratch org definition file. You can specify using the `--definition-file` flag with the `sf package version create` command, or list the definition file in your `sfdx-project.json` file. See: [Project Configuration File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev2gp-config-file.md) 8. Create a package version. This example assumes the package metadata is in the `force-app` directory. ```nolang sf package version create --package "Expense Manager" --code-coverage --installation-key test1234 --wait 10 ``` 9. Install and test the package version in a scratch org. Use a different scratch org from the one you used in step three. ```nolang sf package install --package "Expense Manager@0.1.0-1" --target-org MyTestOrg1 --installation-key test1234 --wait 10 --publish-wait 10 ``` 10. After the package is installed, open the scratch org to view the package. ```nolang sf org open --target-org MyTestOrg1 ``` Package versions are beta until you promote them to a managed-released state. See: [Release a Second-Generation Managed Package](https://developer.salesforce.com/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-create-pkg-ver-promote.md). **See Also** - [Before You Create Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_before.htm) - [Create and Register Your Namespace for Second-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_namespace.htm) - [Project Configuration File for a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm) - [Release a Second-Generation Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev_dev2gp_create_pkg_ver_promote.htm) # Your Customers and the Go-To-Market App The Go-To-Market (GTM) app is designed for partners, but your customers interact with it in order to respond to private offers. After you set up the GTM app and turn on Private Offers, your customers can request offers directly from your AgentExchange listings. ## Before You Begin For customers to view and accept private offers, they must opt-in to receive and manage offers from the Your Account page. For more information, see [Receive Private Offers from AgentExchange Partners](https://developer.salesforce.com/docs/atlas.en-us.appExchangeInstallGuide.meta/appExchangeInstallGuide/appexchange_install_private_offers.htm) To streamline private offers, you can allow customers to request them directly from your AgentExchange listings. To turn on the Request Private Offers button: ## Steps 1. Go to the Partner Console. 2. On the Listings tab, select a listing. 3. Go to the Lead-Generating Activities section and select Request a private offer. 4. The **Request Private Offer** button appears on your listing detail page. When a customer selects that option, a private offer lead appears in your PBO.