Skip to content

Deployment governance

Deployment principles.

Moving configuration and code from sandbox to production is not simply a technical act — it is a governance event. The following principles form the basis of a mature deployment practice on the Salesforce platform.

Standardise. Define and apply a consistent deployment process across all changes, regardless of size. A hotfix and a major release should follow the same steps — only the urgency and approval path differ. Consistency reduces risk and makes the process auditable.

Consolidate. Where possible, group related changes into a single deployment rather than releasing many small, untested combinations. Fragmented deployments increase the risk of inter-dependency failures and make root cause analysis harder when something goes wrong.

Build momentum. Establish a regular release cadence — for example, aligned with Salesforce's own three-release-per-year schedule. Predictable releases reduce the pressure to rush changes and create a rhythm the business can plan around.

Anticipate. Every Salesforce release brings platform changes that can affect existing customisations. Review Salesforce release notes in advance, run regression tests in a sandbox pre-release org, and communicate upcoming impacts to the business before they materialise in production.

Drive efficiency. Automate what can be automated — change set creation, deployment validation, unit test execution and post-deployment smoke tests. Manual steps in a deployment pipeline are sources of both delay and error.

Group by maturity level. Not all Salesforce users and administrators operate at the same maturity level. Deployment procedures should reflect this — with lighter-touch processes for lower-risk, declarative changes and more rigorous controls applied to Apex code and integration changes.

Driving adoption.

A technically successful deployment that is not adopted by the business has no value. These principles support the people side of change:

  • Get an ambassador. Identify a business-side champion in each team who understands the change, believes in it and can translate it into the language of their colleagues.
  • Build a champions network. Ambassadors from multiple teams form a champions network — a multiplier for adoption that operates within the business rather than being driven by IT.
  • Don't over-customise. Every customisation adds to the training burden, the testing surface and the maintenance overhead. The most adoptable Salesforce orgs stay close to standard functionality and complement it deliberately.
  • Answer "what's in it for me?" Change management fails when communication is about the system rather than the benefit to the individual. Frame every deployment in terms of what becomes easier, faster or more visible for the end user.

Change authority.

Every organisation implementing Salesforce should define a clear change authority — the person or group with the mandate to approve changes before they are deployed to production. This does not need to be a formal Architecture Review Board for every change, but the principle of authorised approval must be consistently applied.

A MoSCoW analysis (Must have / Should have / Could have / Won't have) applied to the backlog of requested changes is an effective prioritisation tool that brings the change authority and the business into alignment before development resources are committed.