In our previous articles in this section, we've defined what metadata is, the users that work with it, and why they may want to be making changes to it. This article explains why users run deployments and the challenges they pose.

Imagine a company only had one Salesforce instance: their production org which powers their team of 2,000 employees around the world. 

One of their administrators decides they need to make a small change to improve the workflow for their sales and support teams - tweaking the permissions, so the teams can access a new field they just added to track customer sentiment. It looks fairly innocuous, so they go ahead and make the change in the org and head home.

In a best-case scenario, all goes well, and the teams begin tracking this new metric. But what would happen if the administrator accidentally misclicked and made it so that the teams can now only access that field and no others? 

Suddenly the sales team can't sell - they can't access any user records. The support team can't get into customer accounts to see what's wrong or begin debugging the issues. Panic ensues. Customers complain, and the business loses money. 

This is a slightly contrived situation, but it demonstrates the issues of working directly in the live environment. Surely there's a better way?

It's for the reasons outlined above that the vast majority of companies using Salesforce maintain multiple environments and don't make changes directly in production. The risk of disrupting business as usual is too high, and there is no way to spot and resolve human error before it's too late. There are some platform limitations which limit what users can do directly in production. For example, new Apex code can't be written directly in a production org.

Sandboxes and development environments provide companies with a safe, isolated space for building and testing features before they get released into production. Each extra org provides another degree of separation and hence a chance to catch and fix bugs before they go live. As a result, most companies will have a range of sandboxes and developer orgs used throughout their development process.

While this approach has a huge range of benefits, maintaining multiple environments introduces some new challenges. Primarily, changes must now be propagated between orgs in a controlled and reliable manner.

Once each piece of work has been completed and tested in the development environments, it needs to be moved down the org pipeline and into production instance so that end users can begin making use of it. In Salesforce, this process is called a deployment.

Deployments are the riskiest points in any software development project. They represent the moment of truth for development teams, as new features are pushed live for the first time, and there are many ways in which they can go wrong. 

Surprisingly, although so many things about Salesforce are simple, deployments stand out as one area that is particularly tricky. The root cause of this is the inherent complexity of metadata and the requirement to maintain its relationships as changes propagate between different environments. There's no point moving across your new button on the Lead object if it gets mangled in translation and ends up as part of the Case object instead.
​
Salesforce orgs can be extremely intricate, with huge numbers of objects and dependencies between them, with the result that it’s all too easy to make an error during the deployment process. Forgetting to deploy just one object can potentially cause a deployment to fail.

Luckily, there are several tools that Salesforce developers and admins can use to help them deploy changes between their orgs in a quick and efficient manner.

Check out our articles on Salesforce release management, and our white papers here.