How to Configure Building Block Approvals and Scheduled Runs
This guide explains how to require approval before specific building block changes are applied, and how to let meshStack periodically check for or fix configuration drift on its own. Both are configured on the building block definition's Policies tab.
Challenge
Some building block changes are risky enough that you want a human to review them before they're applied — for example, a version upgrade, or any change to a production tenant's inputs. At the same time, you don't want to review every single run: routine changes should keep applying automatically.
Separately, infrastructure can drift from what your building block declares — someone changes a resource directly in the cloud console, for instance. You want to find out about that drift, and possibly have meshStack fix it, without relying on someone remembering to trigger a run.
Run approvals and scheduled runs solve both problems. Run approvals need the OpenTofu implementation type, and so do most scheduling options — see Implementation Type Support for the one exception.
Prerequisites
- Admin permissions, or the platform team's managed building block permission, on the building block definition you want to configure
- A building block definition using the OpenTofu implementation type — required for run approvals and for most scheduling options; see Step 3 for the one exception
- To approve or reject a run once it's held for approval, you need the same permission again — see Who Can Approve a Run
Step-by-Step Guide
Step 1: Open the Policies Tab
- Navigate to Platform Builder (or the Admin Area) > Building Blocks > Definitions
- Select your building block definition
- Go to the Policies tab
Step 2: Configure Run Approvals
In the Run Approvals section, toggle on the causes that should hold a run for approval:
| Toggle | Holds for approval... |
|---|---|
| Building Block creation | New instances of this building block |
| Version upgrade | Runs that execute a building block upgrade |
| User input changes | Runs with user or platform operator input changes |
| Manual triggers | Manually triggered runs, including retries after failures |
| Any input changes | Any resolved input change, including system-driven ones — a superset of "User input changes" |
Enable only the causes that matter for your compliance needs. Every enabled cause adds a manual step application teams and platform operators must complete before that kind of change lands — see Run Approval Causes for the full picture, including what "Any input changes" also covers.
If your building block isn't on the OpenTofu implementation type, this section instead shows "Approvals are not supported for this implementation type," and there's nothing to configure here.
Step 3: Configure Drift Detection & Schedule (Optional)
In the Drift Detection & Schedule section, choose a mode:
- Disabled — leave this selected if you don't want scheduled runs at all.
- Detect drift only — meshStack periodically runs a dry run and records whether it found drift, without changing anything.
- Detect and fix drift — meshStack periodically runs and fixes any drift it finds. If you pick this mode, also choose:
- Wait for approval — the fix is held for approval like any other gated change (requires OpenTofu).
- Apply automatically — the fix is force-applied immediately, with no review. meshStack warns you that this may destroy or recreate resources without review.
Then pick a frequency, Daily or Weekly. See When Scheduled Runs Actually Fire for the exact time of day these run.
Manual building blocks can't be scheduled at all. GitHub Actions, GitLab CI/CD, and Azure DevOps Pipelines building blocks can only use "Detect and fix drift" with "Apply automatically" — they can't produce a plan to review first, so "Wait for approval" and "Detect drift only" aren't offered.
Step 4: Save
Click Save. The policy applies to every building block instance of this definition.
Step 5: Approve or Reject a Held Run
Once a run is held, the affected building block shows a Review Approval action in its list, and its status reads Waiting for Approval. Whoever can approve it also gets an email notification — sent within 15 minutes, batched together if several runs need approval in that window.
- Open the run's details page (from the building block's Runs tab, or via the Review Approval action)
- Review the plan shown on the page — this is exactly what will be applied
- Click Approve run to apply it as-is, or Reject run to cancel it without applying anything
Rejecting a run does not schedule a new review of the change. Trigger a new run yourself if you still want it applied later.