Shopify Flow：触发器、条件与动作的自动化
Shopify Flow 是官方称为电子商务自动化平台的应用：监听店铺内的事件，满足条件时自动执行一串动作，用来减少重复的后台操作，例如给订单打标签、发内部通知、隐藏库存为零的商品。它是商家侧的后台自动化，不是面向顾客的功能，不在店面页面里运行，也不是浏览器事件采集工具。Shopify Flow。
本库哪些内容依赖它
本文是 Flow 的权威来源，其他文章只写各自页面语境下的用法：
- 库存状态与到货通知：Product variant back in stock 触发器是商家侧信号，不是顾客订阅表单；
- 弃单率：Customer abandons checkout 触发器；
- Loyalty Rewards与会员计划页：自动化发放类方案，Flow 的适用性未核验；
- Web Pixels、浏览器采集、服务端 GTM 与标签网关：那里的「标签」是 GTM 标签，与 Flow 里给订单、客户、商品打的 Shopify 标签（tags）无关，也不是同一条数据链路；
- 隐私与同意、销售计划、库存与地点：相关触发器所在的领域。
核心对象与概念
| 对象 | 官方含义 | 备注 |
|---|---|---|
| Workflow | 由触发器、条件、动作组成的一条自动化 | 一个工作流同一时间只有 1 个触发器，条件与动作数量不限 |
| Trigger | 启动工作流的事件，如新订单 | 也可以是定时或应用提供的触发器 |
| Condition | 用 GraphQL Admin API 取值，按运算符与比较值判断 | 决定是否执行后续动作，可分支 |
| Action | 触发后执行的任务 | 官方分为店铺动作、通信动作、应用动作、高级动作 |
| Connector | 连接第三方应用，如 Slack、Google Sheets、Klaviyo、ShipStation | 并非所有应用都有 Flow 连接器 |
| Workflow run | 执行后生成的日志，记录做了什么 | 保留期见下 |
条件支持 Float、Integer、Date、String、Boolean、Enum 六种数据类型；字符串比较不区分大小写；运算符含等于、包含、开头结尾、列表的 at least one of、none of、all of，以及空值判断；AND 与 OR 可组合，空列表下 AND 为真、OR 为假；多个条件按从上到下的顺序处理。条件。
常见触发器
触发器索引按主题分组。下面只列本库相关的名称，非完整清单：
| 分组 | 触发器示例 |
|---|---|
| 商品与库存 | Product created、Product status updated、Product variant back in stock、Product variant out of stock、Product variant inventory quantity changed、Inventory item created |
| 订单 | Order created、Order paid、Order fulfilled、Order canceled、Order risk analyzed |
| 客户 | Customer created、Customer tags added、Customer abandons checkout、Customer subscribed to email marketing、Customer joined segment |
| 退货与退款 | Refund created、Return requested、Return approved、Return processed |
| 销售计划与订阅 | Selling plan group created、Subscription contract created、Subscription billing attempt failure |
| 其他 | Scheduled time、Metaobject entry created、Workflow error occurred |
Product variant back in stock 与本库到货通知所述一致：当变体库存从 0 或负数增加到 1 或以上时触发，不论来源是订单、手动调整还是第三方应用；商品须开启 Inventory tracked；草稿订单转成订单之前不影响可用库存；输出为 productVariant。触发器页。Scheduled time 触发器最短每 10 分钟运行一次，可按小时、日、周、月重复。
动作索引列出的类别有店铺修改（加标签、发布与取消发布商品、取消订单、捕获付款、删除客户与商品等）、数据获取（Get order data 等）、Metafield 管理、通信（含 Send HTTP request、Send Admin API request、Send internal email）、备注、履约，以及 Count、Sum、For each loop、Wait、Run code、Log output 等。动作需要触发器或 Get data 动作提供数据，缺少数据会报错。动作索引。
在哪里配置
- Shopify admin 的 Apps > Flow。应用可从 App Store 免费安装。
- 手动创建：Create workflow > 选触发器 > 加条件 > 在 True 或 False 分支加动作 > 命名 > Turn on workflow。创建。
- 模板创建：Create workflow > Browse templates > 选择并 Install > 编辑占位数据 > Turn on workflow。
- 运行记录：Apps > Flow 的 Recent runs。
- 管理：官方列出复制工作流、在店铺间复制、导出与导入、删除、版本历史；也可在 Shopify admin 对单个订单、草稿订单、客户或商品手动运行。管理。
与主题、Liquid 和 API 的连接
Flow 不属于主题。条件里的值来自 GraphQL Admin API 的字段；动作里用 {{ }} 插入触发器或前序步骤的数据。官方页没有说明这种变量语法与主题 Liquid 对象是否等价，本文不假设它们等价。需要调用外部系统时，官方动作里有 Send HTTP request 与 Send Admin API request，能力与限制以各动作页为准，本文未逐项核验。
可用范围与限制
以下核验于 2026-09-29。
套餐（概览、限制页）：Flow 可用于 Basic、Grow、Advanced、Plus 套餐；Send HTTP request 动作需要 Grow、Advanced 或 Plus；自定义合作伙伴应用任务仅 Plus；各店铺按其套餐的 API 限制获得不同的使用额度，具体额度官方页未给数值。
| 项目 | 官方数值 |
|---|---|
| 每店工作流数量 | 1000 个（含启用与未启用），超出后不能新建，直到降到限额以下 |
| 同一触发器上的启用工作流 | 超过 10 个会出现性能警告 |
| Wait 步骤 | 每个工作流最多 40 个，总等待最长 90 天 |
| 单个配置字段值 | 必须小于 50 kB |
| 工作流单个分段执行超时 | 36 小时 |
| Get data | 只能处理最多 100 项的列表；每个工作流最多取回 100 个对象 |
| For each 的列表 | 不得超过 1,000 项，超过则工作流失败；只能嵌套 1 层 For each；Repeat for each item 分支里不能放 Wait、Get data 与 Run code |
| 运行记录保留 | 完成后 14 天 |
Get data 的 100 与 For each 的 1,000 来自不同页面，指的是不同动作，不是矛盾。
自动化的风险
以下只写官方页所述：
- 并行与冲突：同一触发器上的多个工作流并行运行，可能互相冲突并超出 API 限制，官方建议合并成单个工作流以控制顺序。优化。
- Get data：必须写查询过滤条件，缺少过滤会返回全部资源或没有结果；过滤语法错误会使查询被整体忽略。
- 触发量是放大器：官方称触发器的量会成倍放大工作流里的任何问题，并给出 100 个商品乘以每分钟 1000 次执行的例子。
- Wait：编辑处于等待中的工作流后，恢复的运行使用更新后的版本；停用或删除工作流会取消所有等待中的运行；Wait 之前的 Get、Sum、Count 数据在 Wait 之后不可用，需要重新取。
- 时序：工作流「尽快运行」，时间不作保证；部分 GraphQL 字段异步填充，可能得到意外结果；官方建议用 Order risk analyzed 这类条件触发器代替 Order created。
- 标签：含标签条件的工作流在订单、商品或客户关联超过 250 个标签时可能失效。
- 营销邮件：向已拒绝营销的客户发送营销邮件会产生永久错误，官方建议先加条件核对营销同意；同意的定义见隐私与同意。
- 破坏性动作：动作索引包含 Delete customer、Delete product、Cancel order 等；Delete product 页说明它会删除商品及其全部变体与媒体，Delete customer 页说明删除客户，两页在读到的内容里没有永久性或可恢复性的提示。官方没有为批量变更给出专门警示，本文不据此推断，建议见下文的验证做法。
- 失败恢复：已取消的运行不能恢复，只能自动重新触发或手动重试；可用 Workflow error occurred 触发器搭建失败通知。监控。
验证一次
- 用测试模式先看逻辑：测试使用真实店铺数据，但不发送通知、不修改订单或商品，遇到第一个会修改数据的动作即停止；外部服务动作显示「无法模拟」，测试运行也不出现在 Recent runs。测试。
- 新工作流先用不含删除、取消的动作（如加一个测试标签或 Log output）在开发店或单条测试数据上运行，再换成正式动作。
- 以 Product variant back in stock 为例：用一个开启库存追踪的测试变体，把库存从 0 调到 1，检查 Recent runs 是否出现该运行，并核对
productVariant是否是预期变体。 - 同一触发器下同时启用两个工作流时，观察运行顺序与结果是否互相覆盖。
- 故意让一个动作缺少数据，确认错误提示与失败通知路径。
待继续完善
- 触发器与动作的逐项输出字段、Send HTTP request 与 Run code 的行为与限制；
- 员工使用 Flow 所需的权限；
- 各套餐的具体 API 使用额度；
- 与第三方应用连接器的能力核验；
- 会员、积分类自动化在 Flow 中的可行做法，见Loyalty Rewards的待核验项。