Roles

A role in BNDRY is the named bundle of permissions assigned to a user account that determines what they can see and do in the platform. Roles are managed in the identity provider and enforced on every API call by the BNDRY backend. The set of roles BNDRY ships with is deliberately small and aligned to job functions — view-only admin, HR, investigations, duty manager, and the broader reader, writer, admin, and collaborator roles — rather than to fine-grained capabilities. A user is granted one role and can do everything that role permits; no second role is required to fill in gaps.

Why roles exist

BNDRY is used by people doing very different jobs against the same data. A duty manager at a club's front desk needs to open a workspace and complete a payout form. An HR officer needs to manage employee records and run identity checks. An AML analyst needs to run every screening job available, including onboarding. A general manager needs to read everything for board reporting but should not be able to change anything. Without roles, every user would either be over-privileged (a write-everything account that has to be trusted not to break things) or under-privileged (a read-only account that cannot do the job).

Roles also matter for the audit trail. When a sensitive action happens — an entity is created, a risk status changes, a workspace is resolved — the record of who did it is only useful if "who" was acting under a clearly defined set of permissions. Job-function roles make that "who" legible to auditors, customers, and BNDRY itself.

Key properties and sub-types

Every BNDRY role has a small set of properties in common:

• Name — a stable identifier such as bndry-admin or bndry-duty-manager, used in the identity provider and recognised by the backend.
• Standalone — every shipped role is self-sufficient. A single role assignment is enough to sign in and use the parts of BNDRY the role permits.
• Endpoint scope — the role lists every API procedure it can call. The backend interceptor enforces this on every request, and the build fails if any procedure is not assigned to a role.
• Core app endpoints — every role inherits a small shared group that the application shell calls on every page load, so any user with a valid role can at least log in and see the app.

Roles are enforced at the backend; the frontend uses role membership only to decide what to show in the user interface. A user who reaches the UI for a procedure they cannot call will see the backend's permission error rather than a silent success.

The current model controls access at the API procedure level. Finer-grained controls — restricting a role to a specific entity type (HR sees only employees, not patrons), to a specific workspace type, or to a subset of fields on a response — are intentionally out of scope.

How roles relate

Roles are assigned to users in the BNDRY identity broker. A user signing in to BNDRY arrives with their roles attached to the session, and every subsequent API call is checked against them. Adding a new role, or changing what an existing role can do, is a coordinated change between the identity provider, the BNDRY backend, and the frontend; the backend is always the security boundary.

What a role controls intersects with most of the other BNDRY concepts. Roles decide who can create, read, update, and delete entities; who can run jobs (verification, screening, risk rating, onboarding) against them; who can open and operate on workspaces and the forms inside them; and who can administer the tenant. The roles themselves do not define those concepts — they decide who is allowed to act on them.