How to automate tasks after a customer's order is updated on Shopify Flow?

[maxrfinch]

Just discovered there's no trigger for an updated order on Shopify Flow. I'm looking to use this to automate tasks after a customer's order is updated.

[bryanro]

Trigger needed are:

Updated order

Updated Draft order

Updated Customer

Updated Product

[Koennn]

+1 For the Updated Order and Updated Draft Order triggers. Its weird that Zapier can do this, but Flow cant. Hope this will come soon!

[paul_n]

What is your use case?

[Koennn]

We deliver big pieces of furniture, and the time a delivery takes varies
greatly. For planning purposes, we have a metafield that calculates
delivery time based on order weight and distance.

We work a lot with Draft orders for people visiting our showroom. This
metafield needs to be updated every time the Draft Order is updated,
especially immediately after the edit. Otherwise our showroom employee
might promise an unrealistic delivery time to our customer.

[paul_n]

How fast after edit? We recently improved scheduled workflows to work every 10 min, so if that is fast enough (probably not?) you could do:

Every 10 min

Get updated draft orders

For each draft order

   update delivery time metafield

[jonmossman]

Has this trigger been added to Shopify Flow yet?

[bryanro]

No. I have to use an App for these automations. Arigato Automation works well.

[paul_n]

You can use the scheduled time trigger + a "Get data" action to make your own update event. 

Something like:

• Scheduled time trigger: Every hour
• Get order data (with a query matches which orders you care about)
• For each (order)
  • Whatever action you want to take

[bryanro]

I read another thread about this workaround. How would that work in a scenario where I want to trigger an automation for ANY customer that is modified, specifically, any of the following information is changed:

tags

tax-exempt status

email address

custom fields

I don't want to risk missing a trigger because my query isn't correct, so it's easier to trigger based on ANY update to the customer (or order for that matter).

[bryanro]

I can't seem to find the other thread on this topic. Was it removed?

[paul_n]

idk, I haven't seen another thread

[paul_n]

Anything that causes an update event should be caught if you use "updated_at" in your query. You won't know what changed, though, unless you store the prior value somewhere. 

If you want "tags changed", you can use "Customer tags added" or "customer tags removed".

[bryanro]

Does that mean I could query for all customers (or orders) that have been updated and run them through the automation individually?

This is what I need, because I will use Conditions to validate the changes that I am looking for before I start the trigger. 

Or do I have to query against a specific field?

[paul_n]

You need to query with updated_at at the very least. It's generally better use the query filters to get the smallest number of results as possible as there is a limit of 100 at a time. 

[tjbiddle]

Why so many replies just providing workarounds and asking users' use-case?

The use-case is: This should just simply exist! For every 1 person that makes a post, there's probably 1000s more that want the feature. You're asking one particular person for their use-case, but there's an infinite amount of possibilities. 

I'm needing to use 3rd party tooling to monitor order edits and order updates because this isn't supported in Flow. I really don't see why this doesn't exist; you have all the supporting technology right there.

[paul_n]

While the events exist, the events don't provide the needed information to be able to use them for most Flow use cases. The Order updated event doesn't tell you what was updated. In addition, merchants will unintentionally build infinite loops like Order updated -> update order metafeld if Flow doesn't have controls on that. We seen it already with experiments. 

I'm asking for use cases because (1) many of them can be solved now as I've outlined above. I wouldn't consider those workarounds as sometimes it's a better solution than an event. And (2) the design of a system that stores data and computes what's changed requires many decisions in order to make it work as merchants want. The more we know about use cases the better we can design it. 

[tjbiddle]

That's fair. I can see the infinite loop happening. Maybe can build something that will recognize when that will happen and disallow it unless there is a break case when it gets called the second time?

In my case, I want to know whenever an order is edited(/updated) and to tag the order with "Pending Edit" so that we can see that someone made a change, and follow our SOP.

Right now, I have in my Admin -> Notifications -> Webhooks section I have an order/edit and order/update events going to the same address.

If it's an edit: We get the order, and tag the order

If it's an update: We get a metafield that is storing an address line, check if that metafield is matching the current shipping address, if it's not - we update the metafield, and then tag the order same as the above edit

We do get a bit of that 'infinite loop' due to the order updates on the tagging; but after the event is received, it breaks on the conditionals and doesn't repeat.

[paul_n]

Thanks, you may want to experiment with Scheduled time (every 10 min) + Get order data. It could get you there.