Where pending approvals appear
There is no single universal queue implied by this table. Open the surface for the work you are reviewing. If you cannot see a queue or decision control, check access and configuration rather than trying to bypass the review.
Which actions require approval?
Workflow step gates and applicable action rules determine where a workflow pauses. Some steps can be configured to always require a human; protected steps cannot simply be unlocked by the reviewer. Shared rules can also apply. Availability and configuration vary by organization. Where the approval-policy configurator is enabled, Settings → Approvals (/settings/approvals) requires approvals:view. Creating or managing policies requires approvals:manage; policies scoped to workflow steps or step actions additionally require agents:manage. Workflow-local gate controls have their own edit and gate-rule permission checks.
Do not change approval policy just to clear an individual pending item. First establish why the proposed action requires review and who is authorized to decide.
Who can approve?
The configured chain and server-side authority checks determine the next eligible role or person. Havingagents:view, agents:manage, or access to the pricing inbox does not by itself prove that you are the next approver for a particular item. Use the decision controls available to you; a missing control may reflect routing or an unmet prerequisite.
Some workflows require more than one signoff. Your approval can leave the item waiting for remaining approvals rather than completing it.
What evidence to review
Before deciding, verify:- The exact proposed action and its consequences: draft, send, approval, or issuance.
- The customer, recipients, order or request reference, product, quantity, units, and currency where relevant.
- The supporting source records, dates, attachments, and any conflicting evidence.
- The exact quote or PDF being reviewed, when one is available—not an earlier downloaded copy.
- The decision history and whether the item has changed since an earlier review.
Email actions in a workflow
A pending email action shows its draft content and supported review controls. Review the subject, body, recipients, attachments, and any quote PDF before using an explicit approve/send action. That action can send an email. Read the button and its confirmation rather than assuming it only records an internal decision. Use Edit where supported. For multi-material quote changes, save the changes and refresh the quote review, then inspect the refreshed PDF before explicitly approving. Stale quote evidence must not be approved as though it were current. If an Override control is available, read its confirmation carefully. It is not approval to send: the supported override path does not email, and it can complete Intake and allow other enabled agents to start. Do not use it as a generic substitute for rejection or correction.Pricing and quote decisions
The quote approval path separates pricing approval, quote approval, and issuance. Pricing review comes first. Issuance is a separately authorized operation after the required approvals; quote issuance does not itself send email. The review panel shows the saved quote revision and, when prepared, the exact reviewed PDF. It requires a decision reason and offers Approve, Send back, or Escalate according to server-confirmed authority. Inspect the recorded decision history afterward. If the quote, pricing policy, cost, or approval authority changes, the earlier review can be invalidated and a new review is required. Approval of an earlier revision is not approval of the changed quote.Approval, rejection, and requested changes
There is no universal Reject or Request changes button across all these surfaces. Follow the actual controls for the item. For lessons, see the lifecycle and independent review requirements.