---
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
 3 minutes to read
Summarize
 Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
## Summary of Exploring Federated ID
The ServiceNow Identity system uses Federated ID to uniquely identify users across multiple ServiceNow instances.
This consistent identification enables accurate counting of unique users, which is critical for licensing and user management.
Federated IDs are generated by hashing selected ID Fields from thesysusertable and stored in thefederatedidcolumn.
Show full answer Show less
## Key Features
* **Configurable ID Fields:** By default, User ID (`username`) and Email fields generate Federated IDs, but you can customize which fields are used.
* **Unique Field Requirement:** At least one unique field must be included to ensure each Federated ID is distinct per user record. Unique fields are those enforced as unique in the database (single-column uniqueness).
* **Secondary Fields:** You can add non-unique secondary fields to supplement the unique field(s), but they cannot fulfill the uniqueness requirement alone.
* **Flexible Field Selection:** You may select multiple unique fields, and a Federated ID is generated if at least one unique field has a value. Records missing values in all unique fields do not receive a Federated ID.
* **Validation and Safety:** The system blocks saving configurations without a unique field and safely skips Federated ID generation runs if the unique field is missing, preventing errors.
* **Change Management:** Changing any ID field (unique or secondary) triggers regeneration of Federated IDs for all existing user records, which can impact integrations relying on existing IDs. This requires careful planning.
* **Plugin and Schema Updates:** The `Federated ID Generation (com.glide.identity.globalid)` plugin auto-installs on all instances, adding the `federatedid` column to `sysuser` and setting up default configurations.
## Practical Implications for ServiceNow Customers
Federated ID empowers customers to unify user identification across multiple instances for improved licensing accuracy and user management. Customers can tailor which user fields generate these IDs to match organizational needs, provided at least one unique field is included. Admins with the `iamsyncadmin` role can update these configurations, but should be aware that changes cause regeneration of all Federated IDs, potentially affecting integrations. This feature supports robust identity synchronization and reporting across complex ServiceNow environments.
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 sys_user 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 criteria 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 mandatory. You can select any unique field from the sys_user table as the required unique field. The User ID field itself qualifies as a unique field, so you can still use it if you want.
* 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 sys_user 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 needs 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."). The `iamsync_admin` role is required 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 criteria 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, Fed 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. Once 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.