Structure of our Groups

[GeraintJo]

A year into our use of Workfront and we're looking at how we've set up Groups.

We started with our own departments at the top level, but have had to add partner companies at that same level too.

We do that when we need to differentiate teams within those companies, or give them different layout templates etc.

I've checked a few other Q & A's but didn't find anything addressing this specifically.

Should we, as it's early days, create a top level 'Company Name' entry for our company in Groups.

We'd then have to move all our existing groups under that root item.

Other companies would continue to have their own 'root' groups at this top level too.

Hope that makes sense.

Any thoughts welcome about whether it's worth doing now before we get too far down the line, and likely grow the number of third parties we deal with.

Thanks

[Lyndsy-Denk]

I might not entirely follow what you're suggesting, but I've thought a lot about our own group structure, so I'll share what we've done.

We use the Companies field and Groups. Here's how it works:

• Companies: The vast majority of users fall under our actual company name. I create a new company when we have two or more external users belonging to the same company (for example, an agency). I can assign a company to a layout template. Additionally, the company settings provide added security so that external users see only what they're allowed to see.
• Groups: We keep groups as flat as possible because maintaining them can be a lot. There are two reasons I create a unique group or a subgroup: permissioning and reporting. I create a group when the set of users needs custom permissions to manage work, do work, or see work. I also create a group if we need to report on the users within, especially for a request queue. For example, I want to report on which group requests come in from.
• Teams can add some nuance for permissions, layout assignments, and reporting if you need it. Because there are additional function and features with Teams, I tend to start with groups. I do not create Teams that are parallel to Groups as it's redundant and causes confusion with my project managers.

I hope that helps!

[GeraintJo]

Thanks Lyndsy-Denk,

that's useful learning.

This is all stemming from wanting to better control who sees what statuses - and that is driven off groups.

So to be able to best segment who sees what, the groups have to be correctly structured,.

So it's currently impossible for us to restrict other companies, and to some degree departments (with groups) inside our organisation, from only seeing certain statuses.

Hence one particular challenge would be to create a company group for us - and move all department groups underneath it.

Sorry - that wasn't as simple to explain as I had hoped

I have to also admit the mechanism to restrict status to groups is overly complex - having to create them, then delete/hide for those groups they don't apply to.

[Lyndsy-Denk]

I see: it's about statuses. I've heard others recommend keeping statuses relatively simple because, as you've discovered, managing them is sometimes not easy. Defining clear governance around statuses can help reduce how often someone asks for a new status. For example, in our organization we use:

• Not started (PLN) for when a project owner is actively constructing the project.
• Requested (REQ) for when a project is constructed, but the planned start is a ways out.
• In progress (CUR) for active work.
• etc.

Additional statuses can be helpful to trigger approval flows. Otherwise, I discourage creating too many custom statuses. You may have already fought that battle.

[GeraintJo]

Yeah that's good advice.

But we do find it useful to trigger FUSIOn scenarios of statuses - so that is starting to drive up the numbers and leading to us wanting to hide statuses from certain groups.

Thanks