Make.com architecture for a Shopify → Google Sheets workflow

Questions
,
1

Hello,

I’m trying to validate the best Make.com architecture for a Shopify → Google Sheets workflow.

I can’t access the Make Community at the moment, so I’m asking support directly.

Context:

I have a Shopify Basic store. Customers select delivery details in the cart, and these are saved as Shopify order note_attributes.

Important attributes:

  • villa_id

  • villa_name

  • partner_id

  • delivery_area

  • delivery_date

  • delivery_window

I want Make to process new Shopify orders and update Google Sheets.

Sheets:

  1. Orders_Log
    Each Shopify order is written once.

  2. Slot_Availability
    Pre-populated with slot rows like:

2026-05-09|AREA_A|AM1

I need to monitor capacity per date / area / delivery window.

Question:

For a robust MVP, is it safer to:

A. let Make search Slot_Availability and increment booked_count directly;

or

B. let Make only append/insert the order into Orders_Log, and let Google Sheets calculate booked_count using formulas like COUNTIFS from Orders_Log?

My concern is avoiding duplicate processing and race conditions if two Shopify webhooks arrive close together.

Also:

  • What is the best deduplication strategy for Shopify webhooks in Make?

  • Should I use Make Data Store to store processed order_ids?

  • Is Shopify webhook trigger better than Shopify “Watch Orders” for this case?

  • What is the safest way to parse Shopify note_attributes?

  • For cancellations/refunds, is it better to update the existing Orders_Log row or append an event to a separate Order_Events log?

Goal:
simple but robust Shopify → Make → Google Sheets MVP for delivery slot monitoring.

4

Hello,

There is no simple answer – but here are my takes.

Go with option B. It calculates everything dynamically, so if you delete or modify any order, slot availability updates automatically – no extra Make runs needed.

It depends on the use case. Sequential processing combined with a database check is the safest approach.

You can search for the order_id directly in your Google Sheets – no need for a separate Data Store if the sheet is already your source of truth.

There’s no “safest” way – it’s JSON, so there’s really only one way to parse it :slight_smile:

I’d go with a dedicated Cancellations_Log table. It keeps your Orders_Log clean and lets you track cancellations without any extra tooling.

Main differences: Webhook trigger is instant. Watch Orders runs on schedule. Watch Orders is ACID ( Types of modules - Help Center ).

My take- if you don’t have at least one order every 10 minutes webhook is simply cheaper and faster.

Have a nice day,
Michal

5

Hi Michal,

thank you, this is very helpful.

Based on your feedback, we will proceed with option B:

Make will only write the Shopify order into Orders_Log, and Google Sheets will calculate booked_count, remaining_slots, is_full and needs_review dynamically with formulas from Orders_Log.

We will not use Make Data Store for the MVP.
Deduplication will be handled by checking order_id in Orders_Log before writing a new row.

We also agree that a Shopify webhook is the best option for our volume, since we expect only a few orders per day.

Current architecture:

Shopify orders/create webhook
→ Make parses note_attributes
→ Make writes one row into Orders_Log
→ Slot_Availability updates via COUNTIFS formulas
→ Make/Sheets flags needs_review if needed

We also added a structured Config tab with:

  • delivery_window

  • window_normalization

  • area_window

  • delivery_area

For cancellations/refunds, we will probably add a separate Order_Events_Log later, so Orders_Log can remain the current state table while events are tracked separately.

For now, we will build only the orders/create happy path and test the real Shopify note_attributes structure first.

Thanks again,
Omar