I've built out a fully-featured managed Salesforce app that I would like to now split into multiple price tiers with different features. Has anyone successfully implemented an extension package that essentially 'unlocks' features in the base package? With all of the tool's functionality in the main package, I'd rather not have to pull code out of the main package and into extension packages if I can avoid it.

I'm hoping for some sort of way, either leveraging extension packages or the license management app, to be able to decide whether or not to make certain app features available to the current licensed user.

Is this at all possible?

1 Answer 1


We have used the following technique for a similar situation.

We have added a custom field to the License object in our LMA org and added a Force.com site (so public, meaning no authentication is required) @RestResource GET API that allows the value to be accessed for a specific org. The underlying query of this form:

select CustomField__c
from sfLma__License__c
where sfLma__Subscriber_Org_ID__c = :subscriberOrgId
and sfLma__Package_Version__r.sfLma__Package__r.sfLma__Package_Id__c = 'xxxxxxxxxxxxxxx'

Then in our managed package that value is queried over HTTPS with the request providing the org ID and the returned value is cached in a protected custom setting.

As the customer cannot tamper with that managed package code and cannot alter the value returned from the LMA org (without some serious network hacking), we can use the CustomField__c value to enable the managed package code features. And changing the enabled features just requires a simple edit of the LMA app License object.

(You could also use multiple additional managed packages to provide flags. At its simplest the managed package would be more or less empty - one managed package per feature - and the base package would just use the UserInfo. isCurrentUserLicensed API to see if the feature is licensed. Or you could just query for a marker class of the expected namespace included in he additional managed package.)

  • 1
    isCurrentUserLicenced is an easy way to do this per user if you split licences that way, but remember to catch exceptions if the org doesn't have the sub package installed.
    – sfdcfox
    Commented Dec 17, 2014 at 4:03
  • Thanks Keith, this is definitely the approach I was looking for. I really didn't want to go down the path of extension packages, so this should work well. I'll give this a try and see how it works.
    – emroc
    Commented Dec 17, 2014 at 14:40
  • Very creative approach! Commented Aug 7, 2015 at 11:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .