How AI is changing our Salesforce operations
Claude ships PRs while I watch
We had a problem.
Our Salesforce org is mature, clean, and high-functioning, thanks to years of careful work. But staying clean came at a cost: keeping the keys tightly controlled.
Every task waited on a short list of people who were allowed to ship. We paid for hygiene with velocity.
This year we asked a different question. How do we keep the intentionality while letting more people ship autonomously?
Here’s what we built.
Two AI layers
The system has two distinct layers: qualification and build.
Layer one: qualifying what to build
Before anything gets built, it goes through SFOps Buddy. This is a Dust agent that acts as the first-line intake for all Salesforce requests.
The goals of this agent are:
Own the initial qualification of a task. This increases speed and frees bandwidth for our Salesforce PM.
Prevent unnecessary work. Deflect tasks that are redundant or low-impact.
Maintain architectural discipline. Write a clean spec with awareness of our existing org structure.
Here’s what Buddy does.
Check existing work and knowledge
Checks Trello for duplicate or in-progress work
Searches our Salesforce GitHub repository to see if the field, object, or automation already exists.
Searches our Confluence knowledge base for documented workarounds.
Only after that sweep does it ask the requestor anything.
Qualify using RICE
Next, Buddy asks questions to qualify the request using the RICE framework:
Reach
Impact
Confidence
Effort
This puts scrutiny on what to build before anyone spends time building it. It looks at things like how many users or records are affected, whether the request aligns with an OKR, the estimated time or cost saved, and so on.
Once it’s satisfied, Buddy updates the Trello card with a clean spec, including the OKR alignment, the RICE scores, a summary of what it checked and what it found, and moves the card to the execution queue.
This is the hygiene gate. Everything architectural gets decided here, before a single line of code is written.
Layer two: knowing how to build it
Once a card is ready, an operator will paste it into a new Claude Code session to begin execution. Most builders will work in the Claude Desktop app without needing to read files or open an IDE.
Claude can read the spec from Trello, but it doesn’t just have the ticket context. It has a runbook, a detailed set of rules covering how we deploy, how we branch, how we commit, and how we handle every common class of change.
This runbook is encoded in a set of rules files, which are referenced via pointer in CLAUDE.MD and loaded in every new session.
A few examples of what’s in there:
Branching process. Every feature branch is cut from
main, namedfeature/SFO-{cardID}-{description}, and commits follow a consistent format.Preferred architectural approaches. For example, it knows we default to Apex over Flow in most scenarios now, as it’s much easier for LLMs to work with. And it has detailed conventions and templates for writing Apex that aligns with our standards.
Standard rules for field-level security. What profile categories get access by default, when to be conservative.
PR format. What to include in the body and whether to self-merge or wait for review.
When Claude opens a PR, it’s following a documented process that we designed and that Claude now executes consistently.
The release path
CI does a lot of heavy lifting here.
We use delta deploys via GitHub Actions so only the changed metadata hits the org. That keeps deployments fast and scoped. But the more important thing is the safety layer on top of it.
Before any PR merges, CI checks that the branch files match what’s actually in the target org. If someone manually changed something in Salesforce Setup that wasn’t retrieved, CI flags it before the deploy can overwrite it. If a PR touches metadata that lives in production but isn’t in the branch, we know about it before anything ships.
“Safe Zone” Tickets
“Safe Zone” tickets are simple enough to go directly to production without an architect review. These include custom fields, additive picklist values, layouts, permission set FLS, Lightning pages.
These tickets can self-merge once CI checks pass.
This increase in velocity is one of the biggest wins for our whole team. People are often working on projects (e.g., integrating a new platform, a new automation) that depend on adding Salesforce fields. It’s disruptive to have your project blocked while you wait a few days for someone to deploy a field. Now it can be done in real time.
Complex Tickets
All other changes go through a more complex UAT process.
CI validates
Architect reviews before merging to our UAT sandbox
Builder completes UAT testing
Separate production PR.
What it looks like in practice
Last week, my colleague and I watched Claude write Apex and open a PR for a ticket that would have sat in the queue for weeks waiting for developer time.
We had identified a need as part of another project. We used Buddy to create the Trello request, both as good hygiene practice and because it would write a clean spec for us.
My colleague opened Claude Code, dropped in the ticket, and let the runbook drive.
Claude read the Apex standards, asked a few clarifying questions about the expected behavior, wrote the class and the test coverage, and opened a PR with the correct format, title, and body.
It went to our architect for review, and we were clear to merge.
What was needed to build this
This system itself is not terribly complicated, but it required several months of iteration and testing to become smooth and reliable.
We also benefited from having the following foundational pieces in place (or at least having the necessary ingredients for them already on hand):
A mature team. Both our Salesforce PM and developer/architect have been with the company for 5+ years and had built our existing system from the ground up. They had hardened the process manually, which is a pre-requisite for automation.
Clean documentation. Our org is well documented on Confluence and GitHub, including automations and fields. This enables an agent to easily identify the business context surrounding existing configuration and make more intelligent decisions. This documentation represents years of persistent work and discipline.
CI/CD process. This would be much harder if we were deploying changes manually from org to org. GitHub provides the rails for Claude to run the process.
An opinionated runbook. Our architect, Bastien, spent many hours refining the rules so that Claude executes precisely and reliably. These rules are themselves a business asset that takes time to develop.
It’s also fascinating to consider how fast things are moving right now.
When we first discussed the idea as a team in January, it seemed ambitious and perhaps too bleeding edge. Now it seems much more inevitable.
The advances in coding agents over the past several months have been a big part of making it reliable.
Everything described above is thanks to our amazing Salesforce team: Bastien and Denis!