Why use Feature Parameters
Managed packages installed in orgs contain a lot of metadata that configure the applications' work. If you need to set some settings that are not available to edit by any user after package installation, you can create a new Custom Setting on your packaging org with Protected visibility. This ensures that this custom setting will not be available for manual editing after installing the package on the Salesforce Organisation.
This implementation is effective, for example, for storing private data (username, password, etc.) about each user using the application from the installed package, and making them inaccessible to others. But all this data is stored only inside the package installed on this org, and it is impossible to access the data from an external org.
When you need to follow any setting values which are set on the installed packages, or you need to change them from an external org, you should use Feature Parameters. You can find this tab in the Package Manager, in your selected package.
There are 3 available types of parameters: Boolean, Integer and Date. And there are 2 data flow directions: Subscriber To LMO and LMO To Subscriber. We will look at them in more detail later.
Feature Management App installation
Feature Management App (FMA) is an extension of the License Management App (LMA). This application is not available for open download from AppExchange, here you need to make a support request. Detailed instructions for installing FMA are provided in the documentation at the link.
License Management Organization (LMO) is a Salesforce organization where you install LMA. You use it to track all Salesforce users who install your managed package.
Feature Management Org (FMO) is a Salesforce organization that allows you to set feature parameters values on different orgs where a package is installed. This is the same organization as the LMO, but it includes the FMA.
Create and configure Feature Parameters
After installing the app on your FMO, the Feature Parameters tab will be available on your packaging org. Now you can create any parameters that you need to manage installed packages from your FMO. You can choose between 'LMO To Subscriber' and 'Subscriber To LMO' directions. Let's look at examples of using each of them.
The 'LMO to Subscriber' direction should be used when you need to set any value for a selected package from LMO, and subscribers are not able to edit those values by themselves. For example, if your package app works differently for premium and non-premium access, you can create a Boolean parameter and then set it as true, if the customer bought the premium.
Firstly you create the parameter on the packaging org, then include it in the package.
When a subscriber installs the package, its data appears on the LMO org in the LMA app. You will see different tabs, including Packages and Licenses.
On the Licenses tab choose the parameter which needs to be edited.
Set Feature Parameter Value as true. After that, this value for the selected org will be seen as true, and the subscriber will have premium access.
'Subscriber to LMO' direction should be used if you want to collect some data from the subscriber’s orgs and check them on LMO. For example, you can create an Integer parameter to use as a counter of Processed records.
Use Feature Parameters from the Apex code
Data about the parameters' values on the current org can be received or configured using the System.FeatureManagement Apex class. To get param values, use these methods:
To set param values, use these methods:
- System.FeatureManagement.setPackageBooleanValue('YourBooleanFeatureParameter', booleanValue);
- System.FeatureManagement.setPackageDateValue('YourDateFeatureParameter', datetimeValue);
- System.FeatureManagement.setPackageIntegerValue('YourIntegerFeatureParameter', integerValue);
- Feature Parameters with 'LMO to Subscriber' direction are not editable from Apex. It's an important part of such functionality, you can edit them manually on LMO in the License Management App.
- Feature Parameters with 'Subscriber to LMO' direction are available for editing on LMO. But don’t change their values. They are used to collect data from subscriber’s org, and manual changing will break the sync.
- You can’t use methods to edit Feature Parameter values in the same transaction with the DML operation. In this case you get the MIXED_DML_OPERATION exception. To avoid this, use the @future methods for System.FeatureManagement class.
Best practices to use Feature Parameters
Now it is worth highlighting the general recommendations to use Feature Parameters.
- You should first set feature parameters in a test package and a test LMO before using it in a Prod. It’s important to get a full understanding of the issue and how to resolve it.
- Try to plan your implementation so as to use up to 25 Feature Parameters in one package. If you need more than 25 parameters, you will need to make a request in the Salesforce Partner Community
- Use “LMO to Subscriber” parameters if you need to enable features from your LMO for individual subscriber orgs. Don’t change their values from the code on the packaging orgs.
- Use “Subscriber to LMO” parameters to populate their values from code in packaging orgs and monitor them on LMO. Don’t change their values on LMO
Considerations for Feature Management
There are some important rules which must be used for correct development:
- Parameter names should be the same in packaging org and LMO. Therefore, if you have already released a package version, it’s better to edit only the value field located in LMO-to-subscriber junction objects.
- Don’t create or delete feature parameters from LMO. Use packaging org for this.
- When you update any 'LMO to Subscriber' parameter values, changes are updated in packages asynchronously for several minutes.
- The value changes of the 'Subscriber to LMO' parameters are also performed asynchronously. Changes are displayed on the LMO within 24 hours.
It is quite simple to implement the use of FMA in an organization's Salesforce. There is no need to buy an app in AppExchange, you just need to make a support request, after which an extension of the existing package management functionality will be received. Thus, the package administrator can use a single FMA application to manage all installed instances.