What's your game plan for offboarding system administrators?

[----]

Hi there, does anybody have a sample project template/series of steps you go through when offboarding a system administrator and/or a user who owns a lot of objects within your instance? I'm thinking of situations such as reports owned by the offboarded user that may need to be set up with a "Run As" of an active user, recurring scheduled report sends which need to be set up again by another user, etc.

Essentially, a list of object types that may cease functioning once that user is deactivated. 

[lgaertner]

Hello,

we do not have such a plan yet, but perhaps we could use this thread to collect necessary steps.

As I was investigating the resource management functionalities of Workfront, which we did not really used before, I stumbled across the Bulk Assignment functionality in the Workload Balancer. I thought that this could really be helpful if a user is leaving the company, as it brings a lot of filter possibilites to assign, replace and unassign users.

Regards

Lars

[KatherineLa · Accepted solution]

We don't have anything formally documented, but here's some notes off the top of my head if someone wants to compile them. This could be a good blueprint for Workfront to offer someday maybe?

1. Log in 'as' the departing individual and look for:
   1. Calendars/Boards, which cannot be transferred. Depending on requirements, these may continue to work or may need to be rebuilt entirely
2. Review any configured integrations to ensure they are not running as this individual, primarily applicable to admin-users
   1. Oath, custom integrations, salesforce etc. 
3. Fusion - Review all connections and associated webhooks, and any scenarios where credentials/API keys may be in use to connect to off-platform systems. 
4. Develop a dashboard that summarizes "My" objects - portfolios, programs, projects, issues and tasks and use while logged in as the departing person to migrate regular project work. I have a stock dashboard for projects, issues and tasks and give it to the departing person's manager to start for my instance.
5. Reports - 'Run as User Name' is a column you can add to a report-report, check there as well as checking for automated scheduled reports as you noted
6. Check user-built filters, views, groupings - see if they need to be transferred to/shared with the user's manager or backfill
7. Check templates to see if the user is set as default assignment on any project details or task assignments
8. Check routing rules in request queues for the user being assigned either directly, or via membership in a Team. The Team part can be particularly invisible if the user happens to be the lone member of a team when they are disabled
9. Is the user hard-coded in any report filters? This one can be a pain to see if you have a lot of reports, but this text mode in a Report-report will give you a column that's at least searchable for the user's ID.

displayname=Filter
textmode=true
valuefield=filter:definition
valueformat=HTML
​

Let's see what other people come up with that I forgot to check next. Anyone else?

[-Jaye]

Thanks @KatherineLa (accidentally posted this discussion from my personal Adobe account, not my corporate one). Completely forgot about Calendars, and I believe this user in question has a number of them, so you've saved us there. I didn't realize filters, views, and groupings depended on the owner being active, so also appreciate that! I do have a "report report" with a column displaying the text mode, SO helpful in these situations or when making changes to other objects on the back end. 

This is a very comprehensive start and I'm grateful for it. Thank you! Interested to see if anyone else can add to it.

[skyehansen]

For non-system-admin leavers, I can't recommend the departing users dashboard enough, if you're a novice system admin. 

https://experienceleaguecommunities.adobe.com/t5/workfront-discussions/blueprint-released-offboardin...

Most seasoned admins already have their own versions of this dashboard, but for those that don't, it can be a great way to start the mental exercise of "what objects mean the most in my instance and how do I locate them". 

Our own game plan starts before the system admin leaves. In an ideal world, you have the ability to set up a "service account" -- a permanent account in workfront that isn't meant to depart -- and this account is the one that system admins would log into, to build their objects (so ideally the system admin's departure shouldn't impact anything). Your system admin might also have a project listing their usual functions as recurring tasks -- things like updating the company calendar every year, a list of fields that might need to be updated yearly, any regular system maintenance, and so on.

Lastly, you should have the following key bits of info handy for update.

* the name of the user that "owns" the instance (might need to be updated in setup) 

* contact info of any adobe contacts, such as account manager, customer success manager (reach out with your new admin's contact info)

* knowledge of how to log support cases, and who is authorized to do so (might need to be updated with Support)

[-Jaye]

Thanks @skyehansen (I'm the original poster - accidentally posted this discussion from my personal Adobe account). Like you said, I had my own version of this but that blueprint version was much more cohesive. Unfortunately due to SSO as well as corporate policy we are unable to create a "service account" - sure would make things a lot easier!

Your key bits at the end are also a great call-out and have got me thinking about documentation for my role so that I can more readily pass it off one day.