Roles & permissions

CondoPulse has four roles. The design principle: everything operational is public to the building; everything personal or administrative is staff-only. Residents can see every incident and every uptime number - transparency is the product - but only staff move incidents through their lifecycle, and only admins manage people.

The roles at a glance

Capability	resident	board	manager	admin
View statuses, uptime bars, incidents, timelines	✅	✅	✅	✅
View contacts directory (/directory)	✅	✅	✅	✅
Report incidents (web/mobile, photos, anonymous)	✅	✅	✅	✅
Comment on incidents	✅	✅	✅	✅
Follow incidents, get notifications	✅	✅	✅	✅
Verify fixes (Confirm fixed / Still broken on resolved incidents)	✅	✅	✅	✅
Change incident status (acknowledge / in progress / resolve)	-	✅	✅	✅
See real reporter name on anonymous incidents	-	✅	✅	✅
Triage email-in incidents (assign asset/unit, set severity)	-	✅	✅	✅
Merge duplicate incidents	-	✅	✅	✅
Manage assets and contacts	-	✅	✅	✅
Manage maintenance windows	-	✅	✅	✅
Manage webhooks	-	✅	✅	✅
See resident directory (who lives where)	-	✅	✅	✅
CSV export, board reports, costs, Insights	-	✅	✅	✅
View audit log	-	-	-	✅
Manage user roles	-	-	-	✅

Throughout these docs (and the API reference), “staff” means board/manager/admin.

Role descriptions

resident

The default role - every new account, including Google SSO sign-ups, starts here. Residents see everything public: asset statuses, the full incident list with timelines, uptime history, and the contacts directory. They report incidents (with photos, anonymously if they choose), comment, follow, and - importantly - verify fixes. The Confirm fixed / Still broken step on resolved incidents is deliberately open to every signed-in resident, not just staff, because that’s the accountability loop.

What residents can’t see: other residents’ personal contact details. The resident directory (units, names, contact info) is staff-only.

board / manager

Board members and property managers have the same permissions in CondoPulse - the two labels exist so the audit log and notifications read correctly (“board” for elected members, “manager” for management staff).

Everything residents can do, plus the operational toolkit:

• Acknowledge and resolve incidents, set them in-progress, and post status-changing updates. (Status changes via incident updates are staff-only; resident comments never change status.)
• Triage the email-in queue: assign an asset or unit and a severity to untriaged incidents.
• Merge duplicates - close a dupe into a target incident, carrying its reporter and followers over.
• Manage assets, contacts, and maintenance windows in /admin.
• See through anonymity - anonymous incidents show the real reporter to staff (residents see “Anonymous resident”).
• See the resident directory and the money/health views: incident costs, the Insights ranking, CSV exports, and the board report generator.
• Receive escalation email - SLA breach notifications and the weekly digest go to board+ users.

admin

Everything above, plus user management: changing roles (promoting a new board member, demoting a departed one) and the org-level settings and feature flags under /admin → Organization. The audit log view under /admin → Audit is admin-visible.

How API authentication maps to roles

• Session cookie (web sign-in) - you act as yourself, with your role.
• Mobile bearer key - requests act as the building’s designated “Mobile Reporter” user. It can read public data and create incidents/updates; it is not staff.
• CRON_SECRET / INBOUND_EMAIL_SECRET - machine credentials for the sweep/digest endpoints and inbound email; actions they trigger are audited as the system actor.

Details and examples in the API reference.

Practical guidance

• Keep the admin count low - one or two. Role changes are audited, but fewer hands on user management is simpler governance.
• Give every active board member a board account rather than sharing a login: the audit log records who resolved an incident, and that record is the point of the product.
• Don’t hand out staff roles to get someone notifications - residents already get notified on everything they follow. Staff roles are for people who acknowledge and resolve.
• New Google SSO users arrive as residents. Promote them at /admin (admin-only) after they first sign in.