Build a multi-step browser workflow: navigate, fill, submit in one key
Chain navigation, waits, clicks, fills, and scripts into a single sequence that runs end to end — reliably, from one keystroke.
To build a multi-step browser workflow, chain individual steps — navigate, wait, click, fill, run a script — into one sequence bound to a single key. Each step hands off to the next, so a small procedure you repeat all day runs end to end from one press. The reliability comes from waits between steps, not from hoping the page keeps up.
The tasks that waste the most time are rarely one action; they are a short procedure: go here, wait for it, click that, fill the form, submit. Doing it by hand is a dozen small motions you repeat without thinking. This guide covers the step types you can chain, how to make a sequence dependable, and how to test it before you rely on it.
The step types you can chain
A sequence is built from a handful of step types, each doing one thing. Navigation moves you to a page, a wait pauses for it, a click or fill interacts with it, and a script step handles any custom logic. Combining them in order is what turns separate actions into one workflow.
| Step | What it does | When to use it |
|---|---|---|
| Navigate | Go to a URL | Start the flow on the right page |
| Wait / wait-for | Pause until ready or an element appears | Between slow steps |
| Click | Press a button or link | Advance the UI |
| Fill | Type into a field | Enter data or a template |
| Run JavaScript | Execute your own code | Logic the other steps cannot do |
Sequence or single macro?
A recorded click macro and a sequence overlap, but they are not the same tool. A macro captures actions as you perform them on one page; a sequence is assembled step by step and is built for spanning pages, waiting, branching, and dropping in a script step. Reach for a sequence the moment a task crosses pages or needs to make a decision.
| Need | Recorded macro | Multi-step sequence |
|---|---|---|
| Repeat clicks on one page | Ideal | Works, heavier |
| Move across several pages | Fragile | Built for it |
| Wait for slow loads | Basic delays | Wait-for steps |
| Branch on what the page shows | No | if/else |
| Run custom logic mid-flow | No | JavaScript step |
Chain the steps
You build a sequence by adding steps in the order you would perform them. Navigate to a URL, wait for the page, click an element, fill a field, then run a line of your own JavaScript if you need it. Each step hands off to the next, so the whole flow runs in order without you in the loop.
- Add a navigate step to land on the starting page.
- Add a wait-for step so the sequence pauses until the page is ready.
- Add the click and fill steps that do the actual work, in order.
- Add a JavaScript step for any logic the other steps cannot handle.
- Bind the finished sequence to a trigger key.
Make it reliable
The reliability of a sequence comes down to timing and branching. Real pages are not instant, so per-step delays and wait-for steps let the flow pause until the page is ready instead of firing blind, and if/else branching handles the cases that differ so one sequence covers more than a single happy path.
Waits over guesses
A wait-for step that pauses until an element appears is more robust than a fixed delay, because it adapts to how fast the page actually loads that time. Detecting when an element appears is exactly what the browser’s MutationObserver is built for — watching the page for changes rather than guessing. Use fixed delays only where timing is predictable and wait-for steps everywhere timing varies.
Branch for the exceptions
Add if/else branching where a step depends on what the page shows — take one path when a field is present, another when it is not. That keeps a single sequence working across the real variations instead of breaking the first time reality differs from your recording.
Test before you bind it
Test-run the whole sequence before binding it to a key so a mis-timed or mis-targeted step surfaces while nothing is at stake. The test replays every step in front of you, so you can adjust a delay, fix a target, or add a wait-for before the sequence runs for real.
- Navigate, wait, click, fill, and run JS in one ordered flow.
- Per-step delays and wait-for steps handle slow pages.
- Branching and a test-run keep the sequence dependable.
A worked example: file a ticket in one key
Take a support task that spans two pages — open a queue, grab the top ticket’s ID, and log a triage note on it. By hand that is navigation, a copy, a paste, and a submit. As a sequence it is one key.
- Navigate to the ticket queue.
- Wait-for the list to render.
- Run a script step that reads the top ticket’s ID off the page.
- Navigate to that ticket using the extracted ID.
- Fill the triage note with a template, then click submit.
Every step here is a capability you can map on its own — a shortcut, a script, a template. The sequence is what makes them run as one procedure instead of five separate presses, which is the whole reason to build one.
Frequently asked questions
What is the difference between a click macro and a sequence?
A click macro records actions as you perform them; a sequence is built step by step from typed step types — navigate, wait, click, fill, run JavaScript. Sequences give you finer control over timing and branching, which makes them better for multi-page workflows that need to be reliable.
How do I stop a workflow from breaking on slow pages?
Use wait-for steps that pause until a specific element appears, rather than fixed delays that guess how long a page takes. A wait-for adapts to the actual load time each run, which is the single most effective way to keep a multi-step sequence dependable.
Can a sequence handle pages that differ each time?
Yes. Add if/else branching so a step takes one path when a value or element is present and another when it is not. That lets a single sequence cover the real variations of a task instead of only the one path you happened to record.
Can I mix custom code into a no-code sequence?
Yes. A JavaScript step can sit anywhere in the sequence, so code handles only the part that needs logic — reading a value, doing math — while navigation, waits, clicks, and fills stay no-code. You are not forced to script the whole workflow to script one piece of it.
How do I know a sequence works before I depend on it?
Test-run it before binding it to a key. The test replays every step in front of you, so you can confirm each one lands and adjust timing or targeting while nothing is at stake — rather than discovering a broken step in the middle of real work.
Map the procedure once and a multi-step task collapses into a single keystroke.