If you work with a team, a client, or a contractor on your Android app, you will need to give people access to the Google Play Console — and doing that correctly, with the right permissions, is both a security matter and a practical one for running your closed test smoothly. Granting too much access is risky; granting too little blocks people from doing their jobs. Understanding the Console's user and permission model lets you collaborate safely. And because any app from a new personal account must complete a closed test with at least 12 testers opted in for 14 continuous days before production access, this guide also covers how permissions intersect with managing that test.
The closed-testing process is the same regardless of team size, but the moment more than one person is involved, permissions become part of running it well. Setting them up correctly turns collaboration into an asset rather than a security liability.
The requirement and collaboration
The closed-testing requirement is tied to your developer account type, so any app on a new personal account must complete a closed test with 12+ testers for 14 continuous days before production access. See the closed testing guide. If others help you manage that test — uploading builds, managing tester lists, reviewing metrics — they need appropriate Console access, which you grant through the Console's user and permission system. Review Google's manage users and permissions guidance.
Standard advice applies: recruit committed, device-diverse testers, keep your count above 12, and prepare your listing in parallel. Layer on permissions so that everyone who needs to contribute to the test can, without exposing your account to unnecessary risk.
The Console permission model
The Play Console lets you invite users by email and assign them permissions, either account-wide or scoped to specific apps. Permissions are granular — you can grant abilities like viewing app information, managing testing tracks and releases, editing the store listing, replying to reviews, or viewing financial data, among others. You can also use permission groups to apply a consistent set of permissions to multiple users, which is helpful as a team grows. The principle to follow is least privilege: grant each person only the permissions their role genuinely requires.
For example, a developer who uploads builds needs release management for your app but does not need financial access; a marketer editing the listing does not need to manage releases. Scoping access to specific apps is especially useful if your account holds multiple apps and a contractor should only touch one. Thinking in terms of roles and least privilege keeps your account secure while letting collaborators work. See agency guide to client apps.
Common roles for a closed test
For running a closed test with a small team, a few permission patterns cover most needs. Whoever uploads and promotes builds needs the ability to manage testing tracks and releases. Whoever manages the tester list and communications may need access to testing configuration. Whoever prepares the listing needs store-listing edit rights. And you, as the account owner, retain full control and the sensitive permissions like financial and account management that you should rarely delegate.
| Role | Typical permissions |
|---|---|
| Developer | Manage releases and testing tracks |
| Listing/marketing | Edit store listing, reply to reviews |
| QA/tester manager | View testing config and reports |
| Owner | Full access, including financial and users |
Grant per-app access when a collaborator should only touch one app. See multiple apps on one account.
Security and offboarding
Permissions are a security surface, so manage them actively. Only invite people you trust, grant the minimum they need, and — critically — remove or reduce access promptly when someone's involvement ends. A contractor who finished their work should not retain release access indefinitely, and a departed team member's access should be revoked immediately. Periodically review who has access to your Console and prune anything unnecessary, since stale permissions are a common, avoidable risk. The account owner's own credentials deserve the strongest protection, including two-factor authentication.
Never share a single login among multiple people; instead, invite each person with their own account and appropriate permissions, which preserves accountability (you can see who did what) and lets you revoke individuals cleanly. Treating Console access with the same discipline as any sensitive system protects the app you are working hard to launch and the account it lives on. See account termination risks.
Testers are separate from Console users
An important distinction: your 12+ closed testers are not Console users. Testers simply opt into your test via a link or group and install your app — they never touch the Console and need no permissions there. Console users are your collaborators who manage the app. Do not confuse the two: adding someone as a Console user does not make them a tester, and adding a tester does not grant Console access. You still need 12+ committed, device-diverse testers for 14 continuous days, managed through your testing track, entirely separately from your team's permissions.
If assembling that tester group is your bottleneck, a service that supplies verified real testers solves it quickly, independent of how you structure Console access. You can submit your app to get started, and read where to find real testers and how to keep testers engaged.
Setting up permissions well
Because you will likely add collaborators at some point, setting up permissions thoughtfully from the start saves cleanup later. Decide the roles you need, invite each person individually with least-privilege access scoped to the right apps, and use permission groups if your team is more than a few people. A well-structured permission setup means everyone can do their part of the closed test and launch without friction, and your account stays secure throughout.
Revisit your permissions as your team and app portfolio change, keeping access aligned with current roles. Good permission hygiene is quiet but valuable: it prevents both the frustration of blocked collaborators and the risk of over-broad access. See the Play Console beginner guide.
Permissions across testing tracks
The same permission model governs who can manage your internal, closed, and open testing tracks and your production releases. Someone with release-management permission can upload to and promote across these tracks, so grant it to those responsible for your build pipeline. If you want a collaborator to help only with pre-production testing but not production releases, note that release permissions generally span tracks, so rely on trust and clear process for the production step rather than assuming granular per-track gating. Keeping your build-pipeline permissions with a small, trusted set of people keeps releases controlled. See internal vs closed testing.
As you move from internal to closed to staged production rollout, the people with release access are the ones executing each promotion, so align your permission grants with who you actually want performing those sensitive steps. See staged rollouts.
After launch: maintain access hygiene
Your closed test is one phase; permission management continues for the life of your app. After launch, keep reviewing who has Console access, remove collaborators whose work is done, and adjust roles as responsibilities shift. Protect the owner account with strong authentication, and never let stale access accumulate. An account with disciplined, current permissions stays secure and easy to manage as it grows; one with sprawling, forgotten grants becomes a liability. See post-launch monitoring.
Account-level vs app-level permissions
The Console distinguishes between permissions granted across your entire account and those scoped to individual apps, and understanding the difference is central to safe delegation. Account-level permissions apply to everything in your account and include sensitive capabilities like managing users, viewing financial data, and administering account settings — these you should keep tightly held. App-level permissions restrict a collaborator to specific apps, so a contractor working on one product cannot see or touch the others. For anything but a solo account, preferring app-scoped grants is the safer default.
This matters most as your portfolio grows. If your account eventually holds several apps, an account-wide grant means every collaborator sees every app, which is rarely what you want. Scoping access per app keeps each person's reach aligned with their actual responsibility and limits the blast radius if a collaborator's account is ever compromised. Thinking explicitly about account-level versus app-level when you invite each person is a small habit that pays off in security and clarity. See multiple apps on one account.
Protecting the owner account
Your owner account is the most valuable and most dangerous credential in the whole setup, because it can do everything — publish, delete, manage users, and access finances. Protect it accordingly: enable strong two-factor authentication, use a unique and strong password, and be extremely cautious about where and how you sign in. Never delegate owner-level access casually, and never share the owner login. If the owner account is compromised, your entire developer presence — every app, every user, your revenue — is at risk, which is a far worse outcome than any single collaborator issue.
Treat recovery options seriously too: keep your recovery email and phone current so you can regain access if something goes wrong, and ensure the account is not tied to an address you might lose. Many painful developer horror stories trace back to a poorly secured owner account, and almost all are preventable with basic account hygiene. The strength of your permission model rests on the security of the account at its apex. See account termination risks.
A permissions workflow for your test
Putting it together, a sensible workflow for a small team running a closed test is: create the account and secure it with two-factor authentication; invite each collaborator individually with least-privilege, app-scoped permissions matching their role; use permission groups if you have more than a few people; and document who has what access so it is easy to review. As the test runs, whoever needs to upload builds, manage the tester track, or edit the listing can do so, while sensitive account and financial controls stay with you.
When the test ends or roles change, promptly adjust or revoke access, keeping your permission map current. This lightweight discipline means your collaboration is both frictionless and secure throughout the window and beyond. It scales naturally as your team and app portfolio grow, so establishing it now sets a good precedent. See agency guide to client apps.
Auditing access regularly
Even a well-set-up permission structure drifts over time as people join, leave, and change roles, so schedule periodic access reviews. Open your Console's user list, confirm each person still needs their current access, remove anyone whose involvement has ended, and tighten any grant that has become broader than necessary. This audit takes minutes and repeatedly catches the stale contractor access and over-broad grants that are the most common Console security gaps.
Make the review a recurring habit rather than a one-time setup, especially after milestones like finishing your closed test, shipping a launch, or ending an engagement. An account whose access is regularly pruned stays secure and comprehensible; one where grants only ever accumulate becomes a growing, unmonitored risk. See the Play Console beginner guide.
Key takeaways
- The 12-tester, 14-day requirement applies regardless of team size.
- Grant least-privilege permissions scoped to roles and specific apps.
- Testers are not Console users — they opt in via a link, needing no Console access.
- Remove access promptly when someone's involvement ends.
- Never share a single login — invite each person individually for accountability.
Frequently asked questions
Do my testers need Console access?
No. Testers opt into your test via a link or group and install the app; they never use the Console and need no permissions there.
How do I add a team member to the Console?
Invite them by email in the Console's users and permissions settings and assign least-privilege permissions, scoped to specific apps if appropriate.
What permissions does a developer need for closed testing?
The ability to manage testing tracks and releases for your app. They do not need financial or account-management access.
Should I share my login with collaborators?
No. Invite each person with their own account and permissions to preserve accountability and allow clean, individual revocation.
How do I remove someone's access?
Revoke or reduce their permissions in the Console immediately when their involvement ends, and periodically review for stale access.
Can I limit access to one app?
Yes. You can scope permissions to specific apps, which is useful for contractors or when your account holds multiple apps.