Project Management Tool Offboarding for Startups: What Jira, Linear, and Asana Don't Tell You

When someone leaves your startup, removing their project management tool access feels like a formality — you click deactivate, their name disappears from the workspace, done. But Jira, Linear, and Asana all have access and data problems that survive that click. Automation rules keep firing under their account. API tokens they created still carry write access to your repositories. Tasks nobody reassigned sit unowned in backlogs. Private boards they managed may become inaccessible. This guide covers what actually stays active after deactivation and gives you a tool-by-tool protocol to close the gaps.

Why PM Tool Offboarding Gets Missed

Most startup founders think of project management tools as productivity software, not access-security software. That framing means PM offboarding gets included on the checklist but not investigated. You know to remove the Slack seat and the Google Workspace account. Project management tools feel lower stakes — they hold your tasks, not your customer data or your bank account.

That's wrong for three reasons. First, PM tools often have direct integrations into your GitHub, GitLab, or Bitbucket repositories. Linear, Jira, and Asana all support repo-level integrations that let the tool trigger actions in your codebase. The credentials authorizing those integrations may be tied to a departing employee's account. Second, PM tools hold your roadmap, your sprint history, your incident logs, and your internal strategy — data a departing employee could export or screenshot before you deactivate them. Third, automation rules in Jira and Asana can run indefinitely under a deactivated account in certain configurations, creating zombie workflows that affect your team long after the person is gone.

Jira: What Survives After You Deactivate a User

Atlassian deactivating a Jira account removes the user's ability to log in. It does not clean up everything else.

Automation rules keep running. Jira automation rules created by the departing user remain active after their account is deactivated. If they built a rule that auto-assigns issues, sends Slack notifications, or updates Sprint fields, those rules keep firing — attributed to the deactivated account. You won't see an error; the automation just runs without a valid owner. To find these: go to Project Settings → Automation, filter by author. Reassign or delete rules owned by the departed user.

Personal API tokens still exist. If the employee generated a Jira API token (used for integrations, CI/CD pipelines, or local automation scripts), deactivating their Jira account does not revoke that token. An API token authenticated against a deactivated user still returns a 200 if the token itself wasn't revoked before account deactivation. To fix this: before deactivating the account, go to Atlassian account settings → Security → API tokens and revoke all tokens. Do this before deactivation, not after — you lose access to the account's API token list once the Atlassian account is deactivated.

Service project agents persist. In Jira Service Management, agents assigned to queues stay assigned after deactivation. Incoming customer requests may route to a deactivated agent with nobody triaging them. Audit your JSM queue configurations and reassign agent roles before the last day.

Linear: GitHub Integrations and API Keys That Outlast the Employee

Linear has a cleaner deactivation model than Jira — removing a member immediately blocks their access. But two access surfaces survive.

GitHub and GitLab integration tokens. Linear's GitHub integration syncs issues with pull requests. This integration is often authorized using a personal access token (PAT) belonging to whoever set it up. If your departing engineer configured the GitHub↔Linear sync with their own GitHub PAT, removing them from Linear does not revoke that token. The integration keeps working until the token expires or is explicitly revoked in GitHub. When your senior dev leaves: check Settings → Integrations → GitHub in Linear, look at which account authorized the integration, then rotate the token in GitHub under that account.

API keys and webhooks. Linear supports personal API keys for external integrations — dashboards, Zapier automations, home-built tooling. Like Jira, removing the member from the workspace does not revoke their API keys. Go to Linear Settings → API → Access Tokens. You'll need to audit this while the account is still active, or immediately after removal if your plan exposes an admin view of tokens. Any webhooks configured using their credentials should be reauthorized under a shared service account or a remaining team member.

Issue assignment. Linear does not automatically reassign issues when a member is removed. Their issues stay in the backlog, technically unowned, until a team member manually picks them up or your team admin bulk-reassigns. Do a filtered search (Assignee = departing person) and reassign or triage before removal.

Asana: Guest Members, Service Accounts, and Shared Dashboards

Asana's deactivation model has a quirk: removing a full member converts them to a guest if they're still listed on projects, not a complete removal. This matters.

Guests can still view tasks. If you remove a departing employee from your Asana workspace but forget to remove them from individual projects, Asana may leave them as a project guest. Guests retain read access to every task in that project. The fix: before deactivating the account, remove them explicitly from every project they're listed on. Asana's member profile page lists all their memberships — use that to do a complete sweep.

Reporting dashboards become headless. Asana's reporting views (Portfolios, Goals, and Dashboards) that the departing employee owned may become unviewable or throw errors once their account is deactivated. If they were the Portfolio owner, reassign portfolio ownership before their last day. Portfolios → click the Portfolio → Settings → Members → transfer ownership to a current team member.

Rules they created. Like Jira, Asana's Rules (automations) created by a departing user persist after deactivation. Go to each project they managed → Customize → Rules, and check for rules with their name as creator. Transfer or delete them.

Service account workaround. If your team relies on shared dashboards or automations that need to outlast individual employees, this is the prompt to move those integrations to a service account — a dedicated non-human Asana member tied to a role-based email (e.g., ops@yourcompany.com) rather than an individual's account. Connections tied to service accounts don't break when people leave.

The Private Board Problem: Data You Can't See After They're Gone

All three tools support private projects or boards — spaces only the owner and explicitly invited members can see. When the owner leaves and their account is deactivated, those private spaces don't automatically transfer to an admin. They go dark.

In Jira, a project with restricted permissions set by the departing user may become inaccessible if no other admin has view permissions configured. To recover it, a Jira admin can grant themselves access through the Jira admin panel, but this requires knowing the project exists. If the project was completely private and not listed in your project directory, you may not know to look.

In Asana, private projects disappear from search and browse when the owner is removed. An Asana super admin can still find them through the admin console's member management view, but this requires proactive action before or shortly after the account is deactivated.

In Linear, private teams (teams with specific member lists) have similar behavior — removing the last admin from a team can lock your other team members out of the team's issues.

The operational fix: before the last day, ask the departing person to either make their private projects visible to a second admin, or export and document them. This is uncomfortable but necessary. Make it part of your standard offboarding conversation, framed as continuity, not suspicion.

The PM Tool Offboarding Protocol (Do This Before Their Last Day)

Run these steps in order. Items marked "before deactivation" cannot be done after you remove the account.

For Jira:

1. Go to the user's profile → list all projects they manage or own.
2. Reassign project lead role on any projects they lead (Project Settings → Details → Project Lead).
3. Go to Project Settings → Automation for each project they managed, filter by their name, and reassign or delete their automations.
4. If they use Jira Service Management, reassign their agent queues.
5. Before deactivation: Log into their Atlassian account settings and revoke all API tokens, or ask them to do it in your presence.
6. Deactivate the Atlassian account (Atlassian admin console → User management → Deactivate).

For Linear:

1. Search for all issues assigned to them (Assignee filter), bulk-reassign to a team member or unassign.
2. Check Settings → Integrations → GitHub/GitLab — note which account authorized the integration.
3. Go to GitHub/GitLab and revoke the PAT tied to the Linear integration if it belongs to the departing user.
4. Before removal: Check their API keys in Linear Settings → API (if your plan shows this). Note any active keys.
5. Remove the member from the workspace.

For Asana:

1. Open their member profile, list all project memberships.
2. Reassign Portfolio ownership for any Portfolios they owned.
3. In each of their projects, go to Customize → Rules and identify rules they created.
4. Remove them from all projects explicitly (not just workspace).
5. Check for private projects via Asana admin console.
6. Deactivate the account from admin settings.

What Survives Deactivation: Tool Comparison

This table is a snapshot. Tool behavior changes with plan tier and product updates — verify in your admin settings at offboarding time.

PM tools are part of a larger access cleanup problem. If you're running this protocol manually every time someone leaves, see our guides on building a role-based access template and running a quarterly access review — those give you the upstream infrastructure that makes each individual offboarding faster.

Frequently Asked Questions

What happens to Jira tasks when a user is deactivated? Jira tasks assigned to a deactivated user remain in place — the task is not deleted, but the assignee field shows the deactivated user's name (often greyed out). The tasks still appear in the project board and backlog. You need to manually reassign or triage them, either before deactivation using bulk-edit (Project → Issues → filter by Assignee → select all → reassign), or after deactivation using the same filter with the deactivated user's name.

Does deactivating a user in Linear remove their GitHub integration access? No. Linear's GitHub integration is authorized via a personal access token (PAT) belonging to whoever set it up. Removing that person from the Linear workspace does not revoke the PAT. You need to go to GitHub → Settings → Developer Settings → Personal Access Tokens and revoke the token tied to the integration directly. Check who authorized the integration under Linear's Settings → Integrations first so you know whose GitHub account to look in.

Can a deactivated Asana user still access projects? If they were a full member and you remove them from the workspace, they lose login access. However, if they were a guest on individual projects and you only removed their full membership, Asana may retain their guest access on those projects. The safest approach: before deactivating the account, explicitly remove them from every project they're a member of using their profile page's membership list, then deactivate the workspace account.

Close the PM Tool Gap Before Someone Walks Out the Door

Optserv tracks every tool an employee has access to — including PM tools — from the day they join. When someone leaves, the offboarding flow includes PM tool revocation steps with the automation and API token checks specific to each tool. You don't rely on memory or a manual checklist; the system knows who has access to what, and it walks you through the revocation in the right order. Start for free at app.optserv.ai — no IT team required.

Sources

• Atlassian documentation: Deactivate or reactivate a user's account (Jira Cloud)
• Atlassian documentation: Create an API token for your Atlassian account
• Linear documentation: Members and roles, API key management
• Asana Help: Remove a member from a workspace, project guest access behavior
• Asana Help: Portfolios ownership and admin console access