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 data 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.

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 data 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. The one exception is a dynamic table’s snapshots, which restore immediately behind a confirmation.

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.