Lab #6a: Moveworks Data Syntax Language (DSL)

Key Concepts

DSL is the logic layer of Moveworks, allowing you to write custom “if-this-then-that” rules for access and filtering. Core concepts include:

• Context: The specific data object available to the rule. For example, a “Bot Access Rule” uses the user context, while a “Ticket Filter” uses the ticket context.
• Dot Walking: The syntax used to access nested properties within an object, such as user.department to check an employee’s org unit.
• Normalization: The use of methods like $LOWERCASE() to ensure that logic remains consistent even if source data has inconsistent capitalization.
• Operators: Logical tools (like ==, AND, OR, IN) used to build complex conditions, such as allowing access only to specific departments or locations. Relevant Documentation:
• Moveworks Help: Data Syntax Language Reference
• Moveworks Help: DSL Best Practices
• Moveworks Agent Marketplace: Agent Architect

🛠️ 1: Walkthrough

1.1: Building DSL Rules

1. Navigate to the Bot Access Rule to see an example of a Moveworks DSL block we have already leveraged
2. By clicking into the DSL Block & removing the pre-existing TRUE, we can see the available context, operators, and methods that are available for us to configure this. We will select the user. option from the dropdown to view the list of available attributes

3. When accessing a Moveworks Data Object’s context, the DSL evaluator will show all of the attributes associated with that object. We can use these attributes to build DSL rules that determine which types

4. Continue dot walking into an attribute on the user object. You will see the DSL manipulation methods that are available. Use the LOWERCASE method to normalize all of the text processed from the attribute, to ensure case mismatches don’t result in unexpected rule outcomes

5. Once you select a method, press Space to view the auto-populated list of Operators. These are used for logical comparisons and data manipulation. For instance, using IN allows you to compare an attribute against a list of values; it returns TRUE only if the attribute exists in that list. 6. We can add several different layers of DSL logic by combining operators. As long as an attribute is being ingested on the Moveworks User or Ticket object, you can build an access rule around it! Try adding the below block to see a combination of fields, case normalization, operator combination, and comparisons

1
(
2
  (
3
    user.department.$LOWERCASE() IN ["it support", "engineering"]
4
    OR 
5
    user.role.$LOWERCASE().$MATCH("chief|vp|president").$LENGTH() > 0
6
    OR 
7
    user.email_addr.$LOWERCASE().$ENDS_WITH("@example.com")
8
  )
9
  AND NOT (user.role.$LOWERCASE().$MATCH("contractor|intern").$LENGTH() > 0)
10
)
11
OR 
12
(
13
  "bot_user" IN user.user_tags 
14
  AND 
15
  user.location.$LOWERCASE() IN ["us", "uk"]
16
)

7. After configuring a DSL rule, you should ALWAYS PERFORM the follow two checks: a. Select the Validate Syntax button to verify there are no syntax errors b. Select Run to compare your DSL rule against a user or ticket which you know should pass & fail, and confirm your rule is working as expected

1.2: Using Moveworks Agent Architect to Construct DSL Rules

Use the Moveworks DSL Architect when trying to create complex DSL rules to restrict access. The architect allows you to turn natural language requirements into ready-to-use DSL code. Simply describe who should (or shouldn’t) have access, and the Architect will handle the nesting, methods, and operators for you.

1. Navigate to Moveworks Agent Marketplace by clicking the ? icon in the upper right hand corner and selecting AI Agent Marketplace
2. Select Create -> Agent Architect
3. Select DSL Architect
4. Input the following prompt to see how DSL Architect can help you construct DSL rules:

Create a DSL rule for Bot Access that allows users in the IT Support or Engineering departments. I also want to include anyone with a ‘Chief’, ‘VP’, or ‘President’ role, as well as anyone with a @company.com email_addr. However, even if they meet those criteria, we must exclude anyone whose role contains the words ‘contractor’ or ‘intern’. Lastly, regardless of the above, always allow access for users tagged with a user_tag ‘bot_user’ if their location is in the US or UK. Normalize all variable text comparisons to lowercase. Recall that all fields will be nested under the user object

✅ 2: Verification & Next Steps

1. Confirm Understanding:
   1. Read the DSL rule we constructed. Understand exactly what it is doing, and what functions, operators, context, and attributes are available
   2. Read the prompt provided to the DSL architect. Understand the level of specification to ensure a consistent output that meets the designated criteria
2. Practice:
   1. After implementing Moveworks & ServiceNow Ticketing, go to the Ticket Filters configuration, and add DSL rules to limit what types of tickets Moveworks can action on

🪞 3: Reflecting on This Configuration

Through this guide, you’ve learned the following:

• What Moveworks DSL rules are used for
• What content is available within a Moveworks DSL block (operators, bender methods, relevant context, attributes)
• How to construct & validate a DSL rule
• How to access and leverage the DSL Architect to aid you in creating complex logic

🧠 4: Knowledge Check: Lab #6a

1. What does “context” mean in a Moveworks DSL block?

• Answer: Context is the data object available to the rule — for example, user context gives access to user attributes like department or role, while ticket context gives access to ticket fields.

2. Why should you always use $LOWERCASE() when comparing text values in DSL?

• Answer: Source data may have inconsistent capitalization (e.g., “IT Support” vs “it support”). Normalizing with $LOWERCASE() ensures comparisons work regardless of how the data was entered.

3. What are two ways to validate a DSL rule before applying it in production?

• Answer: (1) Use the Validate Syntax button to check for syntax errors, and (2) use the Run button to test the rule against a real user or ticket to confirm expected pass/fail behavior.

4. When would you use the IN operator instead of == in a DSL rule?

• Answer: Use IN when comparing a single attribute against multiple allowed values (e.g., user.department.$LOWERCASE() IN ["it support", "engineering"]). Use == for a single exact match.

⚙️ 5: Configuration Details

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