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

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.

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