Jira Offboarding Workflow: Department Checklist and Setup Guide

Onboarding gets all the attention. There are templates, welcome kits, buddy programs, 90-day plans. A Jira offboarding workflow, meanwhile, is usually a Slack message to IT saying "can you disable Sarah's account?" — followed by three weeks of discovering things that were never turned off. (PPLX Software builds TeamOps, a Jira app for HR workflows — vendor on record. Every step below runs on native Jira.)

The problem compounds. Every incomplete offboarding leaves behind active credentials, lingering access to shared drives, API tokens nobody revoked, and knowledge that walked out the door without documentation. Security teams now treat ex-employee accounts as a distinct attack surface — SSO audit logs routinely surface active accounts for departed employees weeks after their last day.

IT and infrastructure

IT owns the largest chunk of offboarding tasks, and these are the most time-sensitive. Every hour of delay after an employee's last day is an hour of unnecessary access. In Jira, track all IT Tasks under the IT Component — run project = OFFB AND component = IT AND statusCategory != Done ORDER BY due ASC on the last day to confirm every task is closed before account disable proceeds.

• Disable SSO / IdP account (Okta, Azure AD, Google Workspace). This is step one because it cascades to everything behind SSO. Add a "blocks" issue link from the SSO-disable Task to the SaaS-revoke and credential-rotation Tasks — Jira links are informational by default, but they surface visibly in every linked issue so no assignee can miss the dependency, and a Jira Automation rule can check link status before allowing a Done transition if you need the sequence enforced.
• Revoke email access and set up forwarding if needed for handoff.
• Deactivate VPN credentials and remove device certificates.
• Revoke access to SaaS tools: Jira, Confluence, Slack, GitHub, Figma, AWS console, etc. Walk the SSO audit log if you are unsure what they accessed. When revoking Jira specifically, remove the user in Atlassian admin — deactivation alone leaves the account visible in issue history; full removal clears the assignee field and prevents the user from being re-added by an admin mistake.
• Rotate shared credentials the departing employee had access to. This includes shared service accounts, team passwords, and API keys stored in vaults.
• Collect hardware: laptop, monitors, access badges, YubiKeys, hotspot devices.
• Wipe or reimage returned devices before reassigning them.
• Remove from distribution groups, shared calendars, and mailing lists.

For engineering-specific offboarding (SSH keys, deploy access, code review ownership), see the Engineering Offboarding template.

HR and people operations

HR offboarding is less urgent than IT, but has legal deadlines attached to some of it.

• Process final payroll, including unused PTO payout where state or country law requires it. Set the sub-task due date to the applicable legal deadline, not the next regular payroll cycle — California requires same-day payment for involuntary terminations. The Jira task completion timestamp is the audit trail that the deadline was met. If you track leave in Jira, export the departing employee's balance before triggering account deactivation; some integrations lose leave history when the Atlassian account is removed.
• Terminate benefits and send COBRA notification (US) or equivalent continuation-of-coverage notice. Federal law gives the employer 30 days to notify the group plan administrator after the qualifying event; set the sub-task due date to last day + 29 days. If you run offboardings in both the US and elsewhere, add a cobra-applicable label to US Epic entries and filter your queue with project = OFFB AND labels = cobra-applicable AND statusCategory != Done to separate them from non-US offboardings.
• Update HRIS records with termination date, type (voluntary or involuntary), and rehire eligibility. If your HRIS syncs users to Jira via SCIM or a directory connector, verify the sync propagated the termination — some SCIM configurations provision on hire but do not deprovision on termination without a manual trigger. After updating the HRIS, confirm the user no longer appears in project = HR-OPS AND component = IT AND statusCategory != Done before closing this task.
• Conduct exit interview or send exit survey. Do not record responses in a Jira task comment — task comments are visible to all project members. Create a Confluence page in a restricted HR space before the session and link it to the offboarding Epic. The Jira task marks that the interview happened; the Confluence page holds the content, restricted to HR only.
• Retrieve company property not handled by IT: parking passes, company credit cards, branded materials. Create one sub-task per item with the asset identifier (serial number, card last-four) in the description. A single "retrieve company property" task is unauditable when a missing item surfaces months later.
• Send separation letter confirming last day, final pay date, and benefit continuation details. If severance is involved, track document state with a custom label sequence on the sub-task: drafted → sent → signed. Standard Jira workflow statuses (To Do / In Progress / Done) are too coarse for a document lifecycle — the task moves to Done only when signed, not when sent.
• Remove from org chart and internal directory. Check two places: the HRIS org chart and any Confluence org-chart pages maintained by hand. Search Confluence for the employee's full name as plain text before closing this task — manually authored pages embed names as text strings that do not update when the Atlassian account is deactivated.

Legal and compliance

Legal tasks are often overlooked because they involve paperwork that does not feel urgent. They are urgent — and the IT sequence depends on them. Disable accounts before legal hold is complete, and you may have destroyed evidence you were obligated to preserve.

• Confirm NDA and non-compete agreements are on file. Send a reminder of post-employment obligations to the departing employee.
• Issue IP assignment confirmation if applicable. Make sure any work product created during employment is documented as company-owned.
• Initiate litigation hold review. If the employee is involved in any pending or anticipated legal matter, preserve their email, files, and Confluence pages before disabling accounts. In Jira, add a legal-hold label to the offboarding Epic so IT can filter for it — project = OFFB AND labels = legal-hold — and hold account disable until Legal clears it.
• Process any stock option or equity paperwork, including exercise windows and vesting schedules.
• Confirm data retention compliance. In GDPR jurisdictions, employee data must be handled according to your retention policy, not just deleted on the spot. The Jira offboarding Epic and its child Tasks are themselves employee records — note that in the Epic description before archiving the project.

Security

Security overlaps with IT but deserves its own Component because these tasks require a different owner and a different due-date constraint. Use project = OFFB AND component = Security AND statusCategory != Done ORDER BY due ASC as the Security lead's working view. For a deeper treatment, read The Security Tasks Everyone Forgets During Offboarding.

• Revoke SSH keys from all servers and repositories. Log the revocation date in the Jira Task description — it becomes the audit record if a breach investigation later asks when access was closed.
• Invalidate personal access tokens and API keys across GitHub, Bitbucket, AWS, GCP, and any other service that issues long-lived tokens. Create one Task per service rather than one catch-all "revoke PATs" task — each needs a separate assignee and verified completion, and a single unchecked item in a bundled task is invisible.
• Remove from privileged access groups (admin roles, root access, database admin). Use the "is blocked by" link type to connect this to the IT SSO-disable Task — privileged group removal depends on SSO being cut first.
• Audit recent file downloads and data exports. The pattern of high-volume downloads in the two weeks before departure is common enough that DLP tools flag it routinely. Record the audit outcome in the Jira Task description — either "nothing anomalous" or a linked Confluence investigation note.
• Disable MFA recovery options tied to the employee's personal devices.

Manager and knowledge transfer

The manager is responsible for making sure the team does not lose institutional knowledge when someone leaves.

• Identify and reassign open Jira issues. Run assignee = "firstname.lastname" AND statusCategory != Done before the last day — not after, because the account deactivation breaks currentUser()-style queries. Use Jira's bulk-edit (select all → Actions → Assign) to move issues to the covering team member in one step.
• Conduct a knowledge transfer session. Have the departing employee create a Confluence page under the team space — current projects, recurring tasks (with Jira project keys), key contacts, and anything that only lives in their head. Link it from the offboarding Epic before the account is disabled.
• Transfer Confluence page ownership for pages they authored. In Confluence Cloud, go to the user's profile → Content → bulk-change page owner before the account is deactivated; after deactivation, orphaned pages require a site admin to reassign.
• Reassign 1:1 reports if the departing employee is a manager — update org structure in your HRIS and in any Confluence org chart pages that reference them.
• Update sprint capacity. Remove the departing employee from the active sprint, subtract their story points from the capacity figure, and flag any Tasks they held that are now unblocked by the reassignment.

Timing and structure summary

Setting up the Jira offboarding workflow

Timing is the failure point. The department checklists set the sequence; Jira enforces it by making each step a trackable deadline with an owner.

Project configuration

Use a company-managed project, not Jira Service Management. Service Management adds request types and customer portals suited to support queues; an internal offboarding workflow needs a board with assignees and due dates, not a ticket intake form. Simplify the issue type scheme to two: Epic and Task. Removing Story, Bug, and Sub-task from the scheme prevents classification confusion when HR is confirming an NDA, not reviewing a pull request. In Jira's hierarchy, Tasks are Level 2 children of the Epic — one Task per checklist item, each owned by the assigned department.

Create five Components in the project settings — IT, HR, Legal, Security, Manager — each with the default assignee from the timing table. When a Task's Component is set, Jira assigns it to that Component's default assignee automatically. No per-task manual assignment.

Epic structure per departure

One Epic per departing employee, named "Offboarding — [First Last] — [Last Day]". Set the Epic's start date five business days before the last day — that is when manager knowledge-transfer tasks should begin. Set the due date 30 days after the last day, because some legal and compliance tasks do not close until then.

Due-date scheme

Set each Task's due date relative to the Epic's last-day date. For Tasks created manually, set each sub-task's due date individually using the offsets below; the Automation rule in the next section calculates these automatically when you open the Epic.

• IT and Security: Last day. Access revocation has no grace period — every day of lingering credentials after departure is unnecessary exposure.
• HR: Last day + 3 business days. Final payroll, benefits termination, and HRIS updates have external deadlines but not the same urgency as live credentials.
• Legal: Last day + 5 business days. NDA confirmation and litigation-hold review often involve outside counsel and take time to route.
• Manager (knowledge transfer): Last day − 5 business days. KT completed before departure, not scrambled in the final afternoon.

Automation

Jira Cloud Automation can spawn the full Task set the moment a new offboarding Epic opens. Rule structure: trigger Issue created, condition Issue type = Epic AND Project = OFFB, then one Create issue action per checklist item with Issue Type = Task, parent set to the triggering Epic, the Component, and a due-date smart-value expression — {{issue.dueDate}} for last-day tasks, {{issue.dueDate.plusDays(3)}} for HR, {{issue.dueDate.plusDays(5)}} for Legal, {{issue.dueDate.minusDays(5)}} for manager KT. One rule, one trigger, 15–20 actions. Without it, whoever opens the Epic creates each Task manually every time someone leaves.

Add the actions in this order — Legal first, IT last. The litigation-hold task must exist before IT disables the account; creating it last means a fast IT admin can close the account before Legal has even opened the task.

Before relying on the rule in a real departure, test it against a staging instance or a separate sandbox project. Create a test Epic with due date 14 days out, confirm all sub-tasks appear within 30 seconds, and verify each due date matches the expected offset. The most common failure is a field mismatch: the smart value {{issue.dueDate}} references Jira's internal "Due date" field, but some company-managed project configurations expose it as "End date" — if the due-date offset actions produce blank dates instead of calculated ones, check which field name your project uses under Project Settings → Fields and update the smart-value token to match.

Closing the Epic automatically

Add a second rule: trigger All sub-issues moved to Done, condition Issue type = Epic AND project = OFFB, action Transition issue to Done. Without it the Epic stays open indefinitely after every task resolves — the manual close is the step that gets skipped. Chain a second action to Edit issue → Labels → add with the smart value closed-{{now.format("yyyy-MM-dd")}}. The label makes quarterly audit queries unambiguous: project = OFFB AND issuetype = Epic AND labels = "closed-2026-*" returns every completed offboarding in the year without relying on Jira's status-change history.

Saved filters for working visibility

Save these three as team-managed filters (accessible to project members without admin rights, under Filters → View all filters → Create filter):

• Today's IT/Security tasks: project = OFFB AND component in (IT, Security) AND due <= 0d AND statusCategory != Done ORDER BY due ASC — what IT checks on any departure day before disabling accounts.
• All active offboardings: project = OFFB AND issuetype = Epic AND statusCategory != Done ORDER BY due ASC — HR's primary view of open departures with the nearest last days first.
• Overdue by 2+ days: project = OFFB AND due < -2d AND statusCategory != Done ORDER BY due ASC — the escalation queue; anything here needs a manual follow-up before end of day.

Once you have built this out — the Epic-per-employee structure, the five Components with default assignees, and the due-date offsets per department — the General Offboarding template in TeamOps (PPLX Software, our app) ships that same structure pre-wired. It creates the per-department sub-tasks with the Component assignments and timing above already configured, so the automation step is already done. Free for teams up to 10.

Frequently asked questions

How do you revoke Jira access when someone leaves?

Disable the employee's SSO or identity-provider account first (Okta, Azure AD, Google Workspace), since most Jira access is granted through SSO and disabling it cascades. Then remove the user directly in Jira and Atlassian admin so any non-SSO access is closed, and walk the SSO audit log to confirm nothing was missed. Do this on or before the last day.

What Jira permissions does the offboarding Epic owner need?

Create Issues and Edit Issues in the offboarding project, plus Manage Components if you're configuring the department Components or their default assignees. The auto-assign behavior on each Component requires no extra permission — Jira resolves the default assignee when the Component field is set. Building the automation rule requires Manage Project or a Jira automation admin role in the project.

How do you offboard a Jira admin without losing site admin access?

Before disabling the account, open Atlassian Admin → Users and filter by "Site admin" role. If the departing employee appears there, promote a replacement to site admin first — not just project admin or Jira admin, which do not grant access to the Atlassian Admin panel. Have the replacement confirm they can reach Atlassian Admin under their own credentials before you disable the outgoing account. The same check applies to automation rules: if the departing employee built and owns the offboarding automation, verify the replacement has "Manage project" permission in the project before account disable, or the rules become uneditable until a site admin reassigns them.

Can I track onboarding and offboarding in the same Jira project?

Yes, but label them distinctly (onboarding vs offboarding Epic labels) and use Component filtering for each department's view. At scale the shared project blurs — IT sees access-grant tasks alongside revoke tasks in the same board column. The cleaner split is two projects (HR-ONBOARD and HR-OFFBOARD), each with its own Component set and automation rule. Use Jira issue links to cross-reference them when a departing employee's access list becomes the baseline for a replacement hire's provisioning.