Runtime & troubleshooting

Why this approval?

When an approval is pending on a quote, the configurator’s Approvals card lists every firing rule, each with the approver’s name and a hover-revealed Why this approval? tooltip. The tooltip shows:

  • Every condition on the rule, with a check / X glyph reflecting that condition’s truth value.
  • The combine setting (All / Any / Custom) and the rendered logic expression.
  • The live observed value of each tested field, so reps can see exactly which field tipped them past the threshold.

This is the same diagnostic surface the engine writes to ApprovalEvaluationLog__c.ConditionTrace__c — one log row per rule per evaluation, with a JSON trace per condition. Open the log records when investigating “why didn’t this rule fire on this deal?” The note field on each trace entry surfaces the skip reason verbatim:

  • skipped: TestedObject Quote incompatible with tenant TargetObject Opportunity
  • skipped: ScopeProduct <id> not present on cart
  • unresolved variable: <Name>
  • tested value unavailable
  • no numeric values for <Field>
  • aggregator field missing

The submission-time toast in the configurator summarises per-chain results — which chain fired, how many of its paths are required, and whether the match policy means “all must approve” or “any will advance.”

Disabling approvals

The kill switch lives on the singleton ConfiguratorSettings__mdt record (the same CMDT that drives the product / pricing rule kill switches). Check Disable Approval Rules (DisableApprovalRules__c) to disable the entire engine: no rules fire on submit, no preview gating happens on the Product Display tab, and any existing pending requests are preserved but not enforced. Use this if approval rules cause issues in production — your existing approvals don’t disappear, they just stop blocking new work.

Worked example — a full discount-escalation rule

A finance team asks: “Any deal with > 20% discount on our Enterprise Tier SKU should escalate. Manager approves up to 25%; VP between 25% and 35%; CFO above 35%.” Here’s how that lands as a Pinion approval chain.

  1. Open the wizard. Pinion Admin → Approvals → New approval flow. Name: “Enterprise discount escalation.” Target: Opportunity.
  2. Pick the chain mode and match policy. Mode: Sequential. Match Policy: Any (First Match) — the higher tier shadows the lower, so only one step fires per deal.
  3. Add the rule-level scope. Set the rule’s Scope Product to “Enterprise Tier.” Every step inherits this gate.
  4. Author the variable (optional but useful — discount threshold moves over time). Variables tab → New → Name: DiscountFloor, Formula: Account.Discount_Threshold__c, Return Type: Percent. (Or skip this and use literals.)
  5. Add Step 1 — Manager. Approver Type: Manager. No Approver record needed. Firing condition: Opportunity.Discount__c Greater_Than 20. Single condition; ConditionsMet defaults to All.
  6. Add Step 2 — VP. Approver Type: Approver. Pick an Approver record wrapping “VP, Sales.” Firing condition: Opportunity.Discount__c Greater_Than 25. Because Match Policy is Any (First Match), this step shadows step 1 for any deal > 25%.
  7. Add Step 3 — CFO. Approver Type: Approver. Pick “CFO.” Firing condition: Opportunity.Discount__c Greater_Than 35.
  8. Step 4 — Policy. SLA Hours: 48. Reroute On Fields: Opportunity.OwnerId. Editable After Approval: off. Smart Approval: on (if the rep recalls and resubmits unchanged, don’t ping the approver again).
  9. Step 5 — Review. Wizard validates: every step has an approver, every condition has a value, every variable resolves. Save.

What the rep sees: configures Enterprise Tier with a 30% discount, hits Submit for Approval. The Approvals card shows one pending request (“VP, Sales”). Hover Why this approval? — the tooltip explains: Opportunity.Discount > 25 (observed: 30) ✓. The rep can see exactly which threshold they tripped. The VP approves; the configuration is locked (Editable After Approval = off); the rep can sync to the QLE.

If the rep then ups the discount to 40% and resubmits, step 2 stops matching, step 3 matches, and the request routes to the CFO instead — because the match policy is First Match, only one step ever fires per submission. Smart Approval doesn’t help here: the snapshot changed.

If the rep is later moved to a different team mid-approval, the Reroute On Fields setting catches the OwnerId change and re-resolves the approver chain against the new owner.

  • Authoring a Rule — the wizard this example drives.
  • Conditions — the firing criteria and the trace notes.
  • Approvers — the resolution paths (Manager, Approver, Formula).