Propose and review changes

Who can do this

Any member with the User role can propose changes. Approving a new note, workflow, or app proposal needs an Admin. Committing an edit draft (note, workflow, or table) needs an Admin. Nobody can approve their own proposal.

Changes to shared features by non-admins are staged, never direct. They come in two shapes:

• A proposal is a brand-new resource waiting to become shared — a note, a workflow, or an app. Its Inbox row reads “proposed as a new shared workflow”.
• An edit draft is your private copy of an existing shared resource. The live version is untouched until an admin commits your draft.

See Versions, drafts, and approvals for the full model.

As the requester

1. Make the change in chat. In a shared feature, Ronja files a non-admin’s new resources as proposals and their edits as drafts automatically. (Admins’ changes go live once they approve Ronja’s action in chat.)
2. Submit the draft when it’s ready: click Submit for review on the resource’s draft banner (workflows and apps), or ask Ronja to submit it (notes). The chip flips from Draft to Review requested.
3. Track everything under Account → Requests — your proposed notes, workflows, and apps, your open drafts, plus a Recent promotions history of settled scope-change requests.
4. Click Withdraw on any pending item you’ve changed your mind about.

Admins don’t see your draft at all until you submit it — and their Approve button won’t appear until you do.

As the reviewer

1. Open the Shared features page (/features).
2. Find the Inbox at the top of the page; narrow it with the Content filter pill to see proposals and drafts.

The Inbox: every proposal, draft, handover, and move waiting on a decision.

3. Click Review on a draft or handover row; click a proposal row itself to open the full review (or use its inline Approve / Reject).
4. Check the contents. Proposals show the full resource (“Review proposal”); drafts show a diff against the live version — workflow drafts add an AI-written Change summary, a metadata diff, an output preview, the code diff, and — when the workflow files its outputs into folders — an Access changes section listing the folders it will be allowed to write to. Table drafts show the SQL diff plus, when they changed, an Input tables section (which tables the draft reads from — a draft can repoint a table’s data source without the SQL changing at all) and a Details section for the table’s name and description.
5. Click Approve to commit — the change goes live and the previous version lands in version history — or Reject. Approving a workflow that files its outputs into folders also grants that folder access; approval is refused if the proposer doesn’t have access to a declared folder.

Caution

Approving publishes to everyone the feature is shared with, immediately. On table drafts, watch for the banner “Live has changed since this draft was created” — approving overwrites changes that landed after the draft forked.

Note

The Inbox is on the Shared features page — not the Approvals page, which holds approval-policy settings. See Versions, drafts, and approvals for that distinction and the self-approval policy.

One row you decide somewhere else

The Inbox also carries RUN APPROVAL rows: “{workflow} run is waiting for a decision”, with how long is left and how many approvers were asked. These are workflow runs that stopped part-way through for a human decision — not proposals or drafts, and there is no inline Approve / Reject on the row.

Click the row and it opens the run page, where the decision is made on a card above the run’s activity: the question, the details behind it, an optional comment, and Approve or Reject. See A run that is awaiting approval. The row is here so an admin sees a run nobody has answered; the named approvers are emailed directly.