What is user identity?

Overview

Every employee in a organization has a unique system ID or profile in the systems with which Moveworks integrates (i.e. Chat, IDAM, ITSM, etc). For Moveworks to complete actions across systems on the behalf of a user, it needs to have knowledge of all of the system IDs for the given user. For example:

• When a user wants to check the status of their tickets, Moveworks only “sees” the user’s chat ID in the inbound message. To find and return the user’s tickets in the ITSM system, Moveworks needs to know that user’s ITSM System ID, as well as their Chat System ID.
• When Moveworks polls the Identity system for locked accounts, it only “sees” the System IDs for the accounts that are locked in the Identity System. To send lockout notification messages to those users in the chat system, it needs to be able to correlate those Identity IDs to the corresponding Chat IDs.

To support these scenarios, Moveworks builds a single unified User Profile for every user in an organization that contains user profile information as well as External Identities sourced from the various systems that Moveworks is integrated with. We commonly refer to these systems as "sources", and the Moveworks User Profile as the "Moveworks User Object".

User Import Process

To build the Moveworks User Profiles, Moveworks needs to import users from sources it is integrated with. This important process consists of the following steps:

1. Fetch: Pull the list of all user profiles from each source into a JSON file. This usually involves an operation to List all users per each source e.g: "GET /users"
2. Map: Once Moveworks has the raw profiles of the users, it takes the raw JSON user profiles and maps them to standardized Moveworks User objects, which is required for further processing.
3. Process: Once it has the preliminary user profiles for each source, it applies post-processing steps to the users. For example, UserGeocodeProcessor extract a user's geocode based on their country and gets used for Profile Boosting), and UserPasswordMetaInfoProcessor calculates the password expiry date using the password last set field. Similar to the UserGeocodeProcessor, and UserPasswordMetaInfoProcessor, there are a variety of other processors to filter, process, augment and enhance information on the Moveworks on the user profile.
4. Merge/Join: Lastly, Moveworks joins the processed profiles from each source together into the final Moveworks user profile. This joining process does the following:
   • It joins the system specific profiles based on a single merging attribute / joining key.
   • It assigns each Moveworks user profile a unique Moveworks User ID, which is a hash of the joining key.
   • It automatically extracts the external system id's from each source system and stores them under external_system_identities on the User Object.
   • It applies the mapping configuration that specifies from which source to gather each attribute from when constructing the final Moveworks User Object.

This entire process runs every 4 hours, and follows the Ingestion Schedule defined here.

Configuration options

Primary Source

It is extremely important to that a singular system is defined as the primary source when setting up user ingestion. Only users that exist in the primary source will be part of the final Moveworks user profiles. By default, all attributes in the Moveworks User Profile will be used from the primary source, unless explicitly configured to use a different source. It is important consider what makes a good primary source:

1. Data Completeness: All users exist in the primary source..
2. Filterability: The APIs exposed by the primary source allow for easy filtering.
3. Attribute selection: The APIs exposed by the primary source allow for explicitly selecting the attributes required.

Typically an ITSM system or Identity system is chosen as the primary source.

Joining Key

The Joining Key is the attribute that will be used to match user profiles across different ingestion sources. The value of the Joining Key is unique to each user. By default, Moveworks joins users using their email address. However, it is always recommended to configure a unique identifier such as employee ID, or any other GUID. This will help handle cases where multiple accounts have the same email address. e.g: admin accounts, service accounts, etc.

Cadence

By default, Moveworks imports users every 4 hours, but the cadence can be reduced to once a day if required.

Attributes

For each integration source, you can configure the attributes that Moveworks fetches from the source.

Filters

For each integration source, you can configure filters to filter out certain users from being imported into Moveworks. Common use cases for filters include:

• Filtering out Service accounts, conference rooms, or other accounts that do not correspond to real employees.
• Filtering out users from certain unsupported regions.

FAQs

Q: How are users deleted/removed?

A: When Moveworks polls your primary source system for users every four hours, it checks for new user profiles, updated user profiles, and deleted user profiles. If a deleted user profile is found, and if that profile continues to show as deleted in the user set over seven days, the user profile is permanently deleted. Seven days is the default window of time before a profile is deleted, but the deletion window can be configured to as low as one day.

Q: A user was able to talk to the Moveworks Copilot yesterday but today it alway responds with a message that begins: "Sorry..." or "I am not enabled"

A: If all messages are responding with the same error message, there are a few reasons this could be happening:

1. The user does not exist in the Moveworks Roster. This means they do not exist in the primary source, and therefore their user record is not making it to the final merged roster.
2. The user exists in the Moveworks Roster, but their chat integration external identity is not mapped. This means Moveworks cannot identify who the user is.
3. The user exists in the Moveworks Roster, but is not enabled for bot access. Usually the bot indicates this scenario as such, rather than sending a generic error message.

Q: A user is able to talk to the Moveworks Copilot and everything works as expected, but whenever they try to look up tickets or try to get access to a software/group, the bot responds with an error message.

A: This usually means the user exists in the roster, but similar to the above, their ticketing system ID or IDAM system ID is not mapped. Therefore the Copilot cannot take action on behalf of the user, because it is unable to understand who the user is in these systems.