Settings and protection

The API connection, the inactivity threshold, and the protected list that bounds everything.

Jira → Apps → License Waste Manager → SettingsIllustration

Settings

DashboardUsersAdmin RolesAPI TokensAutomationAudit LogSettings

Organization API Connection

ConnectedRequired. Every user, group membership and product-access read goes through it, as does every change.

Organization ID

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

API Key

••••••••••••••••••••

Test ConnectionSaveDisconnectUse detected Org ID

Generate an API key at admin.atlassian.com → Settings → API keys. The key requires Organization admin permissions.

Default Inactivity Threshold

Days

Users inactive for more than this number of days will be flagged.

Protected Entities

Protected users, groups and domains are excluded from all bulk actions and automation rules.

Protected Users

Marina Costa ✕Site Admin ✕Search user to add…

Protected Groups

org-admins ✕site-admins ✕Search group to add…

Protected Domains

example.com ✕Add domain (e.g. company.com)

Organization API connection

Why it is needed. Jira alone cannot tell you when somebody last used Confluence, and it cannot suspend an organisation account. The Atlassian organisation API can do both.

1Go to admin.atlassian.com → Settings → API keys and create a key. Choose Create API key without scopes — this matters, see the note below. It requires Organization admin permissions.
2Copy the organisation ID, or click Use detected Org ID if the app has already worked it out from the key.
3Paste both values into Settings and click Test Connection. If the organisation ID is wrong, the app lists the organisations your key can actually reach.
4Click Save. The app can then detect your licence groups automatically, so product access maps to the right groups.

	With the connection	Without it
Running a scan at all	Yes	No — the button is disabled and the Dashboard says why
Last-active dates, per product	Yes	No
Visibility across your organisation's sites	Yes	No
Automatic licence-group detection	Yes	No
Group membership and product access	Yes	No — both are read through the organisation API
Suspend and restore accounts	Yes	No — the app says so instead of failing
Automation rules	Yes	No — rules will not fire, and the scheduler says so in the log

Create the key without scopes

Atlassian offers a choice when you create an organisation API key: with scopes or without. This app needs one without. A scoped key reaches only the endpoints in Atlassian’s scope table, and suspending or restoring an account is not in it — Atlassian’s own words are that any endpoint not listed “needs an API key without scopes”. The trap is that a scoped key passes Test Connection, because reading your organisation is scoped. Everything looks right until the first revocation, which fails with a rejected credential and no obvious cause.

The API key is a powerful credential

An organisation admin key can change access across your whole organisation. The app keeps it in Forge's encrypted secret store rather than alongside the rest of its configuration, and masks it on screen — but treat it like any other admin credential: create it for this purpose, rotate it on your normal schedule, and use Disconnect when the app no longer needs it. It is listed as stored data in the privacy policy.

If the key is revoked, expires, or stops being an organisation admin key, the app notices the first time a call is rejected and marks the connection as disconnected rather than retrying against a dead credential.

Scheduled scan

Scans can run themselves — weekly, every two weeks or monthly, on the day and UTC hour you pick, reading either scope. The point is the rules: they act on the snapshot, and an admin should not have to remember to feed them. The panel previews the next three runs, and the Dashboard shows the next one beside the Scan button.

Saving never starts a scan. The first scheduled run waits for the next due moment — turning the schedule on at 16:00 does not surprise you with a scan at 16:01.
No daily option, deliberately. The freshness rules need comes from the live per-person check at action time, not from scanning more often; a daily walk of a large directory multiplies API cost and lock time for nothing.
Scans and rules take turns. Only one operation runs at a time. On an hour when both a scan and a rule are due, the scan goes first and the rule follows on the next hourly tick — landing on the snapshot the scan just wrote. Nothing is lost; a blocked firing simply retries.
Off by default. Off — scans start manually is the state every installation begins in.

Default inactivity threshold

The number of days after which an account counts as inactive, set on a slider from 7 to 365. It drives the dashboard's dormant-seat count and the default position of the Inactive For filter. Ninety days is a common starting point; a quarterly business rhythm may justify more.

Product licence groups

A read-only list of the groups the app believes grant each product, detected from your organisation when the screen opens. It is here to be read, not edited — it is what every Revoke Product Access and every licence-group rule acts on, so it is worth checking once. Groups your identity provider synchronises are badged, because membership changes there would be overwritten on the next sync.

Protected entities — the most important screen in the app

What each of the three lists protects

Protected Users protects named accounts. Protected Groups protects everyone in the group, and the scan now collects membership for the groups you name here even when they are not licence groups. Protected Domains protects by email domain — useful for a whole partner or contractor domain, with the caveat that Atlassian redacts the email address on many accounts, and a person whose email the API hides cannot be matched this way.

Add your admin accounts, including the one you are signed in as. Adding org-admins as a group works, and is the more durable choice because it keeps protecting new admins as they join.
Add service and integration accounts individually. They are inactive by definition, which makes them prime targets for exactly the wrong reason.
Add the individual accounts of anyone whose suspension would be expensive — executives, auditors, a regulator-facing team.
Prefer Protected Groups for anything that changes over time — a group keeps protecting people who join it later, where a list of accounts silently goes stale.

Tip

Fill this in before your first bulk action, not after your first incident. Protection is what makes an aggressive automation rule safe to enable.

Groups your identity provider owns

If a group is synchronised from Azure AD, Okta or another directory, this app will not touch it — it is not selectable when you build a rule, and it is skipped at execution time with the reason recorded. That is not caution for its own sake: the provider would put everyone back on its next sync, the rule would remove them again on its next run, and you would have an audit log full of successes that never stuck and a savings figure counting seats that never came back. Change membership of those groups where they are actually managed.