Google Play Collaborator Access: A Permission Checklist for App Owners

Give a collaborator the access needed for named work, not a shared Google login. Before inviting a developer, agency or publishing operator, list the apps, tasks, release authority, review date and person responsible for removing access. A permission checklist makes that decision inspectable before work starts.

Google's Play Console distinguishes account-level access from access to selected apps. Owners and administrators manage users; individual permissions control the work a user can perform. This article offers a planning method, not a universal permission preset.

Write the job before selecting permissions

“Help with my app” is too broad to approve. Replace it with a concrete task, such as inspecting a draft listing, preparing a release for your approval, reviewing technical reports or maintaining one named app. Record whether the collaborator needs to change something, view it, or only receive an exported report.

Separate permission to prepare work from authority to make a business decision. If the owner wants to review every production release, the workflow should say who prepares the build, who checks the declarations and who gives the final go-ahead. Access settings alone are not a complete approval process.

A task-to-access worksheet

Work requested	Scope question	Evidence to retain
One app's listing	Can the work be limited to that app?	Package name and approved listing changes
Release preparation	Who may upload, review and release?	Build version and approval trail
Performance review	Is view access or an export sufficient?	Report scope and review period
Ongoing maintenance	Which apps and how long?	Owner, review date and handover plan
Account administration	Why would app-level access not suffice?	Specific need and owner approval

Invite a named user and check the actual scope

Use the Users and permissions area and the collaborator's confirmed email address. Google's documentation permits invitations with an access expiry date and explains that an invitation without expiry continues indefinitely. Review the current permission descriptions rather than relying on an old screenshot or another app's setup.

Ask the collaborator to confirm they accepted the invitation under the intended identity. Then check a harmless required task, such as opening the selected app's relevant screen. “The invite was sent” and “the collaborator can do the approved work” are different acceptance checks.

A temporary job should have an end condition

For a short engagement, record both an expiry and a completion condition. The condition might be delivery of a tested release candidate and its documentation. An expiry is useful, but it does not tell the next person where the build, source or project records are located.

For ongoing work, set a regular access review that fits your own operations. Check whether each collaborator is still assigned to the app and whether their tasks have changed. Remove unnecessary permissions through the supported controls; do not test a sensitive production action merely to see whether it is available.

Keep account access separate from release materials

A Play Console invitation does not transfer a source repository, domain, signing keystore, advertising account or privacy-policy website. Make a separate ownership register for those assets. Giving someone a console role is not evidence that the app can be rebuilt without them.

Use the signing and handover checklist to identify release materials. For a build you have not inspected, start with the APK and AAB inspection guide.

Record a clean handover and removal

1. Collect the agreed source, release notes, build instructions and operational documents.
2. Identify any remaining scheduled work or support responsibility.
3. Review the named user's remaining Play access and remove it when the work no longer requires it.
4. Review access to the other project systems separately.
5. Retain a dated record of what was delivered, checked and removed.

Do not assume removal from one system removes access everywhere. A former collaborator may still have repository access or a service credential in a separate platform. Handle those systems through their own supported administrative processes.

Questions to settle with a publishing operator

Ask which apps will be maintained, who approves a release, how you see changes, which information you receive and what happens when the relationship ends. A request for a password, recovery code or ownership credentials is not a substitute for answering those questions.

Commercial disclosure: Preciousky promotes ConsoleMint. Its published model uses scoped Developer-role collaboration for the apps it builds and maintains; the exact work and access must be agreed for the case. Review the publishing-partner information, including responsibilities and exit terms, rather than treating this checklist as approval of a particular arrangement.

Primary reference

Google Play: add users and manage permissions, checked on publication. The worksheet and handover process are editorial aids; consult the live permission descriptions when making changes.