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 chats with Ronja: their own, and any shared with them with Full access — 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)	✓	✓	✓	—
Edit your own policy	✓	✓	✓	✓
Edit the organization policy	✓	✓	—	—
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	✓	✓	✓ ²	—
Create a project & move chats into or out of one	✓	✓	✓	— ²¹
Add or remove a project’s members	✓	✓	◐ ²²	—
Build & edit tables	✓	✓	◐ ³ ²⁵	—
Connect a data source by asking Ronja in a Build mode chat, and query it live	✓	✓	◐ ⁴¹	—
Set up scheduled imports & manage connections on the Connections page ³⁶	✓	✓	—	—
Find a managed database in Search (⌘K) & open its console	✓	✓	✓	✓
Provision, rename & delete a managed database	✓	✓	—	—
Mint & revoke a managed database’s connection logins	✓	✓	—	—
Write to a managed database through a Saved Agent ³⁵	✓	✓	◐ ³⁵	—
Create, refresh & discard a database’s dev copy	✓	✓	—	—
Promote a dev copy’s migrations onto production	✓	✓	—	—
Mirror a managed database into a feature & manage its replication — pause and resume, Sync, Re-snapshot, Disable CDC	✓	✓	—	—
Connect a mailbox & have Ronja read it in chat ¹⁷	✓	✓	—	—
Manage stations — create, change, regenerate a link & disconnect	✓	✓	—	—
Schedule automations in shared features	✓	✓	◐ ⁴ ²⁵	—
Open an automation’s Email trigger to any sender ²⁸	◐ ²⁸	◐ ²⁸	—	—
Read shared skills, secrets, workflows & apps	✓	✓	✓	✓ ⁵
Create & edit shared skills, secrets, workflows & apps ³⁷	✓	✓	◐ ⁶ ²⁴ ²⁵	—
Take your own copy of an app you can open (Make my own)	✓	✓	✓ ²⁶	—
See every member’s private features and My Private Feature, and everything in them — the admin area’s lists and Trash, search (⌘K), pickers and the API	✓	✓ ¹⁸	—	—
Cancel a workflow run on dedicated compute — any run of a workflow you can run, whoever started it ⁴⁰	✓	✓	✓	—
Edit, delete or restore an item in another member’s private feature	✓	✓ ¹⁸	—	—
Share another member’s private feature with the organization — never their My Private Feature	✓	✓ ¹⁸	—	—
Attach any resource in the organization to an app, or reference it from a Saved Agent, automation or workflow — whatever feature it lives in, attached to an access group or not, private or shared	✓	✓ ¹⁸	—	—
Request promotions & propose new shared resources — never on My Private Feature (scopes)	✓	✓	✓ ⁷	—
Connect personal MCP servers	✓	✓	✓	—
Use Ronja from your AI assistant	✓	✓	✓	✓
Choose the AI model & reasoning effort per chat	◐ ⁸	◐ ⁸	◐ ⁸	—
Approve promotions & note / workflow / module / Saved-Agent proposals; commit drafts — nobody can approve a promotion of My Private Feature, Admins included	✓	✓ ⁹	◐ ²⁵	—
Approve app proposals	✓	✓ ¹⁰	◐ ²⁵	—
Drive an app with interaction steps while Ronja renders it ²⁰	✓	✓	—	—
Verify, retire & acknowledge-drift on tables and metrics	✓	✓	—	—
Add, edit, silence & remove health checks on a table	✓	✓	◐ ³ ²⁵	—
Make a health check admin-protected — or silence or remove one that is	✓	✓	—	—
View the member directory	✓	✓	✓	✓
Invite members & assign roles	✓	✓ ¹¹	—	—
Remove people from the organization	✓	✓ ¹¹	—	—
Add themselves to the organization as Super Admin — a member of the Ronja team only ³⁴	—	—	—	—
Manage people properties — create them, give people values, Import from file	✓ ³³	✓ ³³	—	—
Manage organization & access group settings	✓ ²²	✓ ²²	—	—
Change organization settings — on Organization rules, or over the API and the CLI	✓ ²⁷	✓ ²⁷	—	—
View every member’s explorations	✓	✓ ¹²	—	—
See another member’s project and the chats inside it	◐ ²³	◐ ²³	—	—
Create, rename and delete Spaces, and decide who is in them	✓	✓	—	—
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)	✓	✓ ¹³	—	—
Set weekly AI budgets (Control Center → Rules)	✓ ²⁹	✓ ²⁹	—	—
Give someone extra credits for this week, or take them back (Give extra credits this week / Remove extra credits in their panel on People)	✓ ²⁹	✓ ²⁹	—	—
Set the organization’s daily AI safety limit (Control Center → Rules)	✓ ³⁸	✓ ³⁸	—	—
Change the organization’s monthly budget (Control Center → Rules)	✓ ³⁹	✓ ³⁹	—	—
Promote members to Admin or Super Admin	✓	—	—	—
Buy credits	✓ ¹⁴	—	—	—
Rename the organization — on Organization, or over the API	✓	—	—	—
Delete the organization	✓ ¹⁵	—	—	—
Register a login domain (auto-join)	✓ ¹⁶	—	—	—

Footnotes

Any member can attach a file to a conversation. It lands in your own My Files, or follows the chat it was attached in: a chat in a shared feature keeps it where that feature’s members can open it, and a chat in a project puts it in the project’s folder. A User Read-Only member can attach files to their own chats, or to a chat shared with them with Full access, for Ronja to read and analyze. The file stays in their My Files, or follows the chat as above, and they cannot move it, share it or turn it into a table. They cannot upload at all when Read-only AI access is off (footnote 19), and an API token given the User Read-Only role cannot upload: a read-only member uploads as themselves, in Ronja or with their personal access token. Managing the files inside an organization-scoped feature additionally requires Admin, or a maintainer of that feature (footnote 25).
New features are private to their creator (Admins see them too) 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 what defines it (a Derived table’s SQL; a Metric’s recipe, which is what a metric carries instead of SQL), build it to see what came out, and submit it for review. Both are editable from the CLI too, as one .sql or one metrics/*.json file per row. The Admin bar is at commit. Running a draft is not the same as a Build of the live table, which stays 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. Health checks follow the same rule, because writing a check is writing its table: a User can add, edit, silence and remove checks on a table they can already write, and needs Admin on an organization-shared one. Removing one happens only in a Build-mode chat. The one exception is the row below — a check that is admin-protected is Admin-only to create, and Admin-only to silence, downgrade or remove once it exists, whoever can write the table. Wherever this footnote says Admin, a maintainer of the table’s feature counts too, within the limits footnote 25 sets. See Versions, drafts, and approvals.
Any member can create automations in their own private features. Automations in organization-scoped features require Admin, or a maintainer of that feature (footnote 25).
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. Anything inside a private feature belongs to that feature’s owner — theirs to see and to edit, whoever originally wrote it — so an item moved into someone else’s private feature becomes theirs to see and to edit. Automations are the exception: an automation follows the credential that created it, never the feature’s owner. Archiving, trashing and restoring an app follow the feature’s owner too; for skills and secrets they stay with whoever created the item, and a workflow is trashed by the feature’s owner but restored by whoever created it. Permanently deleting is always an Admin.
Users can propose new shared resources for review (an approver decides before they go live); creating or editing a shared resource in place requires Admin, or a maintainer of its feature (footnote 25). For apps and shared workflows a User can go further — over the API and the CLI the whole draft lane up to the commit is open to them; footnote 24 has the app detail. Two things stay with the person who made them: the owner of a shared secret can update its credentials, and press Log in now on it, without an Admin, and the author of a shared app can keep editing it in place — those edits land in a draft an Admin or the feature’s maintainer still reviews before they go live. Archiving, trashing and restoring a shared resource stays with an Admin or a maintainer of its feature (footnote 25); permanently deleting one is always an Admin. A shared module goes the other way: a User can propose a new one, but changing one that is already live is Admin only, or a maintainer of its feature (footnote 25) — there is no draft for a User to open at all, because a module edit reaches every workflow that imports it.
Any member with read access to a shared feature can propose a brand-new shared note, workflow, app, module, or Saved Agent there; an approver reviews it before it goes live. Saved Agent and module proposals are listed in the Inbox but not decided there: both are approved or rejected over the API — by an Admin or a maintainer of its feature.
The per-chat model + effort picker is open to everyone by default; an admin with billing access can deny it for a role or a person (Choose model & effort on the Control Center’s Rules tab). Super Admins always hold it and User Read-Only never does. While the organization is out of credits the picker is hidden for everyone, Super Admins included; the reduced-models step does not hide it and keeps each user’s own pick. See Govern AI spend.
Deleting a shared MCP server requires the Admin role, or maintaining the feature it lives in (footnote 25).
Approving an app proposal, and committing a shared app’s draft so it replaces what everyone sees, both require the Admin role — as do deleting a shared app and restoring one from the trash. A maintainer of the app’s feature can do all four as well (footnote 25). Two things are not the Admin’s: an app you created in your own private feature stays yours to delete, and an app you started and never published is yours too — you can remove it, and recover it yourself under Unpublished apps on the Trash page. Everything up to that bar is open to a User who can read the app; see footnote 24.
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. Changing someone’s role and removing them from the organization follow the same order: an Admin can change the role of, or remove, only someone whose role is below theirs — never another Admin or a Super Admin — and a Super Admin can act on anyone. The one exception is for removal only: any Admin can remove a Ronja staff member, whatever their role. Nobody can demote, remove or delete the organization’s last Super Admin, and an API token holding the role doesn’t count as one. Inviting a member, removing one, and assigning or removing a role are also browser-only: they refuse an API token, the CLI and automations, whatever the role behind them. See Actions the API can’t take.
Admins can view every chat in the organization, including private ones, for support and governance: they can open any member’s exploration, and the Activity page lists every chat with its theme, a short summary, who started it and how it ended. Everyone else can open only explorations shared with them or filed in a project they belong to, or a run of an automation or Saved Agent they can see.
Each destructive admin action requested through chat still requires explicit human approval in the conversation.
From the Billing page, and only from there: every billing change — buying credits, saving a card, top-ups, auto-refill, and opening Manage billing — is browser-only and refuses an API token, the CLI and automations (reading billing and usage stays open). In an organization billed by invoice, a purchase is added to your next invoice, in your plan’s currency, and no card is charged. An organization that pays by card buys with its saved card. See Credits and AI spend and Actions the API can’t take.
Browser-only — it refuses an API token, the CLI and automations, whatever their permissions. 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. See Actions the API can’t take.
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. Registering a domain and editing one are browser-only — they refuse an API token, the CLI and automations, since both widen who can join. Removing a domain narrows it and stays scriptable. See Actions the API can’t take.
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. Connecting a mailbox has no API route at all — it is a sign-in at Google or Microsoft, so it only ever happens in a browser. Disconnecting one, and changing a mailbox’s settings (the Compose recipients list, the Watched label, the Daily send limit), are browser-only in the stricter sense: the endpoints exist and refuse an API token, the CLI and automations. Disconnecting revokes the grant and deletes the credential; clearing the Compose recipients list removes the only bound on where an unattended run may send new mail as your own address, and putting the list back does not reach over mail already sent. See Actions the API can’t take.
Admins see everything in the organization, members’ private features and My Private Feature included: in the admin area’s lists and Trash, pickers, search (⌘K), the API and the CLI, and when they open one. Ronja’s chat and AI assistants connected to Ronja find what a member would, plus the feature you open the chat in and anything you link them to; the admin area, search (⌘K) and the API you call yourself show everything. That keeps an instruction planted in something they read from sending them through colleagues’ private work. In pickers, search and on the feature’s page a colleague’s private feature is shown with their name, for example “Anna Berg’s private feature” or “Q3 forecast (Anna Berg)”. No screen, list or export ever shows a secret’s value. Anyone who may write code that uses a secret can make that code reveal it. 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 — and restore or permanently delete what the member put in the Trash, without the owner being told. An admin can also attach an item in it (unless the item is a table and the feature is in the Trash) to a shared app, or reference it from a Saved Agent, automation or workflow, which makes its contents readable through that resource. Admins can move things into a member’s private feature from an organization feature, but cannot create anything new inside one, and nobody can move something between two people’s private features. Renaming, deleting, exporting or sharing the private feature itself is Admin-only in the same way. When an admin shares it, the owner gets a notification naming the admin and their optional reason, and becomes its maintainer, so they keep full access to it, even while no access group reaches it (footnote 25). A feature in the Trash, or an owner who has left the organization, gets neither. See Scopes and sharing.
On by default, and an organization setting can turn it off — the Read-only AI access toggle on Users & Access. In a read-only member’s conversation Ronja can query, chart and run Python over the data that member can already see, run a Deep analysis, and update Your policy for them; asking her to change the Organization policy is refused. She can also make documents and files for them — PDF, Word, Excel, CSV — which always go to their private My Files, where only they and admins can open them; saving into any other folder is refused. Files the conversation produces along the way (Python outputs, generated images, pictures Ronja renders, files unpacked from a zip) follow the chat: a shared feature’s members can open them in that feature’s chats, a project chat puts them in the project’s folder when the member can save there, and otherwise they stay in the member’s My Files — so in Slack or Teams, or a chat someone shared with them directly, colleagues can’t open them. Nothing they make is visible more widely than the chat’s feature or project; see Files a read-only member makes. The conversation cannot use Build mode, create or change a table, note, workflow, app or automation, move, rename or share a file, or 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 from an external database the organization has connected, with Ronja handling the credential. Ronja only ever reads an external database, and on some engines the connected account is what governs whether writing is possible — so a read-only account is what to connect. A read-only member can attach files, such as a spreadsheet or a report, for Ronja to read and analyze, and the attachment follows the chat like anyone’s: in a project’s chat it lands in the project’s folder, where the project’s members can open it. With the setting off, their uploads are refused too. 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 allocations and weekly budgets on the Control Center’s Rules tab 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.
Granting access to a folder or file is browser-only — it refuses an API token, the CLI and automations, because it expands who can reach your files. Removing a grant narrows access and stays scriptable, as does reading who has one. See Actions the API can’t take.
Most settings can be changed through the API; the parts that expand reach cannot. Adding a member to an access group, attaching a feature to one, and granting an access group access to a feature’s tables are browser-only — they refuse an API token, the CLI and automations. Removing a member, detaching a feature, and every read stay scriptable. Give access and Remove access on several features at once (POST /api/v2/workspace/:id/features/bulk) are browser-only both ways; a script removes access one feature at a time. See Actions the API can’t take.
Browser-only. Permanent deletion refuses an API token, the CLI and automations, whatever their permissions — nothing automated can make an item unrecoverable. Ordinary deletion stays fully scriptable and puts the item in the trash, where it is recoverable for 30 days. See Restore from trash and Actions the API can’t take.
A User Read-Only member can be added to a project and use every chat in it, but cannot create a project, and cannot file a chat into one or take it back out — both are writes into a shared container. Beyond the role, a chat can only be moved by the person who started it — not by a colleague who can work in it, and not by an Admin. Putting a chat into a project — by starting a new one there, moving one of your own in, or dragging it onto the project — additionally needs Full access on that project, so a View member reads what is already there rather than adding to it. Taking your own chat back out only narrows access, so it needs nothing else — it stays possible even after you leave the project.
Anyone with Full access on a project can add or remove its members, and a member can then open every chat in that project — the ones already filed and the ones filed later — at whichever level their share gives them. Full access is therefore a transitive grant: whoever holds it can hand the whole project on to anyone else in the organization, and the Share project dialog says so. Adding a whole access group also requires belonging to that access group, unless you are an Admin. Renaming a project, changing or detaching its folder, and deleting it stay with whoever created the project (and Admins).
Project membership decides this, not a role. An Admin’s own Projects list shows only the projects they created or were added to, and being an Admin does not make them a member of someone else’s project — so the project’s chats stay out of their sidebar and project lists, and its chat list shows them only conversations they could already reach some other way, until they join it — which is recorded like any other membership change. An Admin who opens a project directly can still rename it and manage its members. This is not a stronger privacy boundary than Ronja already has: as footnote 12 says, an Admin can still open any individual exploration by its link for support and governance, and the Activity page lists every chat.
Over the API and the CLI a User can go further with a shared app, the way footnote 3 describes for Derived tables and Metrics. A User who can read a shared app may check it out into their own draft, edit its files, change its name, description and access lists, validate it, restore an earlier version into it, discard it, and submit it for review. From the app’s page or its Details page they can also start that draft with Edit with Ronja, which opens a Build-mode chat on the app that waits for what to change, and, when the app’s page shows Update available, with Update with Ronja, which opens a Build-mode chat that makes the update. Both need Build mode access; read-only members don’t see them. The Admin bar — or a maintainer’s, footnote 25 — is at commit, and at approving a proposal, deleting a shared app, and restoring one from the trash (an app you created in your own private feature, and one you started and never published, stay yours — see footnote 10). Drafts are per-person: a colleague cannot touch yours, but an Admin can, so they can fix one up before approving it. See Versions, drafts, and approvals.
Maintainers. An Admin can put one person — or a whole access group — in charge of a single organization-scoped feature, without giving them the Admin role. A maintainer has full access to that one feature. They see and open everything in it — on the feature’s page, in search, in a chat and over the API — even items their access group is restricted from, and even when no access group of theirs shares the feature; a secret’s value stays hidden, as it does from everyone. Inside it they create and edit its tables, apps, workflows, notes, secrets, automations, Saved Agents (a colleague’s too), MCP servers, codexes and modules; write and clear its tables’ data and look after their health checks; manage its files; archive, delete and restore its items, from the feature’s Trash as well; rename the feature; and decide its reviews — approving or rejecting the proposals and committing or rejecting the drafts colleagues file against it, so that work no longer waits for an Admin. Where a maintainer decides: in the web app, the feature page’s waiting for review chip opens the feature’s Inbox, and Review on an item’s page and the draft banners offer the same controls an Admin gets; over the API or the CLI as well. Saved Agent and module reviews are listed in the Inbox but decided over the API, or for a module change with the CLI. In a chat their edits to the feature’s tables, metrics, workflows, apps and notes go live; no chat tool approves a proposal. Their own edits still follow the organization’s self-approval setting, exactly as an Admin’s do: where it is disallowed, their own edits — in a chat too — go to review. A maintainer’s edit to a Saved Agent always starts a draft, which they then commit, and over the API they edit a shared table through a draft and commit it. A User Read-Only member made a maintainer sees everything in the feature and changes and decides nothing. What a maintainer sees only through the grant they can use only inside that feature: connecting such an item to an app, workflow, note, Saved Agent, derived table or metric in another feature, sharing the feature’s folder through a project, or capturing it into a blueprint is refused with a message naming the item; an Admin shares it with an access group to use it elsewhere. A delete has to stay inside the feature: if removing something would take resources in any other feature with it — even another feature you maintain — Ronja refuses, names those resources, and the delete needs an Admin. The grant reaches that one feature and nothing else — not the features nested under it — and is used only when the maintainer acts themselves: an automation never writes with it. What stays with an Admin: promoting or demoting a feature; moving, deleting, restoring or exporting one; and making anyone a maintainer. Some other things inside the feature stay Admin-only as well: opening one of the feature’s Email-triggered automations to any sender, and everything that counts as widening one — raising or clearing its rate limits, or re-enabling it after a pause (footnote 28); permanently purging an item before its 30 days are up; overriding a column’s personal-data flag; verifying or retiring a table, and making a health check admin-protected or silencing or removing one that is; pushing files into an integration table; and scheduled imports and the Connections page (connecting a source in a chat is footnote 41), managed databases and mailboxes. An Admin grants it from More → Access at the top of the feature — see Grant a maintainer and Scopes and sharing. When a private feature is shared with the organization, its former owner becomes its maintainer in the same step, whoever shared it, so they keep full access to it. An Admin can remove that like any other maintainer.
Copying needs no approval and no Admin — the copy lands in your own private feature, where you are the owner. Two conditions decide whether the button is offered. Every table, metric, Codex, Saved Agent, workflow and secret the app uses is re-checked as you before anything is written, so you cannot end up owning an app wired to something you could not have reached yourself; when one of them is out of reach the button greys out and names what is missing, which is an access request to take to an Admin. And because editing an app happens only in a Build mode conversation, the button also greys out when Build mode is off for your account — a copy you cannot edit is no use. A User Read-Only member does not see the button at all.
The organization’s typed settings: its Currency and Number format, the default AI model and reasoning effort (and the reduced models a spend step switches chats to), the cap on how many Saved Agent runs go at once, the self-approval rule, whether read-only members can use Ronja’s AI, whether Ronja may use web search (Perplexity, a US service; turning it back on needs a person signed in to Ronja), and what Ronja may send by email, the address inbound mail reaches, and whether individual automations may be opened to any sender at all (openEmailTriggersAllowed, footnote 28). An Admin changes them on the Organization rules page, or over the API and the CLI — a token limited to scopes needs the Admin scope as well as an admin behind it. Reading them is open to every role, User Read-Only included: every member already receives these values when the app loads. Billing is not among them — buying credits, cards, top-ups and the billing plan stay Super Admin and browser-only (footnote 14). Every change is recorded with its before and after values.
Admin, and a person — no role on its own is enough. An Email-triggered automation normally runs only for senders on its own allowlist. Opening one to any sender — the Open to any sender switch under Configuration on its detail page — is the one capability on this page that no credential can hold. It needs the Admin role and a request a person actually made: every machine caller is refused outright whatever role it carries — an automation, a workflow, a Saved Agent, the CLI, an API token, and a personal access token bound to your own admin account. That leaves exactly two ways in: the switch on the automation’s page, and asking Ronja in a Build mode chat in the Ronja app — not in Slack or Microsoft Teams — where she stops for your approval first. Three more conditions must also hold — your organization’s Open email triggers setting is on (footnote 27), its Agent email policy is off Anyone, and the automation carries both of its own rate limits. Widening the only bound left on an open automation costs the same as opening it: raising or clearing either rate limit, and re-enabling one after a pause, are refused on the same terms. Clearing a rate limit — putting an automation back on the organization’s default — is done on the automation itself, in the per min and per day boxes under Configuration on its detail page, or over the API and the CLI. Asking Ronja in a chat to clear one no longer works at all: in a chat an empty rate limit reads as leave this setting alone, so she will say the setting was left unchanged rather than clear it. Setting a rate limit to a number in a chat works as before. Closing one needs none of it and stays scriptable, as does muting its refused-sender alert — a safety control you cannot switch off without an Admin present is not a safety control. A maintainer of the feature (footnote 25) does not get this one. Unlike the browser-only actions above, the refusal is a plain 403 with prose, not the human_required code — see Actions the API can’t take and Accepting mail from anyone.
Any Admin sets them — no billing access needed: every Admin can open the Control Center’s People and Rules tabs, which show weekly budgets and the daily AI safety limit only without billing access. A weekly AI budget applies to every role in a chat, Admins and Super Admins included, which is the difference from a billing-period allocation: an Admin is never stopped by a Limited allocation, but an Admin who has used their weekly budget is refused new prompts until Monday 00:00 UTC. Because every Admin can edit the budgets, an Admin can always raise their own. The same goes for Give extra credits, which adds credits to one person’s weekly budget until the next Monday 00:00 UTC. See Set weekly AI budgets.
Every member can read people properties — Ronja uses the properties of the person she is talking to, apps can read the viewer’s, and an API token that can read Structure can list them — but only an Admin changes them, and only in the browser: creating, renaming and deleting a property or value, giving people values, and Import from file refuse an API token, the CLI and automations. See People properties and Actions the API can’t take.
No role grants it. A member of the Ronja team adds themselves — never anyone else — as Super Admin, from Ronja’s own tools and in a browser, and must give a reason. The organization’s own Super Admins and Admins (Ronja staff are left out) each get a notification in Ronja naming them, their previous role and the reason, whatever the notification settings say. An email goes out as well — to the same people until an admin redirects it (to other people, or as a Slack message) or turns it off on Notification routing. They carry a Ronja staff chip on Users & Access. Any Admin can remove them (footnote 11), unless they are the organization’s only Super Admin, which the notification then says; they can add themselves again, and each time the admins are notified again. See Ronja staff in your organization.
A Saved Agent that references a writable database login can write through it, and anyone who can run the Agent can trigger that write. Writing this way needs reach on a write or custom login for the Saved Agent to reference, not the Admin role; the write is made as that login, whoever started the run.
This includes Create SharePoint key on a SharePoint connection Ronja support has approved: it makes a SharePoint key, a secret Workflows use to read your SharePoint files.
Except a SharePoint key: nobody can write or edit its credentials, Admins included. It is made only with Create SharePoint key.
Any Admin sets or removes it — no billing access needed — in the Daily AI safety limit section of the Control Center’s Rules tab, at or below the limit Ronja sets for the organization, and every Admin sees how much of today’s limit is used there and on People. It is browser-only: an API token, the CLI and automations can’t change it, because a script must never lift a safety limit. When the lower of the two limits is reached, AI pauses for everyone, Admins and Super Admins included, until 00:00 UTC. To raise Ronja’s own limit, contact Ronja support. See Daily AI safety limit.
For an organization on a monthly budget, any Admin raises or lowers it — no billing access needed — in the Monthly budget section of the Control Center’s Rules tab. Only Ronja can remove it. It is browser-only: an API token, the CLI and automations can’t change it, because a script must never lift a spending stop. When it is used up, new chats and runs stop for everyone, Admins and Super Admins included, until the next billing period or until the budget is raised. See Monthly budget.
Only a person can cancel — from the run’s page, an automation’s Recent runs, or over the API with their own token; an automation, a workflow or a script cannot. See Cancel a run on dedicated compute.
Ronja connects it for you in the chat: you sign in to the service or enter its credentials, she saves them as a secret, and you can then query the source live. A User can have that secret saved in their own private feature, or in a shared feature they maintain. In any other shared feature Ronja can’t save it there: she saves it in your private feature instead, or an Admin connects the source. It also needs Build mode to be on for you — Build access is on for everyone unless an Admin turns it off for your role or for you on the Control Center’s Rules tab, and it is always off for User Read-Only.

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.