Write down the workflow before choosing the tool
Name the event that starts the work, the source of truth, the decision rules, the intended change and the person who owns failures. Include volume, acceptable delay, permissions and whether a human must approve the result. A diagram with those details is more useful than starting with a request for an AI agent.
For example, tagging an order after a known condition is deterministic. Writing a product description from incomplete supplier notes involves uncertainty. The first can often follow fixed rules. The second needs a source-data policy, quality review and a publication decision. Combining them does not remove those different requirements.
Check native capabilities and existing apps first
Shopify Flow uses triggers, conditions and actions to automate work in a store and connected apps. Check whether the required trigger and action exist, including connectors from apps you already use. An existing application may already provide the interface, operating history and support needed for a routine workflow.
As checked in October 2026, Flow is available on Basic, Grow, Advanced and Plus. The Send HTTP Request action is available on Grow, Advanced and Plus; tasks created by custom partner apps require Plus. Plan and API usage limits matter. Verify the current documentation against the merchant's plan before promising an integration.
Representative example: tag a product for merchandising review when a supported product event meets a known condition. If the required event and action are available, a small Flow workflow may be enough. Confirm its behavior on an update as well as on creation, and check that it cannot repeatedly trigger itself.
Identify where a custom service is justified
Custom development becomes useful when the workflow needs an unavailable event or action, complex external data mapping, persistent job state, a specialized review interface or reliable coordination across systems. It can complement Flow: Flow can initiate a supported action while a service handles a long-running external operation.
Representative example: an ERP supplies product specifications, a catalog service prepares drafts, and a merchant approves selected fields before Shopify is updated. This requires agreement on product identifiers, conflicting edits, field ownership, credentials, retry behavior and approval state. It is not solved merely by connecting two API endpoints.
Give each piece of data an owner
Decide whether Shopify, a PIM, an ERP or another service controls each field. Establish how changes are reconciled when two systems update the same product. Preserve identifiers and source timestamps needed to investigate a failure. Collect only the data the workflow requires, with permissions and retention appropriate to its purpose.
For AI drafting, distinguish an approved product fact from an inference. Do not turn a photograph into an unsupported material, certification or compatibility claim. Route uncertain content for review. Deterministic validation can reject missing identifiers or malformed output; it cannot establish that persuasive prose is factually correct.
Design the failure path alongside the happy path
What happens if an API is unavailable, an event is repeated or a product changes during drafting? Define bounded retries, duplicate protection, an exception queue, alerts and the person who can safely resume a job. Keep a record of the intended change and actual outcome. Do not allow a retry to silently publish content that has lost approval.
Agree what a rollback can and cannot restore. A previous field value is useful only if restoring it will not overwrite newer merchant work. Test partial failures as well as successful batches, and make unresolved items visible to the operator.
Use Lumi as a concrete boundary example
Lumi is a Shopify catalog application built by Configurate. Its public workflow covers finding gaps, drafting supported content, comparing and editing, and publishing approved changes. Optional Maintain automation is a separate mode; merchants who require approval must select save as drafts. Those app controls are not a promise that every custom integration has already been built.
The lesson for custom work is to specify review and publication as separate operations. Evaluate representative products and difficult cases before expanding a workflow. A successful demo on one simple product does not establish reliable operation across a full catalog.
Compare ongoing ownership and cost
Compare app subscriptions, usage charges, AI generation costs, infrastructure, operator review time, monitoring and maintenance. Custom software also needs someone to manage API changes, access, incidents and documentation. Name that owner in the scope. Choose the smallest arrangement that meets the operating requirements and can be maintained by the merchant's team.