Submitting & Recalling
This is the rep’s side of an approval: getting a deal that triggered an Approval Rule into the approval queue, and managing it while it’s there. You do this on the deal — from Product Display or from the configurator’s Approvals panel — not the Approvals app (that’s where approvers work).
Where the controls are
There are two rep-facing surfaces, and they share the same engine:
- Product Display (on the record) — shows each configuration’s approval state (an Approval Required badge) with a Submit for Approval / Resubmit for Approval button. An Open in QLE button here takes you into the configurator and its Approvals panel.
- The configurator (QLE) → Approvals panel — a richer panel that lists the rules with Required / Submitted chips, a Submit for approval button, a lock banner when pending, and a Recall submitted approvals button.
Either surface submits the same way; recall lives in the configurator’s Approvals panel.
When a configuration needs approval
After you save a configuration, its approval state shows up. The states a rep sees:
| State | What it means | What you can do |
|---|---|---|
| Not required | Matches no active rule | Sync it — no approval needed |
| Required | Matches a rule; not yet submitted | Submit for Approval |
| Submitted / pending | Submitted; waiting on approvers | Wait, or Recall to edit |
| Approved | All required approvers signed off | Sync it to the deal |
| Rejected | An approver sent it back | Fix it, then Resubmit |
| Synced | Already synced to the deal | — |
Submitting for approval
When a configuration is Required, click Submit for Approval (Product Display) or Submit for approval (configurator Approvals panel). Submission:
- Evaluates the active Approval Rules against the saved configuration (not unsaved edits),
- Creates an approval request per firing rule and routes each to its approver(s) in the chain’s order (sequential or parallel, with SLAs),
- Locks the fields the rules test on the deal (the configurator panel shows a “Quote locked — fields gated by pending approval” banner),
- moves the configuration to Submitted / pending.
While it’s pending
Once submitted, the configuration sits in Submitted / pending until the chain resolves. The rule’s tested fields are locked on the deal — editing one is blocked with a message naming the rule. When the chain resolves: Approved → you can sync it; Rejected → it returns to you. You’re emailed on the final decision. Approvers act in their My Approvals queue.
Resubmitting after a rejection
A rejected configuration shows Resubmit for Approval. Make the changes the approver flagged (their rejection comment says what), save, and resubmit — it runs the rules again and re-routes the chain. The decision history is in the Trace.
Recalling a pending submission
Need to pull a submission back before a decision — to fix a number without waiting for a reject? Use Recall submitted approvals in the configurator’s Approvals panel (it appears once a configuration is submitted, next to the lock banner). Each rule defines a recall scope (set by your admin on the chain — see Approval Rules ▸ Policy) that controls what the recall invalidates:
- No recall — the rule can’t be recalled; wait for the decision.
- Only this step — just the current pending step.
- Downstream only (default) — the pending step and everything after it, preserving approvals already given.
- Whole chain — the whole chain re-evaluates from the top on resubmit.
After a recall, the configuration returns to an editable state; fix it and resubmit.
Related
- Overview — the full lifecycle and who does what.
- My Approvals — the approver’s side.
- Notifications & Locks — which fields lock and the emails that fire.
- Approval Rules (§3) — authoring the rules, chains, and recall-scope policy.