​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.

  • Record IDs. All the record ids change. (Sandboxes mirror the ids at the time it is created.)
  • Usernames. The initial user has a known ID, but any other users in your source org are changed to include an arbitrary hash, meaning you can’t predict the new username. (Sandboxes use the sandbox name to usernames to make then unique.)
  • @example.com. Trials change all of the domains to @example.com. (Sandbox emails are changed using the same pattern as usernames.)
  • Password policies. Trials always reset the policies to the factory defaults. (Sandboxes inherit the same password policies.)
  • Encrypted data. Trials cannot mirror the key, and any encrypted fields must be repopulated. (Sandboxes can mirror the key used for the encrypted fields feature.)
  • Template blackout. Salesforce rolls out a major release three times a year. For trials, there is an eight-day blackout on new templates while the release rolls out to all the orgs. You can still provision trials from prior templates, you just can’t create new templates for several days. (Sandboxes can be provisioned at any time — though you might end up on the new release before the production org is upgraded.)
  • cloudforce.com. If you use the custom branding option, and do not specify a custom subdomain when provisioning a trial, the trial is provisioned on the “cloudforce.com” domain instead of “salesforce.com”, which doesn’t change, even when the trial is upgrade to production. When an org is provisioned on cloudforce.com, you cannot use the Social Contact feature with Facebook. (Sandboxes mirror the subdomains under a different server id.)

On balance, we find that using trials for All The Things is a better approach than trying to do the same with developer orgs or sandboxes. Even so, trials are not without their blemishes: forewarned is forearmed.

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.”