Triggering workflows when fields change

Workflow Companion can start Shopify Flow workflows whenever important data on orders, draft orders, products, product variants, collections, customers, companies, company locations, locations, markets, the shop, pages, blogs, blog posts, or metaobjects changes. You decide which fields or metafields to watch by configuring rules in the app.

Available triggers

Tag change triggers

Use these when you only need to respond to tag mutations. Each trigger returns the list of tags that were added or removed compared to the previous state.

Order tags added
Order tags removed
Draft order tags added
Draft order tags removed
Product tags added
Product tags removed
Customer tags added
Customer tags removed
Blog post tags added
Blog post tags removed

Custom attribute change triggers

React to changes in an order's or draft order's custom attributes — cart-level metadata such as gift messages, delivery instructions, preferred delivery dates, gift wrap flags, or any marketing data set during checkout. The trigger fires whenever an attribute is added, removed, or its value changes. If multiple attributes share the same key, the last value is reported.

If an attribute's value is too large to fit into the payload, the workflow still receives its key in a dedicated list — so it knows the attribute was affected even when the value itself cannot be shipped through Flow.

Order attributes changed
Draft order attributes changed

Field change triggers

Track when business-critical data points differ from their previous values. These triggers emit a structured Field change payload with before/after values so workflows can branch on the exact delta.

Order field changed
Order fulfillment field changed
Draft order field changed
Product field changed
Product variant field changed
Collection field changed
Customer field changed
Company field changed
Company location field changed
Location field changed
Market field changed
Shop field changed
Page field changed
Blog field changed
Blog post field changed

Metafield change triggers

React to updates on merchant-defined data. These triggers return a Metafield change payload describing the namespace, key, type, and the previous/current value in a type-safe structure.

Order metafield changed
Draft order metafield changed
Product metafield changed
Product variant metafield changed
Collection metafield changed
Customer metafield changed
Company metafield changed
Company location metafield changed
Location metafield changed
Market metafield changed
Shop metafield changed
Page metafield changed
Blog metafield changed
Blog post metafield changed

Metaobject field change trigger

Track when fields on custom metaobject entries change. A single trigger covers all metaobject types — you configure which types and fields to watch.

Metaobject field changed

Sales channel and market publishing triggers

React when a product or collection is published to — or unpublished from — a specific sales channel (Online Store, POS, or a channel app), or when a product is published to or unpublished from a market (region). Each trigger fires once per channel or market that changed, and its payload names that single channel or market, so a workflow can respond to a specific one — for example, create a URL redirect whenever a product leaves the Online Store.

Product published to sales channel
Product unpublished from sales channel
Collection published to sales channel
Collection unpublished from sales channel
Product published to market
Product unpublished from market

These triggers cover sales channels and markets only — other publication types (such as B2B catalogs) are not tracked. Markets apply to products only: collections can be published to sales channels but not to markets. Each resource is tracked across up to 250 channels or markets.

To enable them, open the Publishing card in Settings → Triggers, select Manage, and turn on Product → Sales channels, Collection → Sales channels, or Product → Markets (see How to enable tags, attributes, order timeline, and publishing below).

How to enable field or metafield tracking

You enable field and metafield changes with a rule you add from the picker:

Open the Workflow Companion app.
Go to Settings → Triggers.
Select Add rule and choose the resource type (Orders, Products, Customers, etc.). For metaobject fields, select the metaobject type from the Metaobjects submenu.
Choose the field to monitor. For entities that support both built-in fields and metafields, use the Fields / Metafields tabs to switch between them.
Grant the access Shopify requests when prompted.

How to enable tags, attributes, order timeline, and publishing

Tags, custom attributes, order timeline (comments and events), and publishing triggers aren't in the Add rule picker — they have their own cards below the field trigger rules in Settings → Triggers. Each card groups the resources you can turn on.

Open the Workflow Companion app and go to Settings → Triggers.
Find the card you want — Tags, Custom attributes, Order timeline, or Publishing — and select Manage.
In the modal, turn on the resources you want to watch. The status of each resource (enabling, indexing, or on) is shown next to it.
Grant the access Shopify requests when prompted.

For Order timeline, the Comments resource has an extra Capture comment author option. Turn it on to include the staff member who wrote each comment in the payload; it requires the Read users permission, which is available on Shopify Plus and Advanced. The comment trigger works without it — the author is reported as empty.

How field changes are tracked

Shopify reports that something changed, but not the exact before/after values. Workflow Companion stores the previous value for every tracked field or metafield in a dedicated metafield so it can compare the incoming change data with the previous one.

Initial indexing

When you enable a monitoring rule, the app indexes existing items and records their current (meta)field value in the technical metafield. The snapshot lets the app decide whether the value changed on future updates.
Disabling a rule stops indexing and future trigger executions.

Order field tracking

Stores can have a large order history, so the initial indexing only covers orders inside the Order coverage window (see Order coverage below) — by default, orders created in the last 90 days. Orders outside the window are not tracked.

Once the rule is active:

For new orders that already have a value in the monitored metafield, the trigger fires immediately.
For existing covered orders with a stored technical metafield value, the trigger runs whenever the monitored metafield changes.
For existing covered orders without a stored technical metafield value, the first update only stores the current value without firing. The next update can then compare the stored value and emit the trigger when the value changes.

In practice, orders inside the coverage window behave as expected right after you enable the rule because the technical metafield is pre-populated. For a covered order that wasn't pre-populated yet, the first update seeds the technical metafield (no trigger), and later updates fire the trigger when they detect real changes.

Order coverage

The Order coverage setting controls how far back order triggers watch your existing orders. It applies to every order and order fulfillment rule at once, and you can change it any time.

To change it, go to Settings → Triggers, find Order coverage at the bottom of the field trigger rules card, and select Edit. Choose one of:

Orders from the last N days — a rolling window relative to today (the default is 90 days).
Orders created on or after a date — a fixed start date.

Only orders created on or after the cutoff are watched, and only their future changes fire triggers. Changing the coverage never re-fires triggers for past changes on older orders — it just decides which orders are watched going forward.

Widening the window (covering more, older orders) starts a one-time backfill that indexes the newly-covered orders so their future changes can be detected. Your existing rules keep firing while it runs, the wider window takes effect once it finishes.

Suspended rules

If a field rule remains enabled while no workflows use its related triggers, Workflow Companion suspends the rule to avoid unnecessary webhook processing. Suspended rules stop monitoring webhooks until you manually resume them or the matching trigger is activated again. Resuming may take time because the app needs to store current field values during indexing.

Workflow payload details

Field-change triggers send a Field change object with:

field – the human-readable field name.
stringValue – string representation of the previous and current values.
Optional numericValue, booleanValue, moneySetValue, referenceValue, or numericWithUnitValue when the field type supports them.
Order fulfillment triggers also include Changed order fulfillment: id so you can target the affected fulfillment.
Product variant triggers also include Changed product variant: id so you can target the affected variant.
Collection triggers also include Changed collection: id so you can target the affected collection.
Draft order, location, market, page, blog, and blog post triggers also include the affected record's id (and, for draft orders, its name) so later workflow steps can act on it.

Metafield-change triggers send a Metafield change object with:

namespace, key, and type for the definition that fired.
Type-aware snapshots such as stringValue, stringListValue, referenceValue, numericValue, numericWithUnitValue, moneyValue, linkValue, or ratingValue, depending on the metafield definition. Each snapshot includes previous and current values so workflows can check the exact delta.

Tag-change triggers provide Tags.added and Tags.removed arrays.

Publishing triggers send one payload per changed channel or market:

Sales channel triggers include a Sales channel object with id (the publication), channelId, name, handle (e.g. online_store), and appId. Match a specific channel on appId or handle; name and handle are best-effort labels. Product triggers also include product_id; collection triggers also include Changed collection: id.
Market triggers include a Market object with id (the publication), catalogId, and name. Match a specific market on catalogId. These fire for products only and include product_id.
When a channel or market is removed or deleted, its labels come from the last stored snapshot, so the workflow still receives a readable name even for a deleted publication.

The order attributes changed trigger sends an Attributes change object with:

changes — list of attributes that changed. Each entry has key, previous, and current. An empty previous means the attribute was added; an empty current means it was removed.
oversizedKeys — keys of attributes whose value could not be included because it was too large. The workflow knows that something changed for these attributes, but cannot read the value itself.

Metaobject-field-change triggers send a Metaobject field change object with:

key – the field key in the metaobject definition.
type – the field type (e.g., single_line_text_field, number_integer).
Type-aware snapshots (same structure as metafield changes): stringValue, numericValue, booleanValue, etc., each with previous and current.

The trigger also provides a Metaobject object with id, handle, and type to identify the changed entry.

Reinstalling Workflow Companion

If you uninstall and later reinstall the app:

All field rules reset; re-enable the ones you need.
Shopify will ask for the required scopes again.
Indexation restarts to rebuild stored values, ensuring tracking resumes from the moment you re-enable each rule.

Important considerations

In rare cases a trigger may fire twice (for example, if a connection issue prevents the app from seeing Shopify’s acknowledgement). The app retries automatically to ensure the workflow starts.
Large stores may take time to finish the initial indexing. You can continue working; status updates appear in the UI and the process runs in the background.