Users, groups & permissions
PeoplePit’s access model has two layers: a simple role per user (Admin / Editor / Viewer) as the baseline, and fine-grained permissions — per type, per field, even per record — layered on top through groups. The result: a treasurer sees payments but not health notes, a coach sees only their own team, and a member portal user sees only themselves.
Users and roles
Section titled “Users and roles”Manage users in Admin → Users — add a person with name, email and a role:
| Role | Can do |
|---|---|
| Viewer | See and search records, run reports and dashboards. No changes. |
| Editor | Everything a Viewer can, plus create, edit, import and delete records. |
| Admin | Everything, including all configuration — types, fields, forms, workflows, users, billing. |
Roles are the ceiling: fine-grained permissions can restrict below a user’s role, never grant above it. Administrators are always exempt. Deactivate a user to block sign-in without losing their history, and note that unlimited users are included on every plan — see Billing & plans.
Sign-in options
Section titled “Sign-in options”Besides email + password, users can sign in with Google — the button appears on your workspace’s login page once configured, and matches accounts by email. Microsoft sign-in is available the same way. A user who signs in with Google needs no password at all.
Groups
Section titled “Groups”Admin → Groups organizes users into named groups — Coaches, Treasury, Event staff. Groups are used everywhere a set of people is needed: permissions (below), report sharing, notification recipients, assistant access.
Per-type and per-field permissions
Section titled “Per-type and per-field permissions”Each group carries a permission scheme — for any record type, and any field of it, choose:
- Hidden — it doesn’t exist for these users: not in the menu, not in search, not in reports.
- Read — visible but never editable.
- Write — full access (within the user’s role).
Field rules cap what the type allows: hide the salary field from everyone but Treasury while the rest of the record stays editable. A user in several groups gets the most access any of them grants — but never more than their role.
Record-level rules
Section titled “Record-level rules”Type access can be narrowed to specific records:
- “Only records matching a filter…” — any condition, built with the standard filter editor: records where team = the user’s team, records related to the user, records the user created (
Created by = me). - “Their own record” — the shortcut for self-service: each user sees exactly the record linked to their account.
Rules can combine field values, relationships and ”= me” anchors — so “coaches see people who attended their events” is one configured filter, not code. These rules follow the user everywhere: lists, search, reports, dashboards all show only their slice.
Deny-by-default groups
Section titled “Deny-by-default groups”Normally, types without a rule fall back to the user’s role. A group can instead set its default access to Hidden — then its members see only what the group explicitly grants. Perfect for external collaborators or portal-like accounts: start from nothing, grant three types, done.
Checking your setup
Section titled “Checking your setup”The fastest verification is to sign in as a test user in the group and look around — the menu, lists, records and reports all reflect effective permissions immediately. Remember the API enforces everything server-side: hiding is real, not cosmetic.