Availability of this feature depends on your license type. Before you get started, check the table below to confirm your license includes this functionality.

Find out more about Evo licenses>

Connectors give the AI access to live data and systems beyond what you've uploaded to a project. Where an uploaded file is a snapshot, a connector is a live link — so the AI can fetch current information, and in many cases take action, rather than working from something that may already be out of date.

Uploads give the AI a snapshot of a file. They work well when the content is stable, such as a contract, a playbook or notes from a single call. They stop working well when the content changes every day.

Connectors keep answers current. If you ask "How many open tickets does this customer have?" against an upload, you get the count from when the file was saved. If you ask the same question through a connected helpdesk, the AI fetches the live count.

Connectors can also take action. An upload is read-only, but a connector can write back to its source. You can use one to raise a ticket, move a candidate to the next stage or start a workflow.

You add all four types from the Connectors tab in a project. The Add connector wizard shows only the steps that apply to the type you choose.

The connectors you can see depend on your organisation's setup and region. Open Add connector to see the options available to you.

If a connector you need isn't listed, it may not be set up for your organisation or region yet.

Some connectors appear in a project without you adding them. Data Spaces works this way when the project has data spaces selected.

You can set up default connectors that are added to every new chat and project. For example, you might want Data Spaces available everywhere.

The flow is the same for all four types. The configuration step changes depending on the type you choose.

You need access to the project. For a custom connector, you also need the server URL and any sign-in details your IT team provides.

Each connector shows a status badge in the list. If the badge shows an error, check the server URL and your sign-in details, then retry from the list.

The AI doesn't check connected systems in the background. Each connector gives the AI one or more tools it can call when your message needs that data.

For example, if you ask "What's open for this customer in the helpdesk?", the AI:

The chat shows which tool was called and whether the call succeeded or failed. Every connector call is also recorded for the AI Platform team's debugging. End users don't see these records.

Every connector you add is another option the AI considers on every message. Add the connectors your work needs and leave the rest off.

Add the connectors your work needs and leave the rest off. A template with many connectors gives the AI a wider set of tools to pick from, which can lead to more wrong choices.

Use an Evo product connector when the data lives in another Evo product. Use a custom connector when it lives anywhere else.

Some connector actions change information in another product, such as creating a record or updating a status. Before the AI makes one of these changes, it stops and shows you an Approval needed card.

Actions that only read information, such as searching or listing, usually run without asking. The connector's owner can change this for each action.

The card names the connector and the action, and explains why the AI is asking. Select Show details to see more about the call. Nothing runs until you choose one of these options.

If your organisation has turned on wider approval choices, the dropdown next to Always allow in this project also offers Always allow [connector] in this project and Allow everything in this project.

A standing permission applies to one action, in one project, for one person. Allowing a search doesn't allow a delete. Once you allow an action, the AI runs it without asking, including actions that send, change or delete information. Use the wider options only for connectors you fully trust.

A different action on the same connector still asks the first time it comes up. In a standalone chat, the chat counts as the project. A workflow that makes many different changes asks several times, then settles down as the common actions are approved.

In a shared chat, an approval card belongs to the person whose message the AI is acting on. Other people viewing the chat can't approve it for them.

If your organisation has turned on wider approval choices for you, you can stop the AI asking before each change in a project.

Before each change, the AI still runs a check that compares the action with your request, and blocks anything you didn't ask for. The shield icon shows which mode you're in.

A Researcher admin sets the wider approval choices for the whole organisation. A Connector Author can also set the approval rule for each tool in an organisation connector.

The connector's owner has the final say on whether a tool asks for approval. A read-only operation can be set to require approval, and a write can be set not to require it. For an organisation connector, the Connector Author sets this for each tool.

Wider approval choices apply per project and per person. Each collaborator approves for themselves, because connector calls run under each person's own credentials.

The change takes effect immediately. The next time that action comes up, the AI asks again.

How a connector handles sign-in depends on its type. This matters when you share a project with collaborators.

Tokens and keys you enter yourself are used only for your account. OAuth sign-ins are always personal.

Templates include the connector setup but not anyone's sign-in details. Each person who creates a project from a template signs in for themselves.

A custom connector lets you connect Evo Researcher to any service that supports the Model Context Protocol (MCP). Use one when the data or action you need lives outside Evo and no third-party connector covers it.

The server must be hosted remotely, reachable over the internet using HTTPS, and must use the Streamable HTTP transport. Servers that support only SSE aren't supported.

Requests to custom servers come from Evo Researcher's cloud servers, not from your computer. Evo Researcher can't reach a server running on your own machine or local network, including a server that gives access to local files. To work with files on your computer, add them as an upload instead.

When you save a custom server, Evo Researcher connects to it and lists its tools to confirm it works. The badge shows the result. A failing badge usually means the URL is wrong, the server can't be reached, or the credentials were rejected. You can retry from the list.

You can save a custom server to your personal library and reuse it across projects, or add it to a single project.

Custom headers are key and value pairs sent with every request. Everyone on the project shares them. Use them for anything the server needs on top of authentication, such as an organisation ID.

You don't set up any OAuth details yourself. Evo Researcher finds them from the server. You only enter the server URL and choose OAuth.

Your connection belongs to you, on this project. A template never shares an OAuth connection, so each person who uses it connects their own account.

Evo Researcher acts as the app you sign in to. It never sees your provider password. It keeps the connection alive by refreshing it in the background. If it can't, for example because the provider issued no refresh token or the connection was revoked, the badge shows Reconnect. Select Connect account again to sign in. To remove your stored connection, select Disconnect.

Some providers won't accept a new application until an administrator has registered the Evo Researcher callback URL. If so, you'll see an error that names the problem and shows the callback URL to give your administrator.

Connector Author is an organisation-level role in Evo Researcher. Like the other delegated roles (such as Org Author, App Author/Publisher and Org Settings), it is granted by an organisation's admin rather than by the Evo platform, so it hands one specific area of org administration to someone without giving them full admin rights. Its purpose is to let a trusted person own the organisation's custom connectors.

A Connector Author can:

Because a connector is only useful once the organisation decides how its tools are governed, the role reaches a little beyond connector setup itself. In the admin area it also unlocks the Chat Approvals section and a focused view of Org Settings limited to the organisation-wide tool-approval choices. In short, it is a "owns the organisation's connectors and the approval policy around them" role, scoped so connector management can be delegated without granting broad administration.

Everything the Connector Author does happens in the admin area, which a normal user never sees — the Custom Connectors section only appears for someone who holds the role. What a normal user gets instead is the result of that work, surfaced on a project's Connectors tab. The connectors an organisation has published are visible to every member, even though only a Connector Author can create or change them.

To use one, a normal user:

The shared definition — the connector's address, authentication method, the tools it exposes and their approval rules — is read-only to the normal user; it was configured once, centrally, by the Connector Author. What the user supplies is their own connection: depending on the connector, they either enter their personal token or credentials into the fields the connector asks for, or sign in through OAuth. This is a "connect once" design — the credential belongs to the individual, is scoped to them, and works wherever a live copy of that connector exists, so they don't have to reconnect per project.

The result is a clean division of labour: the Connector Author builds and governs each connector for the whole organisation, and a normal user simply picks it from the list and plugs in their own credentials to start using its tools in chat.