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

Admin → Users has two tabs: Users (the list — + Add user opens a small creation popup) and Authentication (self-registration, the password policy, single sign-on, and automatic sign-out). 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

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.

Everyone also has a “Forgot password?” link on the login page: it emails a single-use reset link (valid 30 minutes) so people recover access without an administrator.

Password policy

Admin → Users → Authentication → Password policy sets complexity rules for every password created in your workspace — minimum length, and whether an uppercase letter, a lowercase letter, a number, or a special character is required. The policy applies when users change their own password, when admins create or reset accounts, when someone self-registers, and on password resets.

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

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.

Creating records is its own switch. Each type row also has a Can create toggle, independent of read/write — a group may edit records it can see but not add new ones, or vice versa. Unlike the access levels, an explicit “no create” rule applies to administrators too: it’s a guardrail, not a lock-out risk, and it’s how you keep hand-made records out of a type that’s fed only by a sync (say, emails imported from a mailbox) — the + New button disappears and the API refuses, while imports and sync jobs keep working. Any admin can lift the rule again in the group editor.

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

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

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.