Quick guide for structure: Companies, Portfolios, Programs, etc.

[CaitlinWh]

We are in the planning stages of a broad deployment of WF throughout our organization. I'm curious if there is a quick reference guide to detail the difference of various structures. I'm looking for best practices on how to implement:

- Companies

- Portfolios

- Programs

- Groups

- Etc.

I have some assumptions on what may make sense for our company. However, I'm trying to determine what roadblocks may be created by arranging our work in certain categories above. Specifically, I want to ensure we fully understand the impacts of access and reporting capabilities when we categorize projects in these areas. 

[Madalyn_Destafney · Accepted solution]

There is a lot to say about this topic, especially with sharing/access to each. In general, projects/work can be organized among Portfolios, Programs, Projects, Tasks/Issues (Portfolio as broadest in the hierarchy, task/issue as smallest). Some info on Portfolios here and you'll see on the left side more about the other objects in the hierarchy. These are how you organize work. Sharing/access is inherited from the top down, but you can break the permissions at any level. More on that here.

Companies, Groups, Teams (Companies as broadest category) are how you organize people in WF. You can only associate 1 company per object above, but they may be shared with multiple Groups/Teams/specific users.

Like you said, every instance is set up differently and you'll have to assess what's best for your org. Some people handle Groups as departments, and Teams as the people on various teams of those departments. 

If you found this helpful, please mark correct to help others! : )