How do you decide what an automation should never touch?

How do you decide what an automation should never be allowed to touch?

Work out the blast radius before you work out the feature. For every piece of data the automation could reach, ask whether a human would notice the change, whether it can be undone, and who gets hurt if it goes wrong at three in the morning. Anything that fails all three is off limits.

Most people build the automation first and think about permissions afterwards, usually when something has already gone wrong. The order matters because permissions granted during a build are almost never taken back. They just sit there being available.

This is the decision layer rather than the list. I have written elsewhere about which CRM fields an automation should never write, and this is how I decide what belongs on a list like that in the first place.

Why is a written rule not enough on its own?

Because a rule in a document is a suggestion to your future self, and your future self will be in a hurry. A rule enforced by the credential is a rule that holds even when the person maintaining the automation has forgotten the rule existed, which will happen.

The gap between policy and enforcement is where incidents live. Everyone agrees the automation should not delete records. Nobody removes delete access, because removing it is fiddly and nobody plans to delete anything. Then a filter behaves unexpectedly and the capability that should not have existed gets used.

So my test for any rule is whether it survives my absence. If the only thing preventing a bad write is that I remember not to, it is not a control. It is a habit, and habits do not transfer when someone else takes over an automation after the builder leaves.

What does least privilege mean for an automation?

Granting the narrowest access that lets the job succeed, and nothing held in reserve for convenience. HubSpot's own developer guidance puts it plainly: follow the principle of least privilege, and only include scopes for features you are actually interacting with.

The same guidance makes the incremental case, which is the part people miss. It notes you can always add scopes over time as your usage or functionality expands. So the cost of starting narrow is one configuration change later, while the cost of starting broad is a capability nobody audits for years.

HubSpot describes a scope as providing access to a specific set of API endpoints and the associated data from an account. That framing is useful even outside HubSpot, because it reminds you that a permission is not abstract. It is a specific door into specific data, and you are deciding which doors to leave unlocked.

Which three questions draw the line?

Can a human tell this changed? Can it be reversed without a backup? And who is affected if it runs a thousand times by mistake? I ask those three of every write an automation performs, and the answers sort the work into safe, careful and forbidden.

The first question is about detectability. A status field flipping is visible. A tag quietly removed from four hundred contacts is not, and invisible changes are worse than loud failures because they compound before anyone investigates.

The third question is the one that changes people's minds. A workflow writing to an internal field affects your team. A workflow writing to something that triggers an email affects your customers, and a mistake there is not an internal cleanup, it is an apology to people outside the company.

Why should deletion almost always be off the table?

Because it is the one action that removes your ability to recover from the mistake. Every other bad write leaves evidence you can inspect and reverse. A delete leaves an absence, and you cannot audit an absence or restore from one.

The safe substitute is nearly always available and nearly always sufficient. Archive it, flag it, move it to a different view, set a status. Automations can mark things for deletion all day long; a human, or a separate deliberate process, does the deleting. The separation costs almost nothing.

I hold this line even when a client finds it excessive, because the asymmetry is so stark. The upside of automated deletion is a tidier database. The downside is a phone call about data that is gone. I have never regretted keeping something a machine wanted to remove.

What about the fields humans treat as their own?

Leave them alone entirely, even when you technically could write to them. Notes, owner assignments, deal stages and anything a person has manually set are territory. An automation overwriting a human's deliberate choice destroys trust in the automation faster than any outage.

This is a social constraint rather than a technical one, and it is the one engineers most often dismiss. When a salesperson finds that a machine has changed a deal stage they set on purpose, they stop trusting every field in the system. You have not broken data, you have broken adoption.

The workable compromise is one-way. An automation can write to a field nobody edits by hand, and read from the fields people do. If a value genuinely needs to flow both ways, put the automation's version in its own field and let a person reconcile them. Two fields is cheaper than an argument.

How do you handle an automation that needs broad access for one rare job?

Split it. The monthly job that needs wide reach gets its own credential and its own automation, separate from the hourly job that only needs to write one field. Bundling them means the frequent automation carries permissions it never uses.

That is my own practice rather than a vendor instruction, and I recommend it because of how failures actually unfold. When something misbehaves, the question is always what it could have reached. If the answer is scoped tightly per job, the investigation takes minutes. If everything shares one broad credential, the answer is everything.

There is a maintenance cost to this and I will not pretend otherwise. More credentials means more things to rotate and document. I accept that cost because the alternative concentrates risk in the automation that runs most often, which is exactly the wrong place to put it.

How do you review this later without starting over?

Write down, next to each automation, what it is allowed to touch and why. One line per permission, in plain language. Then the review is reading that list against the automation's current job, which takes ten minutes rather than an afternoon of reverse engineering.

What makes permissions drift is scope creep in the work itself. The automation that started by routing leads now also updates a field and posts to a channel, and each addition arrived with a small permission increase nobody logged. The list is how you notice.

Schedule it against something you already do. I revisit permissions whenever an automation changes behaviour, not on a calendar, because a calendar review of something that has not changed is theatre. If you are changing it anyway, you are already in there, and that is the cheapest moment to also plan how to roll the change back safely.

What should you do next?

Open your most important automation and list everything its credential can reach, not everything it uses. The gap between those two lists is your exposure, and for most automations I inherit the gap is large enough to be uncomfortable once it is written down.

Then remove one thing from it today. Not all of it, because that turns into a project you will abandon. Remove delete access, or revoke the one permission you know is unused, and confirm the automation still runs. One narrowing is worth more than a plan for ten.

The automations I run for Ajust on Airtable with WhaleSync have delivered 25,000+ cases and helped 400,000+ people, saving 50,000+ hours, and for Kismet Health I run HubSpot work through Zapier. At that volume the permissions decision is not paperwork, it is the difference between a small incident and a large one. If you are about to hand an automation write access to your CRM, reach out and let's scope it before you switch it on.