Inviting people & granting access

Getting someone working in REEZN takes two separate steps: invite them to the org with a role, then grant them access to the projects they’ll work in via a team. The first decides what they can do; the second decides where they can do it.

Both are admin-only and both live in Org settings: invites under the Members tab, access under the Teams tab. They are deliberately distinct, since a role on its own grants access to no projects at all, so inviting a person and giving them somewhere to work are two moves, not one.

Inviting someone to the org

You invite by email and pick the role they’ll hold. There are no accounts for you to provision; the person brings their own identity and claims the invite the first time they sign in.

1. Open Org settings → Members.
2. Type the person’s email address in the invite row and choose a role from the dropdown: Org admin, Tech reviewer, Feature author, or Observer. (It defaults to Feature author.)
3. Click Invite. A pending invite is created for that email, and a row appears in the members table marked “Invite pending” with the role you chose.

Pending until claimed

An invite sits in a pending state from the moment you send it until the invited person signs in. It is tied to the email address you entered, not to any account that exists yet, so you can invite people who have never used REEZN before.

The first time someone signs in (or signs up) with an email that has a pending invite, REEZN claims it automatically: it creates their member record in the org with the role you assigned, links their account to the org, and clears the pending invite. There is no acceptance link or confirmation step; signing in with the invited address is what joins them.

Managing members & invites

The Members tab lists everyone in the org, active members and pending invites together. From there an admin can adjust roles and remove access:

Change a role

Set any member’s role to one of the four from the dropdown on their row. The change takes effect on their next read or write. You can’t change your own role from here, a safeguard against an admin accidentally locking themselves out.

Remove a member

Remove someone from the org with the × on their row. It revokes their role and access entirely. You can’t remove yourself.

Revoke a pending invite

Cancel an invite that hasn’t been claimed yet with the × on its “Invite pending” row. The invite disappears and that email can no longer claim a place in the org.

Granting project access with teams

A new member can sign in, but until a team grants them access they see no projects at all; only admins see every project by default. Access flows through teams, and it cascades down the hierarchy in one move: give a team a project and its members can see that project, every service in it, and every feature, analysis, and canvas within.

1. Open Org settings → Teams and choose New team (or Manage on an existing one).
2. Give the team a name.
3. Check the members who belong on it.
4. Check the projects the team should be able to reach.
5. Save. Everyone on the team can now see those projects; what they can do there is still governed by their role.

Enforced server-side

Both dimensions are real boundaries, not just hidden UI. A member’s role lives on their record in the org and is checked on every write; project access is checked against each project’s own access list, which REEZN keeps in sync from your teams automatically. Even a direct request that slipped past the interface would be refused.