Enterprise AI Project Wiki · Requirements and business scenarios
User role
Also calledBusiness role · User type · Participant role · Role of the user
A user role is a stable abstraction that groups people who share goals, responsibilities, tasks, and a context of use while directly using a service or participating in its business outcome. It explains why those participants enter a scenario, what they need to know and accomplish, which business decisions they may make, where they hand work over, and which conditions constrain them instead of substituting a person's name or system account for a requirement.
A user role describes business responsibility, not an account label
‘User’ is not a sufficient requirement. The person who submits a request, checks evidence, authorizes a decision, handles an exception, and only receives the outcome have different goals, information needs, authority, and consequences of error. Calling all of them a standard user postpones decisions about screens, workflow, notifications, access, and acceptance until implementation.
A role abstracts recurring responsibility. Many people may carry one role, and one person may carry several roles by scenario or time. A store manager may request replenishment and approve it below a defined threshold; the system must evaluate the current object and conditions rather than infer authority from a name.
Roles should come from real work, not be copied from an organization chart or current permission table. The same job can involve different tasks because of region, qualification, delegation, or working conditions, while different jobs can perform the same task. Existing access describes today's implementation, not necessarily the target service.
What a project-ready user-role record contains
A role name is only the entry point; the useful part is the work behind it. Two people called operations staff may differ because one only reads results while another edits sources and approves release. Connecting tasks, accountability, information, and limits lets the project design for real work instead of guessing from job titles.
Stable name and context
Use a responsibility the business recognizes, such as purchase requester or quality-exception reviewer. State the organization, region, product, channel, or scenario where it applies; avoid User A or power user.
Goal and successful outcome
State the business result and how responsibility reaches completion. The goal is not to use a system but to submit a valid request, make an evidence-based decision, or recover a blocked task.
Responsibilities and exclusions
Identify whether the role initiates, checks, decides, executes, notifies, reviews, or takes over, and what it must not combine because of qualification, risk, or segregation of duties.
Tasks and triggers
List scenarios, events starting the work, frequency, batch size, and time constraints. Retain tasks that affect requirements rather than treating every click as a responsibility.
Information and records
Describe required business objects, sources, history, and decision basis and the records changed afterward, including sensitivity, minimum visibility, and retention.
Decisions and authorization boundaries
Distinguish view, recommend, edit, submit, approve, withdraw, and exception handling, with amount, region, state, time, or dual-review conditions. Access controls implement this business meaning.
Handoffs and collaboration
State where work comes from, who receives which result, when it escalates, and how delegation, absence, shifts, and cross-organization work operate.
Capability and context of use
Record domain knowledge, training, language, digital skill, device, workplace, connectivity, and accessibility needs instead of assuming everyone in one role works alike.
Risk and affected parties
Identify who and what can be affected by an error, delay, bias, or overreach and whether the role handles high-value, sensitive, irreversible, or regulated work.
Evidence, owner, and version
Retain supporting research, policy, tickets, and logs, plus the business approver, applicability date, and version so change can trigger review.
How to identify roles from real users and real work
An organization chart shows where people report, but not necessarily who performs each step. Role discovery follows how people receive work, make decisions, handle exceptions, and own outcomes. Employees, contractors, and temporary delegates may play different roles in the same process.
Start with tasks and outcomes
Identify real tasks, triggers, and end states, then find people who perform, support, or are affected by them. Do not decide names first and search for confirming evidence.
Include frontstage, backstage, and non-digital participants
Research interface operators together with people working by phone, email, or offline, caseworkers, supervisors, operations staff, and third parties.
Observe as well as ask
Combine interviews and contextual observation with forms, tickets, logs, policies, and training. Compare formal rules, actual practice, and workarounds.
Cluster by responsibility
Group people who share goals, tasks, decisions, information, and handoffs. Department, seniority, or age matters only when it changes the need or responsibility.
Find consequential differences
Check limits, qualifications, region, device, volume, time pressure, accessibility, delegation, and impact of error. Split only when a difference changes flow or acceptance.
Replay business scenarios
Take candidate roles through nominal, insufficient-information, exceptional, unauthorized, and takeover paths and confirm what each knows, decides, records, and passes on.
Validate with actual participants
Involve real users, business ownership, support, technical and security specialists, and accessibility expertise in proportion to risk. Record disagreements and missing groups.
Maintain a registry
Assign stable IDs and connect roles to scenarios, requirements, access, training, tests, and owners. Version material changes and assess downstream effects.
When user roles should be split or combined
Roles that are too broad mix low- and high-authority users; roles that are too narrow create a design for every individual. Split when tasks, information, permissions, risk, or success criteria truly require different treatment, not merely because job titles differ.
- Do their goals differ?
Fast submission and independent judgment remain distinct even on the same screen.
Check goals, success outcomes, and accountability.
- Do responsibilities or decisions differ?
Viewing versus approval, recommendation versus execution, and preparation versus review often require explicit separation.
Check delegated authority, RACI, approvals, and audit records.
- Do task paths and information differ materially?
A department name alone may not justify a role; different rules, exceptions, devices, or handoffs may.
Check scenario, field, rule, and integration differences.
- Does capability or working context change design?
Digital confidence, assistive technology, shop-floor use, connectivity, and language can change interaction and support.
Check research, device constraints, and accessibility tests.
- Is only the permission limit different?
When goals and tasks are the same, express a temporary limit as an authorization condition instead of cloning roles.
Check whether role definitions and permissions can be maintained separately.
- Is the distinction evidenced?
Do not create a role from one person's habit; record an assumption and test it with more users and operating evidence.
Check coverage, counterexamples, and unrepresented groups.
What a user-role record can look like
The constructed procurement setting below is unrelated to any customer and shows how a role can be read from its name through tasks, authority, and accountability. A project need not copy the fields, but a new reader should understand why the role exists and how the system supports it.
UR-03: purchase requester
Prepares and submits a verifiable request for an established business need and responds to requests for more information and the outcome; does not approve its own request or alter the budget balance.
Participants and context
Employees in several departments may carry the role on desktop or mobile for their department. Region, category, proxy submission, and accessibility still require research.
Principal tasks
Select a cost center, explain purpose and date, provide supplier and quotation evidence, confirm declarations, submit, correct returned requests, withdraw where allowed, and receive the outcome.
Information needed
See applicable policy, required evidence, available cost centers, status, and return reasons without automatically seeing other people's sensitive requests or approval notes.
Decisions and limits
Save, submit, and withdraw in defined states; never self-approve, bypass evidence, or treat AI guidance as purchasing authority. Proxy use records operator and represented person.
Handoffs and exceptions
A complete request goes to procurement; incomplete work returns. Unconfirmed identity, cost center, or rules stop submission and pass retained context and an error reference to support.
Validation
Confirm with actual-user research, representative requests, support tickets, denied-access tests, and accessibility testing; this example is not acceptance evidence.
How user roles map to accounts and permissions without becoming the same thing
One person may carry several business roles, and several people may rotate through one role. An account identifies the visitor, while permissions decide what that identity may do now. Equating all three leaves excessive access after transfers or temporary delegation and obscures who owns the business outcome.
Define business meaning first
Explain who needs to see or do what because of which responsibility, then translate objects, actions, and conditions into authorization rules. Menu permissions can contain historical over-access.
Identity establishes who acts
Accounts, SSO identities, service accounts, and external principals identify operators. One identity may carry several roles, and one role may be carried by many identities.
Authorization decides what is allowed now
RBAC can assign permissions to security roles, while effective access can also depend on ownership, amount, region, state, time, device risk, or delegation.
Segregation of duties checks combinations
Request and approval or preparation and review conflicts require checks across role combinations, the current object, and prior actions—not just separate menus.
Delegated and emergency access is evidenced
Cover and emergency access need authority, reason, scope, start and end, renewed confirmation, and audit rather than a silent role change.
Test allowed and denied behavior
Test what each role must complete and what it must not view, change, approve, or process; logs should reconstruct identity, role, condition, and decision.
How user roles support scope, design, testing, and operations
A role is not a persona written during discovery and then archived. Scope uses it to identify whom the phase serves, design adapts the journey to the work, testing asks representative roles to complete tasks, and operations observes errors, handoffs, and support by role. Without those uses, the definition is only a label.
Project scope
State supported and excluded roles, organizations, regions, channels, and delegation, plus the research, migration, training, access, and support work required.
Requirements and priority
Connect goals, tasks, information, decisions, and exceptions to scenarios and requirements, without prioritizing only the loudest manager or most technical users.
Interaction and content
Organize around the current task, language, frequency, device, pressure, and accessibility need. Views may differ while the underlying business state remains consistent.
Data and access
Build a role–scenario–business object–action–condition matrix for field visibility, batch scope, export, approval, deletion, delegation, and audit.
Testing and acceptance
Cover nominal, exceptional, unauthorized, cross-role handoff, and accessibility paths with representative participants and authorized business confirmation. An administrator cannot stand in for every role.
Go-live and training
Prepare proportionate training, guidance, support, and notices and confirm provisioning, access approval, delegation, and leaver removal before formal use.
Operations and maintenance
Observe completion, errors, escalation, abandonment, and support by role, and reconcile organizational change and permission drift with the role baseline.
Why enterprise AI must distinguish different human roles
Who sees an AI output, who may ask it to act, and who reviews the result determine the real risk of the same capability. Direct users, affected people, approvers, and operators may be different groups. Calling all of them “users” leaves important accountability unassigned.
The person who uses AI directly
This person may ask an occasional question or carry AI output into a formal process every day. The system needs to make capability, evidence, required checks, and error reporting understandable. It cannot assume everyone is skilled at prompting and then blame poor usability or misuse on the user.
Output reviewer
The reviewer needs original material, citations, model and knowledge versions, edits, and rejection records. Accountability cannot remain the phrase human in the loop.
Business decision authority
A person making a consequential decision needs authority independent of model advice, a basis to refuse or override, and explicit accountability.
Human-takeover operator
On insufficient information, uncertainty, overreach, conflict, or tool failure, the operator needs context, executed actions, and the stop reason instead of rebuilding the case.
Knowledge and rule owner
This role approves, updates, withdraws, and scopes sources and handles permission propagation, conflict, and expiry; it differs from the everyday user.
System operator and risk overseer
These roles monitor quality, cost, latency, misuse, drift, incidents, and appeals and own pause, degradation, and recovery duties.
Affected person without an account
Applicants, customers, suppliers, or employees may be affected without operating the system. Define explanation, correction, appeal, and human-review routes.
Automated principal or third-party system
An API or bot may be a UML Actor, but requirements still name the accountable business owner, calling identity, limits, failure responsibility, and audit.
Concepts commonly confused with a user role
Job positions, personas, accounts, permission groups, and stakeholders all describe people from different angles. A user role focuses on responsibility and behavior within a business task. Replacing it directly with another concept removes a layer that design, authorization, or communication still needs.
| Related concept | How it differs from a user role |
|---|---|
| Actual user or person | A person has a specific identity, experience, abilities, and several responsibilities. A role abstracts shared responsibility; one person may carry several roles. |
| Job or position | A job belongs to organizational design; a role follows goals and tasks in a service. One job can carry many roles, and one role can cross jobs or organizations. |
| Persona | A persona communicates researched behavior, needs, context, and differences. A role focuses on responsibility, tasks, decisions, and handoffs in a business context. |
| User group or customer segment | Groups can follow demographic, market, contract, or behavior attributes. A difference becomes another role only when it changes task, responsibility, or context. |
| UML Actor | An Actor is a role outside a selected system boundary and may be a person, organization, or system. A user role explains human business responsibility and can precede that boundary. |
| Account | An account is an identifiable access principal and does not explain a business goal. Accounts may receive several roles; service accounts and delegation need separate governance. |
| Permission or RBAC role | An RBAC role connects permissions to an organizational function. A business role supplies requirements; mapping need not be one-to-one and a business name does not prove least privilege. |
| Project-team role | Product owner, project manager, developer, and tester describe who builds and governs the project. User roles describe participants in the target service. |
| Stakeholder | Stakeholders include anyone influencing or affected by a project, many without a service task. A user role covers a recurring responsibility connected to use and outcome. |
Sources and scope
This entry explains a user role in requirements, service design, and enterprise AI projects: the goals, responsibilities, and tasks carried by a class of participants in a particular business context. It is not a named person, account, username, job title, persona, customer segment, UML Actor, permission group, project-team role, or synonym for every stakeholder. Roles can inform access-control design, but this entry does not replace identity governance, an RBAC model, security review, organizational delegation, or segregation-of-duties policy. Actual roles, delegation rules, conflicting duties, and permissions require approval by the responsible business and security authorities.
- NASA Systems Engineering Handbook: identify stakeholders early, elicit expectations through concepts and scenarios, and involve appropriate roles in review
- ISO 9241-210:2019: human-centered design principles and activities across the interactive-system lifecycle
- GOV.UK Service Manual: research who will use a service, what they are trying to do, how they work now, and who provides or supports it
- GOV.UK Service Manual: research different users, end-to-end channels, needs, capabilities, and people providing and supporting the service
- OMG UML 2.5.1: Actors represent roles outside a system boundary that interact with the system
- NIST CSRC Glossary: role can mean organizational duties or rules governing user-system interaction depending on source context
- NISTIR 6192: RBAC mediates resource access through organizational identities called roles
- NIST AI RMF Appendix A: distinguishes end users, operators, domain experts, evaluators, auditors, and other AI lifecycle roles
- NIST AI RMF Core: document risk roles, communication, operator proficiency, human oversight, affected groups, appeals, and deactivation duties