Identity Integrations — Google Workspace & Microsoft 365

The Identity tab of the Breeze Integrations page is where you connect a customer’s directory to Breeze. It has two sub-tabs — Google Workspace and Microsoft 365. Microsoft 365 offers two separate connection methods: Customer Graph Read uses customer-administrator consent without asking you for a reusable secret, while Legacy direct accepts a tenant-specific app client secret for existing read and action workflows.

Open it at Integrations → Identity (/integrations#identity). The two sub-tabs deep-link to /integrations#google (Google Workspace) and /integrations#m365 (Microsoft 365).

This page is about *connecting* a tenant

This page documents the connection step only — the credential fields and the connect/verify/disconnect flow. For what you can do once a tenant is connected (viewing identity posture, the full list of read and mutating AI actions, guided offboarding, and the approval gate), see the Identity Console. This page and the Identity Console describe the same two connectors from two angles: setup here, day-to-day use there.

Off by default

Both provider sub-tabs are feature-flagged off by default. A host operator must enable GOOGLE_WORKSPACE_ENABLED (Google Workspace) and/or M365_ENABLED (Microsoft 365). Customer Graph Read has an additional organization allowlist; if your organization is not enabled, its card remains visible but consent cannot be started. Host operators self-hosting Breeze: the environment variables that turn Customer Graph Read on are documented under Customer Microsoft 365 Graph-read consent.

---

Connecting a tenant

There is one Google Workspace connection per organization. Microsoft 365 can have one Customer Graph Read connection and one separate legacy direct connection per organization. Connecting, re-consenting, retesting, or disconnecting requires organization write permission and current MFA where shown.

Google Workspace

Google Workspace lives on the sub-tab at /integrations#google. Breeze authenticates as a Google Cloud service account that uses domain-wide delegation to impersonate a super-admin in the customer’s domain.

Credentials required

Field	Description
Primary domain	The customer’s domain, e.g. example.com
Super-admin email (impersonated)	A super-admin account in the domain that the service account impersonates
Service-account JSON key	The full service-account JSON key file, pasted into a masked field

Connect

1. Set your scope to the customer organization, then open Integrations → Identity → Google Workspace.
2. In the Google Cloud Console, open IAM & Admin → Service Accounts and create (or pick) a service account.
3. On that service account, open the Keys tab and choose Add key → Create new key → JSON. The JSON downloads once — that file is what you paste into Breeze. Note the service account’s numeric Client ID (its unique ID); you will need it in the next step.
4. Enable the APIs the identity tools use: Admin SDK, Gmail, Calendar, and Enterprise License Manager.
5. In the Google Admin Console, go to Security → Access and data control → API controls → Manage domain-wide delegation. Add the service account’s Client ID and authorize the exact OAuth scopes Breeze shows in the walkthrough (copy them straight from the card).
6. Back in Breeze, enter the Primary domain, the Super-admin email to impersonate, and paste the service-account JSON key.
7. Click Save & Verify. Breeze makes a live Directory API call to confirm the key works and that domain-wide delegation is correctly authorized, then stores the connection.

Domain-wide delegation scopes

The walkthrough card displays the exact comma-separated OAuth scope list to authorize. It covers directory user/group read and write, user security, aliases, mobile-device actions, Gmail settings (basic and sharing), Calendar ACLs, and Apps licensing — the scopes the Google identity tools actually call. Authorize the full list so every supported action works.

Microsoft 365

Microsoft 365 lives on the sub-tab at /integrations#m365. Choose the method that matches the work you intend to do. The cards are independent; connecting or disconnecting one does not change the other.

Customer Graph Read (recommended for read-only inventory)

Customer Graph Read uses Breeze’s dedicated multitenant, certificate-backed application. You do not enter a tenant ID, client ID, client secret, certificate, scope, or vault location. A customer Global Administrator or Privileged Role Administrator reviews Microsoft’s permission screen and grants consent.

1. Set your Breeze scope to the customer organization and find the Customer Graph Read card.
2. Review the nine required permissions shown on the card, then choose Connect.
3. Complete Breeze MFA and sign in to Microsoft as a Global Administrator or Privileged Role Administrator for that customer tenant.
4. Review Microsoft’s consent screen carefully and accept only if it shows the expected application and exact permissions below.
5. Complete the second Microsoft identity check. Breeze independently verifies the signed tenant identity, administrator role, service principal, exact grants, and organization probe.
6. Confirm the card shows Active, the expected tenant name/GUID, manifest version 2, and no missing or unexpected permissions.

Customer Graph Read requests exactly these Microsoft Graph application permissions:

Permission	Why it is requested
Application.Read.All	Read the dedicated application’s authoritative app-role assignments for drift detection
AuditLog.Read.All	Read audit and sign-in inventory
Device.Read.All	Read Entra device inventory
DeviceManagementConfiguration.Read.All	Read Intune configuration inventory
DeviceManagementManagedDevices.Read.All	Read Intune managed-device inventory
Group.Read.All	Read groups and memberships
Organization.Read.All	Verify and read the customer organization
Sites.Read.All	Read SharePoint site inventory
User.Read.All	Read users and directory profiles

The card shows required, observed, missing, and unexpected grants. Active requires exact equality. If Microsoft cannot complete authoritative reconciliation—for example, because Application.Read.All was removed—the card becomes Degraded and labels the retained observed list Last-known, rather than presenting it as current.

Use Retest to check an already-bound tenant. Use Re-consent when permissions were changed or the manifest is stale. Customer Graph Read is read-only and does not authorize password resets, user disablement, other Graph mutations, Exchange PowerShell, or delegated mail/Teams access.

Legacy direct (existing client-secret method)

Legacy direct uses a customer-specific Entra app registration and the client-credentials flow. You create the app in the customer’s tenant, grant its permissions, and give Breeze the tenant ID, client ID, and client secret. This method remains available for existing identity read and action workflows.

Credentials required

Field	Description
Tenant ID	The tenant’s Directory (tenant) ID — a GUID; the contoso.onmicrosoft.com form is also accepted in the field
App (client) ID	The Application (client) ID of the Entra app registration
Client secret	The app’s client secret value (not the secret ID), entered in a masked field

Connect legacy direct

1. Set your scope to the customer organization, then open Integrations → Identity → Microsoft 365.
2. In the Microsoft Entra admin center (entra.microsoft.com) or the Azure portal, open Microsoft Entra ID → App registrations and pick an existing app or click New registration. Give it a name and choose “Accounts in this organizational directory only.”
3. On the app’s Overview page, copy the Directory (tenant) ID and the Application (client) ID into the Breeze fields.
4. Go to Certificates & secrets → Client secrets → New client secret. Set a description and expiry (24 months max), then copy the secret Value immediately — not the secret ID; it is shown only once.
5. Under API permissions, add the Microsoft Graph application permissions listed below, then click Grant admin consent.
6. Back in Breeze, enter the Tenant ID, App (client) ID, and the client secret.
7. Click Save & Verify. Breeze acquires a token and makes a live Microsoft Graph call to confirm the credentials and admin consent are in place, then stores the connection.

Legacy direct Microsoft Graph permissions

The connection card spells out which permissions back which capabilities:

Capability	Graph application permissions
Reads (user lookup, group memberships, sign-in activity)	User.Read.All, Group.Read.All, AuditLog.Read.All
Disable user / reset password	additionally User.ReadWrite.All + User-PasswordProfile.ReadWrite.All, plus the User Administrator Entra role

Grant admin consent for these in the app registration before saving, or the live verification (and later actions) will fail.

Tip

Google Workspace and legacy direct secrets are encrypted at rest and never returned to the browser. Customer Graph Read never asks the browser for a reusable Microsoft credential: its certificate is confined to a private executor and only safe connection health is returned.

---

Remove Customer Graph Read consent

Disconnect from Breeze immediately revokes Breeze’s local connection, clears its executable tenant/grant state, and rejects delayed callbacks. It does not delete the Microsoft Enterprise application or remove tenant-wide admin consent.

To remove Microsoft consent separately, a customer Entra administrator must:

1. First choose Disconnect from Breeze on the Customer Graph Read card and confirm the card shows Revoked.
2. Open the Microsoft Entra admin center for the verified customer tenant.
3. Go to Identity → Applications → Enterprise applications, find the dedicated Breeze Customer Graph Read application by its verified name and application ID, and open it. Do not modify an unrelated app registration.
4. Use the Enterprise application’s delete/remove option to remove that tenant’s service principal and tenant-wide application consent. Microsoft labels can vary by portal version; verify the tenant and application before confirming.
5. Confirm the Enterprise application is no longer present. If Breeze had not already been disconnected, a subsequent Retest would report an application verification failure; local status alone is not proof that Microsoft consent was removed.

Removing an individual permission is different from removing tenant-wide consent. In particular, removing only Application.Read.All prevents Breeze from authoritatively reading the current assignment set, so the card reports reconciliation unavailable and retains the prior list as last known.

---

After connecting

Once a sub-tab shows Connected, technicians work with the directory through the in-app AI assistant rather than through this Integrations page. Read-only lookups (user details, group memberships, security posture, Microsoft 365 sign-in activity) run automatically; anything that changes an account is gated behind a human approval step with a mandatory reason and a full audit trail. The two providers are not at parity — Google Workspace exposes a much broader mutating action set than Microsoft 365.

For the complete list of what you can view and do — including guided offboarding, the security-drift report, and the read-vs-mutating tiers — see the Identity Console.

---

Troubleshooting

The Google Workspace or Microsoft 365 sub-tab shows “not enabled on this instance.” The connector is feature-flagged off. Ask your host operator to enable GOOGLE_WORKSPACE_ENABLED or M365_ENABLED on the API server, then reload the page.

The connection fails to save with a credentials error. Both providers verify credentials live before storing them. For Google Workspace, confirm the service-account JSON key is valid and that domain-wide delegation was authorized with the exact scopes shown on the card, using the service account’s numeric Client ID. For Microsoft 365, confirm the tenant ID and client ID are correct, the client secret Value (not the secret ID) was copied and has not expired, and admin consent has been granted for the required Graph permissions.

Customer Graph Read says an eligible administrator is required. Complete both Microsoft steps as a Global Administrator or Privileged Role Administrator in the customer tenant. Other directory roles fail closed even if Microsoft allows them to reach a consent screen.

Customer Graph Read is degraded. Review missing and unexpected grants on the card. Restore the exact nine-permission manifest, choose Re-consent, then Retest. If the card says reconciliation is unavailable, restore Application.Read.All first; the displayed observed list is last known, not a current assignment inventory.

Retest says the verification service is unavailable. This does not mean Microsoft consent was removed. Existing active state is preserved during a transient executor outage. Ask the Breeze operator to restore the private verification service, then Retest again.

Save is disabled. A fresh connection requires all fields. For Google Workspace: primary domain, super-admin email, and the service-account key. For Microsoft 365: tenant ID, client ID, and client secret. When updating an existing connection, the secret field may be left blank to keep the stored value.

I connected a tenant but AI identity actions still do not work. A verified connection is required in addition to the feature flag being on. Re-open the sub-tab and confirm the badge reads Connected. Also confirm the service account or app registration carries the write permissions and admin role required for the specific action (see the permissions tables above).

---

Related

• Identity Console — viewing identity posture and running AI-assisted identity actions once a tenant is connected
• AI Assistant — how read and mutating actions, approvals, and the audit trail work
• Integrations — the full Integrations page and its other tabs