---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Policy-based login experience

# Policy-based login experience {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
The policy-based login experience routes each user to the appropriate authentication method based on administrator-defined policies, using an identifier-first login flow.

The policy-based login experience is a framework for personalizing how users sign in. Traditionally, the login page presents every authentication option to every user. The framework replaces that one-size-fits-all page with a routed
login: administrator-defined policies decide which authentication method each user is sent to, such as a single sign-on (SSO) provider or password-based authentication.

As a framework, the policy-based login experience defines the goal --- evaluate policies and route the user --- independently of any single implementation. The way that routing is presented to the user can evolve from release to
release.

The policy-based login experience introduces an identifier-first login flow. While accessing the login page, a user first enters an identifier such as a username or email address. Instead of presenting every option,
the instance evaluates administrator-defined policies and routes each user to the right authentication method --- an SSO provider or the local password page --- without requiring the user to choose.

You manage the policy-based login experience in the Authentication Console. To know more, see [Authentication Console](https://www.servicenow.com/docs/M4bpezEagqFdYJWXy6Bjrw "The Authentication Console enables administrators to configure and manage authentication behavior across a ServiceNow instance, including identifier-first login policies and related settings.").

## Identifier-first login policies {#next-gen-login-experience__section_cqx_pj5_kkc}

The central object in the experience is the identifier-first login policy. An identifier-first login policy controls how login is determined. Each policy maps a set of conditions to an authentication method. After a user enters an identifier, the instance evaluates the active policies and uses
the first matching policy to route the user. A policy brings together three things:

* Conditions --- the criteria that determine when the policy applies.
* Authentication method --- where the user is routed when the policy matches.
* Evaluation order --- the priority of the policy relative to other policies.

{#next-gen-login-experience__ul_dqx_pj5_kkc}

For more about policies, see [Identifier-first login policies](https://www.servicenow.com/docs/gz9Vg9MB68_d1HR2O3Nyjw "Identifier-first login is the framework the policy-based login experience currently uses. Identifier-first login policies, evaluated through the policy-based login experience, determine how the instance routes a user to an authentication method after the user enters an identifier."). For field descriptions used when building a policy, see [Identifier-first login policy field reference](https://www.servicenow.com/docs/OvSXj9wh3ojTnx7K7NRx7Q "Field descriptions for an identifier-first login policy in the Authentication Console.").

## How identifier-first login works {#next-gen-login-experience__ngle-how-it-works}

The identifier-first login flow operates in the following sequence:

1. The user navigates to the ServiceNow login page.
2. The user enters their identifier --- username or email address.  
   Note:  
   The identifier can be any <kbd class="ph userinput">sys_user</kbd> field. The user_name field is available, and the additional field can be configured in the `glide.authenticate.multisso.login_locate.user_field` property. This property is currently available on the SSO properties page.
3. The platform looks up the identifier in the `sys_user` table and evaluates identifier-first login policies in order of priority.
4. The first matching policy determines the authentication method:

   SSO login
   :   Routes the user to an organization identity provider. Available only when the Multi-Provider SSO plugin is installed and at least one identity provider is configured.

   Use Password
   :   Routes the user to log in with a username and password managed within the platform.
5. If no policy matches, the platform applies fallback logic:
   * If the user exists in the system, the platform checks for a user-level or company-level SSO source, then the default identity provider.
   * If the user does not exist, the platform checks for identity providers with auto-provisioning enabled. If one such provider exists, the user is redirected to it. If multiple exist, the user is shown the provider selection page. If none exist, the user is directed to the local password page.
   {#next-gen-login-experience__ul_kvp_n42_pjc}

{#next-gen-login-experience__ol_ivp_n42_pjc}

When the user is redirected to an SSO provider, the identifier entered on the identifier-first login page is passed as a `login_hint` query parameter to pre-populate the username field on the provider login page, where supported.

## Traditional login versus identifier-first login {#next-gen-login-experience__ngle-traditional-vs-ngle}

The following table compares the traditional login experience with the identifier-first login experience:
{#next-gen-login-experience__table_htp_n42_pjc__entry__2}

| Traditional login | Identifier-first login |
|-|-|
| All authentication options are shown on the login page. | Only the relevant authentication method is presented, based on the user's identity. |
| Single auto-redirect to one identity provider for the whole instance. | Policy-driven routing supports multiple identity providers across different user personas. |
| User must identify and select the correct login method. | Platform routes the user automatically after identifier entry. |
[ ]

{#next-gen-login-experience__table_htp_n42_pjc}

## Policy conditions {#next-gen-login-experience__section_tnx_pj5_kkc}

Because the user's identity is known once the identifier is entered, a policy can match on user-context attributes. The console supports the following condition attributes:

* IP address
* Role
* Group

{#next-gen-login-experience__ul_unx_pj5_kkc}

When a policy uses more than one condition, all of the conditions must be met for the policy to match.

## Authentication methods {#next-gen-login-experience__section_rlx_pj5_kkc}

Each policy specifies the authentication method to apply when the policy matches. The method routes the matched user to one of the following:

SSO login
:   Routes the user to an organization identity provider. Available only when the Multi-Provider SSO plugin is installed and at least one identity provider is configured.

Use Password
:   Routes the user to log in with a username and password managed within the platform.

## Getting started {#next-gen-login-experience__getting-started}

The policy-based login experience takes effect when the property is enabled and at least one active identifier-first login policy exists. To set it up:

1. Enable the experience in the Authentication Console. See [Activate the policy-based login experience](https://www.servicenow.com/docs/Si3sc37mZXa~NGw~6RWhMw "Activate the policy-based login experience so that you can create and manage the identifier-first login policies that drive the policy-based login experience.").
2. Create at least one identifier-first login policy. See [Create an identifier-first login policy for password authentication](https://www.servicenow.com/docs/xygA2Mc5fBXNKYcIdbXdiw "Create an identifier-first login policy that routes matching users to password-based authentication (a username and password managed within the platform).") or [Create an identifier-first login policy for SSO authentication](https://www.servicenow.com/docs/07gSc7m3fMNwQpahTbcJRA "Create an identifier-first login policy that routes matching users to a single sign-on (SSO) identity provider.").

{#next-gen-login-experience__ol_cwb_5j5_kkc}  
Note:  
Traditional login pages, such as `login.do` and `oauth_login.do`, remain functional and aren't affected by this feature.

## How policies are evaluated {#next-gen-login-experience__section_vjx_pj5_kkc}

The instance evaluates identifier-first login policies in order and applies the first policy whose conditions match the user. Use the evaluation order to control which policies are checked first. Only active policies participate in evaluation; a
deactivated policy is retained but skipped. For a fuller explanation, see [Policy evaluation order](https://www.servicenow.com/docs/2HikQKa2Kfo3YIfNc4zE8A "The instance evaluates identifier-first login policies in order and applies the first policy whose conditions match the user.").

## What happens when no policy matches {#next-gen-login-experience__section_c3x_pj5_kkc}

If no active policy matches the user, the instance applies the default routing: it uses the user's SSO source or the default identity provider (IdP), and falls back to the local login page if no IdP applies. If the instance can't
identify the user from the entered identifier, it follows auto-provisioning routing rather than revealing whether the user exists.