Lab #4: User Identity & Service Account Setup

---

Key Concepts

The user roster is the core of Moveworks identity. It determines 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 a default 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. This lab uses department as the 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. The Optional Lab: Data Syntax Language (DSL) and Optional Lab: Moveworks Bender cover the syntax in depth.

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) 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: Set Up the Moveworks Service Account

1. Navigate to User Identity > Advanced Settings > Bot Account and enter the values from the table above.

   

   The screenshot shows example values (admin@example.com, admin). Enter the machine_admin values from your notes.

2. Click Submit.

---

1.3: Set Up the Bot Access Rule

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

   

---

✅ 2: Verification & Next Steps

1. Wait for Processing:

   • Wait for the user ingestion cycle to complete. The user roster typically refreshes every 4 hours; lab environments may refresh more often.

2. Confirm Completion:

   • On the User Identity > Imported Users page, confirm that:
     • You can find yourself in the user roster
     • Enabled Users and Bot Reachable Users are greater than 0
     • The page shows when the last ingestion cycle completed and when the next one is scheduled

   

---

🪞 3: Reflecting on This Configuration

Through this lab, 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 configure the Bot Account for the Moveworks integration account
• 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.