---
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


---

# Exploring Federated ID

# Exploring Federated ID {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read  
The ServiceNow Identity system uniquely identifies users across multiple instances and assigns each resolved user a unique Federated ID for consistent identification.

With Federated ID, you can accurately calculate the number of unique users across instances, which is useful for licensing and user management. You can generate Federated ID for Role and User on ServiceNow.

To identify and match users and roles across instances, the ServiceNow Identity system generates a Federated ID from the fields configured as the ID Fields for a table, using a hashing function, and stores the value in the `federated_id` column of
the <kbd class="ph userinput">sys_user</kbd> table. By default, the User ID and Email fields are used. You can change the fields used for generation to meet your requirements.  
Note:  
A Federated ID criterion must include at least one unique field. The unique field verifies that the generated Federated ID stays unique for each record on the selected table.

## Selecting ID Fields {#federated-id__selecting-id-fields}

By default, Federated ID generation lets you choose the fields used to generate Federated IDs, subject to these rules:

* The User ID (`user_name`) field is no longer required. You can select any unique field from the <kbd class="ph userinput">sys_user</kbd> table as the required unique field. The User ID field itself qualifies as a unique field, so you can still use it if you need to.
* At least one unique field must be selected. You can select more than one unique field.
* You can add secondary, non-unique fields from the <kbd class="ph userinput">sys_user</kbd> table, and add, remove, or change them at any time. Secondary fields don't satisfy the unique field requirement on their own --- for example, valid selections include (User ID, Email) or (a unique field, Email).
* A Federated ID is generated for a record only if at least one of its selected unique fields has a value. If you selected several unique fields, the record requires a value in just one of them. If all the selected unique fields are empty, no Federated ID is generated for that record (the Federated ID is null).

{#federated-id__ul_sp4_klp_vjc}

User ID and Email are used to generate Federated IDs by default. To change the fields used for generation, see [Update the ID fields for Federated ID generation](https://www.servicenow.com/docs/CyZ7_aK4Zz~hC_kqUv9Qgw "To generate new Federated IDs, you can either use the existing user resolution search criteria or update the criteria before regeneration."). You must have the `iamsync_admin` role to update the configuration.
Figure 1. Federated ID column in the Users list   

## Which fields qualify as a unique field {#federated-id__qualifying-unique-fields}

A field qualifies as a unique field only when its uniqueness is enforced on a single column. The following table shows which field types can be selected as the unique field.
{#federated-id__table_nng_twy_tjc__entry__2}

| Field type | Can be used as a unique field |
|-|-|
| Field marked unique in the dictionary | Yes |
| Field with a single-column unique database index | Yes |
| Field with a database index that isn't unique | No |
| Field that is unique only as part of a composite (multi-column) unique index | No |
| Non-unique field | No |
[ ]

{#federated-id__table_nng_twy_tjc}

## Validation {#federated-id__validation}

* If you save a criterion without a unique field, the save is blocked and the error At least one unique field is required for Federated Id generation. is displayed. The Federated ID Criteria form also shows a message guiding you to include at least one unique field.
* Before a Federated ID generation run begins, the system confirms that a unique field is configured. If a unique field is missing, the run is safely skipped instead of failing repeatedly.

Note:  
When the unique field data is empty, Federated ID is not generated.

## Changing the ID Fields {#federated-id__changing-fields}

You can change the unique field to a different unique field at any time.  
Important:  
Changing any ID Field --- unique or secondary --- regenerates the Federated IDs for all existing records on the table. Because downstream systems may rely on existing Federated ID values, changing the fields can break those integrations.

The Federated ID Generation (`com.glide.identity.globalid`) plugin is auto-installed on all instances. After the plugin is installed, the schema changes are as follows:

* A column `federated_id` in the sys_user table is created.
* A table, `iamsync_type`, is auto-populated with the default configuration for the sys_user table.