Changing Groups Changed Access to Projects

[AmandaFarris]

I'm here to admit defeat. I'm the newly appointed admin of our WF instance and was labeled the SME even though I'm still learning the platform. Our original setup was everyone was in one big Group as their home group, then they were sectioned off via Teams for their smaller ones. Since Group is a big reporting object, I thought it didn't make sense to lose (basically) this reporting function, so I created new groups and divvied everyone up accordingly.

When that happened, every user started having trouble looking at projects. They all received the error "You do not have sufficient privileges to access this project." and a Request Access button. There aren't any Group level permissions from what I can see, so I'm not sure why changing the Group would impact literally all of my users. 

Basically I want the Groups to be like Martech, Creative, & Strategy while having the Teams be like Designers, Production, Email, etc. Previously the Group was Marketing with the Teams being Creative, Martech, & Strategy. 

Please, oh wiser than me SMEs, help me out. Can I do it the way I want? What is the way forward here? 

-Sincerely, StressedAF

[Madalyn_Destafney]

Hi there so it seems all of the projects was shared with the original group you had, so you just need to adjust the project sharing on your projects to add the new groups and/or teams you created. You can do this in bulk by pulling in all the relevant projects in a project report (i.e. all the projects in xyz portfolios or programs, etc.) and then select all to bulk edit the project's sharing and add the new teams/groups of folks that need to have access to them.

[skyehansen]

If you didn't delete the original group, you should maybe put everyone back into it. People can be part of more than one group, so this is a nice workaround to restore permissions, while you are figuring things out.

Many objects in the system can be shared with a group. Before moving people out, you should check templates, projects, portfolios, programs, request queues, and reports and dashboards, at the very least. While it's true that projects MAY be shared with the group, it can make sense to attribute the sharing at a portfolio level in order that the projects just inherit those permissions.

Projects are also assigned to a group (usually the group that created the project, or the group listed on the project template).

It's just not wise to delete a group without considering all of these interactions. (If you just deleted the group this week, well... it's tuesday. I recommend you head over to the Preview Sandbox, and figure out what was previously shared with the group so you can recreate those links.)