What Should an Automation Never Be Allowed to Do?

Should an automation have full access to your CRM?

Almost never. Most automations need to read two fields and write one, but they get connected with a credential that can read and write everything. That gap between what a workflow needs and what it is allowed to do is the single most expensive design mistake I see in marketing automation.

It is an easy mistake to make, because nothing goes wrong at first. You are building, you want it to work, and the fastest path is the widest permission. The bill arrives later, usually on a day when something else has already gone wrong and the automation is quietly making it worse.

I want to make the case for deciding what an automation is forbidden to do before you decide what it should do.

What is blast radius, and why does it matter more than uptime?

Blast radius is how much damage a workflow can cause when it behaves incorrectly. Uptime tells you whether an automation ran. Blast radius tells you what happens when it runs wrongly. The second question is the one that decides whether a bad afternoon becomes a bad quarter, and almost nobody asks it during the build.

Think about a simple lead router. The happy path takes a form submission and assigns an owner. Now imagine the input is malformed and the logic falls through to a default branch that updates every contact it can see. Uptime is perfect. The automation ran exactly as instructed. You now have a contact database with the wrong owner on thousands of records and no clean way to tell which ones were correct yesterday.

The reason I keep coming back to this framing is that it changes what you build. Once you ask what the worst realistic outcome is, you stop designing for the happy path and start putting walls around the unhappy one. Those walls are usually permissions, not code.

What does least privilege actually look like in a marketing stack?

It means every automation gets its own credential, scoped to the objects and actions it genuinely needs, and nothing more. A workflow that enriches contacts should not be able to delete deals. A reporting sync should be read only. The principle is old and boring, and it is still the highest leverage thing you can do.

HubSpot says this in its own documentation. When you create a service key you define the scopes, and HubSpot tells you to follow the principle of least privilege. That is the vendor telling you, in writing, that the default of connecting everything to everything is not the intended design. Most teams read past it because scopes are a checkbox screen that stands between them and a working integration.

In practice this takes one extra conversation at build time. What does this workflow read? What does it write? What does it never touch? Write those three answers down before you open the credential screen, and the scope selection becomes mechanical instead of a guess made under deadline.

How does HubSpot want you to connect an integration now?

With a service key for data-only work. HubSpot published guidance in May 2026 describing service keys as account-level API credentials built specifically for system-to-system, data-only integrations, and says they replaced legacy private apps for data-only workflows. OAuth remains required for apps distributed to multiple accounts, whether on the marketplace or to allowlisted accounts.

The reasons HubSpot gives are worth repeating, because they are exactly the properties you want when something breaks. Compared with legacy tokens, service keys offer rotation without disruption, audit logging, and account-level rather than user-tied ownership. Account-level ownership is the quiet one. A credential tied to a person leaves with that person, and I have seen more automations die from an employee offboarding than from any technical fault.

HubSpot frames the fit plainly. Service keys are for when you need stable, scoped API access to HubSpot data but you are not building an app, not distributing anything, and not setting up webhooks. A scheduled sync to a warehouse or a scheduled script is the example it gives. That describes most of what a marketing team actually runs.

Why should one automation never hold one key for everything?

Because a shared credential turns every incident into a choice between breaking one workflow and breaking all of them. If eight automations share a key and one starts misbehaving, revoking the key stops the damage and also stops your lead routing, your reporting and your onboarding email. Separate credentials let you switch off exactly one thing.

There is a hard limit worth knowing here. HubSpot's own documentation states you can create up to 20 private apps in a HubSpot account, so the one-credential-per-automation idea has a ceiling in that system. That is not a reason to give up on separation. It is a reason to spend those slots on the workflows with real blast radius rather than on every small convenience script.

My rule of thumb is to separate by consequence rather than by team. Anything that writes to customer records gets its own credential. Anything that only reads gets a shared read-only one. That usually collapses a sprawling list into a handful of credentials that I can reason about at three in the morning.

What should an automation be forbidden from doing without a human?

Deleting records, sending anything to a customer's inbox at volume, changing money, and writing to a field that another system treats as the source of truth. These four categories cause damage that is either irreversible or publicly visible, which is a different class of problem from a job that simply fails and retries.

Deletion is the obvious one and still the one I see automated most casually. A deduplication routine that merges records is deleting data with extra steps, and merges are rarely as reversible as people assume. If a workflow can delete, it should be proposing deletions to a human queue, a Slack message or an Airtable view somebody actually reads, rather than performing them.

The source of truth rule is subtler and catches people out. If your CRM owns lifecycle stage and your automation writes lifecycle stage from a Google Sheet, you now have two systems that both believe they are authoritative. The automation will win every sync, silently, and nobody will notice until a report looks wrong. Decide which system owns each field, and forbid the others from writing it. This is the same discipline behind guardrails on AI-driven automations, and it applies just as hard to plain deterministic ones.

How do you rotate a credential without breaking the workflow?

Create the new credential, point the integration at it, confirm it is working, then delete the old one. HubSpot describes exactly that sequence for service keys and says it keeps downtime to zero. The order matters. Revoking first and rebuilding after is how a routine security task turns into an outage.

For legacy private apps HubSpot's documentation recommends rotating your token every six months, and gives you two paths when you do. Rotate and expire now revokes immediately, or rotate and expire later triggers expiration of the old token in seven days. That seven day window is the thing to use. It gives you a period where both credentials work, which is when you find the one integration nobody remembered was using it.

Whatever platform you are on, write the rotation steps into the runbook while you build, not when you need them. A credential rotation is a scheduled, calm task if it is documented and a genuine emergency if it is not.

What does all of this cost you in convenience?

Real time, and I am not going to pretend otherwise. Scoped credentials mean more setup screens, more things to name, more places to look when something fails. The trade is that you exchange a small, predictable cost at build time for a much smaller chance of an unbounded cost later.

I run automations in production for client work, including an Airtable and WhaleSync pipeline for Ajust that has helped deliver more than 25,000 cases, and a HubSpot workflow for Kismet Health connected through Zapier. The stacks differ, and the platforms differ. Zapier, Make, n8n, an MCP server and a Claude Code agent all ask the same underlying question before they can do anything, which is what account you are connecting and what that connection may touch.

That is the moment the decision gets made, and it is usually made in three seconds by someone who wants to see the workflow run. Slowing that moment down is the cheapest risk reduction available to you. Everything after it, including a rollback plan for a workflow that writes to your CRM, is cleanup for a decision you could have made better at the start.

What should you do next?

Open the integrations screen on your CRM and list every connection along with what it can reach. Most teams find at least one credential nobody can account for and at least one workflow with far more access than its job requires. That inventory takes an afternoon and it is the honest starting point.

Then pick your highest blast radius workflow, usually whatever writes to customer records, and give it its own scoped credential with a documented rotation procedure. Do not try to fix everything at once. Fix the one that would hurt most, then the next one. If you are building lead routing specifically, the same thinking applies to how you route inbound leads to the right owner, where a wrong write is visible to your sales team within the hour.

None of this is exciting work and none of it shows up in a demo. It is the difference between an automation you trust and one you are quietly afraid of. If you are staring at a stack you inherited and cannot tell what has access to what, reach out and I will help you map it.