Members and roles

Inviting people, the two team roles, company administration, and exactly what happens when someone is removed.

Available Updated 2026-09-23

The two roles

A team member is either an admin or a member.

MemberAdmin
Read the team’s issues and projects (Vault access is per space)YesYes
Create and edit issues, projects, commentsYesYes
Create and edit labels, saved viewsYesYes
Approve an IntentYesYes
Add an existing company member to the teamNoYes
Remove people from the teamNoYes
Change a member’s roleNoYes
Rename the team, edit board columnsNoYes

Roles are per team. Being an admin of one team grants nothing in another.

Company administration is separate: company admins create teams, invite new people by email and manage company membership. Renaming a team, changing its key or administering its roster requires admin membership of that team; company-admin status alone does not grant it. A company admin can remove someone from the company entirely. That is a stronger action than removing them from a team — see below.

Vault spaces have their own roles — viewer, editor, admin — layered on top of team membership.

Inviting someone

Adding an existing company member to a team: a team admin uses the team’s roster under Settings → Teams to add them and choose their team role.

Inviting a new person by email: a company admin uses Settings → Members and chooses the initial teams and roles. The whole Members tab is company-admin-only. An email already in the company is rejected by the invitation path; use the team roster instead.

Pending invitations can be revised or revoked. Re-requesting the same pending invitation avoids sending a duplicate. Once claimed, changes to the person’s team role use the roster controls rather than editing the old invitation. The invitee must sign in with the invited email address to claim the grant.

What happens when a grant arrives

You have been added to a new team. What you see depends on where you are:

  • A signed-in session receives a membership-change signal and refreshes its permitted scope. The current transition can reload the workspace; pending changes can delay that refresh.
  • If the team is still missing, reconnect and reload to request current membership. A failed membership request is not proof that access was removed.

If a newly granted team does not appear, reload before reporting it. If it still does not appear, tell us — that is a real bug.

What happens when access is removed

This is the part worth reading carefully, because a local-first product cannot honestly claim what a server-rendered one can.

Removed from a team. Server-side authorisation is re-derived from durable membership, so the removed client stops receiving that team’s future events and new requests for that team’s data fail. The client attempts to purge the team’s rows and replay position when it reconciles. Cleanup can be delayed or fail; revocation is not a guarantee that previously delivered data has been erased.

Removed from the company. The stronger case. The client halts its runtime and attempts to wipe the entire local replica and underlying storage, as described in Companies and teams.

What revocation cannot do

Removal stops future access. It cannot reach into a machine that is offline, or into a copy someone took, and erase what was already delivered. A client that is powered off at the moment of revocation holds what it held until it next connects.

We state this rather than implying otherwise, because the honest version of “we revoked their access” for any local-first product is “we stopped delivering to them and cleared what we could reach”. If your threat model needs guaranteed erasure on a device you do not control, no product of this shape can give you that.

Something here wrong, missing or out of date? Tell us at support@orneos.com — corrections to these pages are welcome and we would rather hear it than have you work around it.