Roles and permissions
Expert: with sources and numbers. Plain: the same, without them, for beginners.
What access an ASO practitioner actually needs on each platform, and the permissions that quietly block the work.
Not a governance topic. The practical question is which access lets someone do ASO work, and which missing permission stops it.
App Store Connect
A Roles include Account Holder, Admin, Finance, App Manager, Developer and Marketing. (Role permissions, verified 2026-09-18)
A The Account Holder can access all of App Store Connect and the Apple Developer site, and is the only user who can sign legal agreements, renew membership, request App Store Connect API access, remove auto-renewable subscriptions from sale, submit Safari extensions, or create developer ID certificates. Same source.
A Admin and Finance can view all app information and cannot have their access limited. Admins can add Developer or Marketing users, and can grant access only to apps they can view. A App Manager, Developer and Marketing roles can be restricted to specific apps. Same source.
A Setting an age rating requires Account Holder, Admin, App Manager or Marketing (Set an app age rating, verified 2026-09-18).
A Responding to reviews requires Admin or Customer Support (Ratings and reviews, verified 2026-09-18).
What an ASO practitioner typically needs: App Manager or Marketing on the relevant apps, to edit metadata, upload creative, configure custom product pages and in-app events, and read App Analytics. Review responses need a separate role, the single most common access gap, because it is not obvious that the person who owns the rating cannot reply to the reviews.
Google Play Console
A There are three access levels: account owner, admins, and users. Permissions can be set at account level (all apps) or at app level (selected apps), and some permissions are available only at one level or the other. (Add developer account users and manage permissions, verified 2026-09-18)
A The “Release to production, exclude devices, and use Play App Signing” permission grants Admin access, and with it the user also receives all other permissions. Same source.
A Permission groups can be created to manage multiple users at once. Same source.
That release permission is the one to watch. It is presented as one permission among many and it confers full admin. Granting someone the ability to publish a release also hands them everything else. Worth knowing before it is granted casually to a marketer who only needed to edit a listing.
Play’s model is finer-grained than Apple’s: you assign permissions rather than a named role, which is more flexible and easier to get wrong.
The practical view
| Task | App Store Connect | Play Console |
|---|---|---|
| Edit store listing text | App Manager / Marketing | Store listing permission |
| Upload creative | App Manager / Marketing | Store listing permission |
| Custom pages / listings | App Manager / Marketing | Store listing permission |
| In-app events / promo content | App Manager | Store listing permission |
| Read analytics | Most roles | View app information |
| Respond to reviews | Admin or Customer Support | Reply to reviews permission |
| Submit a release | App Manager or Admin | Release permission, confers admin |
| Sign agreements | Account Holder only | Account owner |
What goes wrong
Nobody can respond to reviews. Different role from metadata editing on iOS.
Granting Play release permission casually. It confers full admin.
One shared login. No audit trail, and a leaver problem.
Account Holder is someone who left. Only they can sign agreements and request API access. And this surfaces at the worst moment.
ASO cannot edit metadata without asking. Turns a ten-minute change into a two-day request.
In short
Every fact on this page in one line, with its evidence tier, source and verification date, 4 A. Generated from the claim register, so it cannot drift from the page above.
Not a governance topic. The practical question is which key-card lets someone actually do the work, and which missing one stops it cold.
On Apple's side
There are a handful of named key-cards. The person named on the lease can reach everything, and is the only one who can sign paperwork with the centre, renew the lease, ask for certain technical access, pull a subscription from sale, or take out certain identity certificates.
Two of the cards can see everything and can't be narrowed. Holders of those cards can hand out the working cards, but only to shops they can already see themselves. The working cards, the ones that actually edit a shopfront, can be limited to specific shops.
Setting an age notice needs one of the senior cards or the marketing card specifically. Replying to what shoppers say needs a different, separate card again.
What day-to-day shop work actually needs: a working card on the shops that matter, enough to edit the sign and window, upload creative, set up a specially-dressed window or a poster, and read the counter. Replying to shoppers needs a separate card entirely, and it's the single most common gap, because it's not obvious that the person who owns the rating can't answer the comments underneath it.
On Google's side
There are three broad levels: the person who opened the account, admins, and everyone else with a specific card. Cards can be handed out for the whole account or for one shop at a time, and some cards only exist at one of those two levels.
One particular card, letting someone actually open a refit to visitors, quietly comes bundled with every other card at once. It's presented as one item on a long list, and handing it out casually hands out everything else along with it.
That one card is worth watching closely. Giving someone the ability to open a refit also, without saying so, gives them every other permission there is. Worth knowing before it's handed to someone who only needed to edit a leaflet.
Google's system is more finely sliced than Apple's: individual permissions rather than one named card, which is more flexible and easier to get wrong.
The practical view
Editing your sign, leaflet and hidden filing words needs a working card on both sides. Uploading window photos, and setting up a specially-dressed window or a poster, need the same. Reading the counter is open to most cards. Replying to what shoppers say needs its own separate card on Apple's side, and its own separate permission on Google's side. Opening a refit needs the senior card or admin on Apple's side, and on Google's side needs the one card that quietly grants everything else too. Signing paperwork with the centre stays with whoever holds the lease, or the account owner.
What tends to go wrong
Nobody can reply to what shoppers say. A different card from the one that edits the sign.
Handing out Google's "open a refit" card casually. It grants everything else along with it.
One shared card for the whole team. No record of who did what, and a real problem the day someone leaves.
The person named on the lease has moved on. Only they can sign paperwork or ask for certain technical access, and this is discovered at the worst possible moment.
Whoever runs the shopfront day to day can't actually edit it without asking someone else. Turns a ten-minute fix into a two-day wait.