Corthex · WooCommerce / Diagnostic field guide
An order is missing. Find the failing link.
A chatbot can answer a policy question and still lack access to an order. Work through the connection chain before changing prompts or permissions.
- 01Pairing
- 02Tools
- 03Session
- 04Ownership
Check your own installation, then answer
Is this storefront paired to the intended assistant?
This tool follows your answers. It does not contact your shop or run an automated connection test.
Read the symptom
Four checks, in a useful order.
Use a known fictional order and a dedicated test customer. Change one condition at a time, record what happened and repeat the original question.
01The widget works, but the shop is not paired.
Start with the connection rather than the wording of the answer. A generic widget can load an assistant using its public Bot ID without establishing WooCommerce commerce access. In WordPress, verify that Corthex AI is active, WooCommerce is active and Connect to Corthex has paired this shop to the intended assistant. Then inspect the connection in Corthex. A similar assistant name in another workspace is not evidence of the correct pairing.
Re-test after pairing with a new storefront conversation. Do not paste a private REST key into the embed or the prompt. The native plugin route uses its scoped connection token; replacing that mechanism with an administrator credential changes the problem and creates unnecessary access. If a connection must be recreated, record the original environment and configuration first so the test remains understandable.
02The assistant has no suitable tool.
Knowledge search and commerce tools are different capabilities. Uploading an order-related document does not enable a live order lookup. Check the assistant’s relevant commerce tool settings and the actual tool result in the conversation. Ask a narrow question about the known order rather than a long multi-part request. That makes it easier to see whether a tool was available, whether it was called and whether the store returned useful data.
If the tool is intentionally disabled, the correct result is an honest limitation or the configured support route. Do not train the assistant to claim that it checked an order when no lookup happened. Use the existing commerce-tools Help article for the current controls; keep this diagnostic worksheet for deciding which part of the chain to examine next.
03The conversation lacks verified shopper identity.
Test on the storefront with the customer account that owns the order. A WordPress administrator, a Corthex workspace member and a store customer are different roles. Dashboard preview is useful for knowledge answers but does not prove the real customer session is present. Sign out and back in, confirm which customer is active, and repeat in a fresh browser session if you are comparing guest and account behavior.
An email address collected by a form cannot replace this authentication. Neither can a message that says “I am the owner.” If the visitor checked out as a guest or the order belongs to a different account, route them to the shop’s established verification process. A lack of private access is sometimes the expected outcome, not a defect to bypass.
04The record or requested field is unavailable.
Confirm the test order exists in the same environment and is attached to the test customer. Then distinguish an unavailable order from an unavailable field. The store might return an order state but no carrier tracking date. An imported or historical order can have a different association than the account you are using. Inspect the specific result rather than converting every missing detail into a broader permission request.
If the connector is unavailable, the assistant should not fill the gap with a delivery-policy paragraph presented as personal order status. Explain what could not be checked and give a usable next step. Keep a sanitized record of the failure and retry after the connection is restored. A successful second attempt does not erase the need to understand the first customer-facing response.
Make a report someone can reproduce
Collect conditions, not customer secrets.
A useful support report names the environment, version, selected assistant, enabled capability, test role and expected outcome. Add the exact question and a redacted tool outcome or error. Say which diagnostic step passed and which failed. A screenshot of a generic “not found” reply without the role or environment leaves the important distinction unresolved.
Do not include passwords, connector tokens, full private customer profiles or real payment details. Fictional test order aliases let you discuss ownership without publishing an actual customer’s purchase. Keep unredacted operational logs in your own controlled support process, rather than adding them to a public knowledge source.
- Example environment
- Staging shop · fictional test accounts
- Observed condition
- Customer B is signed in; order belongs to A
- Expected outcome
- No private order details; clear support route
- Evidence
- Question, enabled tools and redacted result; no credentials
Close the loop with a negative test.
After fixing the intended access, repeat the guest and other-customer tests. Otherwise a broad change can appear to solve “order not found” while weakening the very boundary the connector is meant to preserve. Include a deliberately disconnected connector and unavailable staff scenario in your final review. You are testing the quality of failure handling as well as the happy path.
Use the launch acceptance workbench
Recheck the own-order, guest and other-customer access scenarios after repairing the connection. Plan a staff fallback when access remains unavailable.