The guest is in Teams but SharePoint says access denied

The invitation was accepted, the guest appears in the Team, and chat works. Clicking Files produces “Access denied” or an invitation-redemption loop. Re-sending the same invitation usually adds confusion. The repair depends on finding which identity, tenant and sharing boundary the browser is actually using.

A cross-tenant situation with two valid identities

A design supplier collaborates with a Perth venue. The supplier’s email address is also a Microsoft account, while their employer has recently created an Entra tenant using the same address. The venue invites the work account to a Team. Teams desktop opens chat successfully, but the SharePoint files link launches a browser session authenticated as the personal Microsoft account.

The venue administrator sees a guest object and concludes that permissions are correct. The supplier sees their email address in both places and concludes that Microsoft is inconsistent. In fact, two directory identities with the same visible address are participating in different sessions.

Other variants include an old guest object from a previous tenant, a redeemed invitation whose issuer changed, a SharePoint site with more restrictive sharing than the tenant, or cross-tenant access settings that permit Teams collaboration but block the resource flow needed by SharePoint.

Stop multiplying invitations

Repeated invitations can create duplicate guest objects, stale redemption state and more browser links. Pause and capture the failing URL, timestamp, resource tenant, visible signed-in account and exact error. Ask the guest to identify the account type shown in the Microsoft account picker; do not ask them to send passwords, codes or private browser data.

On the resource side, record the guest object ID, user principal name, external user state, invitation redemption status and group or Team membership. Confirm that the Team’s connected SharePoint site is the site being tested, including private or shared channel sites that have separate permissions.

Use object ID and issuer as the diagnostic key. The email string is a presentation identifier.

Check the four sharing boundaries

Tenant external collaboration: is the domain allowed and may the inviting role create guests?
Cross-tenant access: do inbound trust and access policies permit this organisation and authentication context?
SharePoint/OneDrive policy: is external sharing enabled at the required level?
Site and object permission: is this guest in the correct connected group for this exact site or channel?

A permissive tenant setting cannot override a more restrictive site. Direct site membership cannot overcome token issuance blocked by a cross-tenant policy. Check from broad boundary to specific resource and record where the effective restriction changes.

Resolve the guest object and issuer

GET https://graph.microsoft.com/v1.0/users/{guestObjectId}
  ?$select=id,userPrincipalName,userType,accountEnabled,
  externalUserState,externalUserStateChangeDateTime

GET https://graph.microsoft.com/v1.0/auditLogs/signIns
  ?$filter=userId eq '{guestObjectId}'

Use Directory.Read.All for the guest row and the approved audit-log scope for sign-ins. Retain request ID, status, resource ID, tenant ID and conditional-access result. No guest row indicates invitation or object-resolution work. A successful token for the wrong resource or tenant sends the next branch to session context. A SharePoint 403 with the expected issuer sends it to site membership, sharing capability or cross-tenant policy.

Prove which session reaches SharePoint

Use a clean browser profile or private session to isolate the diagnostic. Document the normal tenant-selection path before closure. Sign into the intended organisational identity first, then open the direct SharePoint site URL. If account selection appears, verify the organisation name and tenant context. A successful clean-session test indicates cached account selection or cookies; a failure with the correct identity points back to invitation or policy.

Teams desktop and the default browser do not always share account state. “Teams works” proves the desktop client has a usable guest context. Capture the browser tenant and issuer separately because the desktop result contains no browser-session evidence.

If the guest object was redeemed by the wrong issuer and no controlled remapping is available, remove and reinvite only after documenting memberships and confirming the business owner. Preserve the guest object and memberships until the identity path is captured.

Repair the smallest broken boundary

For a stale or wrong guest object, restore the membership map, create a clean invitation to the intended work identity and verify redemption. For site-level restriction, adjust only the site policy necessary for the collaboration pattern. For cross-tenant policy, define the partner organisation and required inbound access in a scoped cross-tenant rule. Keep the tenant default unchanged.

Use access reviews or sponsorship for enduring guests. A venue collaborating with one production supplier needs different controls from a public submission portal. The solution should match the relationship: named partner, invited guest, one-time link or authenticated application user.

Avoid direct-permission sprawl. Prefer the Team or SharePoint group that represents the role, and keep private/shared channel membership explicit.

Verify the complete guest journey

Test invitation redemption, Teams chat, the Files tab, direct SharePoint navigation, upload, edit, download and any deliberately blocked action. Confirm the guest cannot open another site or channel merely because external sharing was loosened. Sign out and repeat the tenant switch so the repair is usable beyond the administrator’s guided session.

Record the guest object ID, sponsoring owner, groups, allowed resources and review date. Capture the policy decision without publishing the guest’s email address in a general runbook.

Design external collaboration as a product

Publish one short joining guide that explains the expected account type and tenant switch. Maintain a partner onboarding checklist, guest sponsorship, review/expiry and an exit process. Monitor duplicate guests and invitations that remain unredeemed.

Email address is presentation. Object ID plus issuer establish the identity under test. Reliable Microsoft 365 collaboration requires the organisation to govern the directory object, issuer, session, policy boundary and resource permission as one journey.

A support script that avoids blaming the guest

First acknowledge that the same visible email can represent more than one identity and that Teams and the browser may hold different tenant sessions. Ask for the organisation name shown by the account picker, the time of the failed attempt and the resource being opened. Do not ask the guest to clear every browser cookie before the resource team has checked the directory object and policy.

Give one direct test URL and one expected account context. If a private session works, document how to select the intended tenant in the normal browser and clear the stale account state. If policy or membership is wrong, own the server-side correction.

This script matters because vague advice—“try another browser” or “ask your IT”—turns an identity design problem into repeated user labour while leaving the broken boundary untouched.