26
Thanks for the question! I've created an answer in three parts, each one meant to address a specific question you've asked.
PART ONE: How to Create Second-Generation Extension Packages
PART TWO: How to Get the LMA to "see" a Second-Generation Managed Package
PART THREE: Technical Enablement for Second-Generation Extension Packages
Not gonna lie, ...
11
The LMA has documentation here. There's a lot of reading material to go over, but basically it is pretty straight forward. You request an installation link to the package, you install the package into your business org (note: definitely not in a Developer Edition org), connect the app to your package, and finally configure any workflow rules or processes you ...
8
Great observations. I've encountered these are two variations:
someone who logs into the AppExchange and clicks Get It Now will have:
lead source SFDC IN|PackageName
appropriate campaign membership
a Trial license created
someone who holds the package install link (eg by copying it out of the URL) will get:
lead source Package Install
no campaign ...
5
Generally speaking, there's nothing "special" you need to do (in most cases). Once you switch to a per-license model, salesforce will automatically restrict access to all components in your package unless the logged in user has a license assigned, even if they have permission at the profile/permission set level. From their perspective, they won't even know ...
5
I know it is marked as an Answer because probably at that time this function wasn't yet devised by Salesforce, I'm adding the link for anyone coming to this question like I did today :-) ...
Assigning Licenses using the API
Also take a look at the Idea here Exposing License Management Objects to API and see the latest Comment from Product Management with ...
5
I've recently tested for all the cases dealing with Leads coming from the AppExchange (SFDC-XX) and Leads coming from an actual Package installation.
As expected, it's pretty confusing at times.
Here's a flowchart that explains everything, depending on whether an individual chooses to install your app on a Production/Dev org or a Sandbox.
5
All currently assigned users retain access to the application until they are deactivated by the Administrator. No further licenses can be assigned to other users until the License Count reaches a positive value.
This is mentioned in the documentation:
What happens when I decrease the number of available licenses below the current number of licensed users?...
5
In salesforce, access is controlled through Permission sets.
LMO org can assign how many feature-specific licenses are assigned using an FMA Integer parameter,
Currently there is no standard way to limit license specific permission set assignments
here is the approach I would take to breeze this gap
Create an Integer FMA parameter and permission ...
5
2GP managed packages only appear in the LMA after security review has been passed (as you have pondered). (Note that, as an aside, without the security review being passed it is actually impossible to create patch releases for a 2GP managed package.)
Publishing 2GPs on the AppExchange is explicitly covered in the documentation, as is dealing with 2GP ...
4
I don't know of any way of doing this, but maybe you could somehow capture the production org Id (post install script or at some point when they run your app in product) in a private custom setting, then read it once your in the sandbox.
4
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 ...
4
If you can, it's much better to use the License Management App application to access the debug logs from a managed package installed in a client org.
You'll find limited usage for a custom object logger, as even dumping the stack trace will be obscured to just the namespace in the subscriber org.
4
Install the LMA in your production org. This is necessary because the LMA will create leads for you as your clients install or try out your app. If you put this in your developer org, you may run out of storage space or might even accidentally create a dependency in your app on the LMA, which means your package could no longer be installed by clients.
4
As long as you have the package ID, you can:
sfdx force:package:install --package 04t... --targetusername scratchOrgAlias
If you don't have the package ID, you can't use this command.
You can get package IDs via:
sfdx force:package:installed:list -u prodOrgAlias
3
The required permission isn't called "Debug Apex" as it currently appears in the docs. Rather it is
Permission Name: View and Debug Managed Apex
Description: View the Apex code in your packages, and debug code with Apex Debugger, when logged in to subscriber orgs. Limited to code in Managed - Released packages.
This permission should be assigned to the ...
3
Should you need a custom logging class for your managed package?
Generally speaking, no. Some ISVs do decide to do this to avoid the complications of subscriber logging (you have to submit a case, etc), and the default Apex Error Notification system tends to work well enough, but if you feel it's inadequate, you certainly could build your own.
I'm aware ...
3
If you go to the Package in the LMA there is a "Refresh Licenses" button. Press that and then wait 24 hours for all the Subscriber information to be refreshed.
Otherwise you need to wait for the subscribers to install newer versions of the managed package that was created after the LMA app was setup.
3
This managed package application (namespace sfLma) includes conventional SObjects that you can access programmatically and see in the normal setup UI or in the Schema Builder:
So you can write Apex and SOQL that accesses these objects to achieve your goal. I also see the LMA objects in the report types so assume that you can create reports using them too. ...
3
As far as I know this is fine. The warning is really that if you have something, anything, that prevents the license record from saving you end up losing that license record.
However if you're making a callout you'll need to use Queueable - you can't make callouts directly from trigger contexts. That's actually good here since a callout failure in an async ...
3
You can use the Metadata API (just import that WSDL separately), login with the Partner WSDL, assign the endpoint/session ID to the Metadata API binding, then call listMetadata from the Metadata API. The specifics will depend on your programming language.
PartnerConnection partnerApi = new PartnerConnection();
LoginResult loginResult = partnerApi.login(...
3
How can I check license for a set of users other than current user?
Use UserPackageLicense:
SELECT UserId FROM UserPackageLicense WHERE PackageLicense.NamespacePrefix = 'your_prefix'
I'm aware that we can check licenses for the current user. But checking for licenses for X number of users would require a DML operation in every run. What are the best ...
2
I am assuming in your description that Lead 1 and Lead 2 are actually the same installer. This is the typical scenario, where both an SFDC IN|PackageName and a Package Install lead are created. The SFDC IN lead is created when a customer clicks Get It Now and gets as far as authenticating themselves. The Package Install link is created when the package ...
2
See Publish Your First App with AppExchange Checkout. It lists all the steps necessary to publish an app to the app exchange, including going through the required security review. There are lots of links from that page which provide additional details for anything you don't understand or steps you haven't completed. For a more comprehensive document, see the ...
2
Yes, it is mandatory to use the COA. It is used for two things:
For OEM partners the app is for provisioning the underlying salesforce.com licenses as well as revenue sharing
For ISVforce partners it is for revenue sharing.
Note that Salesforce explicitly tells you "Orders should be submitted based on the sales and licensing of applications to customers, ...
2
When your app is approved and passed security review, you can submit a case to have your ISV business org provisioned, or your current org upgraded to two full licenses, or two additional licenses added depending on the status of your current business org
2
You can do that - open a case and request this from Salesforce support.
2
You cannot limit access to the object aside from the local standard OWD and sharing settings.
And even at that logging will be limited to your specific text. Any errors logged via getMessage, getStacktraceString, or other apex methods would be obfuscated when written to the DB so it is not helpful.
LMA is best for real time debugging
2
A license allows the currently running user to use an app. Any user can be referenced normally (e.g. a custom lookup to a user), but they will be unable to query or modify the data that points to their user record. So, just like any other app, your licensing should be set for the number of users that will actually need the license attached to their user ...
2
Yes, Installing a package into a scratch org WILL create a license record in the LMA and a Lead Record.
The Lead name will be User User. I not not have a current one to check the org Status on the license, but the Sandbox checkbox will be true
Note Scratch orgs can live for up to 30 days
2
I don't think there's an explicit document that states this for sure, but checking a few different type of profiles based on license types, it appears that the Log in to Subscriber Org permission can only be set on Salesforce licenses. I don't have access to the more esoteric licenses, so I can't confirm all of the license types, but it seems that you need ...
Only top voted, non community-wiki answers of a minimum length are eligible