# Connecting Systems (/concepts/connecting-systems)
Connecting a system means giving a Trelium agent a safe way into a tool you already use. You do it once per system. After that, the agent can look things up and do work there, and your records stay where they are.
Connecting is not migrating. Your order system, inbox, and other tools stay
the official home for your data. The agent reads from them and writes results
back. See [Integrations](/concepts/integrations) for the bigger picture, and
[Security & Data](/platform/security-and-data) for how Trelium handles the
data an agent works with.
## Six ways in [#six-ways-in]
Every system is different, so Trelium has six ways to connect. Most tools work with more than one, and the Trelium team helps you pick during setup. Open the one that sounds like your situation.
Many modern tools can hand out an **API key**. Think of it as a spare key cut just for Trelium: a long, generated password that lets the agent use the tool's built-in connection for other software.
Because the key is separate from anyone's own login, many tools let you limit what it opens and take it back without affecting your team's accounts.
**Your side:** an admin creates the key in the tool's settings and passes it along during setup.
You have seen this before: "Sign in with Google" or "Allow this app to access your account". The tool itself asks you to approve what Trelium can do, so Trelium never sees your password.
It is common for email, calendars, and file storage.
**Your side:** you follow the tool's own sign-in page and approve the permissions it lists. To take access away later, you do it in that tool, not in Trelium.
Sometimes the facts an agent needs are stored in the system's database but the tool never shows them. In that case Trelium can read the database directly. This suits checking and reporting work, such as reconciling records.
**Your side:** your IT team creates a login for the agent and decides what it can see. Read-only access is common.
Older systems often cannot talk to other software but can produce a spreadsheet or CSV file. A **file drop** is a shared folder where that file lands on a cadence your team agrees. A scheduled agent picks it up from there. These docs treat that as a scheduled pickup, not a separate product guarantee that every new file instantly starts a run.
**Your side:** your team sets up the export and the shared folder, and agrees on the file layout and how often it arrives.
If orders, invoices, or requests already land in an inbox, the agent can watch that inbox and start work when a new message arrives. Nothing else about how your customers or suppliers work has to change.
**Your side:** you connect the mailbox the agent should read. A shared mailbox, like orders@ or accounts@, works better than someone's personal one.
For old portals and tools that were never built to share anything, a browser agent does what a person would: it logs in, opens pages, and fills in fields.
**Your side:** you create a separate user account for the agent, just as you would for a new hire. That keeps its activity easy to tell apart from your team's. See [Browser Agents](/concepts/browser-agents) for how it works once it is logged in.
In Trelium, the systems you have connected are listed under **Integrations**, on the **Connected apps** tab. Each app shows how many workflows use it and how many accounts are connected, and **Connect an app** adds a new one.
The Connected apps tab under Integrations. Apollo is connected with an API key, and each app shows how many workflows use it.
## What a connected agent can do [#what-a-connected-agent-can-do]
Once a system is connected, the agent gains three abilities.
Look things up, such as an order status, a customer record, or a balance.
One job can read from several systems in turn.
Create and update records, but only as far as the connection allows. A
read-only connection means read-only work.
A connection can also be where work starts, such as a new email in a
connected inbox. See Triggers & Inputs for what can start a run.
Being connected does not mean the agent acts alone on everything. Anything
your process reserves for a person, such as approving a change before it is
saved, still goes to that person. See
[Human in the Loop](/concepts/human-in-the-loop).
## Example: checking last night's shipments [#example-checking-last-nights-shipments]
Say your warehouse ships orders all day and saves a shipment file to a shared folder every night. Two connections cover the whole check: the folder, and your ERP. A schedule starts the agent each morning.
### The agent picks up the file [#the-agent-picks-up-the-file]
On its morning schedule, the agent opens the newest shipment file in the shared folder.
### The agent checks each line [#the-agent-checks-each-line]
For every line in the file, the agent looks up the matching order in your ERP and compares the item, quantity, and address.
### Mismatches are flagged [#mismatches-are-flagged]
Lines that agree need nothing more. Lines that do not are flagged, along with what the ERP expected and what the file said.
### Your team decides [#your-team-decides]
Your team reviews the flagged lines. Nothing is corrected in the ERP until a person approves it.
The folder brings the data in and the ERP supplies the facts to check it against. The automatic part stops at the flag. A person decides what happens next.
## Where to go next [#where-to-go-next]
What an integration is, and why connecting never means migrating.
How an agent works inside a web interface when there is no API.
Where approvals fit when an agent reads and writes in your systems.
What starts a run, and what the agent receives when it starts.