Today our system can only read Salesforce. This is the plan to let a small group write to it too, with strong safety rails and a Python script that checks the work every hour, plus AI that steps in if needed.
In one sentence: let a few trusted people update purchase orders in Salesforce without handing anyone the keys to the whole system.
Right now our Salesforce connection can only look, not touch. We want to open up writing for a short, careful test. The thing we care about most: a person is never the one checking the work. An AI watches every change, records it, and can stop everything on its own if something looks wrong. Nothing should fall through the cracks because a human forgot to look.
Small on purpose. One shared connection, a couple of people, a narrow set of things they can change. If it works, we widen it later.
| Item | V1 decision |
|---|---|
| Can change | Purchase Orders and Purchase Order Lines (edit and create new ones) |
| Read only | Products (look, no changes in V1) |
| Never | Delete anything. "Removing" something is a status change, never a true delete. |
| The connection | One shared login (the existing read-only one), not one login per person yet |
| How we know who did it | A Google Sheet activity log records the real person's email on every single change |
| People in the test | Maryanne, Arvhiane, and Jason |
| Where we test first | The Salesforce sandbox, before any real data is touched |
Two kinds: rails that stop a bad change before it happens, and watchers that catch anything that slips through.
We keep two records, not one. Together they are stronger than either alone.
The script cross-checks the two. They should always match. If Salesforce shows a change that our Sheet does not, that is a red flag. Saving the old value before each change is what gives us a working undo, because Salesforce has no one-click restore.
A Python script that runs every hour during the workday and watches the work for us. The AI only steps in to act when something looks off.
The hourly run is plain code, so it costs nothing to run. It only calls the AI to think when it actually finds something odd. Each hour it reads our activity log and Salesforce's history, compares them, and then:
It runs on a machine that stays on all day. If that machine ever goes down, someone else can pick up the exact same program on another machine, because everything it needs lives in the shared Sheet, not on one computer.
We did not just plan this. The two pieces below are built, and we will continue to test them.
Still to build: the change tool itself (Jason and Anthony will build this), the undo button, the two-person approval step, and the manual freeze command. These are next on our list.
We built this off your write-access playbook and changed two things on purpose for this test. These are the parts we most want your read on.
Your playbook says always give each person their own login. For a quick test we are sharing one login and using the Google Sheet to record who did what. We can switch to one-per-person later (per-person is free up to the license ceiling below). Is the shared login plus a hardened activity log acceptable for a bounded test?
| License | Total | Used | Free | Cost beyond free |
|---|---|---|---|---|
| SF Integration (API only) | 5 | 1 | 4 | $10/mo per person |
| Salesforce full (UI + API) | 4 | 3 | 1 | ~$150+/mo per seat |
Per-person identity for V1 is free up to the 4 open Integration slots, then $10 per person per month. The full Salesforce seats are nearly maxed and far more expensive, so the API path is the cheap one.
Your playbook says let the change go through and just flag the missing log. We flipped it. On a shared login the Sheet is the only record of who did it, so if the Sheet is unreachable we block all changes until it is back. A change we cannot attribute is worse than a change that waits.
Two questions, plus any feedback before we build the rest.
Given the V1 scope and the guardrails above, are you good with us running this bounded test?
Anything in the safety set you would add, drop, or change for a system of record like Salesforce versus an ad platform like Meta? Especially the two deviations in section 07.
Anything wrong, missing, or worth changing before we keep building.