Application setup, Administration and configuration
This section describes how to install the application, what Jira permissions it needs, how to perform initial setup, and how to configure delegated admins, system settings, and resource data.
Resource Management for Jira on the Atlassian Marketplace — install, try free, and see pricing and reviews.
Jira application permissions (Jira deployment)
When the application is deployed on Jira (e.g. as a Forge app), it requests the following Jira permissions so it can function properly:
| Permission | Purpose |
|---|---|
| read:jira-user | Read Jira users (e.g. for user sync, resource records, assignees, managers). |
| read:jira-work | Read issues, projects, worklogs, and related work data (for resource requests, timesheets, worklog sync). |
| write:jira-work | Create and update issues, worklogs, and work data (for one-click task creation from resource requests, worklog create/update/delete, approval properties). |
| storage:app | Store application data (Forge storage / app data). |
| manage:jira-project | Manage project configuration (needed for project access and issue operations). |
| manage:jira-configuration | Manage Jira configuration (needed for app installation and admin operations). |
The app also uses content permission for inline styles where required by the UI. These permissions are declared in the app manifest; Jira prompts the installer to approve them when installing the app.
Installing the application
The Resource Management for Jira application can be installed in two ways:
- From the Atlassian Marketplace — The app is listed on the Atlassian Marketplace. A Jira administrator can find and install it from within Jira (see How to install from the Marketplace below).
- Via a link from Sales or a partner — You may receive a direct installation link (e.g. from your account manager or a solution partner). That link leads to an install flow that does not require searching the Marketplace (see Installing via a direct link below).
In both cases, only a Jira site administrator (a user with the Administer Jira global permission) can complete the installation. For details on who can install apps and how Jira presents the install flow, see Atlassian’s documentation: Integrate apps and Installing and managing app access.
Installing from the Atlassian Marketplace
- Log in to your Jira site as a user with Administer Jira (site admin).
- In Jira, go to Apps (or Settings → Apps) and choose Find new apps or Explore more apps (wording may vary by Jira version). This opens the Marketplace or the app discovery experience.
- Search for Resource Management for Jira (or the name provided by your vendor).
- Click Install (or Get it now / Free trial as applicable). Jira may prompt you to log in at my.atlassian.com if you are not already logged in.
- Approve the permissions requested by the app (see Jira application permissions above).
- Wait for the installation to complete. The app then appears in your Jira app list and in the application navigator (or as configured by your Jira admin).
Reference: Integrate apps — Jira Cloud administration.
Installing via a direct link
- Open the installation link you received (e.g. from Sales or a partner). The link points to an Atlassian/Forge install page for the app.
- Select your Jira site (or log in to Atlassian if prompted).
- Confirm installation. Only a Jira site administrator can complete the install; if you are not an admin, the flow may ask you to contact your Jira administrator.
- Approve the permissions requested by the app.
- Wait for the installation to complete.
Reference: Installing and managing app access.
First login and initialization
Once the app is installed, a Jira administrator must log in to the application first. The first admin login triggers the migration/initialization procedure: the application creates the required database structures (e.g. Forge SQL tables) and an empty Corporate team. If no admin logs in first, the app is not fully initialized and other users may see errors or an incorrect setup.
After initialization, the admin can configure delegated admins, system settings, and then sync users from Jira to create resource records (see Resource management below).
Configuration overview
The Configuration area (gear icon in the app) is available only to Instance Admins and Resource Management for Jira App Admins. It is organized into tabs:
| Tab | Purpose |
|---|---|
| Application settings | Enable or disable app-wide features (resource requests, worklogs, approvals, overtime, availability, timesheets, invoice, task creation, notifications). |
| Notification settings | Configure which events send Jira notifications (worklogs, resource requests, availability). Shown only when Enable notifications is on. |
| Roles | Define and order team roles (e.g. Developer, QA). Used in resource request views and confirmation modal. |
| Seniority Levels | Define and order seniority levels. Used in resource request views and confirmation modal. |
| Priorities | Define request priorities (name and color). Used when creating/editing resource requests and in the confirmation modal. |
| Users and Roles | Assign Resource Management for Jira App Admins (delegated admins). Typically used to grant HR or resource managers the ability to manage teams structure and calendars without Jira site admin. |
| Worklogs Sync | Configure worklog sync cadence, manual sync, and retention policy. |
The following sections describe each tab in more detail.
Application settings tab
Organization-level feature toggles. When you change a setting, it is saved immediately and applies across the app.
| Setting | When enabled | When disabled |
|---|---|---|
| Enable resource requests (also enables project timesheets view) | The Requests tab is visible, and the Project view inside Timesheets is available. | The Requests tab is hidden, and the Timesheets Project view is hidden. |
| Enable worklogs management | The Worklogs tab is visible; users can create and edit worklogs. | The Worklogs tab is hidden. |
| Enable worklogs approval | Worklog approval workflow is on; approvers can approve/reject from Timesheets. | Worklog approval is off; approval dialog is read-only. |
| Enable overtime tracking | “Claim overtime” is shown on worklogs; overtime appears in timesheets and invoice options. | “Claim overtime” and overtime options are hidden. |
| Enable availability management | The Availability self-service tab is visible. | The Availability tab is hidden. |
| Enable timesheets | The Timesheets tab is visible. | The Timesheets tab is hidden. |
| Enable analytics | The Analytics tab is visible for supported roles. | The Analytics tab is hidden. |
| Enable invoice generation | The Download invoice action and dialog are available from Timesheets. | Download invoice is hidden. |
| Enable task creation from resource request | The Task button is shown on accepted resource requests (one-click Jira task creation). | The Task button is hidden. |
| Enable notifications | Notifications can be sent; the Notification settings tab is visible. | Notifications are not sent; the Notification settings tab is hidden. |
Notification settings tab
Visible only when Enable notifications is on in Application settings. Configure which events trigger Jira (or platform) notifications.
- Default notification issue (Jira only) — Optional Jira issue key used when sending notifications that are not tied to a specific issue (e.g. some availability or request events). If unset, those notifications may be skipped.
- Worklogs — Send when worklog is approved; send when worklog is rejected.
- Resource requests — Send when request is submitted to the team; sent for PM review; accepted; rejected; closed; cancelled.
- Availability requests — Send when availability request is created; send when availability request is approved or rejected.
Recipients are determined by the app (e.g. request author, worklog author, team managers by RBS). See the app’s notification implementation for exact routing.
Roles, Seniority Levels, and Priorities (lookup data)
These tabs define lookup data used in resource planning:
- Roles — Team roles (e.g. Developer, QA, Designer). You can add, remove, and reorder them (drag-and-drop). They appear in Resource request views and in the Resource request confirmation modal when assigning or viewing resources (e.g. role per resource).
- Seniority Levels — Seniority levels (e.g. Junior, Mid, Senior). Same add/remove/reorder behavior. Used in Resource request views and in the confirmation modal (e.g. seniority per resource).
- Priorities — Request priorities with name and color. Used when creating or editing a resource request (priority field) and in the confirmation modal. Project managers choose a priority so Team Managers can triage by importance.
Delegated admins (Users and Roles tab)
Delegated admins (Resource Management for Jira App Admins) are users who have full access within the Resource Management app (teams, resources, calendars, configuration) but are not Jira site administrators. They are typically HR or resource managers who need to manage the organization structure, team leads, and calendars without having Jira Administer permission.
Where to manage them
Only a Jira Instance Admin can add or remove delegated admins. In the app, go to Configuration (gear icon) and open the Users and Roles tab.
Key controls on the Users and Roles tab
- Resource Management for Jira App Admins (Jira) — Section that lists the current delegated admin accounts.
- Add admin — Opens a search dropdown to find Jira users by name. Selecting a user adds them to the delegated admins list. The button is disabled if the adapter does not support delegated admin management or if the current user is not a Jira Instance Admin.
- Delegated admin accounts — List of users who are Resource Management for Jira App Admins. Each row shows the user’s display name (or account ID if the name could not be resolved).
- Remove — Removes that user from the delegated admins list. Only Jira Instance Admins can remove; the list is read-only for others.
- Permission note — The tab shows: Only Jira Instance Admins can add/remove delegated admins.
Delegated admins cannot add or remove other delegated admins; only the Jira Instance Admin can change this list. Typically you assign resource managers or HR so they can manage the organization structure (teams, RBS, managers) and calendars (default calendar, overrides, availability) without needing Jira site admin rights.
Worklogs Sync tab (Jira)
(Jira deployment only.) The Worklogs Sync tab configures how Jira worklogs are mirrored into the app and how long data is kept.
Why worklogs are synced
To enable quick calculations for timesheets and invoices, all Jira worklogs are proxied in a Forge SQL table (task_worklogs). This table is automatically synchronized according to the Sync Cadence you set (hourly, daily, or disabled). The sync process fetches updated and new worklogs from Jira and writes them into the Forge table so the app can aggregate by period, resource, and project without calling Jira on every request.
Sync Cadence and manual sync
- Sync Cadence — Choose Hourly, Daily, or Disabled. When set to Hourly or Daily, the app runs the sync on that schedule (daily sync uses the Daily Sync Start Hour (UTC) you configure). When Disabled, no automatic sync runs.
- Sync Now (Global) — If you need to backfill or resync all existing worklogs from Jira, click Sync Now (Global). This queues a full sync that fetches worklogs from Jira and updates the Forge table. The sync runs asynchronously; the Last Sync Status block updates when it finishes.
Last Sync Status block
After at least one sync has run, the Last Sync Status block shows:
- Last sync run — Date and time of the most recent sync run (whether it succeeded or failed).
- Last successful sync — Date and time of the most recent run that completed successfully.
- Status — success, error, or never (no sync has run yet).
- Sync Results (when available) — Counts for Updated, Deleted, Upserted, Skipped, and Errors for the last run.
Use this to confirm that sync is running and to troubleshoot if status is error or counts look wrong.
Data retention policy (Forge quota)
Forge allocates a limited database size (e.g. 1 GB) per app. To keep the Forge-allocated database within the allowed quota, the app applies a data retention policy: worklogs and other historical records older than the retention window are deleted during sync/cleanup. The admin can set the retention duration manually in the Worklogs Sync tab (e.g. 1, 3, 6, 12, or 24 months, depending on configuration). When the admin changes the retention setting and confirms (via the confirmation dialog), the policy is applied immediately: the retention routine runs and deletes records that no longer fall within the new retention window. Older worklogs and related data are permanently removed from Forge SQL.
If the database exceeds a threshold (e.g. 800 MB), the app may enforce a smaller retention window automatically to stay under the 1 GB limit. In that case the Data retention status block shows the enforced value.
Data retention status block
(Jira only.) The Data retention status block displays:
- Consumed space — Current database usage in MB (and optionally threshold and limit in MB).
- Total rows (approx.) — Approximate number of rows in the affected tables.
- Measured at — When the usage was last measured.
- Enforced retention — If the app has overridden your retention setting to protect storage (e.g. to stay under 1 GB), the enforced retention in months is shown here; otherwise “None”.
Use this to monitor storage and to understand when the app has automatically tightened retention.
Other data retention (Resource Management for Jira config)
The application also uses Resource Management for Jira data retention (dataRetentionMonths), stored in the main Configuration (default 12 months). It applies to:
- Availability periods, resource rates, and resource calendar assignments (JSONB-style data).
- When fetching, the backend only returns periods whose end date (or start date if no end) is on or after the retention threshold (today minus
dataRetentionMonths). Older periods are excluded. - When saving, the backend overwrites the full payload from the frontend, so data beyond the retention boundary is not re-stored.
This is separate from the Worklogs Sync retention policy, which applies specifically to the synced worklog table and Forge storage.
Resource management
After the app is initialized, resource records (one per Jira user who can be assigned to work) must be created and kept in sync with Jira. This is done from the Organization Structure tab, not automatically in the background.
Initial sync: fetch users from Jira
- Log in as an admin or delegated admin (e.g. HR or resource manager).
- Open the Organization Structure tab.
- Click the Update Users button (in the structure toolbar).
- The application will:
- Fetch Jira users from the Jira instance (in batches).
- Create or update resource records for each user and link them to the Corporate team.
- Set up application data so that permissions and team membership are consistent.
Until this is done, the app has an empty Corporate team and no resource records; other features (e.g. resource requests, timesheets) depend on these records.
Resource records are not automatic
Resource records are not created automatically when new users are added in Jira, and they are not deleted when users leave Jira. This is by design for data consistency: requests, assignments, and history refer to resource IDs; deleting resources would break referential integrity.
Therefore:
- New users in Jira — An admin or delegated admin must run Update Users (Organization Structure tab) periodically so that new Jira users get a resource record and appear in the Corporate team.
- Users who leave or are no longer involved — Admins or delegated admins should archive those resources in the app (e.g. via Team Management or Organization Structure). Archiving marks them as inactive without deleting them; they can be excluded from active planning while keeping historical data intact.
In practice, admins or delegated admins (often HR or resource managers) should:
- Click Update Users after new people join the organization (or on a regular schedule).
- Archive resources for people who have left or are no longer involved in projects, so that the active list stays accurate.
Summary
| Step | Who | Where | Action |
|---|---|---|---|
| Install app | Jira admin | Atlassian / Forge | Install on Jira instance |
| First login | Jira admin | Any app page | Log in once to run initialization |
| Delegated admins | Jira Instance Admin only | Configuration → Users and Roles | Add/remove Resource Management for Jira App Admins |
| Configuration | Admin or delegated admin | Configuration | Application settings, Notification settings, Roles, Seniority, Priorities, Worklogs Sync, data retention |
| Create/update resources | Admin or delegated admin | Organization Structure | Click Update Users to sync Jira users to resource records |
| Archive leavers | Admin or delegated admin | Team Management / Organization Structure | Archive resources no longer in use |
Need help?
If you have further questions about installing or configuring the app, or if you run into issues during setup, please contact our support team via the Contact form.