enterprise add-on
Rules and Workflows give your team structured control over how content moves from idea to publish. Use them together to integrate review, approval, and editorial standards across your Space, or use either one on its own to solve a narrower problem.
- Workflows define the creation process, the stages a piece of content moves through, and the people responsible for each step.
- Rules define who can do what, the approval requirements, and the content criteria that must be satisfied before content moves forward or is published.
- Find Rules and Workflows in Settings → Content Governance tab → Workflows or Rules
- Required entitlement:
governanceorcustomRoles - Webhook events:
stageMoved,requestPublish,requestStageMove - Scope options for stage permissions: everyone, no one, only selected users or role
Rules apply at publish, and you can use them without a Workflow. A Workflow without Rules acts as a lightweight progress tracker with permission control per stage.
| Goal | Use |
|---|---|
Require an editor or legal reviewer to approve before publish | Rule |
Restrict who can publish in a specific locale | Rule |
Require a translation review only when French content is touched | Rule with an advanced query |
Track content through Draft → Review → Approved → Published states | Workflow |
Lock editing of a page to copywriters during the Review stage | Workflow with stage editors |
Require legal approval before a page can leave the Legal Review stage | Workflow + Rule combined on the stage |
Notify an external system such as Slack, Jira, or a custom tool when a stage moves | Workflow with a webhook |
A Rule is a reusable approval requirement defined by four properties:
- Scope: specific models, specific locales, or everything.
- Approvers: a list of users or roles.
- Trigger: every time content matches the scope, or only when an advanced query matches.
- Status: disabled rules are stored but never evaluated.
- Go to Account Settings → Content Governance.
- Click Rules in the left sidebar.
- Click + New Rule in the top right.
- Fill out the Create Rule dialogue.
- Click Create.
A confirmation notification appears: "Rule saved!" The new rule appears in the Rules list with an ACTIVE or DISABLED badge on the right.
| Field | What it does |
|---|---|
Rule name (required) | Short label. Shown to approvers and editors when the rule triggers. Placeholder: French content rule. |
Description (required) | One- or two-sentence explanation. Shown next to the rule name in the editor's review panel. Placeholder: This rule ensures French language content is reviewed by an authorized user. |
Users/roles who can approve the rule action(s) | Multi-select of users and roles in your organization. Anyone in this list can grant approval when the rule triggers. By default, the creator of the rule is added. |
Locales | Multi-select of configured locales (plus Default). Leave empty to evaluate the rule across all locales. When set, the rule only triggers if matching localized fields are present in the entry. |
Apply Rule to all models (toggle) | On by default. Off reveals a Models picker so you can scope the rule to specific content models (pages, sections, data models). |
Enable this rule (toggle) | On by default. Toggle off to retain the rule's configuration without it triggering. |
Advanced Query (under Show Advanced) | A MongoDB-style query that filters which content fields trigger the rule. Optional. |
Click any row in the Rules list to open it. The dialogue header becomes Edit Rule, and three buttons are available:
- Delete Rule: bottom-left, red. Removes the rule. Causes any Workflow stages that reference it to no longer apply the Rule.
- Duplicate: creates a copy of this rule with a new ID. Useful when starting from an existing rule that's close to what you need.
- Update: saves changes.
The advanced query field lets you trigger a rule only when content data matches specific criteria, much like a MongoDB find query. Open the rule, scroll down, and expand Show Advanced.
Builder evaluates the query against each block on the entry plus the entry's top-level fields. If any element matches, the rule fires for that element.
Common patterns:
Require approval whenever a "Hero" component appears
{ "component.name": "Hero" }Require approval only on pages with URLs that start with /legal/
{ "data.url": { "$regex": "^/legal/" } }Require approval when a CTA's link points to an external domain
{
"$and": [
{ "component.name": "Button" },
{ "component.options.link": { "$regex": "^https?://(?!www\\\\.example\\\\.com)" } }
]
}Require approval if a "promotional" tag is present
{ "data.tags": { "$in": ["promotional"] } }Supported operators include $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists, $regex, $and, $or, $nor, and $not. If you leave the advanced query at its default { "$comment": "..." }, the rule applies on the basis of the models and locale filters alone.
An approval is tied to the specific content it covers. If a contributor edits the same element again after approval, the rule will require a fresh approval. Moving content backward through stages does not invalidate prior approvals.
1. Legal review for marketing landing pages
- Name: "Legal review for marketing pages"
- Description: "All /marketing/ pages must be reviewed by Legal before publish."
- Approvers: Role: Legal
- Apply to models: Page model only
- Advanced Query:
When a contributor presses Publish on a /marketing/... page, the rule appears in the Approval Required panel. A user with the Legal role clicks Approve, and publish becomes available.
2. French content reviewer
- Name: "French content reviewer"
- Description: "French translations must be reviewed by a French-speaking editor."
- Approvers: User: Marie L., User: Jean P.
- Locales: fr-FR
- Apply to all models: on
Now any French content edit triggers the rule, regardless of model. Anyone else who tries to publish will see "Request Approval" and can ask Marie or Jean to review.
3. Restrict who can publish a particular model
- Name: "Press Release publisher"
- Approvers: User: Press Officer
- Apply to all models: off → Press Release
- Advanced Query: (leave default)
Without an Advanced Query, the rule triggers on every Press Release edit. Effectively, only the Press Officer can publish.
A Workflow is a series of named Stages that content moves through, plus the rules and permissions that gate each stage. Every content entry under a Workflow has a current stage.
- Go to Account Settings → Content Governance.
- Click Workflows in the left sidebar.
- Click + New Workflow in the top right.
- Fill out the Create Workflow dialog (described below).
- Click Create.
A confirmation notification appears confirming that Builder has saved the workflow. The workflow is now in the list with an ACTIVE or DISABLED chip.
Each new workflow starts with two pre-populated stages: Draft and Completed. You can rename, reorder, or delete them, and you can add as many stages in between as you need.
| Field | What it does |
|---|---|
Workflow name (required) | Shown in the editor's Workflow Stage picker and in the workflow list. |
Stages (required, 1 or more) | Ordered list of stages. Use + Add Stage to add another. Drag to reorder. |
Assign workflow owner(s) (required) | Users or roles responsible for the workflow. Owners can always edit, transition stages, and skip stages, regardless of stage-level permissions. |
Apply Workflow to all models (toggle) | On by default. Off reveals a Models picker. When scoped to specific models, only entries of those models follow this workflow. |
Enable workflow (toggle) | On by default. Disabled workflows are not applied to any content. |
Require sequential stage progression (toggle) | On by default. When on, non-owners can only move to the next or previous stage. Workflow owners always have full freedom to jump. Turn off to allow anyone to jump between any stages. |
Webhooks (under Show Advanced) | Outbound HTTP POSTs to your systems when governance events happen. |
Each stage has its own configuration:
| Field | What it does |
|---|---|
Stage name (required) | Display name, such as Draft, In Review, Approved, or Completed. |
Stage color | Optional. Used for the colored swatch shown next to the stage name in the editor. |
Description (required) | Helper text: Tell your team what this step is about. Appears beneath the stage picker in the editor so contributors know what is expected at this stage. |
Rules for this stage | Multi-select of existing Rules from the Rules tab. All selected rules must be satisfied, or approved, before content can move out of this stage. |
Users and roles who can transition this stage | Controls who can move content forward or backward from this stage. Options: Everyone, No one, or Only selected users/roles. |
Users and roles who can edit entries in this stage | Controls who can change content while it sits in this stage. Same scope options as transitions. |
The two pre-populated stages start with these defaults:
- Draft — Transitions: Only selected users/roles (you); Editors: Everyone. Description: "First step in the process where ideas and concepts are explored before being finalized or implemented."
- Completed — Transitions: No one; Editors: Everyone. Description: "Final step in process and content is ready to be published."
Workflow owners override everything. Anyone listed as a workflow owner can always edit, transition, and skip stages, even if a stage's scope says otherwise.
When a user transitions a piece of content:
- Forward by more than one stage. Every rule attached to every intermediate stage is approved on the user's behalf (if they have permission to approve). This is the "skip-ahead" path workflow owners commonly take to fast-track content. If a non-owner attempts this and Require sequential stage progression is on, Builder does not offer the option to skip.
- Backward. Rules are not re-evaluated. Stage history is preserved as a checkpoint so contributors can compare the content as it was at each stage.
- To a stage the user can't transition to. The button label changes from Move Stage to Request Stage Move. Clicking it creates a task for the stage's allowed admins, who get a comment notification.
A checkpoint is automatically created each time a stage changes, so the previous state of the content is preserved.
Workflows can fire HTTP POST requests to external systems when governance events happen. Open the Workflow editor and expand Show Advanced → Webhooks to add one.
For each webhook:
| Field | What it does |
|---|---|
URL (required) | Builder sends a POST with a JSON body to this URL when the selected events fire. |
Events | Pick one or more. Leave empty to receive every event. |
Custom headers | Add header key/value pairs. For example, an authentication token. |
Disable proxy (advanced) | By default Builder proxies the request through our backend. Turn this on to have your browser send the request directly. Useful for localhost development. Your endpoint must return CORS headers if you do. |
Supported events:
stageMoved— Content was moved from one stage to another.requestPublish— A user requested approval to publish.requestStageMove— A user requested a stage transition they don't have permission to perform.
Each event posts a JSON body that includes the event type, the workflow ID and name, content ID, content name, URL, the involved stages, and the user who triggered the action.
Use webhooks for integrations that help you send a Slack message, open a Jira ticket, or kick off a translation job. Builder handles in-product reviewer notifications automatically through tasks and comments.
1. Blog post workflow
Four stages: Draft → In Progress → Ready for Review → Completed
- Draft — Editors: Everyone. Transitions: Everyone. No rules.
- In Progress — Editors: Role: Writers. Transitions: Role: Writers. No rules.
- Ready for Review — Editors: Role: Editors, Role: Writers. Transitions: Role: Editors. Rule: "Editor approval required".
- Completed — Editors: Everyone. Transitions: No one. No rules.
Result: A writer drafts and moves to In Progress on their own. To leave Ready for Review they need an Editor to approve. Writers can't change their own work once it's in a Completed status.
2. Localization workflow scoped to a specific model
- Apply to all models: off → Article model
- Stages: Draft → Translation → Translation Review → Completed
- On Translation, attach Rule: "French content reviewer" (scoped to fr-FR).
- On Translation Review, attach Rule: "German content reviewer", scoped to
de-DE. - Workflow owners: Role: Localization Lead.
Each language reviewer is only pulled in when their locale's content actually appears in the entry. The Localization Lead can skip stages if needed.
3. Lightweight progress tracker (no rules)
- Stages: Idea → Drafting → Live
- Editors and transitions: Everyone on every stage.
- No rules attached.
The team gets a shared, visible status for every entry without any blocking gates. This is useful when you want visibility without friction.
Once a Workflow and any Rules are in place, contributors interact with them in the Visual Editor. When a contributor is ready to publish or move a stage, they receive a Publish or Save button with a small chevron. Clicking the chevron opens the governance review modal.
Workflow Stage picker at the top:
- Shows the workflow name and a dropdown of stages the user can move to.
- The current stage is marked IN PROGRESS; earlier stages are marked COMPLETED.
- The dropdown's options are filtered by Require sequential stage progression and the stage's transition permissions.
- Beneath the picker, the stage's description is displayed.
Rules, in up to three sections:
- Approval Required: rules that have triggered on this entry and have not yet been approved. Each row shows the rule's name and description. If the user is an approver, they see an Approve button. Otherwise, they see Request Approval, which posts a task and a comment tagging the approvers.
- Pending Approval: rules where this user has already requested approval and is waiting.
- Rules for this entry: all rules attached to the current and earlier stages, for context.
Move Stage button (bottom-right).
If there are no blocking rules and the user can move stages, clicking Publish directly publishes without opening the modal.
To submit content for review:
- Click the chevron next to the Publish button to open the governance review.
- Select the next stage from the Workflow Stage picker, for example, Ready for Review.
- Click Move Stage, or Request Stage Move if you don't have transition permission.
- Approvers receive a comment notification and a task. From the entry, the approver clicks Approve on each pending rule, then move the stage forward or click Publish.
A user attempting to publish is blocked from publishing when:
- They cannot transition the current stage and the stage's rules have not all been satisfied. Their only option is Request Stage Move.
- A rule is in Approval Required that they cannot approve themselves. They'll see Request Approval.
A user attempting to edit is blocked from editing when:
- They are not in the stage's editors scope, and they are not a workflow owner, and they are not a Builder admin. The editor will be read-only for them while content sits in this stage.
Approvals are content-aware. When someone approves a rule, Builder records a fingerprint of the data they reviewed. If that data later changes, the rule resurfaces and needs a fresh approval.
| Action | Who can do it |
|---|---|
Create, edit, or delete Rules and Workflows | Organization admins |
Approve a rule | Anyone listed as an approver on the rule; Organization admins |
Transition out of a stage | Anyone in the stage's transition scope; workflow owners; Organization admins |
Edit content in a stage | Anyone in the stage's editor scope; workflow owners; Organization admins |
Skip past intermediate stages | Workflow owners and Organization admins (always); other users only if Require sequential stage progression is off |
- Start small. A two-stage workflow with one approval rule is often enough. You can add stages and rules later without disrupting in-flight content (each entry stays at its current stage).
- Use roles, not individuals, in scopes when you can. Approver lists and stage scopes that reference roles, for example, Role: Editors, persist through team turnover. Individual user references break when that person leaves.
- Disable, don't delete. If you're not sure whether a Rule or Workflow is still in use, toggle Enable this rule or Enable workflow off and observe before deleting.
- Match locales precisely. A Rule with a Locales filter only triggers when the entry actually contains localized data in one of those locales. Empty or untouched locale fields will not match.
- Use one Workflow per model. If multiple active workflows could match a given model, Builder picks the first one whose model filter applies. Avoid overlap by giving each workflow a distinct model scope, or using Apply to all models on only one.
- Stage descriptions are guidance. Use them to specify completion criteria for each stage, as they are the most visible piece of workflow documentation contributors encounter.
- Webhooks are not retried. Builder does not retry webhooks. If your endpoint is down, the event is lost. Make sure your endpoint responds quickly and treats events as idempotent.
Content Governance is not visible in Settings
This area is only available to Organization admins on plans that include the governance entitlement. Contact your Builder.io account team or Organization admin to confirm access.
A rule is not triggering
Check four things:
- the rule is enabled
- the models filter includes the content's model or is set to all models
- the locales filter is empty or includes a locale present in the content
- any advanced query matches at least one element on the page
A contributor cannot publish
Open the entry and check the governance review popover. Pending rules appear under Approval Required with a reason. If the issue is stage permissions, the Move Stage button reads Request Stage Move instead.
Content moved to a workflow stage automatically
When you first enable Content Governance in All content mode, Builder places existing entries at the first stage of any applicable workflow. This happens once, on initial setup.
A webhook fires multiple times
Builder fires each subscribed event once per occurrence. If an endpoint receives duplicates, check whether multiple workflows have webhooks pointing at the same URL.