function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

isCurrentUserLicensed() worthless inside managed package?

Hey folks,


I have some Visualforce pages in a managed package that I would like to expose to ALL users in an org (ALL meaning those with a license to my app and those who do not) and based on whether they have a license or not it will act differently.


At first glance I thought, hey cool they have a function for exactly that... I can call UserInfo.isCurrentUserLicensed('myApp') to find out and act accordingly.


Upon further thought, I realized that no code from the package can ever be run by unlicensed users in the first place, so there is no way to perform such a check... am I missing something?  Or is this method not able to be used from within a managed package?


You can use it in your own code to see if a user has a license to something else you've installed... or one partner app could use it to see if you have their competitors product installed (LOL) but nether of those seem all that helpful.  Any idea what this method is good for?


In case you are wondering, this is another thread that explains what I am trying to accomplish which lead me to wonder about this method:


Code from your package can be run by an unlicensed user in some contexts, and so isCurrentUserLicensed is with purpose ... it tells you if the current user is licensed. Now, that sounds redundant, but there are at least a couple scenarios where you would care:


1) "Global" classes can be globally accessed (outside the package), even without a license, so you might want to restrict access to the class by returning or throwing an error if the user is not licensed. This is probably most useful for webservice methods, REST methods, Batchable Interfaces, and so on, where they must be global to be used in that context, yet they may be restricted in usage.


2) Triggers run in system mode. All the time. Just because the user isn't licensed doesn't mean the trigger itself won't run. But if that trigger does something that it should only do for a licensed user, you can check for that. Consider an address validation trigger that uses a callout. No license, no callout.


In addition to the above, its possible that there are other conditions that can cause your managed code to run with impunity.


However, that doesn't fully answer your (other) question, so I'd say that you'll have to create a global class as the constructor for a interim page that checks for licensing, then directs the user to the correct page, be it a system page or your custom page. I don't believe that "pages" of themselves require licensing, it's the controllers that cause the licensing effect. This statement might be incorrect, though; I simply don't have enough experience with LMA and packaging to know the specific nuances that way, nor do I currently have the time to set this up.


If you're willing to wait a day or two, I would be more than willing to try this out in my dummy dev org that has a managed package with LMA, just to see if it works.


Edit: Why not try an unmanaged package, or a separate managed package, that calls the appropriate pages? I know it's a bit like sawing your foot off to save your life, but at least it should be viable.


Mr. Fox,


Thank you for the thorough and awesome response.  I had also reached out to some packaging experts via email with my issue and they said as you did that while there are some situations the method can be helpful (global classes and triggers) it will not help me because Visualforce Pages and the Controller Extension and other utility classes can only be run if you have a license.


I did a test as you described, and even a simple page with no controller will display a "License Required" error.


It's a bummer, now I'm working with salesforce to determine if it's possible for them to shut off license enforcement altogether for my app and let me handle it myself.  I've basically gotten a "maybe" back, which means that even if it's a yes it would take quite a while.


The only workaround will be: 1) charge "per org" for the app so that no matter what everyone has access  and 2) Have a second free package that gets installed after the first and the customer overrides their buttons with pages in the free app, which does the check and if they have a license for the paid app will direct them to that page... this is an ugly workaround that I really don't think is feasible as installation then becomes a support nightmare, and a free trial becomes more of a hassle than anything.

Rogerio Da SilvaRogerio Da Silva
Hey Michael,

Did salesforce return to you with a workaround or did you find a solution for this item?

David Torres 15David Torres 15
Hey guys, how can I test my restricted feautures in a Beta? there is no way of handling licenses in a package. any suggestion?? thx in adv.