> ## 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.
# Approvals and proposed changes
> Review the exact consequential change before authorising it.
Use Approvals to decide whether Kina's prepared work should change your store, send a customer-facing reply or affect another connected system. Each proposed Action sets out the change for review; Kina can research and draft before that decision.
## What to review
Read the target, the exact operation and the proposed before-and-after change. Check the evidence behind it, the relevant risk and whether a reversal is supported. Reject or revise a proposal that changes the wrong record or relies on an unsupported fact.
For a batch, review every edit. An approval should be bound to the version you saw. A later change to the proposal is not covered by your earlier decision.
## Approval and execution are different
Approval records your decision. Execution attempts the authorised effect. The receipt records the result, including partial or failed work. An approval badge alone is not proof that every record changed.
Your role may allow you to inspect a proposal without allowing you to approve it. A missing provider permission is also separate from approval: authorising a change does not grant BYOM an absent Shopify scope.
## Example
Kina drafts five improved product descriptions. You can read and refine all five. Before applying them, check the products and every field change. After execution, inspect the individual results; check any partial result before treating the batch as complete.
## Review a change in the interface
Open **Approvals** or the decision linked from HQ, Workspace or the relevant task. The same proposed change can be reached from several places; the review must still concern the same target and version.
The review shows **Before** and **After** where field changes are available, alongside the reason, risk and reversal information. **Approve** and **Reject** are decisions about that proposal. Read the confirmation text before submitting: some contexts combine approval and making the change, while other contexts record approval and then offer **Make the change**. A supported helpdesk operation can show **Send to your helpdesk** instead.
Do not infer the operation from a button alone. The confirmation should make clear which service is affected and whether the effect happens in that step. After an approval-only step, the view can say the change has not been made in the provider yet.
## Before you can approve
You need a role that can make the decision, a current proposal and the applicable permission. A higher-risk change may require an additional sign-in check. Some proposals require another approver; if the interface says a second approver is required, having drafted the work does not let you approve it yourself.
If the proposed work includes media, the exact attached version and its source must be available for review. An unavailable preview is a reason to stop, not to approve from a filename. Accepting creative work for editorial review is also distinct from approving its rights, publishing it or authorising spend.
## Worked example: approval with a narrower meaning
A fictional merchant reviews a prepared creative pack. Its copy and ordered versions are suitable, so an editorial review is accepted. That acceptance alone does not give permission to use an unlicensed image or publish an advertising campaign.
Before any external use, check the relevant rights and the separate effect being authorised. Check which effect the proposal authorises before accepting it.
For a simpler catalogue batch, suppose five descriptions are prepared but one includes an unsupported material claim. Revise that item before accepting the batch. Approval is not a request for Kina to decide which unseen edits you would probably accept.
## When approval is unavailable
| Situation | Useful next step |
| - | - |
| You can read but cannot decide | Ask the appropriate company approver to review the same proposal. |
| Source or proposal changed | Reopen the current version and check it again. |
| Preview cannot be loaded | Restore reviewable evidence or reject; do not approve unseen content. |
| Provider permission is missing | Resolve access in Integrations; approval cannot create that scope. |
| Result is uncertain | Use **Check status** where shown and inspect the receipt before repeating. |
Use **View receipt** after a recorded decision or result. The receipt keeps the detailed evidence needed to establish what was authorised and what completed.
Reviewed 2 October 2026.
## Related guides
* [Review a proposed change](/guides/review-a-change)
* [Receipts and undo](/product/receipts-undo)
* [Trust and control](/trust/overview)
## Related topics
- [Review a proposed change](/guides/review-a-change.md)
- [Receipts and undo](/product/receipts-undo.md)
- [HQ and Workspace](/product/hq-workspace.md)
- [Kina](/product/kina.md)
- [Customer Service](/product/customer-service.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.