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 two scopes

Scope	Who has access
Private	Only the feature’s creator.
Organization	Access Groups the feature is shared to on the access map below — and, by default, everyone (see the note there).

New features start Private, so you can experiment freely without affecting anyone. When something proves useful, you promote it to Organization, then choose which access groups reach it on the access map.

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 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 back to Private) — an Admin approves.

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 access groups can reach them on the Features × access groups map on the Shared features page — a grid of shared features against access groups with a Full / Partial / None legend and a per-access-group SHARE ALL FEATURES switch. Scope decides how far a feature may reach; the map decides which access groups actually get it.

After promoting, attach the feature to an access group if no access group in your organization has SHARE ALL FEATURES turned on — otherwise the feature stays visible to admins only and members won’t see it. The approval screen flags this for you when it applies.

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