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?
Accessing External Sharepoint Site
I am able to access internal Sharepoints within my company and have up until now been able to access Sharepoints outside the company. When I now try to access an external Sharepoint, I get the following message on the external company's landing page. "Your account has been locked. Contact your support person to unlock it, then try again...." The external company states they have not made changes any access protocols. Likewise, my company says nothing has changed with respect to the rules/ability to access external Sharepoints. Someone indicated that the Microsoft “federation” settings/setup of the two companies may (now) be incompatible. Has anyone encountered this issue?
SharePoint Permissions Management
Over the last 3 years of managing permissions across a suite of sites, I have uncovered more new issues with the way SharePoint permissioning is designed at every turn. A few examples, before the question: If I "Share" a file or folder somewhere on the site (breaking permissions inheritance), it is very inconvenient to find it again. If I "copy link" in this one particular way, permissions inheritance is broken. When looking at site-level permissions, I see site-level permissions groups, but there could be hundreds of other users who have been added to my site(s) without my knowing. If I want to reset permissions in an area (set of folders or library), I have to do it file-by-file or folder-by folder. If I want to get an excel snapshot of - anything really - IT has to pull it and it takes a couple days. Not to mention the permissions interface is incredibly clunky. All-in-all, there seem to be a million ways to break permissions inheritance, creating an access tracking and security nightmare. AND there's no easy way to truly see and understand who has access to what or what is broken, without spending hours with IT to pull a bunch of narrow-visibility reports. So my question is: what is the best way to navigate full permissions visibility? Am I doing something wrong? Is anyone else experiencing these issues? We have resorted to having a very strict "no outsides besides a few exceptions" policy and only managing permissions at the site-level, which really hampers on the collaboration benefits that SharePoint is trying to enable. It is also very administratively intensive. One of the benefits to SharePoint is that users don't really need to understand how it works to use it, but that's becoming less and less true with the increasing lack of security we feel in the platform.Extracting and Auditing Azure DevOps Permissions at Scale with PowerShell
Managing access in Azure DevOps is easy at small scale — and increasingly opaque as organizations grow. This post introduces ADO Permissions Output, an open-source PowerShell toolset that queries Azure DevOps REST APIs across 30+ security namespaces, decodes bitmask permissions, resolves cryptic GUIDs and tokens into readable names, and produces structured JSON/CSV output ready for Power BI. It also surfaces "ghost" members — users who appear in ADO through nested Entra groups but hold no active entitlement — which the standard Graph API alone cannot detect. Whether you're preparing for a compliance review or just want to know who actually has access to what, this tool closes the gap between the ADO portal and a complete audit picture.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!
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!
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.
