Forum Discussion
Site Collection Admin in Modern Team Sites
I agree with the sentiment, which is why all of our modern UX guides users down safe paths. But as you can see from this thread, we also have a community of people who depend on being able to do some advanced, custom configuration, and don't want to leave them in the lurch. We believe that we've struck a good balance here, where unlike the past 10 years we avoid users accidentally stumbling into trouble, but empowering the experts who to get their job done. I hear your feedback that you think we need to go further, but I know if we completely block it we'll have a lot of feedback saying we went too far.
Given that there is a group upon which many other features depend, we should not be allowed to Delete or otherwise modify the functionality of that group. By allowing us to accidentally break the site, you are setting the stage for expensive support tickets. I have already experienced this once (with the special groups in the Root site collection that are used to control the Editing of Links on the Quick Launch bar). MS should not be Hiding things like this, they should be Locking them so that can't break the services.
Providing customers the ability to change/delete features with dependencies has been an issue for over 10 years in SP and it long past time that the problems be avoided by better software engineering practices
I agree with the sentiment, which is why all of our modern UX guides users down safe paths. But as you can see from this thread, we also have a community of people who depend on being able to do some advanced, custom configuration, and don't want to leave them in the lurch. We believe that we've struck a good balance here, where unlike the past 10 years we avoid users accidentally stumbling into trouble, but empowering the experts who to get their job done. I hear your feedback that you think we need to go further, but I know if we completely block it we'll have a lot of feedback saying we went too far.
- Perhaps a global admin or sharepoint admin setting is in order.
Something like Simple vs Advanced mode. Simple gives you all the locked down/protect the user options, and Advanced gives experienced professional full access to go in and do what we need to do. As an IT professional, I obviously want to have a complete freedom to do EVERY advanced configuration that I feel necessary for my customers (at my risk, naturally...).
Hence, IMO, you have ALREADY gone too far with blocking/hiding advanced configuration interfaces.
Nevertheless, I understand your effort to guide inexperienced users users down safe paths.
I only hope that this strategy will not impair us, experienced professionals, in our work.
In short: go ahead with hiding, if you have to, but please document thoroughly all advanced configuration interfaces and all dependencies that are in place.
- Longer term I hope to not need to remember a collection of urls for assigning scadmins or adding an ad group with thousands of members to a site. I get this model for private team site but I would bet it will need refinement as you get into the publishing use cases in the future where broad sharing goes beyond what O365 groups support today. Many of us have investments in fim and mim that manage enterprise level ad groups so that will hopefully have a place in the story even if the answer is they can be added to an O365 group. That would be better than doing it on the sharepoint site but recognize that's maybe another team.
This thread is perfect for now because it tells us we can use them, it's not going away, we are just making it harder. Hope this gets shared more broadly because it's super important for people to understand it's not a broken sharepoint site, just a site with some guard rails to help simplify While I did not explicity state it in my earlier post, one of my key concerns is the fact that MS is allowing things to be done that cannot be undone without a call to Tech Support. Save the company some tech support money, and us a big headache with our clients (which are your customers and when they ask what happened, I have to tell them that MS gave them bullets and gun and they just shot themselves in the foot) and seal/block/lock etc all of the objects upon which you have taken dependencies. Allowing people to accidentally or intentionally change something without providing the ability to undo the change is not a good design decision. Hiding something does not prevent someone from making a mistake with SP Designer, PowerShell or CSOM. The fact that many of the dependencies are undocumented only exacerbates the problems.
