Use case · Systems without an API
A web portal without an API, scraped to Sheets on a schedule — with change alerts
A Studio bot logs into the portal on a schedule, navigates to the page, reads the table (pagination included) and returns rows. The workflow writes them to a sheet or table, diffs them against the previous run and posts only what changed — new, closed, delayed — to the channel. When the portal has an export or a hidden API, the bot uses that instead of the screen.
- Who it is for
- Procurement, logistics, finance and operations teams who check the same portal every day — a supplier's order status page, a carrier's tracking, a regulator's publication list, a customer's extranet — and copy numbers into a sheet.
- Systems involved
- Any web portal (Studio web automation)Google Sheets / AW TablesSlack / TeamsAI Workflows
How the run goes
5 steps · logged per run
- Trigger01
Every 2 hours
Or on demand from Slack
- Bot02
Log in and read the table
Pagination, filters, downloads
- Agent03
Diff and classify changes
New / changed / closed, priorities
- System04
Update sheet or table
Full snapshot + change log
- System05
Post changes
Slack / Teams, only the delta
How it runs, step by step
- 1
Before anything is built, the portal's terms of service are checked; where automated access is forbidden, we say so and stop. Where the portal offers CSV export or an undocumented JSON endpoint behind the login, the bot uses that — faster and more stable than reading the page.
- 2
A schedule triggers the run. The bot logs in with its own portal user, applies the filters, reads the table page by page, and downloads attachments if the use case needs them.
- 3
The workflow writes a full snapshot to the sheet or table with the run timestamp, then an agent compares it to the previous snapshot and classifies changes — new rows, status changes, delays past a threshold — in plain language.
- 4
Only the delta is posted to Slack or Teams, each line with the row link; a weekly summary goes to email.
- 5
If the portal changes layout or the login fails, the bot stops and the run posts the screenshot — the same morning, not a week later when someone notices the sheet stopped moving.
Limits — what this does not do
- Terms of service decide whether a portal can be automated at all; some public-sector portals forbid it and are excluded.
- CAPTCHAs are not bypassed; a portal that shows one on every login is not a fit.
- Diff-based alerts need a stable key per row (order number, tracking ID); portals without one get snapshot-only mode.
Questions about this process
It depends on the portal's terms. We read them first and prefer exports or APIs behind the login over reading the page; some portals are declined.
The run pauses for a person to approve the code, like the bank statement use case; a portal that demands it on every login runs attended or not at all.
Yes, that is the data-entry variant: rows from a sheet entered into the portal with on-screen verification.
Related use cases
Build this on your systems in a guided sandbox.
Tell us the process; after a 30-minute call the sandbox is ready from 24 hours, and we build the first run with your team.