I would add, though ... that I *think* I'm able to add groups as members of Teams / Teams sites Sharepoint Groups. I say this because my oft repeated adage is the only tip that I would add, here ... next! 🙂 ( _just so that it's buried and doesn't look like I'm critiquing you ... because I'm totally not!!!_ :-) ... )
I would say that wherever it is possible, place 365 groups inside SharePoint groups. This then puts the access squarely in the hands of your IT / IT Admin/Security team to manage access requests. They already have a business process for handling user access requests, and placing this in their hands is a salient choice all around. Managing SharePoint groups in 2024 should not be someone's job, and at best it should be the odd admin having to give themselves access to something.
Remember, too, that it's entirely possible to create low-level M365 Security groups, and you could even set-up an automation to sort this all out. When someone makes a new communications site, let's call it " _financeforms_ " ( _later renamed to " _*_Finance Forms_* " and it's there just to fulfull a very obvious purpose. You can have a subscription monitoring for new sites, and that will create 3 `sp_financeforms` groups like so: - `sp_financeforms_owners` - `sp_financeforms_members` - `sp_financeforms_visitors` This might all seem like duplication, but managing M365 groups and their members is second nature for an IT team, or the person who's been assigned that work. Plus, you can often get away with just having a members and visitors group for most functions. The IT team certainly *won't* want to be managing SharePoint groups in addition to resources that already exist, plus the ' _SP Finance Forms Owners_ ' group will then be the group that is asked for authorisation to add additional staff to a team, anyway. 👍 But, yes, leaning into adding individual users to sites will always immediately create a job that someone will need to keep an eye on those memberships.
I like to try to think functionally with my groups, so that if I'm working with a business process, then I will have a Teams team that owns the process. So, here, there will be a Finance Teams team, and the *Members* of that teams team will in the be SharePoint Owners group of the Communications site. They'll also be in the SharePoint Members group ( _because SP can be fickle sometimes_ ), then that enables the whole team to manage the process adequately.
You mentioned that nobody should create custom permission levels, but how else do you prevent deletion of critical folders or files, either intentionally or unintentionally? What if you want to allow modification and adding of new files, but not deletion?
This was a general advice, but if you must absolutely have such permission level - you can create it. The problem with it is that it is local to a Site and if you need such custom permissions on many sites - they need to be set up manually on all sites. There are also ways to allow for file deletion but set up alerts or even retention policies. But again, if that is the requirement - then it is what it is.
We have the AD Security Group, plus the Microsoft 365 Group, both explained in the video. On top there are also SharePoint Groups at the site level. Could the later not also be well used for access to a specific folder on a site?
👉 If you want to learn more on this topic, check out this video as well: czcams.com/video/SumfCvtlYWI/video.htmlsi=rXrVJVPSoTHn_65h
Thank you for this excellent video. Very informative.
You are welcome, happy to hear you found it useful
Very helpful, thank you!
You are welcome!
Great tips for folks new tosite ownership or just making their way in administering a SharePoint Online instance.
I would add, though ... that I *think* I'm able to add groups as members of Teams / Teams sites Sharepoint Groups.
I say this because my oft repeated adage is the only tip that I would add, here ... next! 🙂
( _just so that it's buried and doesn't look like I'm critiquing you ... because I'm totally not!!!_ :-) ... )
I would say that wherever it is possible, place 365 groups inside SharePoint groups.
This then puts the access squarely in the hands of your IT / IT Admin/Security team to manage access requests. They already have a business process for handling user access requests, and placing this in their hands is a salient choice all around.
Managing SharePoint groups in 2024 should not be someone's job, and at best it should be the odd admin having to give themselves access to something.
Remember, too, that it's entirely possible to create low-level M365 Security groups, and you could even set-up an automation to sort this all out.
When someone makes a new communications site, let's call it " _financeforms_ " ( _later renamed to " _*_Finance Forms_* " and it's there just to fulfull a very obvious purpose.
You can have a subscription monitoring for new sites, and that will create 3 `sp_financeforms` groups like so:
- `sp_financeforms_owners`
- `sp_financeforms_members`
- `sp_financeforms_visitors`
This might all seem like duplication, but managing M365 groups and their members is second nature for an IT team, or the person who's been assigned that work. Plus, you can often get away with just having a members and visitors group for most functions.
The IT team certainly *won't* want to be managing SharePoint groups in addition to resources that already exist, plus the ' _SP Finance Forms Owners_ ' group will then be the group that is asked for authorisation to add additional staff to a team, anyway. 👍
But, yes, leaning into adding individual users to sites will always immediately create a job that someone will need to keep an eye on those memberships.
I like to try to think functionally with my groups, so that if I'm working with a business process, then I will have a Teams team that owns the process.
So, here, there will be a Finance Teams team, and the *Members* of that teams team will in the be SharePoint Owners group of the Communications site. They'll also be in the SharePoint Members group ( _because SP can be fickle sometimes_ ), then that enables the whole team to manage the process adequately.
Thank you!
You mentioned that nobody should create custom permission levels, but how else do you prevent deletion of critical folders or files, either intentionally or unintentionally? What if you want to allow modification and adding of new files, but not deletion?
This was a general advice, but if you must absolutely have such permission level - you can create it. The problem with it is that it is local to a Site and if you need such custom permissions on many sites - they need to be set up manually on all sites. There are also ways to allow for file deletion but set up alerts or even retention policies. But again, if that is the requirement - then it is what it is.
this is totally off topic to what was discussed in the video, but how did you get the twitter web part on your site?
Twitter Web part no longer works in SharePoint
We have the AD Security Group, plus the Microsoft 365 Group, both explained in the video. On top there are also SharePoint Groups at the site level. Could the later not also be well used for access to a specific folder on a site?
Yes, they can
What would your recommendation be for using lists as data source in powerapps, would the recommendation be to create a new site for the lists?
I am not familiar with Power Apps, so can't really answer this question.
Can you make a group as site owner. so you dont see all the administrators as owner but just the group.
thanks
Yes, you can create a Microsoft Entra ID Group, but it will only work on non-M365 Group sites (i.e., Comm Site).
@@SharePointMaven thank you!!!