Connections
A connection is a saved, authenticated link to an external system. It holds the credentials, and nothing else: it does no work of its own, produces no output, and never appears on the canvas.
A connection exists because a node depends on it. That is the whole idea, and it is worth getting the order right. You do not start by adding connections and then look for something to do with them. You add the node you want—a Jira action, a Slack message, a content trigger—and it asks for a connection of the type it needs. The connection is the dependency, the node is the point.
The reason it is a separate thing at all, rather than a credential typed into each node, is reuse. Authenticate once and every node of that type can use it, across every automation. Rotate a token in one place and every step that depended on it keeps working.
Manage connections on the Connections page. It lists your existing connections with their status and lets you create a new one by choosing a type. A connection that has lost its authentication is flagged there, which is where to look when steps that used to work start failing.
Creating and authorizing one
How you authenticate depends on the system, and there are two shapes:
- Authorize in the provider. The connection shows a Connect button. Clicking it sends you to the provider to sign in and grant access, then returns you with the connection active. A Disconnect action tears that authorization down.
- Paste a credential. The connection stores a token, key pair, or client secret that you enter directly. It becomes usable as soon as those fields are saved.
Once active, a connection shows a confirmation with the connected identity—which is worth reading, because it tells you whose access the automations using it will have.
Some connections need groundwork before you can create them at all: an administrator registering an application with the provider and handing you its credentials, an account holder issuing a key, or a permission granted on the far side. Each integration's page covers what its connection needs.
What a connection carries into a run
One thing about a connection is easy to overlook.
A connection acts as somebody. Everything an automation does through a connection runs as the identity that authorized it, with exactly that identity's permissions—it can read and change whatever that account can, and nothing more. If a step fails with a permission error, the account behind the connection is usually the thing to look at, not the step.
One connection, several nodes
A connection type is not tied to a single node. Adding one Brightspot connection lights up a content trigger, several content actions, and a remote agent step; adding one Jira connection lights up both the Jira trigger and the Jira action. That is normally what you want—one authorization, one identity, one place to rotate a credential.
Having more than one connection of the same type is equally normal, and each node picks which it uses. Two Brightspot connections point at two different CMS instances; two Slack connections reach two different workspaces. Because the agent-based steps run in the automation engine itself, a single flow can hold connections to several environments at once—reading from one instance and writing to another.
Which nodes each connection powers
Read this table backwards from the usual direction: it starts from the connection and names what depends on it. Use it to answer "if I add this connection, what can I then build?"—or, coming from a node that is asking for a connection you do not have, to find where to set one up.
| Connection | Nodes that depend on it | Where it is documented |
|---|---|---|
| Brightspot | The Content trigger; the Content, Content Query, Content Fetch, Content Script, and Remote AI Agent actions | Brightspot CMS |
| GitHub | The GitHub trigger and the GitHub action | GitHub |
| Jira | The Jira trigger and the Jira action | Jira |
| Slack | The Slack Message action; also the channel a human-in-the-loop request can be asked and answered in | Slack |
| Microsoft Teams | The Teams Message action; also the channel a human-in-the-loop request can be asked and answered in | Microsoft Teams |
| Custom OAuth | No node of its own. It authorizes any service that speaks OAuth 2.0, for steps that call that service directly | Connections in the built-in node catalog |
| OpenAI | An AI provider account. Serves the model behind the AI Agent action and the AI Judgment condition | OpenAI |
| AWS | An AI provider account serving Bedrock models, and the account the AWS AgentCore action invokes hosted agents through | AWS |
| Azure | An AI provider account. Serves the model behind the AI Agent action and the AI Judgment condition | Azure |
| Gemini | An AI provider account. Serves the model behind the AI Agent action and the AI Judgment condition | |
| Google Cloud | An AI provider account. Serves the model behind the AI Agent action and the AI Judgment condition |
Two things need no connection at all. The Email action sends through delivery an administrator configures once for the whole deployment, and the OpenAPI action names the specification it calls on the step itself. Both are on the Integrations index.
For each connection type field by field, see Connections in the built-in node catalog and the connection section at the end of each integration's page.
Provider accounts for AI
Five of the connection types above hold an account with an AI provider. They are connections like any other—created and authorized on the same page—but what depends on them is different: rather than a trigger or an action, they serve the model an AI step's work runs on.
Adding one means AI work runs on your credentials with your provider. The tokens land on your bill rather than being counted as platform usage, and your content travels only to the provider you chose. Which account a particular step uses, and how that is decided, is covered in AI agents and models.
MCP servers
The Connections page also manages MCP servers—the tool sources an AI agent draws from as it works. They sit alongside connections but are a different kind of thing, and the difference matters when you are setting one up.
A connection authenticates the automation engine to a system that its own triggers and actions call directly. An MCP server gives an agent a set of tools it can decide to call for itself, and it authenticates against its own endpoint, separately. A connection to a system does not authenticate an agent to that same system's tool endpoint—the two are configured independently even when they point at the same place.
A server's name is also how its tools are identified to the agent, so give each one a short, recognizable name.
To add an MCP server:
- On the Connections page, under MCP Servers, select a server type from the list and click +.
- Complete the fields for that type.
- If the server uses OAuth, click Connect and authorize access. The server shows Connected when authorization succeeds.
Which servers an agent may use is set on the agent and, additively, on the step. For each server type field by field, see Connections in the built-in node catalog.