# 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. |
| `mvp:view-audit-trail` | — | See which voter picked which candidate | **Owner only.** Cannot be granted to anyone else. |

### Notes on specific permissions

- **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 audit trail (`mvp:view-audit-trail`)** — deliberately restricted to the owner. The ordinary MVP history permission shows results and leaderboards; only the audit trail reveals who voted for whom, and that stays with the owner. See [Audit logs, email logs & security](/docs/admin/audit-and-security).

## 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).

## 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 removals** — when someone is 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)