Automation rules
Turn a filter and an action into a scheduled rule, and roll it out without frightening anyone.
What a rule is. The same thing you just did by hand, on a schedule: a filter that selects people, an action to apply, and a time to run.
Why bother. Licence hygiene done once a year is a project everybody dreads. Done monthly by a rule, it is invisible.
Reclaim dormant Jira Software seats
What goes into a rule
- Name and description
- What it does and why. The next administrator reads this, not your filter settings.
- Scope
- Who the rule can touch: All users matching the condition, Users in selected group, or External users on the email domains you name.
- Action
- Remove user from selected access groups, Remove every product licence the user holds, or Change user status to deactivated. Groups your identity provider synchronises are locked out of the picker and badged Managed externally.
- Condition
- Last active more than N days ago, or Users who have never been active — which the rule processes first, because they are the safest.
- Then also add the affected users to a group
- Optional, and the most useful setting on the page. Everyone the rule acts on is added to a group you pick, so that group becomes the list of who was affected — and putting a licence back is a matter of removing them from it.
- Schedule
- Daily, Weekly with a day, Every 2 weeks, or Monthly with a day of the month, plus the hour in UTC. A day-of-month past the end of a short month clamps to the last day. The panel previews the next scheduled runs so you can see what you have actually asked for.
- Enabled
- A rule can exist and be switched off. New rules should start off.
The last look: every person is re-checked live
A rule's candidates come from the snapshot, and a snapshot is stale by construction — someone seen idle 80 days at scan time crosses the 90-day line by arithmetic alone, and someone seen idle two years may have come back yesterday. So before a rule touches anyone, it re-asks the live APIs about that person: still inactive past the threshold? Still in the scoped groups? Whoever came back since the scan, or left the scope, is left alone — and counted, by reason, in the result line on the rule's card: “3 left alone: the live check found them active or out of scope since the scan.”
- Every uncertain answer lands on leave this person alone: a read that fails skips the person with its own named reason, never a revocation on a guess.
- The one deliberate exception is a dead API key — that is a verdict about the run, not the person, so the run stops with a single clear message instead of dressing up as a green success with a thousand skips.
- Verification is always on for rules whose condition involves activity or group scope. There is no toggle to act unseen.
How to roll out a rule without breaking anything
- 1Build the filter on the Users tab first and read the names it selects. Actually read them.
- 2Create the rule with the same criteria, leave it disabled, and check the match count it reports.
- 3Click Run Now once. Then open the audit entry and read the per-user results.
- 4Only now enable the schedule.
- 5After the first scheduled run, read the audit log again. A result of
partialmeans some people failed, and the error text says why.
Each rule records its last run, the result — success, partial or failed — how many accounts it affected, and one sentence saying what shaped the outcome: how many the live check left alone, the snapshot's age when it mattered, or the reason a run refused to start. A rule that keeps returning partial is usually hitting accounts managed by another organisation.