Structure of our Groups | Community
Skip to main content
G
GeraintJo
New Participant
June 23, 2025

Structure of our Groups

  • June 23, 2025
  • 1 reply
  • 506 views

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

 

1 reply

Lyndsy-Denk
Lyndsy-Denk
New Participant
June 30, 2025

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!

G
GeraintJoAuthor
New Participant
July 1, 2025

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
Lyndsy-Denk
New Participant
July 2, 2025

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.

Terms & ConditionsAccessibility statement

Loading footer...