Application Roles
What Is Role-Based Access Control?
Role-Based Access Control (RBAC) is the standard pattern for governing who can do what within a system. Rather than assigning permissions directly to individual users — which becomes unmanageable at scale — RBAC groups permissions into named roles. Users are assigned to roles, and roles are assigned to applications. When a user’s responsibilities change, you update their role assignment rather than their individual permissions.
RBAC underpins the access control model of virtually every enterprise application. It enforces the principle of least privilege: users get only the access they need to perform their function, and no more. This reduces the risk of accidental or malicious misuse of application capabilities.
Application Roles vs Business Roles
Application Roles and Business Roles are distinct concepts in ArchRepo and should not be confused.
- A Business Role represents an actual job function or responsibility within the organisation — for example, “Finance Manager” or “Customer Service Agent”. Business Roles describe who people are in the organisation.
- An Application Role represents a set of permissions within an application — for example, “Billing Admin” or “Report Viewer”. Application Roles describe what people can do in a system.
There is often a relationship between the two, but it is rarely 1:1. A single business role may require access to several different application roles across multiple systems. Conversely, a single application role may be appropriate for people in several different business roles.
Documenting Application Roles separately from Business Roles allows you to model the access design of your solution accurately, without conflating the organisational structure with the technical implementation.
Why Document Application Roles in an Architecture Repository?
Application Roles are a security and architecture concern, not just a configuration detail. Documenting them in ArchRepo provides:
- Access design traceability — link roles to the business requirements and use cases that justify them; demonstrate that the access model is grounded in real business need
- Security review support — a complete picture of who can access what, available to reviewers and auditors alongside the rest of the architecture
- Performance model input — the number of users in each role, and the number of concurrent users, are direct inputs to capacity and performance planning
- Impact analysis — when an application changes, see immediately which roles are affected
Application Roles in ArchRepo
In ArchRepo, Application Roles are model items identified by an auto-generated reference in the format AR-1, AR-2, etc.
Each role defines three levels of access to applications:
| Access Level | What it means |
|---|---|
| Admin | Full access, typically including create, edit, delete, and configuration |
| Write | Create and edit rights, but not delete or administrative functions |
| Read | Read-only access to application data and views |
A single Application Role can have different access levels across different applications — for example, admin access to one system and read-only access to another.
Roles also capture:
- Number of Users — the total count of users expected to hold this role
- Concurrent Users — the number of users in this role likely to be active at the same time
Both figures feed directly into the performance and capacity model for the solution.
Application Roles are typically assigned to Business Roles in your access design — but the mapping is rarely 1:1. Document Application Roles based on the permissions needed within the application, then separately document the mapping to Business Roles as part of your access governance documentation.
The collection view for Application Roles includes an Apps and Roles diagram that visually maps all roles to the applications they have access to, providing a clear overview of the access model across the whole solution.
Fields Reference
See Application Role Fields for a description of each field and guidance on what to record.