As enterprise Salesforce deployments grow in scope and complexity, managing them without a mature deployment, testing, and collaboration process becomes increasingly unsustainable. That pressure is pushing organisations to adopt DevOps practices — but doing so exposes a structural tension: the people who configure Salesforce day-to-day (admins) and the people who write code (developers) often work in separate silos with different tools, habits, and vocabulary.
Closing that gap is not just a technical problem. It is an organisational and cultural challenge that, when solved well, produces faster delivery, lower risk, and better collaboration across the entire Salesforce team.
Why Salesforce DevOps Has Become Unavoidable
Salesforce has deliberately lowered the barrier to building business solutions. Its declarative, point-and-click tooling means that business administrators — often called “no-code admins” — can iterate and ship new features without writing a single line of code. This speed is genuinely valuable, but it creates a problem at scale: changes made directly in a production org bypass the safety nets that mature engineering teams rely on.
DevOps provides those safety nets. At its core, DevOps is a set of practices, attitudes, and tools that govern how changes move from development through testing and into production. It reduces friction and waste by making that journey repeatable, auditable, and automated. Because Salesforce instances now underpin critical business operations — CRM, sales pipelines, customer service workflows — the consequences of uncontrolled change can range from data corruption to genuine downtime.
The result is that DevOps has become the operating model of choice for teams managing Salesforce at scale. Continuous integration pipelines, automated test suites, and version-controlled metadata are no longer exotic practices reserved for software engineering shops; they are becoming standard expectations for any serious Salesforce delivery team.
The Core Friction: Admins and Version Control
Most DevOps toolchains centre on version control — typically Git — as the single source of truth for all changes. Developers are already comfortable with this model. They commit code, open pull requests, run automated tests, and deploy through a pipeline. For them, this is routine.
Admins, by contrast, have historically worked directly in the Salesforce UI. They click, configure, and save — and their changes take effect immediately in whatever org they are working in. Salesforce does not provide a native mechanism for tracking these configuration changes in version control, which means that without deliberate process design, admin work exists outside the delivery pipeline entirely.
This creates real risks:
- Configuration changes made in production cannot be easily audited or rolled back.
- Developer and admin changes can conflict silently, with neither party aware until something breaks.
- Automated testing cannot protect admin-driven changes that were never committed to the pipeline.
Demystifying Code for Salesforce Admins
One barrier to admin participation in DevOps toolchains is psychological: code feels foreign and intimidating to people who have never needed it. Popular culture does not help — the archetype of the solitary, superhuman hacker makes programming seem like an exclusive skill that takes years to acquire.
The reality is more prosaic. Writing code is, fundamentally, writing — in a language with a stricter grammar than English, but one where the computer provides immediate feedback when you get the syntax wrong. That feedback loop is actually an advantage: you do not have to wait days or weeks to know whether you have made a mistake.
Experienced developers switching to a new language go through exactly the same learning curve that admins face. They work through “Hello World” examples, they copy and adapt snippets, and they make errors repeatedly before developing fluency. The difference is not innate ability — it is familiarity and confidence built through practice.
For admins, the practical goal is not to become a full-stack developer. It is to reach a baseline of code literacy sufficient to:
- Run command-line tools such as the Salesforce CLI to retrieve and deploy metadata.
- Commit changes to a Git repository and understand basic branch workflows.
- Read a pull request diff to understand what changed and why.
- Contribute to or review automated test specifications.
Even a small amount of hands-on experience with the command line tends to break the psychological barrier. Once an admin has successfully run a sf project retrieve start command and seen their org metadata appear as files in a repository, the abstraction becomes concrete and far less intimidating.
What Version Control Actually Gives Admins
Once an admin is comfortable tracking configuration changes in version control, the benefits are immediate and practical:
Full Change History
Every commit records what changed, when, and who made the change. This audit trail is invaluable when debugging a regression or demonstrating compliance. Without version control, answering “what changed in the last two weeks?” often requires manually comparing org snapshots or relying on the Salesforce Setup Audit Trail, which has limited depth and scope.
Rollback Capability
If a configuration change causes a problem, version control makes it straightforward to identify the offending commit and revert it — either by reverting in Git and redeploying, or by comparing the previous and current states of the metadata to understand what needs to change back.
Participation in the Delivery Pipeline
This is perhaps the most significant benefit. Once admin changes are tracked in version control alongside developer changes, a continuous integration (CI) engine can automatically deploy those changes to a scratch org or sandbox, run automated tests against them, and only promote them to production when the tests pass. Admins stop being a risk vector in the pipeline and become an equal contributor to it.
Shared Ownership of Automated Tests
A CI/CD pipeline for Salesforce typically runs Apex unit tests and, increasingly, UI-level tests using frameworks such as Selenium or UTAM. The value of those tests depends entirely on whether they cover the real behaviour of the org — including behaviour driven by admin configuration, not just developer code.
Admins are uniquely positioned to define what correct behaviour looks like for the features they own. When admins can articulate acceptance criteria — or better, contribute directly to writing or reviewing automated tests — they extend the protective coverage of the test suite to their own work. Those tests then guard against future regressions, regardless of whether the regression is introduced by a developer or another admin.
This is a meaningful shift in mindset: from “I made a change” to “I made a change that is now protected by an automated check that will catch any future breakage.” That shift turns testing from a developer concern into a shared team responsibility.
The Organisational Case for Unified DevOps
Keeping admins and developers in separate processes is not a neutral choice — it carries ongoing costs:
- Production risk: Changes made directly in production orgs are effectively uncontrolled experiments that put live data, users, and business operations at risk every time they are made.
- Duplicated effort: When admins and developers are not working from the same baseline, both parties may unknowingly make conflicting changes to the same metadata, requiring time-consuming reconciliation.
- Reduced velocity: Teams that cannot trust their deployment process move slowly and defensively. A shared, automated pipeline with good test coverage allows teams to ship more confidently and more often.
- Governance gaps: Without a shared pipeline, it is difficult to enforce change management controls or demonstrate an auditable process to stakeholders and compliance teams.
Bringing admins into the delivery pipeline is an investment in both technical resilience and cross-team collaboration. It gives admins a structural reason to communicate with developers about timing, dependencies, and testing. It gives developers visibility into configuration changes that would otherwise be invisible to them. And it gives the organisation a single, governed pathway through which all Salesforce changes — regardless of origin — must pass before reaching production.
Getting Started: Practical First Steps
Organisations looking to close the admin-developer gap in their Salesforce DevOps practice should consider the following starting points:
- Install the Salesforce CLI on admin workstations and walk admins through a basic retrieve-commit-deploy cycle in a sandbox environment.
- Establish a shared Git repository for all Salesforce metadata — both code and configuration — with a branching strategy that all team members understand.
- Set up a CI pipeline (using tools such as GitHub Actions, GitLab CI, or Jenkins) that runs automated Apex tests on every pull request.
- Run collaborative training sessions where developers explain the pipeline to admins and admins explain their configuration workflows to developers. Mutual understanding reduces friction on both sides.
- Treat automated test coverage as a shared metric. Make it visible to the whole team, and celebrate when admins contribute to improving it.
Conclusion
The separation between Salesforce admins and developers is a historical artefact of how the platform was originally positioned, not an inherent property of how it must be operated. As Salesforce environments grow in strategic importance, that separation becomes a liability. A unified DevOps practice — grounded in version control, automated testing, and a shared delivery pipeline — turns the admin-developer relationship from a potential conflict into a genuine force multiplier for the organisation.
The technical barriers are real but surmountable. The cultural and organisational investment required is modest compared to the risks of leaving them unaddressed.