Approvers

An Approver__c record is reusable across many rules. Each Approver wraps one of four backing entities:

  • User. Direct user assignment. Simplest case.
  • Queue. All members of the queue see the request. Two resolution modes: First Claim (the first member to act decides for all) and All Members (every member must act).
  • Public Group. All group members are notified; the cohort policy on the request decides whether one or all must approve.
  • Role. All users in the role (or role + subordinates, per Salesforce semantics) are valid approvers.

Each Approver also supports:

  • Active. Lets you sunset an Approver without deleting it.
  • Delegate User + Delegate Until. OOO coverage — if the original approver is out and the date is in range, the engine routes the request to the delegate.

How a rule picks its approver

Approvers attach to rules through ApprovalRuleApprover__c (a junction with an Order, so multi-approver steps have a deterministic sequence). A junction row stores both Approver__c (the picked record) and ApproverRecord__c (the original authored identity, preserved across save+hydrate so the wizard’s Review step always renders the right display name).

The rule itself has an ApproverType__c picklist that determines the resolution path:

  • Approver — use the Approver records on the junction directly. Most rules use this.
  • Manager — walk one step up from the submitter (the rep who hit Submit).
  • AccountOwnerManager — walk up from the deal’s Account owner. Used for “sales leader for this customer must approve.”
  • Formula — evaluate ApproverFormula__c (a field path like Quote.Account.Owner.ManagerId) to a User Id. Use this when the approver isn’t a fixed person — they’re a function of the deal.

Sequential, Parallel, and cohorts

The chain’s Mode__c picks how the steps run:

  • Sequential. Step 1 fires first; step 2 only after step 1 resolves.
  • Parallel. All steps fire at once; the chain advances when every step resolves.
  • AnyOf. First decision wins.
  • AllOf. All steps must approve before the chain advances.

Within a single multi-approver step, the request’s CohortClaimMode__c picks Any Claim (first approver in the cohort decides) vs All Members (every approver in the cohort must act). Queue approvers use the Approver’s QueueResolutionMode__c to pick the same semantics.

Reroute and consolidation

  • Reroute On Fields (per rule, see the Policy step). Listed fields, when changed mid-approval, trigger a re-resolve of the approver — the current Pending request is replaced with a fresh one pointed at the new approver. Solves “Account Owner changed and the old owner is still on the hook.”
  • Consolidate Redundant Approvers (per chain). If the same user appears on multiple steps of the same chain, their approval on an earlier step carries forward to later steps. The carried-forward request is written as Approved immediately on activation rather than as a fresh Pending row.