Second-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
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
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

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

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

Note

Lifecycle of a Feature Parameter

Set Up the Feature Parameter
Start by defining your feature parameter in an XML file. Create one XML file 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.