Force.com provides Embedded Force.com and ISV partners a technology and distribution platform to build, test and release applications in the cloud. Once you have built and tested your application, you'll need to prepare for commercial distribution.

There are multiple areas to consider as you begin to release your app, and this article is intended to help you understand what steps to take. Depending how you plan to release your app, you will need to consider packaging, security, license management, distribution channels, future upgrades and support. This article is intended for partners of salesforce.com who plan to develop and release a Force.com app.

Prerequisite Reading

This article is for the partners who have already created their app and now want to understand how to release it. If you are still in development or looking to learn more around design, it is recommended you review the following articles:


Packaging is a means by which you can store and distribute the various components of your app. Once you have created a package, you can begin the process to release your app. Packages can be either Managed or Unmanaged. This article focuses on Managed Packages as they are ideal to ISVs because of their benefits, which include:

  • IP Protection
  • Support for Upgrades and Push Patch Upgrades
  • License Management and Administration
  • Aloha App compatibility

ISVs are eligible for many different environments (a.k.a. organizations or "orgs") during the app development and distribution life-cycle. If you are unfamiliar with the various environments available, you should review An Introduction to Environments. The most important thing to understand regarding this article is that Managed Packages can only be created in Developer Edition (DE) orgs. Now there are two types of DE orgs that you can sign up for:

  1. The standard DE org is available (for free) when you join DeveloperForce.
  2. The partner DE org is available to partners through the Partner Portal. This is essentially a standard DE org with more users, data storage and limits. Details of the partner DE org can be found on the Partner Development & Test Environments page.

Note: To be clear, both DE orgs described above will produce Managed Packages. The only difference is the second DE org listed has increased limits.

With that said, once you develop your app in one of the DE orgs mentioned above, creating a managed package is very simple and can be done following the steps listed in How to Create and Register a Package.

Beta Managed Package

Once the Managed Package is created, you'll want to first upload it as a beta Managed Package. A beta Managed Package is an early version of your Managed Package. The purpose of the beta Managed Package is to give you the ability to test the app before releasing. You can also share with pilot customers or prospect to facilitate early feedback. Beta Managed Packages are not production ready packages, as such; they cannot be installed in production orgs. They can ONLY be installed and tested in the following orgs:

Note: If you plan to test against Professional or Group Edition Partner Test environment, you will need to make sure your app is Apex Authorized and immune to Apps/Tabs/Object limits. Your app must first be a Managed Package (beta or released) to be granted these special permissions. Details can be found here. Be sure to specify that you need these permissions to complete your testing.

These partner test environments are available only to partners. They are very similar to production orgs, but they have been granted special permissions allowing the installation of beta Managed Package. Details of these special test environments can be found on the Partner Development & Test Environments page.

Once you release your managed package, certain components are locked allowing you to upgrade your package. As a result, certain destructive changes cannot be made if found during testing. As a beta Managed Package, the app is still completely unlocked allowing you to make any necessary fixes or changes discovered through testing. Once you release your managed package, certain components are locked and cannot be edited or deleted. To find a complete list of what components become locked, review Components Available in Managed Packages in Developing Packages for Distribution.

This is why it's so important you test the app thoroughly as a beta Managed Package before releasing. One other important area to focus on during testing is security.


Before you release your Managed Package, you'll want to ensure it adheres to our security recommendations. The Security page provides a wealth of knowledge and tools to help ensure your app is secure and optimized. In particular, the Force.com Security Source Scanner allows any developer to enter their admin username of their DE org and perform a scan of the Apex and Visualforce is the org to ensure security and development best practices are being utilized. To use the scanner, you must meet the following requirements:

  • Your salesforce.com account must have the "Author Apex" permission enabled.
  • The Force.com Security Source Scanner does not currently work in sandbox orgs. Please submit code from a trial or DE org.
  • Code must not be contained within a package. Source code that lives inside of packages is not scanned to avoid inadvertently scanning code unrelated to your application.

The scan looks for any anti-patterns such as ensuring your triggers are bulkified or making sure your test methods include assertion. Once the scan completes, a report will be generated and sent to the user's email address.

The recommend approach when submitting for Security Review is to:

  1. Visit the Security page for requirements and guidelines during your development phases.
  2. Use the free testing tools to validate code prior to creating a Managed Package.
  3. Upload your released Managed Package, only after completing steps 1 and 2
  4. Log into the AppExchange (using the same DE credentials where you created your app) and click Start Review in AppExchange Publishing area.

Released Managed Package

Once you have thoroughly tested your beta Managed Package and passed the Security Review, you'll want to upload the Managed Package in a released state. The process to upload a released Managed Package is identical to the process for beta, except you select Managed-Released in the Upload Package page (Figure 1).

Figure 1: Uploading a released Managed Package

Once released, the app can now be installed in all orgs (including productions) as long as the features/objects in your app are supported by the end-customer edition.

Packaging Best Practices

The way you package your app can have direct impact on your customers' experience. If you package your app in the right way, you can ensure the installation experience is simple with many steps already complete. With each new release, more components of the platform can be packaged automatically. To find a complete list, review Components Available in Managed Packages in Developing Packages for Distribution.

For instance, as of Summer '10, you can streamline the installation process by automatically packaging remote sites (if you app makes any external callouts), button overrides for custom objects, and more. For anything that can't be packaged and automatically setup, you should include a configuration guide. You can do this by creating a custom link that opens up into a new window to your configuration steps. Adding this custom link to your package will automatically add a Configure button, so the customer can easily access the post-installation steps (Figure 2).

Figure 2: Add a Configure button to assist with post-installation steps

Finally, be sure to review the new release page to see if there are any new enhancements to packaging your app you can leverage. Next, you'll want to setup licensing so you can track installs and administer access.

License Management

License Management starts with the Licenses Management App (LMA). The LMA is developed by Salesforce and is available to eligible partners. For more information on the Partner Program, including eligibility requirements, please visit us at www.salesforce.com/partners.

With the LMA, partners can:

  • Set up trial defaults
  • Track installations and used licenses
  • Extend, activate, suspend or expire licenses

The LMA should be installed in a production org. The org needs to be Enterprise or Unlimited Edition because of the features required to use the app. Partners who do not have a compatible production org are eligible for a 2-user Enterprise Edition org. Details can be found here. Once you install LMA into your production org, this org will be known as your License Management Org (LMO). The LMO will store the licenses, leads, packages and package versions associate to your Managed Package. It is important to note that the LMA cannot be uninstalled, so be sure to review the org before installing. If you decide to release multiple managed package apps, you can use one LMO to manage all of these packages. This will ensure all of your prospects and customers are all in one org.

To associate your Managed Package to your LMO, you need to use the AppExchange. You can only associate a released Managed Package to your LMO. You cannot associate a beta Managed Package or an Unmanaged Package. After you have successfully uploaded your released Managed Package, you will need to login to the AppExchange. Follow these steps to complete the associate:

  1. Visit AppExchange and click the Publishing tab.
  2. Login with your DE credentials - if you have a different publisher profile you'd like to use, you can change this later by following this guide.
  3. Next you must navigate to the Default License Settings page to setup the LMO association.
  4. To access the Default License Settings page, click Manage Licenses link next to the managed package in the Your Uploaded Packages section of the Publishing Home page.
  5. The first time you associate the managed package to the LMO, you will be required to register the package. When the Register Your Uploaded Package page appears, click Register to register your uploaded package.
  6. Specify the username and password of your LMO. After you set this, all subsequent versions of your managed package will automatically be associated to the same LMO and the LMO name and org id will be displayed.
  7. Select whether your default license is a free trial or active. If your app is free, then select active.
  8. If you selected a free trial license, enter the length of the trial in number of whole days, up to 90. A trial cannot last more than 90 days, even if you try to extend this in the LMO. If you selected an active license, enter the license length in number of days. If your license is free or does not expire, select License does not expire.
  9. Enter the number of seats associated with your default license, or select License is site-wide to offer the license to all users in the installer's organization. If you select site-wide, the customer will not need to setup licensing when installing.
  10. Click Save to submit your changes.

Note: If a previous version of your package is associated with an LMO, when you register your uploaded package, the package is associated with the same LMO and the default license settings are initially set to the previous version’s settings. You can override the default license settings, but you cannot change the LMO.

License Assignment Best Practices

Depending on how you setup your license defaults, the customer experience will vary. If you decide to define a default number of seats, this means the admin will need to assign licenses to any user interested in using the app including him/her. After install, the admin will need to assign licenses for the install managed package.

An alternative path that is recommended is to set your license default to site-wide (Figure 3). The benefit is that the installation process will be even easier for the customer since they will not need to assign licenses initially. Instead, licenses will be automatically assigned to all your users and the ability to manage licenses will not available. Your users will have instant access to your app as long as they have the appropriate profile and permissions.

Figure 3: Associating your LMO and defining Default License Setting

Before you trial expires, you will then want to reach out to your customer and determine the number of licenses they want to purchase. If they don't want site-wide, you can change this at the license record in your LMO by editing the license (Figure 4). If you set the license to a specific number of seats, then you will need to guide the user to assign licenses to their users as discussed previous. The steps for your customer can be found here.

Figure 4: Defining the number of seats for a customer license

The end result is a better user experience for your customers when installing your app. Once you have configured your licensing, you can begin planning your distribution strategy.

Distributing your App

In addition to a technology platform for application development, Force.com also provides multiple distribution options to launch your app and go to market. The 2 options for partners with commercial intent are AppExchange and Trialforce. As a partner, you can leverage either or both. It is important to note, regardless of which distribution path you decide, you should still follow the steps above.

Note: If you plan to distribute your app through a public listing on the AppExchange, you MUST PASS the Security Review. Be sure to review the Security section above.


The AppExchange is a directory of apps that can be installed by salesforce.com customers. If you plan to release an app that is for existing salesforce.com customers, you will want to leverage the AppExchange. As of July 2010, there are 77,300 customers that could potentially use your app, so this can be a very effective distribution engine.

In order to make your app public on the AppExchange, you will need to complete all of the prior steps to prepare your package, pass Security Review and associate your license management. Creating your AppExchange listing is done at the Publisher tab of AppExchange. Once you login, you can follow these steps for creating and editing your listing (Figure 5).

Figure 5: Creating and Editing your AppExchange Listing

If you have a different publisher profile that you'd like to link your managed package to, then follow these steps:

  1. Determine which org will become your master org for all your publishing tasks (The recommendation is your production org, such as your License Management Org that contains the LMA).
  2. Visit the AppExchange, click the Publishing tab and log in with this org.
  3. Click the Your Organizations link (Figure 6).
  4. Click the Link New Organization button to start linking others orgs such as your developer and Trialforce master orgs to your AppExchange publishing org (Figure 7).

Figure 6: Managing Your Linked Organizations

After you link all your organizations, the next time you log into the AppExchange Publishing page using this org, you will be able to see all the listings, packages and trial templates across all your linked orgs. Details can be found in the online help.

Figure 7: Linking New Organizations to your AppExchange Publishing org

Once you complete your listing and pass the Security Review, you can make your listing public to all customers who browse the AppExchange. This lets customers browse, review, try, and install your app into their instance of Salesforce. Depending how you configured your listing (Figure 8), you can capture lead info from any prospect who watches the demo, tries the test drive, install via Get It Now, or sign up for a new trial.

Figure 8: Defining your Lead Settings to track prospects

As of August 2010, you can now offer free trials of your app through the AppExchange. In order to install an AppExchange app, you must be a Salesforce Administrator and already have a Salesforce org. However, with this new behavior, you can also offer your prospects the ability to provision a trial of Salesforce with your app pre-installed. This is perfect for non-admins, prospects who don't have Salesforce, and admins who'd like to kick the tires before installing into their sandbox/production org. To learn how to take advantage of this new functionality, visit How to Create a Trial on AppExchange.

AppExchange Publishing Best Practices

Your AppExchange listing is one of the first experiences your customer will have with your app. As such, it's imperative the experience is high value and results in a trial. The best way to ensure this is to make your AppExchange listing as compelling as possible. Some recommendations are:

  • Use graphics in your banner and promotion to make your listing more attractive.
  • Follow these methods to ensure your customers find your listing.
  • Use clear, honest and consistent messaging in your abstract, pricing, highlights, descriptions, system requirements and support options when describing your app.
  • Incorporate HTML to make the text more engaging.
  • Customers love to try before they buy, so give them as many options to experience your app before installing including screenshots, demos videos, test drive, data sheets, white papers, testimonials, recorded webinars, etc.
  • Have a free trial that allows your user to fully take advantage of your app before they buy.

The following slide outlines the top 5 best practices to consider when creating your AppExchange listing.


Trialforce is a distribution technology allowing you to provision a free trial of your app. This is done by creating a bundled trial with your app preinstalled and configured in a Salesforce or Force.com Edition org. The benefits are:

  • You can distribute a turn-key solution to customers who don't use Salesforce
  • You can provide trials of your app to non-System Administrators who normally cannot install an app from the AppExchange

With Trialforce, you can create copies of an org that has your app installed and already setup, thus making the trial experience instant and more valuable. Your customers will be able to get started immediately with little to no configuration required.

Trialforce is ideal when selling to customers who don't have Salesforce. If you customers already have Salesforce, they can take advantage of AppExchange to install your app into their existing Salesforce org. In the event the prospect is not a Salesforce Admin, or they would like to try your app in a separate org before installing into their existing org, Trialforce offers an easy alternative for them to leverage.

For more details, review the Trialforce page for an overview and instructions for setup.

Trialforce Best Practices

Since Trialforce is intended for an audience new to your app, Salesforce and Force.com, it's important to help guide your prospect during the trial experience to help them fully appreciate your offering. Here is a list of tips when building your Trialforce master org:

  • Include sample data in your Trialforce master, so your prospects have sample data to see your trial in action. Note: if your app requires a lot of sample data, it's even better to include a feature to delete sample data to help them transition to an active customer.
  • Setup a Getting Started page with an overview describing your app and other areas of Salesforce/Force.com that are relevant.
  • Be sure your trial is already fully customized and configured, so your user can start using the app, instead of configuring it.
  • Provide clear actions for your customer to purchase, find support, provide feedback, etc.
  • Test the trial experience with novice users before releasing to ensure a positive experience.

Upgrading your App

When selling a cloud computing app, you'll likely want to release new features and/or bug fixes. Force.com covers this crucial requirement in its distribution technology. Using Managed Packages, you'll be able to offer you customers an easy way to upgrade their existing version of your app. Certain upgrades, such as enhancements to Apex Code and Visualforce, can also be push-upgraded to make the experience for your customers seamless and transparent.

To upgrade a package, you must go back to the original DE org that was used to build your app. Similarly to building your original package, you'll want to create your new functionality in the same org and add the related new components to your managed package. Some components are automatically added to the package such as a new field on an object that was previously packaged or changes to Apex Code for a class that was previously added. For more information about publishing upgrades, review the documentation. Once you've published your upgrade, it is recommended you use the LMA to discover all your existing customers and what versions they are currently using. This way you can create customized emails and configuration guides to help upgrade each of your customers.

As of Summer '10, partners can now leverage push upgrading for Apex Code and Visualforce enhancements. To take advantage of push upgrading, you must be an eligible partner. For more information on the Partner Program, including eligibility requirements, please visit us at www.salesforce.com/partners. Once enabled, you will need to create a patch. A patch is essentially a minor upgrade that just focuses on Apex Code and Visualforce changes. Review the documentation to learn how to create and upload patches. Once complete, a patch can either be distributed by sharing the install link or scheduling a push upgrade. Push upgrading is ideal as the upgrade experience becomes transparent for your customers, requiring no work on their side. Details about scheduling a push upgrade can be found here.

Upgrading Best Practices

Similar to installing your app, upgrading could require some additional steps that are not automated. Here are some recommendations:

  • Include an upgrade guide for your existing customers to follow.
  • Don't assume all your customers are on your latest version, so test upgrades from every prior version and have appropriate documentation prepared.
  • Test your upgrades thoroughly before sharing publicly.
  • Update your listing to make sure you newest version is being installed from the Get It Now.
  • Be sure to upgrade your Trialforce Master org and create a new snapshot if you are leveraging this distribution channel
  • If you decide to leverage push upgrading, it's recommend you first review the Best Practices for Push Upgrades and Patch Versions.
  • Consider building functionality in your app that proactively notifies customers when a new version is available, perhaps on your Getting Started page.
  • Review the new release page to see if there are any new enhancements to upgrading your app you can leverage.


As a partner with a cloud computing app, there may be times when you need to support your prospects or customers. Using the LMA, you have insight into what prospects have installed your app and how many users are using your app. For every license created in the LMO, there's also a related Lead created with the installer's name, company, and email address. Use this information to learn more about your lead, so if a support issue arises, you have the ability to contact them and provide the necessary support.

Support Best Practices

Support is one of the most important areas of your business to ensure success with your cloud computing app. To reduce and streamline support, here are some recommendations:

  • Have up-to-date documentation within the app to help mitigate customer cases.
  • Focus on user experience to design for error prevention and recovery. Review the following blog for some User Experience Best Practices.
  • Maintain your LMO to ensure you have your customer's latest information.
  • Add meaningful error message to help you and the user understand the core problem.
  • Ensure your team is helping your customers all upgrade to the latest version of your app.
  • Review the new release page to see if there are any new enhancements to supporting your app you can leverage.


Releasing your cloud computing app is just as important as design and development. Knowing these recommendations and best practices before you start the process to release will help save you time and reduce mistakes. Once you release your app publicly, it's now open to reviews, feedback, and more; so it's important to spend some time carefully planning your release to ensure success.


About the Author

Sati Hillyer is a Sr. Technical Alliances Manager at salesforce.com. His background consists of technical evangelism, product management and product marketing. At salesforce.com, his mission is to ensure partners experience technical success architecting their SaaS app and business on Force.com. He can always be reached on the discussion boards, look for shillyer.