Authoring a rule — the four-step wizard

Open Pinion Admin → Approvals → New approval flow. The wizard has four steps and a sticky brand-themed header so you always know where you are.

Step 1 — Basics

Give the chain a name (e.g. “Discount escalation”), pick the target object (Quote / Opportunity), set the chain Mode (Sequential / Parallel / AnyOf / AllOf) and Match Policy. Match Policy controls which firing steps advance the chain:

  • All (default, back-compat). Every step whose criteria match must approve. Use this for “Manager, then Sales Ops, then CFO” stacks where every escalation level still has to sign.
  • Any (First Match). Only the first step whose criteria match fires; its decision is final. Use this for tiered routing — “if discount > 30%, CFO; else if > 20%, VP; else manager.” Higher tiers shadow lower ones.
  • Any (Fallback). The first matching step’s approval ends the chain; if it rejects, the next matching step’s approver is invited. Use this when an approver should have right of first refusal but the chain should keep escalating if they say no. A fallback approver’s approval approves the chain, so the configuration can be synced even though an earlier step rejected it. If every matching step rejects, the chain is rejected and the configuration returns to Draft. The chain ends for that submission only. When reps submit several configurations on one deal to the same chain, each configuration runs its own copy of the chain, and approving one configuration never cancels the requests of another.

Step 2 — Steps

This is the split-pane editor. The left rail lists the steps in the chain; the right pane edits the selected step’s firing criteria and approver. Click Add step for each rule.

Each step has:

  • A name (rendered on the runtime request and the chain card).
  • One or more firing conditions — the “when does this fire?” criteria. At least one is required. See Every step needs a condition.
  • A scope product (optional) — restricts the whole step to deals carrying that product. See Scope Product.
  • An approver assignment — see Approvers.

You can drag steps to reorder them; the wizard re-numbers Order__c on save.

Every step needs a condition

An approval step with no conditions never fires. Pinion treats a step with nothing to test as a configuration mistake, not as “approve every deal”, so it never requests that approval. To stop a flow from looking like it gates deals when it gates nothing, the wizard won’t save a step that has no conditions:

  • The step’s When this step fires panel reads No conditions · never fires, and the step is marked Needs a condition in the left rail.
  • A banner on the Steps page and on the Review page names each step that needs a condition.
  • Save stays disabled, and the reason is shown next to the button, until every step has at least one condition.

Pinion enforces the same rule on the server, so it applies however a rule is saved. A condition that is switched off doesn’t count, because only active conditions are evaluated.

To require approval on every deal, give the step a condition that is always true. For example:

Tested objectFieldOperatorValue
Configuration OptionStatusIs Not Null(leave blank)

Every configuration option has a status when it’s submitted, so this condition matches every submission. Pinion has no separate “applies to every deal” switch; an always-true condition is how you get that behavior.

Opening an older flow that has a conditionless step. The wizard shows the same banner and won’t save until you add a condition. If you only want to turn that flow off, use its Active toggle on the Approvals list instead. Switching a flow off never requires a condition, but switching a rule back on does.

Step 3 — Policy

Per-chain knobs:

  • Consolidate Redundant Approvers. When on, if the same user appears on multiple steps, their approval on an earlier step carries forward — later steps for that user auto-approve. Off by default. Turn on if your org has a CFO who sits on three steps of the same chain and shouldn’t get three notifications.

  • Editable After Approval (per rule). When off (default), the configuration is locked once the rule’s approval is granted. If multiple active rules fire, the strictest one wins.

  • Allow Bulk Approve. Off by default. When on, approvers can sign off on requests from this rule in batches from the bulk-approve dashboard. Leave off for high-stakes rules.

  • SLA Hours. Optional. Hours-to-decision; breached requests are picked up by ApprovalEscalationBatch and re-routed to the Escalation Approver. Blank = no SLA. The sweep is scheduled automatically on install (job name Pinion Approval Escalation, cron 0 0 * * * ? — top of every hour). To disable escalations, leave the job running and turn off SLA on the rules that should opt out (set SLA Hours to blank or 0), or abort the job in Setup → Scheduled Jobs.

  • Reroute On Fields. Comma-separated field paths (e.g. Account.OwnerId, Opportunity.StageName). If any of these change while a request is Pending, the approver is re-resolved. Fixes the “Account Owner moved teams mid-approval and the old owner is still on the hook” problem.

    A field listed here does not need to appear in any of the rule’s conditions. Pinion loads and records every path you list, whether or not the rule also tests it, so you can gate rerouting on a value the rule never evaluates — TCV__c, for instance, on a rule whose only condition is on Stage. The recorded value is what Pinion compares against on the next submission, so listing a field here is what makes a change to it count as a change at all — and it is also what the approver’s What Changed panel compares, so listing a field here makes it visible in that Field / Before / After table.

    Paths are checked against your schema when the rule runs. A path that names a field that does not exist, or one the submitting user has no read access to, is ignored rather than treated as an error — the rest of the rule still works, and approvals themselves are unaffected, because whether a request is required at all is decided by the rule’s conditions, not by this list.

    The cost of a typo is that the rule stops rerouting on that field entirely. An unresolvable path is recorded as blank both times it is compared, so it always looks unchanged and never triggers a re-resolve. If an approver is not being re-resolved when you expect, check the spelling here first — a silently ignored path looks exactly like a field that never moves. Cross-object paths (Account.OwnerId) and paths on the target object itself (TCV__c) are both supported.

  • Smart Approval. When on, if the same approver previously approved an unchanged version (Pinion diffs the snapshot JSON), the new request auto-skips with a Skipped_SmartApproval trace note.

Step 4 — Review

A read-only summary of the chain. The wizard runs author-time validation here: per-step missing approvers, steps with no conditions (see Every step needs a condition), per-condition missing fields, and null-RHS rejection (a Greater Than condition with a blank value would silently never fire — the wizard refuses to save it). Each step’s When line shows its conditions, or says the step would never fire. Fix any flagged items and click Save.