Specialised Training | SharePoint | Microsoft 365 | Nintex | LiveTiles | Azure | Project Server
Permissions is one of those areas of SharePoint which can take up a lot of the site owner’s time if they are not structured correctly in the first place.
In order to ensure permissions are easy to manage and are fully scalable going forward, I find it beneficial to group users by role, rather then what permissions they were assigned within a particular site. For example, you may create a “Sales Members” group within the Sales SharePoint site in order to assign contribute permissions to the sales team – this is what SharePoint suggests is the appropriate method.
The problem I see with this method is that if you then need to provide the sales team with a different permission level in another site, you may be tempted to create a new group containing the same set of users, when an appropriate group already exists. You may be asking yourself why someone would be tempted to create a new group in this scenario… one of the main reasons is that the term “members” is synonymous with the Contribute permission level, and therefore the site owner may not want to assign Read permissions to a group named “Sales Members“. The group name “Sales Members” suggests that it contains all of the people with contribute permissions to the Sales site – owners of other sites within the same site collection may not feel comfortable using a group which doesn’t describe its contents.
In this scenario, I would name this group “Sales Team”, as it describes the users it contains unambiguously, and it not directly related to a specific permission level, so you could easily use this group to assign read permissions to the entire Sales team without confusion.