Developer experience · start here

The developer story, in plain English

The job being automated

When a big sales deal is won, somebody has to remember to chase the renewal a year later. People forget, and the company loses revenue it had already earned once. So the team automates it: when a deal over $50,000 closes, set up next year's renewal, give the salesperson a follow-up task, and tell them it exists. This is the story of the developer who builds that — and, just as importantly, of what happens months later when it breaks. His name is Devin. He writes code for a living, but almost nothing here requires you to.

Two tracks, one automation

Building it

Seven steps, from an idea to something running against real deals. Folder: headless journey

1
Describe what you want
He types the requirement in ordinary English and gets a working first draft back. No diagram to draw.
2
Change your mind, easily
The rule shifts from six months to a year. Three ways to make that edit — code, plain language, or the visual map — all equally real.
3
Drop into code where needed
Working out what a renewal is worth needs a genuine calculation, so he writes a small piece of custom code and the automation calls it.
4
Try it somewhere safe
He tests on a copy of the system with no real customers in it. One test fails, and the error is a sentence rather than a code.
5
A second pair of eyes
A colleague reviews exactly what changed, automated checks run, and only then does it ship — switched off, until a human turns it on.
6
Living with it
It's live. Alerts arrive in the team chat with an explanation and a suggested fix, not just an alarm.
7
When you need to see it
A year on, six steps have become thirty-four. Branching is a shape, and no list can show a shape — so he opens the visual canvas to read it.

When it breaks

The same automation, months later, on a bad day. Folder: troubleshooting journey

1
Something breaks
Someone switches off a price list for an unrelated reason and 18 renewals quietly fail. The system notices before any human does.
2
Where did it go wrong?
The failure is drawn on a map of the automation — and the real culprit one step earlier is flagged, because what fails is rarely what's wrong.
3
Make it happen again, safely
You can't experiment on real customers, so the assistant rebuilds the exact failure in the safe copy. The bug is now on a workbench.
4
Fix it, and prove it
He steps through the failure line by line, sees the precise moment it goes wrong, and fixes it against the real problem rather than a guess.
5
Make sure it can't recur
The fix ships and leaves a tripwire behind. Switch that price list off again and the system catches it before release.

The words you'll see on the mockups

Flow
Salesforce's tool for building automations without writing code — “when this happens, do these things,” assembled from ready-made steps.
Apex
Salesforce's programming language. Used for the parts a ready-made step can't do, like a real calculation.
Sandbox
A complete working copy of the company's Salesforce with no real customers in it. Where you try things before they count.
Deploy
Moving a finished change out of the workshop and into the live system that real people use.
Pull request (PR)
How developers propose a change: here is exactly what I altered, please review it before it ships.
Agent & MCP
The AI assistant, and the connection that lets it actually read and change Salesforce rather than only talk about it.
Telemetry
The automatic record of what ran, what worked and what failed. The system's own account of itself.
Intent Map
A plain-language, step-by-step view of what an automation does. Editable — and always the same automation underneath.
HINT
Our name for an error written for a human: what broke, why, who's affected, and a fix you can act on.