data.day
simplicity / architecture / reliability

One Trigger, One Action: The Only Automation Rule We Need

Complex automations are fragile. If you chain 20 steps together, step 14 will break. Keep your robots small, stupid, and sturdy.

Ingrid Pipeline Ingrid Pipeline

The Rube Goldberg Machine

The marketing manager wanted to automate a lead form. “When they fill the form,” she said, “I want to:

  1. Add to CRM.
  2. Send an email.
  3. Slack the team.
  4. Create a folder in Dropbox.
  5. Wait 3 days.
  6. Send another email.”

She built it all in one giant “Zap.” It was beautiful. It was huge. Then Dropbox changed their API permissions. Step 4 failed. Because Step 4 failed, the automation stopped. The lead was not added to the CRM (Step 1 was rolled back? No? Who knows). The email was not sent. The entire machine crashed because of one small gear.

The Fragile Link: Interdependency

When you chain actions, you create dependencies. Step 5 relies on Step 4. Step 4 relies on Step 3. If any vendor changes a setting, the whole chain dies.

This is Fragile. It is also impossible to debug. When the error log says “Failed at Step 9,” you have to investigate the whole history. You waste hours tracing the wire.

The Sturdy Fix: The Atomic Rule

We tore it down. We rebuilt it using Atomic Automation. One Trigger. One Action.

Automation A:

  • Trigger: Form Submit.
  • Action: Add to CRM.
  • End.

Automation B:

  • Trigger: New Contact in CRM.
  • Action: Send Email.
  • End.

Automation C:

  • Trigger: New Contact in CRM.
  • Action: Create Folder.
  • End.

If Dropbox breaks, Automation C fails. But Automation A and B still run. The lead is safe. The email is sent. The damage is contained.

[TO EDITOR: Diagram showing ‘The Monolith’ (Chain of 5 boxes) vs ‘The Micro-services’ (1 Event triggering 5 separate, parallel arrows)]

Build with Bricks, Not String

A brick is a solid unit. You stack them. If one brick cracks, the wall stands. A long string is weak. If you cut it anywhere, the connection is gone.

Build your operations with bricks. Keep the robots small. Keep the scope narrow. Reliability comes from simplicity.

FAQs

But I have a complex process.

Then you have a chain of simple processes. Break them apart. If step 3 fails, step 1 and 2 should remain safe.

Doesn't this create more automations to manage?

Yes. But they are small. You can fix a small thing easily. You cannot fix a giant tangled knot without cutting it.

What is the risk of a long chain?

Latency. Timeout. Confusion. If it breaks at step 10, how do you replay steps 1 through 9? It is a mess.