How I Built a Status-Driven Batch Automation System in Make (Google Sheets → Apify → Google Drive)

Knowledge Hub
, , , ,
1

How I Built a Status-Driven Batch Automation System in Make (Google Sheets → Apify → Google Drive)

Screenshot 2026-03-02 at 12.10.12 PM
Screenshot 2026-03-02 at 12.10.12 PM2850×1536 507 KB

I’ve been experimenting with building safer batch-processing systems in Make, and I wanted to share a structure that worked surprisingly well.

The use case: archiving TikTok videos listed in Google Sheets into Google Drive.

But the interesting part isn’t the TikTok piece — it’s the architecture pattern.

The Problem

When you process rows from Google Sheets in bulk, things can go wrong:

  • Duplicate execution
  • Partial failures
  • Hard-to-track status
  • Folder chaos in Drive
  • Re-running the scenario re-processes the same rows

I wanted something that behaves more like a controlled job queue than a simple “read and run” automation.

The Core Architecture

Here’s the structure I implemented:

  1. Generate today’s date (YYYY-MM-DD)
  2. Search Google Drive for a folder with that name
  3. Create it if it doesn’t exist
  4. Search Google Sheets for rows where:
    • TikTok URL exists
    • Status = PENDING
    • Limit = 20 (configurable)
  5. Immediately update each row to PROCESSING
  6. Run the Apify Actor synchronously
  7. Download the returned video file
  8. Upload the file to today’s folder
  9. Write results (title, author, Drive link, error message) back to the sheet

The key idea: Google Sheets becomes a lightweight task queue.

Why the Status Update Happens Before Processing

One small but important decision:

I update the row status to PROCESSING before calling the external API.

Why?

If the scenario stops mid-run, that row won’t get picked up again automatically.
It prevents accidental duplicate downloads and keeps execution deterministic.

You can later manually reset rows to PENDING if needed.

Daily Folder Logic

Another reusable pattern:

  • Generate a date string using formatDate(now; "YYYY-MM-DD")
  • Search Drive within a specific parent folder
  • If not found → create
  • Store the folder ID in a variable for reuse

This avoids hardcoding folder IDs and keeps the archive clean over time.

It’s simple, but it scales nicely.

Why This Pattern Works Well

• Controlled batch size
• Explicit status transitions
• Error handling per row
• No duplicate runs
• Clear audit trail in Sheets
• Easily reusable with other APIs

You could replace the TikTok Actor with:

  • AI enrichment
  • Data scraping
  • Image processing
  • CRM updates
  • Bulk transformations

The batch-control pattern stays the same.

What I Learned

  1. Status-driven design is safer than time-based triggers
  2. Sheets can act as a task queue if you structure it properly
  3. Updating state early prevents downstream chaos
  4. Folder auto-generation keeps file automations scalable

Example Implementation

If you want to see a working implementation of this architecture, here’s the template I built:

https://us2.make.com/1817829/templates/13251/edit?templatePublicId=18625

I’m curious — how do you handle batch control and idempotency in your Make scenarios?

Do you rely on Data Stores, Routers, or external queues?

1 Like