Roles and permissions

Every member of your organization holds one role (assigned when they’re invited), and the role decides what they can do everywhere in Ronja. The in-product Role guide states the philosophy in one line: “Pick the role that matches what someone actually needs — you can change it later.”

The four roles

Super Admin — the organization owner, assigned automatically to whoever creates the organization. Has every permission, and is alone in a few of them: promoting members to Admin or Super Admin, buying credits, registering a login domain, and deleting the organization.

Admin — runs the organization day to day: invites members and assigns roles, manages access groups and settings, and owns the data layer — connects data sources, builds and edits tables, schedules data jobs, and acts as the approver for governance requests (handovers, edit drafts, and note, workflow, and data-app proposals). An Admin can also open any member’s explorations for support and governance.

User — everyday use: runs explorations, asks Ronja questions, creates features (private until shared), and proposes changes to shared resources through drafts and proposals.

User Read-Only — view-only access, ideal for stakeholders: browses shared content and the member directory, but can’t run explorations or change anything.

The exact capability × role matrix — every action, verified against the product — lives in the roles matrix reference.

Rules worth knowing

• Invited members start as User Read-Only, the least-privileged role. Assign the real role right after inviting — you don’t need to wait for them to accept.
• You can only hand out roles below your own (Super Admins are the exception — they can hand out any role, including Super Admin). An Admin can assign User or User Read-Only — but only a Super Admin can make someone an Admin or Super Admin.
• You can’t demote yourself into a locked-out organization. Ronja refuses a self-demotion when you’re the only member at your level or above — promote someone else first, then change your own role.
• “No role” is a real state. A member (or API token) without a role fails every permission check until one is assigned.

Roles are only half the picture

A role says what someone may do; access group membership and feature scopes say what they can see. An Admin who isn’t in the Finance access group still won’t see a feature shared only to Finance (one attached to that access group, when the default access group isn’t set to share all features).

Where you manage roles

Roles are assigned on the Users & Access page — a matrix of members against access groups, with a role pill on each member’s row. The Role guide button there opens the full “What each role can do” matrix inside the product, so you can compare roles before picking one.

The Role guide on the Users & Access page — the same matrix the docs reference is built from.

For the step-by-step on inviting people and changing roles, see Manage users and roles.