Can someone explain Inherited Permissions? And other access issues.

[JillAc]

I can't understand how inherited permissions work in the real world and am hoping for an explanation using real world examples because I can't figure out the Help articles.

I just recently after 2 years finally understand how to use Groups to give access to Queues, and am trying to reconfigure Queue access based on that knowledge. I come to the realization that i have set up Groups badly, giving everyone the Default Group desgination and using that so that everyone would have access to everything, and now that is regrettable.

We are now adding a whole lot of new internal company requesters and to my horror, all these new people have access to all the reports. I think it's because of the Company designation and I'm hoping I can fix this by removing inherited permissions. Is there a way to mass change Report sharing?

Since we don't assign tasks or requests to Teams I am coming to the conclusion that Teams don't matter to me other than to sort and filter people in reports. Am I missing something about Teams I should know where they are used for access designations?

Any other advice on best practices on setting up people and objects would be appreciated.

This is a morass I am hoping to tackle.

Thanks!

[TiaCa]

Hi Jill,

One way to cut off the Requestors from seeing everything is by reducing their permission levels. Unless your requestors need to do more than making a request, add documents and participate in Updates, they shouldn't be able to anything else. Also, you could look at their Layout template and make adjustments there so they can't wander around.

I like to think of teams as very specific set up people (maybe even across groups) that perform a specific function or role. The group is a level up. Unless you want to segment your user groups/teams, meaning they can't participate in each others work at all, I'd recommend you only have one Company (could be your business's name). In our set up, my Teams are our known teams and individuals who have a specific function, like answer a request q. We have several q's that encompass people from across teams or are only part of a larger team or group. Our Groups are more like a Department or Division or Center.

Hope this helps at least a little.

Tia

[CalvinFold]

We use Groups the same way an IT admin would use a permission group—a set of people that have a certain set of access in aggregate. So we use groups to assign access to reports, templates, etc. We only create a new group when a unique circumstance of permissions comes up.

Teams we use to manage receipients of requests from our requests queue, and to assign tasks to a pool of people when we can't assing an individual (though this may be changing soon because it causes complications). We don't allow users other than SysAdmins to create teams because of the chaos/confusion; wish we could force it, but we have to police it instead.

We use Company for two main purposes:

1. Users are assigned to a company so we can keep certain groups away from each other's projects…a way to create separate instances. Such as when we first make an aquisition, or perhaps someone wants to piggyback on our account only to use Workfron Proof, etc.
2. Companies on a project reflect a rate sheet. We have a number of rates we cross-charge at depending on the circumstances, and this is how we set the rates.

I used to use "share system wide," now I never do. Sharing is now very explicit.

Layout Templates also become part of security/permissions in as much as what parts of the interface (UI elements, fields, dashboards, etc.) we expose.

And…I have no idea how perfect or "as intended" this all is…been learning this as I go from Support, WSAs, or this Community. The rest I cobble-together because we already know we dont use WF "as intended/designed" so have to forge our own solutions.