> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Members & roles

> Invite people at the organization level, give them a default role, and override it per business unit where needed.

People join Orriven at the **organization** level and get a default role there. Inside each
business unit that role can be overridden — tightened or raised — without touching what the
person can do anywhere else.

## Inviting members

1. Open **Members** in the organization section of the console.
2. Choose **Invite**, enter the person's email address, and pick their organization role.
3. The invitation appears under **Pending invitations** until it is accepted.

The Members page lists everyone in the organization and their default roles.

## The roles

The same role names are used at both levels:

| Role              | Meant for                                                           |
| ----------------- | ------------------------------------------------------------------- |
| **Owner**         | The account owner. Full control, including billing-level decisions. |
| **Admin**         | Runs the organization: business units, members, settings.           |
| **Planner**       | Builds and runs events: ticket types, agenda, emails, attendees.    |
| **On-site staff** | Day-of-event work: check-in style tasks, attendee lookups.          |
| **Viewer**        | Read-only. Can see, cannot change.                                  |

A person's **organization role** is their default everywhere; a **business unit role** applies
inside one unit only.

## How a person's role resolves in a business unit

When someone opens a business unit, their effective role is decided in this order:

1. **Organization owners and admins always have access**, with that role. This is the escape
   hatch — an organization can never be locked out of its own business unit.
2. **An explicit role granted in that business unit** wins next. On the unit's **Members** page,
   the "Role here" column shows it; anything not overridden shows as *Inherited*.
3. **Otherwise the organization role is inherited** — unless the business unit is **restricted**,
   in which case there is no fallback and the person has no access at all.

## Setting per-unit roles

Open the business unit, then its **Members** page. Each row shows the person's organization role
and their role here. Pick a different role to override; choose **Reset to organization role** to
remove the override and go back to inheriting.

## What this means when setting up a team

A few worked examples for an admin:

* **Most companies need only organization roles.** Give planners the Planner role at the
  organization and let every business unit inherit it. Overrides are for exceptions, not the
  norm.
* **Contractor for one project:** invite them as organization **Viewer**, then grant **Planner**
  inside the one business unit they work in. Everywhere else they can only look.
* **Confidential unit:** mark the business unit **restricted** in its settings, then explicitly
  grant a role to each person who should be inside. Everyone else — whatever their organization
  role — cannot see the unit exists. Organization owners and admins still can.
* **Demote locally:** a broadly-trusted Planner who should only observe one sensitive unit can be
  overridden to **Viewer** there, keeping Planner everywhere else.

## Rules to know

* **No access looks like "not found", not "no permission".** A member without access to a
  restricted unit does not see it listed and gets a not-found page on its URLs. This is
  deliberate: the unit's existence is itself confidential.
* **An override is one unit only.** Granting Planner in one business unit says nothing about any
  other unit.
* **You cannot restrict an owner or admin out.** Restricted mode removes the organization-role
  fallback for regular members; owners and admins always retain access by design.
* **Absence of an override means "inherit".** Resetting a role is not a removal from the unit —
  the person keeps whatever their organization role (and the unit's access mode) gives them.
* Membership of the organization is managed on the organization **Members** page; business unit
  pages only decide *roles*, never who is in the company.

<Tip>
  Every role change — invitations, overrides, restriction toggles — is recorded in the
  [audit log](/en/organization/audit-logs), so you can always answer "who gave this person
  access, and when".
</Tip>