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