Hi @neslot
Good question.
Updates for many apps are not triggered on a per field basis.
This may not be easily doable as it can be a challenge to isolate which data point triggered the update as those are often not explicitly indicated, but it is doable.
NOTE: The first approach below is Task intensive as it will require at least 2 Tasks each time in order to Filter.
Zap steps would look like this:
- Trigger: Shopify
- Action: GSheet - Lookup Row
- By Order ID
- Action: Code
- Compare NEW vs OLD values
- Action: Filter
- Only if change detected
- Action: GSheet - Update Row
- Map the Row ID from step 2
Alternatively, you let the Zap be dumb with just update the GSheet Row each time for those address fields.
- Trigger: Shopify
- Action: GSheet - Lookup Row
- By Order ID
- Action: GSheet - Update Row
- Map Row ID from step 2
Hi @Troy Tessalone, thanks for the response!
I’m having a bit of difficulty setting these up, in either of these options will it cost me a zap for every time an order is updated / filtered? Which means every order that happens on the store will be a zap, as I believe simply fulfilling the order counts as an order update, if so this will sadly be too expensive.
Hopefully there’s a solution for this.
@neslot
Help article to learn about how Tasks are counted in Zap Runs: https://zapier.com/help/manage/history/learn-about-tasks-in-zapier
Hi @neslot!
Troy’s solutions will definitely work, but you’re right that each time the order is updated (including fulfillment status), it would trigger the Zap. You could save some tasks by setting up a filter where if the status is ‘fulfilled’ the Zap doesn’t run any other actions. So, any fulfilled orders wouldn’t count against your tasks because the filter would stop them. Are there any other fields or order statuses you could filter on? For example, if the status is cancelled, shipped, or unpaid?
Do you think that would reduce the tasks enough to make Troy’s solution viable for you?