SharePoint Sharing Report vs Entra Guests: A Guide

SharePoint sharing reports and Entra guests show different evidence

A SharePoint sharing report shows resource, permission, user-or-group, and link evidence for one covered SharePoint site or OneDrive. A Microsoft Entra guest export shows directory identity objects inside a defined tenant snapshot. The report is resource-centric; the directory is identity-centric. Neither is a complete substitute for the other.

Join them only when supported identifiers match. Keep link-only, group, ambiguous, and directory-only cases separate. An unmatched report row does not prove that no guest exists, and a guest object does not prove that the person can access a particular SharePoint resource.

This distinction is the foundation of a bounded guest-access review.

What the SharePoint sharing report contains

Microsoft's official sharing-report documentation, last updated 7 May 2026 when reviewed, says a site administrator can create a CSV of every unique file, user, permission, and link on a given SharePoint site or OneDrive.

The documented columns include:

• resource path;
• item type;
• permission;
• user name;
• user email;
• user or group type;
• link ID;
• link type;
• link used for access.

That makes the report useful for questions such as:

• Which covered resources have named direct access?
• Which rows refer to groups?
• Which link types appear in the report?
• Which named external identities need owner review?
• Which permissions are associated with each reported resource?

The report boundary is the site or OneDrive where it was run. Combining reports from ten sites produces evidence for ten sites, not automatic proof of tenant completeness.

What the sharing report leaves unresolved

Microsoft documents two particularly important limitations:

• SharePoint groups appear, but the report does not list each individual inside them.
• Links emailed directly but not clicked, and Anyone links, are not included.

There are other interpretation boundaries. A link row may describe a sharing mechanism rather than a confirmed human identity. A named email may be stale or formatted differently from the directory record. A resource permission does not show whether a policy will permit the next sign-in.

The report should therefore preserve evidence types:

What an Entra guest object contains

Microsoft's B2B guest user properties, last updated 20 March 2026 when reviewed, explains that B2B collaboration creates a user object in the resource organization's directory. Useful fields can include object ID, user principal name, UserType, identities, invitation state, mail values, and sponsor information where available.

The documentation also makes two distinctions that prevent bad joins:

1. B2B external users can have Guest or, in some scenarios, Member relationships.
2. UserType describes the user's relationship to the host tenant; it does not determine how the user signs in.

An Entra snapshot can support questions such as:

• Does a candidate object exist in the supplied directory evidence?
• Is the invitation pending or accepted according to the available field?
• Which identity provider or identity values are recorded?
• Is a sponsor present in the supplied snapshot?
• Are there duplicate or ambiguous objects for an email?

It cannot, by itself, answer which files the object can open.

Why the join is useful

A cautious join can turn a raw report row into a reviewable identity case. For example:

• report evidence: alex@supplier.example has Edit on a project folder;
• directory evidence: one guest object has an exact approved mail match;
• ownership evidence: the project owner identifies Procurement as sponsor;
• review state: owner must decide whether access remains needed.

The join reduces ambiguity. It does not make the decision.

For collection steps, use how to audit SharePoint guest access.

A safe matching sequence

1. Preserve source values

Never replace the source email, UPN, object ID, link ID, or resource path with a normalized value. Add normalized comparison fields beside the originals.

2. Prefer immutable identifiers

If both approved sources provide the same immutable directory object ID, that is stronger than a display-name or email comparison. Record which source populated it.

3. Compare exact normalized mail fields

Normalize only according to a documented rule, such as trimming accidental surrounding whitespace and comparing domain casing consistently. Do not invent mailbox transformations or assume two aliases represent the same person.

4. Evaluate alternate identity fields deliberately

UPNs for B2B users can differ from invited email addresses. Microsoft documents the #EXT# form for guest UPNs and explains identities separately. Use an approved mapping method rather than reversing a UPN string and hoping it reconstructs the invitation.

5. Reject ambiguity

If two objects match the same supplied email, classify the result ambiguous. Do not choose the newest, oldest, or accepted object without an authorized rule and supporting evidence.

6. Keep links and groups distinct

A link ID is not a guest object ID. A group is not the same as its membership. Obtain separately authorized evidence or leave the person unresolved.

Recommended match states

• Exact: one supported object match.
• Ambiguous: multiple candidates or conflicting identity fields.
• No match in supplied directory snapshot: no supported candidate in a snapshot that was complete for its stated extraction.
• Link only: the report row does not identify a person.
• Group unresolved: membership evidence was not supplied.
• Directory only: a directory object has no matching row in the supplied site reports.
• Out of scope: the record belongs to an excluded tenant, site, user type, or evidence period.
• Unknown: evidence quality does not support another classification.

These states are more useful than one “matched/unmatched” flag because they tell the reviewer what evidence is missing.

Synthetic evidence join

Assume this invented input:

Sharing rows

1. pat@vendor.example has View on /Contracts/2026.pdf.
2. lee@vendor.example has Edit on /Delivery.
3. SharingLink, type Specific People, appears on /Forecast.xlsx.
4. External Reviewers, type SharePoint group, has View on /Reports.

Directory snapshot

1. One accepted guest object has pat@vendor.example in an approved mail field.
2. Two guest objects contain lee@vendor.example across supplied identity fields.
3. One guest object for old@vendor.example has no corresponding row in the supplied site report.

Safe output

The output should not say Lee has duplicate access, the link is anonymous, the group contains guests, or the old guest has no access. None of those claims follows from the supplied evidence.

Settings are a third evidence layer

SharePoint and Entra configuration affects which sharing and invitation paths are allowed. It still does not replace resource or identity evidence.

Microsoft's SharePoint and OneDrive sharing-settings guide, last updated 30 June 2026 when reviewed, documents organization and site sharing levels, link controls, and the interaction with Microsoft Entra B2B settings. The Entra external collaboration guide, last updated 24 April 2026 when reviewed, covers who can invite guests, guest directory access, domain restrictions, and related controls.

Use SharePoint Online guest access settings to collect that context. Do not infer a person's current entitlement from a setting alone.

Join-review checklist

Evidence quality

• Confirm every report source and observation time.
• Confirm directory pagination or export completeness.
• Preserve originals and checksums.
• Record the extraction filters.
• Identify fields unavailable because of role, license, API, or policy.

Matching

• Compare immutable IDs first.
• Use documented mail normalization.
• Preserve original values.
• Keep UserType, identity provider, and invitation state separate.
• Reject multiple candidates as ambiguous.
• Never equate a link ID with an object ID.
• Never infer group members from a group row.

Decision

• Attach resource owner and sponsor evidence.
• Ask whether the business purpose remains valid.
• Keep match confidence separate from access approval.
• Route changes through an authorized process.
• Recollect affected evidence after approved changes.
• Retain unresolved states instead of forcing closure.

For the broader operating workflow, read the Microsoft 365 guest access review.

Limitations

A joined dataset cannot prove that:

• every site, OneDrive, Team, group, or application was included;
• every group member or link recipient was resolved;
• missing report rows mean missing access;
• a guest object has no entitlement elsewhere;
• an exact email match proves the same human in every case;
• the next sign-in will succeed;
• Conditional Access will produce a particular result;
• an owner should retain or remove access;
• the tenant is secure or compliant.

Exports can contain personal and access-sensitive information. Use least-privileged collection, restrict storage, define retention, and avoid copying raw evidence into tickets or content where it is unnecessary.

Microsoft features and schemas can change. Recheck current primary documentation and validate the exact tenant, sharing model, permissions, and review purpose.

Official sources reviewed

Microsoft platform facts were checked on 23 July 2026 against the SharePoint sharing-report documentation, Microsoft Entra B2B guest user properties, SharePoint and OneDrive sharing-settings guide, and Entra external collaboration settings.

To inspect a bounded, read-only evidence join with explicit unknown states, review the GuestPreflight sample and request one paid guest-access preflight. It does not make or execute an access decision.