Google Workspace tenant, roughly 120 users. Two users have been unable to access Data Studio at all since 2026-07-30. I’m the Workspace admin. Sharing admin-side audit log findings in case they help identify the cause, and hoping someone has seen this pattern.
Symptoms
- While signed in, every Data Studio page returns Bad Request immediately — not just individual reports, but the home page and navigation as well
- Response body is
)]}'followed by{"errorStatus":{"code":3}}(INVALID_ARGUMENT) - On mobile browsers, the same response is downloaded as a
json.txtfile instead of rendering - Signed out / incognito: public reports load normally
- A different Google account on the same device and browser: works normally
- All other Google services (Gmail, Drive, Calendar) work normally for the affected users
- Reproduced on macOS and iOS, across home broadband, mobile tethering, and two separate office networks
- Clearing cache and restarting browser/OS has no effect
- Revoking the Data Studio grant at
myaccount.google.com/connectionsand re-authorizing does not help — the authorization flow itself returns 400 and loops indefinitely - Note: one affected user had a brief outage at first, then worked normally for about two hours on 2026-07-30 before breaking permanently. So this is not a static misconfiguration
Admin console state — everything is unrestricted
- Admin log events for the relevant period show no configuration changes affecting Data Studio
- App access control: all Google services set to unrestricted; no Data Studio entry in configured apps
- Marketplace app “Data Studio” (project (PII Removed by Staff)): distribution ON for all organizational units, data access granted, all 5 requested scopes allowed
- Turning distribution OFF, saving, waiting, then ON again (re-provisioning) did not resolve it
- Domain-wide delegation: no entries at all
Audit log evidence
- OAuth log events show zero denied events for the affected users — so this is not a policy block
- However, “authorize” (grant) events for client ID (PII Removed by Staff) are recorded repeatedly, every 5–10 minutes, continuously for the affected users. The grant is recorded as successful server-side but never takes effect client-side
- The Data Studio activity log shows a successful report view as the last entry on 2026-07-30, and nothing at all since — despite continuous access attempts over several days
- So: no denial, but also no arrival at the application layer. The failure appears to occur in the authorization layer, before requests reach Data Studio itself
- The same repeated-grant pattern appears for several other users in the tenant who are currently still able to use Data Studio, so repeated grants alone don’t distinguish broken users from working ones
Two things I’m unsure about, and would appreciate input on
- The troubleshooting guide states that Data Studio requires consent for the
datastudio.firstpartyscope to make RPC calls. But the scopes I see being granted in the OAuth logs aredatastudio.reports.readonly,presentations, andscript.locale— notdatastudio.firstparty. Is that expected? Could the looping grant be a separate API-consuming app rather than the Data Studio UI itself? - The Data Studio API docs state that apps using the Data Studio API can only authorize Workspace users if the organization has authorized the app via domain-wide delegation, and that a 400
invalid_scopeduring authorization indicates the organization has not or incorrectly authorized the app. Our domain-wide delegation list is empty. Is a DWD entry required for normal Data Studio UI access in a Workspace tenant, or only for third-party API clients?
Also worth noting: in this tenant, there is no “Data Studio” or “Looker Studio” entry under either Additional Google services or App access control → Google services in the admin console. Data Studio only appears as a Google Workspace Marketplace app. I don’t know whether that’s the expected post-rebrand layout or a sign of an incomplete migration.
This may be related to Error: Authorize Data Studio API — that thread is primarily about viewers of shared dashboards being prompted to authorize, which is a different symptom, but some replies there describe the same 400 authorization loop and the same pattern of users breaking one at a time as their tokens expire.
Any known bug ID, workaround, or suggestions for what else to check from the admin side would be much appreciated.