Understanding App Exchange LeadSource in the LMA

Great observations. I've encountered these are two variations:

1. 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

2. someone who holds the package install link (eg by copying it out of the URL) will get:

   • lead source Package Install
   • no campaign membership
   • a trial license created

I have found it gets confused if you log into the AppExchange with multiple Session Ids present, because that can cause the capture of lead 1 from your AppExchange login, but then creation of a License (and another lead 2) from the org whose credentials you actually provide for the install.

Similarly another edge case exists where the package has previously been installed, then the trial expires and it is uninstalled. When I later reinstalled it into the same org, a new trial License was not created (it reconnects the old license). A lot of this is undocumented, and I think is due to having Checkout set up to handle trials.

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.

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 actually installs and the LMA issues a license. Both of these lead creations can be lagged from the action, I've seen it delays up to 30 minutes. All you need to do in this typical scenario is merge the leads.

For Lead 3, it's not a typical case where you have the lead from the Get It Now action and the lead from the license creation. Something caused the SFDC IN lead to go missing.

As user320 mentions, it is possible to install from the direct install link for the package - this would get you the Package Install lead created but not the SFDC IN lead (because the second one is tied to the Get It Now action). This probably isn't the case since you say that all installs went through Get It Now button.

You may also be seeing the lag problem of the two leads not being created at same time, you may want to check for duplicate leads again and see if the other one has show up.

Finally, I have sometimes seen customers installing via Get It Now and two leads being created with different names. In these scenarios the SFDC IN lead will have a name and/or email that differs from the corresponding Package Install lead, but they're for the same org. This could be what's happening with Lead 3. Typically a search in the Subscribers tab for the org ID or org name will give you a hint about matching the two leads and merging them.

One other note that is not applicable to the scenario you describe but which is related and good to know: successful installs to a sandbox will not produce a Package Install lead, because no license is issued in the LMA. You will get an SFDC IN lead, and again, if you check in the Subscribers tab you will see an installation for the org name or ID. So just because you don't have a Package Install lead doesn't mean that the customer didn't successfully install to sandbox.