> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Integrations
> Workflows for deterministic plumbing, agent tokens for contextual action — and how to choose between them.
There are two ways cloudsquid connects to the rest of your stack, and they're for different jobs.
Structured, Zapier-style flows. Triggers, syncs, and pushes. Deterministic: the same input takes the same path every time.
Access-controlled credentials the agent uses directly from [its environment](/concepts/agent-runtime), for actions that depend on judgment.
## Workflows — the plumbing
A workflow is a graph: a trigger, then a sequence of actions. Use it for the parts of the process that shouldn't require thought.
**Triggers** start a workflow:
| Trigger | Fires when |
| ------------ | ------------------------------------------------------------------------ |
| Email | A message arrives in a connected mailbox or a managed cloudsquid address |
| Webhook | An external system posts to your workflow's URL |
| Extraction | An extraction run finishes |
| Table action | Someone triggers a flow on selected table rows |
| Filesystem | A file lands in the project |
| Schedule | On a cron schedule |
| Manual | Someone runs it by hand |
**Actions** do the work: run an extraction, run a reconcile table, call an agent, run Python, branch on a condition, loop over a list, write into a storage table, send an email, update a ticket. Plus connector actions for the app you've connected.
Two shapes you'll build early:
**Intake.** A support ticket arrives → fetch its attachments → create a case in the reconcile table → the agent works it → update the ticket with the outcome.
```
Zendesk ticket webhook ──▶ fetch attachments ──▶ reconcile table run ──▶ update ticket
```
**Master-data sync.** Keep the agent's reference data current without anyone exporting a CSV.
```
SharePoint (scheduled) ──▶ storage table (overwrite)
```
## Agent tokens — the judgment calls
Some actions can't be pre-wired, because what to do depends on what's in the case. Drafting the right reply to a supplier who sent a partial order isn't a template — it needs the facts of that case.
For those, you connect the system and grant the agent a token. The agent then acts from inside its own environment: composing the email with the case's actual data, looking up the record it needs, checking the state of the system before it writes.
**Once a system is integrated, the agent can query it directly** — including your ERP. There is no ceiling where the agent hands off to a fixed connector for the interesting part. What bounds it is the grant: which connectors this reconcile table may use, and what that token is allowed to do.
Outbound actions still pass the [approval gate](/concepts/review-approvals). A drafted email is a draft until someone approves it.
A case doesn't end when the agent sends something, either. When the response lands — the supplier answers, the ticket gets a reply — the agent picks the case back up and carries on from where it left off.
## Choosing between them
| Use a workflow when | Use an agent token when |
| ------------------------------------------------------- | ----------------------------------------------------------- |
| The step is the same every time | What to do depends on the case |
| You're moving data between systems on a schedule | You're composing something (a reply, a summary, a decision) |
| You need a trigger — something must *start* the process | The action happens mid-process, as part of the agent's work |
| The failure mode should be "retry" | The failure mode should be "flag it for a human" |
In practice most deployments use both: a workflow brings the event in and pushes the final result out, and the agent uses tokens for everything in between.
## Connecting a system
Connectors are managed per project under **Connect**. Connect an app once and it's available to that project's workflows and — where you grant it — to the agent.
Beyond the native integrations, cloudsquid connects to hundreds of apps through Pipedream, so most systems your team already uses are reachable without custom work. For systems that expose an MCP server, see [MCP servers](/concepts/mcp-servers).
### Connecting Outlook
Outlook connects per project. You can link multiple accounts to one project, and use the same account across projects.
**Two ways to connect:**
* **Ask the agent** — "Connect my Outlook account". It gives you an authentication link.
* **Via Connect** — open the project's **Connect** panel and click **Connect** next to Outlook. Same authentication flow.
Once authenticated, cloudsquid creates a folder in your mailbox named **cloudsquid\_\[projectname]**. Any email in that folder is picked up and appears in your project within seconds.
**Routing mail into it:**
* **By hand** — move or copy any email into the folder.
* **By rule** — in Outlook, go to **Settings → Rules → Add new rule**, set your conditions (sender, subject keywords, has-attachment), and choose **Move to folder → cloudsquid\_\[projectname]**. Orders, invoices, or anything else then flow in without anyone touching them.
**Managing accounts:** ask the agent "What Outlook accounts are connected?" to list them, or "Disconnect my Outlook account" with the address you want removed.
The full intake recipe — mailbox to worked cases, including routing rules and reply drafting — is in the [inbox intake cookbook](/cookbooks/inbox-intake).
A shared mailbox turned into structured, worked cases.
How the agent uses tokens from inside its environment.
Connector grants, approval gates, and zero retention.
Extending what the agent can reach.