Application Role Fields

Within ArchRepo, Application Roles are defined with a small set of fields that describe the role’s purpose, its user population, and its access rights across applications.

1. Description

• What it’s for: A plain-language summary of what this role can do within the application or system, and the business function it serves.

• What to include:

  • Describe the application capabilities this role has access to.
  • Identify the type of user who typically holds this role (without referencing individual names — use Business Roles instead).
  • Note any important constraints (e.g. “read-only access to all modules except own profile”, “admin access restricted to configuration screens only”).

• Example: "The Billing Administrator role has full access to the invoicing and payments module, including the ability to create, edit, and void invoices. Cannot access the user management or system configuration screens."

2. Number of Users

• What it’s for: The total number of users expected to hold this role at any one time.

• What to include:

  • Provide a realistic estimate of the total user population for this role.
  • This figure is used as an input to the performance model — it influences capacity planning, database connection pool sizing, and infrastructure sizing decisions.
  • If the number is expected to grow significantly, note the anticipated future figure as well.

• Example: 250 (total users with this role across all regions)

3. Concurrent Users

• What it’s for: The number of users in this role expected to be actively using the application at the same time.

• What to include:

  • Estimate the peak concurrent user count — typically a fraction of the total user population, based on working patterns and time zones.
  • This is a key input for capacity and performance planning: it drives decisions about server instance count, caching strategies, and load balancing.
  • Consider peak periods (e.g. month-end for finance roles, morning rush for customer service roles).

• Example: 40 (peak concurrent users during business hours)

4. Admin Access (relationship to Applications)

• What it’s for: Lists the applications where this role has admin-level access — typically full edit rights including configuration and administrative functions.
• What to include:
  • Link all applications where this role has admin or superuser access.
  • Admin access usually includes everything write access covers, plus the ability to delete records and configure the application.
  • Keep admin access narrowly scoped in line with least-privilege principles.

5. Write Access (relationship to Applications)

• What it’s for: Lists the applications where this role has write access — typically the ability to create and edit records, but not delete or administer.
• What to include:
  • Link all applications where this role can create and modify data.
  • Write access is the most common access level for operational users who need to do their job without having full control.

6. Read Access (relationship to Applications)

• What it’s for: Lists the applications where this role has read-only access — can view data but cannot create, edit, or delete anything.
• What to include:
  • Link all applications where this role is limited to viewing data.
  • Read-only access is appropriate for oversight roles, auditors, reporting users, and stakeholders who need visibility without the ability to make changes.

Other Relationships