Remove/Offboard/Deprovision a User from an Organization, and what to do beforehand

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 rules with “Only you can edit this rule” currently checked, uncheck the box or recreate the rule with another user as the rule 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:

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:




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

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




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.



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.

1 Like

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!

1 Like

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,


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!

1 Like

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,



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


Our new tool Offboarding report is ready to be used!


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.

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

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.


1 Like

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

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)

1 Like


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 and, both the real emails and Asana logins, and just change the passwords annually. I think that’s been mentioned elsewhere.

Good alternative!


1 Like

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!