After configuring your Microsoft 365 and Google Workspace connections, use the built-in connection test to confirm everything is working correctly. This article explains how to run the test, what it checks, and how to resolve common errors.
Testing a connection
- In CloudM Continuity, go to Connections in the sidebar
- You will see your configured connections: Source Connection (Microsoft 365) and Destination Connection (Google Workspace)
- Click the three-dot menu on the connection card you want to test
- Select Test connection
- Wait for the test to complete — this typically takes a few seconds
- A green toast notification confirms "Connection test successful" if everything is configured correctly
Test both connections before creating your first sync policy.
Both connections successful?
If both Microsoft 365 and Google Workspace connections test successfully, you're ready to create your first sync policy. Return to the setup checklist to continue.
Connection details
After a connection is created, the Connections page shows the key details for each connection:
Source Connection (Microsoft 365)
| Field | Description |
|---|---|
| Source name | The connection name, with a Successful badge when the connection test passes |
| Tenant Id | Your Azure AD Directory (tenant) ID |
| Client Id | The Application (client) ID from your Azure AD app registration |
Destination Connection (Google Workspace)
| Field | Description |
|---|---|
| Destination name | The connection name, with a Successful badge when the connection test passes |
| Domain | Your Google Workspace domain |
| Admin email | The Super Admin email address used for domain-wide delegation |
| Service account | The GCP service account email address |
What the connection test checks
Microsoft 365 connection
| Check | What it verifies |
|---|---|
| Authentication | The Client ID, certificate, and Tenant ID are valid and can obtain an access token |
| API permissions | The registered application has the required Graph API permissions and admin consent has been granted |
| Data access | The application can successfully query the Microsoft Graph API to read user and mail data |
Google Workspace connection
| Check | What it verifies |
|---|---|
| Token access | CloudM's token provider can generate an access token for your service account (Token Creator role is configured) |
| APIs enabled | The Gmail API and Admin SDK API are enabled in the GCP project |
| Domain-wide delegation | The service account has domain-wide delegation enabled and the required OAuth scopes are authorised |
| Data access | The service account can successfully impersonate a user and access Gmail |
Managing connections
The three-dot menu on each connection card provides the following options:
| Action | Description |
|---|---|
| Test connection | Run the connection test to verify credentials and access |
| Edit | Update the connection credentials (e.g. after rotating a certificate or updating a service account) |
| Remove | Delete the connection. You will need to recreate it to resume sync operations. |
Troubleshooting a failed connection test
If the connection test fails, work through the relevant checklist below.
Microsoft 365 — things to check
- Tenant ID and Client ID — Verify these match the values shown in your Azure AD app registration's Overview page
- Certificate — Confirm the PFX file uploaded to CloudM Continuity matches the public certificate (.cer) uploaded to Azure AD. Check the certificate has not expired.
- Certificate password — Ensure the password entered matches the one used when exporting the PFX file
-
API permissions — In Azure AD, go to your app registration > API permissions and verify that
Mail.Read,User.Read.All,Directory.Read.All, andMailboxSettings.Readare listed as Application permissions (not Delegated) - Admin consent — Check that all permissions show a green checkmark under the Status column. If not, click "Grant admin consent"
-
Network access — Ensure outbound HTTPS traffic to
graph.microsoft.comis not blocked by your network
Google Workspace — things to check
- Service account email — Verify the email entered in CloudM Continuity exactly matches the service account shown in the GCP Console
-
Token Creator role — In the GCP Console, go to your service account's Permissions tab and confirm that
coop-tp-sa@coop-production-488013.iam.gserviceaccount.comhas the Service Account Token Creator role. IAM changes can take a few minutes to propagate. - APIs enabled — In the GCP Console, go to APIs & Services > Library and confirm both the Gmail API and Admin SDK API are enabled
-
Domain-wide delegation — In the Google Admin console, go to Security > API controls > Domain wide delegation. Verify the service account's Client ID (numeric ID) is listed with the correct OAuth scopes:
https://mail.google.com/https://www.googleapis.com/auth/gmail.modifyhttps://www.googleapis.com/auth/admin.directory.userhttps://www.googleapis.com/auth/admin.directory.domain.readonly
- Admin email — Confirm the admin email entered is a valid Super Admin in your Google Workspace domain
- Propagation delay — If you recently configured domain-wide delegation or granted the Token Creator role, wait 15–30 minutes and try again. In rare cases, propagation can take up to 24 hours.
-
Network access — Ensure outbound HTTPS traffic to
googleapis.comis not blocked by your network
Still having issues?
If you've worked through the checklist above and the connection test still fails, contact CloudM support with details of the error and the steps you've already tried.
Re-testing after changes
You should re-run the connection test whenever you:
- Rotate a certificate (Microsoft 365) or update a service account (Google Workspace)
- Change API permissions in Azure AD or GCP
- Modify domain-wide delegation settings
- Update connection credentials via the Edit option