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.” A field listed here is recorded at submit time whether or not any condition on the rule also tests it, which is what makes the reroute fire on that field specifically rather than on any edit to the record.
  • 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.