Overview

DSL (Domain Specific Language) Builder and Validator is designed to simplify the creation, modification, and testing of DSL rules used across the Moveworks. DSL rules are integral to applying customer-specific business process via logic defined by a Moveworks specific syntax that is able to interfaces with various system contexts.

Types of DSLs

DSL fields can vary in complexity:

• Simple Expressions: Some fields take basic logical values like True or False.

• Context-Dependent Expressions: More complex DSL fields reference dynamic data contexts, allowing them to evaluate conditions based on specific inputs.

  • For example, user.email_addr in ['[email protected]'] requires the user context to evaluate correctly. This means the user must ensure the email_addr attribute is being ingested via Identity Ingestion.

    

  • Another example, is chaining multiple user attributes together in a single rule to create a Complex one like below. Here we are checking across two conditions - If the user has the state Contractor & If the user email is present in the list defined.

    

Key Features of Moveworks DSL Builder and Evaluator

Autocomplete

• The Builder now offers users autocomplete suggestions for valid fields within a given data context. For instance, typing user. prompts suggestions like email_addr, name, etc. This ensures users do not write rules with invalid or missing attributes or contexts.

📘

If you are ever unsure about what context a DSL Field supports in a Moveworks configuration, just click on the DSL Rule Box and it will list on the contexts supported.

• The Builder also takes nested attributes into consideration and auto completes the suggestions under the parent. For instance, here the attribute employment_info has other fields under it which can be selected like role, department, etc. which are also suggested.

  

Validate Syntax

• Every DSL builder has a button labelled “Validate Syntax” which evaluates the DSL expressions to ensure their correctness before evaluation. Moveworks highly recommends validating DSLs before saving a configuration.

  • Validation ensures the right attributes are being utilized in the DSL rule. If the DSL rule is invalid, the UI will raise an error regarding the problematic attribute.

    • e.g: In the example scenario below, the user mistyped email_adrrtherefore the following error was raised: email_adrr is not a valid key

      

  • Validation ensures the Syntax, indentation, structuring of IF ELSE Conditions are done appropriately.

    

  • When there is a Validation Error being throw, please reference the Errors Section below, which explains what the could be.

Run

• Allows real-time testing of DSL rules by including the context of the resource users are trying to test against. For instance we are testing the rule present in the Preview on top against the user selected from the Dropdown.
  Note : Only ingested users will list this dropdown.

  

• There are some DSLs Fields which support ticket context as well and are tested in the same way. In the tester here, you need to select the Connector for your ITSM system and enter a Ticket Number which will be polled to evaluate the rule against.

  

Best Practices to Follow

• When writing or editing an existing DSL rule ensure you understand the objective of, what the Rule will achieve on evaluation. This helps identify which context this rule will be written under as Moveworks has the below data contexts:
  • User
  • Ticket
  • Resource
  • Approval
• If the DSL Rule being written leverages custom attributes from a specific data context, ensure these custom attributes are suggested by the autocomplete feature.
• Before finalizing a DSL rule and submitting it, click on Validate Syntax feature to check for potential errors with the syntax or attributes being used.
  • Use the Error returned by the Builder to understand what the cause is and what resolution steps can be leveraged.
  • Here is a list of Errors which are returned by the DSL Tester that can be used to understand the root cause of the issue.
• It is always recommended to test individual parts of a complex DSL rule incrementally to ensure each component functions correctly before combining them and testing against the final rule.
  • For example if you have a single rule with 2 pieces of logic: (user.email_addr ENDS_WITH "company.com") AND (user.department == "Engineering"), you can decompose this into 2 rules and verify them individually as you are building the rule:
    • user.email_addr ENDS_WITH "company.com"
    • user.department == "Engineering" Verify the decomposed rules helps ensure that the final rule will work correctly, and makes debugging of the rule easier.

Usage of Customer Attributes

DSL fields across different plugins with the below contexts support custom attributes which can be defined in the Moveworks Attribute Registry. These are attributed which are specific to the customer environment.

1. User Management
2. Ticket Processing
3. Approvals
4. Knowledge Management

This is a required pre-requisite if you plan to use custom attributes across DSLs Rules. In order to learn more about Custom Attributes and How to create them please visit this Guide.