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.

How does Moveworks User Import handle duplicate users?

As long as the count of duplicate users is < 5% of total users within an organization, Moveworks will not halt the identity pipeline, and continue importing users.

Those accounts that have a duplicate associated with them will be dropped and need to be resolved by following the steps mentioned in our documentation here.

Configuration options

View the configuration guide here for details on configuring Moveworks User Identity when implementing Moveworks.

If you have already implemented Moveworks, the how-to guides for other common configuration tasks.

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.

Q: A user was able to talk to the Moveworks yesterday but today it always 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 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, action cannot be taken on behalf of the user, because it is unable to understand who the user is in these systems.

Q: What fields exist on the Moveworks User Object?

A: Please refer to the User Attribute Reference documentation to see the fields on the Moveworks User Object.