Fine-grained app licensing using FMA and Permission Set Groups

Question

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

• Permission Sets
• Custom Permissions
• Permission Set Groups

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?

Answer 1

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.