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:

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.

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

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 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
• Organization settings & branding
• Audit logs, email logs & security