The one idea
Every automation, in every tool, in every language, is the same sentence:
When X happens, if Y is true, do Z.
Trigger. Condition. Action.
That is not a simplification for beginners. It is the actual structure. Complex automations are chains of these, not a different thing.
Something starts it. Something decides whether it should continue. Something gets done.
Write your process as one sentence in that shape before opening any tool. If you cannot, the process is not ready to automate.
Event source, predicate, effect. Triggers are either event-driven (something pushed to you) or polled (you check on a schedule), and the difference determines latency, cost and duplicate handling.
The three parts
| Part | Question | Examples |
|---|---|---|
| Trigger | What starts this? | A form is submitted. A file lands in a folder. It becomes 9am Monday. An email arrives from a specific sender. |
| Condition | Should it actually run this time? | Only if the amount is over 10,000. Only if the sender is external. Only on weekdays. |
| Action | What gets done? | Add a row. Send a message. Create a task. Rename a file. |
The condition is the part beginners omit, and it is the part that prevents your automation from firing on every email you receive rather than the four that matter.
The two kinds of trigger
This distinction explains most confusing automation behaviour.
Event triggers fire the moment something happens. The other system tells
yours. Fast, efficient, and requires the other system to support it — which is
what a webhook is, covered in what-an-api-actually-is.
Schedule triggers run at fixed times and check whether anything changed. Simpler, works with anything, but slower to react and it will re-check even when nothing has happened.
| Event | Schedule | |
|---|---|---|
| Reacts in | Seconds | However often you check |
| Works with | Systems that support notifications | Almost anything |
| Risk | Missing an event while you were down | Processing the same item twice |
A large share of "why did my automation run three times?" is a schedule trigger that has no memory of what it already handled.
Mapping a real process
Take something ordinary: an office where expense claims arrive by email, get logged in a sheet, and anything over a threshold needs the manager to approve.
From how you do it to three lines
1 of 6Describe what you actually do, in order, in plain sentences.
"I check email in the morning. If there's an expense claim, I open the attachment, put the amount and the name into the sheet, and if it's more than ₹10,000 I message my manager."
Do not tidy it yet. The messy version contains the exceptions, and the exceptions are the important part.
"Notify me when a client replies" looks like one automation. Mapped properly it is: trigger — email received; condition — sender is on the client list AND it is a reply, not a new thread; action — send a phone notification.
Without the condition, you have automated "notify me about every email", which you already had, and which is why you wanted this in the first place.
"Back up my photos" as three parts: trigger — it is 2am; condition — I am on wifi and the phone is charging; action — upload anything new.
Those conditions are the whole feature. Without them you have an automation that drains your battery and your mobile data, which is why you would turn it off.
Try this
Map this into trigger, condition and action:
"Whenever a new candidate applies through our careers form, I check whether they have the minimum years of experience. If they do, I add them to the shortlist sheet and send them the assessment link. If not, I send a polite rejection."
Your challenge
Level 3 · IndependentTake one process you do repeatedly at work or in your studies and write it as a four-line specification: trigger, condition, action, on-failure.
You have succeeded when someone who does not know your job could read the four lines and tell you exactly when it would run and what it would do — and when you have written down at least one exception that means a human stays involved.
Do not build anything. The specification is the deliverable. If it is right, building it in any tool is the easy part.
What people usually get wrong
- No condition. The automation fires on everything and you turn it off within a week.
- Trigger set to your habit, not the event. "Every morning" instead of "when it arrives" adds a delay you did not need.
- One action doing four things. Separate them. Then a failure in step three does not undo step one, and you can see which step failed.
- No failure path. Silence is the worst outcome — you assume it ran.
- Conditions that need information the trigger did not carry. If the trigger is "file uploaded" and the condition needs the customer's account status, you need a lookup step between them.
- Building before writing the sentence. Every tool asks the same three questions. Answer them on paper and the tool becomes trivial.
How someone experienced does it
Experienced people design for the automation running twice. Networks retry. Schedules overlap. Someone submits the form again. If running twice creates two rows, two emails or two payments, that is a bug waiting for a bad day.
The fix is to make the action safe to repeat: check whether this item is already handled before acting, or key the record on something unique from the source. It is fifteen extra minutes and it removes an entire category of embarrassment.
They also keep the trigger broad and the condition tight, not the reverse. It is easier to reason about "every new email, filtered to these three senders" than about a clever trigger that only fires sometimes for reasons you will not remember.
And they log what happened. Not what the tool logs — a line you write, saying which item was processed and what was decided. When someone asks in March why a claim was never logged in January, that line is the only thing that can answer.
Why chains of automations get hard
One automation is easy. Six connected ones behave in ways nobody predicted, for three reasons.
Order stops being guaranteed. If two automations both react to the same trigger, they may run in either order, or at once. If one depends on the other having finished, it will work in testing and fail under load.
Loops. Automation A writes to a sheet. Automation B triggers on sheet changes and sends an email. If a reply to that email triggers A, you have built a machine that runs forever, and you will find out from a bill or an inbox.
Nobody holds the whole picture. Each piece is simple and documented nowhere. Six months later a person changes one column name and three things break in ways that look unrelated.
The defence is a single written map of what triggers what — one page, kept current. Teams that skip it eventually reach a state where nobody is willing to turn anything off.
Prove it
Write the four-line specification for a process you actually do, then have someone who does that process read it and tell you what you got wrong.
They will find an exception you forgot. That exception is the most valuable output of this exercise, because it is exactly what would have broken in production.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned designing an automation as trigger, condition and action. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood designing an automation as trigger, condition and action. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at mapping a manual process into an automation — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.