Roles and Permissions

This page is the customer-facing reference for who can do what in Clue2App. It corresponds one-to-one with the platform's authoritative permission matrix and is refreshed every time enforcement changes.

This page moves with the platform: every capability change that reaches production also updates this reference.

---

The role model at a glance

Clue2App has two role scopes plus two account-level flags plus a platform tier. Every access decision the platform makes reduces to a combination of these five things.

Account role — one per member per account

Role	What it means for the user
ACCOUNT_ADMIN	Full authority over the account. Manages members, changes anyone's role, creates and deletes projects, converts a trial to billing, adjusts account limits. Implicitly PROJECT_ADMIN on every project in the account.
MEMBER	Belongs to the account. Cannot do anything account-wide on its own — capabilities come from the two flags below plus per-project grants.

Every invited user is a MEMBER unless the inviter explicitly picks ACCOUNT_ADMIN.

Two flags on MEMBER — opt-in account-level capabilities

ACCOUNT_ADMIN gets both of these implicitly. On MEMBER they default to off and an ACCOUNT_ADMIN opts each member in individually.

Flag	What it grants
canCreateProjects	The member can create new projects in the account.
canCreateApplications	The member can create new apps — but only in projects where they also hold PROJECT_ADMIN. This is a conjunction: the account-level flag alone does not grant blanket app-create rights across the account.

The two flags are why a well-shaped organisation can have a "team lead" MEMBER who is PROJECT_ADMIN on team-alpha and can spin up new apps there, but cannot touch team-beta even though the same person has canCreateApplications on the account.

Project role — one per member per project they belong to

Role	What it means for the user in that project
PROJECT_ADMIN	Full control of the project: deploy, edit apps, manage secrets and custom domains, invite / remove project members, delete the project.
CONTRIBUTOR	Ship code and tweak runtime: deploy revisions, restart, rebuild, edit env vars and autoscale knobs. Cannot manage secrets, domains, or members.
VIEWER	Read-only: browse apps, logs, builds, metrics. No writes at all.

An ACCOUNT_ADMIN gets PROJECT_ADMIN on every project in the account automatically, without an explicit grant row.

Platform tier — Clue2Solve staff

SYSTEM users are Clue2Solve staff acting on your behalf (support, ops, incident response). They are cross-account super-admins. Every action a SYSTEM user takes is audit-logged. You will never grant SYSTEM to your own users; SYSTEM is a property of the Clue2Solve employee's account, not a role you can hand out.

---

What each role can do

The table below covers the actions customers most often ask about. Cells: Yes = allowed, No = denied, Own only = allowed on rows the user owns / is granted, See note = allowed under the condition explained after the table.

Account actions

Action	ACCOUNT_ADMIN	MEMBER	MEMBER + canCreateProjects	MEMBER + canCreateApplications
See who else is in the account	Yes	Yes	Yes	Yes
Invite a new member	Yes	No	No	No
Change another member's role or flags	Yes	No	No	No
Remove a member from the account	Yes	No	No	No
Convert the account from trial to a billing plan	Yes	No	No	No
Create a new project in the account	Yes	No	Yes	No¹
Read your own effective permissions (c2a me permissions)	Yes	Yes	Yes	Yes

¹ The canCreateApplications flag does not grant project creation — that requires canCreateProjects (or ACCOUNT_ADMIN).

Project actions

Action	ACCOUNT_ADMIN²	PROJECT_ADMIN	CONTRIBUTOR	VIEWER	MEMBER (no grant)
View the project	Yes	Yes	Yes	Yes	No
Rename the project	Yes	Yes	No	No	No
Delete the project	Yes	Yes	No	No	No
Add or remove project members	Yes	Yes	No	No	No
Provision Daari services (Postgres, S3, DynamoDB, …)	Yes	Yes	No	No	No
Turn log capture on / off	Yes	No	No	No	No

² ACCOUNT_ADMIN gets these implicitly on every project in the account.

App actions

Action	ACCOUNT_ADMIN²	PROJECT_ADMIN	CONTRIBUTOR	VIEWER	MEMBER + canCreateApplications
View the app	Yes	Yes	Yes	Yes	Yes
Create an app	Yes	Yes	No	No	See note³
Delete an app	Yes	Yes	No	No	No
Rename the app	Yes	Yes	Yes	No	No
Deploy a revision (push new code, rebuild, restart)	Yes	Yes	Yes	No	No
Edit environment variables and autoscale settings	Yes	Yes	Yes	No	No
View logs, builds, metrics	Yes	Yes	Yes	Yes	Yes
Manage secret bindings	Yes	Yes	No	No	No
Assign or remove a custom domain	Yes	Yes	No	No	No

³ canCreateApplications is a conjunction with PROJECT_ADMIN. A MEMBER with the flag can create an app only in a project where the same user also holds PROJECT_ADMIN. The flag alone, or PROJECT_ADMIN alone (for a MEMBER without the flag), is not enough. If the platform denies your app-create request the console shows one of three specific reasons: can_create_applications_required, project_admin_required, or the combined can_create_applications_and_project_admin_required, so you know which of the two conditions to fix.

Billing actions

Billing lives entirely under ACCOUNT_ADMIN today. There is no dedicated "billing only" role in the current release — an ACCOUNT_ADMIN either has the whole account or does not.

Action	ACCOUNT_ADMIN	Everyone else
Convert trial to billing plan	Yes	No
Change plan / payment method	Yes	No
View invoices	Yes	No

---

Common scenarios

"I invited someone but they can't see anything."

They were invited without a project grant. Invite them to at least one project with --project and a project role (or grant the project role from the console's Access → Members screen), or make them ACCOUNT_ADMIN.

"My developer wants to create their own apps in the shared project."

Two changes, in order:

1. ACCOUNT_ADMIN sets the member's canCreateApplications flag to true (c2a user invite … --can-create-applications, once available on the CLI; today go through the console Access → Members detail).
2. ACCOUNT_ADMIN (or an existing PROJECT_ADMIN on that project) upgrades the member's role on the project to PROJECT_ADMIN.

The member can then create apps in that project — but not in any other project where they don't also hold PROJECT_ADMIN.

"I want a read-only user for compliance."

Invite as MEMBER, no flags, and grant VIEWER on the projects they need to observe. VIEWER reads app metadata, logs, builds, and metrics but never sees secret values.

"I want to delegate project management without giving up the account."

Invite as MEMBER, set canCreateProjects and canCreateApplications both true. On each project the delegate manages, grant PROJECT_ADMIN. They now cover the same day-to-day surface as an ACCOUNT_ADMIN except they cannot invite account-level members, change other members' roles, delete the account, or manage billing.

"Can I write my own custom roles?"

Not today. Clue2App ships a fixed role set so every access decision is enumerable for SOC 2 evidence. Custom roles are on the v1.1 aspirational roadmap and would require an entity change; follow the tracking ticket if you need this.

---

The two flags — a note on defaults

Both canCreateProjects and canCreateApplications default to off for a new MEMBER invite. This is the safer default: a new hire who receives a project grant on their first day can ship code (as CONTRIBUTOR) but cannot spin up new projects or apps until the account admin explicitly opts them in. Elevating a member from "no flag" to "flag on" is a one-click change; retroactively cleaning up a MEMBER who created a proliferation of projects on their first week is not.

---

Where enforcement lives

Every capability on this page is enforced server-side by the Clue2App platform — the console and CLI are convenience surfaces on top. If the console lets you attempt an action the server rejects, you will see a specific error message with the reason (e.g. can_create_applications_required, project_admin_required, Cross-account moves aren't supported automatically yet.). Those reasons come straight from the API; report the exact reason string when opening a support ticket and Clue2Solve staff can match it to the enforcement point.

---

Version and staleness

This page is refreshed by the same PR that changes any capability in the platform. If you see guidance here that disagrees with what the platform does, please report it — the reference matrix and this page are meant to move together.