Notifications & Locks

The visible parts of approvals are submitting and deciding. Behind them, three things keep the process honest: notifications so people act in time, field locks so a deal can’t drift while it’s under review, and rerouting so the right person still approves when the deal changes.

Notifications

Pinion notifies on the two moments that matter:

  • Submitted — the approver is emailed when a request lands in their queue (“Action required”), with the deal context, the reason, and the SLA deadline.
  • Decided — the submitter (the rep) is emailed when the chain reaches a final decision (“approved” / “rejected”), including the approver’s comment.

Email delivery is best-effort — a send failure is logged and never blocks the approval itself.

Field locks

When a configuration is submitted, the fields its rules test are locked on the deal — so the number that triggered approval can’t quietly change while approvers are reviewing it. Try to edit a locked field and you’re blocked with a message naming the rule and telling you to recall or wait.

  • While pending — every tested field across all pending requests on the deal is locked.
  • After approval — the lock persists unless the rule was authored Editable after approval (then those fields free up once it’s approved). When multiple rules touch the same field, the strictest wins — any rule that isn’t “editable after approval” keeps it locked.
  • Syncing an approved configuration is allowed — the system briefly lifts the lock for the approved sync so writing the line items doesn’t fight it.

Rerouting on change

Some changes should send a deal to a different approver — most commonly when the deal’s owner changes and the chain routes to “the owner’s manager.” For that, a rule can name reroute-on-change fields. If one of those fields changes after submission:

  • Pinion re-resolves the approver from the rule’s formula,
  • and if it now resolves to a different person, the original pending request is skipped (kept in the audit trail) and a new request is created for the new approver.

So a deal reassigned mid-approval doesn’t sit in the wrong person’s queue — it follows the rule to whoever should now sign off. (Fields the rule already tests are covered by the field lock above; reroute-on-change is for fields that should re-route without being locked.)

Re-checking a pending approval when the deal is recalculated

The field lock keeps you from changing a deal while it’s pending, but Pinion itself can still recalculate it (for example, re-rolling up line totals at the end of a line-item sync). When a sync recalculates a pending deal, Pinion re-runs the approval rules against the final, recalculated deal and checks every pending request (not only rules with reroute-on-change fields):

  • Still required, same approver — the request stays pending; its recorded snapshot is updated to the recalculated values. No one is notified.
  • Still required, different approver — the request is rerouted: the original is skipped and a new request goes to the new approver, who is emailed as for any new submission.
  • No longer required (the rule no longer fires) — the request is recalled automatically with the comment “Auto-recalled: the deal changed and this approval is no longer required”. The approver is emailed that no action is needed, and you get the usual decision email. This happens even when the rule’s recall scope is No recall, which only limits recalls you start yourself. The recalled request no longer locks the fields its rule tests.
  • Submitting & Recalling — the lock is applied at submit; recall (in the configurator’s Approvals panel) lifts it.
  • My Approvals — where the notified approver acts.
  • Approval Rules ▸ Policy — “editable after approval”, “reroute on change”, and the reason template are authored there.