Anatomy of an automation: triggers, actions, filters and the data that flows between them

Every day your team copies an enquiry from email into a sheet, forwards it to a salesperson, sends an acknowledgement and sets a reminder to follow up. No-code automation tools can connect the apps you already use — Gmail, Google Sheets, Zoho, Razorpay, your website forms — so these hand-offs happen on their own, every time, at 2 am as well as 2 pm. But almost every automation a beginner builds breaks for the same reason: they start clicking inside the tool before they understand the four parts every automation is made of. This lesson gives you that mental model so everything you build later in this programme stands on firm ground.

What you need to know

What "no-code" really means. No-code does not mean no logic. It means you build logic by choosing apps, events and fields from menus instead of writing programming code. You still have to think clearly about order, conditions and data formats. Zapier, Make, n8n, Microsoft Power Automate and Pabbly Connect, and the built-in automation features inside tools like Zoho CRM, HubSpot and Shopify, all follow the same underlying model described here, even though each uses different words for it (Zapier calls an automation a "Zap", Make calls it a "scenario", n8n and Power Automate call it a "workflow" or "flow").

The trigger: what starts a run. Every automation begins with exactly one event. There are two kinds:

• Polling triggers. The platform checks an app at intervals — "is there a new row in this sheet?" There is a delay between the event and the run, and the interval usually depends on your plan.
• Instant or webhook triggers. The source app pushes the event the moment it happens — a payment captured, a form submitted, an order placed. Faster, and better for anything a customer is waiting on.

If you find yourself wanting two different triggers for one automation, you usually need two automations, or one shared place (a sheet or a table) that both sources feed into.

Actions: what the automation does. An action changes something in an app: create a row, send an email, update a contact, create a task, post a message to a team channel. Actions run in the order you set, and each one can use data from the trigger and from any action before it. A "search" or "find" action is also an action — it looks up an existing record, for example "find the customer whose mobile number is this".

Filters and branches: when to continue and which way to go. A filter stops a run unless a condition is true — "continue only if the order value is above ₹10,000" or "continue only if the email does not contain 'test'". A branch (Zapier calls them paths, Make calls it a router) sends the run down different routes — "Gujarat enquiries to the Ahmedabad desk, everything else to head office". Without filters, automations do too much: they email every lead, including the spam and your own test entries.

Data mapping: the part that decides whether it works. A trigger produces a bundle of fields — name, mobile, city, amount, date. Mapping means telling each later step exactly which field goes where. Most real-world failures happen here:

• A mobile number arrives as "+91 98765 43210" but the next app expects ten digits.
• A date arrives as 03/04/2026, which one app reads as 3 April and another as 4 March.
• An optional field is blank, and the next app refuses to create the record.
• An amount arrives as text ("₹1,250/-") and cannot be added or compared.

Runs, steps and billing units. Platforms charge by a unit of work, and each defines it differently. Zapier counts tasks (broadly, successful action steps), Make counts operations or credits (each module that runs), and n8n's cloud plans count workflow executions. The same five-step automation running 600 times a month can therefore use 600 units on one platform and 3,000 on another. Definitions and plan limits change, so always confirm them on the vendor's current pricing page before you design.

Designing for "the same event twice". Sources sometimes send the same event more than once — a customer double-clicks Submit, or a payment gateway retries a notification. A well-built automation gives the same result either way: it checks "does this record already exist?" before creating it. Lesson 08 covers this in depth; keep it in mind from your first build.

The four questions for every automation.

1. What event starts it, and how quickly must it react?
2. What exact data does that event carry, and in what format?
3. Under what conditions should it stop, continue or branch?
4. What should change in which app — and who is told if a run fails?

Step-by-step method

1. Pick one repeated task that someone in your business did at least ten times last week. Write it as one sentence: "When X happens, we do Y in Z."
2. Name the trigger precisely, down to the app, the event and the specific form, inbox or sheet (for example, "Google Forms — new response in Dealer Enquiry Form").
3. Decide the acceptable delay. If a 10–15 minute lag would upset a customer, look for an instant or webhook trigger.
4. Open one real example of the event and write down every field it contains, with a sample value next to each.
5. List the situations in which the task should not happen: test entries, duplicates, spam, incomplete details.
6. Write the actions in order, and next to each action list the fields it needs.
7. Mark every field that needs cleaning before use — mobile numbers, dates, names typed in capitals, amounts with symbols.
8. Estimate monthly runs and multiply by the number of billable steps to get monthly usage.
9. Name the person who will be alerted when a run fails, and how they will be alerted.
10. Only now open the automation tool and start building.

Automation anatomy card

• Automation name: ____
• Trigger app, event and exact source: ____
• Trigger type: polling / instant / not sure yet
• Acceptable delay: ____ minutes
• Fields available (field — sample value): ____
• Stop conditions (filters): ____
• Branches (condition → route): ____
• Actions in order (app — action — fields used): 1. __ 2. 3. __
• Fields that need cleaning: ____
• Expected runs per month __ × billable steps = __ units
• Duplicate check planned: yes / no
• Failure alert goes to ____ by email / team chat / both

Common mistakes

• Building before looking at a real sample of trigger data, then discovering the form sends first name and surname in separate fields that were never mapped.
• Treating a polling trigger as instant and promising customers an "immediate" reply that actually arrives 15 minutes later.
• Leaving out filters, so internal test submissions trigger acknowledgement emails to your own staff and to salespeople.
• Mapping a text date into a date field without stating the format, so 03/04 is stored as March instead of April.
• Estimating cost from actions alone when the platform also bills for search, lookup or formatting steps.
• Having no named person who receives failure alerts, so a broken automation goes unnoticed for weeks.

Ask the AI Business Tutor

• "I run a [type of business] in [city] with [number] staff. A task we repeat about [number] times a month is: [describe the task in one sentence]. Break it into trigger, filters, branches and actions; list the data fields each step needs; point out which fields are likely to need cleaning; and estimate the billable steps per run if we build it on [platform name]."