# 2. Roles: Use Cases

**Use Case #1: Delegating Support vs. Administrative Tasks**

Create two Roles—“Support Agent” with permissions limited to viewing and updating Requests and Actions, and “System Administrator” with full permissions across Projects, Settings, and Users. Assign Support Agents to day-to-day ticket handling without risking data-model or configuration changes, while Administrators maintain overall system health.

**Use Case #2: Segregating Financial Controls**

Define a “Finance Manager” Role that can view and export Transactions, manage Accounts, and adjust Company Fees but cannot modify client personal data or system Settings. Meanwhile, assign a “Compliance Auditor” Role read-only access to Transactions, Logs, and Agreements. This separation of duties ensures that financial workflows remain secure and auditable.

**Use Case #3: Enabling Analytics Access**

Create a “System Analyst” Role with **view all** permissions on Projects, Desks, Clients, and sub-modules (Actions, Requests) but **manage own** on none. Analysts can generate cross-project reports and dashboards without altering any records, preserving data integrity while granting broad visibility.

**Use Case #4: Scoped Project Administration**

For regional teams, define “Project Admin – EU” and “Project Admin – US” Roles that grant full CRUD and manage-all permissions—but only on their respective Projects and Desks. This lets local managers configure workflows and users within their region without touching other areas of the business.

**Use Case #5: Time-Bound Elevated Access**

When contractors or temporary staff need extra privileges—for instance, to perform a data migration—clone the “System Administrator” Role into “Temp Migration Admin” but set an expiration date on the token used to authenticate that Role. After the project completes, remove or let the token expire to automatically revoke access.