> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect Google Workspace and Microsoft 365: calendars, contacts, and mail for CRM and agent tools

> Connect Google Workspace or Microsoft 365 as CRM data sources for your agents — OAuth scopes and consent, what Orbit ingests, the connector-aware CRM tool catalogue, health monitoring, and revoke.

# Connect Google Workspace and Microsoft 365 for CRM and agent tools

Two shipped integrations, **Google Workspace** and **Microsoft 365**, read calendars, contacts, and mail metadata into Orbit's CRM surfaces and the agent tool catalogue. Both are productivity integrations that behave like CRM providers: Google Workspace covers Gmail, Google Calendar, and Google Contacts; Microsoft 365 covers Microsoft Graph — Outlook Mail, Outlook Calendar, and Outlook Contacts.

This guide covers connecting either provider for CRM and agent-tool use, end to end. If you only want them for team presence (you appear busy in Orbit when a Google or Outlook meeting is running), that path is separate — see the [presence federation guide](/guides/presence-federation-settings). Sign-in with Google or your identity provider is also separate and is covered in the [security-console guide](/guides/settings-security-console).

***

## Step 1 — Decide which provider to use

Connect the system your team already keeps its calendars, contacts, and mail in. Either provider (or both) works for presence and CRM, so choose based on where the data lives:

| Provider             | Read into Orbit                                                          | Scope families requested at consent            | Typical fit                                     |
| -------------------- | ------------------------------------------------------------------------ | ---------------------------------------------- | ----------------------------------------------- |
| **Google Workspace** | Gmail send, Google Calendar events, Google Contacts sync both ways       | Gmail send, calendar read, contacts read/write | Teams on Gmail and Google Calendar              |
| **Microsoft 365**    | Outlook Calendar events, Outlook Contacts, Mail.Send via Microsoft Graph | Graph read on calendar, contacts, and mail     | Teams on Outlook, Exchange, or Entra ID tenants |

Both are tenant-owned connections: your organization grants the consent, Orbit reads only what the scopes below authorize, and you can revoke at any time.

***

## Step 2 — Connect the provider

**From the dashboard:** open **Settings → Integrations**, find the **Google Workspace** or **Microsoft 365** card, and click **Connect**. Complete the provider's consent screen. The card flips to **Connected** when the grant lands.

**From the API** (same flow for automation): request the consent URL and open it in a browser:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/integrations/connect \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "integration_id": "google-workspace" }'
# or '{ "integration_id": "microsoft-365" }'
```

Owner or admin role required, plus the `integrations:write` scope on the API key. The connect call opens the same consent screen either way; the only difference is who clicks through it.

<Check>
  After consent, `GET /api/v1/integrations` shows the provider row in a connected state and the dashboard card reads **Connected**.
</Check>

***

## Step 3 — What Orbit reads

Scope claims map 1:1 to the registered capabilities:

**Google Workspace** requests Gmail-send, calendar-read, and contacts read/write scopes. Orbit:

* reads Google Calendar events into the contact timeline, so a contact's upcoming meetings surface inside their Orbit profile;
* syncs Google Contacts both ways;
* sends Gmail messages through the same template engine used for SMS and WhatsApp.

**Microsoft 365** requests Microsoft Graph scopes for calendar, contacts, and mail send. Orbit:

* reads Outlook calendar events into the contact timeline;
* syncs Outlook contacts;
* sends email through `Mail.Send` alongside SMS, WhatsApp, and every other channel.

Neither integration writes back to your calendar or deletes anything on the provider side; calendar and mail stay records of your own system, and Orbit is a reader plus one sender.

***

## Step 4 — Turn on agent CRM tools

Google Workspace and Microsoft 365 are first-class entries in the CRM-tool provider list, alongside HubSpot, Salesforce, Zendesk, Calendly, and Intercom. The agent tool catalogue is connector-aware: an agent's CRM tool list only includes providers with an active connection, so connecting one of these two surfaces its actions without enabling them globally.

To let an agent use them, open **Agents → your agent → Tools** and enable the CRM toolsets. The active provider list comes from the integrations registry, so the catalogue reflects the current connection state — disconnect the provider and the action disappears from the menu.

Provider slugs the CRM catalogue reads: `google-workspace` and `microsoft-365`. They join the same enum as the other CRM providers, so the tool catalogue treats them identically to Zendesk or Calendly.

<Info>
  A revoked or expired grant breaks the tool catalogue entry, not the agent's other tool access. Reconnect and the actions reappear.
</Info>

***

## Step 5 — Monitor connection health

The card badge reports **Connected** (healthy) or **Errored** (revoked token or provider outage). The same signal is readable over the API:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/integrations/google-workspace/status \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

If you also federate team presence from Google Calendar or Microsoft 365 Calendar, the presence page surfaces a per-source **last sync** and **outcome** — use it to confirm the org-level connection is still the grant presence reads.

***

## Step 6 — Revoke or rotate

From the dashboard: open the integration's drawer and use **Revoke** in the Settings tab — Orbit disconnects and asks the provider to delete the grant.

From the API:

```bash theme={null}
curl -X DELETE https://api.orbit.devotel.io/api/v1/integrations/google-workspace/disconnect \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

Google Workspace and Microsoft 365 scopes are narrow (calendar, contacts, mail) so revoking on the Orbit side is enough; rotate a leaked provider credential in Google Admin or Entra ID and reconnect.

***

## Troubleshooting

* **Consent screen scope denials** — re-open the connect flow and re-grant; the popup re-asks for any denied scope. Gmail-send, calendar, or contacts read must be granted for the features above to work.
* **Microsoft tenant admin consent** — a Workspace admin (Google) or Entra ID admin (Microsoft) may need to approve the OAuth client before end users can complete consent. Grant admin consent in the provider account once, then reconnect.
* **Google API verification** — if your Google consent screens show an unverified warning, confirm the Orbit OAuth client is registered under your organization's Google account; app verification status blocks consent for many Workspace tenants.

***

## Where the data lands — cross-references

* [Federate team presence](/guides/presence-federation-settings) — use Google Calendar or Microsoft 365 Calendar for presence routing instead of CRM.
* [The OAuth SaaS integrations guide](/guides/oauth-saas-integrations) — Zendesk, Calendly, DocuSign, and Jira; the same connect/status/revoke flow, four other providers.
* [Integrations API reference](/api-reference/integrations) — connect, status, sync, data, and disconnect endpoints with worked examples.
* [Settings → Security console](/guides/settings-security-console) — SAML and sign-in configuration, separate from these two productivity providers.