What should I use as my APO?

Question

I'm confused about what I should be using as my APO. I see a few options:

• Get a Business Org page from the ISVforce Guide suggests that I should Create A Case and apply for an ISV CRM. The instructions there are pretty outdated though (compared to the current "Create A Case" form), so I'm not sure if this is still the endorsed way to move forward?
• Create an AppExchange Publishing Organization page from the same ISVforce Guide suggests that I should create a DE organization from the partner portal. It later suggests making the APO the same as the LMO, which should be the ISV CRM mentioned above. Many other posts caution against using a DE as the APO.
• This post suggests that we should "Get an ISV / OEM Contract to Legitimize your Salesforce.com Partnership". I have no idea how to proceed on that, and if this is the same as filing the ticket for an ISV CRM (and if so, does it really take months?)
• Or should I just use our company's Salesforce instance directly?

Any guidance would be much appreciated!

Answer 1

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 for ISV or OEM status (OEM is if you want to resell CRM licences as part of your app, or ISV for selling to existing customers of salesforce.com). APO orgs receive leads, and LMA orgs track subscribers. There's definitely a strong reason to have APO and LMA in the same org for that reason. Don't make a DE into the LMA, you might run out of data space for subscribers, and billing will be a nightmare. Don't make the DE org the APO because you will probably lose leads. APO should be LMA so that you can convert leads into accounts and contacts. And LMA should be your production so you can pay your bills. You could use a ISV CRM DE org for APO and LMA, but that would still complicate things. Keep it simple. Your DE org for code, your production for licencing and billing.

Answer 2

One thing to be aware of though, is that whoever has access to the org where you have your APO linked, will also have access to the AppExchange publishing console.

To exemplify, if you have one SF Admin and five Standard Users on the org where you have the APO connected to, everyone will have editing rights to your AppExchange listing, through the Publishing console in the AppExchange.

It might not bother some partners, but it's just a caveat for people who are possible contracting external sales people and bringing them into their Salesforce org.

Answer 3

Great information, thanks for the insight. We have heard (and read) that making the production org the APO can cause significant debilitating issues with the Lead objects. Can anyone speak from experience or offer best practices here? Here are some articles on the subject:

http://www.salesforce.com/docs/en/lma/Content/lma_sales_marketing.htm

LMA Guide: https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/lma_overview.htm?language=en

specifically these pages:

Installing the LMA: https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/lma_system_requirements.htm?language=en Before you install the LMA, you need to decide which organization is your License Management Organization (LMO). Because the LMA is an integral part of the sales, billing, and marketing of a managed package, putting the LMA in the wrong organization makes it difficult to manage licenses as a part of the sales and marketing process.

Integrating with Sales and Marketing: https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/lma_sales_marketing.htm?language=en Do not create workflow rules, triggers, or validation rules that required custom fields on the license or lead objects. Do not impose any conditions on updating or creating license or lead records. Doing so will block creation of the license or lead records by the LMA, resulting in the loss of data concerning the packages installed by your customers.

Best Practices: https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/lma_best_practice.htm?language=en Avoid mandatory fields Don't define before-create triggers or validation rules on lead Troubleshooting: https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/lma_troubleshooting.htm#lma_troubleshooting?language=en (paraphrased): Is there a trigger on the lead or license object in the LMO? If so, Remove it Is there a required custom field on the lead or license record? If so, Remove it Is there a validation rule on the lead or license record? If so, Remove it Is there a workflow rule on lead or licenses? If so, Remove it