Are you frustrated and exhausted living the 'Lone System Admin Life’? Don't miss our May 11 webinar, System Admin Essentials: Leveraging the Group Admin.
Cynthia Boon‚ former System Admin and current Workfront Customer Success Manager, and Kathy McLaughlin, Operations Specialist and Workfront Group Administrator at Mayo Clinic Alix School of Medicine, will come together to discuss how to determine when it’s time to add group administration, review common roles and responsibilities, share best practices for defining standard practices across groups, and more.
If you have Group Admins, we encourage you to bring them along to this webinar. And if you haven’t needed Group Administrators yet, come and learn about the things you will want to think about as you start introducing this role!
UPDATE: This session is now available on-demand. You can access the recording via the link below and a copy of the slides is attached. Thanks for all who joined us!
Giving this thread a nudge in case you missed it or haven't had a chance to register. (PS, if you cant' make it, register anyway and we'll send you the recording. Win-win!)
Thanks for presenting the concept and bringing in customer participants / subject matter experts.
(Not sure our organization is large enough to benefit from this.)
Right now I have some super users as ADMINS so they can search all and create - I can't seem to figure out what the right access level is for allowing them some control but need to now limit them because we've run into issues where some log in as others and make edits 😐
I came to this presentation hoping to ask how to give certain "super users" access to search all projects, create templates -- but NOT give them access to log in as other uses, delete templates and projects ... ?
I created a planner license (with less access) by unchecking the sys admin abilities. and i also went to layout templates for that group of people and restricted the view they see when then click on set up)
Hi! I saw this question yesterday, and we just ran out of time to answer it, but it's such an important puzzle that I also struggled to solve. (If you are able to visit the Ask The Expert session on Tuesday, I will have my Workfront instance up and we can talk through it live.)
My challenge was providing visibility to all projects in the system, but not allowing them to create new projects or deleting something that existed.
So, similar to Samantha, I created a custom Access Level based off the Plan license, and removed all of the capabilities to Delete, as well as unchecked the Create under Projects. Since they are Planners and not Sys Admins, they would not be able to Log In as others (unless you gave them Group Admin access).
Then, I created a Group with those specific users with this Access Level and then shared Companies/Portfolios with this group to allow them to "see" things, but not accidentally deleting something.
Then I created a Dashboard with Reports listing the Projects, Tasks, Calendars, etc. that I thought they actually needed. If they could access the things they needed from the Reports, then I knew that the sharing to Groups worked.
Love the idea of the separate Layout Template as well though!
It was a great pleasure presenting on this topic. Workfront can be structured in so many ways that will work for your organization!
During our session we were asked how our System Admin trains new Group Admins. Here is his response:
The “Training for Group Admins” is a self-directed training, shared 3-5 weeks before the virtual training.
The “Workfront Live Training from Sys Admin” is used during the virtual training. There are two tracks for the virtual training.
Track 1 ‚Äì This track is used when onboarding a Group Admin taking over for a group/process that is already in operations. In this track we utilize existing operational functions/processes in Workfront to test and train with. Allowing us to review and improve on existing processes and provide the new group admin with a deep dive of the specific functions they will need to know to support their group
Track 2 ‚Äì This track is used when the Group Admin is part of a core team implementing Workfront in their group/department/work unit. In this track we utilize the design/development activities to train the group admin by having them build out their custom forms/project templates/reports etc. under the guidance of the System admin. This way they have a hand in creating what they will eventually support.
There was a question about how to get buy-in from a department that is not invested, even though others are.
Getting buy-in is tough. It is like finding a needle in a haystack. It can be done but takes time and patience. Here are some thoughts . . .
There were questions about what is good number of Group Admins and how to structure the number of Group Admins in a department.
I do not know if there is an ideal number or ration, but look at what is the clearest division of work.
In the medical school, there are five teams (5 ‚Äì 10 employees) with people in each team on the three campuses. The team has processes that are unique to the team, as well as ones that are interrelated. In our case, having a Group Admin on each campus that knew their campus structure and was in their time zone was the clearest.
Another department has two main workflows ---- internal vs external work. They have Group Admins based on the workflow. Another department does not have many workflows and has one Group Admin. That person focuses on creating and supporting for reports/dashboards, request queues, and resource pools.
How do you find Group Admins?
As mentioned during the presentation you often find them in training sessions. They are the ones that ask the questions, are wondering if there is another way of doing something.
These are also the people who mention in meetings how they tried something different and how successful it was. They are always part of a group that volunteers to work on changes. They have a reputation for innovation. They have the mindset you need for your Group Admin.
There were questions about naming standards even for fields, creating custom fields and forms, and using metadata vs. naming conventions.
Each Group Admin can create custom fields. This has led to some duplicate fields, e.g., Additional Comments, Contact Phone. Our System Admin is in the process of identifying common fields, which will require clean-up. I am not clear if this will be a manual process or if it can be automated and what impact on data history will be.
During the presentation I shared when creating a new custom field there are two fields ‚Äì Label (the end user sees in views and reports) and Name (what is used for filters, and in report creation). Name contains the prefixed with our abbreviation (MCASOM) and Label is the name that will appear to the end user. For example, Matriculation Year would have in Label, “Matriculation Year” and Name would have “MCASOM Matriculation Year”
If we go back to previously created fields to update Name, then we do check the reports, views, etc. where this is used to verify what is being seen.
The abbreviations are an easy visual that everyone understands. Most departments don’t use their full department name ‚Äì too much to type. 😊 Personally, I found if everything has a prefix there is a natural sorting defaulting.