Role
What It Is
This retained record is superseded by the User Account concept, which now owns its facets.
A role gives staff a reusable name for a set of access definitions. Administrator and Read Only are common examples; a customer can also describe a job such as Finance Clerk. Naming the job allows administrators to work with a meaningful grouping rather than select individual permissions for every person.
The definition combines policies and, where used, inline rules. Policies provide reusable lists of allow and deny rules. Permissions identify actions in applications, and supported conditions restrict when those rules apply. A definition establishes what a role can express; a grant establishes who holds it and where it applies.
Rhythm supplies shared built-in definitions through released catalogs. Customers can read those definitions and create their own, including copies that retain their source and version. Built-ins remain under release control, while custom definitions belong to one customer. This separates a common product starting point from local job design.
What It Is Not
A role definition is not a membership, an invitation or a grant. Creating Finance Clerk does not appoint anyone to that job or select a workspace. CRM responsibilities and committee appointments describe other relationships; they provide security access only when an automatic-assignment mechanism translates the relevant facts into grants.
How It Is Used
Security administrators begin with the available built-ins, then create or copy definitions when their organization needs a different combination. They select policies and rules, inspect validation feedback and save the result. Readers can inspect definitions without receiving the authority to edit them.
Editing a role already held by people can affect existing access, so the definition is part of ongoing administration rather than just initial setup. Delegation checks assess widening, and administrator safeguards protect the customer's ability to manage security. Unused custom definitions can be archived while preserving their history. Referenced definitions need their dependencies resolved before archive.
Its Facets
Permissions and catalog. Released services supply the vocabulary of available actions, including tier, sensitivity and staff-only metadata.
Policies. Named rule groups make access reusable across roles. Allow rules name real permissions; deny rules can also use supported patterns.
Built-in policies. Generated application tiers and explicitly declared policies supply Rhythm's shared starting definitions, with sensitive powers separated where the catalog requires it.
Custom definitions. Customer-owned policies and roles support local jobs. Copies preserve their relationship to the original rather than becoming editable versions of the shared built-in.
Built-in roles. Five customer roles and three staff roles group those shared policies for their respective audiences.
Empty-role indication. A grants-nothing label helps administrators recognize a role with no effective allow before assigning it.
Eligibility binding. An optional workspace rule can derive grants for qualifying contacts, with a configured re-check interval.
How It Relates
Custom definitions belong to one customer and cannot borrow another customer's policies. Grants connect roles to accounts or contact subjects at an allowed scope. Staff roles apply to Rhythm HQ, while staff access uses customer-appropriate roles for work inside a workspace. The catalog links those definitions to the operations applications actually expose.
What It Could Become
The product should finish the editor support for automatic assignments and settle their subject model before accepting that milestone. Definition changes also need a clear explanation of cached authorization behavior. Release-controlled built-ins and customer customization should remain distinguishable as the catalog grows, so administrators understand which changes they own and which arrive with the product.