TeamFlow User Roles
1. Role Design Principles
- Users may hold more than one role
- Project-specific roles may differ from global roles
- Access follows least-privilege principles
- Sensitive decisions require explicit permission
- Users must not approve their own submissions where separation of duties is required
- Management overrides require a reason and are audited
2. Nine Core Roles
SYSTEM_ADMIN
Responsibilities: Maintain users and system configuration
Key Permissions: Create/update users, assign global roles, configure system settings, view security audit logs
Restrictions: Cannot modify approved requirements or use admin access as business approval
CTO
Responsibilities: Provide technical governance and review major risks
Key Permissions: View all projects, review technical assessments, approve high-risk changes, approve releases
Restrictions: Overrides must be logged; approved histories cannot be deleted
MANAGEMENT
Responsibilities: Review portfolio-level delivery and approve business-critical changes
Key Permissions: View executive dashboards, approve major changes, view impact analysis
Restrictions: Cannot edit technical estimates or modify approved requirements
PROJECT_MANAGER
Responsibilities: Plan approved work and manage schedules and sprints
Key Permissions: Create/manage project plans, review requirements, create tasks and releases, recommend change approval
Restrictions: Cannot directly edit approved requirements or delete histories
BUSINESS_ANALYST
Responsibilities: Discover and document business requirements
Key Permissions: Create requirements, submit for review, add acceptance criteria, respond to clarifications, perform BA acceptance
Restrictions: Cannot directly edit approved requirements or alter QA execution results
TECHNICAL_LEAD
Responsibilities: Review feasibility and identify technical dependencies
Key Permissions: Review requirements, approve technical readiness, add technical impact analysis, assign technical tasks
Restrictions: Cannot alter business requirements or overwrite QA outcomes
DEVELOPER
Responsibilities: Implement approved tasks and report progress
Key Permissions: View assigned projects, update assigned tasks, request clarifications, add implementation notes
Restrictions: Cannot edit business requirements, approve changes, or delete audit history
QA_ENGINEER
Responsibilities: Create test cases, execute tests, and raise defects
Key Permissions: Create test cases, link to requirement versions, execute tests, create defects, add QA impact analysis
Restrictions: Cannot change business requirements or approve management decisions
VIEWER
Responsibilities: Read project information without making changes
Key Permissions: View project dashboards, requirements, reports, release status
Restrictions: No create, edit, approve, delete, or export permissions
3. Separation of Duties
The default configuration enforces:
- Requirement author cannot provide final approval for the same version
- Developer cannot provide QA verification for their own implementation
- User cannot approve a change request they created when higher approval is required
- System Administrator cannot use administrative privileges as business approval
- Management overrides require a reason and audit event
4. Authorization Enforcement
Critical Rule: Authorization must be enforced by the backend. Hiding a button in the frontend is not sufficient security.
Backend authorization decision example:
Can user approve requirement version?
├── Is user authenticated?
├── Is user active?
├── Is user a member of the project?
├── Does user hold required review permission?
├── Is version in correct status?
├── Has user authored the version?
└── Does policy allow self-approval?
5. Role Assignment
Users can be assigned roles:
- Globally for organization-wide permissions (SYSTEM_ADMIN, CTO, MANAGEMENT)
- At the project level for project-specific permissions
- Multiple roles can be held simultaneously
Project membership is managed by Project Managers or System Administrators.