Every action inside Play Console is gated by a permission, and in 2026 those permissions are organised on three axes: the access level of the person, the scope of the grant, and an optional expiry date. Get the combination right and a contractor can upload a closed-test build without ever seeing your revenue reports. Get it wrong and a reviewer who was only supposed to answer user comments can push a release to production. This guide walks the Users and permissions page end to end — access levels, account versus app scope, permission groups, expiry dates, removal — and finishes with the parts of team access that do not live inside Play Console at all.

Three access levels, and the one that cannot be replaced

Before you add anyone, decide which of the three levels you are handing out, because only one of them is irreplaceable.

The operational consequence is simple: keep at least one admin at account level so that user management never depends on a single login. Adding someone as a user does not transfer ownership of the account, no matter how many permissions you switch on for them.

Step 1 — Decide between account access and app access

Every grant is either account level (it applies to all apps, including apps you add later) or app level (it applies only to the apps you select). Google's documentation is explicit that some permissions exist at only one of the two levels, which is why the same idea can appear twice under slightly different names:

Note what neither of the draft-app permissions does: they do not publish anything. Google deliberately separates "prepare a release" from "release to production", and the permission names carry that distinction.

Step 2 — Add users and switch permissions on or off

  1. Open Play Console and go to Users and permissions. To change an existing person, click anywhere on their row. To add someone new, type their email address and set an access expiry date if the access is temporary.
  2. Choose the scope. Use the App permissions tab for per-app grants — select Add app, pick the apps, then Apply — or the Account permissions tab for grants that should cover every app in the developer account.
  3. Click Invite user. You need the Admin (all permissions) permission at account level to do this at all.

Two details catch people out. The invited person must sign in with exactly the email address you invited — not an alias, and not a personal Gmail address if you invited a company one. And if you leave the expiry field empty, the access never lapses on its own; it stays indefinitely until somebody removes it.

Permission groups, for teams instead of individuals

Once more than a handful of people need the same shape of access, stop editing people one at a time and create a permission group instead. Go to Users and permissions → Permission Groups → Create permission group, give it a name, optionally tick Set access expiry date, add an internal description that only the account's admins can read, select the app and account permissions you want the group to carry, then add the members on the Users in this group tab and click Create group. Everyone in the group inherits those grants, and deleting the group withdraws them from all of its members at once. If you skip the expiry date, the permissions the group hands out do not expire by themselves.

Invitations and expiry dates

What the "Admin (all permissions)" switch really does

The generic admin permission behaves differently depending on where you grant it. An admin scoped per app can see every user who has permission to access the same apps, but cannot remove a user whose access is global. An admin holding the permission globally can additionally change access expiration dates and review what happened in the account through the Activity log. If your internal controls depend on somebody being able to audit who changed what, that is the distinction that matters — and it is the reason a global admin grant deserves a written reason.

Permissions that live outside Play Console

Three surprises worth planning for:

When the permissions are wrong

The most common symptom is Error 403 inside Play Console: the person signs in, the app is visible, but a section refuses to load. That is a missing permission rather than a broken account, and the fix is to ask the account owner to grant the permission for that app. Other patterns are worth recognising in advance. Someone who can upload files but cannot send a release to production is missing Release to production, exclude devices, and use Play App Signing. Someone who does hold that permission is one mis-click away from a live release, so when the job only needs a testing track, grant Release apps to testing tracks alone — it covers draft uploads, testing releases, .obb files, internal sharing and release notes, and it cannot publish to production. And somebody who can refund orders and cancel subscriptions still cannot see aggregate financial reports unless they also hold a financial data permission.

Checklist before you hand out access

  1. Does this person need account scope, or only one app?
  2. Is the access temporary? If so, set the expiry date at the moment you invite them.
  3. Does the job involve publishing to production, or only to a testing track?
  4. Do they need production publishing but not store listing or pricing changes?
  5. Will they reply to reviews, manage policy declarations, or handle orders and refunds?
  6. If financial data is involved, do they also need to be added in the payments centre?
  7. Is there a second account-level admin, so user management never depends on one login?

The one-line model: the account owner is the only irreplaceable level and the only one that can manage payments; admins can be delegated but their power differs depending on whether the grant is global or per app; every permission is either account-wide or app-only, and some only exist at one of the two; and any grant without an expiry date is permanent until somebody removes it. Grant the narrowest permission that does the job, and set the end date when you start.

Sources