Sys admin leaving // impact to reports and dashboards they built

We wish we had learned about this issue before we deployed WF, but for now (short of the "audit, copy, redeploy" method, which there never seems to be time for) we just renamed the accout that ex-Admin used "WF Admin" so we could leave everything in place.

Going forward we will try to use this "WF Admi" account for all admin-related work. But the "damage" is already done because myself and my manager did most of the deployment work and "own" most of the system objects. Turning my account off, for example, would make a huge mess. Will probably just become another generic "WF Admin" account when that happens.

I [thought I] put in an Idea Exchange in the past about being able to have certain objects "owned" by the system itself, rather than a specific person. Or owned by some concept of "all admins." Or just to easily transfer ownership of any object—ANY object—to another person, preferrably as a bulk edit. But I have never seen any movement in that direction

If I had to give any one piece of advice to someone new to Workfront: admins should have general accounts for themselves and their day-to-day work, and all admins should share a single, separate "Workfront Admin" account to create objects that are for system-level use or are otherwise "editing the system" as contrasted by "definitely a me-specific thing."

I have always used a service account for the ownership and management of Workfront objects. This service account also has it's own email address I can log in to. This allows us to use the same account for Fusion automations and as an admin, I'm not bombarded with emails and notifications.

@Kevin Quosig‚ Can you share the Innovation Lab link? I'll upvote.

We also have a non-person System Admin account. Here are a few more reasons why this is a good idea:

1. We have WF connected to Single Sign On for internal users and we also have a separate external user login. Having a non-SSO Admin account offers some level of protection in case there are issues with SSO. In fact, one time IT messed up SSO and locked it out, so I did have to log in as the System Admin and undo what IT did quickly!
2. Sometimes our external users need their passwords reset, and I have to log in as the System Admin to reset password for them. (For some reason, because of my own SSO account, it wouldn't let me reset other people's passwords.)

We recently had an admin leave. The majority of reports they created still work just fine after deactivation. The only ones with issues are the ones set to run with the access rights of that person.

I have a report with the filter of: Report >> Run as User ID [is not blank]

Then a prompt on that report of: Report >> Run as User ID

so I can pull any reports that are run with the access rights of any user I want to deactivate.

I actually have a whole "departing employee" dashboard with the following reports:

• Departing Employee Open Tasks
• Departing Employee Owned Active Projects
• Departing Employee Open Issues
• Departing Employee Reports (just to see how many reports they did create)
• Departing Employee Owned Portfolios
• Departing Employee Owned Program
• Departing Employee Owned Templates
• Reports set to Run with Users's ID
• Reports Sent with Run as User ID (these are reports that are set to auto-send)

The only other thing we ran into an issue with was calendars - can't report on them and will be an issue if the user who created them is deactivated. We got the following advice from Support:

"This article from the One site lists all the potential impacts of deactivating a user: About deactivating Workfront administrators and Plan license users.

One thing that's not listed here (but should be) is the impact to calendars. When a user is deactivated, any calendar reports they've created will begin to throw an error message. You also cannot change the owner of a Calendar. Therefore, the recommended workaround is to log in as the person that you want to designate as the new owner, and then create a copy of the calendar prior to deactivating the original owner. You can then delete the original calendar and use the copy moving forward."

For our case, I had to log in as the person leaving and make sure all their calendars (that were shared with anyone else) were also shared with me. Then go back to my own profile and copy those calendars and replace the original on any dashboards they were on. Then I logged back in as the person leaving and un-shared all of their calendars.