Roles and permissions
Who can do what, and where the boundaries actually are.
One level, many actions
Everything is decided inside a project. Project permissions are granular — a read, write and delete permission for each record type, plus publishing, backups, the archive, the dashboard, relations, AI use, editing the project itself, and inviting or removing people.
That is why a copyeditor can be given write access to chapters and nothing else, and why a worldbuilder can be given every record type but no ability to publish.
Roles
A role is a named bundle of permissions, edited in a matrix per project. Roles can be imported from another project, which is how a studio keeps them consistent without rebuilding them each time.
How access is decided
Access is checked on the server for every request, and it fails closed: no role, no membership or no context all mean no. A role is granted in one project and means nothing in another — every project is decided on its own.
Inviting
You invite by email address, and the person must already have an account. Up to five addresses a request and a few requests an hour; the limits exist because an invitation sends mail from us on your behalf.
An invitation is a notification the person accepts or declines. Nothing is shared until they accept.
What a contributor should know
Everything in a project belongs to whoever created the project, including work contributed by people invited into it. Being removed, leaving, or closing your account leaves your contributions with the project.
Tell people before they start rather than after — it is in the invitation, and it is section 3 of the terms.
Removing somebody
Removing a member ends their access immediately and leaves everything they wrote. Changing their role takes effect on their next request rather than requiring them to sign out.