 says I'm looking for help with provisioning SharePoint access at a group team level and it just doesn't seem to work. I want to be able to provide a group of people access rather than having to add every individual to a doc or site and send them a link. Any tips are the easiest and the best way to do this. I would have thought that adding groups via the manage access advanced menu would provide the relevant access but this has not worked i.e. when I have added the relevant group as visitors to provide read access, they don't get access. Individuals still need to request explicit access. Can groups and teams only be added by SharePoint admins? That's a long question. Quite simple question. Come on. It's a fairly simple question with a very complex and complicated answer. So as far as can groups and teams only been added by SP admins, if you have the correct access on the site as always for SharePoint to give other people access to the site, that is the level of access. So if you are owner or site collection administrator, you can give access to other people. Absolutely you can add groups. You can add in 365 groups which are the ones that back groups and teams. You can add that. You can add in 365 groups you can add and you can add active directory groups and you can add individual people into SharePoint groups still. The only thing that I can think is it says individuals still need to request explicit access. My guess is they're creating some really complicated unique permissions is what it sounds like. One of the things that you have to think about in the modern version of SharePoint is there are some additional touch points we didn't have before. So for example, in the past I could give explicit unique access to anybody, a person, or a group and they would by default have access to the UI that comes into that. That is not true anymore. So if I want people to for example be able to have access to edit a page because there's certain .NET controls that live on the pages now that you might actually have to give them more access than just the page to be able to do certain things. I think there's a lot of learning when it comes to some of the new controls in SharePoint online and permissions. But at a very basic level, yes, you can add in 365 groups to SharePoint groups and it should follow most of the same protocols that it did before. But if you are doing very explicit unique permissions, it can get very complex and very complicated very quickly. Well, and remember SharePoint is behind the scenes in all of these, right? And there is the advanced permissions. There are three out of the box permission groups when you create a SharePoint site. You can create, there's a, I think it's 27 different attributes that you can create custom permission groups and not just owners, visitors, they can do all the things, they can only contribute to the things, or they can only see the things. You can add, they can add, but they can't delete. They can, and you can assign them at the library level, even down the item level, which I don't recommend, because that's just tedious and too hard to maintain and possibility for failure. But there's more to the story than the advanced permissions and just sharing. And the question I had for you, Sharon, is you used to not be able to add SharePoint groups as members of other SharePoint groups. They had to be the Active Directory security groups. So how's that changed? No, no, that's still the same. And the reason is because a SharePoint group is not truly a group. A SharePoint group is a pointer. So an Active Directory group is a container of names of profiles. Whereas a SharePoint group is actually a pointer, it's not actually a true group. And so what ends up happening is that it works a little bit different. So you can't have a SharePoint group inside of a SharePoint group. You used to not be able to do an M365 group instead of an M365 group. But there are changes that are coming for nested groups. I believe they've been rolled out already, where in Active Directory groups, you can now do nested groups on that site. But you still can't do SharePoint groups inside of SharePoint groups. So that's what I read this question. That was the first thing I thought of, is did they try to add another SharePoint group as the group and that doesn't work? And I was just making sure that that hadn't changed. And to my knowledge, it had not changed. But you know, you know, you all keep up on that more than I do. That's a true 101 question is a lot of people think that you can put SharePoint groups inside of SharePoint groups, because somebody will say, oh, you just add a group to it. You cannot put a SharePoint group in a SharePoint group, but you can put an Active Directory group or an M365 group inside of a SharePoint group, and it will work. So if you're going to do a group and a group thing, then you need to do Active Directory M365 inside of a SharePoint group to make it work that way. Which is the preferred way to do it. Yeah. That way when people are added or removed, Active Directory groups are added to remove to the permissions automatic on a SharePoint site. So the downside of that is you don't control those Active Directory groups. The administrator has to decide who's part of that group and who's not part of that group. And dynamic Active Directory groups tend to sometimes have issues with SharePoint groups. For the most part, they seem to be acting better now, but occasionally if you're having some issues, sometimes I'll go look and it'll actually be a dynamic Active Directory group. And I can always tell sometimes if it's a little goofy that it might be that way. But typically when I get this problem, so we've added a group to visitors to read access, but then they're still having to have to ask for access. It means that there's likely, so let's say for example, we've given them read access to a list, but we didn't give them read access to the page that the list lives on. And so therefore they can't get there. Or maybe we haven't given them access to the site, but we've given them access to the list. In that case, you would have to give them the direct URL to the list for them to access. They would not be able to go to the site and navigate. They would not be able to use search. They would not be able to use any of the controls. They would only be able to go directly to the thing you've given them access to. Whereas if you want them to actually go to the site and navigate, you would have to give them access to the site, to the page, and to the list to be able to access those different levels of UI. Yeah, which is the limited access nightmare, right? Stop doing that. If they're not supposed to be in the list, give them at least read only at the site level of some kind. Don't give them access to the objects in the site without giving them at least read only at the top level. That's what OneDrive is for. Thank you. Using unique permissions. Yes, stop. You know, why don't you have a shared, I mean, they could have if it's a team, like it depends. Is it SharePoint or is it at the back of they've created a team? So therefore, you've got the SharePoint, then they're trying to do that. Could you do a shared channel with them instead? And the docs actually live within the shared and provide it that way. You know, there are alternatives to potentially the complexity of what you're talking about. Is it standalone SharePoint or, you know, how's it been set up? And I've also seen them just sending a link that's got nothing to do with what it is that they've provided permissions to. You know, it's like, what link are you trying to send guys? So they kind of go, well, I'm going, and I'm doing this, I'm going, hang on. But that's got nothing to do with the permissions that you're trying to create and which folder at which level did you create it? You know, you've got it. Is it the whole site you gave read or is it just that one, you know, small folder, but the parent folder doesn't actually have permission just with the parent folder. And if the parent folder didn't have the permission, then no, they're not going to be able to. So, you know, there's so many levels, you've got the higher and then right down to the minute. Well, all the other permissions are always bad, never, ever, ever, never, ever, right? Yeah, just don't as bad. Unless you're, unless you're using somebody. So we do, we have a few clients where we do specific folder permissions for very specific reasons. And there are, there are use cases where it can be beneficial as long as it's like one level deep and it's for a very specific reason. But I would definitely engage somebody who is more, you know, knowledgeable about permissions and has tested in and documented it for you. And I really don't recommend unique permissions if you can all avoid it. Microsoft done a great job of really re-architecting a lot of the environment to go via groups and teams, which is so much easier for the average person. And to Chrissy's point, like, whether it's a shared channel or a private channel or just another team, nine times at a time, like that's easier and faster and smarter than trying to figure out all this nonsense on the back. Yeah. Or is it another document library you can do permissions so that it's unique permissions to that document library rather than trying to break inherited permissions so that you can go, I want to do this piece. So, you know, I don't like them saying the breaking all the inherited permissions and then they never remember what it was they broke in the first place. So. And I love that highly technical term of nonsense. It's a technical term. All that nonsense in the back, all the security, all the security. And I love that. I never remember the things that I break. I move on. I rise above it. If we do unique permissions for clients, we document the entire thing in a spreadsheet. And that's the difference. A lot of people just go click in buttons and they don't write it down. And then you come in later and you're like, what is going on with this? Yeah. Who did this? Smack them upside the head. If you bring me in to clean up unique permissions, I 100% will get rid of all of them and start over. Yep. Yeah. Yeah. Absolutely. Could you just start now? Something what it's supposed to be. Yeah. Well, I say that, look there, again, where things have really become more streamlined. But I mean, back in the day with SharePoint and permissions, I mean, that was the meat and potato of third party solutions was cleaning a lot of that up. And there are valid reasons for having some of that complexity. Most scenarios like you do not need to. So you need to adhere to the standards and use the tools for the way that they're intended. Use OneDrive when OneDrive should be used instead of trying to come up with all these one-off, small solutions. But where there is complexity, I mean, I don't, everybody knows I work for Rencore. We have governance tools. There are solution providers that are out there that do a lot of this stuff really well to help manage that centrally. So there are options out there. But if you don't have those tools, keep it streamlined, keep it simple. Yep. There are best practices that are posted out there for a reason. If you really want to be adventurous, you can create a custom .NET solution that sits on top with its own permissions. Of course. As many organizations have done, just break SharePoint. So that's all it becomes. So there's nothing that upgrades, nothing that, yeah, it's down to its fundamentals. Yeah. Or use Power Automate to control all of the permissions and update the permissions as needed. Just email me all the files. We could just do it via email. Between email, I've got an FTP server. We're good. I can't get SharePoint to do the permissions, so I'm using Dropbox. No, you love that when you're like, I can't find the file and they're like, I'll resend it and you're like, no, don't resend it. Yeah. Don't resend that 45 slide PowerPoint that you have the high-resolution picture on the background and it's now taken up half of my, I just locked up my inbox. Yeah, exactly. Please send that again. Well, that never happens.