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)
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:
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:
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:
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.
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!
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.
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.
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!
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:
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)
My Settings > Email Forwarding > Add new Email - new member’s org email was added
My Settings > Email Forwarding > Remove Email - old member’s email was removed
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…?).
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)
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.
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!
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”.
. Thank you for the clarification.
