RBAC & Permissions
A formal `module.resource.action` permission model, tenant-scoped roles, and per-LOB access scoping — composable rather than role-explosion.
Permissions in BPO operations are inherently multi-dimensional: a supervisor on ClientA's English LOB should never see ClientB's data. FrontLine's RBAC enforces that at the policy layer, so building a new role doesn't require duplicating ten existing ones with different scope filters.
Composable permissions, not a labyrinth of overlapping roles
Every permission is a string in the form `<module>.<resource>.<action>` (e.g., `recruiting.requisition.create`). Roles are bundles of permissions. Roles are always tenant-scoped — there is no global super-admin. Per-user role bindings can additionally scope to a specific client or LOB, so the same role assigned twice (once per client) gives different effective access. The `client` role is hard-wired to client-portal endpoints only.
What's covered out of the box
Audit-ready artifacts your reviewers can lean on
- SOC 2 Type II — logical access controls
- ISO/IEC 27001 A.9 Access Control
- Least-privilege defaults across the role catalog
- Quarterly role-review report available for compliance
What security and compliance reviewers actually ask
Can we use our existing IdP groups to drive roles?+
How do you prevent privilege escalation?+
Can a supervisor be scoped to only their LOB?+
Where can we review who has access to what?+
Run this past your security team
We share security overviews, RLS policy DDL, audit-event schemas, and SOC 2 progress on request. Book a 30-minute security review with the founders.