Build for scale sooner than you think

Build your Salesforce deployment process like you’re a medium-sized company when you’re small, and like a big company when you’re medium-sized. That’s because by the time you feel the need for better processes, it will already be too late. The wrong processes will have solidified and you’ll be too busy to fight against ingrained user habits.
‍
In practice, building for scale means standardizing how you name things in Salesforce. It means documenting how you built each environment (and why), and asking people to submit tickets and provide justification for their requests, even if it all just gets routed to you.
‍

To build your Salesforce deployment strategy for scale:

• Publish a data dictionary—This is a living document where you define all your naming conventions, schema, and data types, and rigidly adhere to a structure.
• Limit one-off code—If you know Apex, it’s tempting to write a script and be done, but it’s not sustainable. At some point, someone is going to ignore the warning you left in the debug logs and overwrite it.
• Start documenting—What seems like a waste today will be an invaluable record tomorrow. Creating documentation is the only way you’ll help new hires understand what you’ve built. In Salesforce, this means assigning a unique identifier to each change and linking that change to its justification in a ticket in Jira or ServiceNow.

‍

‍

Restrict permissions and adhere to a release management process

You will thank yourself for implementing strict permissions early—especially around deployment. Half the challenge with a Salesforce release management process is coordinating everyone’s work, and retaining a record of what’s changed.
‍
With regard to documenting releases, Salesforce’s audit trail often doesn’t give you sufficient detail. It may tell you that something changed, but perhaps not what changed, or who did it. Thus, you’ll find it’s better to move a little slower and be a bottleneck than to have no process, run into an issue, and realize nobody knows the configuration well enough to debug.
‍
Specifically, a release management process means:

• Limiting deployment privileges
• Establishing set roles and responsibilities for deployments (the RACI model is a good start) where someone has to check (QA) and approve changes
• Releasing changes at fixed, regular, well-known times
• Setting blackout times so you don’t release just before quarter-end rushes
  ‍

Practice full software development change management

There’s a lot that Salesforce managers can borrow from the software development world to ensure smooth, error-free deliveries. That includes practices like:

• Version control—This is the practice of maintaining duplicate, non-production versions of your Salesforce environment for testing. It also allows you to revert if something goes wrong.
• Analyze dependencies—Salesforce change set tests may find nothing wrong with your code, but then again, they can’t detect logical fallacies or unintended consequences. For example, deleting a field in Salesforce could irreversibly delete metadata in the ERP, and there’d be no way to know. Salesforce doesn’t provide a tool for analyzing dependencies natively, so you’ll need to find one.
• Collaborate in a code repository—Salesforce’s metadata doesn’t feature any collaboration tools. You’ll want to mimic software developers and use a code repository like GitHub or GitLab so multiple people in your org can branch, commit, and play with configurations before testing.

Now, many Salesforce administrators don’t have an interest in learning to code, but you don’t have to be a developer to benefit from these practices. A declarative language like Salto’s NaCl provides the power of being able to scan, alter, deploy, and version-control a code base without you having to know Apex.

Test things in small batches

Get your mistakes out of your system (literally) in places they don’t matter, like in a code repository, and then verify that what you’ve created works with user acceptance testing (UAT). UAT isn’t a native feature of Salesforce, so you’ll need an additional tool (see below: Salesforce deployment tools).
‍
UAT sounds like a universal good. You should always ask users if they like what you’ve done, right? But it has tradeoffs. Users are generally not interested in participating in tests. They’re busy, and they quickly grow fatigued from giving feedback. That means you can either run black box tests (pick a cohort and don’t tell them it’s coming, which creates its own set of issues) or test sparingly.
‍

Don’t settle for a partial sandbox

For all its strengths, Salesforce leaves developers and admins in a bit of a bind when it comes to using sandboxes. You can either pay rather handsomely for full sandboxes, which completely replicate your environment, or you can settle for a variety of sandbox-light environments known as partial sandboxes.
‍
The issue with partial sandboxes is that they don’t mimic your production instance fully. They’ll capture all your metadata, but not all your data. This can make testing really hard in data-heavy environments or deployment of configuration data (like CPQ) really time-consuming.
‍

For you, cost may be a consideration. Not every organization can afford 30 full sandboxes—but the cost of not being able to actually test may be even greater. As Salto Co-Founder Rami Tamir has pointed out, Salesforce errors can have a tremendous impact—ranging from misfired emails that “burn” your marketing list, to missed revenue earnings because the finance team was blocked from sending invoices.
‍

Be able to easily revert to a prior configuration

Your Salesforce org doesn’t store prior states, which means Salesforce changes are naturally destructive. If you push a change set via the change set tool and something doesn’t work, there’s no native “undo” button. And if that change destroys metadata, it is overwritten and that data is gone.

This has very serious implications because it’s likely your Salesforce org doesn’t operate in a vacuum, and if a change passes into your finance system, it could mean that data is lost as well.
‍
Thus, at the very least, export a full image of your instance each week, and again right before each time you deploy to production. At the very best, use a tool like Salto to automatically store past states, and push them back to production so you can “undo” your change.
‍

Over-communicate with users

Users are busy, and if something unexpectedly changes that affects their ability to complete a task, they won’t be very understanding. You should always get out ahead of these scenarios and circumvent a flood of questions by offering recurring, predictable Salesforce change updates. People will rarely read them, but part of the goal is to train them to know where to look (in their inbox, on a wiki page) when they realize they have a problem.
‍
More communication is good for users—changes may impact their livelihood, as with a salesperson who’s suddenly unable to book a deal before month-end—and it’s good for you. Those twenty minutes spent writing the email will save hours of answering questions.
‍
To communicate with users:

• Publish recurring updates—And consider storing those notes in a place people can find them, like a folder or wiki.
• Use a templated message—That is, always use the sections in the same order. It makes emails easier to write, and makes it easier for readers to scan them. (Also, try using emojis instead of bullet points.)
• Have a formal system for submitting request tickets—A ticketing system will help you triage when an outage causes everyone to submit tickets all at once. It also helps with documentation, as it’ll provide the rationale behind changes. Documentation isn’t a native feature of Salesforce, so you’ll need to find a tool for this.
  ‍

Set automatic alerts for important changes

Despite your best efforts, some releases will invariably overwrite old customizations. Some of those customizations will be tremendously valuable to the individuals who made them. But nobody will know until that functionality doesn’t work, which can be days or weeks later.
‍

Part of the challenge is that Salesforce doesn’t allow you to automatically monitor changes to your org in any meaningful way. But a system like Salto does. Simply select a configuration or metadata that you’d like to be notified about, set an alert, and select either email or Slack.
‍
Specifically: Use Salto free to set alerts for changes to configurations you care about.
‍

Pre-deploy at non-critical hours

If you’re awake and working, likely, so are your users, which means deploying when you’re at your computer during work hours is not a best practice. That’s why Salesforce allows you to “Pre-deploy” changes. You can upload your change sets, but activate them once everyone is asleep.
‍
Pair this with change alerts from Salto in case something goes wrong, and then get some sleep. Because you have plenty of other Salesforce deployment challenges to deal with.
‍

Automate deployment

The best Salesforce deployment strategy is the one that works without you having to actually do much. Anything you can hand over to change
management or release software frees you up for more strategic tasks. Like, for example, investigating how your releases might conflict with other releases.

Salesforce doesn’t natively permit much in the way of automation. It has automatic checks when you upload change sets, but those are for basic code coverage. If you want to automate things, you’ll have to pull your configurations and metadata out of Salesforce and into an interface where you can apply developer-type tools. This is what Salto does.
‍
Salto extracts all your Salesforce configurations and metadata into an interface where you can explore it as one complete blueprint. For those who don’t code in Apex, it’s the power of a programming language but accessible to all. You can search, make changes, analyze impact, debug, and then push those changes back to Salesforce without slogging through the interface.

Salto plus a Git tool like GitHub or Bitbucket lets you:

• Explore your configuration
• Undo changes (quickly re-upload a past configuration)
• Understand dependencies
• Branch changes
• Save versions
• Understand what changes have been made (and why)
• Track usage for compliance
• Coordinate across regions
• Manage multiple environments
• Link changes to business tickets
• Reliably deploy changes to production

The VP of Growth at Torq used Salto to automate changes and found it reduced Salesforce deployment times by 75%. The time-savings has been so dramatic that at a stage where he says he would normally be thinking about his first hire, he’s managing it all just fine himself.
‍

How to deploy in Salesforce

So now that you have your Salesforce deployment strategy principles, how do you actually deploy changes? There are two native ways to deploy in Salesforce. At one time, there were three, but Salesforce is simplifying things. In addition, there is one non-native way to deploy—using Salto—which has the advantage of helping you conduct more rigorous release management.
‍
Native ways to deploy in Salesforce include:

#1. A change set: Simply upload metadata changes in relation to your production org. Use this feature to deploy workflow rules, Apex classes and triggers, visualforce pages, and minor customizations.

#2. The Metadata API: The Metadata API is available through SFDX and the old Force.com migration tool. It allows you to deploy changes to a Salesforce org from a local copy of the new or updated metadata.

However, Salesforce also recommends that you find added functionality through third-party tools that can help deploy Salesforce deployment change sets. That means using a tool like:

#3. However, Salesforce also recommends that you find added functionality through third-party tools that can help deploy Salesforce deployment change sets. That means using a tool like:

Git: GitHub, Bitbucket, etc. Git tools allow for versioning, branching, merging, and agreeing on changes. While this is possible using the XML representation of your metadata, Salto’s NaCI files provide a much more intuitive representation and this makes Git operations easier to automate.

Ticketing / workflow: Because Salesforce change logs often lack detail, it’s a good idea to use a ticketing tool like Jira or ServiceNow to document your rationale for Salesforce deployments. You can link those tickets to tracked changes in the system using Salto.

User acceptance testing: You might also want a tool like Provar Testing which allows you to test your deployments against fictitious users as an extra testing layer.
‍

Go slow to go fast with your Salesforce deployment strategy

No matter what level of maturity your organization is at, these top 10 best practices for Salesforce deployment can improve the quality of your releases. They ensure only authorized people make deployments, that those deployments are recorded, and that you can hit “undo” if something doesn’t work. And if you’re really serious about saving time and reducing error, you’ll want a tool like Salto.
‍
Salto provides you a blueprint of your configurations so everyone can see, agree, and deploy with greater confidence. And that way, even if you do deploy on the last day of the month and hear hollers from the sales floor, you’ll have a way to quickly debug the error.