Settings, Privacy & FAQ

Jira site admins only. That means you need the global ADMINISTER permission — not just project admin, not just JSM agent. The distinction that confuses people most: "project admin" in Jira is a per-project role, and it doesn't give you access to this app. You need site-level admin, which is what lets you into Jira's top-level Settings. If you can navigate to Jira Settings from the main nav (the gear icon at the top), you're a site admin and you'll have access.

Yes, most features work fine without it. You can do all of Work Item Configuration, Audit Log Analyser, scheme management, role assignment, user listing, board management, attachments, components, and releases. The key adds user suspend/delete, last-active dates, inactive owner detection, and group management. If you don't need those, skip the key setup.

They track different things. The Activity Log (under Help & Settings) is this app's own record — it shows actions performed through this app specifically: user deletes, suspends, board deletions, access revocations. It's stored in Forge SQL with configurable retention and is useful for "what did I do through this app last month?" The Jira Audit Log Analyser (under Governance) reads Jira's built-in audit log — everything that happened in your entire Jira instance from any source, including native Jira UI actions, API calls, and other apps. The app reads that log live and doesn't store any of it.

Yes. It's stored using Forge's setSecret — encrypted at rest, never sent to the browser, not included in logs. The browser only ever sees a "Configured" status indicator, not the key itself. It's shared across all admins on the site, so treat it like any other privileged credential.

The main Work Item Configuration view has tabs for Workflows, Work Types, Fields, Permissions, Priorities, Notifications, and Screens. Each tab has an Overview sub-tab (summary stats) and a Details sub-tab (full list with search, filter, sort, and bulk delete). Additional sections — Spaces, Dashboards & Filters, Agile Boards, Attachments, Components, Releases, Automation Rules — are in the sidebar under their respective groups and work the same way.

Items marked "In Use" can't be deleted because they're still referenced by an active configuration. Check the Lookup dropdown or expand the row to see what's referencing them — usually it's a scheme that's assigned to a space, or another item further up the dependency chain. Fix the reference first (reassign the space, delete the parent scheme, etc.), then the item will show as "Not In Use" and can be deleted.

It uses Jira's built-in field usage tracking via the field search API. The date reflects the last time a value was written to that field on any issue. Not all field types are tracked by Jira's API — fields that aren't tracked show a dash. For the ones that are tracked, it's reliable: if a field shows Last Used in 2020 on an active instance, it genuinely hasn't been updated since then.

Jira processes the permanent deletion in the background — it's not instant. Projects with many issues can take several minutes to fully delete. You can monitor progress at Jira Settings > Projects > Trash. Once the deletion completes, rescan your workflow and scheme tabs — things that showed as "In Use" because of those trashed spaces will now show as unused and become eligible for cleanup.

It reads Jira's built-in audit log via the /rest/api/3/auditing/record API. That includes all configuration changes: scheme updates, workflow modifications, user management actions, permission changes, and more — anything Jira itself records. It doesn't read content (issue fields, comments, attachments) — only configuration and admin actions.

No. Records are fetched live on each search. User display names are cached in server memory for 10 minutes to avoid redundant API calls during a session, but nothing is persisted to any storage. When you close the tab, it's all gone.

CSV export is capped at 5,000 records per export. For date ranges that produce more than 5,000 events, narrow the filters — add a category filter, reduce the date range, or search for a specific user or object type. You can run multiple exports and combine them in a spreadsheet if needed.

Team-managed spaces control their own configuration — they don't participate in the global scheme library that company-managed spaces use. Jira's REST API doesn't support bulk scheme assignment for them. They show up in the space list so you can see them, but during Apply they're marked Skipped. To change scheme-equivalent settings on a team-managed space, do it from within that space's own Project Settings.

Jira requires a migration step. Each issue has a current status, and if the new workflow scheme has different statuses, Jira needs you to map old statuses to new ones. The app surfaces Jira's native migration page for that space — you complete the mapping there. Empty spaces update immediately without any migration. This is a Jira platform requirement; there's no way to skip it for spaces with issues.

Jira's REST API doesn't support notification scheme reassignment via REST for most scheme types — the endpoint simply doesn't exist. The app identifies which spaces need updating and provides direct links to each space's notification settings page so you can apply the change with one click in each space. It's an API limitation on Jira's side, not the app's side.

Probably not — that scan is genuinely slow on large instances because it has to check every user's product access and last login date. On 15,000 users expect about 8 minutes. The progress bar shows where it is, so you can tell whether it's still moving. As long as the counter is incrementing ("Scanning 4,500 of 15,000 users"), it's working. Don't close the tab while it's running — you'd lose all the data and have to start over.

Suspend blocks login while keeping the account and all its data intact — it's reversible by re-activating the account in Atlassian admin. Delete permanently removes the user from your directory — it's not reversible, and it affects them across all Atlassian products in your org, not just Jira. For someone who's left the company, suspend is usually the right first step; delete can come later once you've confirmed there's no data recovery needed.

The Atlassian Automation REST API requires Basic authentication — your Atlassian email address and an API token generated at id.atlassian.com (not the Org API key). These credentials are used only for your current browser session and are never stored anywhere. When you close the tab or the session ends, they're gone. You'll need to re-enter them next time you use the Automation Rules feature.

Yes. Use the Transfer Ownership action and enter the account ID of the app user directly in the text field — don't use the dropdown, which only shows regular user accounts. App user account IDs usually look like 557058:f58131cb-b67d-43c7-b30d-6b58d40bd077 and can be found in Jira's audit log or by checking the automation rule's current owner in Jira's native Automation settings.

Jira only allows deletion of disabled rules. If you try to delete an active rule, it'll fail. Disable it first, then delete. If you're bulk-cleaning up rules, the typical workflow is: filter to the rules you want to remove, bulk-disable them, then bulk-delete. The app handles this in sequence if you select "disable and delete."

The Teams Public REST API requires Basic authentication with your Atlassian email and an API token from id.atlassian.com. Same pattern as Automation Rules — per-session only, never stored. The credentials are only sent to Atlassian's Teams API endpoint, nowhere else.

External teams are managed by an identity provider via SCIM. They show up in the team list as read-only — you can see their members but can't change them through the app. Changes to SCIM-managed teams have to be made in the identity provider (Azure AD, Okta, etc.), not in Jira or this app.

For components, it checks whether any issues in the space are currently assigned to that component. For versions, it checks both fixVersion and affectedVersion fields across all issues in the space. Once checked, items with no issue assignments are marked "Not In Use" and become eligible for bulk deletion. The check has to be run before deletion — the app won't let you delete items you haven't checked yet.

Version deletion uses Jira's removeAndSwap API. If any issues reference the version being deleted, Jira removes those references from the issues rather than blocking the deletion. You won't get stuck trying to clean up a version that a few old issues are still using.

Up to 5,000 per JQL search — that's a Forge platform constraint. For instances with more attachments than that in a given search, break it up: search by project, by date range, or by file type. For example, search for just PDFs in a project first, then images, then all other types. The client-side filters (file type, size range, author) let you narrow results further after each search loads without making additional API calls.

After loading dashboards or filters, the app checks each owner's account status via the Jira user API. Accounts that are deactivated get flagged as "Inactive" in the Owner Status column. Filter the list to "Inactive owners" to see the full set, then select them all and use Change Owner to bulk-transfer to an active admin.