Access Control & Governance Roles
In an enterprise environment, the integrity of resource data—such as labor rates, availability, and staffing commitments—is paramount. Resource Management utilizes a sophisticated Role-Based Access Control (RBAC) system that separates the "Demand" (Project Management) from the "Supply" (Team Management).
This separation of concerns ensures that no single user can unilaterally commit resources without the approval of the respective resource owner, preventing "shadow staffing" and unauthorized over-allocation.
The Governance Architecture: Global vs. Scoped Roles
Resource Management distinguishes between users who govern the entire system and those who manage specific operational boundaries.
1. Global Governance (Admin Roles)
Global roles provide a "helicopter view" of the entire organization, ensuring that standards are consistent across all teams and projects.
- Instance Admin: The ultimate authority. Inherits the "Administer Jira" permission. This role is responsible for the overarching system configuration and the appointment of delegated administrators.
- Delegated App Admin: Designed for HR Directors or Resource Officers. These users manage the organizational structure, define team boundaries, and maintain global calendars without needing full Jira Site Administration rights.
2. Scoped Operational Roles
Scoped roles are designed for day-to-day delivery. Their authority is limited to the specific "boundary" they manage.
- Team Manager (The Supply Side): Authority is scoped to specific Teams. They are the guardians of their team's capacity and the only ones authorized to assign resources to requests.
- Project Manager (The Demand Side): Authority is scoped to specific Jira Projects where the user can Administer Projects (or is Project Lead). They define staffing needs across those projects, accept proposals, and can approve worklogs when approvals are enabled.
- Requester (Limited Demand Side): Authority is scoped to specific Jira Projects where the user has the custom Request resources permission — without Administer Projects. They raise and own resource requests for those projects, and review fulfillment on Timesheets and Analytics in Project mode limited to their own requests. They do not get Project Manager powers (no Structure tab, no worklog approval, no visibility into other people's requests on the same project).
Role Responsibility Matrix
To ensure a seamless workflow, the system enforces a strict "Check and Balance" mechanism.
| Role | Primary Objective | Key Authority | Governance Constraint |
|---|---|---|---|
| App Admin | System Integrity | Org Structure & Global Config | Cannot arbitrarily change project commitments |
| Team Manager | Capacity Health | Resource Assignment & Rates | Cannot create project-level demand (unless also PM/Requester) |
| Project Manager | Delivery Success | Demand Definition & Acceptance | Cannot force a resource assignment |
| Requester | Controlled Demand | Own requests on Request-resources projects | Cannot assign people; cannot see others' requests; no worklog approval |
| Viewer | Transparency | Own worklogs, timesheets & analytics (self-scope) | No modification rights beyond self-service; no team/project manager scopes |
Detailed Capability Mapping
The following matrix defines the operational boundaries for each role. Note: Users who hold multiple roles (e.g., a Team Lead who is also a Project Manager) receive the union of these permissions. When more than one scoped role applies, the app still picks a single primary role for navigation labeling using this precedence: Admin → Team Manager → Project Manager → Requester → Viewer. Capability flags (team manager / project manager / requester) remain independent so dual-role users keep the full union.
| Capability | Admin | Team Manager (Scoped) | Project Manager (Scoped) | Requester (Scoped) | Viewer |
|---|---|---|---|---|---|
| Define Org Structure (Teams/RBS) | ✅ | ❌ | ❌ | ❌ | ❌ |
| Open Structure / Team Management tabs | ✅ | ✅ | Structure only (read-only) | ❌ | ❌ |
| Manage Resource Rates & Calendars | ✅ | ✅ (Managed Teams) | ❌ (calendars view-only) | ❌ (calendars view-only) | ❌ (calendars view-only) |
| Create Resource Requests | ✅ | ✅ (For Managed Teams) | ✅ (For Managed Projects) | ✅ (Own projects with Request resources) | ❌ |
| See others' requests on same project | ✅ | ✅ (Managed Teams) | ✅ (Managed Projects) | ❌ (own requests only) | ❌ |
| Assign Resources to Requests | ✅ | ✅ (Managed Teams) | ❌ | ❌ | ❌ |
| Accept/Reject Staffing Proposals | ✅ | ❌ | ✅ (Managed Projects) | ✅ (Own requests) | ❌ |
| Review & Approve Worklogs | ✅ All | ❌ | ✅ (Managed Projects) | ❌ | ❌ |
| View Timesheets (Team Perspective) | ✅ All | ✅ Managed Teams | ❌ | ✅ Own hours only when Let viewers see their timesheets is on (optional; default view is Project) | ✅ Own hours only (when enabled) |
| View Timesheets (Project Perspective) | ✅ All | ❌ | ✅ Managed Projects (all RRs) | ✅ Own RRs as baseline; actuals for those projects | ❌ |
| View Analytics | ✅ Both modes | ✅ Team mode | ✅ Project mode (project RRs) | ✅ Project mode (own RRs demand + project actuals); optional Team self-scope when Let viewers see their analytics is on | ✅ Self-scope only (when enabled) |
| Access Configuration Tab | ✅ | ❌ | ❌ | ❌ | ❌ |
Tabs by primary role (when features are enabled)
| Tab | Admin | Team Manager | Project Manager | Requester | Viewer |
|---|---|---|---|---|---|
| Worklogs / Availability / Calendars / Config shell | ✅ | ✅ | ✅ | ✅ | ✅ |
| Requests | ✅ | ✅ | ✅ | ✅ | ❌ |
| Timesheets / Analytics | ✅ | ✅ | ✅ | ✅ | ✅ when “Let viewers see…” is on |
| Team Management | ✅ | ✅ | ❌ | ❌ | ❌ |
| Structure | ✅ | ✅ | ✅ (read-only) | ❌ | ❌ |
Viewer-only toggles: Let viewers see their timesheets and Let viewers see their analytics apply to pure Viewers for whether those tabs appear. For Requesters, those toggles do not hide the tabs (global Enable timesheets / Enable analytics do); when on, they additionally unlock optional Team self-scope (“my load”) alongside the default Project mode. Requester Project mode also requires Enable resource requests for the Project timesheets view (same as PM).
Viewer Analytics hides Requested allocation; viewer Timesheets never includes approval actions. Requester Analytics shows requested allocation in Project mode for their own open demand (hidden only if they switch into Team self-scope).
The Requester Role in Detail
Use Requester when someone needs to raise staffing demand for a project without receiving full Project Manager authority.
How Requester is granted (Jira)
- Install / ensure the app’s custom project permission Request resources is available in your permission schemes.
- Grant Request resources on the relevant projects to the people who should raise requests.
- Do not grant Administer Projects (and do not make them Project Lead) if you want them to stay Requesters rather than Project Managers.
| Jira signal | App role |
|---|---|
| Administer Projects / Project Lead on a project | Project Manager for that project |
| Request resources only (no Administer Projects) | Requester for that project |
| Both on different projects | Union: PM scope + Requester scope |
What a Requester can do
- Open the Requests tab and create, submit, edit, accept, cancel, or close their own resource requests on projects where they have Request resources.
- Use Timesheets → Project view for those projects, with the staffing baseline built from their own requests (not every request on the project). When Let viewers see their timesheets is on, they may also switch to Team self-scope for their own hours.
- Use Analytics → Project mode with Requested / Filled demand from their own requests, and Actuals aggregated at project level for those projects. When Let viewers see their analytics is on, optional Team self-scope is available (Requested allocation hidden in that mode).
- Use the same self-service surfaces as other users (Worklogs, Availability) for their own time.
What a Requester cannot do
- Assign or propose people on requests (Team Manager / Admin only).
- See or act on resource requests created by other users on the same project.
- Approve or reject worklogs.
- Open Team Management or Structure.
- Use Team-mode Analytics / Timesheets as a Team Manager (unless they are also a Team Manager).
Practitioner's Perspective: Implementing the "Separation of Concerns"
From a governance standpoint, the most critical aspect of the RBAC system is the preventative nature of the workflow.
In many organizations, Project Managers "claim" resources through informal agreements, leading to conflicting priorities and burnout. By enforcing the Team Manager → Project Manager / Requester hand-off:
- Capacity is Protected: No resource can be assigned to a project without the Team Manager's explicit consent.
- Commitments are Validated: No demand-side user can assume a resource is available until the Team Manager proposes the assignment.
- Auditability is Guaranteed: Every assignment is linked to a specific actor and a specific timestamp, removing ambiguity during project retrospectives.
- Demand can be delegated safely: Requesters can staff projects without inheriting Administer Projects or seeing the whole project's request portfolio.
Integrating with Jira Permissions
To ensure a seamless experience, Resource Management synchronizes with your existing Jira permission scheme:
- Project Manager Role: Automatically derived from the Project Lead or Administer Projects permission in Jira. This ensures that as you change project leadership in Jira, the staffing authority in Resource Management updates instantly.
- Requester Role: Automatically derived from the custom Request resources project permission (without Administer Projects). Scope is per project.
- Admin Roles: Leverage Jira's global permissions to ensure that only trusted site administrators can appoint delegated app admins.
Summary Table: Role Assignment
| Role | Assignment Method | Typical User |
|---|---|---|
| Instance Admin | Jira Global Permission | Jira Site Admin |
| App Admin | Configuration → Users & Roles | HR / Resource Director |
| Team Manager | Team Management → Team Lead | Functional Manager / Lead |
| Project Manager | Jira Project Lead / Administer Projects | Delivery Lead / PM |
| Requester | Jira Request resources permission (no Administer Projects) | Coordinator / PMO analyst / proxy on a project |
| Viewer | Default | Team Member / Stakeholder |