Shopify Watch Orders only works when manually started — how to process new paid orders automatically?

[Pistamiglio_Omar]

What is your goal?

I want my Make scenario to automatically process every new paid Shopify order and write/update Google Sheets.

The scenario is for a local delivery flow. Shopify order note attributes contain delivery data such as delivery date, delivery town, delivery area and delivery window. Make uses these fields to build a slot key, search the matching row in Google Sheets, add the order to an Orders_Log sheet and update the booked slot count in a Slot_Availability sheet.

The scenario works correctly when I manually choose an order, but I need it to run automatically for new Shopify orders only, without processing old orders and without duplicate processing.

What is the problem & what have you tried?

My scenario structure is:

Shopify — Watch Orders
→ Shopify — Get an Order
→ Shopify — Make a REST API call
→ Google Sheets — Search Rows in Slot_Availability
→ Router
→ Google Sheets — Add a Row in Orders_Log
→ Google Sheets — Update a Row in Slot_Availability
→ fallback route to Google Sheets — Add a Row in Errors_Log

The scenario works when I run it manually and select the correct order. For example, it successfully imported order #1067 into Orders_Log and updated the matching Slot_Availability row.

However, the Shopify Watch Orders trigger does not seem to reliably pick up new orders automatically. Sometimes Run once returns “The module didn’t return any new data”. If I use Choose where to start manually, the order can be processed correctly.

I have tried:

• Shopify Watch Orders with Watch by: Creation date
• Order limit: 1
• Scenario schedule: every 15 minutes
• Choose where to start → From now on
• Manual test orders in Shopify

The internal logic after the Shopify trigger seems to work. The issue seems related to the trigger, the starting point, or the polling behavior.

My questions are:

1. For Shopify Watch Orders, what is the correct setup to process only new orders from now on?
2. Should I use Choose where to start → From now on, save it, then turn the scenario ON with the schedule?
3. Is Watch Orders a polling trigger that only checks every X minutes?
4. Would Watch Events / webhook be better for real-time Shopify order processing?
5. If I use Watch Events, should I watch order created, order paid, or another event?
6. What is the best practice to avoid processing old orders or processing the same order twice?
7. Should I add a deduplication step by searching Orders_Log for the Shopify order_id before writing/updating rows?

Error messages or input/output bundles

No technical error message.

When using Run once, the Shopify Watch Orders module sometimes returns:

“The module didn’t return any new data. You can use the Choose where to start settings to select the first piece of data you want to return and start working with.”

When I manually select an order with Choose where to start, the scenario runs successfully.

Screenshots (scenario flow, module settings, errors)

[Daraima_Bassey_N]

Please save and activate your scenario and tell that module to start fetching new orders from now onward and choose 1 order to run at a moment.

Don’t forget to let it run on demand. It manually processes the order means your flow is correctly set. It doesn’t pick new orders probably because it has not been activated to do that. Should the issue persist after activating it and setting the watch orders to run on demand then you signal on here let’s take the Debugging one step further.

Give it a shot.

[Pistamiglio_Omar]

Hi John,

thank you, this is very helpful.

I’ll replace my current note_attributes mappings with this safer pattern:

{{get(map(ifempty(3.body.order.note_attributes; emptyarray); “value”; “name”; “delivery_area”); 1; “”)}}

and I’ll reuse it for delivery_date, delivery_window, delivery_town, accommodation_name, full_delivery_address, customer_whatsapp and delivery_notes.

That should solve the invalid array issue when note_attributes is empty or when a specific attribute is missing.

One quick question: for building a slot_key like:

delivery_date|delivery_area|delivery_window

is it better to concatenate three separate safe expressions like this?

{{get(map(ifempty(3.body.order.note_attributes; emptyarray); “value”; “name”; “delivery_date”); 1; “”)}}|{{get(map(ifempty(3.body.order.note_attributes; emptyarray); “value”; “name”; “delivery_area”); 1; “”)}}|{{get(map(ifempty(3.body.order.note_attributes; emptyarray); “value”; “name”; “delivery_window”); 1; “”)}}

Or would you recommend creating variables first and then using those variables in the Google Sheets search filter?

Thanks again!

[EmmanuelB]

A few things that usually fix this:

1. “Watch Orders” is a polling trigger, it only checks on the scenario’s schedule interval, it’s not instant. So “every 15 minutes” is expected behavior for that module, not a bug.
2. The sequence matters: set “Choose where to start” to From now on, hit Save, THEN turn the scenario ON. If you toggle it on before saving that setting, Make can re-evaluate the starting point and you get the “no new data” message or it picks up old orders.
3. For “process only new orders, no duplicates, no old orders, real-time”: switch to Watch Events (webhook-based) instead of Watch Orders (polling). Subscribe to orders/create or orders/paid depending on whether you want to react at order placement or at payment confirmation. For your delivery-slot use case, orders/paid is usually the safer trigger since you don’t want to book a slot for an order that never gets paid.
4. Yes, add a dedup step. Even with webhooks, Shopify can occasionally redeliver the same event. Before the Add a Row in Orders_Log step, add a Search Rows filtered by order_id in Orders_Log, and only continue to the Add/Update steps if no match is found. Cheap insurance against double-booking a delivery slot.

Switching to the webhook trigger alone should solve most of what you’re describing, the polling trigger is the main source of the “sometimes nothing happens” behavior.