Group Administrator Anomolies

[AndyWi]

Updated, see bold comments below Bear with me, this one is a list of three things we've found while using Group Administrators. 1. After setting up our groups with group administrators, we had a system administrator add a new system-wide status. We then had a group administrator attempt to manage that new status from the group settings, but the new system-wide status doesn't show up in the list of statuses that the group administrator can manage for their group. Only the system-wide statuses that existed before we assigned group administrators are showing. This is problematic and feels like a bug, can anyone speak to this? Based on Lilit's comments we Locked the system-wide status and sure enough it appeared in lists for the Group statuses. We then unlocked it and it remained on the Group status list with the ability to hide it. We tested that a user of that group could not see it in the list of statuses. We then unhid it on the Group list and confirmed it did appear as a Status option on a project. However, even though it is a system-wide status, because it was unlocked it was not available to attach an approval process. Conclusion - it doesn't solve the issue with different groups being able to use the statuses they want for both Project Status AND Approval Processes so we have to get various groups to agree to the system-wide status list if we want to be able to use Approval Processes. 2. When a PM goes to a project they manage they are able to attach system-wide approvals and create ad-hoc approvals on the project. However, when the group administrator of that same PMs group goes to the same project they do not even have the Approvals option available on the More tab (there are other items missing too, but for simplicity in this post let's focus on approvals). Why would this be? Is there an assumption that a Group Administrator wouldn't need to manage projects and doesn't need the full functionality? Sharing the project with the Group Admin did solve for this. 3. Real brain twister here. We set up the group project statuses as we wanted them using a combination of system-wide statuses and group created statuses. Then we went to create and approval process that would trigger when one of the group statuses was selected only to find that they couldn't be used. We went to Workfront Experience and searched on creating approval processes and sure enough, right there on the knowledge base page it says. " Only system-wide statuses are available to use. S tatuses that are available only for specific groups cannot be selected." We have Marketing, EPMO, and IT using the system and all need their specific statuses and their own approval processes driven from those and the system doesn't allow it? That seems counter intuitive and begs the question as to how the built in Group Administrator feature is adding value? Apologies for the long post but I'm scratching my head a lot right now... Andy Williams

[MirandaRa1]

Hey Andy, V interested in this one, as our groups expand and we will increasingly rely on Group Admins too. Miranda Rais

[Exp_-_LilitMk]

Hello, Andy and Miranda, Thank you for starting this thread about your experience working with groups. I'm glad to inform that currently we're actively working on enhancing the group administration capabilities and giving the group administrators more power to independently manage their groups/business units. You'll see continued improvements in this area over the coming months. As for the points that you highlighted, please find my comments below: System-wide statuses are supposed to appear for each group if they are locked. If you create a new system status but leave it unlocked, that status won't be copied to the groups. Can you please check if the specific status you're referring to is locked or not? The group administrator has full control over configuring the group, but the data pertaining to the group is not automatically shared with them. The group's projects need to be shared with the group administrator with corresponding permissions for them to have access to the project. You're right, we do have limitations restricting the usage of group-specific statuses in Approvals. We're aware that this creates challenges for our customers while managing their departmental processes, so we're planning to handle this in scope of group enhancements efforts I mentioned above. I'll be glad for a chance to discuss this topic and the direction we're taking in this area in more details over a call. If you're interested, please check out my availability and schedule a call using "https://calendly.com/lilitmkrtchyan/group-management" this link. Thank you again for sharing your thoughts about Group Administration capabilities and hope to make your experience much better very soon. Lilit Mkrtchyan

[JohnO_]

As am I. We've restructured our Groups here at BMS last year. We're using WF primarily within our multi-channel marketing organisation, but we're expanding to other organisations this year. And as we've tied some custom statuses to approvals processes...we'd love to see the ability to hide those statuses sooner than later. -j John J. O'Sullivan Bristol-Myers Squibb

[DebbieSc]

Hello! I am also interested in the expansion plans for Group Admins, as well as having a better understanding as to how the Group partitions function. We are encountering issues with new setups appearing in our environment, as many groups at our company are signing on to Workfront, and each group uses the tool very differently. And even with a governance committee (which we started several months ago), we are still struggling to ensure each group does not overstep and make changes that affect all of us. Thanks. Debbie Scalf BCBST

[AnthonyIm]

Hi, some things from what we learned via group admins... 1. The trick we do is create the new status, lock it so it is system wide, save, go back in, and unlock. And then we tell systems admin that they can hide it if they'd like. There is one exception and that will be for number 3 2. This sounds more like a layout template issue or access level issue than it does Group Admin. I've never had a group admin have different items on the More tab from other PMs or Executives that share its access level or layout template. 3. This has been a big thing ever since custom statuses came out: for approvals and for agile, you can only use system-wide status. For a tech side, it is because these items (teams and approval paths) are not tied to certain groups. For me, the value in Group Admins is that they can update schedules and layout templates for their group and they love they can use the Log In As feature for demos and to troubleshoot. (Although that is just at the group level and not subgroup. Have not found any value in subgroups and would right now recommend against using them). Anthony Imgrund FCB

[LeighHa]

Hi Debbie, Do you have a governance charter you would be willing to share with me? (removing anything proprietary to your company of course) We just rolled out Workfront and with many different areas using Workfront I have created a governance committee of system and group admins and need to create some type of charter for it. Thanks, Leigh Hasty

[StevenHi]

HI, I've also had significant issues with Group Admin rights and Group statuses. Group Admins really can't create all levels of new user accounts. They can only assign Access Levels that are less than or equal to their own Access Level and they must be a member of any Group or Team that they want to be able to assign to a user as a Home Group or Home Team. This is irritating and doesn't really give the Group Admin sufficient autonomy to fully manage their group. Other's have answered your questions well Andy but I do want to mention the following issues that I have an open ticket on with Customer Care: The best way I have found to create custom group statuses is to create ALL custom statuses in the "System Statuses" list in Setup, lock the new status for all groups, then, edit the new status and unlock the status. Locking it initially, pushes the new status out to all groups, then, unlocking it allows you to hide those custom statuses for any group. The reason it works best this way is because we have found a bug in charted reports (NOT grouped list reports) wherein you will see compound status labels on chart bars and wedges which combine statuses labels from different groups, separated by commas. This occurs if you have two custom statuses with the same name in different groups with different status keys OR if you rename any of the "Required" statuses in one group or another. This problem does not occur if you create a single iteration of a custom Status in the root System Statuses, and then hide it in the Group Settings for any group that does not need that particular status. I now avoid creating custom statuses within a group at all and I create all statuses in the root System Statuses and hide them for any group that does not need that status. Hope this is clear and helps. Regards, Steve Steven Hirsch