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 five 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 workspaces and settings, approves data-app proposals, and can open any member’s explorations for support and governance.

Data Admin — owns the data layer: connects data sources, builds and edits tables, schedules data jobs, and acts as the usual approver for governance requests — handovers, edit drafts, and note and workflow proposals.

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 Data Admin, 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; workspace membership and feature scopes say what they can see. A Data Admin who isn’t in the Finance workspace still won’t see Finance’s workspace-scoped features. Some abilities also depend on workspace settings: in a workspace whose members have been granted admin rights, regular Users can create and edit that workspace’s shared resources.

Where you manage roles

Roles are assigned on the Users & Access page — a matrix of members against workspaces, 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.