Free Trials on AppExchange: A Strategy Comparison

It is obvious that customers generally prefer to see the app in action before they decide to pay for it. Salesforce AppExchange partners are given a few options to configure the trial experience for their prospects.

Free Trial License

The most frequently used method is to enable a free trial license for a specific period of time.
This is the easiest option, however, there are a few lesser-known facts and differences depending on your licensing model that you should be aware of.

Generally, you configure a free trial by specifying two things:

1. For how many days the prospect will be able to test your app for free.
2. [If you distribute in a per-seat model] How many seats will be assigned to the customer for free by default when they install the trial.

The configuration is done from the Salesforce Partner Portal (https://partners.salesforce.com):

1. Log in to the portal.
2. Open the Publishing tab.

3. Select Technologies and click Edit Licenses near your current package version:

   
   

As the popup’s name suggests, you configure the default license configuration here – that means every time a customer installs your solution (either via package link URL or via AppExchange), this will be their default license. You can always change the license for individual customers in your License Management Org.

Free Trial License – Sandbox vs Production Installations

The license defaults topic gets a bit unintuitive when the prospect installs your app in a sandbox – in such a case, the number of given seats is ignored, and the customer always gets a full per-org license in the sandbox.

Free Trial License – Checkout vs Channel Order App

Also, if you decide to use Checkout to manage the payments, you have the option to decide whether you will require payment information before the trial or after it.

If you use Channel Order App, you don’t have this choice as you manage the payments on your own.

Test Drive

Sometimes you may want to provide a trial experience of your app in a managed Salesforce environment with prepopulated meaningful data so that the customer doesn’t need to prepare anything and can instantly see what the app is about.

This is exactly what the Test Drive is for. Here’s how it works:

1. You create a dedicated Salesforce org and install your package there.
2. You populate all the necessary records and configurations.
3. Create a read-only user with read access to the app’s features.
4. You connect the org with your listing using the read-only user’s credentials.

Now, every time a customer clicks "Try it" → "Try in a test drive org", they will be logged into your org in the read-only user’s context and will be able to do anything this user can.

It is important to properly narrow down access for this user so that your prospects don’t break or update any config during the test drive run – each customer technically uses the same org!

Test Drive might be a great way of demonstrating your app’s capabilities with perfectly configured data, but it also might not be a perfect fit for apps where read-only mode means no seen value.

If you’d like to see an example of a test drive, feel free to check out the one we configured for our ISV Analytics app.
To learn the details on how to configure the Test Drive org, refer to this article.

Test Drive – Lessons Learned

During the review of this post, my colleague asked why we don’t share our own mistakes from the process of managing the test drive.
I think that’s a great idea – at least you won’t make them ;D

1. Change password expiry policies for the public test drive user – it’s not a good feeling to discover that the test drive hasn’t worked for a month just because the password for the read-only user expired. I still don’t know if one of our prospects was presented with the "change password" screen and actually changed it 😛
2. Prevent the read-only user from making changes to their user profile. You don’t want your prospect to set the user email to fynnyjoke@spam.com and the profile avatar to some meme, right? Since by default Salesforce users can modify their profiles, you need to create additional validations on your test drive org.

Trialforce

There are situations, especially if you are an OEM Partner, when you might want to provision a new Salesforce org (from a template), with your app installed in it, for every prospect who wants to try out your app.
With Trialforce, you can do it, and the prospect can later turn that org into their new Salesforce production org. This is super useful for clients who don’t yet use Salesforce CRM, but need your app.

Contrary to Test Drive, here the customer gets full control over the org – there is no "read-only" constraint as other prospects will use totally separate orgs.

Here’s how it looks in practice (simplified version):

1. You create a Trialforce Source Org (TSO). Here, you install your app and provide any sample data/metadata your prospects might need.
2. From the TSO, you create a Trialforce Template – a template for the orgs your prospects will receive when taking your trial. Salesforce recommends having one template per app version, which means that every time you release significant new functionality, you should create a new Trialforce Template from the TSO.
3. Connect the template with your AppExchange listing.

Now, every time a customer clicks "Try it" → "Try in a new Trialforce org", a new Salesforce org will be provisioned based on the Trialforce Template, and they will be able to try your app there.

You can configure Trialforce to allow users to sign up for a trial org by filling out a form on your website, not only from the AppExchange listing. See more details here.

Trialforce is the most complex approach to configure of all the options I described. A typical Salesforce ISV partner who distributes apps to existing Salesforce customers will not benefit from it. However, this is the only reasonable method for OEM partners to provide a trial to prospects without an existing Salesforce CRM instance.

To learn the details of step-by-step Trialforce configuration, refer to this article.

Here’s how the different trial options are presented to the user when they click Try It on your AppExchange listing:

Conclusion

There are 3 major ways to provide a free trial of your app to your prospects. Here’s a quick comparison:

That’s all I have for you today 🙂 Let me know if it was helpful or if you have anything to add in the comments section.
If you need help with AppExchange app development, reach out to me directly (https://linkedin.com/in/bartosz-suchocki) or to anyone on our amazing team (https://linkedin.com/company/beyondtheclouddev).

Resources

• Default Licensing Setup
• Test Drive Configuration
• Trialforce Configuration
• ISV Analytics app