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

# Troubleshooting

> Identify whether the next step is an access fix, a revised proposal or a result check.

Start troubleshooting by identifying the stage that stopped: source access, preparation, approval or execution. That tells you whether to fix access, revise the work or check a result before trying again.

| What you see | What to check next |
| - | - |
| No store evidence | Correct company, connection state and provider permissions. |
| Unavailable Readout | The named missing source and requested date range. |
| Unsupported draft claim | Source facts and brand guidance; revise before approval. |
| Approval control unavailable | Your role and the proposal's current state. |
| Expired or changed proposal | Prepare or reopen the current version and review again. |
| Partial execution | Individual results in the receipt. |
| Timeout or uncertain result | Receipt and provider state before retrying. |
| MCP authentication failure | Reconnect through the supported consent flow. |

## Example

Kina can read a product but cannot prepare a supported update. Check the change capability and provider permission before treating this as an approval problem. For an approved change, inspect the receipt to establish whether it finished.

## Avoid duplicate effects

Do not repeatedly resubmit a change while its result is uncertain. A request timeout does not prove the provider rejected it. Establish the current result first, then use the supported recovery path.

## Diagnose by the last verified stage

Start with the work reference, the time and the latest visible result. Ask what was last confirmed: the source read, draft preparation, approval, execution or outcome measurement. This narrows the remedy and avoids restarting completed work.

A useful sequence is:

1. Confirm the company and intended record.
2. Check the relevant integration and operation permission.
3. Open the current work or proposed change rather than an old screenshot.
4. Read its latest status and receipt.
5. Resolve the stated cause before another attempt.

## Connection or permission problem

Open Integrations and the relevant service detail. Inspect **What Kina can do** and, where needed, **Access and scopes**. Use **Check connection** for current health and permissions. Use the supported reconnect flow if authorisation is expired.

If products can be read but orders cannot, investigate the order permission separately. Do not disconnect a working catalogue link because another capability is missing. A connection can also be degraded: “connected” and “usable for this operation” are different facts.

## Approval or execution problem

Open the proposed change in Approvals. If no decision control is offered, inspect the role, current proposal state and any need for a second approver. If a source or attached version changed, review the current evidence.

Read whether the recorded approval was followed by making the change. A view saying it has not been made in the provider yet is not an execution failure; the effect may still be a separate step. If the result is uncertain, use **Check status** where offered and inspect **View receipt** before retrying.

## Data or interpretation problem

For an unavailable Readout, inspect the named source and dates. For a partial figure, identify the omitted source or records. A real zero does not need the same recovery as missing evidence. If the calculation seems wrong, inspect the inputs, unit and expression before changing presentation.

For a Brand Memory answer using an old fact, search the supporting passage and check the current source. **Refresh** and **Read everything again** have different scope; a complete reread is not the first remedy for every single missing result.

## Worked example: timeout after a product change

North Coast Goods approves a description update. The response times out. Submitting the same change again immediately would assume that the provider rejected it, which the timeout does not prove.

Open the change and check its status and receipt. If the operation completed, inspect the product rather than repeating it. If it remains unresolved, follow the supported recovery or report the work reference. If a newer edit now exists, compare it before proposing another change.

## Escalate with useful evidence

Include the page, work reference, approximate time, visible message and the last step that completed. Explain what you expected. Redact screenshots. Exclude passwords, bearer tokens, full customer data and provider credentials. A precise work reference lets support investigate without a broad data dump.

Reviewed 2 October 2026.

## Related guides

* [Integrations](/product/connections)
* [Receipts and undo](/product/receipts-undo)
* [Errors, limits and retries](/developers/errors-and-limits)


## Related topics

- [Review a proposed change](/guides/review-a-change.md)
- [Integrations](/product/connections.md)
- [Kina](/product/kina.md)
- [Documentation updates](/changelog.md)
- [Availability and access](/reference/availability.md)


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