Every automation that touches a website eventually faces the same moment: the page is not what it was when the automation was written. Some of them fail loudly. The bad ones fail quietly and write a wrong value into your spreadsheet.
That is the whole reason the “recorder” model is a trap for browser work. Recording is easy to author and impossible to maintain, because a recording captures how you moved the mouse, not what you were doing.
What a recording actually stores
Open any classic macro file and you will usually find three things: a locator that is either an absolute DOM path or an x/y coordinate, a fixed sleep between actions, and no post-condition. Each of those is a way of saying “I am betting this page never changes”.
- Coordinates break on layout. A new banner above the table moves the button eleven pixels and the click lands in a dropdown.
- Absolute paths break on markup. Add a wrapper
<div>andbody > div:nth-child(4) > spanis now pointing at the cookie notice. - Fixed sleeps break on load. Two seconds is a waste on a good day and a failure on a slow one, because the page is not a clock.
- No post-condition means nothing notices. The macro pressed Submit; nobody checked that the record was actually created.
Three questions that decide whether an automation survives
You can ask them of any tool before you buy it or trust it, and the answers tell you everything:
- How is the target identified? A stable selector, a label, an accessibility name, or a pixel position?
- What happens when the element is not there yet? Does it wait for a condition, or does it sleep and hope?
- What stops a wrong value from being saved? Is there a check you can read, or only the result you notice next week?
What ORCA does about each
ORCA is a browser extension with a visual element picker and a rule engine, so the answers are structural rather than “record it again and be more careful”.
Targets. You pick an element while the page is in a normal state, and ORCA stores a locator and the element's label. When the layout shifts, it uses the stored label and structure to re-locate the control instead of clicking where the mouse used to land. That is the practical difference between the rule engine and a macro recorder: a recorder replays gestures, ORCA re-finds intent.
Timing. Steps take a wait or a condition, not a sleep. The rule engine supports dynamic delays and condition-based execution — “click Next while it exists and is enabled” — and a failed action can be retried before the run gives up on that row.
Verification. Every run writes a log: each step, its status, retries, timings, and which extractions came back empty. That log is the post-condition. On a page with a CAPTCHA, a 2FA prompt or a confirmation gate, the run pauses and tells you instead of trying to get past it.
Where an API connector is still the better tool
Being browser-based is not a superiority claim. If the system you are automating has a real API, use it — it is faster, atomic, idempotent and it does not care whether your laptop is awake. The reason tools like ORCA exist is that a large share of real work happens on pages with no API at all: a supplier portal, a government filing form, a 2011 intranet, a job board, a clinic scheduling screen.
| Question | Macro recorder | API connector | ORCA |
|---|---|---|---|
| Needs an API to exist | No | Yes | No |
| Survives a layout change | Rarely | Yes — markup is irrelevant | Partly — re-locates the stored target |
| Uses your logged-in session | Sometimes | No — separate credentials | Yes |
| Writes where the work is | Yes | Only where the API allows | Yes |
| You can read what it did | A video, maybe | Request logs | Per-step run log |
| Safe for high-frequency polling | No | Yes, with rate limits | No — a human page should be hit like a human |
How to write it so it holds
- Pick targets on a page in its ordinary state, not mid-error or mid-loading.
- Add a wait and one retry to any step that touches a lazily loaded region.
- Put a condition on anything that loops over rows, so an empty page stops the run instead of inventing one.
- Run once with the log open and read it top to bottom. This takes two minutes and catches most of what would otherwise bite you in a month.
- Make scheduled runs idempotent: re-running should be harmless, because a scheduled run occasionally fires when it should not.
And keep the scope honest. Automation is for the work you are allowed to do, at a pace that does not hurt the site you are using — the extension paces actions and pauses at verification gates for exactly that reason.
If you want a concrete starting point, the template library writes these steps out for three real jobs, and the quickstart walks the first one from an empty panel. For what the extension can see and where your data goes, the permissions page is the plain version.