Skip to main content
Workflow governance is the set of naming, ownership, access, and review practices that keep production Attio workflows safe to operate. A workflow that fires on a real trigger and writes to real records is infrastructure, not a convenience macro. So it earns the same discipline you give a deploy pipeline: a predictable name, a named owner, the least access that still works, and a recurring review. The cost of skipping governance is paid later and quietly. An unnamed workflow that nobody owns keeps spending credits after the person who built it leaves. A paused run sits unnoticed for a month. A wiring mistake on a broadly permissioned workflow corrupts records at automation speed. None of these surface in the builder. They surface in the run history and the credit bill. This page gives you a working convention for each governance surface. After reading it you can name a new workflow so a teammate understands it at a glance. You can write a description that still makes sense after the author leaves the company. You can set access so only maintainers can touch live automations. And you can run a review on a fixed schedule that catches small problems before they become an incident.

​
Naming workflows predictably

A workflow name states its subject, its trigger, and its outcome. Anyone scanning the workflow list then reads intent without opening anything. Use a single fixed pattern and apply it to every workflow in the workspace:
Each segment maps to a real part of the workflow. The first names the object or list the workflow watches. The second names the trigger that starts a run. The third names what the run produces.
Take a reader who has never opened Deals - Stage won -> Slack alert. They already know it watches the Deals object, fires when a deal reaches a won stage, and posts to Slack. That is enough to decide whether it is the workflow they are looking for.

​
Documenting owner and intent

The description carries the operating facts the name has no room for. It is the first thing a future maintainer reads when a workflow misbehaves. Treat it as the workflow’s runbook entry rather than a label, and include every field in this set: A complete description for the deal-alert workflow reads: owner Priya Sharma; purpose notify the deal team the moment a deal is won; trigger deal stage changes to Won; ~120 runs per month; one Slack message per run through a third-party block, no credit-bearing AI blocks; rollback set the workflow to Off and re-publish. That single paragraph lets a teammate who has never seen the workflow disable it correctly during an incident, even if Priya is on holiday.

​
Granting the least access that works

Three separate permission systems sit behind every workflow. Governance means setting each to the minimum that still lets the workflow run. The detail lives in Permissions & workflow access. The governance rule is short. Set workspace access to the lowest level anyone should have, usually Read only. Then grant Read and write or Full access upward to the specific people who maintain automations. This matters because of one non-obvious rule. More specific settings can only grant additional access, never reduce it. So an individual “No access” assignment does nothing if the workspace default is already Full.
With this configuration, only the two named maintainers can edit or publish a live revenue automation. A new hire who joins the workspace can study workflows without being able to break one. Anyone with edit rights can change a live automation. So treat workflow edit access like production deploy rights, because that is what it is.
A workflow has no write access to objects by default and only gains it when an admin grants it deliberately, object by object. Grant write to one object at a time rather than broadly. A workflow with wide write access plus a wiring mistake can damage records at automation speed.

​
Reviewing weekly, then monthly

A governance review is a recurring read of the run history that catches drift before it becomes an incident. It runs on a fixed cadence rather than only after something breaks. I check this weekly for the first month after a workflow launches, then settle into a lighter monthly pass once it is stable. The first-month weekly review looks for problems that show up early and cheaply:
  • Failed runs, traced in the workflow’s run history to the first block that produced a wrong value.
  • Credit usage, compared against the expected per-run cost recorded in the description.
  • Duplicate records or tasks, the classic sign of a self-triggering workflow or a missing dedupe guard.
  • Actual run volume against the expected monthly volume in the description.
Once a workflow is stable, the monthly review shifts to slower forms of drift. This is the kind that accumulates while nothing appears to be wrong:
  • The named owner is still at the company and still owns it.
  • Every attribute the workflow reads or writes still exists and still has the expected type.
  • Downstream app credentials, such as a connected Slack workspace, are still authorized.
  • No run has been left paused and forgotten.
Run this pass on the deal-alert workflow and it might surface that a stage attribute was renamed last week. The trigger now matches nothing. That is a silent failure the run count exposes immediately, because the expected ~120 runs dropped to zero.
Credit usage is one of the most important review signals. The full per-block cost table and plan allowances live in one place: Credits & pricing explained. Baseline each workflow’s expected spend against that page rather than guessing.

​
See also

Sources: Overview of workflows, Manage access to objects, and Manage workspace and seat credits (Attio Help Center). Last reviewed against the Attio Help Center, June 2026.