Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I am having a similar problem as the one in this post where my leads are coming in with differing sources. All installation attempts used "Get it now" from the listing on App Exchange and successfully went through the installation wizard on the first try. The listing in the App Exchange has "Send me Leads on install" checked, along with an associated campaign.

  1. User 1: Lead 1, from dev org 1, had LeadSource "Package Install" and had a license created, in campaign
  2. User 2: Lead 2, from dev org 1, had LeadSource "SFDC IN|PackageName" but no license, in campaign (uninstall/install)
  3. User 3: Lead 3, from dev org 2, had LeadSource "Package Install" and had a license created, in campaign

Should I give up on using LeadSource and the Product Interest fields for filtering Leads and just use Campaign Members? Is there any way to get consistent behavior?

Reference:

Leads created by the LMA

License Management and Support Guide

share|improve this question
    
I have encountered another scenario related to Test Drive. May I suggest that you add that to the above scenarios and flowchart for the sake of completion (I cannot comment directly). Using Test Drive (with Read Only SF Profile) may show also as "Uninstalled" in the "License Status" filed of the License record in LMA. –  R.Epstein May 20 at 8:00

3 Answers 3

up vote 7 down vote accepted

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.

share|improve this answer
    
But for all of my tests I followed the same pattern; log into the dev org, use the link in the App drop-down to go to App Exchange, search for the package, and click Get It Now. I never used the direct installation link. –  Mike Chale Apr 17 at 14:27
    
Wow. This could really use a deep dive to distill out all the behavioural variations. @MikeChale –  bigassforce Apr 17 at 14:49
2  
Great point about the re-connected license for an uninstalled trial. Assuming installer comes through Get It Now button this is another case where you'd get SFDC IN lead but no Package Install lead. The updated license info will still be on the original install lead. –  Eric Wu Apr 17 at 14:55

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.

enter image description here

share|improve this answer
    
Nice exploration and contribution! Feel free to upload and inline the PNG in your answer for future viewers. –  bigassforce May 6 at 20:07

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.

share|improve this answer
    
Thanks, Eric. I'll clarify my question, but Leads 1 & 2 were two different users from the same dev org. –  Mike Chale Apr 17 at 15:00
1  
Hmm, so Lead 1 is missing the SFDC IN lead, but given that the package was successfully installed to Dev Org 1 that explains why Lead 2 didn't have a corresponding Package Install lead as it was already installed. I wonder if Lead 1 and Lead 3 share any traits that could have caused SFDC IN lead to not be created? –  Eric Wu Apr 17 at 15:08
    
I'm sure there's a logical explanation and a common link, but I just don't know where to look. I'm guessing it's something about the user record or I somehow installed differently without realizing it. –  Mike Chale Apr 17 at 15:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.