Skip to content

Scopes

A feature’s scope decides who can see it — and everything inside it inherits that audience. Concepts: Scopes and sharing.

Scope Meaning (product wording) Who can reach it
Private “Visible only to the creator.” Only the feature’s creator. Admins cannot browse it, but can edit or delete a specific item inside it when given that item directly — and cannot create new ones there
Organization “Available across the organization.” Access Groups the feature is attached to, plus any access group set to share all features — see below

Scope changes are staged: the current scope stays in effect until an approver accepts. The requester can withdraw any time before that.

Change Approver
Private → Organization An Admin — except on “My Private Feature”, which nobody can approve (below)
Organization → Private (demotion) An Admin
  • Requesting a promotion is open to the feature’s owner — except on their own My Private Feature, below; requesting a demotion is admin-only.
  • If the requester is themselves an eligible approver (and the org allows self-approval), the request executes directly.
  • Approvals are blocked while a pending move request targets the feature, while the change would break a dependency, or when the feature is a My Private Feature.
  • “My Private Feature” is never promotable — by anyone, including an Admin. Each person’s personal home is where everything they build without picking a feature lands, so promoting it would publish all of it at once. The refusal is not a role gate that a bigger role gets past: it sits on the write itself, so every route hits it — feature settings, the Hand over flow, an app’s Share… modal, a direct admin promotion, the API’s promotion-request and promotion-direct, and the agent’s requestScopeChange. A request filed before this rule existed can never be approved; an Admin rejects it.
    • Recovery: create a dedicated feature, move the items into it (Private → Organization moves take an Admin’s approval as usual), and share that feature. A home that was promoted before the rule existed is repaired by demoting it back to Private, which stays allowed.

Resources don’t carry their own scope — they inherit the feature’s:

Resource How scope shows up
Table, Workflow, Note, Automation, App, Saved Agent Visible to whoever can reach the owning feature; chips show “Shared” vs “Personal” where relevant
Secret, MCP server Chip Personal (private feature) or Shared (organization feature); sharing happens by promoting or moving the feature, never per secret
File Not scope-managed — a file doesn’t inherit a feature’s scope. Instead its reach is set by the folder it sits in (admins manage folder access), with your own saves kept private in My Files; admins can read every file
Exploration Not scoped at all — private by default and shared per person or access group with View / Full access modes

Moving is its own approval lane, routed by the source and destination scopes:

Move What happens
Private → your own private feature Executes immediately (no request)
Anything ↔ Organization-scoped feature Requires an Admin’s approval

Your explicitly chosen items (“seeds”) can never be excluded from the move; auto-derived dependencies (“linked”) can be unchecked by you or the approver. Each user can have up to 100 open move requests.

Action Minimum role
Create a private feature User
Request a promotion User (the feature’s owner) — never on “My Private Feature”
Approve into the organization / approve demotions Admin
Attach org features to access groups (the matrix) Admin

Full role detail: the roles capability matrix.