Roles and invites
What owners, editors, and viewers may do, and how to invite someone to a project.
Every project has exactly one owner: the person who created it. Everyone else
holds one of two roles, editor or viewer. Roles are ranked, so an owner can
do everything an editor can, and an editor everything a viewer can.
The rank is the whole model. Each server action asks for a minimum role and refuses anything below it, so hiding a button in the UI is never what keeps you out.
What each role may do
| Action | Minimum role |
|---|---|
| Read the story, assets, and variables | viewer |
| See the members roster and pending invites | viewer |
| See the timeline and the branch list | viewer |
| Write scenes, beats, staging, cast, variables | editor |
| Rename the project | editor |
| Upload and delete assets | editor |
| Publish a version | editor |
| Use the co-writer and start an agent run | editor |
| Save a checkpoint | editor |
| Create, merge, and discard branches | editor |
| Invite, remove, and re-role members | owner |
| Restore a checkpoint | owner |
| Hide the "made with Narratomi" badge | owner |
| Delete the project | owner |
A viewer who opens the editor gets a read-only banner at the top ("You have
viewer access to this project. Ask the owner for an editor seat") rather than
fifty separate disabled tooltips. Read-only is enforced on the wire too: the
collab token minted for a viewer carries read and awareness permissions
only, never write, so a viewer's edit is not persisted even if something
client-side lets it through.
Invite someone
Open the Members tab
It is in the right-hand dock of the editor. Everyone sees the roster. The invite form appears only if you are the owner.
Fill in the email and the role
"Invite email" takes one address. "Invite role" is editor or viewer.
Editors can write, viewers can only read.
Press Invite
Narratomi emails a link to that address. The invite shows up under Pending invites as a dimmed row until it is accepted.
The invited person signs in and opens the link. The address has to match: if they are signed in as somebody else, the page tells them which address the invite was sent to instead of silently doing nothing.
Invite links last 14 days. Use the resend icon on a pending row to send the same mail again and reset the clock, or the revoke icon to kill the invite outright.
Editor seats
Editors are billed per account, against the plan of the project's owner. Free plans get zero guest editors, Creator gets one, Team gets as many as the owner has purchased seats for. Viewer invites are never gated.
The count is people, not memberships. If someone is already an editor on another project the owner owns, adding them here costs nothing extra. A pending editor invite counts as a promised seat, so it takes a seat the moment you send it, not when it is accepted.
When the cap is reached the invite comes back with "All N editor seats on this plan are taken. Upgrade to invite more editors." Promoting a viewer to editor runs the same check, for the same reason.
Downgrading a plan does not demote anybody. Existing editors keep writing, and the members panel says so: "Existing editors keep access; inviting more needs an upgrade." Only new editors are blocked.
See Plan limits for the rest of the per-plan numbers.
Removing people, and leaving
Owners change a member's role from the select on their row, and remove them with the X. Neither control appears on the owner's own row: the owner's role cannot be changed and the owner cannot be removed.
If you are not the owner and you want out, go to the project settings page and press "Leave project". You will need a new invite to come back. Owners cannot leave, because the project would have nobody who could administer it. Delete the project instead.
How fast a demotion takes effect
Removing someone from Postgres is instant. Their open editor session is a different question: collab tokens are minted with a lifetime (10 minutes by default) and the collab backend has no revocation API, so an already-minted token stays valid until it expires.
In practice the client re-mints ahead of expiry and the mint endpoint re-checks the role every time, so a demoted or removed person loses write access within roughly the token lifetime. It is not instantaneous. If someone must be cut off this second, that is not a thing roles alone can do for you.