Understanding the AppExchange publishing process, environments, and app lifecycle

In response to some folks’ questions, I thought I’d write up a very brief summary of the “right” way to go about diving into the Salesforce.com Partner world, whether as an ISV / OEM. There’s an order to this madness that can help prevent “wow, wish I’d done it that way from the beginning” moments later on, plus, there’s a whole alphabet soup thrown around related to Salesforce environments / orgs of different types, and their roles in the partner lifecycle.

A quick check to see whether this article will be helpful. If you can identify the meaning and role of each of the following Salesforce-related abbreviations, you can get on with your day. Otherwise, keep reading!

• APO
• LMO
• PDE
• TMO
• ISV
• DE
• OEM
• LMA

What I’ll do in this article is to walk through a “recommended” process for getting started developing Salesforce.com applications, along the way highlighting different Salesforce.com Organization / Environment types, and at the end, I’ll briefly summarize. Here we go!

1. Register as a Salesforce.com Partner.

To do this, go to http://www.salesforce.com/partners/join/ and fill out the form. You’ll receive by email a login to the Salesforce.com Partner Portal, which allows you to do all sorts of necessary things in the Partner lifecycle, like creating special orgs, logging partner support cases, and getting access to special training materials, etc.

2. Start building your Application!

For native Force.com applications, this should take place in your managed-package development org. You will have one, and only one, of these for each Managed Package / App you are building on Salesforce.com. This org must, as the name suggests, be some sort of Developer Edition (DE) org. However, you have choices as to which type of Developer Edition org you can do this in, and one is better than the other:

• Regular DE Orgs: (totally fine, but not ideal) A regular 2-user DE org such as can be acquired by going to developer.force.com
• “Partner Developer Edition” (PDE) orgs (ideal, available to registered partners only: see step 1) A “Super-Sized” Developer Edition org, which can be obtained by registered Salesforce.com Partners by logging in to the Partner Portal, clicking “Create a Test Org”, and selecting, as the org type, “Partner Developer Edition”. This is the ideal place to develop a Managed Application for the AppExchange, as you can have up to 20 full Salesforce user licenses, and your data limits are higher than regular DE orgs’ limits, among other advantages.

Whichever of the two org types you go with, for each AppExchange Application that you would like to build, you must choose one org to be where you create your app’s corresponding “Managed Package” – the Salesforce.com application distribution mechanism. You can create a Package in Salesforce by going to Create > Packages. However, you cannot make a package “Managed” – the requirement for an AppExchange org – until you have chosen a Salesforce-unique namespace for the package, e.g. ‘acme’. Once you’ve chosen this, you’ll be able to convert your package, which contains all of your app’s custom objects, fields, Apex code, Visualforce pages/components, and many other possible metadata types, into a Managed package. Each Developer Edition org can only have one Managed Package, and namespaces cannot be migrated between orgs.

For those of you who did not know about the PDE org option, it is important to note that it is perfectly fine to have your managed-package development org be a regular DE org — there is no need for it to be a full PDE for it to be capable of publishing AppExchange apps. It just makes the development lifecycle a lot easier if you develop in a PDE.

3. Get an ISV / OEM Contract to legitimize your Salesforce.com Partnership

*WARNING*: This step takes a LONG TIME (read: MONTHS).

For those of you who are wondering why this is even necessary — why can’t I just build a managed package and then require that someone writes me a check before I give them an install link? — there are many reasons to go through the hassle. For one, the Salesforce.com Partner Program is pretty rocking — they have killer tools that you’re not going to get going with other partners like Zoho, who haven’t had the time to build up their Partner Programs as well as Salesforce.com has.  Second, you’ll find that unless you’re just writing a few apps for your company or small group of clients, the whole hand-out-install-links method just doesn’t work. At a base level, there’s no way to manage licenses, see who’s using your app, or distribute using Salesforce’s public channels (e.g. AppExchange). Basically: you NEED to go through this process, even though it’s painful. There’s some serious awesomeness at the end of the tunnel: dive in, and be patient. You’ll get through it.

Salesforce really has two Partner models, or ways you can sell your apps, described very well here: AppExchange Partner Programs and Models.

• ISVForce (the ISV program) – you sell apps meant to be installable into most any Salesforce org. Often these are general purposes utility apps, like data cleansing apps, integration tools, user interface development tools (like Skuid!), mapping apps, etc. Under this model, existing Salesforce users can be licensed to use your ISV app in addition to whatever other apps they currently have and in addition to their existing Salesforce CRM license.
• Force.com Embedded Edition (the OEM model) – this is for Partners who want to leverage the Force.com platform – e.g. the cloud platform, logins / roles / profiles / security, object building – everything BUT CRM Objects and Service Cloud, pretty much – as a base for an industry-specific offering, e.g. a student information system. Under this model, users come to YOU for a Salesforce license, and you give them a Platform License + your Application. They can’t access CRM Objects (e.g. Opportunities, Products) but they can access Accounts, Contacts, and the Force.com platform.

Basically, once you’re officially “in” to the Partner Program, you get all kind of power to develop killer apps, sell and manage licenses, and support your customers once they’ve subscribed.

But, getting back to the process, the first HUGE thing you get by finishing out your ISV / OEM contract is an Enterprise Edition CRM org with 2 free licenses (you can pay for more as your company grows). This is referred to variously as your CRM for Partners org, your  License Management Organization (LMO), your partner Business Org, and, as we’ll see later, it is recommended that this be your AppExchange Publishing Org (APO) as well, but it does not have to be — from here on out, I’ll refer to it as either your CRM org or your LMO, as well as your APO. In almost all cases, each company will only have one CRM/LMO org, which will be the place where you manage, for all of your company’s AppExchange applications/packages (some partners sell many different apps!), package versions, licenses, and customer relationships (e.g. Leads, Accounts, Contacts, Opportunities, etc.). Note: you MUST have an ISV / OEM Contract in place with Salesforce.com for them to provide you with this org with its two free licenses.

Once you have this org — note, you do NOT have to request this free org, you can pay full price for all of your users, but why not start with it?), immediately log a case in the Partner Portal to “Request the LMA” — this case asks Salesforce to install a special “License Management Application” (LMA), a managed package, into your CRM org. Once this is installed, congratulations, your CRM org has now also become your License Management Organization (LMO). This org will now be the place where all information about customer interactions with your apps/packages is sent, and where you should manage it. WITHOUT this app, you will be unable to use Salesforce’s license-management tools to keep track of who is doing trials of your apps, activating them once they’ve paid, adding additional licenses to orgs, using the Partner Black Tab / Subscriber Support functionality, etc.

The benefits of having this org are huge: all activity related to client interaction with the AppExchange are tracked in this org — if a client does a demo of your product, a new Lead is generated with Lead Source appropriately set to indicate that a Demo was done. If they do “Get it Now”, another Lead is generated with Lead Source set to “Package Installation”, and a new License record is created in this organization, TIED to the Lead. Once this Lead can be converted, the License records move right along into the Account and Contact, and you can do workflows on the Expiration Date / Install Date, etc.

So, for those of you stuck in Step 3, pulling your hair out, waiting for it to get finished, here are some ideas:

1. Keep developing your app! Make it super-rocking.
2. Along the way, get your app prepped for Security Review — put it through the the Checkmarx Security Scanner (for native apps), and all of the other security guidelines available over at security.force.com.
3. Get involved with the Salesforce Community, whether on the LinkedIn groups, Twitter, User Groups, Developer Boards, Salesforce StackExchange, etc. — build up your non-AppExchange distribution channels.
4. Make some help files. A great way to do this is to leverage BlueMango’s ScreenSteps technology.
5. Take your release notes training to stay current and take advantage of upcoming features.
6. Test your app (see Step 7) in different Salesforce.com editions, pushing out beta packages to make sure you don’t include any features that disqualify your app for inclusion in Group / Professional Edition. This can be a real lifesaver later on if you were hoping for your app to be available to these Edition types! Basically, any references to features / API objects not available to GE/PE subscribers will disquality your app from being installed into GE/PE orgs. You can often avoid these disqualifications through use of dynamic SOQL and DML, but always push out Managed Beta versions of your app and try to install them into test GE/PE orgs to make sure you didn’t miss something!

4. Link your orgs together via AppExchange

Once you have your two main orgs (1. your LMO / CRM org 2. your Managed Package Development Org), and have uploaded at least one Managed Released version of your managed package, login to the AppExchange using your Managed Package Development org credentials, click on your name in the top right corner, and click on the “Publishing Console” drop-down option.

You may be asked, immediately, to specify the credentials of the org where you want to manage licenses for your application. **Enter the credentials of your LMO/CRM org**.  At this point, a “Package” record and “Package Version” record(s) will be created in your LMO corresponding to the Package and Package Versions developed in your APO(s). If someone installs one of these Package Versions, new Lead and License records will be generated in your LMO corresponding to the installed Package Versions. NOTE: This can all happen WITHOUT having a Public AppExchange listing. You can use the LMO to activate licenses, extend trials (up to 90 days), enable Site licenses, or deactivate / suspend license records.

NOTE: Never delete License records from your LMO!!! You can’t recreate them – special magic happens on the backend that generates them, and this is non-reversible.

Now, we’re going to establish which org in our org network will play the role of AppExchange Publishing Organization / APO. To do this, go  on the “Publishing Console” area. From the main screen, click on “Your Organizations”.

You may be asked, immediately, whether your organization has done any AppExchange publishing before. If you click “Yes”, you will be asked to enter the credentials of your “AppExchange Publishing Organization / APO“. **Enter the credentials for your LMO / CRM org.** By doing this, you will define your LMO / CRM org as your APO, meaning that it is now the central place for managing all of your company’s AppExchange apps. This is recommended. It is possible for your APO to be your Managed Package Development org, but NOT recommended. If you need to change your APO, you typically are able to simply by clicking “Change my AppExchange Publishing Organization”, but if you already have a Public AppExchange release, this will not be possible – so you’ll need to  log a case in the Partner Portal, and they’ll change it for you.

Next, **link your Managed Package Development organization** by clicking “Link new Organization”. Enter the credentials of each Managed Package Development organization whose AppExchange listings and Licenses you’d like to manage through your LMO/CRM org’s umbrella.

Once this is done, you’ll be able to, by logging in to AppExchange with your LMO/CRM/APO credentials, see and manage all of your company’s AppExchange listings which you have linked to your APO! (Note: your CEO will like this! No logins to DE orgs needed, and single-sign on views are NICE. Very nice.) Just repeat this process every time you create a new AppExchange application, associating your managed package development orgs to your APO.

5. (Optional – mainly for ISV’s) Create an AppExchange listing

Login to AppExchange using your LMO/CRM/APO credentials, then go to the “Publishing” tab. Create a new Private listing corresponding to each of your Managed Apps. Part of your Private listing settings require you to choose a managed-released version of your app to associate with your package.

In order for the Listing to be changed from Private (meaning only you can see it) to Public (meaning that anyone can search AppExchange for it), your application will need to pass the Salesforce.com Security Review. To do this, click on the Package Version’s “Start Review” action. This will initiate a review process — you’ll get sent an email with a Security Review Questionnaire to fill out (not bad), which you’ll have to submit through the Partner Portal.

Once your app is Security Reviewed (usually takes 2-3 weeks for native apps if your Checkmarx report is error-free, but if you get hit for something, you’ll have to do it all over again, i.e. another 2 weeks), you’ll be able to make your app’s listing PUBLIC on AppExchange, and start earning revenue! Yay! Once customers start clicking “Get it Now”, new Leads and License records will be created in your LMO.

6. (For OEM’s using Trialforce) Create a Trialforce Management Organization

For OEM partners, who are using Force.com as a platform but are not using Salesforce.com CRM or Service Cloud objects, Trialforce is a massively powerful feature of the Force.com Partner Program. It basically lets you create your own trial environments, preconfigured exactly as you want with sample data, pre-installed packages (one or many!), metadata (e.g. reports, report types, custom settings data, public groups, you name it) — which will be used to create trial accounts for your prospective customers, saving them (and you) the hassle of having to set them up with an environment that really showcases your app in full working condition.

To start out with Trialforce, you need to create a Trialforce Management Organization (TMO): to start, create a DE / PDE org, and then go to the Partner Portal and log a case asking for this org to be made your TMO. Once this is enabled, a special “Trialforce” area will appear in the Setup menu below “Develop” and “Deploy”. This area allows you to spawn new Trialforce Master Orgs — these are the actual environments where you define the “trial templates”, from which trial orgs will be created for your customers. So to get this straight, you have ONE Trialforce Management Organization, for managing all of your one or many Trialforce Master orgs, which define the templates for your customer’s trial orgs. However, these Trialforce Management Orgs also serve another purpose, so let’s list out the two main uses of Trialforce Management Organizations:

1. Managing all of your Trialforce Orgs: the TF Management Org allows you to create  one or many Trialforce Master Orgs, which are “template” orgs which allow you to define full Salesforce environments pre-configured with sample data and one or multiple managed applications, which users can use as starting points when they click “Try this application in a free trial environment” from AppExchange, or from a form on your company’s website (if you’d prefer not to go through AppExchange at all). You can push out multiple “Snapshots” of each Master org’s configuration, and you then can change which “Snapshot” is used to actually populate customer trials. There’s two ways to define which “Snapshot” is used:
   1. For AppExchange initiated trials: go to the Appexchange Publishing Console and select which Trial Template you’d like to use. Note: these templates have to be Security Reviewed. However, this process is generally very quick, a few days at most.
   2. For Company-website initiated trials: go to the Partner Portal, and log a case, specifying the new Trialforce snapshot to use.
2. Managing your Custom Branding. From the Trialforce Management Organization, you can define Custom Email Branding to use with each of your Trialforce Master Orgs and define (through a slick builder) a Custom Login Site that users who started a trial using your Trialforce orgs will see INSTEAD of the default Salesforce login page.

7. Create Partner Test Organizations

From the Partner Portal’s “Create a Test Org” area, you can also create specially configured test orgs to use for validating your package internally. These orgs have special privileges:

1. You can write APEX in them, without a Sandbox or having to do Test Coverage.
2. You don’t have to pay for them (a plus!)
3. They have lots of different user licenses pre-configured, like Customer Portal, Partner Portal Gold, Salesforce Platform, etc., that you can use to experiment with these features / functionalities.
4. You can get them in any Salesforce edition type: e.g. you can create a test Group Edition org, Professional Edition org, or Enterprise Edition org. This is very useful for testing compatibility of your package with various edition’s feature restrictions.
5. YOu can request certain features to be activated in them for internal validation: e.g. you do NOT want to enable “Advanced Currency Management” in your managed package development org if you want your package to be installable into orgs that don’t need this, but you might want your package to play well with this feature. So, to test this, get a test org, and log a case to have this feature enabled, then install your package into it and see how it works.
6. You can install Managed – Beta packages in them.
7. They’re great for doing demos for Customers.
8. They come with 6 Sandboxes, including one Full sandbox, so it’s easy to quickly do Quality Assurance of new package version functionality in a sandbox of your main Customer Demo org
9. They have a decent amount of data space — more than your DE orgs will — so you can do load testing.

8. Support your customers

As either an ISV or an OEM, once you’ve got customers who have paid for your app, either through AppExchange Checkout / Recurly or through checks in the mail / credit card / direct deposit, and you’ve activated their licenses (through your LMO), you’ll want to be able to help your customers resolve any problems they may be having. For this, the Salesforce Partner Program has a great tool called the “Subscriber Support Console”, which comes along with the LMA and as such is automatically in your LMO. From the “Subscriber Support” tab included in this app, you can see ALL customers who have installed your application – getting a summary of their org and what packages from your company they have installed, whether those packages are active / expired, when they expire, what version their on, and more!

PLUS, your customers will actually be able to Grant Login Access to your company, in addition to Salesforce.com Support and their admins, so that you can, through the Subscriber Support tab, actually log-in to a customer’s org exactly AS a customer sees it, and make changes – this is known as “Partner Black Tab” access. You will actually get special privileges – for instance the ability to see Protected Custom Settings and set special Sharing Rules – that your customers cannot see on their own.

9. Upgrade / iterate your app

Your app is probably not going to stay the same, so how do you get your existing customers onto newer versions? And what if only certain customers should be upgraded, or if you want to try out upgrades / new features on certain beta-tester customers before all folks should get it?

Fortunately, Salesforce has tools for this as well. From your managed package development org, go to Create > Packages > “Your Package Name”, and click on “Versions”. Then, click on the “Push Upgrades” button. If you haven’t yet, you’ll need to go to Partner Portal to request access to this feature set. Once it’s enabled, though, you can do the following:

• Create Patch Development Orgs: “patch orgs” are like “branches” of a given Managed Released version (e.g. 1.24) of your package that customers may have installed. Each patch org, like their parent managed package development org, can actually create/upload package versions, however only certain components can be modified in patch orgs — no new fields, objects, or components can be added, but existing components, such as Apex code, can be modified to some extent. You can then PUSH these Patch versions to selected / all customers who are on the parent branch (e.g. you may develop a patch 1.24.1 – and then all customers on 1.24 are eligible to upgrade to 1.24.1)
•  Push Major Upgrades: as of Winter 13, you can actually push Major Releases of your package to customers as well – so customers on 1.6 can be upgraded to 1.24 directly, automatically, in the middle of the night, with no action on your end other than scheduling it to take place. However, this possibility is NOT to be taken lightly: tread carefully, following these guidelines.
• Manually Upgrade customer using install links: you can always take the install link from either a Patch version or a Major release version and manually install a package into a customer’s org by logging in to that org (if you have access), or having the customer log in to that org and pasting the link into the URL.

SUMMARY

Anyway, hope this was helpful. To review, do you know what these acronyms stand for now?

• DE – a Developer Edition org, where you can develop / experiment with Salesforce functionality
• PDE – Partner Developer Edition – a special “super-sized” development edition type appropriate for AppExchange application development
• LMA – the License Management Application. Each Partner should have ONE org, typically their CRM for Partners org, that has this installed in it. Whatever org has this app installed is dubbed the “License Management Org” / LMO.
• LMO – License Management Organization / Partner CRM org – where you track customers and package licenses, and support customers
• APO – AppExchange Publishing Organization – AppExchange terminology for the org that you would like to be the AppExchange listing management hub for all of your company’s AppExchange apps/listings. As a best practice, make this your LMO/CRM  org. This will allow you to manage all of your AppExchange listings from one place.
• TMO – Trialforce Management Organization – where you manage your company’s custom branding and create/manage your Trialforce Master Orgs
• ISV – a Salesforce partner who is part of the ISVforce program. Typically these partners build apps for AppExchange distribution, to fit in to any Salesforce org.
• OEM – an “Original Equipment Manufacturer”, but in the Salesforce world, a Partner who uses the Force.com Embedded Edition distribution model, selling Force.com Licenses (technically “Salesforce Platform” / AUL licenses) “embedded” in their application’s cost.