> ## Documentation Index > Fetch the complete documentation index at: https://80x.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Workflow governance > Workflow governance is the set of naming, ownership, access, and review practices that keep production Attio workflows safe to operate. 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: ```text theme={null} [Object/List] - [Trigger] -> [Outcome] ``` Each segment maps to a real part of the workflow. The first names the [object or list](/explanation/records-vs-list-entries) the workflow watches. The second names the [trigger](/explanation/triggers) that starts a run. The third names what the run produces. ```text theme={null} Deals - Stage won -> Slack alert Inbound list - New entry -> Route owner Companies - Domain added -> Enrichment ``` 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: | Field | Why it belongs there | | - | - | | Owner | The person accountable when the workflow fails or overspends. | | Business purpose | The outcome the workflow exists to produce, in plain go-to-market (GTM) terms. | | Trigger | The exact event that starts a run, so volume is predictable. | | Expected monthly volume | The run count you expect, to baseline the review. | | Credit model | Which blocks spend credits and roughly how much per run. | | Rollback instruction | The first action to take to stop or reverse the workflow. | 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](/reference/integrations), 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](/explanation/permissions-and-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. ```text theme={null} Workspace default: Read only Maintainers (Priya Sharma, Jane Cooper): Full access Everyone else: inherits Read only ``` 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](/explanation/runs-and-debugging) 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](/reference/credits-and-pricing). Baseline each workflow's expected spend against that page rather than guessing. ## See also * [Permissions & workflow access](/explanation/permissions-and-access) * [Runs, debugging & publishing](/explanation/runs-and-debugging) * [Production runbook](/troubleshooting/runbook) * [Credits & pricing explained](/reference/credits-and-pricing) * [Overview of workflows](https://attio.com/help/reference/automations/workflows/overview-of-workflows) *** *Sources: [Overview of workflows](https://attio.com/help/reference/automations/workflows/overview-of-workflows), [Manage access to objects](https://attio.com/help/reference/managing-your-data/objects/manage-access-to-objects), and [Manage workspace and seat credits](https://attio.com/help/reference/workspace-settings-billing/manage-workspace-and-seat-credits) (Attio Help Center). Last reviewed against the Attio Help Center, June 2026.* This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.