Optional Lab: 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 User Identity > Bot Access to see the DSL block you set in Lab #4.

2. Click into the DSL block and remove TRUE to see the available context, operators, and methods. Select user. from the dropdown to view the available attributes.

3. The DSL editor lists every attribute on the context object. You can build rules on any of these attributes.

4. Dot-walk into an attribute on the user object to see the available methods. Use $LOWERCASE() to normalize the attribute’s text so case differences don’t change the rule’s outcome.

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. Combine operators to layer logic. You can build a rule on any attribute ingested on the Moveworks User or Ticket object. Paste this block to see fields, case normalization, and combined operators together:

(
  (
    user.department.$LOWERCASE() IN ["it support", "engineering"]
    OR 
    user.role.$LOWERCASE().$MATCH("chief|vp|president").$LENGTH() > 0
    OR 
    user.email_addr.$LOWERCASE().$ENDS_WITH("@example.com")
  )
  AND NOT (user.role.$LOWERCASE().$MATCH("contractor|intern").$LENGTH() > 0)
)
OR 
(
  "bot_user" IN user.user_tags 
  AND 
  user.location.$LOWERCASE() IN ["us", "uk"]
)

7. After writing a DSL rule, always run these two checks:

   1. Select the Validate Syntax button to verify there are no syntax errors

   2. 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 to draft complex access rules. Describe who should (or shouldn’t) have access in plain language, and the Architect produces DSL with the nesting, methods, and operators filled in.

1. Open the Moveworks Agent Marketplace: click the ? icon in the upper right and select 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 @example.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 you built. Make sure you understand what it does and which functions, operators, context, and attributes it uses.
   2. Read the prompt you gave the DSL Architect. Note how much detail it takes to get consistent output.
2. Practice:
   1. After Lab #8, open the Ticket Filters configuration and add DSL rules that limit which tickets Moveworks can act on.

🪞 3: Reflecting on This Configuration

Through this lab, 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 use the DSL Architect to draft complex logic

🧠 4: Knowledge Check

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

DSL Rule to Test:

(
  (
    user.department.$LOWERCASE() IN ["it support", "engineering"]
    OR
    user.role.$LOWERCASE().$MATCH("chief|vp|president").$LENGTH() > 0
    OR
    user.email_addr.$LOWERCASE().$ENDS_WITH("@example.com")
  )
  AND NOT (user.role.$LOWERCASE().$MATCH("contractor|intern").$LENGTH() > 0)
)
OR
(
  "bot_user" IN user.user_tags
  AND
  user.location.$LOWERCASE() IN ["us", "uk"]
)