Scopes and sharing

Everything you build in Ronja lives inside a feature, and every feature carries a scope — the setting that decides who can see and use it. Sharing in Ronja means changing a feature’s scope; the resources inside follow along.

The three scopes

Scope	Who has access
Private	Only the feature’s creator.
Workspace	Members of a single workspace.
Organization	Every workspace in the organization (as granted on the access map below).

New features start Private, so you can experiment freely without affecting anyone. When something proves useful, you promote it.

Scope changes are requests, not switches

Widening or narrowing a scope is called a handover: you request the change, and it stays staged until an admin approves it. The current scope remains in effect the whole time — nobody gains or loses access until the approval lands.

There are two entry points:

• Feature settings — the Privacy section offers Request promotion (move up) and, for Data Admins, Request demotion (move down).
• Hand over — a guided flow from the feature page that walks through what changes for you, where the feature should go, and who must accept, with room for a note to the approver.

Requesting a handover: pick where the feature goes and see who must accept.

While a request is pending, the feature shows a Share pending (or Scope change pending) pill, and you can Withdraw the request any time before it’s accepted. Track your open requests under the Requests tab on your account page.

Dependency safety

Before you send a request, Ronja checks the dependency graph — for example, an organization-shared workflow that reads a table in a private feature would break. Conflicts are shown up front as warnings, and an approval that would actually break a dependency is rejected.

Who approves what

• Promote to Organization (or demote out of it) — a Data Admin approves.
• Promote from Private to a Workspace — a workspace admin of the target workspace, or a Data Admin.
• Demote to Private — a Data Admin.

A workspace admin here means a member of a workspace whose members have been granted admin rights. Reviews happen in the admin Inbox on the Shared features page. If you are yourself an eligible approver, the request form turns into a direct action — the button reads Promote to organization instead of “Request scope change” — and executes immediately.

Sharing one resource without sharing everything

Promoting a feature shares everything in it. To share just one thing, you have two options:

• Move it to a feature that’s already shared. Moves bundle dependencies automatically — your chosen items are “seeds”, and “linked” items ride along — and may themselves need admin approval, depending on the scopes involved.
• On a data app, the Share… button offers both paths side by side — promote the whole feature or move just the app — and shows what else would be affected before you commit to anything.

See Share and promote for the step-by-step, and Organize features for moves.

After sharing: the access map

Once features are shared, admins control which workspaces can reach them on the Features × workspaces map on the Shared features page — a grid of shared features against workspaces with a Full / Partial / None legend and a per-workspace SHARE ALL FEATURES switch. Scope decides how far a feature may reach; the map decides which workspaces actually get it.

Need the exact approver for every scope change, or the per-resource scope behavior at a glance? See the scopes reference.