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 OAuth 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 connection types are available to users. Blocking a connection type removes it from the Connections page for everyone in your org — users can't add it even if they try.
Configurable connection types
| Connection | What it enables |
|---|---|
| Google — Calendar | Read/write calendar events, schedule meetings |
| Google — Gmail | Send and read emails via the user's Gmail address |
| Google — Drive | Access and attach files from Google Drive |
| Microsoft — Outlook Calendar | Read/write Outlook calendar events |
| Microsoft — Outlook Mail | Send and read emails via Outlook |
| Microsoft — OneDrive | Access and attach files from OneDrive |
Each of these can be independently enabled or disabled at the org level under Organization → Connections.
Slack and Teams work differently
Slack and Microsoft Teams aren't per-user connections your users individually authorize, so they don't appear in the table above. Instead, you connect your company's Slack or Teams workspace once, for the whole org — see Slack & Teams for what that setup does from a user's side. Once connected, anyone in the org can message the assistant there; there's no per-user toggle to manage.
Blocking a provider entirely
To block all Google connections, disable each Google sub-item (Calendar, Gmail, Drive) individually. There is no single "block Google" toggle — this is intentional, since some organizations may want to allow Google Calendar but not Gmail.
When a connection type is blocked:
- 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 the connection type, 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 type does and doesn't do to existing connections.
Pre-authorizing connections org-wide
For Google Workspace and Microsoft 365 tenants, you can pre-authorize connections at the org level using service accounts or admin consent flows. This means users get calendar and email access without going through individual OAuth consent — their assistant is ready to use on first login.
Contact platform support to configure org-wide pre-authorization. It requires admin consent in your Google Workspace Admin Console or Microsoft Entra admin center.
Custom OAuth connections
If you use an internal tool or a SaaS product that isn't in the list above, your developer may have configured custom OAuth connections. These appear in the Connections page alongside the built-in ones and can be enabled or disabled the same way.
Custom connections are configured at the platform level. If you need a connection that isn't available, contact platform support.
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-type level (see above), not per user.
The closest lever available is disabling the connection type entirely, but note what that does and doesn't do: it removes the type 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 the type 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.