Share and promote

Who can do this

Any member with the User role can request a promotion for a feature they own. An organization target needs an Admin to approve. Demotions from organization scope back to private always need an Admin, and can only be requested by an Admin. None of this applies to My Private Feature, which nobody can share — see below.

If what you actually want is a version of somebody’s App for yourself rather than for the organization, you do not need any of this: click Make my own on the App’s page and you get an independent copy in your own private feature, no approval involved — see Make your own copy.

Every feature has a scope — Private or Organization — that controls who can see it. Sharing a feature means requesting a scope change, called a handover. Unless you are an Admin who can approve the change yourself, it is staged until an admin approves it, and the current scope stays in effect until then. See Scopes and sharing for the model, and the self-approval policy for when an admin has to hand their own change to someone else.

One feature is never shareable: My Private Feature, your own, where everything you create without choosing a feature lands. Sharing it would hand the organization every one of those things at once, so Ronja refuses it and offers no Share button there. To share something sitting in it, create a feature and move that thing into it.

Request a promotion

1. Open the feature and click Share at the top of the feature page. (Or open Settings → Privacy and click Request promotion.)

2. Confirm the target in the Share feature modal:

   • Organization — “Available to every access group via current data-access rules.”

3. Wait for the dependency preview. “No dependency conflicts — this scope change is safe to request.” means you’re clear; amber warnings list reasons an approving admin might reject.

   The feature’s name also has to be free among the organization’s features — a private Sales can’t be promoted while a shared Sales exists. That’s checked when the promotion is applied, not when you request it, so a clash surfaces as a refused approval naming the feature that has the name. Rename yours and request it again.

4. Click Request scope change.

Promote the feature to Organization; unless you are an Admin who can approve it yourself, the request is staged until an admin does.

If you’re eligible to approve it yourself, the button reads a direct verb instead — Promote to organization — and applies immediately. The guided Hand over dialog is the other route to the same scope change, in numbered steps (what changes for you, where it should go, who must accept) plus a Note for the approver (optional) field — but it always files the staged request for an admin to approve, even when you could have approved it yourself. Use Share if you want the direct verb.

While it’s pending

• The feature shows an amber Share pending pill; Settings shows the pending target next to a Withdraw button.
• Track it under Account → Requests (“Feature promotions”, with an “awaiting review” chip).
• You can withdraw the request any time until an admin accepts it.

Who approves — and where

Approvers find the request on the feature’s own page, where Review sits next to the Share pending pill, and in the Inbox at the top of the Shared features page (/features), as a HANDOVER row. The notification an approver gets for the request opens the feature’s page. Either Review opens the scope-change review: the current → requested transition, a “What approving means” summary, a dependency re-check, and an optional reason for the audit log — then Approve or Reject. See Propose and review changes for the reviewer’s side in full, and the scopes reference for the who-approves-what table.

Caution

Approving is a real access change. Promoting to Organization makes the feature reachable across the organization (every access group that shares all features, plus any you attach it to); demoting back to Private removes access from everyone but the creator immediately.

Only an Admin can request a demotion, but the two routes to one do not behave the same way:

• Request demotion (feature Settings → Privacy) applies immediately, because the Admin asking is also an Admin who can approve. If your organization disallows self-approval it is staged instead, and a different Admin approves it.
• Hand back to creator (from the feature lists) always files the staged request, even for an Admin who could have approved it. Access does not change until an Admin accepts it.

Sharing one resource instead of a whole feature

Promotion shares the entire bundle — when you share an app from its page (Share…), the dialog warns “N other resources will share this scope.” If only one item should be shared, move that resource into an already-shared feature instead.