Are you a Workfront System Administrator who "inherited" an existing instance of Workfront (vs. being part of the team from the start)? If so, would you be open to a quick, 30-minute chat? I'm part of a team at Workfront that creates programs that help customers better adopt and use Workfront, and my next big project is helping Admins who are taking over an existing instance.
I'm certain MANY of you have advice for those folks, and a list of "what I wish I had known." I'd love to hear it! Anything you share will be used to create resources, from templates, to checklists, to email programs, or in-app guidance to hopefully make a System Admin’s life easier.
You can see my availability and book time with me directly here. [INTERVIEW SLOTS ARE CURRENTLY FULL]
Thanks so much to anyone willing to share their time and experience, I genuinely appreciate it (as do our future System Admins!). Drop a comment below if you have questions.
EDIT: WOW! The response to this request has been swift and overwhelming. That in itself is a powerful data point in my research!
Since I won't be able to chat w/ you all, I wonder if you would be open to sharing your thoughts here in this thread? The two questions I'm most interested in are:
Topics help categorize Community content and increase your ability to discover relevant content.
I've been with our instance from the start, but I'm super excited to see the resources that come from this. I just forwarded the link for this thread to a bunch of people here at Thermo Fisher that I know have inherited instances.
Not necessarily a "wish I had known," but a "wish we were better at" is documenting some of the "why" we set things up with way we did. Sometimes even being here from the start I can't always remember why we went in a particular direction when I know we considered other options - if I were inheriting this instance I'd have no clue why something was done a particular way.
I've been with our instance from the start too, but am also excited to see what comes of this! We built up our instance without much Sys Admin documentation and I'm currently trying to catch up on that. WF One is a great resource, but to Heather's point, I need to document things that are specific to our instance and why it's set up that way.
WOW! The response to this request has been swift and overwhelming. That in itself is a powerful data point in my research!
I've currently closed the interview sign-up form, but wonder if those of you who have experienced this would be interested in sharing your thoughts here in this thread?
The two questions I'm most interested in are:
Thanks again, everyone. I'm blown away by your willingness to share!
Yep, I also inherited an instance.
What was your biggest challenge when taking over an existing instance?
‚Ä¢ Trying to guess the original implementers logic on how and why they chose their set-up.
‚Ä¢ I'm still cleaning up settings that were originally set up 5 years ago. It's a lot of work to try and figure out what you might break or lose by changing, streamlining, deleting: fields, reports, system statuses, etc. Extremely time consuming, which is why it keeps falling to the bottom of my to-do list.
What advice do you have for a System Admin who is taking over a new instance (especially if they've never done it before!)? What do you wish you had known?
‚Ä¢ Do as little customization as possible.
‚Ä¢ Try not make immediate changes without fully thinking though what will be impacted. Anyone ever delete an old custom form? 😲
‚Ä¢ Create a Sys Admin Request Queue and project(s) to house all your user change requests, system changes, additions, setups and the description on how, when, and why they were created. Log everything. You will forget why you did what you did.
‚Ä¢ Limit Sys Admin users, but utilize Group Admins and power users for support. Consider creating a recurring user group meeting to discuss pain points, consider changes, answer questions.
‚Ä¢ Seems small, but use the groups and teams in a consistent way for your company. I have groups to clean up that should have been teams, and then there are custom statuses were set for each. None of the original implementers are still with my company, so I'm left with trying to figure out what historical data we'll lose by fixing them.
‚Ä¢ An idea I wish I had considered (credit to @Kevin Quosig‚ Sys admin leaving // impact to reports and dashboards they built) was making a general Sys Admin user id, then use that user id for creating reports. That way if a sys admin leaves the company, the reports aren't forever tied to them.
‚Ä¢ Build as many reports as you can with wildcards and consider only having sys and/or group admins create reports. Make a description on how, when, and why the report was created mandatory.
‚Ä¢ Be an active Community member and attend as many webinars you can!