Skip to content
Docs
flero.ai

Multi-party approvals

When one approver isn't enough. Configure the Approval node with multiple approvers and a policy that controls how their responses combine.

📸 Screenshot needed: approvals__multi-party.png, Approval node inspector with three named approvers added (Ada, Bertrand, Cleo), an "Approval policy: All approvers" selector, and an "Order: parallel" toggle.

Policies

Policy Approved when… Rejected when…
Any one First approver clicks Approve Every approver has clicked Reject (or all but one rejected and the last is silent, depends on timeout)
All approvers Every named approver has clicked Approve Any approver clicks Reject
Majority More approvers approve than reject More approvers reject than approve
Quorum: N At least N approvers approve Reaching total - N + 1 rejections (mathematically can't approve)

Pick Any one for redundancy ("any manager can sign off"). Pick All approvers for joint sign-off. Pick Majority or Quorum for committee-style decisions.

Order: parallel or sequential

  • Parallel (default), all approvers are notified simultaneously; first responses decide based on the policy.
  • Sequential, approvers are notified one at a time, in the order listed. Each approver only sees the request after the previous one has approved. A rejection short-circuits, later approvers never see it.

Sequential is useful for hierarchical sign-off chains ("first the line manager, then VP, then CFO"). Parallel is faster.

Adding approvers

In the Approval node's inspector → Approvers:

  • Type a name or email to add a workspace user.
  • Type a role name (e.g. @finance-admins) to add everyone with that role.
  • Click Add public approver to add an external email (a public approval link will be generated for that person).

You can mix all three.

Drag to reorder (matters for sequential).

Per-approver visibility

By default, every approver sees the same approval card. You can also configure per-approver data, show different fields to different approvers (e.g. the finance team sees the full cost breakdown, the legal team sees just the contract title and parties).

Set up in the node's inspector → Advanced → Per-approver views.

Decision recording

The output payload includes the full record of who approved / rejected and when:

{
  "approval": {
    "policy":     "all approvers",
    "decision":   "approved",
    "responses": [
      { "approver": "ada@acme",      "decision": "approved", "comment": "LGTM",        "at": "2026-05-15T10:00:00Z" },
      { "approver": "bert@acme",     "decision": "approved", "comment": null,           "at": "2026-05-15T10:05:00Z" },
      { "approver": "cleo@acme",     "decision": "approved", "comment": "Approved with notes", "at": "2026-05-15T10:12:00Z" }
    ]
  }
}

Persist this somewhere (Database node, audit log) if you need a long-term record beyond Flero's standard retention.

Escalation

If the configured timeout fires before the policy is satisfied, the Timeout action kicks in:

  • reject, auto-reject.
  • approve, auto-approve (rare).
  • escalate to <user/role>, add another approver and reset the timeout.
  • keep waiting, no timeout effect.

Escalation is the right answer when the approver may be unreachable but the decision shouldn't auto-revolve. E.g. "if line manager doesn't respond in 24h, escalate to their director".

Common patterns

  • Two-of-three quorum for transactions over a threshold.
  • Sequential hierarchy for HR or legal sign-off.
  • Parallel-any-one redundancy among on-call engineers.
  • Time-bounded approval with reject default for security-sensitive requests (no response = denied).

Tips & gotchas

  • Sequential delays add up. If each approver takes a day, sequential of 3 = 3 days. Use parallel when responsiveness matters.
  • Public approvers can't see other approvers' identities by default, for privacy. Toggle this in Advanced if appropriate.
  • A reject in All approvers mode short-circuits immediately, other approvers don't even get notified once one has rejected. (Configurable: toggle "Notify all even on early rejection".)
  • Roles update dynamically. If you list a role, new users joining that role can approve newly-pending requests. Existing pending requests are not re-evaluated.

Found something out of date? This page lives in the Flero docs content set.