Skip to main content
Review a change by checking the exact target and before-and-after proposal, then inspect its receipt after execution. This helps you approve the right fields and catch an incorrect claim or target before it reaches the connected service.
1

Open the proposed change

Use the decision link from the work record, HQ or Approvals. Confirm that it belongs to the expected company and task.
2

Check every affected record

Read the operation, product or other target, and every field being changed. For a batch, review the whole batch rather than a representative item.
3

Check the reason and risk

Verify source facts and policy. Read the reversal information. Ask for revisions if the proposal contains unsupported claims or an incorrect destination.
4

Make the decision

Approve only the version you have reviewed, or reject it. If your role cannot decide, use the appropriate company approver; do not try to bypass the control through conversation.
5

Read the receipt

Check which operations completed. Treat partial and uncertain outcomes explicitly. Resolve those before repeating work.

Example

A proposal updates a product’s title and description. The description is correct, but the title changes the model number. Reject or revise the proposal before approval; an otherwise useful draft is not a reason to accept an incorrect field.

If something changed during review

A newer product value or an edited proposal can invalidate the reviewed version. Reopen the current proposal and check it again. Earlier approval is not permission for unseen changes.

Before you start

Have the correct company, a current proposed change and access to the evidence behind it. You need an account permitted to decide; some changes require a second approver or an additional sign-in check. Do not ask a colleague to approve from a detached screenshot when they can inspect the current proposal itself.

Check what confirmation will do

The review uses Approve and Reject. In Kina, a supported confirmation can both approve and make the change. Elsewhere, approval can be followed by a separate Make the change control, or Send to your helpdesk for an eligible helpdesk operation. Before confirming, read what that particular step will do. If the proposal is only accepted for editorial review, that does not approve media rights, publication or campaign spend. If the change is approved but not made, the view can state that it has not been made in the provider yet. Use View receipt to inspect the detailed operation and result. If a request has an uncertain outcome, Check status can be offered instead of an immediate repeated execution. Follow that recovery path.

Worked review: three product descriptions

North Coast Goods has a batch covering three products. Two descriptions use verified materials and care facts. The third replaces “cotton blend” with “100% cotton”. Retain the blend description unless a verified source proves the exact composition. You can continue refining the draft internally without authorising an incorrect store change.

Finish the review with a result check

Your expected outcome is a recorded decision about the right version and, if the effect was requested and completed, a receipt for the correct provider operation. If one item fails after others complete, inspect why before submitting a fresh batch. If the source changed between review and execution, compare the new state. If an undo is offered, it is a separate effect with its own checks; after using it, read its result too. When sharing completion with a colleague, link the work and receipt rather than saying “approved” when you mean “made in the store”. Reviewed 2 October 2026.