A company with several locations, divisions or time zones hires an SEO specialist, a content writer and a developer in the same month. Each needs access to a different slice of the same stack: analytics, search, tags, ads, the content system, the front end, the DNS. Collecting that access is slow because every platform has its own role names, its own idea of a group, and its own view on whether access should ever expire. This page is the table we wished existed when we started: the least-privilege role per job on twenty platforms, read from each platform's official documentation.
Two facts from the documentation shape everything below. Only three of the twenty platforms offer built-in expiring access for a person: Meta's business portfolio, Google Drive and Google Cloud IAM. Everywhere else, a contractor grant lasts until someone remembers to remove it. And two of the most important platforms for marketing, Search Console and Business Profile, refuse groups outright, so the tidy "one group per job" model breaks exactly where the data matters most.
The lessons here are general. No client, account, property or person from any engagement appears in this post; the platform facts come from vendor documentation and the governance references from NIST and CISA.
- 01Grant by job, at the smallest scope the platform allows.Viewer or Restricted for SEO and content on data platforms; Editor or Standard for developers and paid media; Owner, Admin and Publish stay with the client. The table gives the role name on each platform.
- 02Only Meta, Google Drive and Google Cloud IAM expire a person's access on their own.Meta's temporary access runs 3 to 75 days and is removed automatically. Everywhere else you need a calendar entry and an offboarding list.
- 03Search Console refuses email groups, caps non-owners at 100, and lets a removed owner re-verify.Google's own help page states all three. Deleting an owner without deleting their HTML file, meta tag or DNS record leaves the door open.
- 04One named access owner beats a central admin team.Centralising access creates a queue. A single accountable person with a role-per-job template and an expiry date on every contractor grant is faster and safer than either extreme.
01 — The questionCentralise access, or make scoped access easy?
Multi-location businesses usually answer this by accident. Either one long-serving person holds every login and becomes the queue, or access is handed out ad hoc and nobody can list who has what. The documentation points to a third option. Every platform in the table has a role narrow enough for an outside specialist; most have a way to grant it without sharing a password; a few have a partner model built for agencies. What none of them have is a shared directory, so the coordination has to be yours.
The practical answer is one named access owner at the client, a role-per-job request template, group-based grants where the platform supports them, an expiry date on every contractor grant, and an offboarding list run on the last day. Section 04 sets that out. The table comes first because the role names are the part people get wrong.
02 — The tableThe matrix: least-privilege role by job on 20 platforms
"Least role" is our reading of each platform's documented roles against four jobs: SEO, content, developer and paid media. Where a job has no business on a platform the cell says none. Group support, partner models, caps and expiry are as documented on September 25, 2026; "not documented" means the help page is silent, not that the feature is absent.
| Platform | Least role by job | Groups and partner model | Caps and expiry |
|---|---|---|---|
| Google Analytics 4 | SEO and content: Viewer. Analyst if they need to share explorations. Paid media: Marketer. Developer: Editor, at property level, not account level. | User groups only through a Google Marketing Platform organisation. Adding a Google Group address is not documented. No partner model. | No user cap stated. A user gets the most permissive of their account- and property-level roles. No built-in expiry. |
| Google Search Console | SEO: Full. Content: Restricted. Developer: Full (sitemaps, removals). Paid media: none, or Restricted. | No. An email group cannot be added as a user. No partner model. | 100 non-owners per property; no new delegated owners once a property has 500 owners of any kind (verified owners are uncapped). A removed owner can re-verify while their token remains. No expiry. |
| Google Tag Manager | SEO: Read. Content: none. Developer and paid media: Edit on the container; keep Approve and Publish with the owner. | Marketing Platform user groups, but groups cannot hold Admin, Approve or Publish. No partner model. | None documented. Google recommends at least two admins. No expiry. |
| Google Ads | SEO: Read-only. Content: none. Developer: Standard (conversion setup). Paid media: Standard, through a manager-account link. | Not documented; invitations go to individual addresses. Manager accounts (MCC) link client accounts; a client account has one owner. | 20 accounts per email; up to five managers linked per client; six hierarchy levels. No expiry. |
| Google Business Profile | SEO and content: Manager. Developer and paid media: none. Keep one primary owner at the client. | No: Google Groups cannot be managers or owners. Agency organisation accounts group locations and staff. | New owners and managers wait seven days before removing users or transferring ownership. No expiry. |
| Looker Studio | All jobs: Can view. The person building reports: Can edit. Transfer ownership to the client before offboarding. | Yes: people or Google Groups. No partner model. | 1,500 principals per asset. No expiry found. |
| Meta business portfolio | Content: partial access with content tasks on the Page. Developer: apps and integrations, dataset tasks. Paid media: partner access to the ad account with the tasks needed. SEO: none. | No groups. Partners: the client shares an asset with the agency's portfolio ID; partial-access partners can only pass on the tasks they hold. | Temporary access: basic level only, 3 to 75 days, removed automatically on expiry. |
| Microsoft Advertising | Paid media: Standard user via a client link. Developer: Standard (UET setup). SEO and content: Viewer or none. | No groups, no custom roles. Client linking with Standard or Administrative permission; the agency may take on billing. | No cap on linked clients; manager links up to five levels. Link requests expire after 30 days; nothing else does. |
| LinkedIn Campaign Manager | Paid media: Campaign manager. Content: Creative manager. SEO and developer: Viewer. Billing admin stays with the client. | No. Agencies are added as users on the ad account; Pages have separate roles. | Each ad account must have a billing admin. No expiry. |
| GitHub | Developer: Write on the named repositories as an outside collaborator; Maintain only if they manage settings. SEO and content: Read, or none. | Teams are for members only; outside collaborators cannot join teams. Custom roles on Enterprise. | Outside collaborators use a paid seat on private repos and must use 2FA if the org requires it. Fine-grained tokens can be scoped and given a maximum lifetime. |
| Vercel | Developer: Contributor with Project Developer on named projects. Content and SEO: Pro Viewer or Project Viewer. | Access Groups on Enterprise, mappable from directory sync. | Developers cannot change production environment variables or invite others. At least two Owners recommended. No expiry documented. |
| Netlify | Developer: Developer, customised per project. Content: Reviewer for feedback, Git Contributor for previews. SEO: Reviewer. | Directory sync on Enterprise. | Reviewers need Owner or Developer approval. No expiry. |
| WordPress (core) | Content: Author, or Editor if they publish others' work. SEO: Editor. Developer: Administrator, which core cannot narrow. | Plugins only. | None in core. Expiry only through a plugin. |
| Webflow | Developer or designer: Agency or Freelancer guest from the agency's own Workspace. Content: Content editor. SEO: Marketer. | The guest role is the partner model: the client keeps ownership and invites the agency's Workspace for free. | A guest team brings five members (ten on Enterprise). Guests cannot open General, Team, Plans, Billing or Partner settings. No expiry found. |
| Contentful | Content: Author (cannot publish) or Freelancer on Premium. SEO: Editor. Developer: Admin, or a custom role on Premium. | Roles can be assigned to teams; a user holds the union of individual and team roles. | Author needs Lite or above; Translator, Freelancer and custom roles need Premium. No expiry found. |
| Sanity | Content: Contributor for drafts, Editor to publish. Developer: Developer. SEO: Viewer, which uses no seat. | SAML attributes on Enterprise. Permissions are additive. | Seat-based. No expiry documented. |
| Cloudflare | Developer: Domain DNS or Domain Administrator on the one domain. SEO: Administrator Read Only or Analytics. Content and paid media: none. | User Groups with permission policies. | API tokens support a start and expiry time and client-IP filtering; human roles do not expire. |
| Google Workspace groups | Not a role: the grant mechanism. Put SEO, content and developer contractors in separate groups and grant the group where the platform allows it. | Groups can include external members if the admin allows it. Google says a stricter internal and external classification arrives in 2026. | Works for Looker Studio, Drive and Google Cloud; refused by Search Console and Business Profile. Membership can be set to expire through the Cloud Identity Groups API on Enterprise and Cloud Identity Premium editions. |
| Google Drive | Content and SEO: Viewer or Commenter on the shared folder. Developer: Editor on named files only. | Yes: share with a group. | Access expiry dates for viewers, commenters and editors on files; viewers only on folders. |
| Google Cloud IAM | Developer: the most limited predefined role at the smallest scope, for example on one BigQuery dataset. Everyone else: none. | Google's guidance: grant roles to groups, not individuals. | IAM Conditions let a binding expire automatically; Privileged Access Manager handles temporary elevation. |
Three patterns fall out of the table. Group-based access works in part of the stack: Looker Studio, Google Cloud, Drive, GitHub teams, Cloudflare user groups, Vercel access groups and Contentful teams, plus GA4 and Tag Manager through a Marketing Platform organisation. It is explicitly refused by Search Console and Business Profile. Dedicated partner models exist on Google Ads, Meta, Microsoft Advertising, Business Profile and Webflow, and they are always better than a shared login because the client can cut the link from their side. And built-in expiry for a person exists on three platforms only.
03 — The trapsThe traps, each from the vendor's own page
- Search Console refuses groups and caps usersGoogle Search Console help, users and permissions page.
- 100 non-ownersAn email group cannot be added as a userEvery specialist needs an individual Google account and one of the 100 seats
- A removed owner can come backSame page. Deleting the owner is not enough.
- Token survivesDelete their HTML file, meta tag or DNS record too
- Business Profile refuses Google GroupsGoogle Business Profile help. Use an agency organisation account instead.
- No groupsNew managers wait seven days before some actions
- A role is not an app approvalA Viewer with the right role can still be blocked by a Workspace admin who has not approved the OAuth app the specialist's tool uses.
- Two approvals
- GA4 Viewer is not read-only in the way you expectGoogle Analytics access management page.
- Can create explorationsAdd the No Cost Metrics or No Revenue Metrics restriction where it matters
- Invitations land in the wrong placeTag Manager containers and GA4 properties look alike in an invitation. Confirm the property ID at first sign-in.
- Verify on day one
- A borrowed login records your work as someone elseMost platforms in the table log changes by account. Shared credentials break the audit trail and every offboarding step.
- Never
The Search Console rules are worth reading in Google's words. Its users and permissions page sets the caps and carries the sentence below, which is the reason an offboarding list has to include verification methods and not just user rows.
As long as a user's verification token remains for a property, a deleted owner can re-verify ownership of the property.Google Search Console Help, Managing owners, users, and permissions, read September 25, 2026
Google Ads has its own onboarding trap, covered in our post on the corporate-email requirement for agency access. And the same scoping rules apply when the specialist is an agent rather than a person: our guides to agent data-access permissions and default-deny agent permissions make the case that a read-only role for a tool is the same decision as a read-only role for a contractor.
04 — The modelThe operating model
Two public standards say what good looks like, and neither is exotic. NIST's account-management control in SP 800-53 Revision 5 (AC-2) calls for temporary and emergency accounts to be removed or disabled automatically after a defined period, and for accounts that are expired or no longer tied to a user to be disabled. CISA's Cross-Sector Cybersecurity Performance Goals (goal 2.D) ask for a defined, enforced process that disables a departing person's accounts and access by the day they leave. The model below is those two requirements applied to a marketing stack where most platforms cannot enforce them for you.
One named access owner
A single person who holds Owner or Admin on every platform in the table, keeps the list of who has what, and is the only route for grants. A second owner exists for continuity, as Google, GitHub and Vercel all recommend, but does not process requests.
A role-per-job template
Each request names the job, the platforms, the exact role from the table, and the end date. The owner grants what the template says and nothing above it. Anything above needs a written reason.
Groups where allowed, partners where offered
Use Workspace groups for Drive, Looker Studio and Google Cloud; partner links for Google Ads, Meta, Microsoft and Webflow; individual accounts for Search Console and Business Profile because there is no other way.
An expiry date on every contractor grant
Set Meta temporary access, Drive expiry and IAM Conditions where available. For the rest, the end date in the request becomes a calendar reminder for the owner, and the offboarding list below runs on that day.
The offboarding list is short and mechanical: remove the user row on every platform in the request; on Search Console, delete their verification method as well; on GitHub, revoke any fine-grained token they created; on Tag Manager, check that nothing they published is still in a workspace they owned; transfer any Looker Studio report they own; and confirm on each platform that keeps an audit log shows the removal. It takes an hour with the list and a week without it.
05 — The requestThe one-message access request
A freelancer starting an SEO project can send this in one message. It is written so the access owner can act on it without a call. Swap the platforms and roles for the job in hand; the shape is the point.
For the SEO engagement starting Monday, please grant my work Google account: Search Console, Full user on the site's properties; Google Analytics 4, Viewer on the main property with the No Cost Metrics restriction if you prefer; Tag Manager, Read on the web container; Google Ads, Read-only via your manager link; Business Profile, Manager on the location group. Please set the end date to the project's end date and remove everything then. I will confirm each grant at first sign-in and will not use any shared login.
Teams that connect these data sources to an AI assistant can reuse the same roles: our GA4 and Search Console MCP build runs on Viewer and Restricted access, and our analytics practice starts every engagement with this request.
A reference table built from official documentation only. Role recommendations are ours; every platform fact is the vendor's.
- What was collected
- For each of twenty platforms: the documented roles and their ordering, whether groups can hold a role, whether a partner or agency model exists, documented user caps, and whether a person's access can be set to expire.
- Sources
- Each platform's own help centre or developer documentation. Two help-centre pages (Webflow and Contentful) blocked ordinary fetching and were read through a rendering service; their rows reflect the page text on the read date.
- As-of date
- Documentation read on September 25, 2026.
- Exclusions
- Where the research could not confirm group support in GA4 or Google Ads, the cell says not documented rather than yes or no.
- Known limitations
- The least-role column is a judgement for a typical engagement, not a vendor statement. Enterprise plans add roles not listed here.
- Refresh
- Refreshed in place when a platform changes its roles, caps or expiry features.
07 — ConclusionMost platforms have the right role; almost none will remove it for you
Name one access owner, adopt the role-per-job template, and put an end date and an offboarding list on every grant that exists today
The table answers the question every new engagement starts with. The operating model answers the one it ends with. Neither needs a new tool; both need someone to own them.