9
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 ...
6
The documentation doesn't clearly state "why not" (and this is a very common scenario with the documentation) in regards to leads and Sandbox installs, but I'd take an educated guess and say that Sandbox installs would most likely duplicate leads from one of the other four sources (production installs, test drives, demos, or trials), and are therefore too ...
5
On your first question:
We have configured our AppExchange listings to receive a new lead on install regardless of the type of org. This is just a matter of adjusting settings on the Leads tab of the publishing console in AppExchange and associating a Campaign record with the "Send me leads on install" line. Combined with a lead assignment rule we get an ...
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'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
I suspect it is only possible to manually allocate managed package user licenses.
"The bridge between The "manage Licenses" Section of the Installed App and the actual User Record is not reachable on the platform..." Ideas: Managed Package License Reporting
5
The listing did eventually show up - about three hours after the customer has installed the application. So yes, it does take some time for SFDC to propagate the update.
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?...
4
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 ...
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
Your production instance should be your APO and LMA, especially if you plan on charging for your app. You have to pay 15% or 25% as a partner, but it gives you perks. You should indeed get an ISV or OEM contract, that's what gives you the perks, such as uber-sized demo orgs, dev orgs, patch orgs, and client keys (for PE API access in your apps). File a case ...
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.
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
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
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
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
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 ...
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
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
You can do that - open a case and request this from Salesforce support.
2
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.
2
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 ...
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
