On this page
A brokerage is rarely one flat team. There’s usually a split between account handlers, claims specialists, compliance, and management — each of whom should see different slices of the same client records. NodaBroker’s permissions model is built around that reality rather than a single admin/user toggle.
Module-level access, four levels deep
Every module — Clients, Policies, Claims, Quotes, Reports, and the rest — has its own access level, set independently:
- None — the module doesn’t appear at all
- View — read-only
- Edit — create and update, no deleting
- Full — everything, including delete
These levels are set per team by default, with per-user overrides sitting above the team default where an individual needs more or less access than their team.
Team isolation, with an escape hatch
Teams are fully isolated from each other’s data by default: a claims handler on Team A can’t see Team B’s clients. For brokerages that do want shared visibility — say, a small shop where everyone works every file — cross-team visibility can be switched on explicitly, module by module, rather than being all-or-nothing.
Superuser flags are a separate axis entirely
Module permissions answer “can this person touch Policies.” They don’t answer “can this person backdate a policy start date” or “can this person override a payment that’s already been reconciled.” Those live in a second layer: 25+ superuser capability flags across 8 categories, each gated by an explicit admin grant.
Typical superuser-only actions:
- Backdating dates on records
- Overriding policy statuses outside the normal lifecycle
- Managing payments directly
- Reading the audit log
Every one of these is logged. The audit log itself is tamper-evident — every action is recorded with the acting user and a timestamp, and it’s one of the things gated behind its own superuser flag to view.
Why this split matters for compliance
Sanctions and financial-crime screening (UK OFSI sanctions, HMRC avoidance scheme checks) runs automatically in the background, but acting on a flagged match — overriding it, clearing it — is a superuser action with its own audit trail. The permission model and the compliance workflow are the same system, not two bolted-together features.