OAuth Consent Screen Not Appearing Randomly When Using Google Workspace Scope (OAuthClientID)

Help Activities
, , ,
1

Hi everyone,

I’m using Google Workspace Scope with OAuthClientID to call the activity Get File Info in order to retrieve metadata from Google Drive.

Normally, when the token expires or when re-authentication is required, Google displays the OAuth consent screen for us to grant access again. After granting access, the process continues normally.

Recently, at some random times during the day, the consent screen does NOT appear, which results in:

  • The bot failing to obtain the required permissions
  • API call failure inside the Google Workspace Scope
  • The entire job failing even though the logic itself is correct

This behavior is intermittent and unpredictable.

  • In our Production environment, we have two bots running in sequence.
  • Each bot triggers every 15 minutes.
  • Both bots use the same OAuthClientID configuration for Google Workspace access.

Has anyone experienced a situation where the Google OAuth consent screen fails to appear, causing the UiPath process to lose access? What could be the possible root causes? Are there more stable approaches to avoid UI-triggered consent screens in Production?

Thanks in advance!

2

This issue usually happens when multiple robots share the same Google OAuthClientID. In your case, both bots run every 15 minutes and try to refresh the token, so Google ends up invalidating the previous refresh token. When this happens, the consent screen doesn’t appear, and the Google Workspace Scope loses access, causing random permission or API failures even though the workflow is correct.

The most reliable and production-grade fix is to switch the Google Workspace Scope to a Service Account with Domain-Wide Delegation. This completely removes consent screens, token expiration problems, and any human interaction. Service Accounts are Google’s recommended approach for unattended automation and remain stable even with frequent triggers.

If OAuth must stay, then each bot should have its own separate OAuth Client ID to avoid token conflicts—but this still won’t be as stable as using a Service Account.

The issue comes from shared OAuth tokens being overwritten, and using a Service Account is the long-term and fully stable solution.