3

Salesforce.com own apps are licenced using a fine-grained hierarchy of user licenses and add-on licences where each license has costs and restricts what I can do in an app.

As an ISV selling Managed packages through the AppExchange and the LMA app I am mostly restricted to a Yes/No type licensing. Either a User has permission to my app or not.

Sure I can build in a detailed model of permissions of

and check for them in my code using FeatureManagement.checkPermission('CustomPermissionName'). But only the subscriber admin decides who gets assigned such Permissions. There is no way I as the app vendor can say "You can only assign the "TimeMachine" Permission to 2 users.

This on the other hand can be done by using the Feature Management App (FMA) but there is no connection to this hierarchy and power of Permissions.

I would like to combine the two concepts by

  1. having a Feature Parameter assigning a distinct Permission Set Group to a user
  2. check in code if the user has this Feature enabled.
  3. Reject the call if he is not allowed.

But as I understand to do that I would need to control which user gets assigned which of my packaged permissions. But it looks like I just cant do that. There is no PermissionAssignement trigger or something?

3

Please, never use extension packages for features.

Features are related to pricing, pricing is related to marketing and sales. And by putting features in extension packages, you are roping your sales and marketing to your app's architecture. It's a recipe for future disasters, even if it seems like a great idea now. Just like getting a tattoo of your boyfriend's/girlfriend's name on your arm might seem like a good idea at 19 but you'll probably regret it later.

Not to mention you will make trial upgrades, or downgrades, so much effort that the client will just skip the whole process.

The best way to handle complex per-org features is via protected custom settings. They are inaccessible to the user unless you expose them through your own VF/Lightning page, and your Apex can check to see if they are on or off. Their power, flexibility and granularity are virtually unlimited.

The hassle is setting those protected custom settings. I have personally seen partners take these different approaches:

  • A CD-Key esque approach
  • A hidden VF page that controls the custom settings
  • Requiring the customer to Grant Login Access so you can set the features on your end
  • Your own Webservice that the app calls daily to check what features it should have enabled

The last bullet point is the most work but is the only realistic option for a significant number of installs. If you aren't sure if you will take this option, future-proof your app by adding a remote site to a subdomain on your primary domain. This will give you flexibility later as remote sites can't be pushed into an app as 'live'.

I have built multiple apps on the AppExchange, and both I and all the other battle-scarred ISV's will say the same thing. Don't use Extension Packages for features.

| improve this answer | |
  • I fully agree with packages absolutely being no solution.Especially for a douzens of independant feature "license". I understand that protected settings plus a custom API are similar that FMA but since FMA exits I see no benefit in them. Do you? If you could restart would you use FMA? And how? And if not why not? – Robert Sösemann Apr 13 at 12:35
  • 1
    I view features as a chance to demonstrate value to customers. The FMA is a sledgehammer and Custom Settings are more like a delicate tool. For instance, if the feature is disabled, we can show the button, but when they click it they get an upsell message. Or we can meter it to X uses per month, or X times per user. Also, we can do this to introduce new features without having to call everyone and explain the features. They just magically appear with helpful context so people can call US and say "I want this feature!". So, maybe I would use the FMA, but I'm glad we don't. – StonyGrunow Apr 14 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.