Skip to main content
AccessOwl connects to each SaaS app through a dedicated integration account that lives in your Google Workspace or Microsoft 365. This page explains how the connection process works, what to expect while a connection is pending, and how to resolve the most common errors. For app-specific setup instructions, open the app’s page in this section.

​
How connecting an app works

1

Add the app in AccessOwl

Either add a new application or open Applications and click the +-symbol, then continue. The setup instructions show you the integration account’s email address and the role it needs in the app.
2

Invite the integration account to the app

Invite the integration account to the app and assign it the role listed in the setup instructions. AccessOwl needs this role to create and remove user accounts on your behalf. The same integration account is reused for every app you connect.
The integration account lives in your Google Workspace or Microsoft 365 and receives the app’s invitation email there. For Google Workspace, Gmail must be enabled and 2-Step Verification must be available for the integration account. See Google Workspace for details.
3

The AccessOwl integration account completes the setup

The AccessOwl integration account automatically accepts the invitation, signs in to the app, and runs the first user sync. Once the sync completes, the integration is active and the app’s users and permissions appear in AccessOwl.

​
What the pending status means

After you connect an app, the integration shows as pending until the setup is complete. AccessOwl is either waiting for the integration account to be invited to the app, or still finishing the account setup and the first user sync. As long as you have completed the invitation step, no action is needed on your side. The setup can take up to 10 hours, but it usually completes much faster than that. If the integration stays pending longer than expected, double-check that the invitation was sent to the integration account’s email address and that the assigned role matches the setup instructions.

​
Connection errors

When AccessOwl can’t connect to an app, the integration shows an error state. A Sync paused status is not an error on your side. It means AccessOwl has paused the user sync for the integration, usually for maintenance on our side, and the Sync capability card shows Maintenance with the time of the last successful sync. Provisioning keeps running in the meantime, and the sync resumes on its own once the maintenance is done. No action is needed on your side. A broken authorization is not that. Where a paused sync means AccessOwl is not syncing the app for now, a broken authorization means the app is no longer accepting the authorization AccessOwl connects with. Retrying cannot fix it, so it never clears on its own and the integration has to be reconnected. AccessOwl detects this and shows an alert on the dashboard, so you do not have to spot it on the application itself. For Google Workspace, Microsoft 365 and GitHub, your Org Admins also receive a Slack message with a Reconnect button and a link to the reconnection steps. For every other integration, the dashboard alert is where you find out. The three error states below require action on your side.

​
Integration account not invited

AccessOwl could not find the integration account in the app. Invite the integration account, give it the role listed in the setup instructions, and click Retry.

​
Not enough permissions

The integration account exists in the app, but its role does not allow it to manage users. Verify that the integration account has the role listed in the setup instructions and click Retry.

​
Access denied

The integration account is blocked from signing in to the app. The most common causes:
This error comes from Google, not from the app. SAML sign-in is enforced for the app on your side, and the integration account is not part of the Google group tied to the app yet. Google recognizes the account but blocks it from the app.Add the integration account to the Google group tied to the app’s SAML configuration, then click Retry.
This error also comes from Google, not from the app. Your organization restricts which third-party apps can be accessed, and the app the integration account is signing in to has not been approved yet. Google blocks the sign-in and shows a message that your admin needs to review the app.A Google Workspace admin needs to approve the app in the Admin console under Security > Access and data control > API controls > Apps pending review. Point to the app, click Configure access, set it to Trusted, and apply it to the organizational unit the integration account is in. Then click Retry.
The integration account authenticates directly with Google or Microsoft. If it sits in an organizational unit that enforces passkey sign-in, the sign-in to the app fails.Move the integration account to an organizational unit where passkey sign-in is not enforced, or add an exception for the account, then click Retry.
The app only allows sign-in through SSO for members of a team or group, and the integration account is caught by that restriction.Make sure the integration account is able to log in with or without SSO. In the app, check that the account is not part of a team or group that enforces SSO sign-in, then click Retry.
The integration account’s password or 2FA was changed. These credentials are managed automatically and must never be replaced. Contact AccessOwl Support to restore the account.
While an integration is in an error state, affected provisioning and deprovisioning tasks are reassigned to the Application Admin, so requests are never silently dropped.

​
FAQ

The integration account is set up automatically with a passphrase and 2FA via TOTP. Never replace the password or the TOTP, as this breaks the connection for all apps using the account. If your organization has a policy that requires passwords to be rotated after a set amount of time, contact AccessOwl Support.
No. The integration account does the whole setup on its own. It receives the invite, accepts it, signs in and runs the first sync. If someone opens its invite emails, accepts an invite or signs in as it, the setup breaks and AccessOwl cannot reach the app. If that happened, contact AccessOwl Support to restart the setup.
Disconnecting an integration is not self-serve. Contact AccessOwl Support and we will disable the integration for you.The exception is Google Workspace: if you need to fully disconnect and reconnect it, for example after a scope change, you can do that yourself. See Disconnecting and Reconnecting.
You can do this yourself, no need to contact AccessOwl Support. The link to the groups cannot be removed on its own, because the imported data uses a different internal structure. Instead, archive the application using Archived on its edit screen, then add it again as a new application. Removing the linked permissions first is not enough.
Archiving an application closes every pending approval on that app. Any open access requests need to be raised again after the application is added back.
Yes, this is self-serve. Archive the application using Archived on its edit screen, then add it again with the connection method you want, for example the integration account. See Manage applications via Google or Entra ID groups for details on moving away from group-based provisioning.
It depends on what the app supports. AccessOwl always prefers the least destructive action first, in this order: deactivate, then remove, then delete. Each app’s page in this section states the exact action AccessOwl performs for that app.If the user owns any assets in the app, AccessOwl transfers them to the user’s manager before revoking access. If no manager is available, the assets are transferred to the business owner.When someone loses their last access to an app that AccessOwl provisions automatically, AccessOwl also deactivates their account in that app, so no account is left behind without access. For example, Google Workspace and Microsoft 365 accounts are suspended. This applies to apps where AccessOwl can deactivate accounts.
It depends on the app. On apps with per-seat pricing the integration account occupies a normal seat like any other user, and it needs a role that can manage users. Some apps have a free admin role instead, for example Cursor offers Unpaid Admin, which can manage members and roles without consuming a paid seat.An integration that connects through the app’s own API, like AWS, does not use a seat at all.
No. The integration account never purchases a seat or license. If the app has no seats left, the provisioning request results in a reassignment error and the task is reassigned to the Application Admin.
Last modified on September 28, 2026