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.