Versions, drafts, and approvals

Once a resource is shared, changes to it stop being instant. Ronja stages non-admin edits and new shared resources for review, keeps a version history of what was committed, and gathers the pending work in one admin queue. This page explains the moving parts.

Edit drafts: change without touching live

Editing a shared note, workflow, table, or app as a non-admin never modifies the live version. Instead you get a draft — your own working copy that points at the live original. You can iterate on it as long as you like; nobody else is affected, and it doesn’t appear in the admin Inbox yet.

When you’re happy, you — or Ronja, in chat — Submit for review. The draft’s status flips from Draft (“Still in progress”) to Review requested, and it lands in the admin Inbox. The reviewer sees a diff against the live version — for workflows that includes an AI-written change summary, a metadata delta, and the code diff — and either approves — the draft is committed (published as the new live version) — or rejects it. You can Withdraw your draft at any point.

Admins editing a shared resource skip the queue: their change commits directly.

If someone else changed it while you were editing

Because everyone gets their own draft, two people can edit the same workflow at once. If somebody commits their changes while yours are still in progress, Ronja stops your commit and asks first: Somebody else committed a new version of this workflow since this draft was created. Committing it now replaces their changes. It also shows you which files they changed. Choose Cancel to leave everything as it is, or Overwrite to commit yours anyway and replace theirs.

Nothing is ever lost without you saying so. Your draft is untouched either way, and the version you’d be replacing stays in Version history — so you can look at what changed before you decide, and restore it afterwards if you overwrite something you shouldn’t have. Usually the better move is Cancel, discard your draft, start a fresh one from the updated workflow, and re-apply your change on top.

Approve waits for you

An admin can’t approve a draft you haven’t submitted. Until you Submit for review, the reviewer only sees “In progress” — they can reject or withdraw a stale draft, but never land it on your behalf.

Proposals: brand-new shared resources

Creating something new in a shared feature as a non-admin produces a proposal — the full resource, staged and shown in the Inbox as, say, “proposed as a new shared workflow”. A reviewer opens it, reads the full content (there’s nothing to diff against), and approves or rejects it. Two rules always apply:

• The proposer can never approve their own proposal.
• Notes, workflows, and apps can be approved by an Admin.

Versions and restore

Every commit archives the previous live version into Version history. Restoring an old version never silently overwrites live: for notes, workflows, and derived tables, restore creates a new draft seeded from that version — for a note the toast reads “Draft created from this version — commit to restore” — which then goes through the normal commit path. Two exceptions restore immediately behind a confirmation: a dynamic table’s snapshots, and an app.

For an app, Version history lives on the app’s Details page, under Overview. Each entry shows who published it and when; the newest is marked published because it is what is live right now. View source opens that snapshot’s files read-only on the Source tab, and Restore replaces what is live after a confirmation. Nothing is lost either way — the version you replace stays in the list and can be restored back. If you have an unpublished draft open, publish or discard it before restoring. See Build an app.

Where approvals happen: the Inbox

The admin review queue — the Inbox — sits at the top of the Shared features page. It gathers everything waiting on an admin, with filter pills for Handovers (scope changes), Content (edit drafts, new-resource proposals, and move requests), and Access requests.

The Inbox on the Shared features page — every pending decision in one queue.

Don’t look for it under Approvals

The Approvals page in the admin area is a settings page — the approval policy, the email-trigger ingest prefix, the reporting timezone. The review queue itself lives on the Shared features page.

Requesters track their own side under Account → Requests: pending promotions, moves, proposals, and drafts, each with a Withdraw option, plus a history of past scope-change decisions.

The self-approval policy

On the Approvals settings page, admins can disallow self-approval. When it’s off, the admin who authored a draft or request cannot approve it — a different admin must review. Proposals are stricter still: the proposer can never approve their own, regardless of this setting.