# Your own AI on Shopify, with a confirm step before every change | BYOM blog

URL: https://byom.co/blog/connect-your-ai-to-shopify-safely  
Markdown: https://byom.co/blog/connect-your-ai-to-shopify-safely.md  
Last updated: 2026-10-02

> The confirm before change pattern as banks and IT teams use it, what Shopify can and cannot undo natively, and how to run an approval step that stays a check.

By Kina (Checked by the BYOM team). Published 2026-09-18. 9 minute read. Series: In control.

## Key takeaways

- Shopify keeps no native version history for product fields, so the old text is gone once a new version is saved.
- Shopify Flow offers more than 100 actions, including Delete product and Cancel order, and none of them is a step that asks a person to approve.
- ITIL 4 sorts changes into standard, normal and emergency, so only the changes that carry risk need a full approval.

You already ask an AI assistant to draft product copy, tidy collection descriptions and plan a campaign. The slow part is moving the result into Shopify, field by field. Connecting the assistant removes that slow part, and it also removes the pause in which you would have noticed a mistake.

The answer people have used for a long time, in banks and in IT teams, is a confirm step: one party prepares a change, another approves it, and a record is kept. This post looks at where that pattern comes from, what Shopify does and does not give you natively, and how to run an approval so that it stays a real check.

## Where the pattern comes from

Separation of duties is the name for the idea. Wikipedia defines it as the concept of having more than one person required to complete a task, an administrative control that prevents fraud, sabotage, theft and security breaches. The classic example is the requirement of two signatures on a cheque. In accounting systems, companies separate incompatible roles, such as stopping the same person from both receiving payments and approving write offs.

Payments teams call their version maker and checker. A maker checker payment, in one payments provider's words, separates the person who prepares a payment from the person who reviews and authorises it, which creates a checkpoint before funds are released. The same source says the process reduces duplicate transfers, incorrect beneficiaries and fraud, and creates accountability through documented records of who prepared and approved each transaction.

Two things in those descriptions carry over to a shop. The approver is a different party from the preparer, and the record names both. When an AI assistant prepares a price change and you approve it, the arrangement has the right shape: the assistant is the maker and you are the checker. The risk is that the checker stops checking.

Banks add a point worth copying. The maker does not hold the power to release funds, and the checker does not prepare the payment. Each role is deliberately limited. If one person could do both, the second signature would be a formality. For a shop, that means a tool that prepares changes should not also hold the authority to apply them without you.

## How IT teams sort changes by risk

IT service management has a mature vocabulary for this. Under ITIL 4, the practice is called change enablement, defined as ensuring that changes to IT services and infrastructure are implemented in a way that minimises risk and disruption while maximising value. It sorts changes into three types.

| Type | What ITIL 4 says | A shop example |
| --- | --- | --- |
| Standard | Pre approved, low risk, repeatable | Adding a tag, fixing a typo |
| Normal | Needs risk assessment and approval based on urgency, complexity and impact | Rewriting a description, changing a price |
| Emergency | Time sensitive, expedited, reviewed after the event | Taking a mispriced product offline |

The useful idea is proportion. ITIL 4 moved away from sending every change to a central board. Authority for approving a change can be delegated to teams, automated in a pipeline, or assigned to business stakeholders depending on the level of risk. The practice shifted from gatekeeping towards facilitating faster releases while keeping appropriate risk management.

ITIL 4 also describes standard changes as typically automated or documented in runbooks, meaning the steps are written down and the same every time. That is the right test for what can skip the full approval. If you can write the change as a short recipe, and the worst outcome is small and easy to reverse, it is a candidate. If you cannot write it down, or the worst outcome is a wrong price on a best seller, it belongs in the group that needs your approval.

For a merchant the lesson is to avoid two failures. Asking for approval on every trivial edit trains you to click through, which empties the check of meaning. Asking for approval on nothing removes the check where it matters. Decide which of your changes are standard and which are normal, and put the full confirm step on the second group.

Emergency changes deserve a note of their own. ITIL 4 allows them to be expedited, with assessment and authorisation speeded up and a full review after the event. A mispriced product that is selling at a loss is an emergency in a shop too. Taking it offline first and discussing it afterwards is reasonable, as long as the review happens. The lesson from IT is that the fast route still leaves a record.

## What Shopify gives you natively

Shopify Flow is the obvious tool for automating work, and its documented list of actions is long: more than 100, including Update product status, Publish product, Delete product, Cancel order, Capture payment and Wait. It also includes Send internal email. What the list does not include is a step that pauses a workflow until a person approves it. A Flow can notify you, and it can wait for a set time, but nothing in it asks a named person to say yes before the next step runs.

The bulk editor has gained a preview. Shopify's changelog for 11 December 2025 says the bulk inventory editor now displays original and new values side by side, with increases in green and decreases in red, making it clear that you are replacing quantities and not adjusting them. It also detects conflicts, alerting you if the inventory changes while you are editing and offering to save suggested values, use your entered numbers or discard the changes. That is a confirm step with a good before and after view, and Shopify added it to prevent accidental overwrites.

Undoing is the weaker side. A Shopify community thread asks how to revert an accidental product description edit. The answers say there is no native version history for product fields. The one native option offered is the undo shortcut in the editor before you save. A partner who sells a bulk editing app writes that there is not an easy way to revert an edit with the base Shopify program, and a later answer says the old description is gone from the admin the moment the new one is stored, suggesting the Wayback Machine or Google's cache as a way to recover old text. Those routes only work if the page was captured.

Third party apps that track product changes exist, as the thread notes, but they record versions only from the time you install them. Nothing recovers changes made earlier.

There is one more native limit to know about. Flow includes actions such as Cancel order and Delete product, and the list offers no matching action to reverse them. If you build a workflow that does either of those, treat it as a change that bypasses the confirm step, and decide deliberately whether you are comfortable with that.

The store activity log does not close the gap. It is read only and shows when and by whom, including apps, an action was taken, such as deleting products or changing settings. It shows a maximum of 250 results, events cannot be expanded and the log cannot be exported. It tells you that a product changed. It does not hold what the product said before.

> **What this means.** A bulk change to product text, once saved, has no native way back. The before copy has to be taken by you, ahead of time, or by a tool that records it.

## Building a confirm step that stays a check

OWASP's guidance on excessive agency for AI systems names excessive autonomy, meaning actions executed without human verification, as one of three root causes of damage. Its prevention advice includes requiring human approval for high impact operations, running actions in the context of the individual user, and monitoring logs to detect and contain problems. The pattern in this post is a working version of that advice.

The EU AI Act's article on human oversight is more specific about the weak point. It says the people overseeing an AI system must remain aware of the possible tendency of automatically relying or over relying on the output. That is the checker who stops checking. The design answer is to make each approval ask something of you.

- Show the change as a before and after, in the product the way you will see it, not as a summary. Shopify's bulk editor preview uses the same principle.
- Make the approver and the preparer different. If the assistant proposes and you confirm, the pattern holds. If the assistant can also confirm, it does not.
- Let proposals expire. An approval is a statement about the store as it was when you looked, and a proposal that sits for a week describes a store that no longer exists.
- Record who approved what and when, and keep the record outside the assistant.
- Keep a copy of what was there before, so a change can be put back. Shopify will not do this for you.

Take a normal week. On Monday the assistant proposes new descriptions for twelve products. You read each against the old text, which you copied into a spreadsheet first, and approve ten. On Wednesday it proposes a price change on a range after a supplier increase. You check the figures against your margin sheet, approve it, and note the old prices. On Friday you find one description from Monday reads badly. Because you kept the old copy, putting it back takes a minute. Without the copy, the only route is to rewrite it.

The habit that makes this work is taking the before copy at the moment you approve, not afterwards. Afterwards the information has already gone, and Shopify has no history to fetch it from.

Put the full step on the changes that can hurt: prices, discounts, publishing and unpublishing, deletions and anything that touches customers. Let the standard changes through with a lighter touch, in the ITIL sense, and review them in batches. If you have a team, make sure the person who approves a price change is not the person who asked for it, which is the cheque with two signatures.

## Running it in a small team

Many Shopify merchants are one or two people, and separation of duties assumes more. If you are the only person in the business, you are both maker and checker, and what you can still do is put time between the two roles. Let the assistant draft today and approve tomorrow. Read the proposal on a different screen, or aloud. Delay and a change of context catch a good share of the mistakes that a quick click does not.

If you have a second person, give them the approver role for the changes that matter most and take it yourself for the rest. Shopify's staff permissions let you set access at a granular level, so the person who approves can be a different account from the person who edits. Where two roles are not practical, the GOV.UK 10 steps guidance suggests a substitute: monitor user activity, especially access to sensitive information and privileged actions, and review the logs.

## Questions to put to any connected tool

- Does every write wait for a person, and can the tool ever confirm its own proposal?
- Do I see the exact before and after, or only a description of the change?
- How long does a proposal stay open, and what happens to a stale one?
- Where is the record of who approved what, and can I read it without the tool?
- How do I put a change back, and does that need my approval too?

A tool that answers all five clearly is behaving like a maker. One that cannot answer them is asking you to trust it without a checker. Bring the same questions to a human contractor or a new app, since the pattern applies to anyone who can change your store.

## A record, and undo

Your assistant proposes and you decide. Unconfirmed proposals expire quickly, so nothing lingers waiting to be applied by mistake.

Every confirmed change is recorded: what changed, on which products, and whether Shopify accepted it. Product changes can be undone through the same confirm step.

The product page: [See the Shopify app](https://byom.co/shopify-app).

## Sources

- [Wikipedia, separation of duties](https://en.wikipedia.org/wiki/Separation_of_duties)
- [PhotonPay, maker checker payment explained](https://www.photonpay.com/hk/blog/article/maker-checker-payment)
- [ITSM.tools, change enablement in ITIL 4](https://itsm.tools/change-enablement/)
- [Shopify Help Centre, Shopify Flow actions reference, 2026](https://help.shopify.com/en/manual/shopify-flow/reference/actions)
- [Shopify changelog, prevent accidental inventory overwrite in bulk editor, December 2025](https://changelog.shopify.com/posts/prevent-accidental-inventory-overwrite-in-bulk-editor)
- [Shopify Community, can I revert an accidental product description edit, 2026](https://community.shopify.com/t/can-i-revert-an-accidental-product-description-edit/58646)
- [Shopify Help Centre, store activity log, 2026](https://help.shopify.com/en/manual/shopify-admin/activity-logs)
- [OWASP GenAI Security Project, LLM06 excessive agency, 2025](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- [EU AI Act, Article 14, human oversight](https://artificialintelligenceact.eu/article/14/)
- [GOV.UK, 10 steps to cyber security, managing user privileges](https://www.gov.uk/government/publications/10-steps-to-cyber-security-advice-sheets/10-steps-managing-user-privileges--11)
- [Shopify Help Centre, staff permissions, 2026](https://help.shopify.com/en/manual/your-account/staff-accounts/staff-permissions)