Remove/Offboard/Deprovision (or Pause) a User from an Organization, and what to do beforehand

[lpb]

Update 2026 01 24 from info in Administrator Certification course (and see also related 2025 06 18 update below), emphasis mine:

• When a user is deprovisioned, a private project containing their previously assigned tasks is automatically generated. This project is created to save all of the removed member’s tasks that were visible to the project owner selected during the removal process.
• During the removal process, you can choose another member to reassign this project to, ensuring pending tasks are managed. Super admins and admins in an organization can view private tasks after deprovisioning a user.

Update 2025 10 03 thanks to @Developer_Support which is addressed at the Asana API but contains pertinent info generally as well:

• What happens when I delete a user using the Asana API? - #6 by Developer_Support

Update 2025 06 18 thanks to @Nao_Kumazaki:

• When a user is deleted (deprovisioned) from the Admin Console, all tasks assigned to that user are collected into a project and assigned to the Organization Admin.*
  • If this project is assigned to a Super Admin, the Super Admin will automatically have access to all tasks within the project.*
  • If this project is assigned to a (regular) administrator, the administrator will only see tasks that they have access to.

Before you remove a user from your organization it’s good to take several steps to avoid possibly losing some item access (which could require Asana Support to restore).

I couldn’t find this information in one place, and since it’s hard to remember when only periodically needed, I decided to create this as a reference.

Before removing the user, consider carrying out these steps for any items you care about:

• Note: These steps are easiest to carry out if you log in with the credentials of the user-to-be-removed. This would be easier than using the Admin Console and Advanced Searches generally.

• In the user’s My Tasks, reassign all tasks you don’t want to become unassigned (a project of these will be created generally upon removal, but it’s safer and more orderly to be proactive)

• Consider running @Bastien_Siebman’s tool Offboarding report: a tool to manage an employee leaving which can help with a couple of the following steps

• If the user is the sole member of any private projects, or others all solely have comment-only access, add an existing user as a member with edit access to each such project

• If the user is the sole member of any non-public teams, add an existing user as a team member

• If the user created any custom fields or any rules with the “Only you can edit this …” checkbox checked, then uncheck the checkbox or recreate the custom field or rule with another user as the creator

  • Note: There’s no automated way to find rules created by a given user
  • Note: When you deprovision a rule’s creator for a rule that is editable by other members, the project owner will become the rule owner

• If the user created any portfolios that are private, add an existing user or make them public

• If the user created any goals that are private, add an existing user or make them public

• If the user created any Universal Reporting Dashboards that are used by others, duplicate them

Except as noted above, tasks, projects, teams, messages, files, comments (name remains but is not clickable, no profile image), portfolios, and goals the person created will remain intact.

After taking care of the above steps, follow the instructions below to actually remove (deprovision) the user from the organization:

https://asana.com/guide/help/organizations/basics#gl-free-depro

For a bit more information, see also “What Happens to a Deprovisioned Person’s Tasks?” about a private project that’s created with the removed user’s previously-assigned tasks by scrolling down from:

https://asana.com/guide/help/premium/admin-console#gl-deactivating

A separate but related concept, included here for completeness, is that you can Pause a member’s license (if you’re a paid organization (and not a paid division or workspace). More info is here:

https://help.asana.com/hc/en-us/articles/19370121344795-Pause-a-member-s-license

Thanks,

Larry

[AndySaavedra]

Thanks for sharing this post, Larry! Is it safe to assume that we would include dashboards as well?

[lpb]

Good point, @AndySaavedra; I added a bullet for that.

Thanks,

Larry

[lpb]

@Forum-team,

Can you help? My large ($50M), long-term-Asana-using client who is really struggling with this:

Their IT Manager is leaving the organization after nearly six years of active Asana use, having created tons of custom fields, projects, etc. where she is the owner.

I shared my post here which they very much appreciated and are following these recommendations as much as possible but are quite hamstrung by lack of product functionality and lack of Support assistance (which I had hoped would be attainable).

They contacted Support with these two requests and came up empty:

• Provide a list showing any custom fields this person created, ideally those specifically where “only can update the custom field” is checked. (I believe @Bastien_Siebman’s custom field explorer can help with the former but not sure if his report provides the latter.)
• Provide a list of all projects (public and private) owned by this person (perhaps Bastien’s Overview offers Owner?)

Do you think there’s any possibility for more assistance for this client with the above or any of the other items on my deprovisioning list? If so, thanks, and I’ll provide the details in DM.

My client strongly encourages Asana to address this gap in the product making offboarding painful.

Thanks,

Larry

[Bastien_Siebman]

I am almost done with my tool “Offboarding report”: you give it the email of the person, date they leave, and the tool gives you:

• tasks assigned after the date
• projects/portfolios/goals owned
• custom fields they created (that’s the best I could do, unless I overlooked the API)

If it could help I can deploy it asap and let you have a look.

You are correct, my other tools might be able to help, but the latest tool will be easier to use I think.

[Marie]

Hi @lpb, I’m afraid there isn’t much I can do to help. Our support team isn’t equipped to pull the data your customer has requested, hence why they haven’t received a positive answer.

I’ve gone ahead and filed a VoC task in the hope of highlighting this issue to our team as they think about upcoming developments, but that won’t be any help with this specific case!

[lpb]

Thanks, @Bastien_Siebman, It would be great if you will be able to deploy it in the next week or two so I could try it out then; thanks!

And thanks, @Marie, for filing the VoC task because my client wanted to make sure the feedback was considered for the future too.

Much appreciated,

Larry

[Austin_Crawford]

Hey @lpb, I am fairly new to Asana and I am in the process of onboarding a team of 25; I am aware of one individual who will be leaving the company in the coming months, so this checklist will be super useful for me.

You mentioned that this process is much easier if done from the account to be deactivated; do you typically recommend admins requiring all Asana account passwords to be given and then stored, or should only the IT admin ask and hold these? Asking for passwords will be a much easier process now compared to later, but I am unsure what the best ownership and storage practice would be.

Thanks again for the list!

[lpb]

I’m glad this will be helpful, @Austin_Crawford!

One clarification: I actually didn’t mean what I think you took away regarding credentials. I was referring to the period after the employee’s last day. Reset their password (so they can’t continue to login) and login as them (so you can more easily carry out the cleanup). I wasn’t suggesting to hold active users’ passwords.

Hope that makes sense,

Larry

[Austin_Crawford]

Ah, this makes much more sense . Thank you for the clarification.

[Bastien_Siebman]

Our new tool Offboarding report is ready to be used!

[Marie]

Hi all, i just wanted to add an important note about something I just learned today:

When a user is deprovisioned via the Admin console, all tasks assigned to them are gathered into a project which is assigned to the Organisation Admin.

One important thing to note:

• If this project is assigned to a Super Admin, they will automatically have access to all tasks in this project
• If this project is assigned to a (regular) Admin, they will only see tasks they originally had access to.

[Richard_Sather]

Hi Larry @lpb ! I just stumbled on your original post, very useful!

@lpb

Their IT Manager is leaving the organization after nearly six years of active Asana use, having created tons of custom fields, projects, etc. where she is the owner.

I recently faced a similar situation which I would like to share, as I’m interested in your take.

Bit of back story, the departing member had created numerous projects and owned countless rules so in order to avoid a ‘mass-pause’ (and other unwanted consequences), we decided the best way forward was to essentially have the onboarding member ‘adopt’ the departing member’s Asana account, since they were essentially replacing the exact role within the company.

The method to ‘adopt’ each other’s Asana account was fairly simple but required the departing member’s credentials to login into their account and do the following:

1. My settings > Profile > ‘Your full name’ was changed to the new onboarding member’s name (job title, profile photo and other info were also changed accordingly)
2. My Settings > Email Forwarding > Add new Email - new member’s org email was added
3. My Settings > Email Forwarding > Remove Email - old member’s email was removed
4. My Settings > Account > Password - new member set their own password

Pros: we avoided the mass-pause, and the adoption/account transfer was painless!
Cons: any past references to the departed member, anywhere in Asana (mentions, comments, activity log etc) now show the newly onboarded member’s name instead, as expected. However, this was regarded as a minor set back since it was apparent to all org members that after X date (when the new member took over) it was clear which person was actually responsible for the said actions before and after this date.

Note: the above also procedure required that the departing member did not have any other organisations or workspaces associated to their Asana account, otherwise this would have not been so painless (or even possible without disassociating their other emails…?).

Looking forward to your thoughts on this method.

Richard

[Richard_Sather]

@Marie

When a user is deprovisioned via the Admin console, all tasks assigned to them are gathered into a project which is assigned to the Organisation Admin.

Hi @Marie . I’m afraid this statement isn’t entirely accurate…

In an Organization, when an Admin uses the Admin console to ‘Remove’ a user, they are given a choice to assign the ownership of the private project that Asana will automatically generate to any member, even guests! (Admins included of course, but not just admins)

[lpb]

@Richard_Sather,

I think that can be a good option to consider, but not right for everyone. In your case, it sounds like the right move. I can’t think of any shortcomings besides what you mentioned. I wonder if any experts here can think of any gotchas we’re missing? Or maybe worth running my someone in Asana User Ops or Support?

Note that I know some orgs use this same idea in an even more explicit, formal way by using evergreen roles for users, not actual individuals. For example, if you have an annually changing Board and want continuity, just have the email be board-president@company.com and board-vp@company.com, both the real emails and Asana logins, and just change the passwords annually. I think that’s been mentioned elsewhere.

Good alternative!

Larry

[Bastien_Siebman]

The main cons I see are:

• the new member gets access to potentially private tasks the departing member created
• in terms of liability, I am not sure how a lawyer would like this, if a mistake was made in Asana and someone is now managing the accounts

Otherwise interesting idea!

[AuntJan]

Thanks @lpb! This is a great list that I will be distributing to my teammates.

In the main list, I see that you call out Rules that are marked as “Only you can edit this rule”.

Should Fields that are maked as “Only you can edit this field’s settings” also be in this main list?

Thanks so much! janice

[lpb]

Great catch, @AuntJan; I’ve made the update to the OP.

Thanks,

Larry

[Tiffany_Schmid]

Hi, is there a way to deprovision a guest user without sending them an email notification?
My user is a guest who collaborated on a project a while ago. I would like to remove them from my organization, but they aren’t currently on a team. The only way I’ve found to deprovision them if they aren’t currently on a team is to:
1.) add them to a ‘dummy’ team (which sends them an email saying they were added)
2.) remove them from the team
3.) deprovision them

I would prefer this person not to get an email. So unprofessional and time-wasting to have to send an explanatory email to them.

Surely there should be an easier way to simply delete a guest. What am I missing?
Thanks!

[lpb]

I’m not positive about the answer to this. Perhaps someone else knows and will reply, or you could create a support ticket: go to Asana Support - Help Center • Asana > click the chat icon at the bottom right > type “speak to an agent” > click “Yes” > click “Something Else” > click “Create a support ticket”.