Roles capability matrix

Ronja has four roles. Lower in this list means fewer permissions. For the concepts behind the matrix, see Roles and permissions; to assign roles, see Manage users and roles.

The four roles

Role	In one line
Super Admin	The org owner. Assigned automatically to whoever creates the organization — has every permission, including promoting other members to Admin.
Admin	Runs the access group. Manages people, settings, and the data layer — connects sources, builds tables, and schedules jobs.
User	Everyday use. Explores data and asks Ronja.
User Read-Only	View-only access, plus their own chats with Ronja — perfect for stakeholders. Changes nothing shared.

New invitees start as User Read-Only until an admin upgrades them. A member with no role at all fails every permission check.

Capability matrix

✓ = allowed · ◐ = allowed with conditions (see footnote) · — = not allowed

Capability	Super Admin	Admin	User	User Read-Only
View shared tables, apps & knowledge	✓	✓	✓	✓
Run analyses & ask Ronja in explorations	✓	✓	✓	◐ ¹⁹
Create notes & knowledge (through chat)	✓	✓	✓	—
Upload files (CSV, Excel, …)	✓	✓	✓ ¹	—
Create top-level folders in Files	✓	✓	—	—
Manage folder access — who can read or write a folder	✓	✓	—	—
Read every file, including each member’s private My Files	✓	✓	—	—
Create features	✓	✓	✓ ²	—
Build & edit tables	✓	✓	◐ ³	—
Connect & manage data sources	✓	✓	—	—
Connect a mailbox & have Ronja read it in chat ¹⁷	✓	✓	—	—
Schedule automations in shared features	✓	✓	— ⁴	—
Read shared skills, secrets, workflows & apps	✓	✓	✓	✓ ⁵
Create & edit shared skills, secrets, workflows & apps	✓	✓	◐ ⁶	—
Edit, delete or restore an item in another member’s private feature	✓	✓ ¹⁸	—	—
Request promotions & propose new shared resources	✓	✓	✓ ⁷	—
Connect personal MCP servers	✓	✓	✓	—
Choose the AI model & reasoning effort per chat	◐ ⁸	◐ ⁸	◐ ⁸	—
Approve promotions & note / workflow / Saved-Agent proposals; commit drafts	✓	✓ ⁹	—	—
Approve app proposals	✓	✓ ¹⁰	—	—
Drive an app with interaction steps while Ronja renders it ²⁰	✓	✓	—	—
Verify, retire & acknowledge-drift on tables and metrics	✓	✓	—	—
View the member directory	✓	✓	✓	✓
Invite members & assign roles	✓	✓ ¹¹	—	—
Manage organization & access group settings	✓	✓	—	—
View every member’s explorations	✓	✓ ¹²	—	—
Delete & restore access groups (30-day trash)	✓	✓	—	—
Delete & restore features (30-day trash)	✓	✓	—	—
Delete & restore tables (30-day trash)	✓	✓	—	—
Permanently purge trashed items before the 30 days	✓	✓	—	—
Manage access groups, features & tables through chat (admin tools)	✓	✓ ¹³	—	—
Promote members to Admin or Super Admin	✓	—	—	—
Buy credits	✓ ¹⁴	—	—	—
Delete the organization	✓ ¹⁵	—	—	—
Register a login domain (auto-join)	✓ ¹⁶	—	—	—

Footnotes

Any member except User Read-Only can upload files in a conversation. Managing the files inside an organization-scoped feature additionally requires Admin.
New features are private to their creator until promoted to the organization.
Users can propose edits to shared tables as drafts; an Admin reviews and commits them. Building or editing tables directly requires Admin. Over the API and the CLI a User can go further with that draft: for a Derived table or a Metric they can read — those are the only two kinds that can be drafted at all; every other table type is written or synced directly — they can check out their own draft, change its SQL, run it to see the result, and submit it for review. The Admin bar is at commit. Running a draft is not the same as an AI-assisted Build or Fix, which stay Admin-only. Drafts are per-person: a colleague cannot touch yours, but an Admin can, so they can fix one up before approving it. This also covers writing, importing, clearing, or restoring a table’s data through chat: adding rows to, replacing, importing into, wiping, or restoring an earlier version of a table that lives in an organization-shared feature requires Admin — the same bar as creating one. A User can still freely write to their own private-feature tables and to scratch tables inside a single chat. See Versions, drafts, and approvals.
Any member can create automations in their own private features. Automations in organization-scoped features require Admin.
Read access to shared resources is decided by access group membership, not role — a User Read-Only member of an access group can view that access group’s shared resources. Private resources are visible only to their creator.
Users can propose new shared resources for review (an approver decides before they go live); creating or editing shared resources directly requires Admin.
Any member with read access to a shared feature can propose a brand-new shared note, workflow, app, or Saved Agent there; an approver reviews it before it goes live.
The per-chat model + effort picker is an admin-granted capability (Control Center → Models & effort). Super Admins always hold the capability (User Read-Only never does), but the picker only appears when the organization’s credit wallet has been funded and no spend downshift is active — for everyone, Super Admins included. See Govern AI spend.
Deleting a shared MCP server requires the Admin role.
App proposals and shared app drafts require the Admin role.
Admins can only assign roles below their own level — an Admin cannot make someone Admin or Super Admin. You also cannot demote yourself if you are the only member at your level or higher.
Admins can open any member’s exploration — including private ones — for support and governance. Everyone else sees only explorations shared with them.
Each destructive admin action requested through chat still requires explicit human approval in the conversation.
From the Billing page. Purchases are added to your next invoice — no card is charged. See Credits and AI spend.
Only from a logged-in browser session (never via API token). The organization shuts down immediately for every member; data is permanently deleted after a 7-day cooling-off window — contact Ronja support to restore it before then.
Only the domain of your own login email can be registered, verified via a magic link. Anyone who then logs in with a matching email joins at the chosen default role.
Mailboxes are Admin only. Connecting, reconnecting, or disconnecting a mailbox requires Admin, and so does reading, replying to, or triaging a mailbox inside a chat. An Admin approves every new email per-send; if the mailbox’s allowed-recipients list is set it restricts where an automation or a workflow may send, while an Admin’s own approved sends are unrestricted. The exception to needing an Admin present is an automation, a Saved Agent, or a workflow: an Admin attaches the mailbox to it, and it then works the mailbox through that binding — so an automation on the Mailbox trigger can answer mail as it arrives, and a workflow can send mail as the mailbox, without an Admin running it. Attaching is itself Admin only, and a non-Admin who tries is refused — the refusal is the same whether or not the mailbox exists, so it never reveals which mailboxes are connected. A workflow can only send; saving one that sends as a connected mailbox requires Admin, and reading, replying, and triage stay with the agent.
Admins can repair or retire a specific table, note, secret, workflow, app, MCP server, automation or Saved Agent that lives in another member’s private feature — so a broken thing can be fixed without first taking the feature away from its owner. Two limits hold: an admin still cannot browse a private feature (nothing in it appears in their lists, in search, or in Ronja’s context — they have to be handed the item), and an admin cannot create something new inside one. Renaming, deleting or exporting the private feature itself is Admin-only in the same way. See Scopes and sharing.
On by default, and an organization setting can turn it off — the Read-only members can use Ronja’s AI toggle on Users & Access. A read-only member’s conversation is read-and-analyze only: Ronja can query, chart and run Python over the data that member can already see, and the results live in the chat. It cannot create or change a shared table, note, workflow, app or automation, and cannot send email. On stored credentials the line is about the credential itself, not the data behind it: a read-only member never sees a credential’s value and cannot put one into code they wrote, but they can ask Ronja to read — never write — from an external database the organization has connected, with Ronja handling the credential. The same boundary applies when a read-only member asks Ronja from Slack or Teams. Read-only chats spend credits like any other, and the per-role budgets in Control Center cap them — see Govern AI spend.
Having Ronja open an app and report what it looks like — from a chat, from ronja app test in the CLI, or over the API — is open to anyone who can read the app, except User Read-Only. Sending interaction steps along with that render — clicks, typing, waits — requires Admin: a step runs the app’s own code with the same authority anyone opening the app has, so it can start workflows and Saved Agents, upload files and call outside systems, and nothing is mocked and nothing is rolled back. Over the API a token limited to scopes needs the Admin scope for the steps as well — a token scoped only to Data cannot drive an app even when the person holding it is an Admin. What comes back is an observation either way, never a pass or fail.

Notes

Role changes can take a minute or two to apply to a member’s active session.
Some capability differences you see in the product’s built-in Role guide have been corrected here against the actual backend behavior — where the two disagree, this page is authoritative.