Thoughts on technology and innovation
Ted Husted, Release Engineer
Archimedes said of the lever: "Give me a place to stand and I will move the world."
As a release engineer for Nimble AMS, one of my key responsibilities is to give people the levers they need to develop, test, and demonstrate our product. And, of course, by lever, I mean "environment".
In the land of software development, an environment is a place to work: a ready-to-use copy of an application, ideally loaded with a known configuration and starter set of sample data.
In Salesforce terms, an environment is referred to as an "org", which includes in one tidy bundle the user interface, configuration, data, and reports module. (While "org" stems from "organization", a Salesforce environment is sophisticated enough to also be thought of as an "organism".)
Happily, Salesforce provides us a couple of ways to create environments for development, testing, and demonstrations. The most common approach is to provision a "sandbox" clone of an org.
By clicking a button, and filling out a UI form, you can spawn a mirror image of an org's configuration, right down to the record Ids. The usernames and email addresses are changed in a predictable way that makes it easy to login to one sandbox or another.
As an ISV partner, NimbleUser has access to Trialforce, which can also provision new orgs (or "trials") that mirror the configuration and data of a master, source org.
As a best practice, Salesforce recommends using Trialforce to create environments for development, testing, and sales demos.
Compared to sandboxes, for ISVs, trials do include a number of handy improvements
Upgradable. You can start a prospect off on a trial, and then convert the org to production and keep whatever customizations you already made
Delete trial data. If you no longer need the data copied from the source org, there is a special setup feature to jettison all the data in the trial org.
Template snapshots. A trial is based on a stored snapshot. After creating the template, you can make changes to the source org without affecting what is provided in the trial from a prior template. So you can create a template for your GA release, to use with sales demos, training, and to verify support issues. Meanwhile, you can move on and start prepping the source org for the next release.
Adjust dates. As an option, all of the dates in an org can be adjusted relative to the org creation date. A brilliant feature that, when carefully used, keeps each trial template as fresh as the first.
Finite provisioning time. In practice, a trial is either available in twenty minutes, or, the process failed and you can try again. Sandboxes can take anywhere from minutes to days to provision, and you never know which it will be.
One login URL. Sandboxes are deployed to a separate set of servers. When logging in, or making an API call, you have to use test.salesforce.com instead of login.salesforce. Trials all use login.salesforce.com, just like production.
API provisioning. Trials can be provisioned through an API call, making the process easy to automate. (Words dear to every release engineer's heart.)
Inexhaustible well. An org can only have a certain number of sandboxes, but an ISV partner can request as many trials as needed.
Custom branding. As an option, you can "white label" a trial and hide the Salesforce branding.
There are also a few restrictions.
Expiration date. A sandbox can live forever, but trials have an expiration date. You can push the date out a bit, but if the trial is not converted to production, eventually it expires.
Feature license. A trial can only include the licenses you are authorized to resell. We resell Salesforce Platform licenses, and so our trials cannot include Community, Sales Cloud, or Knowledge licenses, among others. If we want to show off any of these features, which folks can still purchase direct from Salesforce, we have to switch over to a different test org.
Delete trial data. While convenient, the builtin record clearing feature can only delete a certain number of records. If you load too much sample data, you may need to use your own scripts to clean out the demo cruft.
Custom report types. Trials are limited to 50 custom report types, as compared to 200 report types for an enterprise org. If your package bundles report types, and you install other AppExchange apps as part of a sales demo, it's not hard to hit the limit.
Since trials were designed for a different purpose than sandboxes, there are more changes to the configuration.
If you'd like to see more of the restrictions documented in the Trialforce Overview, please vote for this idea in the very excellent Salesforce Community.
Are you using trials as part of your Salesforce offering? Are they working well? Or, are you considering trying trials now? If so, drop us a line, and join the conversation.
Ted Husted is a release engineer for Nimble AMS. "It's my job to make sure that we ship everything that's done, but not before its ready."