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

[OliviaMi]

Hi All - we have a system admin that has left the company. I don't want to deactivate her yet because I'm worried about the reporting/dashboards. She has a lot of reports/dashboards she is the owner of. Several reports/dashboards are run "with access rights of her".... what would happen if we deactivate her? Would this all become broken? Thank you!

[CalvinFold]

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."

[RandyRoberts]

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.

[ElenaDooley]

@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.)

[CalvinFold]

I couldn't find one I created, or even one I voted for, in my Innovation Lab lists so…I found this one:

https://one.workfront.com/s/idea/0870z000000PSa2AAG/detail

I plan to leave my comment in a moment.

[Heather_Kulbacki]

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.

[Madalyn_Destafney]

Hi Heather! I just started a new gig and all the calendars I made in my old company's instance get that error, and I was confused bc I had made sure none of my reports with 'run as user' still had my name. I updated those, didn't think there would be this impact they're now running into with my calendars even when sharing the calendars. Yikes. So there is no way to change the owner or have it 'run as' on a calendar to change it to someone else? So new owner has to copy my calendars?

[Madalyn_Destafney]

@Heather_Kulbacki or to make things easier maybe they just leave me in the system but change my pw (I'm not on SSO but they are) so I can't get in but it keeps the calendars in tact...thoughts?

[Heather_Kulbacki]

Hi @Madalyn_Destafney, congrats on the new gig, I also just started a new gig! For the last couple of admins that left my old instance, I did go ahead and make new calendars for any they created - if those had been shared with users.

But for all the stuff I created I did suggest they leave me in the system and just change my password since, same as Admin I wasn't required to use SSO. And by this point, I had created SO much under my profile. And maybe even change the name on my profile and continue to use that profile any time they want to create something that might be affected by a future admin leaving.

[Madalyn_Destafney]

Thanks, Heather. Congrats on your new gig, too! 
I did all that copying/logging in as/etc when I took over my last instance, was hoping there was a better way. For now I just had them reactivate me. Oy! WF needs a better way for transferring calendar ownership.