Browser Agents
Trelium can automate software that has no API. A browser agent works in the tool's web interface the way a person logging in would, using a dedicated account you create for it.
Yes, Trelium can work in software that has no API. A browser agent works in the tool through a web browser, much like a person logging in: it signs in, moves through the pages, and reads and fills in what is on screen. That is a plain-language description of how it works, not a promise that every login challenge or interface change will succeed without help. Your team keeps using the same system, and nothing is migrated or replaced.
Think of a new hire with a login
A browser agent gets its own account in the tool, just like a new team member would. It can see and do what that account allows, and nothing more.
What a browser agent is
A browser agent is how a Trelium agent reaches a system that offers no API, or whose API does not cover what your team does by hand. It uses the system's web interface, the same one your people use.
For how this compares with an API connection, see Integrations. For how a system gets connected, see Connecting Systems.
What a browser agent can do
With its login, the agent can:
- Log in to the system.
- Navigate between pages.
- Fill in fields.
- Read what is on screen.
What it can do in a particular system depends on that system and on what its account is allowed to see and do. If you need to confirm a specific action in a specific tool, ask during setup.
When browser automation is the right choice
If a system has an API and the API covers the job, use the API. Browser automation is for everything else:
- Systems with no API.
- Systems where the API does not cover what your team does by hand.
- Work where your team's real process lives in the interface, such as a portal that only shows certain information on its pages.
Access and security
A browser agent uses a dedicated user account that you create. This shapes what the agent can reach and how you can see what it did:
- Access is the account's access. The agent can see and do what that account can see and do, and nothing more. If the account cannot reach a page or action, neither can the agent.
- Activity is distinguishable. Because the agent has its own account, what it does stays separate from what your team does in the same system.
- Passwords are kept in a vault. The agent's login is stored in a 1Password vault, not in the workflow itself.
You set the limits
You decide what the account can reach when you create it, so you can give it only the access the work needs.
When an interface changes
Websites change: a button moves, a page gets a new layout, a menu is renamed. A person would look around and find the new spot, and so does the agent. It reads the page the way you do, so it can usually work out a changed interface on its own instead of needing someone to rebuild the workflow.
Sign-in steps
Some tools ask for more than a password, such as a verification code, a CAPTCHA, or a multi-step sign-in. The agent works these out the way a person would, using credentials kept in its 1Password vault. If a particular tool has an unusual sign-in, mention it during setup so it can be confirmed ahead of time.
A stopped run beats a wrong guess
If the agent cannot tell what a page is asking for, it does not guess. The run stops and surfaces as an exception so your team can look at what happened. See Validation & Exceptions.
Example: checking order status on a supplier portal
Say a supplier gives you a portal to look up the status of your orders, and the portal has no API. Today someone on your team logs in each morning, searches for each open order, and copies the status into your own records.
A browser agent can do that lookup using its dedicated account:
An animation of the lookup below, in a made-up portal: the agent signs in, searches for an order, and reads its status on screen.
Log in
The agent signs in to the portal with its own account.
Look up each order
It goes to the order search page and looks up each open order.
Read the status
It reads the status shown on screen.
Record what it found
It records the result, so your team can see what was read and where.
If the portal is redesigned, the agent adapts to the new layout. If it ever cannot tell what a page is asking for, the run stops and raises an exception. If your process needs a person to approve a step, such as acting on a delayed order, the agent waits for that approval. Reading the portal is something the agent does. Approving is a decision a person makes. See Human in the Loop.
Where to go next
Integrations
How API and browser connections differ, and how agents work inside your existing systems.
Connecting Systems
How systems are connected and what the setup involves.
Validation & Exceptions
What happens when a run stops, and how your team reviews it.
Security & Data
What an agent can reach and where your data stays.