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.

The shipped roles fall into a few groups. The first group covers broad capability tiers and predates the job-function model:

• Admin (bndry-admin) — full access, including job creation, form definition management, tenant settings, and integrations.
• Writer (bndry-writer) — full CRUD on entities, companies, jobs, forms, workspaces, files, notes, and activity logs.
• Reader (bndry-reader) — read-only access to entities, files, forms, workspaces, activity logs, events, and settings.
• Collaborator (bndry-collaborator) — a lightweight role for form submission and workspace collaboration.

The second group is the job-function roles introduced for clubs and other customers who needed access tied to a person's job rather than to a capability tier:

• View only admin (bndry-view-only-admin) — read access to everything for board reporting, audit support, and management oversight. Cannot write or run jobs.
• HR (bndry-hr) — manages employee records and runs most screening checks. Cannot run the onboard job, manage settings or integrations, or perform entity evaluation.
• Investigations (bndry-investigations) — runs every job (including onboard) and contributes to evaluations, but cannot create or modify entity records directly.
• Duty manager (bndry-duty-manager) — opens workspaces, completes forms, and runs form-triggered screening jobs. Cannot view entity details, manage settings, or run the onboard job.

A small number of additional roles cover operational and anonymous access — for example, an ops role for BNDRY-internal support work and anonymous roles used when an external user reaches a workspace or onboarding flow through a magic link without signing in. These are not normally assigned to staff users.

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. They are tracked for a later version of role-based access control built on a fine-grained authorisation engine.

How roles relate

Roles are assigned to users in the identity provider. 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.