How to check if current user is external in SharePoint

In this post: Why do we need to check for external users? · The Problem · The Solution · Which of the 3 methods should you actually use? · Solution Screenshots · Doing the same check outside SPFx, in Power Automate · Related reading

Why do we need to check for external users in SharePoint?

There are plenty of situations where this matters, even if it doesn’t seem necessary at first. You might not need the check right now, but eventually, as your application’s requirements change, you’ll want it to be as robust as possible. It’s not always about the user being external, but the possibility is real. SharePoint is known as Microsoft’s collaboration platform — and given that it’s a collaboration platform, we can’t ignore the chance of external users, or users who aren’t part of your organization, being invited into your site to do some work. It could be an approval, a sales document, a template, or a file for anything.

The Problem

“We have our custom application in our HR SharePoint site that tracks all the personal records of an employee. It has records for absences, filed leaves, deductions, promotions, salary information, and more. The site was purely for internal users until our IT director changed. He wants to have some collaboration with external resources. For some reasons, we needed to share the application with external users for information audits and checks. Now we need our custom web part to hide part of it if it’s being accessed by an external user.”

The Solution

SharePoint Online leverages the SharePoint Framework for site application customizations and web parts, and there are a lot of APIs and endpoints available now provided by SharePoint. The problem above asks how to hide part of a custom web part if the current logged-in user is an external one. There are 3 possible ways to figure it out.

1. Check if the current user’s login name has “#EXT#” in their principal login name. This works fine — you can query the user via the SharePoint API:

/_api/web/getuserbyid

You can get the user ID by accessing it in the SharePoint site context:

this.context.pageContext.legacyPageContext.userId

2. Query the guest user and check if its type is ‘Guest’ via a Microsoft Graph API call:

https://graph.microsoft.com/v1.0/users?$filter=userType eq 'Guest'

3. Get it directly from the pageContext already available in your web part’s context, without an extra query. You can access the current user’s object via this path:

this.context.pageContext.user.isExternalGuestUser

Which of the 3 methods should you actually use?

All three answer the same question, but they’re not interchangeable in practice. Method 3 (pageContext.user.isExternalGuestUser) is the right default for the scenario in the Problem above — checking whether the currently logged-in user is external, inside a web part that already has pageContext available for free. It’s synchronous, needs no extra network call, and is exactly what a render-time conditional (like the one in the screenshots below) actually needs.

Methods 1 and 2 earn their extra API call when the question isn’t about the current user at all — checking whether someone else (a user picked from a people-picker, an item’s “Created By” field) is external. pageContext only ever describes the person currently viewing the page, so it can’t answer that. Between the two, the Graph userType filter is the more current, purpose-built approach; the “#EXT#” login-name check works but is really a side effect of how Azure AD B2B names guest accounts internally, not a documented, guaranteed-stable API contract to build long-term logic on.

pageContext.user.isExternalGuestUser only ever describes the current viewer — checking whether someone else is external needs the Graph or REST route instead.

Solution Screenshots

From our scaffolded solution, in the WebPart.ts we have a property for our HelloWorld component called ‘isExternalUser‘:

In our main component’s TSX file, we have a logical condition inside the render function to show different text depending on whether the current logged-in user is external or internal. Below is the screenshot:

Now a screenshot of how it looks if the user is an internal user:

And a screenshot of the custom web part if the user is an external user:

Doing the same check outside SPFx, in Power Automate

Everything above assumes a custom web part — but the same “is this person external” question shows up just as often in a flow, with no pageContext available at all. The Office 365 Users connector’s Get user profile (V2) action is the flow equivalent, run against the relevant email address, with the same “#EXT#” pattern from Method 1 checked against the returned User Principal Name:

Add Get user profile (V2), and set User (UPN) to the email you’re checking.
Add a Condition: contains(outputs('Get_user_profile_(V2)')?['body/userPrincipalName'], '#EXT#').

One real limitation worth knowing before wiring this into a flow a guest user themselves might trigger: Get user profile (V2) can return a 401 Unauthorized when called by a guest account, rather than the profile data. If the flow needs to work reliably regardless of who triggers it, explicitly setting the Select fields parameter (userPrincipalName, mail, displayName, and whatever else the flow actually needs) is the documented workaround — an unscoped call is more likely to hit the permission issue than one that only asks for specific fields.

Same tradeoff as the SPFx side, too: this flow-based check answers the question for whichever email the flow feeds into Get user profile (V2) — it isn’t automatically “the current user” the way pageContext.user.isExternalGuestUser is inside a web part. In a flow triggered by a form submission or an approval, that’s usually exactly what’s wanted (checking the submitter or approver, not whoever happens to be running the flow) — just worth being deliberate about which email actually gets passed in, rather than assuming it lines up with the flow’s own trigger identity.

Actually, It’s Already In The SharePoint PageContext! — more on what pageContext already gives you for free without an extra API call.

Now that’s another tip! Hope it helps somehow. Let me know if you have questions, or leave a comment if you have anything to add to the list of possible current-user checks.

Happy SharePointing! #SharingIsCaring