Overview

User ingestion is the process of replicating your user data into the Moveworks bot in order to educate it about your employees in a private and secure manner.

Once you click on Ingest Users, you will see a table that has a single configuration, it’s name, the last time it was updated and an edit button.

If you are doing this configuration for the first time you will see a create button.

Configuring User Ingestions

Step 1: Select sources

Select the connectors of the source system.

Primary source

This is where you select the connector of the system where all major attributes of your employees reside.

Primary source thus refers to your main system that you use for user management. Most commonly used systems are Active directory or Okta. This will be a source of truth in case there are conflicts between attributes of employees in different systems.

Secondary sources

All the other systems from where you want to ingest the attributes of your employees are secondary sources. Example: Your primary can be Okta or Active directory, and the secondary can be ServiceNow.

Tip: You might want some of the attributes of your users that reside in your ITSM for your ticketing plugin to work properly. Go ahead and add your ITSM connector under the secondary source in this case.

After selecting various sources, let's add filters and configure each of them.

Step 2: Configure selected sources

You will see a table with all the sources that you have previously selected. You can apply filters for each source. There can be different types of filters based on the source.

For example, if you have selected ServiceNow as a source, you are given two options for filters.

1. Generic source filter: This is where you can give the ServiceNow API query to filter out users who should and should not be part of your final user set. Filtering can be on the basis of geography, email, department and many more. You can go to ServiceNow API documentation here, to learn more.
2. Attribute selection: Go ahead and type the attributes of the users corresponding to the system that you are applying filters for.

For example, if manager details is an attribute for an employee in your ServiceNow instance and you do not want this attribute to be part of final user profile, you can skip adding this attribute under filters.

You can add multiple filters for multiple sources as well.

Step 3: Set join key

This is a very crucial step for creating the final user profile. After you have selected all your sources and added filters to each of them, you are given an option to select an attribute that is common for all the other sources. This attribute will be used as a key to merge all the user data from all the sources that you have configured. The final user data will have all the employees with a unique set of attributes.

Please note that the join key is a very crucial element in creating the final user profile. Hence, editing the join key later is not allowed.

Note: User email is most commonly selected as a join key since this attribute is common across all systems.

Step 4: User profile

This is the step where you define the overrides.

Let's understand with the help of an example. Consider a scenario where Okta is the primary source and ServiceNow is the secondary source. You have applied filters and selected the attributes for both the sources. You have seen the sample user set and are satisfied with the attributes that are about to be ingested, but there is an attribute called "department" which is defined in the attribute section for Okta. In the final user profile this attribute is crucial for you. But the value of this attribute is something that you do not want to pick from Okta but ServiceNow.

So basically you want the attribute "department" from Okta but you want it's value to be populated by an attribute called "user_department" from ServiceNow. This is the use case that you can execute by adding overrides.

For our example, the override will look something like this:

{

"department": {  
    "\_name": "snow.department"  
  }

}

Overrides are written in json format.

FAQ

Q: Are there any native filters applied to user ingestion?

A: Yes, for Azure user ingestion specifically, Moveworks will only ingest users that have accountEnabled eq true. This field must to be set to true, otherwise the Moveworks ingestion will skip over that user(s).