Environments with clear purposes
Use separate environments for building, testing, and production, each with a defined role. Developers or administrators build changes in a development environment, a test or staging environment is used to verify them with realistic data, and only approved changes reach production. Keep the environments reasonably similar, since a change that works in a bare development org may fail in a production org with years of configuration.
- A development area for building and experimenting.
- A test area that mirrors production for verification and user acceptance.
- A rule that production is changed only through the release process.
Version control as the source of truth
Store your configuration and code in a version control system. It records what changed, who changed it, and when, and lets you compare versions or revert. Even teams working mainly with declarative tools benefit, because metadata can be exported and tracked. The discipline of committing changes with a clear description also forces the question: why are we making this change?
Deployment pipelines and automation
A pipeline moves changes through environments in a consistent way: validate, test, approve, deploy. Automating the repetitive steps reduces mistakes and frees people for reviewing. Tools range from command-line utilities to dedicated release platforms, and the right choice depends on your team's size and skill. Whatever you pick, make deployments repeatable and make each one traceable to an approved request.
Implementation and integration services →Testing: automated, manual and user acceptance
Custom code requires automated tests, and Salesforce enforces minimum coverage for deployment, but coverage numbers do not guarantee quality. Write tests that verify behavior, including edge cases. Declarative changes such as flows also need testing, which is often done with a checklist of scenarios. Before major changes reach production, have business users confirm the result in the test environment. Keep a small regression suite of critical processes and run it before each release.
Seasonal platform releases
Salesforce updates its platform several times a year, and some changes affect existing configuration or require action by customers. Use the preview window to review release notes, test your critical processes, and fix issues before the update reaches production. Plan communication to users about visible changes. Treat this as a recurring calendar item, not an occasional scramble.
Managed and advisory services →Decisions to settle before you start
- Environment strategy. Define how many environments you need and what each is for.
- Approval path. Decide who approves changes and how emergencies are handled.
- Tooling. Choose version control and deployment tools that your team can actually operate.
- Release calendar. Set a regular rhythm for releases so users know when to expect change.
A realistic first 90 days
- Days 1 to 30. Document current environments, export metadata into version control, and stop direct changes in production except through an agreed exception.
- Days 31 to 60. Set up the test environment, a basic pipeline, and the request and approval step.
- Days 61 to 90. Run the first full release through the process, build the regression checklist, and review lessons learned.
Pitfalls to avoid
- Making changes in production for speed. It feels faster until a mistake takes hours to unwind.
- Overbuilding the process. A heavy process that people bypass is worse than a light one they follow.
- Tests that only chase coverage. Assert real behavior, not just that lines execute.
- Ignoring platform releases. Check the preview each time, or discover issues when users do.
