Authorization Beyond Broad Roles

Early in this platform, authorization was modelled the way most systems start: a small set of broad roles — something like super admin, organization-level user, and agent — each granting a fixed set of permissions. It’s a reasonable starting point, and it establishes the outer boundary of what someone can access.

It doesn’t stay sufficient for long. Two users with the same broad role often need different access depending on context: their organization’s relationship to a specific record, whether they’re assigned to it, what they’re responsible for, and the specific action they’re attempting. Two collaborators on the same record don’t automatically need identical permissions just because they share a role.

The adjustment was to treat the broad role as a boundary, not the full answer, and layer contextual checks on top of it — organization, relationship, assignment, responsibility, and action — before a request is authorized.

The other distinction that mattered here: authorization and auditability are not the same concern, even though they’re easy to conflate. Authorization decides what someone is allowed to do right now. Auditability is the record of what actually happened afterward. Keeping them separate made each one easier to reason about — and easier to change — independently of the other.

This model is still being implemented, and parts of it may change as real usage tests it.