Automation Implementation Methodology

The Automation Implementation Methodology to provide a common roadmap for implementation teams
across the globe.

Depending on the organization's automation program maturity, without having a well-thought-through

and tested plan, implementing a new automation project may prove quite difficult. This methodology also
ensures consistent quality, faster and more reliable implementations, and quicker process handovers.

we’ll look at the different setups for the implementation of automation projects and set the stage for a
methodology that can be applied to all of them.

Automation Implementation Methodology is designed to exhibit versatility, flexibility,

and relevance across various scenarios implementing automation projects.

The first model is the self-sufficient organization. In this, inside the same enterprise, there is a department
taking the role of the Client by requesting an automation, and then there's an automation Center of
Excellence (CoE), providing the expertise and capacity to implement the automation through an
Implementation Team.

The second model involves an organization looking to automate its business processes. Business
Automation Platform and assuming only the role of the Client. Lacking the internal expertise for
implementation, the organization turns to an external automation services provider and typically official
partner, which can provide the required expertise and capacity through an Implementation Team.

In the third model, the Client organization obtains both the licenses and the implementation services. In
this scenario, Professional Services team sets up an Implementation Team to provide the required
services.

In many cases in which an organization is serious about its transformation goals by managing numerous
projects at the same time as part of extensive business automation programs, it adopts a fourth
model that combines elements from both the second and the third models. This involves getting both
capacity and an external partner to fulfil their diverse implementation requirements.

As companies advance with their vast automation programs, they typically start to develop the internal
expertise to source, develop, and manage automation programs and projects. So, there is a natural
progression towards the first model and establishing an in-house Center of Excellence and Implementation
Teams.

The Automation Implementation Methodology guarantees successful automation delivery, focusing on

creating value, ensuring quality, and managing the overall experience.

Debugging

Debugging is the process of identifying and removing errors that prevent the project from functioning
correctly. It is recommended to perform debugging during the design stage of the automation project, at
activity, file and project level.

Debugging can be performed using several options, defined in the ribbon and explained in the Debugging
Actions page.
By default, debugging is performed on the local robot. You can run or debug your projects using a robot
on a remote machine by enabling remote debugging. Several panels make it easier to view the debugging
process, add values or monitor variables and arguments.

Start Debugging
The options for running and debugging a file or project are available both in the Design and Debug tabs.

Debug

Click Debug or use F5 to debug the whole project.

Run

Click Run or use Ctrl + F5 to run the whole project.

Debug File

Click Debug File or use F6 to debug the current file.

Run File

Click Run File or use Ctrl + F6 to run the current file.

The default action under Run/Debug ribbon button can be configured from Backstage View > Settings >
Design tab. Pick from Debug File, Run File, Debug Project, or Run Project, as the default action when
clicking the button.

During debug, click the Break button to pause. The activity which is being debugged remains highlighted
when paused. Once this happens, you can choose other debug actions like Step Into or press Stop to exit
and return to design mode. The keyboard shortcut for the Stop button is F12.

It is recommended to use Break along with Slow Step so that you know exactly when debugging needs to
be paused.

The Continue option is available when the debug process is paused.

Test Activities

Test Activity

The Test Activity context menu option—part of the Designer panel—is used for running a test on the
currently selected activity. When clicked, the Locals panel opens displaying the variables and arguments
in scope.

Test Activity can be used in two ways:

• Add default values to properties and test.

 • Add arguments and/or properties to activity properties and use the Local panel to add values after
clicking the Test Activity option.

Double-click the value field of a variable or argument, or click the icon in the Locals panel, and add a
new value. Next, click Step Into to focus and execute the activity, and monitor the variable or argument's
value in the Locals panel.

The same is available when clicking Continue, but the values are not visible in the Locals panel.

Please take into consideration that dynamic checks when variables depend on other variables that are
defined later are not supported.

Execution logs generated by the Test Activity action are visible in the Output panel. Exceptions in Studio
can be bubbled up, which means that the exception may be passed to parent containers in case it may be
handled by them.

The Test Activity option is not available during debugging.

Example of Using Test Activity

For the If Activity example, a process that asks the user for two numbers, checks to see if one is divisible
by the other, and depending on the result, displays a different message in the Output panel.

To check the behavior of the If activity defined in the process, use the Test Activity option, as illustrated
below:
The Test Activity action places the activity in the debugger and asks you for values to variables. Once
provided, click the Continue button for the debugging process to continue. In this particular case, a
message was written in the Output panel with the correct answer, which means that the expressions
written in the If activity were correct.

Create Test Bench

The Create Test Bench option allows for the creation of automation building blocks, which can then be
tested and added to the final workflow.

It is used for testing activities, working with variables and debugging the process. All this is done in a test
bench workflow, a temporary sequence that’s not part of the current project and that is discarded when
closed.

The Create Test Bench option is similar to the Test Activity option, with the exception that the latter is
contained and defined in an actual workflow.

To use the Create Test Bench option, go to the Activities panel search bar or use Ctrl + Alt + F keyboard
shortcut. Type the name of an activity and right-click to open the context menu.

Select Create Test Bench and the activity is automatically added to a sequence file not included in your
project. From there you can add other activities, change their default properties and debug the process.
The Output panel displays any logs or errors found during the debugging.

To save the file to your project, simply use the ribbon option Save as, add a file name and save it to the
same file path as your project.

Please note that Create Test Bench does not work with Pick Branch activity.

Run to this Activity

The Run to this Activity option is available when right-clicking an activity in the Designer panel.

This option starts the debugging process and pauses before the selected activity is executed while
highlighting it in the panel. If Run to this Activity is triggered when debugging is already paused, the
execution continues until the activity is reached.

Run from this Activity

The Run from this Activity context menu option enters debugging in a pause state, allowing you to make
changes to the values of variables and arguments from the Locals panel. Press Continue to start debugging
or use actions such as Step Into, Step Over, Step Out.

Debugging Actions

Debugging of a single file or the whole project can be performed both from the Design or Debug ribbon
tabs. However, the debugging process is not available if project files have validation errors.
Step Into

Use Step Into to debug activities one at a time. When this action is triggered, the debugger opens and
highlights the activity before it is executed.

When Step Into is used with Invoke Workflow File activities, the workflow is opened in a new tab
in ReadOnly mode and each activity is executed one by one.

The keyboard shortcut for Step Into is F11.

Step Over

Unlike the Step Into action, 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.

Step Over is available using the F10 keyboard shortcut.

Step Out

As the name suggests, this action is used for stepping out and pausing the execution at the level of the
current container. Step Out completes the execution of activities in the current container, before pausing
the debugging. This option works well with nested sequences.

Step Out is available using the Shift + F11 keyboard shortcut.

Retry

Retry re-executes the previous activity, and throws the exception if it's encountered again. The activity
which threw the exception is highlighted and details about the error are shown in the Locals and Call
Stack panels.

Ignore

The Ignore action can be used to ignore an encountered exception and continue the execution from the
next activity so that the rest of the workflow can be debugged.

This action is useful when jumping over the activity that threw the exception and continuing debugging
the remaining part of the project.

Restart

Restart is available after an exception was thrown and the debug process is paused. The action is used for
restarting the debugging process from the first activity of the project. Use Slow Step to slow down the
debugging speed and properly inspect activities as they are executed. When using this option after using
the Run from this Activity action, the debugging is restarted from the previously indicated activity.

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, 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.

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.

From the Breakpoints context menu, you can select Focus to highlight the activity with the breakpoint.

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.
Execution Trail

The Execution Trail ribbon button is disabled by default. When enabled, it shows the exact execution path
at debugging. As the process is executed, each activity is highlighted and marked in the Designer panel,
showing you the execution as it happens:

• executed activities are marked and highlighted in green;

• activities that were not executed are not marked in any way;

• activities that threw an exception are marked and highlighted in red.

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. Note that Highlight
Elements and Log Activities 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.

Logs are automatically sent to Orchestrator if connected, but you can have them stored locally by disabling
the Allow Development Logging option from the Robot Settings tab in the Add or Edit user window.

Disabling Log Activities can be a way to send smaller log files to Orchestrator.
When running processes from Studio, the logs sent to Orchestrator are always Trace when Log Activities
is disabled, and Verbose when Log Activities is enabled. This overrides both the Robot and the
Orchestrator setting.

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.

Continue on Exception

This debugging feature is disabled by default. When disabled in the ribbon, it 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.

When enabled, the exception is logged in the Output panel, the execution continues.

Picture in Picture

The Picture in Picture ribbon option in the Debug tab is available for both executing and debugging
processes or libraries in a separate session on your machine.

If enabled, whenever you select Run or Run File, Debug or Debug File the process starts either in a
separate session or in a virtual desktop in the user session. If Picture in Picture is disabled, debugging and
execution is performed in the current session.
Having the option to run a process in Picture in Picture (PiP) can be very useful in attended automation.
Verify whether a process runs successfully in PiP, and then update the project settings to indicate if it can
be executed using this feature after it is published:

1. In the Project panel, click Settings to open the Project Settings window.

2. In the General tab:

• PiP Options - Indicate whether the project was tested using Picture in Picture and whether
it should start in PiP by default.

• Tested for PiP usage; Starting in PiP - The automation has been approved to run
in PiP mode. When run, it starts in PiP by default.

• Tested for PiP usage; Not starting in PiP by default - The automation has been
approved to run in PiP mode. When run, it starts in the main session or desktop
by default.

• Not tested for PiP usage - The automation has not been approved to run in PiP
mode. When run, it starts in the main session or desktop by default. If run in PiP,
a dialog informs the user it was not tested using this feature and prompts for
confirmation before proceeding.

• PiP Type - Select how to isolate the automation from the user session when running the
project in PiP: New Session (child session on the machine) or New Desktop (virtual
desktop in the user session).

For more information, including limitations of this feature, see Picture in Picture in the Robot Guide.

Remote Debugging

When this feature is enabled, all run and debug operations are performed on a specified remote robot
instead of the robot installed locally, allowing you to test the automation on different environments. For
more information, see Remote Debugging.

Profile Execution

You can identify performance bottlenecks in the workflow when you debug the file. For more information,
see Profile Execution.

Open Logs

Clicking Open Logs brings up the %localappdata%\.\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)

The Breakpoints Panel

Breakpoints are used to purposely pause the debugging process on an activity which may trigger execution
issues. Setting a condition and/or hit count turns the simple breakpoint to a conditional one. Adding
logging results turns the conditional breakpoint in a conditional tracepoint. Adding only a logging message
transforms the breakpoint to a simple tracepoint.

You can place and modify a breakpoint on any activity as follows:

• from the context menu, right-click an activity and select Toggle Breakpoint;

• by selecting the activity, and clicking the Breakpoints button on the Debug tab;

• by pressing F9 while the desired activity 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. Make sure that the order of activities in the workflow is not changed after the
breakpoint is set.

Each breakpoint or tracepoint receives a specific icon based on its state. The icon is set on the activity and
visible in the Breakpoints panel.

Type Description

Breakpoints Breakpoints pause the debugging process before the activity is executed.
Breakpoints can have the following states:

• Enabled -

• Disabled -
 Type Description

Conditional Conditional breakpoints are breakpoints that depend on a set condition and/or
Breakpoints a hit count. Conditional breakpoints can have the following states:

• Enabled -

• Disabled -

Tracepoints Tracepoints are breakpoints with set logged messages. When the tracepoint is
reached during debugging, the message is logged at trace level. Tracepoints can
have the following states:

• Enabled -

• Disabled -

Conditional Conditional tracepoints have a set condition or hit count, and a logged message.
Tracepoints The message is logged when the condition is met the number of times stated in
the hit count field. Conditional tracepoints can have the following states:

• Enabled -

• Disabled -

To modify the state of a breakpoint or tracepoint select the activity and press F9, click the icon in
the Breakpoints panel, or use the Designer or Breakpoints panel context menus. You can also click
the Breakpoints button on the Debug tab, open the drop-down menu and click Toggle Breakpoint.

Note: Breakpoints set during design time persist when reopening the automation project. Breakpoints
don't persist at runtime, only at debugging.

Select a breakpoint in the panel and click the Delete button to remove it. The Delete all breakpoints option
enables you to delete all the breakpoints in the current project. The Enable all breakpoints option helps
you enable all breakpoints in the currently opened project. Consequently, the Disable all
breakpoints option disables all breakpoints. Multiple selection is available in the Breakpoints panel.

Breakpoint Settings

The Breakpoints panel comes with a set of settings that can be individually adjusted for each toggled
breakpoint part of the automation project. Click the icon to open the window.
Note: Please take into consideration that any expression added in the Condition field is not validated.

Field Descriptions for Breakpoint Settings

The Breakpoint Settings window has the following options:

Option Description

Condition The condition for the breakpoint. If the condition is met during debugging, the
execution breaks and the activity is highlighted.

Hit Count Specifies the number of times the condition must be met before the execution
breaks. If the hit count is higher than the number of times the condition can be
met, the execution does not stop upon encountering the breakpoint. The
maximum hit count value is 32,767.

Log Message Specifies the message to be logged at trace level when the condition is met. The
message is visible in the Output panel. If a condition is not set, the message is
still logged.

Continue If selected, the execution is not paused when the condition is met and the
execution specified message is logged. Available only if a log message was previously set.
when logging

Settings for any breakpoint in the project are visible upon hovering the breakpoint in the Designer panel.

The Breakpoints Panel

The Breakpoints panel displays all breakpoints in the current project, together with the file in which they
are contained. The Activity Name column shows the activity with the toggled breakpoint, while the File
Path column displays the file and its location.

The Condition column displays conditions set to breakpoints. The Log Message column shows messages
to be logged if the condition is met. Hover over the breakpoint tag on an activity to view its condition and
log message.

Double-click on a breakpoint to see the activity highlighted in the Designer panel. Use context menu
options or the Breakpoints button in the ribbon to enable or disable breakpoints.

To delete multiple breakpoints, select them and click Delete in the context menu, or the Delete button in
the panel. This removes the breakpoints from the current file.

The Delete all, Enable all and Disable all breakpoints buttons perform actions on all breakpoints listed in
the panel, regardless if they are selected or not.

Context Menu for Breakpoints

Right-click an item in the Breakpoints panel to open the context menu with the following options:

Option Description

Delete Deletes the selected breakpoints.

Focus Jumps to the breakpoint in the Designer panel.

Enable Enables the selected breakpoints.

 Option Description

Disable Disables the selected breakpoints.

Settings Opens the Breakpoint Settings window for adding a condition to the breakpoint.

Note: Breakpoint conditions are not evaluated when using Validate File or Validate Project.

Known Limitations in Windows-legacy Projects

Execution does not pause when a breakpoint is hit if the workflow contains:

• A UI Automation activity where any option is selected for the Wait for page load property.

• Two variables of different types that are called using the same expression.

Panels:

The Watch Panel

Similar to the Call Stack panel, the Watch panel is only visible during debugging. It can be set to display
the values of variables or arguments, and values of user-defined expressions that are in scope. These
values are updated after each activity execution while debugging.
 Column Description

Expression The variable, argument or expression to be monitored.

Value The value of the variable, argument or expression.

Type The type of variable, argument or expression.

Variables or arguments can be added to the Watch panel in the following ways:

• In the Watch panel, click the Add Watch field and type the name of the variable or argument;

• In the Locals panel, right-click a variable or argument and select Add to Watch;

• In the Variables or Arguments panel, right-click a variable or argument and select Add Watch.

To copy a value from the Watch panel, select the value, right-click and select Copy.

To remove one or more entries from the panel, right-click and select Delete or Clear All.

The Immediate Panel

The Immediate panel is only visible during debugging, and it can be used for inspecting data available at
a certain point during debugging. It can evaluate variables, arguments, or statements. To do so, simply
type the variable or argument name in the Immediate window and press Enter.

The Immediate panel keeps the history of previously evaluated statements, and they can be removed
using the Clear All context menu option.
To remove a single line from the panel, select the text and press the Space key. When clicking inside a line
and starting to type, the text is added to the input field.

Please take into consideration that the guidelines for calling a function apply to the Immediate panel as
well, and parentheses should be used.

If you have a List<string> variable, it is recommended to use parentheses to view object-specific methods
in the Intellisense window. For example, use Names.First().ToUpper instead of Names.First.ToUpper to
capitalize the first element in a list of names.

Context Menu for the Immediate Panel

Right-click in the Immediate panel to open the context menu with the following options:

Option Description

Copy Click Copy or use Ctrl + C to copy the selected text to clipboard.

Clear All Use this option to clear all lines in the panel.

Show IntelliPrompt Use Ctrl + Space to open IntelliPrompt.

The Call Stack Panel

The Call Stack panel displays the next activity to be executed and its parent containers when the project
is paused in debugging.

The panel is displayed during execution in debug mode and it gets populated after using Step
Into, Break, Slow Step, or after the execution was paused because an error or a breakpoint was
encountered.

Double-clicking an item in the Call Stack panel, focuses and highlights the selected activity in
the Designer panel.

If during debugging, an activity throws an exception, it is marked in the Call Stack panel and the activity is
highlighted in red.

Profile Execution

Overview

Use Profile Execution to identify performance issues in workflow executions.

How it works

When you run or debug a workflow, Profile Execution provides a performance analysis of all the
operations, showing you a cumulative percentage of the execution time of each activity.
Considerations

• Profiling data generated during debugging might be different from data generated during
production (running the file).

• The data is stored for each session

in C:\Users\username\AppData\Local\.\ProfiledRuns (see Import previous profiling sessions).

Analyzing profiling results

To profile an execution, run a file or debug the file, then go to the Debug ribbon tab.

Make sure that your automation works correctly without slow performing workflows. If you identify
potential flow issues, you can review workflows that take longer to be completed. Use the context menu
for profiling to take actions.
The Execution Details at the bottom of the Profiling tab shows the number of executions and descriptive
statistics such as the average duration and the minimum and maximum duration values.

Import profiling session

You can import profiling sessions to examine previous runs. Focus is disabled on imported profiling
sessions.

Context menu for profiling

Action Description

Open Right-click the parent file in the Profiling tab and select Open to jump to the
selected workflow.

Focus Right-click an activity and select Focus to center the Designer panel view on
the selected activity.

Search Use the search function to look for specific activities.

 Action Description

Expand/Collapse Use Expand All and Collapse All to bring to view or collapse all activities.
All

Types of Logs

The .® Platform has logging capabilities for all of its main components. All of the . specific logs are based
on the Nlog infrastructure.

These logs can be classified by several characteristics, as follows:

Log Category

Judging by the log category, which describes whether the log message was designed by the user or is
automatically generated by the system, logs can be:

• Default Logs - generated by default when the execution of a project starts and ends, when a
system error occurs and the execution stops, or when the logging settings are configured to log
the execution of every activity. The events logged by this category are:

• Execution Start is generated every time a process is started (Level = Information)

• Execution End is generated every time a process is finalized (Level = Information)

• Transaction Start is generated every time a transaction within a process is started (Level
= Information)

• Transaction End is generated every time a transaction within a process is finalized (Level
= Information)

• Error Log is generated every time the execution encounters an error and stops (Level =
Error)

• Debugging Log (Level = Trace) is generated if the Robot Logging Setting is set to Verbose
and contains, activity names, types, variable values, arguments etc.

• User-Defined Logs - generated according to the process designed by the user in Studio, when
using the Log Message activity or the Write Line activity.

Log Fields

Default fields

• Message - The log message.

• Level - Defines the log severity.

• Timestamp - The exact date and time the action was performed.

• FileName - The name of the .xaml file being executed.

 • jobId * - The key of the job running the process.

• processName * - The name of the process that triggered the logging.

• processVersion * - The version number of the process.

• windowsIdentity - The name of the user that performed the action that was logged.

• robotName * - The name of the Robot (as defined in Orchestrator).

• machineName - The name of the robot machine.

• machineId * - The id of the robot machine.

• organizationUnitId * - The ID of the Orchestrator organization.

* Log fields marked with an asterisk cannot be overridden using the Add Log Fields activity.

Note: The processName and processVersion might not appear if the process is run locally without
connection to the Orchestrator.

Type-specific fields

These log fields are present depending on the log type:

• totalExecutionTimeInSeconds for Execution End

• totalExecutionTime for Execution End

• queueName for Transaction Start and Transaction End

• transactionID for Transaction Start and Transaction End

• transactionState for Transaction Start and Transaction End

• transactionStatus for Transaction End

• transactionExecutionTime for Transaction End

• activityInfo for Debugging Log. It is a JSON message with the following fields

• DisplayName

• State (Faulted, Closed, Executing)

• Activity

• Variables

• Arguments

Note: Only the first 3 are always present in the message. Variables and Arguments usually have sub-fields.

User-defined fields
These fields are defined in Studio (by using the Add Log Fields activity) and appear in all subsequent logs
after the activity is generated, unless they are (programmatically) removed by the activity Remove Log
Fields

Object Repository

The Object Repository ensures the management, reusability, and reliability of UI elements by capturing
them as objects in a DOM-like repository, sharable across projects. It allows for creating and reusing UI
taxonomies inside and across automation projects. With Object Repository you can build a UI API for your
application and share it with your team within minutes.

The key features of the Object Repository are:

• UI elements across the project are managed, updated, and modified from a centralized place.

• view a list of all your UI activities inside your process by using the UI Activities tab inside Object
Repository panel.

• quickly capture elements you need in your automation with the Capture Elements wizard.

• increased selector reliability with the help of the Capture Elements recorder that captures
elements, together with their anchors.

• with the help of anchors, objects keep their reliability in case the application received a slightly
new UI.

• drag-and-drop elements from the Object Repository panel.

• objects are reusable in local project or across projects when packaged as libraries.

• upgrade application and process UI elements in one go with UI libraries.

Prerequisites

The Object Repository works with ..UIAutomation.Activities package versions 20.10.x and above in
projects that use the Modern Design Experience. Note that ..UIAutomationNext.Activities package has
been deprecated as of 20.10. The activities from UI Automation Next are now found in the UI Automation
package. The Object Repository is not available in cross-platform projects.
The Use Modern for new projects toggle controls the default design experience for new projects. Modern
experience is a new way of designing automation with wizards, recorders, and activities part of the packs
enhanced for Object Repository support. This toggle is on a global level, meaning that if enabled, all new
projects are created within the context of modern design experience.

When the Object Repository enforced toggle is set to Yes, activities part of the UIAutomation pack need
to reference elements from the Object Repository.
There is also a "Modern Experience" toggle at the project level. If enabled, the current project operates
within the context of modern design experience. In a modern design experience, the classic UI Automation
activities are hidden by default. They can be enabled by using the filters inside the Activities Panel.
Alternatively, you can always switch to Classic Experience for a particular project from project settings. Or
you can switch the behavior for new projects from the backstage Studio settings.

Key Concepts

UI Descriptors

A UI Descriptor is a superset of selectors. It holds information for uniquely identifying elements on the
screen.

UI Descriptors are extracted from activities in the workflow and added to a structured schema that groups
them by Applications, Application Versions, Screens, and UI Elements. Out of this taxonomy structure, only
Screens and Elements hold descriptor information. The rest are used for grouping and their role is to
ensure upgrades between versions of an application.

UI Descriptors can be part of:

 • one project for wide reuse.

• snippets repositories for testing purposes.

• UI Libraries for global cross-project sharing.

UI Elements

UI Elements contain full or partial element selectors, anchor selectors, screen and element image capture
context, and other metadata that describes the element on the screen.

Screens

Screens are UI Scopes that are either extracted from activities inside the workflow or are generated at
element capture time. A screen groups together multiple elements belonging to the same screen.

UI Applications

A UI Application is a targeted application that can have multiple versions and each version can have
multiple screens. Applications can be of multiple types:

• Desktop / Web Application

• Mobile Application

For defining mobile applications, you need to use ..MobileAutomation.Activities package.

The structure of UI libraries created with the Object Browser has the following
hierarchy: Application > Version > Screen > UI Element.

UI Libraries

A UI Library is an encapsulation of elements grouped by applications, application versions, and screens.

Elements you define can be extracted as a UI Library, and after publishing can be installed in other projects
as a dependency.

A UI Library may contain several applications but can contain only one version of a certain application. This
mechanism ensures that when you upgrade a dependency, you also upgrade the application version you
were using inside your projects.

Note that when creating a new version of an existing application, you need to reuse the existing elements.
Elements have unique identifiers that are used when referenced from activities. You can always change
the contents of an element (descriptors and other metadata).

Reusability

The Object Repository enables you to reuse your UI elements across projects:

• all locally stored elements can be reused at project level

• for testing purposes you can use Snippets panel to save into and pass applications between
projects. From Snippets you can add applications to your local project repository.
• extract elements into UI libraries and install them as a dependency into your projects when you
want to reuse at a global level. You can also take a reusability-first approach and start by creating
UI Libraries with the elements you will need across all your automation projects.
Object Repository Structure

The object repository has a tree structure where each node is an object representing screens or elements,
all hierarchical under the application. The structure is the following:

• Application - can be one of 2 types: mobile or desktop/web, depending on what technology is

used for UI Automation.

• Version - applications can have multiple versions

• Screen - top-level window of an application version that can only be created under an app version.

• UI element - an object on the screen with a descriptor and metadata. It can be of multiple types.

UI elements can be freely rearranged in the tree structure, as long as they remain under their designated
screen. To move, simply drag and drop the element to the desired location inside the tree.

Elements can also be part of other elements and they can also be grouped under containers with no UI
specific role. This allows defining a UI structure that is as close as possible to what the user sees on screen.

Creating an Object Repository

Important: The Object Repository works with the ..UIAutomation.Activities or
the MobileAutomation.Activities package versions 20.10 and higher in projects with Modern Design
Experience enabled.

An object repository is a collection of elements grouped by applications, versions, and screens that can
come from a:

• Local project, i.e. the local repository.

• Library, i.e. UI Library dependencies to the current project.

A Local Repository can be created either by:

• Using the Capture Elements recorder to capture UI descriptors.

• Manually, by creating applications, screens, and elements directly in the Object Repository panel.

A UI Library can be created by:

• Extracting the local repository from any project into a library project and publishing it as a NuGet
package.

• Starting from a new library, building the repository there, and publishing it as a NuGet package.

You can then use the UI Library NuGet packages and add them as dependencies to your processes.

Important: The Capture Elements recorder only records objects for reuse in projects, the recorder does
not generate a workflow in the Designer panel.

Creating a repository by capturing elements

In a library or process, click the Capture Elements button in the Object Repository to open the
Capture Elements recorder.
Click Start recording to begin capturing elements. The Capture Elements recorder uses the Unified
Target technology available in the UIAutomation.Activities pack version 20.10 and higher to capture
targets and anchors with a certain degree of accuracy for each selector, image, or anchor.
UI Elements are captured together with a Selector, Fuzzy Selector, and Image, each with a degree of
accuracy. You can choose to keep only one or all of these target elements. The same is applicable for
anchor elements associated to each UI element in the application.

In the recorder, you can:

• Click Add Application or Add Screen to add a new application or screen.

• Pause recording at any time by clicking Pause . To resume recording, click Record again.

• Manage recorded elements:

• Update the properties of a screen or element by selecting it in the left panel and editing
it in the Properties panel on the right.

• Rearrange and group elements by dragging and dropping them in the left panel.
 • Highlight elements you have already captured to easily identify them by hovering over

their name in the Capture Elements window and using the button.

• While recording is paused:

• Remove an element by right-clicking it and selecting Delete.

• Create a new element as a child of a screen or element by right-clicking the

existing element and selecting Create Element.

• Optionally, click Settings , and then select if you want to configure each element or
auto-apply changes (both settings are enabled by default).

• Click Save objects to library to save the changes, close the recorder, and return to your
project.

Capturing all elements

You can use the Capture all elements feature to capture all the available elements of an application by
using Computer Vision technology and add them to the Object Repository. This method is useful for
scenarios where the automation relies heavily on Object Repository usage, as you no longer have to
manually add all the UI elements, thus saving time when creating the process.

1. Click the Capture all elements button in the Capture Elements wizard. You are prompted to
indicate the window that contains the elements you want to add to the Object Repository. You can
also select only a region of the target application by clicking and dragging a rectangle of the area
you want to capture elements from.

2. Indicating the application detects all elements and highlights them green. You can also manually
deselect the elements you don't want to add to the Object Repository. The Scan Wizard window
lets you choose to Select all or Deselect all elements by using the respective buttons. Once your
selection is done, hitting Capture closes the Scan Wizard and returns you to the Capture
Elements window.

If there are elements that weren't identified, you can help us improve detection by sending an image to
.® for analysis. Click Report issues, select an area with unidentified elements, and then select Send.
Note:

This feature requires that you have configured a Computer Vision server for use. There are multiple
methods available of achieving this, as follows:

• Using the Cloud Computer Vision Server

• Using an On-Prem Computer Vision Server

After choosing your preferred server type, you must select it for use in the current project by editing
the Server and Apikey Project Settings.

Descriptor properties

Applications, screens, and elements should be given descriptive names from within the Capture
Elements recorder to make them easily recognizable in the Object Repository.

Element types

A selector in an application can represent a button, a checkbox, a text field, toggle, list box, any type of
element that can interact with the Robot. The captured element can be defined from within the Capture
Elements recorder.

From the Type drop-down list, search and pick the type suitable for each element. In the Object
Repository the element receives an icon specific to its type making it easier to distinguish between
objects.
After capturing elements, click the Save objects to library button, and the objects are added to the Object
Repository. To add additional elements, right-click a screen or element in the repository, and select Create
Element. To add additional screens, right-click the application and select Create Screen.
Using Capture Elements for existing applications and screens

If you exited the recorder before capturing all the desired elements, or you want to add or modify elements
using Capture Elements for an application or screen that is already added to the Object Repository, you
can launch the recorder at any time in the context of that application or screen:

1. Right-click any application or screen under Project UI Descriptors, and then select Capture
Elements. This opens the Capture Elements window in the context of that application or screen:

• If you selected an application, all the screens and elements under that application are pre-
populated in Capture Elements.

• If you selected a screen, all the elements under that screen are pre-populated in Capture
Elements.

2. Update the screens and elements as needed. You can add new screens, start recording to add new
elements, edit or delete existing screens or elements. If you make changes to existing screens and
elements, the changes are applied to the descriptors in the Object Repository when you save.

3. Click Save objects to library to save the changes, close the recorder, and return to your
project.

Creating a repository From the Object Repository panel

You can create your own repository from within the Object Repository panel by defining the application,
each screen, and element manually.

Create a UI application

From the Object Repository panel, click the plus sign in the Descriptors tab or right-click Project
Descriptors in the same tab and select Create Application. The Create Application window opens:

Add a unique application name, version, and description. Click Create application. Your application is
visible in the Descriptors tab, under Project UI Descriptors.

Create a screen

In the Descriptors tab, select your application, click the plus sign or right-click your application and
select Create Screen. The Add Screen window opens:
Add a unique name for the screen, and a description. Indicate the screen that you would like to automate,
and edit the captured element with Unified Target:

• Change the application path if needed.

• Add application arguments.

When completed, click Create screen.

Create a UI element

In the Descriptors tab, select your app screen, click the plus sign in or right-click the screen and
select Create Element. The Add Element window opens:
From the Descriptor Type section click Indicate element to use Unified Target to indicate and capture the
element from the screen.

Add an intuitive name in the Element Name field, and select the type of the element from the drop-down
list under Type. Click Save when done.
Note:

• To edit an element from the Object Repository, right-click it, and then select Edit Element, or
double-click the element in the tree.

• To edit the descriptor of an element, use the Edit Descriptor option from the Edit
Element window, or right-click the element in the tree, and then select Edit Descriptor.

Using Object Repository with recorders

If the Object Repository is enforced in your instance of Studio (as per instructions in the About Object
Repository page), when using the App/Web Recorder, the generated activities do not automatically
reference descriptors from the repository.

At the level of activities, an informative tooltip informs you to add descriptors to the Object Repository or
use existing ones.
To do so, click on the icon inside the activity, and follow the steps for adding or reusing descriptors, or

select Options > Add to Object Repository to add the element to the Object Repository.
Add elements from activities to a repository

After you've created an object repository you can add more UI elements directly from the Designer panel.

In the Designer panel add an activity that supports selectors, like Click or Type Into. Make sure that the
added activity is within a Use Application/Browser activity.

Within the body of the activity, click the Object Repository icon to open the Selection Options window.
Capture the element, select Confirm and the Add Element to Object Repository window opens. Add a
name to the element and click Save. Notice that the element is added to the Object Repository panel.

Use Objects in Current Project

From the Object Repository, drag and drop a screen or element on top of an activity in your workflow.
The object's image, arguments, and other details are automatically added to the activity. When an activity
uses a screen or element from the Object Repository, clicking the Object Repository icon in the activity
highlights the descriptor it uses in the Object Repository tree.
In the below example, we dragged the MyAppScreen object on top of the Use
Application/Browser activity. The application path was automatically added to the activity.

Alternatively, drag and drop an object on top of the plus sign inside the workflow. If you drag and drop a
screen, a Use Application/Browser activity is automatically added. If you drag and drop an element, a list
of compatible activities is displayed. Select the desired activity and the object is automatically added.
Inside the process, the activity receives the following label: activity name + object name. After the object
is added, the activity receives the descriptor properties from the Object Repository, visible in the
activity's Properties panel.

• To indicate or edit the descriptor from the activity, select Options , and then Indicate target
on screen or Edit Target. A dialog is displayed informing you that the action is performed on the
descriptor in the Object Repository. Confirm your choice by selecting Indicate DescriptorandEdit
Descriptor respectively.

• To indicate or edit the descriptor for the current activity only, you must first remove the link

between the activity and the Object Repository by selecting Options , and then Unlink from
Object Repository. Please note that when the Object Repository is enforced, unlinking removes
the target from the activity.
Once objects are added to the workflow, the UI Activities tab in the Object Repository panel displays the
activities and the objects they contain in a hierarchical order. If they are not visible, please save the project
and check again.

The workflows are marked:

• with a gray dot, if at least 1 activity from the workflow file references a UI Descriptor from the
Objects panel.

• with a blue dot, if all activities from the workflow reference UI Descriptors from the Objects panel.

The UI activities are marked:

• with an empty dot, if the activity does not reference a UI Descriptor from the Objects panel.

• with a blue dot, if it references a UI Descriptor from the Objects panel.

Edit descriptors

Element descriptors

Descriptors can be edited from the Object Repository in two scenarios that we'll refer to as "online" and
"offline" editing:
 • Online editing - the application or browser can be accessed on the current machine. The
app/browser is displayed on the screen, allowing elements to be selected again or modified.

• Offline editing - the application or browser cannot be accessed on the current machine, either the
app is not installed, or the machine is offline. The element's selectors are made visible allowing
changes to be made.

Note: Both Selectors and Fuzzy Selectors in your Descriptors can be edited directly in the UIExplorer by
using the button.

Online editing

In the Descriptors tab, right-click an element and select Edit Descriptor. The selection screen opens
allowing you to capture a different element, edit selectors, and anchors.

The same can be achieved by clicking on the Edit Descriptor button from within the Edit Element window.
Note: At runtime, the UI Descriptors are resolved from the Object Repository panel, if the activities
reference such UI Descriptors.

Offline editing

The same steps from online editing apply here as well. In the Descriptors tab, right-click an element and
select Edit Descriptor.

Offline editing offers the option to make changes directly to the element descriptor settings. However, you
cannot indicate new elements. To do so make sure the application/browser is opened in the correct state.
Screen descriptors

To edit a screen descriptor, in the Descriptors tab, right-click the screen and select Edit Descriptor. The
Edit Screen window is displayed.
You can edit the application path or browser URL, application arguments, and window selector, and select
whether only applications with a title that is an exact match can be used in the automation. The application
path, browser URL, and application arguments fields support expressions, variables, and arguments.

Resolve UI descriptors

Whenever you indicate a screen or UI Element which is already referenced in the Object Repository either
under Project UI Descriptors or UI Libraries, the match is automatically detected and the following window
is prompted:
The following options are available:

• Reuse - adds the matching descriptor from the Object Repository to the current activity.

• Create New - opens the options window for creating a new screen/element or updating an existing
one in the Object Repository.

• Cancel - keeps the currently indicated selector inside the activity, without making any changes to
objects in the repository.

Indicating a screen searches for a corresponding UI descriptor, while indicating a target element searches
for a matching UI descriptor. When using the Recorder, corresponding matches for screen and elements
are searched within the local UI library from Project UI Descriptors or the imported dependencies from UI
Libraries.

Note: At runtime, the UI Descriptors are resolved from the Objects Browser panel, if the activities
reference such UI Descriptors.

Variables in descriptors

To increase their degree of reusability, you can use variables in descriptors.

You can edit a target, add variables to it, and then add it to the Object Repository, or you can add variables
to selectors in existing screens or elements from the Object Repository. Whenever you add a descriptor
that contains a variable to a process, make sure to create the variable in the process, otherwise the
expression cannot be read.

To add a variable to a descriptor selector, right-click the element inside the Object Repository, then
select Edit Descriptor and add the variable from the Selection Options window.
Variables added in selectors must be enclosed in double curly brackets. For example, as seen in the image
below, <name='{{VarNumber}}'/> adds the value of the variable VarNumber to the name attribute in the
selector.
In the below example, we used a variable inside the Browser URL field of the Use
Application/Browser activity, and then added the target to the Object Repository as a screen object. In
this way, we make sure the descriptor accounts for cases in which the URL changes.

Highlight elements

In the Object Repository panel right-click a screen or element and select Highlight to highlight elements
inside the application, provided that the app is launched on the machine or the web page is opened in the
browser.
Reusing objects and UI libraries

Start from a UI library

We recommend starting to build your sharable UI elements directly inside libraries, when you know that
your internal applications will be automated multiple times. But even if you did not do so, you can always
extract them from your existing processes.

When you start building a UI Library, you start by creating a simple Library process. To capture your
application elements follow the steps described in Creating an Object Repository.

Extract as UI library project

The project's local repository can be extracted to a UI library project. This allows publishing the library and
reusing the elements from it by adding it as a dependency to your process. Click on the Extract as UI
Library Project icon in the Descriptors tab and provide a name for your library in the New UI
Library window.
Click Create and the descriptors are extracted.

Click Yes to close the current project and open the extracted descriptors in a library project, or No to
return to the current workflow.

After opening the extracted UI library, you can publish it and use it in other workflows.
Publish a UI library

When you publish a UI library, a .nupkg package is created which can be installed in another project as a
dependency and its descriptors used as selectors in other activities. Such packages may be published to
Orchestrator and shared across your organization.

You can publish, the entire workflow together with its UI library, or the extracted UI library.

Publishing the entire workflow or the extracted UI library is done in the same way as for any other process.
Read more about Publishing Projects.

Load UI libraries in projects

Create a process in Studio. From the Manage Packages window, go to the feed where you published your
UI Library and install it to your current project, just as you would an activity package. The UI Library is
added as a dependency to your project, and its descriptors are visible in the Object Repository panel,
under UI Libraries. Please note that one UI Library can contain a single version of a UI Descriptor and a
single version of an application.

The descriptors in the UI Libraries section can also be added to the local project. To do this, right-click the
application name and choose Add to UI Objects.
Whenever you need to use a Screen or UI Element from the project's Descriptors panel or the UI
Libraries section, simply drag and drop it on top of an activity that supports Object Repository. The activity
automatically picks up the descriptor.

Note: The version of the UI library is not incremented in the Publish window. When publishing a new
version of the same UI library make sure to properly add the new version number.

Upgrade application and process selectors

Using UI libraries, you can update selectors in a process in one go whenever the application you're
automating receives a new UI, as it sometimes happens with desktop applications or websites.

1. Inside a library project, create the first version of the object repository a library with elements
from an application. Publish the library when done.

2. Use the objects inside activities as part of a process by installing the library as a dependency.

3. In the initial library, update the descriptor for each screen or element with the new app UI. It is
important not to delete the elements, but rather update their selectors so that the link between
element and select is preserved.
 4. Publish the library with a higher version and install it in the initial process.

5. The descriptors are automatically updated inside activities.

Check in an Object Repository

When an object repository is created, the metadata associated with the descriptors are mapped in
the Project panel, as part of the current project, be it a process or a UI library.

When versioning the project, the object repository is also added to the TFS, SVN, or GIT repository together
with the other project files. You can add new descriptors to the repository, and then check in the changes
as you would do with other projects. Read more About Version Control in Studio.

After adding a new descriptor, right-click the Objects folder in the Project panel and select Check In,
the Check in Changes window opens, displaying the same hierarchy of elements as in the Object
Repository.
Add to Snippets

Snippets can store Applications for testing purposes. The entire local object repository from a project can
be added to the Snippets panel for later use in other local projects, be they processes or libraries. Right-
click the application and select Add to Snippets. Applications are added together with child screens and
UI elements.
From the Snippets panel, you can edit, and add descriptors to your project via the context menu option
available in the application version menu. Adding screens and UI elements to your project can be done via
the same context menu available for each of the elements.
Dragging and dropping elements from the Snippets Panel is not a supported feature. Referencing elements
from Snippets Panel is not supported either. Snippets Panel is only a testing capability which allows saving
elements on your disk. From there, elements can be then added to your local repository and vice-versa.
As a result, any added resource, be it a descriptor, a screen, a version of an application, or a whole
application can be removed from the Snippets panel, without affecting the existence of that resource in
other areas of the project, such as the Object Repository panel.

The Snippets panel plays the role of an "on-disk" personal object repository that can hold elements from
any of your local projects and make them available for other projects. As an added benefit, since Snippets
is never involved in referencing elements or runtime execution, you can store here multiple versions of
the same application. To create multiple versions of an application you can right-click on the application,
choose Create Version and then copy elements from the previous version to ensure you maintain element
uniqueness between versions.

Fill in the details of the new version in the New Application Version Inside Snippets dialog, then
click Create version.
Note: Object repositories cannot be published from the Snippets panel as they play no role in referencing
inside projects or at runtime.

Copy and Paste objects

You can copy the whole tree structure to and from the Object Repository, Snippets panel, or in between
Studio instances, using the Copy Tree options available at right-click in the Object Repository and
the Snippets panel.

In addition, the Copy option or the combination of keyboard shortcuts, Ctrl + C and Ctrl + V shortcuts
allows you to copy individual elements from the repository, and paste them in the above-mentioned
locations.

Find References

Using the Find References option you can check whether the UI Element or UI Descriptor from your library
is used throughout the project.

To do so, right-click a UI Element in the Descriptors tab from any of the Objects Browser panels (Project
UI Descriptors, UI Libraries, or Snippets - UI Descriptors) and select Find References. The results are
displayed in the Find References panel. Double-clicking on a result focuses the activity that uses the UI
Element.
Workflow Analyzer

Workflow Analyzer is a static code analyzer that ensures your project meets high quality and reliability
standards. A static code analyzer checks for inconsistencies without actually executing the project, as
opposed to dynamic analyzers which step in during execution.

Workflow Analyzer uses a set of rules to check for various inconsistencies unrelated to project execution.
The rules are based on Automation Best Practices and take into consideration variable and argument
naming, empty sequences or workflows, package restrictions, and so on. The analyzer does not identify
errors in execution or compilation.

It is available in the Design ribbon tab, the Analyze File and Analyze Project buttons. The first performs an
analysis on the file currently focused in the Designer panel, while the second analyzes all files in the
automation project.

Studio comes with a set of built-in rules, identifiable by the ST- prefix.
The UIAutomation.Activities, Excel.Activities, Testing Activities, and Mail.Activities also have their own
rules, identifiable by the prefix. Find more in the table below:
 Rule Category Description Source

Naming Checks the file or project for any inconsistencies related Studio
to naming.

Design Ensures your project meets a general set of best Studio

practices.

Project Anatomy Ensures your project meets general requirements in Studio

terms of anatomy.

Maintainability and Confirms projects are easy to understand so that Studio

Readability maintainability is ensured.

Usage Ensures elements defined in your project are actually Studio

used.

Performance and Checks the file or project for any inconsistencies related Studio
Reusability to performance and reusability.

Reliability Checks the file or project for any inconsistencies related Studio
to reliability.

Security Checks the file or project for any inconsistencies related Studio
to security.

Application Testing Tests the workflows and automation projects. Activities

UI Automation Validates workflows that consume either Classic or Activities

Activities Modern UI Automation activities.

Excel Activities Validates workflows that consume Excel Activities. Activities

Mail Activities Validates workflows that consume Mail Activities. Activities

You can also create custom rules. For more information, see Building Workflow Analyzer Rules in the
Developer guide.
Rules can also be configured when creating a Studio policy in Automation Ops. For more information, see
the Automation Ops guide.

Note: Studio built-in rules cannot be ported to older Studio versions. However, rules from compatible
activities packages can be used in older Studio versions that come with the Workflow Analyzer.

Rules Naming Convention

Each rule has an ID, name, description, and recommendation. The ID contains the origin, category, and
number. For example, Variables Naming Convention has the ST-NMG-001 ID:

• ST - reveals that the rule is built into Studio.

• NMG - shows that the rule is part of the Naming Rules category. Rules part of Project Anatomy
Rules category have the ANA abbreviation, those part of Design Best Practices the DBP, and so on.

• 001 - is the rule number.

Scope

Each rule has a scope to which it applies:

• Activity: The rules are enforced at activity level, checking variables, arguments,
properties. Variables Naming Convention is one such rule.

• Workflow: Rules perform checks in a single project file, for example Unused Variables.

• Project: Checks are performed at project level.

Action

Rules have a number of actions that can be set:

• Error: Generates an error in the Error List panel.

• Warning: Generates a warning in the Error List panel.

• Info: Generates a message in the Error List panel.

• Verbose: Creates large log files.

Check the Logging Levels page to learn more about logging with Studio.

Managing Rules

The project or file is analyzed based on a set of rules available in the Project Settings window:
 • In the Project panel, click the icon, then select Workflow Analyzer.

• In the ribbon, click the Analyze File button, then select Workflow Analyzer Settings from the
dropdown.

By default, rules are arranged by code in the window, and enabled rules are displayed first.

Use the search box at the top of the window to search rules by name or code. To filter rules by scope and
default action, click the button to the right of the search box.
Configure Rules

You can enable/disable a rule using the checkbox on its left, or change the default action using the
dropdown on its right.

Some rules require no additional configuration, while others contain parameters that you can configure,
such as thresholds not to be exceeded, or lists of specific items that are allowed or prohibited. Please note
that when you configure rules that contain text fields (for example SecureString Misusage or Package
Restrictions), text shouldn't be entered between quotes.

Reset to Default

After any changes were made to the default values of rules, be it Regex or thresholds, the values may be
reverted to default by right-clicking the rule and then selecting Reset to Default.
Validation

Validation of the file or project is performed whenever the Workflow Analyzer is triggered. Validation
options are available in the Analyze File ribbon button, Validate File and Validate Project.

This action checks whether variables, arguments, expressions, and imports are properly configured.
The Validate File action can be triggered using the F8 shortcut, while Validate Project using Shift + F8.
Validation can be cancelled at any time.

The file(s) that contain errors are marked in the Project panel with a red dot, and the errors are shown in
the Error List and Output panels.
Double-clicking an item in the Error List panel opens the .xaml and highlights the element which threw
the error, whether it's an activity, argument, or variable.

Unless all .xaml files are validated, the project cannot be debugged, executed or published. Breakpoint
conditions are not evaluated.

Managing Errors

When triggered, the Workflow Analyzer uses the configured ruleset to check the project or file, and logs
the found errors in the Error List panel, in accordance with the rule action.

The Error List panel filters items by Errors, Warnings and Messages. The scope drop-down menu is useful
for filtering errors by project, current file or a specific file in the automation. In addition, items can be
filtered by rule ID.
Click a found warning or error to display the rule’s recommendation and a link to the documentation page
for each rule.

In addition to rule violations, the Error List panel also displays errors that may occur in the execution of
workflow analysis, When the Workflow Analyzer or one of the configured rules fails to run, an error is
logged with details about the cause of the error in the description.

Command-Line Support

The ..Studio.CommandLine.exe command-line user interface contains a set of parameters for checking
files or projects against certain rules, even in CI/CD pipeline configurations.

..Studio.CommandLine.exe is available in the installation folder:

• For per-machine installations, the default path is %ProgramFiles%\.\Studio\

• For per-user installations, the default path is %LocalAppData%\Programs\.\Studio

Configure Rules

By default, all Workflow Analyzer rules are enabled when installing Studio with the exception of the
following:

• Argument Default Values

• Undefined Output Properties

You can configure rules:

• From the Workflow Analyzer Settings window, enable or disable rules by clicking the checkbox
next to each one of them,

• From the RuleConfig.json file, path %LocalAppData%\.\Rules. Find a specific rule, modify its
parameter, change the IsEnabled parameter to false to disable the rule. Optionally, if the path is
not accessible, you can place the RuleConfig.json file in a custom location and include the path to
the file in the command. For more information, see Analyze Files and Projects.

Rules are organized according to their unique ID, visible in the Workflow Analyzer Settings also.
For example, in the image below only the Variables Naming Convention rule was enabled and received
the ([A-Z]) Regex expression. This means that variable names must be uppercase. All the other rules were
disabled in this example.

The following parameters are available for each rule:

 Parameter Description

RuleId The ID of the rule.

IsEnabled Whether the rule is enabled or disabled. If set to null, the value of the
parameter DefaultIsEnabled is applied.

DefaultIsEnabled Whether the rule is enabled or disabled by default.

DefaultErrorLevel The default level of the log message (Error, Warning, Info, Verbose).

Parameters Additional parameters that the rule can contain (for example, Name or Value).

ErrorLevel The level of the log message. If set to null, the value of the parameter
DefaultErrorLevel is applied.

Analyze Files and Projects

After configuring the rules, access the ..Studio.CommandLine.exe command-line user interface.

The following Workflow Analyzer commands are available:

• analyze - Analyzes the whole project. Requires the path to the project.json file.

• analyze-file - Analyzes a single file. Requires the path to the .xaml file.

The following arguments are available for Workflow Analyzer commands:

Argument Description

-p, --project- For analyzing one file, provide the path to the .xaml. For analyzing the entire
path project, specify the path to the project.json file.

-c, --config- Path to the RuleConfig.json file. Specify this path only if the rule configuration file
path is not placed in the default location (%LocalAppData%\.\Rules).

--help View the arguments available for each command.

--version Check the version of ..Studio.CommandLine.exe.

For example, the command ..Studio.CommandLine.exe analyze-file -p
"C:\BlankProcess\Main.xaml" analyzes only one file in a project, Main.xaml. The output of the command
returns a json-encoded dictionary with the following information for each rule violation:

• FilePath: The path to the analyzed file.

• ErrorCode : The rule ID.

• ActivityDisplayName: The display name of the activity (null if not applicable).

• Item - The name and type of the item (for example, activity or variable) where the error message
was generated.

• ErrorSeverity: The value of the DefaultAction parameter, which is the configured log message for
each rule, either Warning, Error, Info or Verbose.

• Description: The rule's description.

• Recommendation and URL: The recommended changes for solving the issue, together with the
documentation link with more information.

To use a RuleConfig.json file placed in a custom location, add the location to the command. Using the
previous command as an example, to configure rules with the file located
at C:\CustomFolder\RuleConfig.json, run the command as follows: ..Studio.CommandLine.exe analyze-file
-c "C:\CustomFolder\RuleConfig.json" -p "C:\BlankProcess\Main.xaml".

To return the exit code of the command, execute echo %errorlevel% after you run it. If there are no
messages with the ErrorSeverity Error, the code 0 is returned. Otherwise, 1 is returned.

Please note that some of the entries may not be associated with a rule, but can be errors generated by
the Workflow Analyzer. For example, in the case of an empty .xaml file, an error is displayed.

The Globally Unique Identifiers (GUID) used as prefixes for an entry are generated on each run and apply
to the current result only.

Exporting Workflow Analyzer Results

To configure Studio to export the results of each workflow analysis to the project folder, go to Studio
Backstage View > Settings > Design and enable the Export Analyzer results option.
When this option is enabled, the results of each workflow analysis are saved in
the \.local\.analysis\ subfolder of the project folder in a file named with the timestamp of the analysis
followed either by project_analysis_results.json (when the Analyze Project option is used)
or file_analysis_results.json (when the Analyze File option is used) .

Note: The .local folder is hidden. You can enable viewing hidden items from the Windows File Explorer
settings.

The files contain the following information about each enabled rule:

• RuleId - The rule ID.

• RuleName - The name of the rule.

• Parameters - The customizable parameters in the rule, if applicable.

• Severity - The rule action, if the rule is violated.

• ErrorsDescription - A list of error messages generated by the rule, if applicable.

Enforcing the Workflow Analyzer before Run, Publish, or Push/Check in

You can prevent executing, publishing, and pushing/checking in to remote repositories projects that
contain Workflow Analyzer errors by enabling the following options from Studio Backstage
View > Settings > Design:

• Enforce Analyzer before Run - Whenever running/debugging a file or project is initiated, the
Workflow Analyzer checks all the rules with the Error action and execution is allowed only if no
errors are found.

• Enforce Analyzer before Publish - Whenever publishing is initiated, the Workflow Analyzer checks
all enabled rules regardless of their action and publishing is allowed only if there are no rule
violations with the action Error.

• Enforce Analyzer before Push/Check-in - Whenever sending a project to a remote repository is

initiated (Commit and Push for GIT, Check in for SVN and TFS), the Workflow Analyzer checks all
enabled rules regardless of their action and the operation is allowed only if there are no rule
violations with the action Error.

When Enforce Analyzer before Publish is enabled, if publishing is successful (there are no rule violations
with the action Error) the results of the workflow analysis are included in the published .nupkg package in
the file project_analysis_results.json located in \lib\net45\.analysis\. The file contains the following
information about each enabled rule:

• RuleId - The rule ID.

• RuleName - The name of the rule.

• Parameters - The customizable parameters in the rule, if applicable.

• Severity - The rule action (if the rule is violated).

 • ErrorsDescription - A list of error messages generated by the rule, if applicable.

Components

Test SuiteTM, as a solution, comprises four of .®'s tools: Studio, Orchestrator, Robot, and, finally, Test
Manager. Check out the diagram and information below to learn about every component, and how it
works.

Component Description

Studio The IDE for test automation development, enabling you to create test cases.
Studio offers you two experiences when designing test cases within Studio:

• Low-code: Comprises a visual interface, with drag-and-drop activities,

that allow you to have a low-code experience when designing test cases.

• Coded: Comprises a code editor, along with services and APIs that you
can use to execute your desired actions, that allow you to have a full
coded experience when designing your test cases.

Orchestrator The platform that allows you to publish, centralize, and execute your tests, from
Orchestrator, or using a CI/CD pipeline.

Testing Robots The agent connected to Orchestrator, that executes processes, including tests.

Test Manager The test management tool, and the native integrations that Test Manager offers.

CI/CD CI/CD pipelines that allow you to deploy testing projects and manage them.
Integrations
.® Test Suite is the testing solution powered by the .® Platform. As the visual below depicts, the .® Platform
does more than just empowering you to discover automation opportunities; it also provides the means to
automate them. Beyond this, it offers tools for the operational context to enable you to deploy, govern,
and measure the real-world impact of your robotic process automations.

Now, think of .® Test Suite as a vertical slice straight through our platform:
This slice is packed with capabilities for everything from discovering tests, automating tests, running tests,
to analyzing test results, and managing your testing efforts. Essentially, .® Test Suite is the quality hub of
our platform, acting as the backbone of both your top-notch robotic process automations and high-quality
software applications. So, .® Test Suite has a dual purpose:

First, .® Test Suite is used by testing teams in software development to test a wide range of software
applications, including web apps, mobile apps, and CRM/ERP systems like Salesforce, ServiceNow, and SAP.
This is what we call application testing. Secondly, Test Suite is used by RPA teams, who are typically found
in business departments such as marketing, finance, and sales, to test their robotic process automations.
This is what we call RPA testing. The beauty of .® Test Suite is that it's a single solution that can be leveraged
for testing both software applications and robotic process automations.

In addition, think of .® Test Suite as a solution, a suite of 4 tools:

First, we have .® Test Manager , our test management tool. Then we have .® Studio, our IDE for developing
test automation. Next, we have .® Orchestrator, our tool for orchestrating (cloud-based distributed) test
execution. And lastly, our .® Robots for performing the test execution. These 4 components come with a
variety of testing capabilities for automating tests in virtually any technology, including web, desktop, API,
and mobile test automation. .® Test Suite also enables you to fully integrate your testing efforts into your
version control tools and CI/CD pipeline(s).

It doesn't stop there. .® Test Suite comes with comprehensive test data management capabilities for data-
driven testing. It provides a rich set of test management capabilities, including requirements management,
analytics and reporting, manual testing, and test mining capabilities – all powered by AI and tightly
integrated into your ALM tools. And if you're looking to transition from legacy testing tools to .® Test Suite,
we offer migration assistants to ease that shift.

Best of all? All that's available both on cloud and on premises. And there you have it, in a nutshell – the
range and richness of .® Test Suite, designed to accelerate and streamline your testing.

Now, let's zoom out even more for a moment to see .® Test Suite from a bird's-eye view. .® Test Suite is
versatile. It allows both tech-savvy testers and everyday business users to document test cases with .® Task
Capture and to create tests for virtually any technology, thanks to its low-code and coded test automation
capabilities. But what about other tools you are using? .® Test Suite has got that covered too. It can work
smoothly with version control tools like Git, SVN, and TFS. It also teams up with build tools, for example,
Jenkins. On top of that, .® Test Manager, the test management tool of .® Test Suite, provides native
integrations to widely used ALM tools: think ServiceNow, SAP Solution Manager, Azure DevOps, Jira, and
even Jira plugins like Xray.
And if there's an ALM tool we don't integrate with, our software development kit, included with .® Test
Manager, helps you make that integration happen. Need more? There's Planview Hub, an integration
platform connecting you with more than 60 popular ALM and test management tools. And the cherry on
top? All these integrations coming with Planview Hub, which we collectively call .® Test Manager Connect,
are included in every .® Test Manager license, at no extra charge.

Capabilities

The Capabilities section provides a snapshot of the features and capabilities that .® Test SuiteTM offers for
seamless and powerful software and RPA testing:

• API Test Automation: .® enables you to automate the process of API testing, validating the
performance and security of your APIs, which is vital for seamless communication between
different software applications.

• Test Data Management: Manage your test data effectively with our test suite. It allows you to
create, modify, and manage data needed for your tests, ensuring accuracy and efficiency in your
test runs.

• RPA Testing & Application Testing: Test your RPA workflows and application performance with our
range of testing tools, to ensure they function correctly and effectively.

• Mobile Test Automation: Validate the functionality of your mobile applications with our mobile
test automation capabilities. Test across different devices and operating systems to ensure a
smooth user experience.
• Test Reporting & Analytics: Generate detailed reports and visual analytics from your test results.
These insights can help you understand the performance of your applications and identify areas
for improvement.

• Integrations (ALM, CI/CD): Integrate your testing workflow seamlessly with Application Lifecycle
Management (ALM) and Continuous Integration/Continuous Delivery (CI/CD) pipelines for
automated and streamlined operations.

• SAP Testing: Specialized tools for testing your SAP software. Ensure your SAP applications are
running at peak performance with detailed testing.

• Test Execution: Efficiently run tests and get reliable results.

• Manual Testing: Perform hands-on, exploratory tests with our tools designed to make manual
testing effective and efficient.

• Migration: Migrate your testing processes and data easily with our tools. No matter the platform
you're coming from, we help smooth your transition.

• AI-powered testing: employ generative AI features to streamline and simplify your testing process.