Jira user offboarding is 8 actions. Here's how to make it easier.
When someone leaves a company, the Jira admin usually gets one instruction: remove them.
Simple enough. Except "remove them" in a mature Jira instance isn't one action, it's closer to eight and if you miss any of them, you end up with orphaned boards, broken filters, stale component leads, or worse, an ex-employee who still technically has access to projects they shouldn't.
We've handled offboarding across 300+ Jira implementations at Grandia Solutions . What looks like a single task from the outside is almost always a sequence. Here's what complete offboarding actually involves, and which steps are realistic to automate.
The full sequence: what complete offboarding actually requires
1. Remove from project roles
Every project where the user holds a Developer, QA, or custom role needs to be updated. In a small instance with five projects, this is annoying. In an instance with 80 projects, it's a serious time commitment — and it has to happen across all of them, not just the ones you remember.
2. Remove from Jira groups
Group membership controls what users can see and do at the instance level. Removing someone from a project role doesn't remove them from the groups that grant them access in the first place. Both steps are needed. Most manual offboarding processes miss one of them.
3. Reassign open issues
Issues assigned to a departing user don't reassign themselves. They sit there, assigned to someone who no longer exists in the system, until someone notices. In regulated environments, unassigned work isn't just a process gap it can be a compliance one.
4. Remove as component lead
If the user is set as a component lead on any project component, that assignment needs to be cleared or transferred. Component leads receive notifications and are used in some automation rules. A departed employee as component lead breaks both.
5. Transfer board ownership
Boards with the user as owner become admin-only to manage once the user is deactivated. If your teams are mid-sprint on a board that suddenly can't be edited without admin intervention, that's a disruption that shows up at the worst possible time.
6. Reassign or delete personal filters
Filters owned by the departing user that are shared across projects become effectively ownerless. Some organisations clean these up proactively; most find them months later when someone reports a broken dashboard.
7. Update default assignees
If the user is set as a default assignee on any project, new issues in that project will be unassigned the moment they are created silently, with no error. This one tends to surface in retrospectives, not in offboarding checklists.
8. Log and document the change
In any environment with access governance requirements, the offboarding needs a record: what was removed, when, by whom, and what the user had access to beforehand. Manual processes produce inconsistent records. Automated ones produce audit trails.
What native Jira automation can handle
Jira's built-in automation handles issue-level operations well. You can build a rule that reassigns open issues when a custom field on an offboarding request ticket changes — that's step 3, handled automatically.
You can transition an offboarding issue through a workflow and trigger notifications. You can schedule a rule to catch stale assignments. Steps that live at the issue level are genuinely automatable with native tools.
The problem is that six of the eight steps above don't live at the issue level. They live in the admin layer: project roles, group memberships, component leads, board ownership, default assignee settings. Native automation doesn't have scope to touch any of them. The automation actor simply doesn't have that access.
So most teams end up with a hybrid: a Jira rule that handles reassignment, and a manual checklist for everything else. The checklist gets run when someone remembers to run it, with whatever level of completeness the admin has time for that day.
What a fully automated offboarding sequence looks like
With Automation Actions Bundle for Jira, the admin-scope steps become actions available inside the rule editor, same trigger-condition-action structure, same audit log, same place your team already manages automation.
An offboarding rule triggered by an HR ticket moving to "Approved" can:
- Remove the user from all project roles across the instance
- Remove the user from relevant Jira groups
- Reassign their open issues to a defined fallback assignee or team lead
- Clear their component lead assignments
- Log each action with a timestamp for audit purposes
Steps 5, 6, and 7, board ownership, personal filters, and default assignees still benefit from a human review step, because the right resolution depends on context: who inherits the board, whether the filter is worth keeping, which project needs a new default. Those are judgment calls, not data operations.
But the bulk of the administrative work,the part that takes an experienced Jira admin 30 to 90 minutes per offboarding runs automatically, consistently, with a record.
Why this matters more as instances grow
In a 20-person company with 10 Jira projects, manual offboarding is manageable. Annoying, but manageable.
In a 200-person company with 60 projects, two departures per month, and a Jira admin who also manages three other tools it isn't.
The completeness of your offboarding process doesn't degrade because your admin is careless. The process depends on human memory and available time. Both run out.
Automation does not make those judgment calls for you. It just removes the eight manual steps that should not require judgment in the first place.
Was this helpful?
Thanks!
Alina Chyzh_Grandia Solutions
1 comment