Type it once. Let the flow type the other nine hundred.
Some systems have no API and never will — but they have a form, and someone on your team is allowed to fill it in. Record that person doing it once. Parameterise what they typed. Then run the same flow for every row in the spreadsheet, with a verdict and a screenshot for each one.
Four steps, and only the first one is manual.
1 · Record one row
Drive the real system in a live browser — log in, open the form, fill it, submit, confirm. Every action becomes a step with a durable locator and a screenshot.
2 · Parameterise
Swap the values you typed for named inputs. The flow now declares a schema: which fields it needs, which are secret, and what it reads back.
3 · Run per row
Feed it your rows. Each row is one run of the same flow, queued so runs cannot collide, paced so the target system is not hammered.
4 · Read the results
A verdict per row, the value the flow read back, and the screenshot and trace that prove it. Re-run only the rows that need it.
What a row comes back with
The shape of a per-row result. Illustrative — we are pre-launch, these are not real customer records.
| Row | Verdict | Read back | Evidence |
|---|---|---|---|
1 · ACC-1041 | PASS | Confirmation RCV-88213 | screenshot · trace |
2 · ACC-1042 | PASS | Confirmation RCV-88214 | screenshot · trace |
3 · ACC-1043 | FAIL | "Account is closed" | screenshot · trace |
4 · ACC-1044 | UNMEASURED | page never settled | screenshot · trace |
Row 3 is a real answer from the system — the flow saw the refusal and reported it. Row 4 is the one most tools get wrong: nothing was observed, so nothing is claimed. Why a verdict needs a third state →
Three shapes of bulk data entry
Filing into a system with no API
A vendor portal, a regulator's submission form, an insurer's claim screen. You have a spreadsheet of things to file and the only way in is the form. One recording covers all of them.
Migrating records between two apps
Read a record out of the old system and type it into the new one — a single flow that spans both, so the values never round-trip through a person. The read-back is what proves the record landed.
Bulk updates in a legacy admin
Nine hundred records need one field changed and the UI is the only thing that can write it. The flow does the click path once per record and tells you exactly which ones did not take.
All three are cases where the screen is the only interface. Where you would rather call it than schedule it, the same flow becomes an HTTP endpoint.
What this will not do
- You have to be authorised. Your credentials, your account, work you are permitted to do. QA Reef automates a person's legitimate access; it does not create access.
- No CAPTCHA solving, ever. A challenge, an unexpected auth wall or an interstitial stops that row, keeps the screen as evidence, and hands it to a person.
- Politeness is the default, not a setting you must remember. One warm browser per site, calls queued so they cannot collide, a deep queue answers
429instead of piling on, and every run has a wall-clock budget. - A row that could not be measured says so. UNMEASURED, never a fabricated success and never a false failure.
- No guessing when it counts. When a flow runs as an endpoint, the model and OCR heal tiers are off and nothing is written back — a job that writes data has to be deterministic. The worst failure mode is not an error, it is a plausible answer forever.
What runs today, and what is next
Live now
- Recording a workflow in the hosted browser, with durable locators and a screenshot per step
{placeholder}inputs, with a declared schema of required fields, secrets and outputs- Running the flow over HTTP, one call per set of values, with JSON back
- A shared run queue so many runs execute one at a time rather than fighting
- Verdict, screenshot and trace stored per run
Roadmap
- A CLI flag that walks a CSV for you, instead of you looping over the rows
- A per-row results table in the app, with one-click re-run of the failed rows
- Talking to the agent to generate the variants and error cases from one recording
Until then the loop is yours to write: one call per row, and the results are already per-row.
Questions about bulk data entry
How do I automate data entry from a spreadsheet?
Do the job once by hand in a live browser while QA Reef records it. The values you typed become named inputs, the flow declares them as a schema, and then the same flow runs once for every row of your data — each run producing its own verdict, screenshot and trace. Nothing is scripted against selectors by hand.
Does the target system need an API?
No. That is the point. If a person can complete the task in a browser, the recorded flow can complete it too — vendor portals, frame-era ERPs, internal admin tools and government systems that were never built to integrate with anything.
What happens to a row that fails?
It comes back FAIL with the error and the screen at the moment it broke, or UNMEASURED if the run never got a clean look at the page. A row is never reported as filed unless the flow's assertion actually saw the confirmation. A partial, honest result beats a complete, fabricated one.
Is bulk browser data entry allowed?
You must be authorised to use the target system — your own credentials, your own account, work you are permitted to do. QA Reef never solves CAPTCHAs and never attempts to defeat an access control. If a site challenges the agent, the run stops, keeps the screen as evidence, and hands it to a person.
How fast does it go, and can I slow it down?
Runs are deliberately paced rather than parallel-blasted. One warm browser is kept per site and calls to the same site are queued so they cannot collide; a deep queue answers 429 rather than piling on, and each run has a wall-clock budget. Being a polite, single-lane client is the default.
Bring us the spreadsheet.
Tell us what your team types into what, and we will record it once and show you the per-row result.
Talk to the team