# Zapier > Connect the apps you already use with no code: build Zaps from a trigger and actions, add filters and paths, and avoid the task-limit and duplicate-run traps. --- # Zapier You have a dozen apps that don't talk to each other. A form fills up on your website, and someone has to copy each entry into a spreadsheet. A payment lands in Stripe, and someone pastes the customer into your CRM. A new lead emails you, and you remember to add them to a list three days later, maybe. Every one of these is a small, repetitive, copy-paste chore that a computer should be doing while you sleep. Zapier is the tool that gets the computer to do it - without you writing a single line of code. The way it works is one idea repeated forever: **when this happens in one app, do that in another app.** A new row appears in Google Sheets, so send a Slack message. A new Stripe charge arrives, so create a row in Airtable and email a receipt. Zapier sits in the middle, watching for the "when" and performing the "do." It already speaks the language of thousands of apps - Gmail, Slack, Notion, Shopify, HubSpot, QuickBooks, and on and on - so you wire them together by clicking, not by reading API documentation. This guide is for founders, ops people, and anyone drowning in manual handoffs between tools. You don't need to be technical. Phase 1 builds your very first working automation - a trigger and an action - and shows you what a Zap actually is (and the limits of what it can do). Phase 2 moves past the two-step toy into real workflows: many actions in a row, filters that stop a Zap from running when it shouldn't, paths that branch like an if/then, and the Formatter that cleans up messy data along the way. Phase 3 is the part nobody tells you about up front - how Zapier charges you (per "task," which has a specific meaning), why your Zap sometimes runs fifteen minutes late, why it occasionally fires twice, and how to fix a Zap that quietly broke at 2am. By the end you'll be able to build automations that hold up in the real world instead of ones that look clever in a demo and fall over by Friday. --- # Your First Zap A **Zap** is one automation. It has two halves: a **trigger** (the thing that starts it) and one or more **actions** (the things it does in response). Read it as a sentence with a built-in "when" and "then": > **When** a new email arrives in Gmail with a label, **then** post a message in Slack. That's a Zap. The trigger is "new labeled email in Gmail." The action is "send a Slack message." Everything else in Zapier is variations on that one shape. ## Pick the two apps first Before you touch the editor, finish this sentence out loud: "When ___ happens in ___, I want ___ to happen in ___." If you can say it, you can build it. If you can't, you're not ready to build yet - figure out the workflow on paper first. Let's use a concrete one founders actually need: > When a new response comes in from my Typeform, add a row to a Google Sheet. Trigger app: Typeform. Action app: Google Sheets. Hold those two names in your head. ## Connect your accounts Zapier can't watch your Typeform or write to your Sheet unless you give it permission. The first time you use an app, Zapier sends you through that app's normal login screen (a flow called OAuth - you log in to Typeform, it asks "let Zapier access this?", you click Allow). You're not handing Zapier your password; you're granting it a revocable key, which you can take back later from the app's own settings. You connect each account once. After that it shows up in a dropdown for every future Zap. Connect both apps now - the trigger app and the action app - so you're not interrupted mid-build. ## The Zap editor, step by step Create a new Zap and you land in the editor: a vertical stack of steps, top to bottom, that runs in that order. The top step is always the trigger. 1. **Choose the trigger app and event.** Pick Typeform, then the event "New Entry." Apps usually offer several trigger events - "new entry," "new contact," "updated record" - so read them and pick the one that matches your "when." 2. **Choose the account.** The Typeform account you connected appears in a dropdown. 3. **Set up the trigger.** Typeform asks *which* form to watch. Choose it. 4. **Test the trigger.** This is the step people skip and regret. Zapier reaches into Typeform and pulls a real recent response so you can see the actual data - the question answers, the submission time, the respondent's email. If nothing comes back, submit a test entry to your form and try again. You need real sample data here, because the next step depends on it. Now the action: 5. **Choose the action app and event.** Pick Google Sheets, event "Create Spreadsheet Row." 6. **Choose the account**, then the specific spreadsheet and worksheet. 7. **Map the fields.** This is the heart of it. Google Sheets shows you its columns; next to each, you insert a value pulled from the trigger. Click the Name column, and choose the "Name" answer from the Typeform step. Click Email, choose the email answer. You are wiring the trigger's output into the action's input. Those inserted values look like little tagged tokens - they're placeholders that get filled with real data each time the Zap runs. 8. **Test the action.** Zapier writes one real row to your sheet using the sample data. Go look at the sheet. A row is there. That's the whole loop working end to end. ## Turn it on Until you flip the switch to **On** (sometimes labeled "Publish"), nothing happens automatically - you've only been testing. Once it's on, Zapier watches Typeform on its own, and every new response lands in your sheet without you lifting a finger. ```text TRIGGER → New Typeform entry ACTION → Create a Google Sheets row (Name column ← Typeform "Name") (Email column ← Typeform "Email") STATUS → On ``` ## What a Zap is - and isn't A Zap is **event-driven and one-directional.** Something happens, then steps run, top to bottom, once. That mental model saves you from three common wrong expectations: - **It's not a two-way sync.** A Zap pushes Typeform → Sheets. It does not also notice when you edit the sheet and update Typeform. If you want both directions, that's two separate Zaps, and you have to watch out for them triggering each other in a loop. - **It doesn't run on a continuous loop over old data.** A Zap reacts to *new* events from the moment you turn it on. It won't go back and process the 400 responses you already had. (For bulk history you'd export and import by hand, or use a separate one-time transfer.) - **It's not instant for every app.** Some triggers fire the moment something happens; others are checked on a schedule. We'll cover that timing - and why it matters - in Phase 3. One Zap, one trigger, a chain of actions. Get this single trigger-and-action pattern working and feel it run on its own, because every workflow in the next phase is this exact idea with more steps, smarter branches, and a cleanup stage in the middle. --- # Multi-Step Zaps, Filters & Formatting A two-step Zap is a demo. Real work needs more: do several things in response to one event, skip the whole thing when conditions aren't met, take different routes depending on the data, and tidy up messy values before they land somewhere. That's what this phase is about. ## More actions, in order After your trigger, you can stack actions, and they run strictly top to bottom. New Stripe charge → create the customer in your CRM → add a row to a revenue sheet → post in the team Slack. Four steps, one trigger. The order matters for two reasons. First, each step can use the output of *any* step above it - so if step 2 creates a record and hands back its new ID, step 3 can use that ID. Second, if a step fails, the steps below it don't run. Put the steps that must happen earlier; put the nice-to-haves later. ## Passing data between steps Every step produces **output** - named fields you can pull into later steps. The trigger outputs the email, name, and amount. A "create record" action outputs the ID of the thing it created. You insert these outputs into the fields of later steps, the same way you mapped fields in Phase 1. Two habits keep this from biting you: - **Always test each step before building the next one.** A step's outputs only become available to map after you've tested it. Build, test, then move down. - **Watch for empty fields.** If a trigger field was blank in your test sample, Zapier may not even show it as a mappable option. Use a test record that has every field filled in. ## Filter: the brake pedal A **Filter** step stops a Zap from continuing unless a condition is true. Place it right after the trigger (or anywhere you want a checkpoint). If the condition passes, the Zap rolls on; if it fails, the Zap halts there and the steps below don't run. Say you only care about high-value orders: ```text TRIGGER → New Stripe charge FILTER → Only continue if Amount > 100 ACTION → Post in #big-sales Slack channel ``` A charge for $40 hits the filter and stops - silently and correctly. A charge for $250 sails through. Filters are how you stop a Zap from spamming you on every trivial event, and (important for your bill, as Phase 3 explains) a filtered-out run is cheap. Common filter conditions: "exists / doesn't exist" (skip if no email), "text contains" (only support emails with "refund" in the subject), "greater than / less than" for numbers. ## Paths: branching A **Filter** is one road with a gate. **Paths** give you a fork - different actions depending on the data. Each path has its own condition and its own set of actions. ```mermaid flowchart TD T[Trigger: new lead] --> R{Path rules} R -->|Plan = Enterprise| A[Notify sales team] R -->|Plan = Free| B[Add to nurture email list] R -->|No plan chosen| C[Send a follow-up email] ``` Each branch runs only if its condition matches. This is your if / else-if / else. Reach for Paths when "it depends" enters the conversation - VIP customers go one way, everyone else another. Note that Paths are a feature of paid plans; on the free tier you'd approximate branching by running several separate Zaps, each with its own filter. ## Formatter: the cleanup crew Real data is messy. A date arrives as `2026-06-30T14:00:00Z` but your sheet wants `June 30, 2026`. A name comes in as ` jane DOE ` with stray spaces and wrong casing. A phone number has dashes you don't want. **Formatter** is a built-in utility step (it's "by Zapier," not a separate app) that transforms values between steps. What you'll use most: | Formatter type | What it does | Example | |---|---|---| | Text | trim, change case, find/replace, split, truncate | ` jane DOE ` → `Jane Doe` | | Date / Time | reformat dates, add or subtract time, change zones | ISO timestamp → `June 30, 2026` | | Numbers | round, do arithmetic, format as currency | `19.99 * 12` → `239.88` | A Formatter step takes a value in, transforms it, and outputs the cleaned-up version, which you then map into the next step instead of the raw one. Pattern: trigger → Formatter (clean the name) → action (use the cleaned name). ## Lookups: find before you act Often you don't want to blindly *create* a record - you want to find an existing one and either update it or create it if it's missing. Many apps offer a **"Find or Create"** action (sometimes a separate "Lookup"). It searches for a match (say, a customer by email); if found, it hands you that record's ID; if not, it creates one. This is how you avoid duplicate contacts piling up every time the same person triggers a Zap. ```text TRIGGER → New form submission LOOKUP → Find CRM contact by email (create if not found) ACTION → Update that contact's "last seen" date ``` ## Putting it together A grown-up Zap reads like a recipe: ```text TRIGGER → New paid invoice (Stripe) FILTER → Continue only if Amount > 0 and Email exists FORMATTER → Format amount as currency LOOKUP → Find or create customer in CRM PATHS → If first-time buyer → send welcome email If returning buyer → send thank-you + upsell ACTION → Append row to revenue sheet ``` Trigger to start, a filter to guard, a formatter to clean, a lookup to stay tidy, and paths to handle "it depends." That's the full vocabulary. Phase 3 covers what it costs to run all this, and the timing and duplication traps that catch everyone the first time. --- # Recipes, Limits & Gotchas This is the phase that saves you money and saves you a bad afternoon. The mechanics from Phases 1 and 2 work fine in a demo; the things below are what bite you once real volume flows through. ## How Zapier charges you: tasks Zapier bills on **tasks.** A task is one **action** step that successfully runs. Read that carefully, because the details decide your bill: - The **trigger does not cost a task.** Zapier watching your form for new entries is free; only the actions it then performs count. - **Each action that runs is one task.** A Zap with four actions that fires once = four tasks. The same Zap firing 100 times = 400 tasks. - A **Filter that stops a Zap costs nothing** for the steps that didn't run. This is why filters are your budget's best friend - guard early and you don't pay to do work you didn't want. - Formatter, Filter, and Paths steps themselves generally **don't count as tasks** (they're built-in utilities, not app actions), though policy can shift over time, so treat that as "cheap," not "always literally zero," and watch your usage. The lesson: **task cost scales with actions × how often the trigger fires.** A noisy trigger feeding a five-action Zap burns through a plan fast. Two ways to control it: filter aggressively so most events stop early, and don't add actions you don't truly need. ```text Zap fires 500 times this month × 3 action steps that run each time = 1,500 tasks (but if a filter stops 60% of runs early after step 1, you pay far fewer than 1,500) ``` Plans come with a monthly task allowance. Cross it and, depending on your plan, Zaps pause or you're moved into overage - so watch the usage meter, not only the calendar. ## Polling vs instant triggers Not every Zap reacts the instant something happens. Triggers come in two flavors: - **Instant (webhook-based):** the app actively pushes Zapier the moment the event occurs. Near-real-time. - **Polling:** Zapier *checks* the app on a schedule - "any new entries since last time?" The check interval depends on your plan, and on lower tiers it can be as long as **every 15 minutes.** So a polling Zap can sit idle for up to that interval before it notices a new row and runs. That's not a bug; it's how polling works. If your test seemed to "do nothing," it may be waiting for the next poll - give it the interval before you panic. When you genuinely need instant reaction (a "thanks for paying" message), prefer an app whose trigger is marked **Instant**, or use a direct webhook. ## Duplicates and missed runs Two failure shapes show up at scale. **Duplicate runs** - the Zap fires twice for one event. Causes vary: a record gets edited and re-detected, an app re-sends an event, or your own two Zaps form a loop (Zap A updates a record, which triggers Zap B, which updates it back, which re-triggers Zap A). Defenses: - Trigger on a *one-time* event ("new charge") rather than a *re-occurring* state ("charge exists") where you can. - Use a **Find or Create** lookup (Phase 2) so a second run updates the existing record instead of making a twin. - Add a Filter that checks a "processed?" marker and skips if it's already set. **Missed runs** - the Zap doesn't fire when you expected. Usual culprits: it was switched Off, a polling interval hadn't elapsed yet, the trigger field was empty so a Filter stopped it, or the connected account's login expired and needs reconnecting. ## When a Zap breaks: errors and replay Zaps break quietly. An app changes, a required field comes through empty, or a reconnect is needed - and the Zap **errors** instead of completing. Where to look and what to do: - **Zap History** is the log of every run: which succeeded, which were filtered out, which errored. This is the first place to check when "the automation stopped working." - **Turn on error alerts.** Zapier can email you when a Zap starts failing. Set this up the day you build anything important; otherwise you find out when a customer does. - **Replay.** When you fix the cause (reconnect the account, handle the blank field), you can **replay** the failed runs from history so the work that got skipped still happens - you don't lose those events. - **Autoreplay** exists on higher plans to retry transient failures automatically. A reliable Zap isn't one that never errors - it's one that tells you when it does and lets you recover the missed work. ## A few high-value recipes These are workhorses, not party tricks. **Lead capture, deduplicated.** ```text TRIGGER → New form submission LOOKUP → Find or create CRM contact by email ACTION → Update contact + notify sales in Slack ``` **Payment to bookkeeping + receipt.** ```text TRIGGER → New successful Stripe charge (Instant) FILTER → Continue only if Amount > 0 ACTION → Add row to accounting sheet ACTION → Send branded receipt email ``` **Inbox triage.** ```text TRIGGER → New labeled email (Gmail) PATHS → Subject contains "invoice" → save attachment to Drive + log it Subject contains "refund" → create a support ticket ``` **Scheduled digest.** ```text TRIGGER → Schedule (every weekday 8am) ACTION → Read yesterday's rows from the sheet ACTION → Post a summary to Slack ``` ## The short version Tasks are actions that run, so filter early and keep action counts lean. Polling means "soon," not "instant" - pick instant triggers when timing matters. Guard against duplicates with one-time triggers and lookups. And the day you build something you'll rely on, turn on error alerts and learn where Zap History lives - because the Zaps that hurt are the ones that fail silently while you assume they're working.