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.
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:
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:
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.
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:
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:
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).
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.
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).
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 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:
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:
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.
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.
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.
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.
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.
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).
If you have a different publisher profile that you'd like to link your managed package to, then follow these steps:
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.
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.
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.
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:
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:
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.
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:
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.
Similar to installing your app, upgrading could require some additional steps that are not automated. Here are some recommendations:
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 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:
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.
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.