ServiceNow Portal Routing - Why the Approver Role Will Break Your Redirect Logic

[sgrison]

When you build a Service Portal as the front door for end users, routing logic becomes critical. The goal is simple - end users land on the portal, everyone else lands on UI16. In my experience, getting that baseline working is straightforward. Keeping it working as you layer in more roles is where things get interesting.

The common approach is to check for a role like snc_internal and if that's the only role the user has, redirect them to the portal. It works well until you start assigning additional roles to end users for legitimate reasons.

A perfect example is the approver_user role. If an end user needs to approve requests through the portal rather than just via email, they need this role - it's a ServiceNow requirement. Makes sense. But the moment you assign it, that user now has two roles: snc_internal and approver_user. If your routing logic is checking whether the user has more than one role, or checking for the absence of specific roles, they'll get routed to UI16 instead of the portal. From their perspective, something is broken. From a technical perspective, everything is working exactly as configured.

The fix is to customize the SPEntryPage script include. Rather than a simple role count or generic check, you need logic that explicitly accounts for roles that can coexist with a portal user - approver_user being the primary example. The routing decision should be based on whether the user has any roles that indicate they're a platform user, not just whether they have more than one role.

In my experience, this is the kind of thing that surfaces post-go-live when your first wave of approvals goes out and end users start calling saying they can't get to the portal. Getting the SPEntryPage logic right upfront, and documenting which roles are considered portal-safe, will save you that conversation.