Google Play Console Users and Permissions: Team Access Done Right

The fastest way to create a security incident on Google Play isn't a code vulnerability — it's handing your agency "Admin" access because you were in a hurry. Play Console's permission model is granular enough to do this properly, but most teams never go beyond the defaults. Here's how to set up Google Play Console users and permissions so every person (and service) has exactly the access they need and nothing more.

In short: Play Console permissions work at two levels: account permissions apply to everything, while app permissions apply to specific apps. Give most people app-level access only, scoped to the apps they actually work on, and reserve account admin for one or two founders. Set an expiry date on every contractor invite, and review the whole user list once a quarter.

Granular Google Play Console users and permissions prevent over-privileged team access.

What are the two permission layers?

Play Console permissions operate at two levels, and confusing them is the #1 mistake:

• Account permissions apply across everything: managing users, viewing financial reports, account-level settings. Admins live here.
• App permissions apply to specific apps: releases, store listings, testing, quality data.

Always prefer app-level permissions. An ASO freelancer working on two of your six apps should never have account-level anything. Google's guide to adding users and managing permissions explains how the two levels interact and lists every permission by its exact name.

Which permission groups actually matter?

When you invite a user (Users and permissions → Invite new users), you choose from permission groups. The ones you'll actually use:

Different roles need different groups under Google Play Console users and permissions.

Two critical details people miss:

1. Release rights are split by track. "Release apps to testing tracks" lets a developer ship to internal, closed and open testing without touching production; production needs the separate "Release to production, exclude devices, and use Play App Signing" permission. Give every developer the testing-tracks permission and reserve production for the release manager.
2. "Reply to reviews" is separate from "Manage store presence." Your support team doesn't need listing edit rights, and your ASO person doesn't need to reply to reviews. Split them.

How do I onboard a new team member?

1. Go to Users and permissions in Play Console (account level).
2. Click Invite new users, enter their Google account email. (They need a Google account — not necessarily a Gmail, any Google-linked email works.)
3. Set Account permissions: for most people, none. Seriously — leave it blank.
4. Under App permissions, click Add app, select the specific apps, then tick only the needed groups per app.
5. Set an access expiry date for contractors. This is the feature everyone forgets and then regrets. A 90-day expiry on agency access means you never have to remember to revoke it.
6. The invitee accepts via email. Verify their access shows the correct scope before they start work.

Follow these steps when onboarding with Google Play Console users and permissions.

One more detail: an invitation expires after 30 days if the invitee doesn't accept it, so if someone never shows up in your user list, resend the invite rather than assuming the permissions are wrong.

How do service accounts fit in?

CI/CD pipelines, fastlane, and the Gradle Play Publisher plugin authenticate as service accounts — Google Cloud service accounts you invite like users. Treat them with the same least-privilege discipline:

# Create the service account in Google Cloud gcloud iam service-accounts create play-publisher \ --display-name "Play Console publisher (CI)" # Create and download a key (store in CI secrets, never in the repo) gcloud iam service-accounts keys create play-key.json \ --iam-account play-publisher@your-project.iam.gserviceaccount.com 

Then in Play Console: invite play-publisher@your-project.iam.gserviceaccount.com under Users and permissions, grant it Release apps to testing tracks permission scoped to the specific apps (and ideally testing tracks only for dev pipelines, production only for the release pipeline). Two separate service accounts — ci-testing and ci-production — is the clean setup. If the testing key leaks, production is untouched.

Rotate service account keys on a schedule — quarterly is reasonable. And never commit play-key.json to version control; that's how keys end up on GitHub and in someone else's pipeline.

What does the quarterly access review cover?

Permissions rot. People change roles, contractors finish, co-founders drift. Every quarter:

• [ ] Export the user list from Users and permissions
• [ ] For each user: do they still need this access? At this scope?
• [ ] Check access expiry dates — extend or let lapse deliberately
• [ ] Verify no former employees or finished contractors remain
• [ ] Confirm service account keys were rotated
• [ ] Check that exactly 1–2 people hold account Admin (never more than necessary)

The most common finding in these reviews: an agency that finished six months ago still has production release rights. The expiry-date feature exists precisely to prevent this.

What about special cases?

Transferring ownership when a founder leaves. Don't just add the new person as Admin — remove the departing founder's access entirely, rotate service account keys they may have seen, and update the account's contact email and developer name if needed.

External translators or designers. They typically need nothing in Play Console at all — screenshots and strings can move through your project management tools. If they insist on direct access, store-listing edit rights on the specific app, with an expiry date.

Multiple organizations, one developer. If you consult across clients, ask each client to invite your Google account to their Play Console with scoped app permissions — never the reverse. Your account stays clean, and offboarding is their one-click revoke.

What to do when something goes wrong

If you discover over-privileged access after the fact:

1. Revoke immediately — don't wait for a "convenient time."
2. Check the Activity log, where Play Console records changes made in the console, for anything done with the excess access.
3. If a service account key may have been exposed, rotate it and check recent release history for unexpected uploads.

Getting the permission model right from the start is far cheaper than auditing it after a scare. If you'd rather have the whole setup — users, roles, service accounts, CI scoping — configured correctly in one pass, hands-on help with Play Console account setup covers exactly this kind of operational groundwork.

FAQ

Should I give my agency account admin access?

No. Admin is the one permission that grants everything, including inviting and removing users and changing other people's permissions. Give the agency app-level access scoped to the apps they work on — usually Manage store presence and Release apps to testing tracks — and set an expiry date so the access lapses when the engagement ends.

What is the difference between account and app permissions?

Account permissions apply to your whole developer account and every app in it — managing users, viewing financial reports and account settings. App permissions apply to one selected app only, such as releasing to its testing tracks or editing its store listing. Prefer app permissions; most people never need anything at account level.

How do I stop a contractor keeping access after the work ends?

Set an access expiry date when you send the invite — Play Console offers a "Set access expiry date" checkbox for individual users and permission groups. A 90-day expiry on agency access means it lapses on its own. Also run the quarterly review and remove anyone who no longer needs access.

Do team members need a Gmail address to join my Play Console account?

No. Invitees need a Google Account, but they can create one with an existing email address, such as a company address — it does not have to be Gmail. The catch is exactness: they must sign in with the same email address you put on the invitation, or Play Console will not let them in.

What happens if someone never accepts my invite?

The invitation expires after 30 days, and you have to resend it. If the person still cannot get in after accepting, check that they are signing in with the exact email address on the invitation — Play Console only accepts that address, not an alternate Google Account they happen to own.

Can I see who changed permissions or shipped a release?

Yes. Play Console keeps an Activity log that account admins can review for changes made in Play Console, including permission changes. If you discover over-privileged access, revoke it immediately, check the log for anything done with the excess access, and rotate any service account keys that may have been exposed.

About the author: This guide was written by the team at Play Console Store — an independent marketplace for Google Play publishing services, not affiliated with or endorsed by Google LLC. We help Android developers with Play Console account setup, closed testing coordination, and policy compliance. Note that each developer must register their own Play Console account ($25 one-time fee).