Restirct user access to SPO Root SiteCollection
Hi everyone, In a tenant, the SharePoint Online root site collection was deliberately locked down to a very small audience. We are currently seeing some issues that could be related to this. While investigating, I noticed that some Microsoft documentation seems to imply that the root site collection plays a special role and should be accessible for the users, for example: https://learn.microsoft.com/en-us/sharepoint/modern-root-site https://learn.microsoft.com/en-us/troubleshoot/sharepoint/sites/url-that-resides-under-root-site-collection-is-broken However, I couldn’t find any explicit or official recommendation stating whether restricting access to the root site collection is supported or discouraged. So my question is: Is it a best practice or implicit requirement that the root site collection remains broadly accessible for M365 / SharePoint Online to work reliably? Thanks!
Users unable to determine who has access to document library due to security groups
Greetings, Maybe I went about this the wrong way. Looking for advice on either the proper way we should be moving forward on this or any other comments or insight we should be considering. This is for SharePoint online via Microsoft 365 Business license. Scenario: 1. SharePoint Document Library per department (Each Document Library exists in its own SharePoint site), essentially being used as a company drive. 2. Some users should only officially have access to specific folders in some of the document library. 3. If say a person in accounting has access to some specific folders, and either they are replaced or a new accounting user comes in.... should be able to reference the access the existing person has in order to give the same access to the new user. 4. Common Request: Give UserB the same folder access as UserA. 5. Some users should have access to the entire document libraries while other users only have access to specific subfolders. Current Implementation: 1. In Entra, created Security Groups that tied to specific folders. -- For Example for the accounting folder, only management has access to the entire folder but the accounting staff only have access to specific folders. So like there is a FiscalYear2024 folder, so I created a security group called sec-Accounting-FiscalYear2024 and assigned the members that should only have access to that folder and not the rest of the library. -- My thought behind this was if a new user was replacing the existing user or joining the department, I can just reference the existing user security group membership and copy it to the new user. 2. In the SharePoint document Library, I create a shareLink that is assigned to the security group I made for that access. Then I give that link to the users I assigned the membership to. Current Issue: 1. Aside from the official document sharing/access that is being done from the security groups above. There are occasions where users of a sharepoint need to share specific files or folders to other users. 2. However, they are all panicking and confused because aside from themselves they are unsure who has access to the existing folders/files in the document library. 3. When going to manage permissions of a file/folder, it only shows the group assigned to it but not the members of the group. 4. So since users can't see the members of the group assigned to a folder, they have no idea who has access to that folder and are getting confused. If this was an NTFS drive, it would be super easy for users to see who has access and etc by looking at the properties but I'm stuck behind some limitations of sharepoint I didn't realize existed until I tried to implement certain workflows. Any advice here would be greatly appreciated, as my implementation has turned into a point of frustration for end users. Thank you in advance!
I need some simple layman explanation
Hi, I am involved with an implementation of an epm system that is integrated into sharepoint M365 and I started reading on its manual on the setting it up for the first time. I know the steps but I wish to get some simple understanding of why the steps are needed since I am not a very technical person. The tool involves the deployment of an addin in Microsoft word (both web and desktop app). The manual said the addin app can be installed by the user directly from app store or being deployed by the M365 administrator to group of users...but in the section for M365 administrator to deploy this addin app, it said that permission needs to be granted to the app. The permissions are: openid profile sites.selected user.read So why is it ok to let user install directly (without any instruction to set permissions) but when M365 administrator do it, it suddenly needs the given permission? In addition, the manual said to run a powershell script in order to grant permission to the sharepoint site created for the epm system integration. it wrote that sharepoint admin must have Microsoft graph powershell SDK installed and run the script being signed in as site owner. What is this powershell script that it needs special installation to run? Then something mention that when deploying the addin to a group of users, there is a step to run a manifest script. This step might need to be re-execute if there is changes in the addin development. What is this Manifest meant for in Sharepoint? What does it do? Thank you in advance.MGDC for SharePoint FAQ: How to Run a PoC without Pulling Your Entire Tenant
Overview When getting started with SharePoint data in Microsoft Graph Data Connect (MGDC) for SharePoint, many teams want to validate scenarios - such as reporting or analytics before committing to a full production deployment. A common first instinct is to pull a complete dataset from a production tenant. While this delivers the most comprehensive view of SharePoint usage, it also: Requires broad administrative authorization Consumes the most Azure compute and storage resources Increases MGDC extraction and processing costs Adds complexity to early experimentation Fortunately, MGDC for SharePoint provides multiple ways to run low‑cost experiments or proof‑of‑concept (POC) deployments using partial or scoped datasets. This guide presents these options using a uniform comparison model, helping you choose the right approach based on: Cost Representativeness of production behavior Implementation effort Dataset completeness Supported datasets Option 1: Use a Dev or Test Tenant Description Use an existing development or test tenant (or create a new trial tenant) to enable MGDC and run initial experiments. Pros Smaller datasets reduce MGDC and Azure costs Easier to obtain administrative permissions Lower operational impact Cons May not reflect production‑scale usage patterns Some SharePoint features or integrations may be missing Requires simulated user activity to generate meaningful data Trial tenants are time‑limited Learn More Microsoft 365 Trial Options Azure Trial Options Option 2: Start with the SharePoint Sites Dataset Description The Sites dataset is typically the smallest MGDC dataset for SharePoint and provides tenant‑wide metadata for all site collections. Pros Lower cost compared to Files or Permissions datasets Provides organization‑wide coverage Minimal MGDC configuration beyond standard onboarding Small dataset can be handled directly by a variety of analysis tools Cons Does not include permission or file details Limited insight compared to full datasets Learn More How can I estimate my Azure bill? Updated! Gather a detailed dataset on SharePoint Sites Option 3: Sample a Limited Number of Rows Description Some MGDC SharePoint datasets support returning only a subset of rows in query results. This is supported across the top 5 SharePoint datasets in MGDC (Sites, Permissions, Groups, Files and File Actions). Pros Minimal and predictable extraction cost Enables rapid schema inspection Provides total dataset row count in request metadata Cons Rows are not returned in a predictable order Sample is not randomized. It is not reproducible and could be biased Results should not be used to draw tenant‑level conclusions Learn More How can I sample or estimate the number of objects in a dataset? Option 4: Filter by SiteId Description Because SharePoint data is partitioned by site collection, MGDC filtering allows you to extract data from a single site or a small group of representative sites. This supports Sites, Permissions, Groups, Files and File Actions datasets. Pros Enables realistic workload simulation Reduces total extraction volume Simplifies downstream reporting Cons May introduce sampling bias Not suitable for tenant‑wide reporting Learn More How can I filter rows on a dataset? Option 5: Filter by TemplateId Description Instead of selecting individual sites, filter by site template to isolate specific workloads. For example, you could filter for OneDrives or SharePoint Embedded. Pros Consistent dataset scope Useful for workload‑specific analysis Cons Limited dataset support (supported only for Sites, Files and File Actions) May not reflect cross‑workload usage patterns Learn More How can I filter rows on a dataset? Option 6: Use Delta State Datasets Description Delta datasets allow you to retrieve only changes since your last data transfer for supported SharePoint State datasets. Pros Enables recurring analytics with lower extraction costs Supports daily or weekly trend analysis Reduces data movement after initial ingestion Cons Requires an initial full dataset pull Adds complexity to downstream merge processing Learn More How can I use Delta State Datasets? How do I process Deltas? Summary MGDC for SharePoint provides multiple approaches to extract targeted subsets of tenant data, allowing teams to: Run proof‑of‑concept deployments Validate analytics pipelines Test governance or migration scenarios Estimate ongoing MGDC and Azure costs By selecting the right combination of dataset scope, filtering strategy, sampling method or delta tracking, you can balance cost, representativeness, and implementation effort before scaling to a full production deployment. For additional guidance on MGDC for SharePoint, visit SharePoint Data in MGDC.How can I stop a user from resharing a document if they have Edit access on that item?
I want to share a document with someone in my organization and give them Edit access, but I also want to prevent that user from sharing the file with anyone else (within organization). Below solutions are not applicable to me Use site or library‑level settings to block members from sharing and only owners can share. This solution is not applicable to us. Use Sensitivity Labels or Purview policies to restrict resharing. We don't have Purview
Horrible sharing URLs in Sharepoint
What is the story with Sharing URLs - they are horrible! In classic SharePoint you could click/drag over a document and you had a user-friendly URL that linked to the document and could be pasted directly into documents, emails etc. Permissions were set once based on the organisation's policy. The link was completely separate to access. Now it creates a horrible unprofessional looking GUID filled thing! In addition, you now have to specify the type of sharing/access you are providing - in most cases existing access is fine! - which can then result in completely unnecessary permissions entries that now have to be managed/audited. Not only was it fine the way it was, it was better! Any chance of sorting this out?
Issue to move folders
Hello everyone. This is my first post here. I'm facing an issue where I'm unable to move folders. This started after the last SharePoint update. For example, as shown below, I cannot move folder 1 into folder 2. Inheritance policies and read/edit security groups have already been changed, and nothing changed. Anyone else experiencing this? Thank you for the community helping here.
How to hide the Modify this view and Create View as per users available in groups
Hi All, I have classic view of SharePoint in list/libraries. I have group(for Managers). I just want want to show and hide the Create View/Modify View/Modify this view depends on users available in group. If user available in group(for Managers) then they can do anything like Create View/Modify View/Modify this view but if user is not a part of the group(for Managers) then they can not modify any Public views but the can create Personal view. Is there any way how I can achieve this functionality?
Classic SharePoint features appearing on a Modern Site
I have a modern SharePoint site, with a modern list that has never been associated with classic SharePoint features. But today, two users have experienced intermittent instances of the list appearing in the classic interface. They have not accessed this site before now so I do not believe there should be a cache issue. Does anyone know why this is happening and how it's possible when this site has no association with Classic features? They are using the same browser, same permissions across the site but sometimes the list opens in Classic mode, sometimes it opens in Modern. It also is happening in incognito mode. They are unable to use the site while in Classic Interface at all - the people pickers deny them access ("Error: Sorry, you do not have permission to query for users" and they cannot edit anything because of this error.
