Debugging is the process of identifying and removing errors from a given project. Coupled with logging, it becomes a powerful functionality that offers you information about your project and step-by-step highlighting, so that you can be sure it is error-free.

Before attempting to debug a workflow, it’s a good idea to validate it by simply clicking Validate in the Execute tab.

All functions you can use while debugging are found in the Execute tab.

Breakpoints enable you to pause the execution of a project so that you can check its state at a given point. After a breakpoint has been triggered you can stop, go to the next step of the automation or continue the debugging process by clicking Stop, Step Over, Step Into or Continue.

Logging enables you to display details about what is happening in your project in the Output panel. This, in turn, makes it easier for you to debug an automation.

Step Into

Step Into is the functionality to be use when you want to closely analyze your activities while debugging step-by-step. When this action is triggered, the debugger opens and highlights activities in any container you might have in your workflow, such as flowcharts, sequences, or Invoke Workflow File activities. In the latter case, the invoked workflow is opened in a new tab in a Read Only mode.

If you’re sure such a container is free of possible issues, you can use Step Over to continue debugging without showing you what’s happening inside the container.

Step Over

Unlike the Step Into functionality, Step Over does not open the current container. When used, the action debugs the next activity, highlighting containers (such as flowcharts, sequences, or Invoke Workflow File activities) without opening them.

This action comes in handy for skipping analysis of large containers which are unlikely to trigger any issues during execution.

Break

Break allows you to pause the debugging process at any given moment. The activity which is being debugged remains highlighted when paused. Once this happens, you can choose to Continue, Step Into, Step Over, or Stop the debugging process.

It is recommended to use Break along with Slow Step so that you know exactly when debugging needs to be paused. This is because activities are highlighted during debugging only when Slow Step is active, or when using Step Into and Step Over.

An alternative to using Slow Step in this situation is to keep an eye on the Output panel and use Break on the activity that is currently being debugged.

Focus

Focus Execution Point helps you return to the current breakpoint or the activity that caused an error during debugging. The Focus button is used after navigating through the process, as an easy way to return to the activity that caused the error and resume the debugging process.

Alternatively, when debugging is paused because a breakpoint was reached, Focus can be used for returning to said breakpoint, after navigating through activities contained in the automation process.

A third case is when the debugging is paused either after using Step Into or Step Over and then navigating through the process. In this case, Focus returns to the activity that paused the debugging process.

Validate

The Validate action ensures that all variables, arguments, and imports are properly configured and used across the workflow. Validation issues can easily be identified by this icon.

Validation should be one of the first steps to take before executing workflows. You can think of Validate as a simple reminder to check variables, arguments, and imports.

Breakpoints

Breakpoints are used to purposely pause the debugging process on an activity which may trigger execution issues. You can place a breakpoint on any activity either by selecting it and clicking the Breakpoints button on the Execute tab, from the context menu, or by pressing F9 while the activity of interest is selected.

A single activity needs to be selected for a breakpoint to be toggled. You can, however, toggle as many breakpoints as you see fit.

When a breakpoint is set on an activity, it is enabled by default and carries the following icon .

To disable a breakpoint, simply select the activity and press F9 or click the Breakpoints button on the Execute tab. The breakpoint icon attached to the activity changes to the following icon icon state, suggesting that the breakpoint is disabled.

Use F9 or click the Breakpoints button on the Execute tab to remove a certain breakpoint in the selected activity.

The Remove All Breakpoints option enables you to delete all the breakpoints from the opened project.

The Enable All Breakpoints option helps you enable all breakpoints in the process at once. Consequently, the Disable All Breakpoints option disables all breakpoints, allowing you run your process in debugging mode without interruptions.

Slow Step

Slow Step enables you to take a closer look at any activity during debugging. While this action is enabled, activities are highlighted in the debugging process. Moreover, containers such as flowcharts, sequences, or Invoke Workflow File activities are opened. This is similar to using Step Into, but without having to pause the debugging process.

Slow Step can be activated both before or during the debugging process. Activating the action does not pause debugging.

Although called Slow Step, the action comes with 4 different speeds. The selected speed step runs the debugging process slower than the previous one. For example, debugging with Slow Step at 1x runs it the slowest, and fastest at 4x. In other words, the speed dictates how fast the debugger jumps from one activity to the next.

Each time you click Slow Step the speed changes by one step. You can easily tell by the icon, which updates accordingly.

Options

Debugging options allow you to focus on fragile parts in your workflow. As such, you can have UI elements highlighted during debugging, as well as all activities logged in the Output panel as they are debugged.

Note that these options can only be toggled before debugging, and persist when reopening the automation project. This is not applicable for invoked workflows, unless these files are opened in the Designer panel.

Highlight Elements

If enabled, UI elements are highlighted during debugging. The option can be used both with regular and step-by-step debugging.

Log Activities

If enabled, debugged activities are displayed as Trace logs in the Output panel. Please note that this option is enabled by default. Logs are automatically sent to Orchestrator if connected, but you can have them stored locally by disabling the Allow Development Logging option from the Settings tab in the Add or Edit Robot window.

Disabling Log Activities can be a way to send smaller log files to Orchestrator.

By default, the debugger logs activities so that each step appears in the Output panel. We recommend leaving it enabled for easier tracing, as you can see in the image below:

The issue here is that one or more input fields from the User Input sequence are blank, which is a True condition for the Flow Decision. You can tell this by the fact that, during debugging, the User Input sequence is executed twice, meaning that one or more fields were left blank during the first execution.

If you decide to disable the Log Activities option for debugging, Trace logs are not displayed in the Output panel. In the case of a normal execution with no errors, you only get to see the debug execution start and end times. However, adding a Log Message can help you determine where issues might occur.

For example, you can add a Log Message activity to inform you that, in this case, one or more input fields are empty. This message appears in the Output panel during debugging, even if the Log Activities option is disabled, as you can see below:

Remember that you can always filter the messages displayed in the Output panel by simply selecting the alert types of interest, or even clear all messages.

Note that by default all debugging logs are sent to Orchestrator. You can disable this by clearing the Allow Development Logging option from the Settings tab in the Add or Edit Robot window. If this option is disabled, debugging logs are only stored locally.

Break on Exceptions

The option is enabled by default and it triggers the Runtime Execution Error window, whenever an exception is detected during debugging. The execution stops and the activity which threw the error is highlighted.

• Break - the project remains in the paused state. The activity which threw the exception is highlighted and its arguments, variables, and exception details are shown in the Locals panel. The Output panel shows the whole execution during debugging and mentions the activity that faulted.
• Retry - attempts to execute the activity which faulted again and if the error is encountered again, the Runtime Execution Error pop-up message is shown again.
• Ignore - ignores the execution error and continues from the next activity.
• Continue - throws the execution error and stops the debugging, highlights the activity which threw the exception, and logs the exception in the Output panel. If a Global Exception Handler was previously set in the project, the exception is passed on to the handler.

If the Break on Exceptions option is disabled, the Runtime Execution Error window is displayed, containing information on the thrown exception, without the options described above.

Open Logs

Clicking Open Logs brings up the %localappdata%\UiPath\Logs folder where logs are locally stored. The naming format of log files is YYYY-DD-MM_Component.log (such as 2018-09-12_Execution.log, or 2018-09-12_Studio.log).