Second-Generation Managed Packaging Developer Guide

Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Set Up Your Development Environment
Before You Create Second-Generation Managed Packages
Scratch Orgs and Package Development
Workflow for Second-Generation Managed Packages
Components Available in Second-Generation Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Advanced Features for Second-Generation Managed Packages
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Feature Parameter Metadata Types and Custom Objects
Set Up Feature Parameters
Install and Set Up the Feature Management App in Your License Management Org
Create Feature Parameters for Your Second-Generation Managed Package
Use LMO-to-Subscriber Feature Parameters to Enable and Disable Features
Track Preferences and Activation Metrics with Subscriber-to-LMO Feature Parameters
Hide Custom Objects and Custom Permissions in Your Subscribers’ Orgs
Best Practices for Feature Management
Considerations for Feature Management
Get Started with AppExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Newer Version Available

This content describes an older version of this product. View Latest

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.

Feature parameters for managed 1GP packages are created in the packaging org’s UI, see Create Feature Parameters in Your Packaging Org in the First-Generation Managed Packaging Developer Guide for details.

Note

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.

It’s not possible to create feature parameters using a scratch org’s user interface.

Note

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)
  • 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.

After a feature parameter is included and released in the package version, the data flow direction can’t be changed.

Note

Examples of Feature Parameter file

AdvancedPricingEnabled.featureParameterBoolean-meta.xml

NumberofLedgers.featureParameterInteger-meta.xml

ProjectActivationDate.featureParameterDate-meta.xml