Approvals
Forge never changes your application without asking. Here's how approval cards, risk levels, and approval modes keep you in control.
Forge doesn't change anything behind your back. When it's about to create, modify, or delete something, it pauses and shows you an approval card — what it wants to do, and how risky the change is. Nothing happens until you decide.
Reading never requires approval: Forge freely explores your application — listing workflows, inspecting the database schema, checking logs — to understand the context before proposing changes.
The approval card
When Forge requests a change, an Awaiting your approval panel appears above the input field:
- A plain-language summary of the change, e.g. Create agentflow "Support Bot" or Delete credential "Slack token" (any workflow using it will break).
- A Details section you can expand to see the exact contents of the change.
- Three actions: Approve, Reject, and Add reason — reject with a note explaining what you'd like instead, and Forge takes it into account and adjusts its approach.
Rejecting doesn't end the conversation. Forge treats it as feedback: it won't perform the action and will suggest an alternative or ask what to change.
An approval request expires after 15 minutes. If you step away and it times out, just ask Forge to try again.
Risk levels
Every proposed change carries a risk level, shown on the card:
| Risk level | What it covers | Examples |
|---|---|---|
| Low risk | Reversible edits to drafts | Adding a node to a workflow draft, linking two steps |
| Medium risk | Visible configuration changes | Saving a credential, subscribing a workflow to a trigger, inserting data |
| High risk — cannot be undone | Destructive changes | Deleting a table or field, removing rows, rotating a secret |
Worth pausing on high-risk cards: they are exactly the changes with no undo. Expanding Details before approving takes a second and is a good habit.
Approval modes
How often Forge asks is up to you. The Approval mode setting below the chat applies to the current conversation:
| Mode | Behavior |
|---|---|
| Auto | No approvals — every change runs silently |
| All changes | Ask for every change, including low-risk draft edits |
| Medium & high (default) | Ask for medium and high risk; low-risk draft edits run without asking |
| Only high risk | Ask only for destructive changes |
The default strikes a practical balance: Forge iterates on drafts freely, but anything visible outside the draft — credentials, triggers, data — still comes to you first.
Auto mode lets Forge perform any change, including irreversible deletions, without asking. It suits experimenting in a scratch application; think twice before using it in a workspace with real data.
Approvals and drafts are separate safety nets
Approvals control what Forge may change; drafts control what your users see. Even an approved change only lands in a draft version — deploying to production remains a separate, deliberate step you take in Studio. Running a flow to test it happens in design-time and doesn't affect your published versions either.