Debug mode provides an isolated testing environment within the workflow canvas where you can simulate workflow execution and validate task behavior. This replaces the time-intensive, error-prone process of manually mocking data using the stub task, significantly streamlining workflow testing. By simulating workflow inputs and task outputs, you can test and debug workflows predictably without external dependencies. You can mock tasks to simulate their behavior without executing against live systems, then create debug scenarios that use this mock data to validate your workflow’s behavior.
Before using debug mode, ensure you have:
From the Debug Configuration Panel, you can configure your starter scenario or create new scenarios.
Debug scenarios define the set of mock instance data and conditions used to validate your workflow. Each scenario represents a different test case or execution path of the workflow that you would like to validate within debug mode.
When you configure mock task data in your debug scenario and run it in debug mode, the system replaces real responses from external systems and built-in functions with the mock data you provided. This mock data is stored separately from the workflow itself, making it reusable across different workflows throughout the system.
In the Debug Task Panel that opens, click +. In the Create Mock Data dialog, provide values for the mock data fields: Name, Description (optional), Transition type, Delay (optional), Response type, and Response value.
The mock data output must match the structure of the real task response to ensure your workflow tests accurately. This output should also align with your workflow’s data transformation and variable mapping requirements.
By default, the transition type is set to Success, and the Response Type dropdown preselects the expected outgoing data type for the task. However, if the task isn’t available in the current environment — due to a missing adapter or custom application — no default will appear in the Response Type dropdown. When this occurs, refer to previous completed jobs for this workflow to determine the expected mock data response.
The following fields are available when creating mock data instances. Configure these fields to define how your mock data behaves during debug execution and what response it returns to the workflow.
A unique name for this mock data instance. Use descriptive names that clearly indicate what this mock data represents.
Example: Cisco IOS Target File Found
A brief explanation of what this mock data simulates or its purpose in testing. This helps other team members understand the test case and makes scenarios easier to maintain.
Example: Mocks Cisco IOS target file found during file verification
Specifies how the job should proceed after this mock response is processed. This determines the execution path your job will follow.
Valid values: Success, Failure, Error
The amount of time in seconds to wait before returning the mock data response. This simulates real-world processing delays and helps test timing-dependent workflow logic.
Example: 5
The data type of the mock data you are providing. This must match the expected workflow task output.
Valid values: Boolean, String, Number, Integer, Object, Array, Null
The mock data output that will be returned from your workflow task. This should match the structure and data types that the task expects from the actual external system.
After configuring your debug scenario and mock data:
To distinguish between mocked tasks and jobs and those run against their designed configuration, mock data is annotated with a yellow beaker icon.
To return to Design Time Mode from the debug mode screen, select Exit Debug Mode at the top of the canvas.
If your scenario fails to execute:
If the debug workflow execution differs from expectations:
After testing your workflow in debug mode: