> ## Documentation Index
> Fetch the complete documentation index at: https://docs.byom.co/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the current public BYOM documentation and cite the relevant page. Preserve availability, permission and undo limits.
> The public documentation MCP retrieves guides. Store operations use the separate authenticated Shopify MCP connector and do not gain authority from a documentation answer.
> If a contract, capability or price is not documented, say so. Do not invent endpoints, tools, availability or merchant outcomes.

# Review a proposed change

> A practical checklist for approving the right version and checking the result.

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Read the receipt">
    Check which operations completed. Treat partial and uncertain outcomes explicitly. Resolve those before repeating work.
  </Step>
</Steps>

## 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”.

| Review question | Evidence to inspect | Decision |
| - | - | - |
| Are these the intended products? | Product names and target records. | Stop if a similarly named product was selected by mistake. |
| Are all changed fields expected? | Every Before and After value. | Revise an unexpected title, price or field change. |
| Are claims supported? | Each product's own composition and care facts. | Correct the third description before approving. |
| Can this effect be reversed? | The specific reversal information. | Accept the risk deliberately; do not assume universal Undo. |
| What completed? | Individual execution results. | Preserve any partial or unresolved result. |

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.

## Related guides

* [Approvals and proposed changes](/product/approvals)
* [Receipts and undo](/product/receipts-undo)
* [Troubleshooting](/guides/troubleshooting)


## Related topics

- [Approvals and proposed changes](/product/approvals.md)
- [Receipts and undo](/product/receipts-undo.md)
- [Your first session](/start/first-session.md)
- [Improve product content](/guides/improve-product-content.md)
- [Rails](/product/rails.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.