APPSINITYTeams and roles
Roles and permissions
Nine permission keys exist, and five role presets assign them. A member's effective access is the preset plus any per-key override.
Open Appsinity StudioOn this pageThe nine permission keysThe five presetsLeast privilege in practiceWhat the model does not haveFrequently asked questions
The nine permission keys
| Key | Grants |
|---|---|
view_dashboard | Opening the app dashboard at all |
manage_listings | Editing listing text, assets and metadata |
publish_listings | Changing publishing status — the switch that makes a listing public |
view_analytics | Reading traffic, downloads and charts |
manage_ads | Ad configuration and the earnings figures |
manage_webpages | The hosted-page routes |
manage_members | The right exists in the model, but the member routes still require the owner |
manage_settings | Advanced settings, declarations and deletion |
manage_billing | Payout details |
Watch out:
manage_members is not sufficient to manage members. The team routes check ownership of the workspace, not this key — do not tell a team an admin "can add people".The five presets
Note what editor does not include: no manage_settings, so an editor cannot delete an app, change declarations or reach the financial and health sheets.
| Role | Keys granted |
|---|---|
owner | All nine |
admin | All except manage_billing |
editor | view_dashboard, manage_listings, publish_listings, view_analytics, manage_webpages |
analyst | view_dashboard, view_analytics |
viewer | view_dashboard only |
custom | Whatever the patched permission object says |
Important:
editor holds publish_listings. Anyone with that key can make a build public without a review step, because there is no review step.Least privilege in practice
- Do not share the owner login to give someone access. Invite them; the login is the only thing that cannot be scoped.
- Review the member list whenever someone leaves a team, not once a quarter.
- Prefer a custom grant over promoting a person to admin for one permission.
| Person | Role | Why |
|---|---|---|
| Founder or account holder | owner | Only the owner can manage members |
| Release manager | admin | Publishes and configures; billing stays with the owner |
| Content designer or marketer | editor | Listing text, assets and the publish switch |
| Data or growth analyst | analyst | Read-only numbers |
| QA or a contractor trialling access | viewer | Sees the dashboard, changes nothing |
| Finance person | custom | Grant manage_billing alone plus view_dashboard |
What the model does not have
- Per-app scoping: a member is granted against the workspace, not one project.
- Time-limited access or expiry.
- An approval workflow for a change made by an editor.
- An audit log of who changed what.
- Separate read and write analytics rights —
view_analyticsis one key. - A second factor per member, see Two-factor authentication.
Not available: Because there is no audit log, the practical control is naming: keep the member list small enough that a bad change is attributable by looking at who has
manage_settings.Frequently asked questions
Can an admin change the owner's payout method?
No — admin explicitly excludes manage_billing.
What is the safest role for an external agency?
editor if they must publish, analyst if they only report. Never admin for an external party, since it includes manage_settings and therefore deletion.
Can permissions be scoped to one app?
No. Workspace-wide only.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]