Use Approvals when a business process needs a named person to make a decision before it continues. The queue brings the request, supporting context, approvers, deadline, and decision history together.
An approval is created by a configured workflow or another supported business action. Opening the queue does not automatically add approval requirements to every action in your account.
Understand the request
Open Approvals. Waiting on you shows pending requests addressed to you, Decided shows completed decisions, and All gives the wider list your account allows you to view.
Select a request and check:
- What action is proposed and which business record it concerns.
- Who requested it and the explanation they supplied.
- Any amount, currency, or supporting fields.
- Who must decide, the current approval step, and the deadline.
- What the policy says will happen if nobody responds in time.
The request records the context supplied when approval was requested. If it links to the underlying item, open that item when you need to compare current details. An old request may not reflect later edits to an order or record.
Make a clear decision
- Confirm that the request is addressed to you and you understand the proposed action.
- Check the amount, recipient, conditions, or other details that matter.
- Add a short comment explaining your reasoning, especially when refusing the request.
- Choose Approve or Reject.
- Read the resulting status and decision history. If more approvers are required, your response may be recorded while the request remains waiting.
Viewing approvals and deciding them are separate permissions. Having decision permission is still not enough when the request names somebody else. A person cannot repeatedly vote on the same approval step.
Know how the policy changes the outcome
| Approval mode | What completes the decision |
|---|---|
| One named approver | The selected person's response |
| Any one of them | A response from one of the eligible approvers |
| Everyone must agree | The required approvals from the named group |
| Step by step | The configured levels completing in order |
Expiry handling is part of the policy. A request can approve, reject, or escalate when its deadline passes. Read the explanation on the request rather than assuming silence always means refusal.
Example: review a proposed exception
A configured message flow asks a supervisor to review a service exception. The request includes the customer, the requested change, and why normal handling was insufficient. The supervisor checks those details, records a decision, and the flow follows its configured outcome branch.
Keep that branch explicit. Approval records a decision; whether a refund, record update, notification, or another action follows depends on the process that requested it. Check the resulting business item when the actual action matters.
When a decision is unavailable
If the buttons are missing, check whether you are a named approver at the current step, have permission to decide, or already responded. Another person may have completed the request, or it may have expired while you were reading.
Refresh before retrying. For an unclear request, ask the requester to clarify rather than treating missing information as approval.
To connect decisions to customer conversations, start with the message-flow guide.
Make the requested decision specific
A useful request explains what will happen if approved: the affected record, the proposed change, any amount and the reason for the exception. “Approve customer request” leaves too much for the reviewer to reconstruct. “Approve the stated adjustment for service request SR-104” gives them a concrete starting point.
If the customer or amount changes while a request is waiting, compare the current business record with the submitted context. Do not assume the approval has silently adopted the new details. Follow your process for correcting or replacing the request before authorizing a materially different action.
For a new approval flow, test both approval and rejection, then check expiry behavior. Verify the resulting record or customer message in each case. A well-formed decision history is useful, but the next workflow step must still execute successfully.
Assign backup responsibility for requests that can arrive while the usual reviewer is away. Choose the approval mode and deadline around that operating reality rather than relying on someone to notice every request immediately.