Instance transition to larger group | Community
Skip to main content
J
JustinEn
Level 3
May 16, 2025

Instance transition to larger group

  • May 16, 2025
  • 2 replies
  • 530 views

Our marketing department structure was redone into 5 centers of excellence (COEs) about a year ago. Currently, only 1 of the COEs uses Workfront as their project management software. We are beginning a transition into all COEs having Workfront, as well as incorporating the Planning tool. I'm just curious if anyone has transitioned from one group using to several, with possible "groups" created to privatize certain projects specific to one COE. If so, what are the challenges you had and what can we think about when planning the license structure and user setup. 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

2 replies

Lyndsy-Denk
Community Advisor
Lyndsy-DenkCommunity Advisor
Community Advisor
May 19, 2025

We tried to go this direction, so I've spent a lot of time thinking and planning for it. Right now we have about half of Marketing and two non-Marketing groups actively using Workfront, which means we have use cases for both siloing work and cross-COE collaboration.

 

User setup

Groups are important for permissioning and offer the potential for group administration. Each COE has their own group. I try to keep my groups as flat as possible until I have a need for more nuanced permissions or reporting. This makes management and reporting easier.

Teams provide an additional layer for:

  • Layout template assigninment
  • Request queue routing
  • Filtering reports and Workload Balancer
  • More nuanced share permissions

 

Portfolios and programs

Each group managing projects has at least one portfolio. The portfolio Group matches the group that is primarily responsible for managing the work within.

Some groups have more than one portfolio due to the volume of work they manage. Naming conventions are helpful. Programs add an additional scaffold for reporting and sharing.

Some portfolios and programs are shared with other groups for cross-functional collaboration. For example, Group A owns Portfolio 1, but Groups B and C also own projects within the portfolio so we can easily report on major initiatives. Additionally, Groups B and C each have their own portfolios to stash work that is agnostic major initiatves.

In at least one case, I have a portfolio that includes a program with Share permissions stripped down so that it does not inherit permissions. This aims to keep the program super isolated for need-to-know projects.

 

Request queues

I have a portfolio called Request Queues. Each program is aligned to the COE that runs one or more request queues. Sometimes queue topics will ask for approvals from a member of a different COE. Sometimes topics will be routed to a central queue project for reporting purposes; or spread to different queue projects for easier triage.

 

We don't use Planning, but I think the above should give you something to noodle on.

    J
    JustinEnAuthor
    Level 3
    May 29, 2025

    Thanks for this info, definitely a lot to noodle on. I like how you mentioned making your groups "flat", that's going to be a big thing for us to implement correctly. Right now, we've had Workfront since about 2013, so there's a LOT of old groups/data/setups in there from my predecessors. Do you think it's beneficial to start a new group for our current COE that use it, just to "start fresh" and reset all permissions/access levels? Or just clean up what we have in existence and iterate on top of it?

    Lyndsy-Denk
    Community Advisor
    Lyndsy-DenkCommunity Advisor
    Community Advisor
    May 30, 2025

    I think it depends on what you need for historical data. When I overhauled our groups, I didn't know what I didn't know and just went for it. Fortunately no one came screaming in protest. That said, if you have a need to hold onto historical data, calculated custom fields can be super helpful. For example, we include fields on every request/issue that captures the requestors home group and home team at the time of submission. Personally, though, I think the need for historical data is not as big as some might think.

    One big lesson I learned: Ensure people have consistent access while you're making these changes; resist the urge to move users out of an old group or team until you've completed setup. When creating a new group, I need to account for parity of access so I don't disrupt operations. We use groups and sometimes teams to drive permissions, assign layouts, filter reports, and (teams only) route requests. For teams especially, I ensure the description of the team itemizes the team's purpose. I put users in both the old and new, then I make sure all the right objects have the new groups or teams aligned. Only then do I remove users from the old alignments.

    Additionally, I've learned that sometimes taking away visibility and permissions to some things can help with adoption and overall satisfaction. For example, we give Creatives a somewhat stripped down layout because they were overwhelmed by all the whiz-bang. Those with free licenses have even less in their layouts.

      Srinija_N
      Srinija_N
      Level 7
      May 20, 2025

      We have onboarded multiple groups(10) into Workfront instance, each with different ways/processes of working. We configured/streamlined everything separately as per each group's requirement.

      Not to bring siloes among each other, we created Request Queues/Templates/Groups/Portfolios with unique identification on their titles and sharing/Permissions accordingly.

        Terms & ConditionsAccessibility statement

        Loading footer...