trailhead

Manage Your Features

Learning Objectives

After completing this unit, you’ll be able to:

  • Define feature parameters and describe their purpose.
  • Identify the tool you use to manage feature parameters.
  • Explain why feature parameter data types are limited.

Manage Features with Flexibility

As a Salesforce partner, you get to use the same platform as Salesforce, with all the fixin’s. This includes operating your own business orgs and selling your solutions on AppExchange—but it’s more than that. You can actually run your business like Salesforce does, using the same tools we do to deliver the goods to your customers.

You’ve probably noticed that Salesforce has a lot of control over the features we ship on our platform. For example, we can selectively enable elaborate features for power users without affecting anyone else. We can also do “dark launches” of features, implementing them for a future release and shipping them deactivated.

These tools grant us a lot of flexibility in how we deploy and manage features. Now, with feature parameters, you can get this same flexibility.

We offer feature parameters to AppExchange partners exclusively. Open a support case in the Salesforce Partner Community when you’re ready to try them out.

Back in the Day

It wasn’t always so. Before feature parameters, many partners cooked up their own schemes for selectively enabling features within a managed package. More often than not, they used Protected Custom Settings to enable and disable features.

It worked like this: You log in to individual customer orgs using the LMA Login Access feature (which we describe in the next unit) and update the Protected Custom Setting to enable a specific feature. This system was complicated and fragile. And our AppExchange partners dreamed of a day when they could manage individual features as easily as managing licenses with the License Management App (LMA).

That day has come. Feature parameters now allow you to manage your app’s features from the same org where your LMA is installed. For an individual subscriber, you make your selections about which features are visible, and it communicates your selections to your customers’ subscriber orgs immediately.

And because you’ve waited so patiently for feature parameters, we’ve thrown in a little something extra. In addition to individual features, feature parameters can also manage custom objects. Based on the Feature Parameters you define, you can hide or expose custom objects.

Pass the Data, Please

Feature parameters for each customer are managed via the Feature Management App (FMA). The FMA extends the LMA, letting you manage your feature settings just like the LMA lets you manage licenses.

Your License Management Org (LMO) and your customer subscriber orgs communicate with each other using feature parameters. Each Feature Parameter’s value gets transferred in one of two directions:

  • From your LMO to a subscriber’s org
  • From a subscriber’s org to your LMO

Your FMA passes the feature parameters values from one org to the other. You can use the FMA to view and modify the feature parameters associated with each individual customer.

What does a feature parameter look like? It’s really simple, actually. A feature parameter consists of a name identifying the parameter, a value, and a data flow direction. The value can be any one of these types:

  • Boolean
  • Integer
  • Date

The data flow direction is LMO-to-subscriber or subscriber-to-LMO. In other words, every feature parameter knows where it’s going and where it’s been. The data in a feature parameter gets written in the org where it originates—the org receiving it can only read its value. This guarantees that the information for a feature parameter flows in one direction only.

By themselves, feature parameters are pretty limited—no string values allowed—and that’s intentional. Since these parameters get passed between customer orgs, we don’t want them to contain any personally identifiable information.

Another benefit of the simplicity of feature parameters is that they can store other kinds of data, like usage or activation metrics. Of course, you must write a little code to collect the metrics, but after that, the rest is easy. The FMA collects the metrics automatically from your subscriber orgs. There’s one more thing you don’t have to worry about.

Manage Features with Flexibility

Here’s a look at the orgs involved and the data they exchange.

A diagram showing how feature parameters are passed between the LMO, subscriber orgs, and your packaging org using the FMA

  • You define feature parameters in your packaging org.
  • Customers install your package from AppExchange.
  • During package installation in a subscriber org, a record appears in the LMO for each feature parameter you've defined (unless such a record already exists) and is managed by the FMA.
  • A junction object record also appears in the LMO. This junction object associates a feature parameter with the license for the subscriber org. What’s a junction object? Basically, it’s a custom object with two master-detail relationships: one for the feature parameter and one for the license. The junction object stores the value for the feature parameter as it exists in the subscriber org. When the junction object is created, its feature parameter adopts a default value specified by the packaging org.
  • Changes to data flow from the LMO to the subscriber orgs. Meanwhile, the LMO collects metrics from the subscriber orgs.

For a more detailed explanation of how feature parameters work, check the ISVforce Guide.

Define a Feature Parameter

  1. Navigate to your package and select the Feature Parameters tab.
  2. Choose the type of parameter you’d like to add. The Feature Parameters tab of the Package Manager, where you define a feature parameter
  3. Enter the information for the new feature parameter: its name, a label that identifies it, and its flow direction (LMO To Subscriber or Subscriber To LMO). The Feature Parameters tab of the Package Manager, where you define a feature parameter
  4. Add the parameter to your package, just like any other custom metadata you define for your app.

Move Data from Your LMO to a Subscriber

Feature parameters that move from LMO to subscriber get created or modified only in the LMO—in a subscriber org they are read only. You can use LMO-to-subscriber feature parameters, for example, to:

  • Hide or unveil new features
  • Control the resources your subscriber can use
  • Make features available for a limited trial period

The sky’s the limit.

To assign values to a LMO-to-subscriber feature parameter:

  1. In your LMO, open the License Management App (LMA).
  2. Select the license for the customer whose feature parameter you want to view or modify. A license record window, where you view and modify feature parameters
  3. Click the down arrow next to the parameter that you want to change to edit or delete it.

Collect Metrics from Subscribers

Use subscriber-to-LMO feature parameters to track activity in your subscriber’s org. Values for these feature parameters originate on the subscriber’s end and travel to your LMO. To collect these values:

  1. In your LMO, open the LMA.
  2. Select the license for the feature parameter whose value you want to inspect. A license record window, where you can view feature parameter values
  3. You can find the value in the Feature Parameter Value field for any subscriber-to-LMO feature parameter.

With feature parameters, you can shape your customers’ experiences in more ways than before, and you can manage the release of new features more carefully. But the LMA doesn’t stop there. Read on to explore how you can use the support console to keep your customers happy.

Resources

retargeting