Right now we can only read from Salesforce. We want to let a few people change things too, without anyone breaking something by accident. Here is the plan and every safety check, in plain words.
From Anthony + Claude · 2026-05-30 · Deeper detail in the PDF below
Today our Salesforce connection can only look, not touch. We want to let a small group make changes to Purchase Orders and Products. We are copying Brian's setup that already works for Meta, adding our own safety checks, and putting an AI in charge of watching everything so no person has to babysit it.
2The plan: a small test first
One shared login
We use the connection we already have, shared by 4 to 5 people, instead of making a separate one for each person. It is a test. If it works well, we can give people their own logins later.
What they can change
Purchase Orders, the lines on those orders, and Products. They can edit and add. They can never delete anything.
Practice before real
We try everything in a practice copy of Salesforce first, so nothing real gets touched until we know it works.
3If everyone shares one login, how do we know who did what?
This is the main risk, and here is the fix.
On its own, Salesforce only sees the shared login, not the person behind it. So we keep our own logbook: a simple spreadsheet. Every time someone makes a change, their Claude writes a line in it: their name, the time, what changed, the old value, and the new value. Jason's change says Jason. Maryanne's change says Maryanne.
The trick that makes the logbook trustworthyThe only way to make a change is through one shared tool, and that tool always writes the logbook. Nobody keeps a copy of the login on their own laptop. So there is no way to make a change that skips the log. As a backup, Salesforce also keeps its own basic record of changes, so our AI can compare the two. If Salesforce shows a change that is missing from our logbook, that is a red flag and we get alerted right away.
4The safety checks
Two jobs: stop a bad change before it happens, and catch one fast if it slips through.
Stop a bad change before it happens
One door. Everyone goes through the same single tool. No personal copies of the login floating around.
Show before you do. Every change shows exactly what it will do first. Nothing happens until the person says yes.
Sanity check on numbers. If a number looks crazy (a price goes negative or jumps way up), the tool refuses it.
A limit per person. Each person can only make so many changes an hour. If someone's Claude goes haywire, it gets stopped fast instead of changing hundreds of things.
Only the fields we agreed on. The tool will not let anyone touch anything outside the short list we approved.
Two people for the risky stuff. Big dollar changes, brand-new records, or anything that touches Products needs a second person to say yes first.
Double-check after. Right after a change, the tool re-reads it to make sure it actually did the right thing.
Catch and fix it after
The logbook. Every change is saved: who, when, what, the old value, the new value.
An undo button. Because we save the old value, we can always put it back. The logbook is also our rewind.
An AI checker every 2 hours. It reads the logbook, compares it against Salesforce's own record, and flags anything off. If it sees something serious, it does not just warn us. It shuts off everyone's ability to make changes until we look.
An emergency stop. Anyone on the team can freeze all changes instantly if something looks wrong.
5If someone makes a mistake, can we undo it?
Salesforce is not like Google Docs, so there is no one-click "go back to yesterday." But because our logbook saves the old value before every change, we can always put it back ourselves. We get the same safety, we just build it. One thing to know: undoing a Product change also re-updates the website stock, which is exactly what we would want.
6Who checks all the changes? Not a person.
If five people make changes in one day, no human should have to check them all. An AI reads the logbook every 2 hours (we can make it more often). It looks for anything off: a change that is too big, someone changing something they should not, or a change with no logbook entry. If it finds something serious, it hits the brakes on its own and tells us, so a mistake gets caught in hours, not days.
Honest noteThe AI checker catches problems after a change, on its next run. The "stop before" checks above are what actually prevent a bad change. Both together is the point.
7What we will ask Brian next
For context. We send this to Brian once you are happy with it.
For Brian, question 1: Build the fancier tool now, or start with simple scripts and add the safety checks on top? (Our lean: start simple, upgrade after testing.)
For Brian, question 2: Is he okay with the one shortcut we are taking for the test (sharing one login, and trusting our logbook to track who did what), or does he want each person on their own login from day one?
8Jason, your review
Does this match how it really works on the Salesforce side? Anything wrong, missing, or worth changing before Brian sees it?
Your review
Tell us: is anything here not true on the Salesforce side, is any safety check missing, and are you 100% good to send this to Brian?