Lab #2: User Identity & Service Account Setup

---

Key Concepts

The User Roster is the “brain” of Moveworks identity, determining who can interact with the Moveworks AI Assistant and what data belongs to them. Key components include:

• Source Connectors: The primary systems (usually an ITSM or IDAM) from which Moveworks pulls raw employee data to build the user roster.
• Filters: API query strings that narrow the records pulled from a source (e.g., only active users).
• Processors: Automated functions that clean or “resolve” data during ingestion, such as transforming a manager’s sys_id into a clickable name or calculating local time zones.
• Source Mapping (DSL Editor): A per-attribute editor where you define exactly which source field maps to each Moveworks profile attribute, with the ability to test the mapping against a real user before saving.
• Joining Keys: The unique identifier used to match a user across sources (e.g., email address).
• Bot Access Rule: A global logic gate (often set to TRUE or controlled via DSL) that determines if a user is permitted to interact with the AI Assistant.

Relevant Documentation:

• Moveworks Help: User Identity Overview
• Moveworks Help: Configuring User Ingestion
• Moveworks Help: Configuring the Service Account
• Moveworks Help: User Data Object

---

🛠️ 1: Walkthrough

1.1: Configure User Identity

The Identity Configuration is a 5-step wizard: Select sources → Configure source mapping → Override field mapping → Set Joining Keys → Test with user.

Step 1: Select Sources

1. In Moveworks Setup, enter identity into the search bar and navigate to User Identity > Identity Configuration. Select snow as your primary source connector.

   

2. Click Test to confirm the connector is reachable.

   

3. After you see Connector tested successfully, click Next: Configure Source Mapping at the bottom right.

   Secondary sources (for example, an HRIS or IDP) can be added under Add secondary sources. For this lab we are using snow as the single source of truth, so leave this empty.

   

Step 2: Configure Source Mapping

1. On the Configure source mapping step, locate your snow source row and click the person icon to the right.

   

   The person icon opens a View Sample dialog that shows real users returned by the source system. Use it to confirm your connector is reaching ServiceNow and pulling records before you continue configuring the mapping.

   If users are not returned, go back to your connector and verify that your credentials were entered properly.

   

2. Close the sample dialog, then click the filter icon next to your snow source to open the Edit: snow dialog.

   

3. On the Filters tab, click Add+ and set the API Query String to active=true. This ensures Moveworks only ingests active ServiceNow users.

   

4. Switch to the Processors tab, click Add+, select User Timezone Processor, and tick Enable processor.

   

5. Click Add+ again to add a second processor. Select Unified Resolve Manager Processor and tick Enable processor. This processor resolves each user’s manager reference into a usable Moveworks profile attribute.

   You can add more processors here (for example, Password Expiry) using Add+ if your environment requires them. For this lab, the User Timezone and Unified Resolve Manager processors are enough to demonstrate the pattern.

6. With both processors configured, click Confirm to save your changes and close the Edit: snow dialog.

   

7. After clicking Confirm, the dialog closes and you return to the source list. Click View Attributes on the snow row.

   

8. The row expands into the per-field mapping list, with sensible defaults for each attribute (for example, department maps from department.display_value). To inspect or override a mapping, click the pencil icon next to any attribute — we’ll use department as the worked example.

   

9. The DSL editor opens. Enter an email in Test this mapping for a user and click Test Rule to validate the mapping against a real ServiceNow record. When the result looks right, click Save.

   

   

   DSL Syntax Reference: The default rule pattern is $TRIM(IF <field> THEN <field>.display_value OR "" ELSE NULL). The left-hand side of each row is an attribute on the Moveworks User Object; the right-hand side is a Moveworks DSL (Bender) expression that reads from the source record. Detailed instruction on Moveworks DSL syntax and logic will be covered in a subsequent laboratory session.

10. Review the full list of mappings, then click Next: Override Field Mapping at the bottom right.

    

Step 3: Override Field Mapping

1. The Override field mapping step is only used when you have secondary sources and want a specific attribute to come from a non-primary source. Since snow is our only source, leave this empty and click Next: Set Joining Keys.

   

Step 4: Set Joining Keys

1. On the Set Joining Keys step, confirm the joining key for snow is set to the email mapping: $TRIM(IF email THEN email.display_value OR "" ELSE NULL). Click Next: Test With User.

   Why it Matters

   • Identity Resolution: Maps a chat user (e.g., Slack) to their backend records (e.g., ServiceNow).

   • Security: Ensures sensitive actions like password resets are tied to a verified, authorized identity.

   • Data Integrity: Prevents duplicate records during multi-source syncs.

   Requirement: A joining key must be unique, immutable (permanent), and present across all integrated systems.

   

Step 5: Test With User

1. On the Test with user step, enter the email of a ServiceNow user (use your own lab user, or the ServiceNow admin email) and click Show User Profile.

   

2. Review the Sample Results. You should see attributes like moveworks.first_name, moveworks.last_name, moveworks.email_addr, moveworks.role, and moveworks.department resolve to real values. Attributes flagged Null: Attribute not configured or Null: Primary source DSL evaluated to NULL are expected for fields you have not customized in this lab. When satisfied, click Save Configuration.

   

3. Confirm the Configuration passed test dialog, then click Proceed To Save.

   

---

1.2: Setup the Moveworks Service Account

1. Navigate to the Bot Account page, and add the corresponding information for the Moveworks Service Account user for each field

   

2. After you enter your configuration, Submit your changes

---

1.3: Set up Bot Access Rule

1. Navigate to User Identity > Bot Access, set the Bot Access Rule to TRUE

   

---

✅ 2: Verification & Next Steps

1. Wait for Processing:

   1. Now that we have configured the Moveworks User Identity Pipeline, we will need to wait for the user ingestion cycle to complete
      1. In a typical environment, the user roster refreshes every 4 hours
      2. If you are participating in a designated Moveworks Lab, your environment will refresh every 30 minutes.

2. Confirm Completion:

   1. Check the Imported Users page, and confirm that:
      1. You are able to find yourself in the user roster
      2. The Enabled Users & Bot Reachable Users is greater than 0
      3. You see when the ingestion cycle completed and when it is next scheduled to run

   

---

🪞 3: Reflecting on This Configuration

Through this guide, you’ve learned the following:

• How to configure Identity Sources within Moveworks using the 5-step Identity Configuration wizard
• How to filter source records (e.g., active=true) and apply processors like User Timezone and Unified Resolve Manager
• How to inspect and override individual attribute mappings using the DSL editor, including testing a rule against a real user
• How joining keys link a user’s identity across sources, and how to validate the end-to-end configuration with Test With User before saving
• How to create the Moveworks Service Account user
• How to enable access to the Moveworks AI Assistant
• That Moveworks ingests users at a regular cadence, and you can see the currently ingested users + cadence in the Imported Users page

---

⚙️ 4: Configuration Details

Use the table below to fill in the required fields accurately.