Fill a Typeform — email + name from env

Filling out the same Typeform survey for QA, lead capture testing, or onboarding rehearsal gets old fast — especially when you need fifty submissions to validate analytics tracking. This template fills in name and email from environment variables and advances through the form. Useful for product managers stress-testing form behaviour, marketers verifying campaign tracking, or QA engineers checking that a Typeform-fed CRM actually receives submissions.

How this workflow works

Seven blocks. The pattern is "wait, type, press Enter" repeated until the form is done. Typeform is single-question-per-screen, so each input requires a tab/Enter to advance.

1. manual_trigger — Sidepanel Run. targetTab: "new" opens a fresh tab so the form fill doesn't disrupt your active page.
2. navigate — Opens the URL stored in env.TYPEFORM_URL. You set this once in Settings → Env; the workflow itself contains no hard-coded form URL, which lets you reuse the same workflow for multiple forms by swapping the env var.
3. wait_for — Waits for the first visible non-hidden input (input:not([type="hidden"])). Typeform mounts a hidden input early in page load before the real form renders, so the :not([type="hidden"]) filter avoids matching too early. timeoutMs: 15000 gives the SPA up to 15 seconds to mount.
4. input — Types env.FORM_NAME into the first text input (input[type="text"]). matchFirst: true is critical because Typeform sometimes pre-mounts hidden form steps below the visible one.
5. press_key — Sends Enter. On Typeform, Enter advances to the next question.
6. input — Types env.FORM_EMAIL into the email input (input[type="email"]). The isSensitive: false flag means the value isn't masked in the log; flip it to true if your form has password-style fields.
7. press_key — Final Enter to submit.

After step 7, Typeform shows its confirmation screen and the workflow ends. The tab stays open so you can verify the submission landed.

Customising it for your case

The template covers the simplest two-question shape — name and email. Real forms are messier.

• Add more questions. Extend the chain: another wait_for (for the next input to appear), another input block (with a new env variable or a literal value), another press_key. The pattern repeats N times for an N-question form.
• Use a different form provider. Google Forms, JotForm, and Tally use different DOM structures but the same shape applies. Replace input[type="text"] with the actual selector for the question (open DevTools, copy the selector). For Google Forms, multi-question pages don't need press_key Enter between fields — you can fill all visible fields and only press Enter once at the end.
• Multiple-choice questions. Typeform's choice buttons aren't <input> elements — they're <button> tags with a letter shortcut (A/B/C). Use a press_key block with key: "a" to pick the first option, or insert a click block targeting the choice button's text.

Common gotchas

Three issues bite people. First: Typeform aggressively rate-limits suspected automation. If you submit 50 entries in 5 minutes from the same IP, expect some to silently drop (the form shows "thank you" but the response never lands in your dashboard). Pace runs at least 30 seconds apart. Second: the email field has client-side validation — if env.FORM_EMAIL doesn't parse as a valid email, the Enter press triggers an inline error and the workflow continues anyway, ending without submission. Third: if you set the env vars in Settings but the workflow can't find them, it's because env values are scoped per-extension — confirm you saved them, then reopen the sidepanel.

FAQ

Do I need a Typeform account? Only to create the form. The respondent flow this template automates is fully public — the URL in env.TYPEFORM_URL is whatever public Typeform link you have.

Can I run this on a schedule? Yes, but you probably shouldn't — Typeform's rate limits and bot detection won't appreciate it. This template is built for manual triggering during QA, not production submission generation.

Is my email exposed in the logs? By default the values live in env, which is stored locally in the extension. The workflow log only shows the literal string at runtime — if you flip isSensitive: true on the email block, that value is masked in the log. Automa has a similar env mechanism; the storage location differs.