What can’t the Google Admin console do?
By Patronum
September 07, 2026
Read Time: 4 mins

By Patronum
September 07, 2026
Read Time: 4 mins

Here’s the number that surprises most admins: Google states Drive files “larger than 750 GB can’t be copied.” Google’s fix is to “download the file and then upload it.” Below: the Admin console and native Google Workspace limits that shape real admin work, marked by kind, with what admins use instead.
Two different things get called a limitation. An Admin console limit caps the management interface, and an API, GAM script or export usually gets past it. A Workspace platform limit is enforced by the service, so no tool clears it.
Bulk work runs through CSV upload, and Google publishes the ceilings: “Maximum CSV file size is 35 MB,” “Maximum number of records per file is 150,000,” and 200 users if you assign licenses in the same file. You “can’t add new columns, such as those for custom attributes.” Admins use GAM or the Admin SDK instead.
Not really. You get Drive log events and storage reporting, not a browsable view of who can open which file. Searching another user’s content needs Google Vault. To build the inventory the console won’t show you, admins enumerate permissions through the Drive API or GAM.
No. Google’s documentation on transferring Drive files states plainly: “Transferring files does not affect who has access to the files,” and “The previous owner can still edit any transferred files, unless you delete their account.” The standard leaver step leaves every share intact. No native bulk unshare exists in the console, so admins script permission removal with the Drive API or GAM.
| What you want to do | Published Google limit or behavior | Limit type |
|---|---|---|
| Copy a huge Drive file | Files “larger than 750 GB can’t be copied” | Workspace platform |
| Bulk upload or copy | 750 GB per user per 24 hours | Workspace platform |
| Bulk changes by CSV | 35 MB, 150,000 records, 200 for licenses | Admin console (use GAM or the Admin SDK) |
| One shared drive | 500,000 items; 600 members, 100 groups | Workspace platform |
| Recover a deleted user | “up to 20 days” | Workspace platform |
| Auto-forward a handover | 40 filters; 10,000 auto-forwarded messages per day | Workspace platform |
| Groups owned by one user | 1,500 | Workspace platform |
| Bulk unshare Drive files | No native bulk unshare | Admin console (use the Drive API, GAM or Patronum) |
| A year of audit evidence | Most logs 6 months; email log search 30 days | Admin console (export to BigQuery) |
Google’s Groups documentation adds these limits “can change without notice.”
Only partially. You can create a user, assign a license, and put them in an organizational unit. It won’t run an ordered sequence: groups, calendar sharing, signature, filters, then reverse it all on exit.
The clock matters too. On Annual or Fixed-Term plans, Google warns “if you later restore the deleted user, you’ll need another license,” and that license fees for the account holding transferred data “are still necessary. This includes AU licenses.”
Six months for most of it. Google’s data retention page lists Admin, Drive, User, Groups, OAuth Token, Devices and Calendar log events at 6 months, and no setting extends that inside the console.
The practical next step: export logs to BigQuery or your SIEM before they age out. Google supports exporting “Google Workspace logs and usage reports to Google BigQuery,” and from there into a SIEM or Looker Studio. It’s edition-gated: Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus. Set it up before you need a year of evidence, not after.
Plenty. Organizational unit inheritance sets policy for a whole population in one edit, service on/off controls are granular, and audit log coverage across Drive, Gmail, Groups, devices and OAuth tokens is genuinely broad. Alerts, data loss prevention and the security investigation tool are real capabilities, though edition-gated. Add the Admin SDK, the Drive API and GAM and almost everything above is reachable, just not by clicking.
The gap isn’t capability. It’s that the Admin console is a configuration surface, not an operations one.
Patronum is a no-code Google Workspace management layer, aimed at the operational gaps:
Where Patronum isn’t the answer: CloudM leads on tenant migration, BetterCloud on multi-SaaS ops, GAT Labs on security forensics.
Bulk operations are capped (35 MB and 150,000 records per CSV, 200 users for licenses), there’s no cross-user permission browser, transferring ownership doesn’t change sharing, deleted users are recoverable for 20 days, and most audit logs last six months. Small teams rarely notice. Teams past a few hundred users always do.
Not from the Admin console. Google’s transfer tool states “Transferring files does not affect who has access.” Bulk unsharing needs the Drive API, GAM, or Patronum.
Six months for Admin, Drive, User, Groups, OAuth Token, Devices and Calendar log events. Email log search covers 30 days. Nothing in the console extends that, so export log data to BigQuery or your SIEM if you need longer evidence.
Vault handles retention, holds, search and export, but Google notes license fees for the account holding transferred data are still necessary, including Archived User licenses, and publishes no price for one.
Start with the limit you’re closest to hitting. Patronum’s management at scale guide and buyer’s guide map tools to the gap you need closed.