How to Use Shopify Magic and Sidekick: A Cross-Border AI Workflow and Review Checklist

Bottom line: use Shopify Magic as a drafting layer that is constrained by merchant-supplied product facts, and use Sidekick as an assistant inside the Shopify admin; put every suggestion or proposed task into a review state before anyone applies it. This guide is for cross-border merchants, content owners, and store administrators who need a repeatable approval trail. It is not a guide to unattended payments, refunds, purchasing, Storefront MCP, or Sidekick App Extension development. Capability and interface statements are last verified 2026-08-30; account, plan, language, permission, and availability differences must be re-tested against the current official documentation before publication.

Bottom line: treat AI output as a reviewable work item

The useful unit is not a prompt; it is a controlled change

An AI prompt is only the beginning of a workflow. The useful unit for a merchant is a work item with a defined input, a bounded output, an owner, a decision, and a recovery point. A practical state model is: facts confirmed → draft or answer pending review → merchant approved → applied and logged. A fluent paragraph is not evidence that the first state was satisfied, and an assistant response is not proof that the last state occurred.

Shopify’s official AI material warns that AI output can be wrong. That warning should change the operating design: reviewers should be able to see what the tool was asked, which facts were supplied, what it produced, what was rejected, and what was actually applied. The Shopify AI-powered tools guidance is the governing first-party reference for this caution, last verified 2026-08-30.

Who should use this workflow

This workflow is intended for a team that has at least one person who owns product facts, one person who can review brand and market wording, and one person who can approve a change in the Shopify admin. One person may hold all three roles in a small store, but the record should still distinguish drafting, review, and approval.

It is especially useful when a team works across languages or markets and wants to avoid carrying a claim from one product version, market, or policy into another. It is not a substitute for merchant judgment about product truth, customer data, prices, inventory, payment status, returns, or local legal requirements.

What “good” looks like

Good use is narrow enough to test. A request such as “draft candidate copy using only this approved fact card; mark anything missing as needs merchant review; do not add delivery, certification, health, return, price, or inventory claims” has a visible stopping rule. “Make this more persuasive” does not.

Scope and non-goals for a cross-border Shopify team

This page covers admin tool use

The single intent of this page is operational: how to use Shopify Magic and Sidekick in a merchant workflow, and how to decide whether a result is safe to apply. The focus is the handoff from input facts to human review, not a promise about universal feature availability.

Magic belongs here as a generation or rewrite aid when the current Shopify admin surface presents that capability. Sidekick belongs here as an assistant working in the Shopify admin, where its answer or a supported task still has to be interpreted in context and reviewed before a change is applied. The official Sidekick documentation is the first-party reference for its current behavior, last verified 2026-08-30.

This page deliberately excludes two development topics

This guide does not provide Storefront MCP endpoints, cart or checkout implementation, consumer-facing agent architecture, or code. It also does not teach how to develop a Sidekick App Extension, declare extension tools, or design extension permissions. The latter is a separate development intent; the official extension page is used only to keep that boundary clear, not to expand this article into implementation guidance.

Three words every reviewer should distinguish

Use “suggestion” for a generated candidate, “preview” for a result whose text, target, or proposed action can be inspected, and “apply” for the merchant-approved operation that changes a current admin object. If a tool gives a suggestion without a usable preview, stop. If there is a preview without a clear target object, stop. If an action can be applied but the approver and recovery point are missing, it is not an auditable release.

Magic and Sidekick: different jobs, shared review gates

Magic is a fact-constrained drafting layer

When the current admin surface offers a Shopify Magic generation or rewrite action, use it to prepare a candidate from an approved fact card. The fact card may contain a product name, variant label, size, material, approved claims, target language, market, and prohibited wording. It should also say when a field is unknown. Unknown is a valid input state; it should not be silently converted into a number or promise.

The review question is not “does this sound like a brand?” It is “which supplied fact supports each sentence, and is the strength of the wording no stronger than the evidence?” A phrase such as “suitable for everyday wear” must not become a guarantee about comfort or allergies without a merchant-approved source. A configured market must not become a promise of worldwide two-day delivery. The Shopify Magic documentation describes the current Magic context, last verified 2026-08-30; if the relevant action is absent from the account, follow the current official instructions and use a manual path.

Sidekick is an admin-context question and task layer

Sidekick works in the merchant admin. It can answer questions or assist with supported tasks in the context available to the store, but the existence of an answer is not the same as a verified store record. Ask it to state the object, scope, time range, basis, and intended action before relying on the result.

When a result involves a proposed admin change, the merchant should review it before applying it. That review must identify the object, the scope of the proposed change, the permission context, and the recovery point. A task path that is available in one account or interface should not be written as a permanent guarantee for every plan, language, or store. Those availability facts are last verified 2026-08-30 and require current-documentation re-testing.

The shared rule is human accountability

Magic and Sidekick can reduce drafting or navigation effort, but neither becomes the source of truth merely by producing a confident sentence. The merchant remains responsible for deciding whether a product statement, market instruction, order-related answer, or policy reference is correct and appropriate to apply. Use the AI best practices guidance as the official reminder to use AI output carefully, last verified 2026-08-30.

Capability, data, and approval matrix

This matrix is the page-specific evidence artifact. It describes a controlled operating pattern, not a claim that every account exposes every action. Capability-related statements are last verified 2026-08-30.

Prerequisites: build a small fact pack before you ask

Use fields that can be checked, not a long background paragraph

A fact pack should be a review artifact. Each field needs a value or an explicit unknown state, a source or owner, a market or language scope, a version, and a last-checked date. Product name, variant, size, material, price, inventory, delivery, and return wording should not be filled in merely to make an AI answer appear complete. If a field is absent, the output should remain pending merchant confirmation.

Separate the pack into three layers. Hard facts are fields that must not change during rewriting, such as an approved product name, variant label, or confirmed size. Flexible language includes tone, sentence order, and level of detail. Prohibited automatic additions include certification, health outcomes, absolute promises, shipping timing, return terms, payment status, and inventory guarantees unless the merchant has supplied and approved the specific claim.

Add market and language labels

Every candidate should carry a target language and market label. The label is a guard against copying a delivery phrase, currency statement, return instruction, or policy reference from one market into another. If the team has not confirmed how a claim varies by market, the safe output is a pending question, not a guessed translation or universal promise.

Keep the input minimal and the record sufficient

Do not paste a full customer conversation, complete order, or internal credential into a prompt when a product ID, field name, and version marker are enough for review. Keep the minimum evidence needed to reproduce the decision: date and time zone, tool, prompt or question, fact-pack version, output or screenshot, target object, reviewer decision, approver, application time, and recovery location.

The official AI guidance should be consulted for current usage expectations, last verified 2026-08-30. This article does not turn that guidance into a regional legal conclusion. Store-specific privacy settings, consent, retention, access, and deletion requirements remain merchant responsibilities to confirm with appropriate advice.

A repeatable Shopify Magic workflow

Step 1: define the task and a stop condition

Write a task that can be checked. For example: “Create one candidate English description from the supplied facts only. Mark missing fields as needs merchant review. Do not add delivery, certification, health, return, price, or inventory claims. Do not write to the admin.” The stop conditions are as important as the positive request: stop on a missing field, a new market claim, a changed number, an invisible target, or an unavailable comparison view.

Step 2: provide the smallest useful fact card

Provide the approved fields and explicitly label what is unknown. Do not mix old articles, customer anecdotes, or unverified sales claims with the current product facts. State the target language and market instead of asking the tool to infer them. A smaller input is easier to compare sentence by sentence and makes an unsupported addition easier to flag.

Step 3: preserve the original before generating

Save the current draft before the generation step. Save the candidate separately, assign an output version, and number its sentences for review. If several candidates are produced, record which one was selected and why. Never mark the whole output approved when the merchant only adopts one sentence.

Step 4: run four review passes

First review facts: name, variant, size, material, market, and language. Second review risk: absolute words, certification, health, delivery, return, price, inventory, or payment claims. Third review brand: prohibited words, approved tone, and whether the translation preserves meaning. Fourth review release: target object, permission context, version, approver, and recovery point.

Step 5: approve, reject, or hand-edit explicitly

An approval record should identify the candidate version, exact object, approver, and time. A rejection record should state why, such as “unsupported delivery timing,” “material does not match the fact card,” or “market scope is too broad.” If the result is useful but not fully reliable, edit it manually and record the final text. “The AI checked it” is not an acceptable substitute for a decision record.

A Sidekick workflow from question to proposed change

Start with scope, not execution

Ask Sidekick to restate the store, object, time range, relevant basis, and intended action. If the answer is not grounded enough to check, narrow the question or return to an admin record. A broad request creates a broad review surface; split it into small units that can be approved independently.

Inspect the proposed target

If the current interface shows a supported task or proposed change, identify exactly which product, draft, policy, market, or other admin object is in scope. Confirm whether the result is only an explanation, a draft, or a change that could affect an admin state. If several objects are bundled without a clear diff or stop option, pause and use a manual path.

Apply only after merchant review

Applying is the responsibility boundary, not a courtesy click. Before applying, the record must include the target object, action scope, source or basis, reviewer, approver, and recovery point. A Sidekick answer cannot grant permission to complete a payment, issue a refund, purchase stock, change a price, or make a fraud decision. Those high-impact choices stay with the merchant and the relevant operational record.

Record anomalies instead of hiding them

Keep the original answer when it is stale, overconfident, aimed at the wrong object, missing a basis, or unclear about side effects. Use a concise label such as missing fact, market mismatch, unclear permission, unclear target, unstated side effect, or no recovery path. Then decide whether to narrow the request, update the fact pack, switch to a manual check, or wait for a current documentation review.

Review example: release one product description through the gate

The test fixture is deliberately not a customer case

The following is a reproducible runbook/test scenario, not a customer story and not a Shopify case study. In a non-production test store, create a draft product fixture called DEMO-PENDANT-01. The fact card contains only: product name Demo Pendant; size 30 mm; and a material field that says “use the current merchant-approved fact-card value.” It contains no shipping promise, certification, allergy claim, return period, price, or inventory quantity. The requested output language is English.

The test instruction is: “Use only visible fact-card fields. Mark unknown fields as needs merchant review. Do not add shipping, certification, health, return, price, or inventory claims. Return a candidate draft; do not write to the admin.” The instruction narrows the work, but it does not make the result automatically correct.

Compare every sentence to the input

To test whether review is real rather than ceremonial, the fixture injects four unsupported claims into a candidate output. One correct sentence does not approve the other sentences.

Sign the review, not the whole model output

A complete record contains case_id=10073-demo-01, non-production environment, fact-pack version, output version, sentence-level decisions, reviewer, approver, date 2026-08-30, adopted text, rejected text, and rejection reasons. If one person holds every role, the record should still say, “I approved candidate version X and only the listed sentences,” rather than “AI output approved.”

The point of the example is to prove that the gate can catch unsupported material, certification, shipping, return, and inventory claims. If the test proves only that the sentence sounds polished, it has failed its purpose.

Failure rehearsal and rollback runbook

Failure condition: a missing claim is repeated as fact

Scenario: Magic produces “worldwide two-day delivery” even though the fact card has no delivery field. A later Sidekick question repeats that sentence with a confident tone. This is an intentionally constructed failure rehearsal, not a customer incident. The goal is to show that the team can stop the ungrounded claim before application and return to the last human-confirmed draft.

Rehearsal steps

1. In a non-production test store, save the original draft and fact-pack version. Record the tool, operator, time zone, and output version.
2. Run the narrow Magic request with an unknown delivery field. Confirm that the result is treated as a candidate. If no usable draft or preview state exists, record a failure signal and stop.
3. Ask a reviewer to map “worldwide two-day delivery” to a supplied fact. The correct review answer is “no supporting fact,” not a replacement delivery number.
4. Ask Sidekick to explain the basis of the sentence without asking it to edit the product. If the explanation still treats it as confirmed, preserve the answer and label missing fact.
5. Reject the candidate, remove the unapproved sentence from the test draft, and restore the saved human-confirmed version. If a rerun is attempted, narrow the prompt or hand-edit the copy.
6. Have the merchant owner sign the final draft and record the recovery point, adopted text, rejected text, and whether the fact card needs an update. Missing evidence means the rehearsal is not passed.

Trigger conditions for rollback or human takeover

Trigger rollback or manual takeover when output adds an unsupported number, timing, certification, health, return, price, payment, or inventory assertion; when the target is unclear; when a diff is unavailable; when no approver is identifiable; when the tool implies unattended completion of a high-impact action; when the original cannot be found; or when the current interface no longer matches the documented review path. The order is: pause, preserve evidence, reject the unapproved result, restore the last human-confirmed version, record the reason, and only then decide whether to rerun.

Pass criteria

The tool does not have to be error-free for the control to pass. The error must be detectable, the output must be isolatable, the reviewer must be able to state the rejection basis, the final text must use approved fields only, the approver and time must be traceable, and the test must not touch production data. If one condition fails, keep the manual workflow and mark the tool path pending repair or current-documentation review.

Acceptance checklist and monitoring

Content and fact acceptance

• [ ] Every product name, variant, size, material, market, and language claim maps to the current fact pack.
• [ ] Unknown fields were not turned into numbers, guarantees, certifications, effects, delivery times, or policy promises.
• [ ] The adopted text is recorded separately from the rejected candidate text.
• [ ] The wording does not promise an unsupported growth rate, ranking result, or AI-search citation.
• [ ] The reviewer checked the strength of each claim, not only grammar and tone.

Permission and side-effect acceptance

• [ ] Operator, reviewer, and approver are identifiable, even if they are the same person.
• [ ] Sidekick answers identify the relevant store, object, and time range; proposed changes have an inspectable target and scope.
• [ ] No AI result is treated as authorization for automatic payment, refund, purchasing, fraud judgment, or inventory commitment.
• [ ] The prompt uses only the minimum customer or operational data needed for the test.
• [ ] The original version and recovery path were saved before any application step.

Post-release sampling

After a page or draft is released, sample more than one language, market, and variant context. Check that the visible copy still matches the approved version and that a later tool run has not expanded the claim. Re-check when the product facts, policy, market setup, or admin AI surface changes. A 7-day and 28-day governance review can record factual errors, manual takeover count, support feedback, and recovery events; those observations are controls, not promises of growth.

If an error appears, isolate the affected draft or page first. Decide whether the root cause was an outdated fact pack, an over-broad prompt, unclear permissions, a missing review state, or a product-surface change. Do not repair this page by automatically changing or redirecting the other articles in the template batch.

Privacy, permissions, price, and inventory boundaries

Privacy is a data-minimisation question

The review trail should be sufficient to reproduce the decision without becoming a second customer database. Use IDs, field names, version markers, and result labels where possible. Do not paste names, addresses, full orders, payment details, or internal credentials into a prompt when they are not needed. Store-specific privacy settings, consent, opt-out, retention, access, and deletion practices need merchant confirmation and appropriate professional review; this page does not give regional legal advice.

Permission is not the same as correctness

A user may be able to see a tool or object and still need to verify whether the proposed result is correct. Review the current account context, target object, action scope, and visible approval path. If permission or scope is unclear, stop rather than using repeated prompts to force a more certain answer.

Price, payment, returns, and inventory remain operational records

AI-generated text is not a live price, stock, payment, refund, or return-policy record. If a user asks “is this available now?”, “what will this market pay?”, “will it arrive by a certain date?”, or “can this order be refunded?”, route the question to the current merchant record and a human decision. Do not let a polished answer create a transaction or policy promise.

Escalate high-impact requests

Escalate when a request contains customer data, payment or refund status, an order anomaly, price or inventory change, a market-policy conflict, a certification or health claim, unclear permission, or an uninspectable change scope. Human takeover is a control, not a failure. Record the reason and decide later whether a better fact pack or a narrower task can safely support another test.

Internal links within the Shopify AI topic hub

Decision context comes before tool operation

Teams that have not selected a responsible AI pilot should read AI cross-border commerce boundaries and implementation route. That article handles prioritisation and human RACI; this one handles the operational review gate after Magic or Sidekick has been selected. The relationship is sequential, not canonical duplication.

Development intent has its own page

Readers who actually need to build a Sidekick application extension should continue to Sidekick AI App Extension tools, permissions, and security strategy. This page only says that extension development is out of scope; it does not repeat extension declarations, permission implementation, or error-handling examples.

Roadmap and evidence governance are adjacent, not interchangeable

For weekly milestones, owners, exit criteria, and a broader rollout sequence, use the 90-day Shopify AI commerce roadmap. For claim-to-source mapping, review dates, evidence chains, and withdrawal rules, use Shopify AI content governance and evidence review. These links create a hub path while preserving separate search intents, acceptance artifacts, and rollback boundaries.

Frequently asked questions

FAQ 1 — What is the difference between Shopify Magic and Sidekick?

In this workflow, Magic is the drafting or rewriting layer when a current Shopify admin surface exposes that action. Sidekick is the assistant working in the merchant admin for questions and supported tasks. Neither is the source of truth, and neither removes the need for merchant review. Capabilities and availability are last verified 2026-08-30 and must be checked in the current account and documentation.

FAQ 2 — Does AI-generated product or marketing copy need human review?

Yes. The official Shopify material warns that AI output can be wrong. Reviewers should map each sentence to an approved fact, check market and language scope, remove unsupported claims, and record the adopted version. Without a usable preview, target object, and approval record, the output should remain pending.

FAQ 3 — Can Sidekick directly change a Shopify store?

Do not treat it as an unconditional direct-write system. The available task scope, account context, permissions, and current interface matter. When a proposed change is shown, the merchant should review it before applying it. If the target, diff, stop condition, or recovery path is unclear, pause and use a manual path; re-test against the current official documentation.

FAQ 4 — What should I do if Magic invents a shipping or certification claim?

Reject the sentence and do not replace it with another unsupported number. Save the output and fact-pack version, label the missing source, restore the last human-confirmed draft, and either update the fact pack, narrow the prompt, or edit manually. The procedure is a failure rehearsal and rollback runbook, not a customer case.

FAQ 5 — Can customer, price, or inventory data be pasted into a prompt?

Use only the minimum data needed for the task and verify the store’s privacy and permission configuration. Avoid unnecessary personal information, payment details, complete orders, and credentials. AI output cannot replace the current price, inventory, payment, refund, or return record; high-impact questions should be escalated to a human and logged with enough evidence for review.

Sources and last verified date

The following first-party sources are the only official references used for the tool facts in this draft. Each was checked on last verified 2026-08-30:

• Shopify AI-powered tools — overall AI-tool boundary, the possibility of incorrect output, and the need for careful merchant review.
• Shopify Magic — current Magic context and official usage guidance.
• Sidekick — Sidekick’s merchant-admin context and review-before-application boundary.
• AI best practices — official caution and review practices for AI output.

The Sidekick App Extensions documentation is intentionally not used as an implementation source here; it only marks the separate extension-development boundary. If a future release changes an entry point, task scope, permission behavior, or review interaction, update this page from the current official documentation and a non-production test before publishing.