# Members, roles & groups

Access in Votare comes from three layers working together: a **base role** that sets someone's overall level of control, **member groups** that scope which voting, events, and reports they touch, and **scoped role assignments** that grant one specific capability without making someone an admin. This guide explains each layer and how to combine them.

## Base roles

Every member has exactly one base role:

| Role | What they can do |
|------|------------------|
| Owner | Full control, including deleting the organization. Holds owner-only permissions no one else can be granted. |
| Admin | Manage members, manage settings, and use most features. |
| Member | The default role. Participates in the features you enable. |

Most people should stay as **members**. Reserve **admin** for people who genuinely need to manage settings and other members, and grant everything else through scoped assignments (below) so you don't over-provision access.

## Member groups and tags

Member groups are named collections such as **Dev**, **Design**, or **PM**. A single user can belong to several groups at once, and groups aren't just labels — they scope real behavior:

- **Weekly MVP voting** is per group — each group votes among its own members.
- **Events** are scoped to groups — only members of a group can RSVP to or be selected for that group's events.
- **Report visibility** can be limited to specific groups.

Set groups up to mirror how your team actually splits its work. Because voting and events key off group membership, keeping groups accurate is what keeps those features pointed at the right people.

## Scoped role assignments

Scoped role assignments grant a single capability without promoting someone to admin. Each assignment can be given to **an individual user** or to **an entire group** (so, for example, everyone in the PM group can author reports), and unless noted they apply at the organization level.

| Permission | Also known as | Grants | Notes |
|------------|---------------|--------|-------|
| `report:author` | — | Create monthly reports | Assign to your reporting leads or a whole group. |
| `planner:edit` | Resource coordinator | Edit Planner allocations | Without it, members can only view the Planner. |
| `timetracker:view` | — | Use the Time Tracker | Required to record and see time. |
| `events:manage` | Event organizer | Create and manage events without org-wide admin | Can be granted org-wide, or scoped to a single event. |
| `mvp:view-history` | — | View MVP leaderboards and history | Read access to past results. |
| `projects:manage` | Project manager | Run the Projects board org-wide | Edit, move, value and **delete** any project and manage its team (including assigning people during a bulk import), plus the pipeline stages. Does **not** cover hackathon-linked projects or the per-stage "suggester can edit" switch, which stay admin-only. |

### Notes on specific permissions

- **Project manager (`projects:manage`)** — the widest of the scoped roles. It covers every project on the board, not just the ones the person is assigned to, and it includes reconfiguring the pipeline stages themselves. Grant it to whoever owns delivery. Revoking it later removes the role, but not project teams they set up — anyone they assigned stays assigned. Two things are deliberately excluded and still need an org admin: hackathon submissions, and the **Suggester can edit** switch on each stage — that switch decides who may edit and delete a project, so turning it on is an access grant rather than a layout change.

  Everything else about the pipeline is theirs, and some of it has consequences worth knowing before you grant the role:
  - **A stage's type matters.** Projects in a *closed* stage don't count toward your plan's project limit or the forecast — that's how archiving a project frees a slot. A project manager can change a stage's type, which moves every project in it in or out of those counts.
  - **The switch is org-wide; teams are one project at a time.** A project manager can't turn on *Suggester can edit* for a stage, but they can add the person who suggested a project to its team, which gives that one person edit rights on that one project. Bulk imports only assign people who are active members of your organization.
- **Resource coordinator (`planner:edit`)** — this is the difference between someone who can shuffle allocations and someone who can only look. Grant it to the people who own capacity planning.
- **Event organizer (`events:manage`)** — grant it org-wide to a standing events team, or attach it to a single event so a person can run just that one without touching anything else.
- **MVP history (`mvp:view-history`)** — shows aggregate results and leaderboards across weeks. Individual ballots are never exposed: Votare stores only per-candidate tallies, so there is no view of who voted for whom.

## Invitations

Bring people in from **Settings → Members** using either method:

### Email invitations

- Sent to a specific address.
- Expire 30 days after sending.
- Can be resent at any time.
- Track a status of **pending**, **accepted**, or **expired**.

### Invite codes

- Share a code or link for self-service joining.
- Configure an **expiry** and a **maximum number of uses**.

For a step-by-step onboarding walkthrough, see [Getting started as an admin](/docs/admin/getting-started).

## Offboarding: deactivate or remove

When someone leaves, **Settings → Members** gives you two options. Deactivation is the one you almost always want.

### Deactivate (reversible)

Deactivating a member cuts their access to the organization and frees their seat, but keeps everything they did:

- Their 1:1s, time logs, allocations, and reports stay in the organization and stay attributed to them.
- Their own settings — work schedule, presence pattern, home office, timezone, notification preferences — are kept, so reactivating restores the person rather than making you rebuild them.
- They drop out of the members list, people pickers, the Planner grid, and their own organization switcher. Any page they still have open stops working within about a minute.
- The seat is released, so it no longer counts toward your plan.

### The hand-over

Deactivating asks for their **last day**, then shows what they leave behind and lets you deal with it in the same step:

- **People who report to them.** Pick someone to take the reports over, or leave them without a manager for now. Reassignment moves the primary reporting line and carries each person's open 1:1 commitments across, stamped with who they came from — the same hand-over you get from changing a manager by hand. A report is skipped (and reported back to you) if the new manager already reports to them, since that would make a loop.
- **Their remaining schedule.** Allocations that start after the last day are removed; anything already under way ends on that day rather than disappearing, so work that actually happened stays in the record. Queued "your plan changed" emails to them are dropped.

Both are opt-in and both are applied in the same transaction as the deactivation, so if the deactivation is refused — the last active owner, say — nothing moves. Whatever the hand-over did is recorded in the audit log, because reporting lines and cleared allocations can't be reconstructed from the member's row afterwards.

Member groups are **not** cleared, and they don't need to be: a deactivated person stops being offered as an MVP candidate, a roster pick, or a vote target while they're deactivated, and their groups come back with them if you reactivate.

Two things are **not** restored when you reactivate, by design:

- **API keys and calendar feeds** — any MCP API keys, connected apps, and their personal Planner iCal link are revoked at deactivation. If they come back, they mint new ones.
- **Reporting lines** — their own manager and direct-report links are removed. If you handed their reports to someone else, that stays; reactivating does not pull those people back.

A few guardrails apply:

- You can't deactivate yourself, and you can't deactivate the last active owner — promote someone else first.
- Only owners can deactivate another owner.
- A deactivated member can't be changed to a different role. Reactivate them first; they return at the role they had.
- Reactivating takes a seat back, so it fails if the organization is already at its seat limit.
- Deactivated members can't get back in on their own. A leftover invite code or a pending invitation refuses them with a message telling them to ask an owner or admin, and domain auto-join simply doesn't pick them up. Reactivation is the only way back.
- Re-inviting them by email won't work either — you'll be told to reactivate them from the members list instead, which also brings back their old role rather than the invitation's.

Deactivated people are listed in their own **Deactivated** section at the bottom of the members list, where one click reactivates them.

### Remove permanently

Removing deletes the membership outright. Their past work stays in the organization but is no longer attributable to anyone in it, and their settings can't be restored. Only owners are offered this option in the members list. Use it only when you need the record gone — otherwise deactivate.

## What gets audited

Changes to who's in the organization and what they can do are recorded in the audit log, including:

- **Role changes** — when someone's base role is changed.
- **Member deactivations and reactivations** — when someone's access is switched off or restored, and by whom.
- **Member removals** — when someone is permanently removed from the organization.

You can review these entries, with actor and timestamp, in Settings. See [Audit logs, email logs & security](/docs/admin/audit-and-security) for how to filter and interpret the log.

## Putting it together

A common setup looks like this:

1. **Owner** — you (or a small number of trusted people).
2. **Admins** — one or two people who help manage settings and members.
3. **Members** — everyone else, sorted into **Dev / Design / PM** groups.
4. **Scoped grants** — give the PM group `report:author`, give your planning lead `planner:edit` (resource coordinator), and attach `events:manage` to whoever is running the next event.

This keeps admin access tight while still letting the right people do the specific things they need.

## Related

- [Getting started as an admin](/docs/admin/getting-started)
- [Organization settings & branding](/docs/admin/settings-and-branding)
- [Audit logs, email logs & security](/docs/admin/audit-and-security)