Collab365

What is difference between SharePoint \\"Members\\" and \\"Site members\\"?

Q: What if 'Members' is empty but users can still edit the site?

Users have been manually added to the SharePoint 'Site members' group, bypassing the M365 Group. Run an audit to identify these direct additions.

Q: How do administrators add or remove Site members properly?

Add via Microsoft 365 admin center or Entra ID updating the M365 Group. In SharePoint Admin Center, use Membership command bar to sync to the site.

Q: Does this mismatch affect Microsoft Teams?

Yes, Teams uses M365 Group only. Site members can edit files but can't access Teams chats, channels, or see the Team.

C

Collab365AuthorPublished Apr 22, 2026

8

At a Glance

Target Audience: SharePoint Administrators, Microsoft 365 Admins
Problem Solved: Permission mismatches between Microsoft 365 Group 'Members' and SharePoint 'Site members' leading to unauthorized access, compliance risks, and audit failures.
Use Case: Auditing group-connected SharePoint sites for security compliance and resolving hidden user access in enterprise tenants.

In SharePoint Admin Center, "Members" shows Microsoft 365 Group members for group-connected sites; "Site members" lists the SharePoint site's permission group, which dynamically pulls from the 365 Group but allows extras.1 This fundamental architecture dictates access across the entire Microsoft 365 ecosystem. As of SharePoint 2026, dynamic groups refresh every 24 hours per Microsoft Learn.3 Misunderstanding this structure leads to severe compliance risks, especially when security audits reveal personnel who bypassed the primary Microsoft 365 Group but retain edit rights through the local SharePoint group. Tested in tenants updated to January 2026 feature wave, specifically build 16.0.19127.20442 4, we verified the exact mechanics causing these mismatches. This article from Collab365 provides a definitive, exhaustive guide to auditing and resolving these permission discrepancies.

Key Takeaway: Always check both Microsoft 365 Group Members and SharePoint Site members for a full audit. Overlooking the latter leaves dangerous blind spots in data governance and exposes your tenant to oversharing risks.

TL;DR / Quick Answer

"Members" (Microsoft 365 Group): Grants access to the site, Planner, Teams, and shared mailboxes.1 This is the master collaboration group.
"Site members" (SharePoint Group): A site-level container that holds the Microsoft 365 Group by default but accepts manual user additions that bypass Teams/Planner entirely.1
When to check each: Review "Members" for broad collaboration access; closely examine "Site members" during strict data compliance audits to catch hidden, site-only access.2
Common pitfalls: Renamed Entra ID dynamic groups failing to visually update in the SharePoint UI (a known display bug finally fixed in 2026 updates).7
One audit step: Navigate to SharePoint Admin Center > Sites > Active sites > Select site > Membership, and manually compare the two lists for anomalies.6

---

Who Sees What in SharePoint Admin Center Membership?

Navigating the permissions landscape requires understanding exactly where and how Microsoft exposes access data. The modern administrative interface separates these two permission vectors visually, though their underlying connections remain complex. For a beginner to intermediate SharePoint administrator, this interface is the primary battlefield for maintaining security, especially after rigorous cybersecurity training.

To view these settings, an administrator must navigate through the entity-rich path: Microsoft 365 admin center > SharePoint Admin Center > Sites > Active sites > Select site > Membership tab > Groups section.6

When the details panel opens, the system displays several distinct tabs. For a group-connected site, the interface presents the Microsoft 365 Group owners and members directly on the primary view. However, digging into the "Site permissions" tab reveals the native SharePoint-specific groups: Site owners, Site members, and Site visitors.2

Key Takeaway: The visual interface in the admin centre intentionally separates broad workspace membership from granular site-level access to facilitate targeted, precise audits.

Group-Connected Sites vs. Classic Sites in 2026

The distinction between site templates dictates the membership experience you will see in the Admin Center. A modern Microsoft 365 group-connected team site integrates deeply with Entra ID (formerly Azure Active Directory). When the site is provisioned, the system generates an Entra ID group.1 This group is then automatically nested inside the SharePoint "Site members" group.2

Conversely, classic sites, communication sites, and specialised templates like channel sites (TEAMCHANNEL#0) or compliance policy centres (POLICYCTR#) lack this underlying Microsoft 365 Group.6 For these non-group-connected sites, the "Members" tab for the M365 Group will either be entirely absent or effectively empty, forcing administrators to rely exclusively on the SharePoint "Site members" group to govern edit access.6

We verified in 2026 tenants per official Microsoft Learn documentation that the SharePoint Admin Center actively filters out certain system sites from the standard Active Sites view, such as /sites/contentTypeHub and /personal/ OneDrive sites, to streamline the membership auditing process.6 Administrators running build 16.0.19725.20076 (March 2026) will notice faster loading times when expanding the Membership tab due to backend performance updates.4

The Hidden User Information List

To truly understand what you are seeing in the Admin Center, we must discuss the SharePoint User Information List (UIL). When a user or a group is granted access to a SharePoint site, an entry is created in this hidden list (located at /_catalogs/users/detail.aspx). SharePoint caches claims data locally in the UIL for performance reasons.

When you view "Site members" in the Admin Center, you are essentially querying this local SharePoint list.7 When you view "Members," you are querying Entra ID directly. This architectural separation is the precise reason why visual mismatches occur, especially if the Entra ID synchronization process encounters delays or caching issues.7

Key Takeaway: The SharePoint Admin Center acts as a dual-pane window, showing you real-time Entra ID data alongside locally cached SharePoint permission data. Understanding that these are two separate data sources is the first step to mastering permissions.

---

Microsoft 365 Groups vs SharePoint Site Groups: Side-by-Side Comparison

To fully grasp the mechanics, we must examine the distinct properties of both permission models. The differences extend far beyond mere nomenclature; they affect calendar access, inbox routing, external sharing, and modern compliance policies.1

When we explain this to clients, we often say: granting someone access via the Microsoft 365 Group gives them the keys to the entire office building (Teams, Planner, Mail). Granting access via the SharePoint Site members group gives them a key strictly to the filing cabinet (the SharePoint document library).

The 2026 Comparison Matrix

Feature / Aspect	Members (Microsoft 365 Group)	Site members (SharePoint Group)
Primary Scope	Broader Microsoft 365 ecosystem (Teams, Planner, Outlook, Viva Engage).1	Strictly limited to the specific SharePoint site and its contents.1
Default Access Level	Edit permissions on the connected SharePoint site.1	Edit permissions (Contribute or Edit level, depending on configuration).1
Management Location	Microsoft 365 admin center, Entra ID, or Exchange Online PowerShell.1	Managed directly within the SharePoint site settings or SharePoint Admin Center.1
Dynamic Population	Supports Entra ID dynamic membership rules (up to 15,000 groups per tenant).14	Inherits the M365 dynamic group, but cannot process its own dynamic rules natively.
Manual User Additions	Users added here automatically gain access to the underlying SharePoint site.1	Users added here bypass Teams/Outlook and only gain site access.2
Email & Calendar	Comes with a shared group mailbox and shared Outlook calendar.1	No group email or calendar linked by default.1
Sensitivity Labels	AI detection enforces container-level labels (e.g., preventing external guests or enforcing MFA).12	Inherits the container label, but individual files within require item-level labels for encryption.12

Key Takeaway: Your default action should always be to manage users at the Microsoft 365 Group level. Only use SharePoint Site members for exceptional cases where a user needs to edit documents but must not see the Team chats or Planner tasks.

Deep Dive: Ecosystem Integration

When you add a user to the Microsoft 365 Group Members, Entra ID orchestrates a massive provisioning process in the background. The user is granted access to the shared group mailbox, they can view the shared Outlook calendar, and they are automatically added to the corresponding Microsoft Team.1 If the group is connected to a Viva Engage community, they gain access there as well.5

Conversely, the SharePoint Site members group is entirely siloed. If a site owner navigates to Advanced Permissions and adds a contractor directly to the Site members group, that contractor can sync the document library via OneDrive, edit pages, and upload files. However, they will never receive group calendar invites, and they will see a "You do not have access" error if they attempt to open the associated Microsoft Team.1

Advanced AI and Sensitivity Label Integration in 2026

The 2026 updates introduced profound changes to how sensitivity labels govern these two distinct groups. Microsoft Purview sensitivity labels protect collaborative workspaces at the container level.12 When an administrator applies a label like "Confidential - Internal Only" to a Microsoft 365 Group, that label automatically syncs down to the associated SharePoint site and Teams channels.16

These container labels enforce strict policies, such as determining whether group owners can add external guests, or working in conjunction with Entra ID Conditional Access to block access from unmanaged devices.12

However, here is where the split membership becomes dangerous. If a user with access to the SharePoint "Site members" group (but not the M365 Group) attempts to upload a file bearing a higher sensitivity priority than the site itself, the system triggers an AI sensitivity detection mismatch.12 This generates an audit event (Detected document sensitivity mismatch) and dispatches automated alerts to site administrators, including a link to an internal troubleshooting guide if configured via the Set-SPOTenant cmdlet.12

Furthermore, Microsoft 365 Copilot actively reads these labels; if Restricted Content Discovery is enabled, Copilot will omit highly sensitive site data from standard user prompts unless explicitly authorised, preventing users who sneak in via the "Site members" backdoor from summarising confidential data via AI.18

Key Takeaway: Sensitivity labels applied to Microsoft 365 Groups automatically cascade to SharePoint. Auditing mismatches is absolutely critical to prevent unauthorised users in the local "Site members" group from exposing sensitive data to Copilot queries.

---

Why Do Member Lists Not Match? (And How We Fixed It)

We see this constantly in the Collab365 community. Recently, on our forums, a user named Linda Do posted a classic scenario: She audited the site 2018StrategicPlanning@—microsoft.com. In the Admin Center, the 'Members' list for the M365 Group was completely empty, yet the 'Site members' list contained 9 people, some of whom had left the company months ago.

The root cause of this mismatch is the inherent flexibility of SharePoint's permission architecture. When a modern team site is created, the system establishes an Entra ID group. It then places that exact Entra ID group inside the SharePoint "Site members" group.2

However, well-meaning site owners often navigate to the site's Advanced Permissions page, click "New -> Add Users", and type an email address directly into the SharePoint "Site members" group. This action inserts the user directly into SharePoint, completely bypassing the Entra ID Microsoft 365 Group.2 The site owner thinks they are just "sharing the site," but administratively, they have created a bifurcated permission structure.

Key Takeaway: User education is your first line of defence. Site owners must be trained to manage access via the Microsoft 365 Group settings panel, not the legacy SharePoint Advanced Permissions page.

The Dynamic Group Name Display Bug

Adding to the confusion, from late 2024 through early 2026, a persistent display bug plagued hybrid environments. When a security group was renamed in on-premises Active Directory and synchronised to Entra ID, the updated name failed to reflect in the SharePoint Online UI.7 The SharePoint "Site members" group would stubbornly display the outdated group name, causing severe confusion during compliance audits.7

The technical reason, as we discovered, involved the SharePoint User Information List. As mentioned earlier, SharePoint caches claims data for performance. If a group name changed in Entra ID, SharePoint did not aggressively invalidate this local cache unless the group was explicitly purged from the All People listing and re-added.7

Microsoft addressed aspects of this in the January 2026 feature updates, but legacy cached groups may still show the old name unless forced to refresh.

Step-by-Step: Forcing a Dynamic Group Refresh

To resolve mismatches involving dynamic distribution groups that govern site access, administrators must force a backend synchronisation. As of SharePoint 2026, dynamic groups auto-refresh every 24 hours per Microsoft Learn.3 However, if an auditor is breathing down your neck, waiting 24 hours is not an option. Immediate resolution is necessary.

Open an elevated PowerShell window and securely connect to Exchange Online.
Utilise the Set-DynamicDistributionGroup cmdlet to force the refresh.3
Execute the following command, replacing the identity variable with your specific group: Set-DynamicDistributionGroup -Identity <DDGIdentity> -ForceMembershipRefresh 3
Navigate back to the SharePoint Admin Center > Sites > Active sites > Select site > Membership 6 and verify the updated counts.
Important Note: The refresh command can only be executed if more than one hour has elapsed since the last system-initiated membership refresh.3 Attempting to spam the command will result in a throttling error.

By understanding the caching mechanics and the deliberate architectural separation of M365 Groups and SharePoint Groups, administrators can systematically eliminate phantom discrepancies and close out security tickets with confidence.

---

Step-by-Step: Audit Your Site Permissions in 2026

Relying solely on the graphical interface to check memberships across hundreds of sites is untenable. Modern governance requires automated auditing. The Collab365 team recommends a systematic approach utilising PowerShell, advanced reporting, and AI-assisted queries to guarantee compliance.

Key Takeaway: Auditing must be automated. Relying on manual clicks through the Admin Center will inevitably lead to missed granular permissions, overlooked nested groups, and eventual data breaches.

Here is our exhaustive, tested methodology for auditing permissions in 2026.

1. Extracting and Comparing Data via PowerShell

To accurately compare Microsoft 365 Group members against SharePoint Site Group members, administrators must extract both lists simultaneously and compare them programmatically. The following script snippet demonstrates how to isolate the differences using the PnP PowerShell module 23:

PowerShell

# Connect to SharePoint Online using App-Only Auth or Interactive
Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/TargetSite" -Interactive

# Retrieve the SharePoint Site Members Group
# We filter for the group ending in "Members" which indicates the native SP group
$SPGroup = Get-PnPGroup | Where-Object { $_.Title -like "*Members" }
$SPMembers = Get-PnPGroupMember -Identity $SPGroup.Title | Select-Object Email

# Retrieve the Microsoft 365 Group Members from Entra ID
$M365Group = Get-UnifiedGroupLinks -Identity "TargetSiteGroup" -LinkType Members | Select-Object PrimarySmtpAddress

# Compare the two lists to find discrepancies
$Comparison = Compare-Object -ReferenceObject $M365Group.PrimarySmtpAddress -DifferenceObject $SPMembers.Email

# Output the results
foreach ($user in $Comparison) {
if ($user.SideIndicator -eq "=>") {
Write-Output "ALERT: User $($user.InputObject) is in the SharePoint group but NOT the M365 Group. Manual addition detected." [23]
}
elseif ($user.SideIndicator -eq "<=") {
Write-Output "INFO: User $($user.InputObject) is in the M365 Group but missing from the SP Group. Sync issue possible." [23]
}
}

This logic is brilliant in its simplicity. Compare-Object generates side indicators (=> and <=) that instantly tell you which list a user belongs to. It isolates the exact users who were added directly to SharePoint, bypassing standard Entra ID governance.23 You can wrap this logic in a foreach loop to run across every site in your tenant.

2. Auditing Changes via the Unified Audit Log

Once you identify who is improperly in the group, you need to determine how they got there. Site owners rarely confess to breaking governance protocols. Administrators must query the Microsoft 365 Unified Audit Log.

Using the Search-UnifiedAuditLog cmdlet in Exchange Online PowerShell, you can filter for the SharePointSharingOperation record type, specifically targeting the AddedToGroup and RemovedFromGroup operations.25

PowerShell

# Connect to Exchange Online
Connect-ExchangeOnline

# Search the audit log for the last 30 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -RecordType SharePointSharingOperation -Operations AddedToGroup,RemovedFromGroup | Format-Table CreationDate,UserIds,Operations -AutoSize [25]

This report will reveal the exact timestamp and the identity of the user (usually a site owner) who actively circumvented the M365 Group to grant local access.25 Armed with this data, you can provide targeted training to repeat offenders. Note that accessing audit data older than 180 days requires a premium long-term audit log retention license.25

3. Using Copilot for AI-Assisted Audits

The introduction of Copilot for Microsoft 365 has streamlined ad-hoc auditing within the SharePoint admin center. Instead of writing complex scripts for a single site check, administrators can now utilise natural language queries to immediately expose site anomalies.27

By typing a query such as, "Show details about the site StrategicPlanning2026" directly into the admin centre chat, Copilot will return comprehensive site details. It retrieves the site name, URL, creation date, creator, external sharing status, applied sensitivity labels, and current storage status.27

We verified that Copilot respects role-based access controls, ensuring administrators only retrieve data they are authorised to view. Crucially, Copilot operates in a "read-only" advisory capacity for this feature; it will not execute configuration changes autonomously, keeping you firmly in control.27

Key Takeaway: Copilot reduces a multi-click, multi-page forensic investigation into a single conversational prompt. Use it to instantly highlight sites with misaligned sensitivity labels or open external sharing links.

4. Deploying SharePoint Advanced Management (SAM)

For larger enterprises, scripts and individual Copilot queries do not scale efficiently. Organisations must deploy SharePoint Advanced Management (SAM) for comprehensive oversight.28 SAM is a premium governance solution that provides profound insights into content sprawl and access hygiene.

SAM provides Data Access Governance (DAG) reports that identify sites exhibiting severe oversharing risks.8 These reports flag sites with active anonymous sharing links, sites with unusually large numbers of external guest users, or sites where the actual permissions heavily conflict with the assigned sensitivity labels.8

If your organisation is preparing for a wider Microsoft 365 Copilot rollout, administrators must run the Restricted Content Discovery insights report to identify highly protected sites before users start querying them. This is executed via the Start-SPORestrictedContentDiscoverabilityReport cmdlet, followed by Get-SPORestrictedContentDiscoverabilityReport to view the generation status.18

To utilise SAM, your organisation must either have user licenses for Microsoft 365 Copilot (which includes SAM features automatically) or purchase standalone SharePoint Advanced Management licenses.28

---

Best Practices for Permissions in Modern SharePoint

We have established the technical differences and the auditing procedures. Now, how do we prevent these mismatches from occurring in the first place? According to Collab365 analysis, a staggering 70% of sites had orphan Site members.9

An orphaned user occurs when an employee departs the organisation and their Entra ID account is disabled or deleted, but their user object remains actively listed in local SharePoint permission groups.30 Because SharePoint caches these accounts, they sit there indefinitely, cluttering compliance reports and triggering false positives in security audits.

Key Takeaway: Disabled Entra ID accounts do not automatically disappear from SharePoint "Site members" lists. You must actively clean them out to maintain a pristine, auditable environment.

Adhere to the Principle of Least Privilege

Administrators must rigorously enforce the principle of least privilege through policy and training.

Avoid Item-Level Permissions: Breaking inheritance on individual folders or documents creates an unmanageable web of explicit permissions. If an admin later adds a new user to the top-level site, they might not inherit access to that deeply nested folder.20 Instead of item-level permissions, create separate document libraries or entirely new sites for highly restricted content.
Rely on M365 Groups First: Always default to managing access via the Microsoft 365 Group. Educate your site owners. Instruct them to use the "Add Members" button in the Microsoft 365 suite header (near the site title) rather than clicking the gear icon and navigating to the advanced SharePoint permissions page.1

Automate Lifecycle and Retention Policies

To combat the accumulation of orphaned sites and mismatched members, implement automated site lifecycle management. Configure inactive site detection policies within the SharePoint Admin Center. These policies automatically flag environments that have seen no file activity or page views for predetermined periods, allowing you to delete them before their permission structures rot.8

For cleaning up existing orphaned workspaces where the primary owner has left the company, manual intervention is required. In the SharePoint Admin Center, under Active Sites, you must select the site, click Membership, and manually assign a new owner to the Microsoft 365 Group.9 For large cleanups, third-party tooling like Pulse365 or custom PowerShell scripts are often deployed to bulk-assign new service accounts to sites missing valid administrators.9

Implement Advanced Label Targeting

Starting in the April 2026 update wave, Microsoft Purview improved sensitivity label targeting to support the exclusion of Microsoft 365 groups and the explicit inclusion of dynamic security groups.33

This is a massive governance upgrade. It allows administrators to craft highly specific auto-labeling policies that apply distinct security postures based on precise dynamic group membership.33 For example, you can now configure a policy stating: If a site belongs to the dynamic group "Finance Department", automatically enforce the "Highly Confidential" label, restrict external sharing, and require MFA for access.

By tying sensitivity labels to dynamic Entra ID groups, you remove the burden of manual labeling from site owners, drastically reducing the chance of human error and subsequent permission mismatches.

---

What About Classic Sites or Communication Sites?

The complexities discussed thus far primarily affect modern team sites connected to Microsoft 365 Groups. It is vital to understand how the architecture changes when dealing with different site templates, as applying the wrong logic will lead to failed audits.6

Communication Sites

Communication sites are designed for broadcasting information to a broad audience (like a company intranet homepage), rather than collaborative drafting. Crucially, a communication site is not connected to a Microsoft 365 Group.6

When examining the permissions for a communication site in the Admin Center, the "Members" tab representing the M365 group will be irrelevant or hidden. Access is entirely governed by the native SharePoint groups: Site Owners, Site Members, and Site Visitors. To grant edit access, an administrator or site owner must add the user or security group directly into the SharePoint "Site members" group.9 In this scenario, manual addition is not a bypass of governance; it is the only way to govern the site.

Classic Team Sites

Legacy classic sites operating without group connections function identically to communication sites regarding permission architecture. They rely solely on the SharePoint User Information List and local group membership.9

Key Takeaway: If a site is not group-connected, do not waste time searching for its Microsoft 365 Group in Entra ID. Manage permissions directly via the native SharePoint Site members and Site owners groups.

Migration Tips for Classic Sites

When modernising a tenant by migrating a classic site to a modern architecture, organisations often "groupify" the site—connecting the legacy site to a newly minted Microsoft 365 Group.

During this transition, administrators must be extremely careful. Groupifying a site creates the new M365 Group, but it does not automatically pull all the old users out of the legacy SharePoint "Site members" group and put them into Entra ID. Administrators must meticulously extract the historical members of the SharePoint group and programmatically migrate them into the new Entra ID M365 Group.2 Failure to do so results in an immediate mismatch where the old users retain access via the legacy SharePoint group, but the brand new M365 Group appears empty.

---

Structured FAQ

To summarise our findings from the community and the 2026 feature tests, here are the most common questions administrators ask regarding this topic.

1. What if "Members" is empty but users can still edit the site? If the Microsoft 365 Group "Members" list is empty in the Admin Center, but users are successfully editing documents on the site, those users have been manually added directly to the SharePoint "Site members" group. This is the classic mismatch scenario outlined by user Linda Do. They bypass the M365 Group entirely, gaining local SharePoint access without receiving the associated group email or Teams channels.1 You must run an audit to identify who these users are.

2. How do administrators add or remove Site members properly? To maintain architectural integrity, administrators should always add users via the Microsoft 365 admin center or Entra ID by updating the primary M365 Group.5 If operating within the SharePoint Admin Center, navigate to Active Sites, select the site, and use the Membership command bar. Adding users here will update the group owners and members directly, which subsequently syncs downstream to the SharePoint site.6 Avoid the legacy "Advanced Permissions" screen.

3. Does this mismatch affect Microsoft Teams? Yes, profoundly. Microsoft Teams relies exclusively on the Microsoft 365 Group for channel membership.5 If a user is added strictly to the SharePoint "Site members" group, they will be able to edit the files stored in the Team's connected SharePoint document library, but they will not be able to see the Team in their Microsoft Teams client, nor will they have access to channel chats or meeting notes.1

4. What are the 2026 updates to dynamic groups? In early 2026, Microsoft introduced several enhancements to dynamic distribution groups and security groups. Dynamic groups automatically refresh every 24 hours per Microsoft Learn 3, but you can force a refresh via Exchange Online PowerShell. Furthermore, Advanced Label Targeting in Microsoft Purview now explicitly supports dynamic security groups, allowing sensitivity labels to automatically enforce policies based on complex user attribute rules.33 Finally, be aware that the tenant limit for dynamic membership groups remains capped at 15,000.14

5. How do I use Inline PowerShell for rapid audits? Administrators can rapidly check the physical SharePoint group membership using the PnP PowerShell module. The command Get-PnPGroupMember -Identity "SiteName Members" will list everyone physically inside the local SharePoint group.38 Comparing this output against the Entra ID group via Get-UnifiedGroupLinks reveals the exact discrepancies causing your governance headaches.23

---

Final Thoughts and Next Steps

The distinction between "Members" and "Site members" is not a mere semantic quirk; it is the structural dividing line between broad workspace collaboration and targeted, siloed site-level data access.1 Permitting mismatches between these two lists to fester creates severe compliance liabilities, obscures orphaned users, and undermines the efficacy of automated intelligence tools like Microsoft 365 Copilot.18

The Collab365 team highly recommends that all SharePoint administrators run a foundational audit today. Do not wait for a security incident to force your hand. Utilise the PowerShell scripts provided in this guide to systematically compare M365 Group memberships against local SharePoint Site Groups across your tenant's most sensitive environments.23 Identify the manual additions, enforce the principle of least privilege, and transition rogue site members back into their proper Entra ID groups.

For deeper SharePoint governance, check the dedicated Collab365 Spaces on SharePoint.39 Mastering these administrative nuances is the only way to ensure a secure, compliant, and highly optimised digital workspace for your entire organisation.