OpenAssistantAPI
→

Connection policies

Control which external services your users can connect to their assistant.

What connections are

A connection gives a user's assistant access to an external service — their Google Calendar, Microsoft Outlook, or a custom integration. Without a connection, the assistant can't read availability, send emails, or interact with those services on the user's behalf.

Org admins control which connections are available to users, and how much access each one grants. You manage all of this under Organization → Connections.

Enabling and disabling connections

The Available Connections list shows every connection your organization can use, grouped by category. All connections start Enabled. To take one away from everyone in your organization, set its dropdown to Disabled. Connections the developer has already turned off don't appear in the list.

When a connection is disabled:

  • It disappears from Connections for all users in the org
  • No one can create a new connection of that type going forward
  • If you re-enable it, users are able to create new connections of that type again

This does not touch connections that already exist — see Reviewing what's connected below for what disabling a connection does and doesn't do to existing connections.

Limiting how much a connection can do

Connection Resource Access sets the maximum permission level for each provider's resources. For each one you choose Off, Read or Read & Write (click the active choice again to clear your setting and fall back to the default), and you can lock it so each user's own preference is ignored. The resources are:

ProviderResources
GoogleCalendar, Contacts, Email, Drive
MicrosoftCalendar, Contacts, Email, Teams
AppleCalendar
SlackMessaging
ZoomVideo
AsanaProjects
HubSpotCRM
IMAP, AgentMailEmail

This is how you allow, say, Google Calendar but not Gmail: there is no single "block Google" switch, and you set each resource independently.

MCP Servers has one default access setting (any value other than Off counts as enabled) with its own lock, which stops users from switching MCP servers on or off.

Team admins can set their own values for their team, but cannot change anything you've locked.

Custom connections

If you use an internal tool or a SaaS product that isn't in the list, you can add it yourself. Under Custom connections:

  • Allow members to add their own custom connections — when off, only org admins can add custom connections, which are then visible to everyone. If you have never set this, members can add their own unless Users can create skills is turned off in Skill policies, which also stops them adding custom connections.
  • Add an org-wide custom connection — adds a connection for the whole organization. Custom connections show a custom label in the list and have a remove button.

Microsoft 365 and Teams work differently

Below the list, Microsoft 365 and MS Teams appear as cards you configure once for the whole org (a card reads "Not configured" if the developer hasn't made it available).

Microsoft 365 uses a single Azure AD app registration for org-level access. Enter your Tenant ID and Client ID, and choose a Credential — a client secret, or a generated x.509 certificate you upload to your app registration. You can then turn on three capabilities, each in Delegated or Application mode:

  • Coworker Calendars — read coworker availability without provisioning a seat (app-only; free/busy only, no changes to their events).
  • Scheduling — full calendar read/write and contact lookup for scheduling.
  • Custom Assistants — for assistants that draft replies, manage contacts or send email on a user's behalf.

The Microsoft 365 panel also has guided steps for limiting scheduling and assistant-inbox access to a specific group in your tenant.

Microsoft Teams connects your company's workspace once for the whole org — see Slack & Teams for what that setup does from a user's side. A messaging connection can be active at the org level or at a team level, not both, and can be moved from the org to a team. Once connected, anyone in the scope can message the assistant there; there's no per-user toggle to manage.

Default approval posture

The Autonomy Matrix at the bottom of the Connections page sets the default approval mode per resource for all teams in the org, with quick presets. Lock a row to stop team admins from changing it. See Supervision for what each mode means.

Reviewing what's connected

There's no per-user view today that lists which individual members have connected which service, or lets you revoke one member's connection on its own — connection controls in this portal operate at the connection level (see above), not per user.

The closest lever available is disabling the connection entirely, but note what that does and doesn't do: it removes it from Connections so no one can create a new connection of that type going forward. It does not suspend or revoke connections that already exist — a user who connected before you disabled it keeps using it. There's currently no admin control that force-disconnects one user's existing connection.

Removing someone from the org or team doesn't do this either. It clears their team-scoped assistants and any org/team permission overrides, but it doesn't delete their user account, their assistant, or any of their existing connections — those keep working exactly as before. If you need to fully cut off a departing user's access to a connected service, that has to be done at the provider (e.g. revoking the app's access in their Google/Microsoft account) or by deleting the user outright.