Examples of Custom Action

Example 1: Python— based Custom Action for System Variables

  1. Use Case: Fetch environment variables dynamically

  2. When to Use: Dynamic values differ per system/environment

  3. Usage: This custom action is used when a Test Step needs to fetch a value (like a URL, username, or configuration setting) that is stored as an environment variable in the system. For example, if you're testing a login flow and the application URL or credentials change based on environment (Dev, QA, or Prod), instead of manually updating the test case every time, you can pass the environment variable name as input and retrieve its value dynamically during execution

4. Steps to create Custom Action:

  1. Add a Custom Action for @Generic Element

  2. Choose Python as the coding language

  3. Add input syntax for the variable name

  4. Write a code to fetch the environment variable

  5. Save the action

  6. Use dynamic input (e.g., TEMP, USERNAME)

  7. Pass output as input to next step̣

5. Code Snippet

6. Custom Action Code for Execution Flow: Step-by-Step Explanation

  1. The first step in the code is to use the OS (Operating System) library, which helps to connect with the system.

  2. Then, as per the code snippet it investigates the system’s environment variables, trying to fetch the value for the input variable name (e.g., "TEMP" or "USERNAME").

  3. If that variable exists, its value is stored in the variable named value

  4. This value can now be:

  • Displayed

  • Used in the next Test

  • Steps o Stored as output, so that other steps in the test can reuse it

  1. This custom action lets users dynamically fetch system-specific values at runtime based on the user’s input — making the test more flexible, portable, and maintainable across different environments.

Example 2: JavaScript Custom Action for Element Interaction in MS Dynamics 365

  1. Use Case: Perform actions not covered by default Test Steps (e.g., advanced DOM manipulation)

  2. When to Use: App-specific DOM manipulations or unsupported behaviours

  3. Usage: In complex enterprise applications like Microsoft Dynamics 365, menu items are often deeply nested and dynamically rendered. Direct interaction using standard Test Steps may fail due to unpredictable DOM structures or dynamic class attributes. Users can utilize Custom Action to simulate user navigation by dynamically selecting menu items passed as input (e.g., "Accounts payable, Payment, Vendor Payments journal). It enhances automation stability by programmatically navigating through layered elements using JavaScript, ensuring consistent interaction despite dynamic UI changes.

4. Steps to create Custom Action:

  1. Capture element in MS Dynamics 365

  2. Add a Custom Action

  3. Select JavaScript as the coding language

  4. Define input syntax to accept menu hierarchy

  5. Write a logic to split input and traverse elements based on labels

  6. Use querySelector and click() to simulate selection

  7. Save the action

5. Code snipper

6. Custom Action Code for Execution Flow: Step-by-Step Explanation

This Custom Action uses JavaScript to dynamically interact with layered menu items in MS Dynamics 365.

  1. The input value is passed as a comma-separated string (e.g., "Accounts payable, Payment, Vendor Payments journal"), representing the menu path the user wants to click through.

  2. The input is split into an array using .split(',') and .trim() to clean up any extra spaces, resulting in a list like ["Accounts payable", "Payment", "Vendor Payments journal"].

  3. The script then starts from a known DOM section (e.g., a div with arialabel="Modules") and:

  • Iterates through the list

  • Finds each matching label in the DOM

  • Simulates a .click() on each label, moving deeper into the UI structure.

  1. This step-by-step interaction mimics a real user manually navigating the menu

  2. Once executed, it ensures:

  • The correct menu item is selected

  • The UI is navigated consistently even if class names or positions change

  • Test failures due to dynamic rendering or nested menus are avoided

This approach makes your automation script robust, reusable, and capable of handling UI complexities typical in modern enterprise applications like MS Dynamics 365

Last updated

Was this helpful?