|
BRAZIL RELEASE Identifier-First Login: The right sign-in for every user Users tell ServiceNow who they are. Your policies in the Authentication Console decide where they sign in. |
At a glance |
|
|---|---|
| What | Identifier-First Login (IFL) asks users who they are before asking them to sign in, then routes them to the right authentication method. |
| Where | Configured in the new Authentication Console, for the platform login and for Service Portals. |
| How | IFL policies built from conditions like role, group, and IP address, each routing to an SSO identity provider or to local login. |
| Release | On by default for new Brazil instances. For upgraded instances it's opt-in, so nothing changes until you turn it on. |
Every login page asks the user a question. For a long time, that question was simple: enter your username and password. Or, with SSO, the page asked nothing at all and sent everyone to the corporate identity provider.
That works when everyone signs in the same way. It's no longer how most organizations use ServiceNow.
One instance, many kinds of users
A single instance today might serve employees, agents, customers, suppliers, contractors, new hires who don't have corporate credentials yet, and frontline workers who sign in a few times a month from their phones. Each group can need a different way to sign in:
| Who's signing in | How they might sign in |
|---|---|
| Employees | The corporate identity provider |
| A specific region or business unit | A second identity provider |
| Customers and other external users | A local ServiceNow account |
The login page is where all of that comes to the surface. Every method you enable becomes another field or button. Eventually users face a question they shouldn't have to answer: which of these is mine?
|
A second IdP breaks the default. One identity provider with auto-redirect works fine. Add a second for a new group, and there's no single right default—someone always lands on the wrong sign-in page. Different users need different paths from the same links. A large financial-services organization needed employees on its corporate network and external users to reach different identity providers, even when both clicked the same link in a notification. New hires hit SSO they can't use yet. Onboarding emails sent new hires to a corporate SSO page before their accounts existed. |
Administrators have worked around this with login scripts, custom login pages, and customized widgets. They work, but they're hard to maintain, hard to reason about, and make every upgrade riskier than it should be.
As ServiceNow instances support more users, personas, and authentication methods, the login experience has to answer an increasingly important question. How do we get each user to the right authentication experience without asking them to understand how authentication is configured behind the scenes?
What if users didn't have to choose?
| Traditional login page | Identifier-First Login |
|---|---|
|
Asks: "How do you want to sign in?" Username and password, Login with SSO, several identity provider buttons. Every option, shown to every user. |
Asks: "Who are you?" One field for a username or email. ServiceNow uses your policies to choose the next step. |
Users always know the answer to the second question. They don't need to know which identity provider their account belongs to, or whether "Login with SSO" applies to them. They just enter their username or email, and ServiceNow handles the rest.
The first step is one question every user can answer.
Introducing Identifier-First Login
With Identifier-First Login (IFL), the first step is intentionally simple: the user enters their identifier. ServiceNow evaluates the IFL policies you've configured and decides which authentication path that user should take.
The key idea is that IFL splits sign-in into two separate steps:
| Step 1: Identify | Step 2: Authenticate |
|---|---|
| The user enters a username or email. This isn't authentication. Nothing is verified and no session is created. ServiceNow only uses the identifier to decide what comes next. | The user signs in on the path ServiceNow chose: a password prompt, or a redirect to an identity provider that runs its own sign-in and any controls you've set up there. |
That separation is what makes the experience simpler for users and more flexible for you. Users see one clear field. You get one policy-driven place to decide where each user goes.
How it works
| 1. Identify | 2. Evaluate | 3. Route | 4. Authenticate | |||
|---|---|---|---|---|---|---|
| User enters a username or email | → | Active IFL policies are checked in order | → | The first matching policy picks the method | → | SSO identity provider or password page |
Steps 1–3: identification and routing. Nothing is verified yet. Step 4: the actual sign-in.
Each IFL policy answers three simple questions:
|
Who does it apply to? Conditions built from attributes such as role, group, and IP address. |
Where do they sign in? An authentication method: a specific SSO identity provider or local login. |
Which policy wins? An evaluation order. Lower order values run first, and the first match wins. |
Put your most specific policies first and the broadest last.
| What if nothing matches? IFL falls back to the default identity provider if one is configured, or to password login if not. |
Configuring the experience in the Authentication Console
The Authentication Console gives administrators one place to configure all of this without custom code. Admin users can open it from All > Authentication > Authentication Console.
| On the Policies tab, you can: | On the Settings tab, you control the experience for the whole instance: |
|---|---|
|
|
IFL policies in the Authentication Console. Order determines which policy takes precedence.
Build conditions without scripting and assign each policy an authentication method.
Instance-level settings for the policy-based login experience.
The biggest change is visibility. Login behavior that used to be spread across system properties, scripts, and customized pages now lives in a list of policies you can read top to bottom. When someone asks, "Where do contractors sign in?", the answer is a policy, not a script you have to trace.
Learn more: Authentication Console and Activate the policy-based login experience.
Bringing IFL to Service Portals
In the Australia release, we introduced portal-specific authentication. It let each portal choose its own identity providers and local login settings, with no Login widget customization.
IFL takes the next step. A portal can now decide the login experience by who the user is, not just by which portal they visit.
| Australia Portal-specific authentication The login experience depends on which portal the user visits |
→ | Brazil Identifier-First Login on a portal The login experience depends on who the user is |
To turn it on:
| 1 Open the portal record under Service Portal > Portals. |
2 In the Authentication Settings section, select Use portal-specific authentication, then select Identifier first login. |
3 Clear conflicting options such as local login and portal identity providers, because IFL takes precedence on that portal. |
4 Select Update. |
Turn on Identifier-First Login per portal, building on Australia's portal-specific authentication.
Users of that portal now see a username or email field first, and your IFL policies decide what happens next. Because this is set per portal, an employee portal can use IFL while a customer portal keeps its Australia-style configuration with local login only.
Learn more: Enable identifier-first login in Service Portal.
Designed for adoption
Changing how people sign in is high stakes, so we built IFL to be adopted deliberately.
- IFL is opt-in for upgrades—it's on by default on new Brazil instances. The new experience takes effect only when the policy-based login property is enabled.
- Portals opt in individually. Each portal chooses IFL on its own record, so you can roll it out one audience at a time.
- You can change policies without deleting them. Deactivate a policy to remove it from evaluation, and turn it back on later.
| Tip: Start in a sub-production instance. Map your users to policies, then sign in as a representative user from each one before you activate in production. Detailed login-flow debug logging shows exactly why a user went where they did. |
The foundation for what comes next
Identifier-First Login does more than tidy up the login page. It changes where the login decision happens.
Once ServiceNow knows who a user is before it asks them to authenticate, it can offer each user a path suited to them. That's why we see IFL as the foundation for a next-generation login experience on the ServiceNow AI Platform.
| Available now in Brazil | Where we're headed* |
|---|---|
|
|
*Capabilities described as future direction are not commitments. Any future features remain at ServiceNow's sole discretion, and purchasing decisions should be based on currently available functionality.
Getting started
| 1 Confirm the Multi-Provider SSO plugin is active and your identity providers are configured. |
2 List the users on your instance and how each one should sign in. |
3 Activate policy-based login and identifier-first login, then create your IFL policies in the Authentication Console, most specific first. |
4 Test with representative users in sub-production, with debug logging turned on. |
5 Turn on IFL for the Service Portals where it helps. |
Closing thought
The best login experience is the one users barely notice. They type their name, and they're where they need to be.
As ServiceNow instances serve more people in more roles, that only works if the platform does the thinking. Identifier-First Login moves that decision out of the user's hands and into policies you control.
If you're running multiple identity providers or serving multiple personas on one instance, I'd love to hear how you plan to use IFL.
