Approvals and Grants: What an Automation May Do

Two different things in BankSync are called approving, and both are a person's decision.

• A grant is what a published automation may do: the permissions, the banks, feeds, tables and mailboxes it touches, where its data may go. A member approves it once per version, and the automation runs under it.
• An approval step holds one run until a person decides on exactly what that run is about to do — delete these forty rows, send this email.

The grant#

What it asks for#

The grant is worked out from the automation itself — the steps it uses, the resources it is bound to and its config — never from what its author wrote in a description. Open the grant from the toolbar (the button with the dot) to read it:

• What it runs — every step by its own name and how serious its effect is (a read, a write, something that cannot be undone).
• Permissions — banks:read, tables:write, notifications:write and so on, one for each kind of step.
• What it touches — each bound bank, feed, table, enrichment, dashboard, widget or mailbox, with the access the steps need (view or edit).
• Where its data may go — any outside host a step sends to.
• Limits for things that can't be undone — a cap on how many of each irreversible effect a run may make without an approval step in front of it. The approver may lower a cap, never raise it.
• Automations it may call.

Each line is marked when it is new since the grant before, so a change is easy to read.

Who approves, and for how long#

Approve is offered to a member signed in to BankSync who holds every permission the grant asks for. An API key or an agent is refused. The approver chooses how long the approval holds — 7, 30 or 90 days, or a year (90 by default) — and the toolbar says when it runs out. Ask an owner sends the request to someone who can.

While the grant is waiting, the toolbar reads Waiting for approval and Run now says why it cannot. Once approved, the automation can be turned on.

When it needs approving again#

The grant holds while what it covers stays the same. It needs approving again when:

• a new version is published that needs more, or different, permissions or resources. (A version that needs exactly what the last one did reuses its approval.) Once a version is approved, publishing a change, on or off, leaves the approved version current until the new one is approved; Withdraw these changes drops the new one instead.
• a binding or a config value changes after publishing. Ask again sends the request computed from the new state.
• the approver loses a permission the grant lists. BankSync checks nightly; the grant moves to needs approving again, runs carry on for seven days, then are refused until a holder approves it.
• the approver loses access to something the automation is bound to, in a workspace that restricts access. The run fails with access revoked and the automation is turned off until someone with access approves it again.
• the approval expires.

Every run checks the grant as it starts: an approved, unexpired grant whose steps, bindings and config still match what was approved. Anything else, and the run does not start; the toolbar and the run's history say why.

Withdrawing#

Withdraw: runs stop revokes the grant for good. New runs are refused at once; runs already going finish. Anyone who can edit the automation can withdraw; approving again needs a holder of every permission. Going back to an earlier version holds only while that version's own grant does — see Publishing, versions and going back.

Approval steps#

An Approval step (Ask someone to approve) in a run creates a request bound to the exact items it is holding. The run pauses as waiting; the request appears in Approvals, reached from the Automations tab, and the people asked are notified.

The card shows the automation and the gated step by its own name, a fingerprint of what it is about to do (the first twelve digits, the whole on hover), how many people must approve and who has, and when it lapses. Approve lets the items through to the step's approved output; Reject sends them to rejected. A request nobody decides in time counts as rejected.

Rules. The person who started the run can never decide its approvals. The buttons are offered to a person only: an agent or an API key can read a request but never decide it. BankSync reads the request again as you decide: if it was already decided, has lapsed, or what the step would do changed since you opened it, your decision is not sent and the card says why.

The inbox filters Assigned to you, All waiting and Decided; a request a newer run has overtaken is marked Superseded. Beside approval-step requests it lists automations whose grant is waiting: New automation for one never approved (an install makes these), and Changes need approval for one, on or off, whose published changes wait while the approved version stays current. Their card opens the automation's approval pane.

When an approval step is required#

A step that cannot be undone — a mirror sync that deletes rows, a bulk delete over the threshold, sending mail — needs an approval step in front of it when:

• its run started from an unverified webhook (one with no signing secret), or
• it would exceed the cap the grant set for that effect.

The builder lists a missing approval step in To do, and the run refuses the step the same way if the draft somehow got past it.

Every decision is recorded#

Every grant request, approval, withdrawal and approval-step decision is written to the automation's audit with who made it and when, before the effect it allows. Nothing can edit or delete the audit. Open the run's history to see each step's effect and every refusal.