Layout diagrams UiPath offers four diagrams for integrating activities into a work structure when developing a workflow file:
- Flowchart
- Sequence
- State machine
- Global exception handling
Sequence
Sequences have a simple linear representation that flows from top to bottom and are best suited for simple scenarios where activities follow each other. For example, they are useful in automating the user interface where navigation and typing are done with one click/keystroke. Because sequences are easy to construct and understand, they are the preferred arrangement for most workflows.
Flowchart
Flowcharts offer more flexibility for linking activities and tend to organize the workflow in a simple two-dimensional way. Due to their free form and visual appeal, flowcharts are best suited for demonstrating decision points within a process. Arrows that can point anywhere resemble an unstructured GoTo programming statement, making large workflows prone to chaotic intermingling of activities.
State machine
A State Machine is a rather complex structure that can be seen as a flowchart with conditional arrows, called transitions. It allows for a more compact representation of logic and we have found it to be suitable for a standard high-level process diagram of transactional business process templates.
Global exception handling
Exception handling is designed for use in both small and large automation projects, to identify execution errors and, more importantly, to determine the behavior of the workflow when such an error occurs. If an execution error occurs during debugging, the global exception handler can be set to step in and allow you to check the behavior of the workflow according to the options previously set in the exception handler.
Elections
Decisions need to be implemented in the workflow so that the robot can react differently in different conditions when processing data and interacting with applications. Choosing the most suitable representation of the condition and its subsequent branches has a great influence on the visual structure and readability of the workflow.
If Activity
The If activity splits the sequence vertically and is ideal for short balanced linear branches. Challenges come when multiple conditions need to be chained together in an If… Else If fashion, especially when the branches exceed the available width or height screen size. In general, nested If statements should be avoided to keep the workflow simple/linear.
Flow decision
The flowchart layout is good for demonstrating important business logic and related conditions, such as nested If statements or If… Else If constructs. There are situations where a flowchart can look good even inside a sequence.
If the Operator
The VB If operator is very useful for smaller local conditions or data calculation and can sometimes reduce an entire block to a single activity.
Switch activity
A switch activity can sometimes be used in convergence with the If operator to streamline and compact the If… Else If cascade with distinct conditions and activities per branch.
Flow switch
The Flow Switch activity selects the next node depending on the value of the expression; A Flow Switch can be thought of as the equivalent of a procedural Switch activity in flowcharts. It can match more than 12 cases by launching multiple connections from the same switch node.
Data
Data comes in two flavors in terms of visibility and lifecycle: arguments and variables. While the purpose of arguments is to pass data from one workflow to another, variables are bound to a container inside a single workflow file and can only be used locally.
Variable range
Unlike arguments, which are available everywhere in a workflow file, variables are only visible inside the container where they are defined, called the scope.
Variables should be kept in the innermost scope to reduce clutter in the Variables panel and to show only what is relevant at a particular point in the workflow in autocomplete.
Arguments
Note that when invoking workflows with the Isolated option (which runs the workflow in a separate system process, only serializable types can be used as arguments to pass data from one process to another. For example, Secure String, Browser, and Terminal Connection objects cannot safely cross an inter process boundary .
Default values
Variables and input arguments have the option to be initialized with some default static values. This is very useful for individually testing workflows without requiring actual input data from calling workflows or other external sources.
Naming convention
Workflow files, activities, arguments, and variables should be assigned meaningful names to accurately describe their use throughout the project.
Projects should have meaningful descriptions as they also appear in the Orchestrator UI and can help in a multi-user environment.
To improve readability, variable and argument names should also match the naming convention:
- Snake Case: First1_Name2, first_name2,
- Camel uppercase or lowercase letters: First name, last name,
- Pascal case: First1Name2, First1Name,
- Kebab Case: Name, Name1.
Argument names should be prefixed with the argument type, for example in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.
Activity names should accurately reflect the action taken, such as Click Save. Keep the part of the title that describes the action (Click, type, element exists, etc.).
Except for Main, all workflow names should contain a verb describing what the workflow does, such as GetTransactionData, ProcessTransaction, TakeScreenshot.
Comments and annotations
The Comment and Annotation activity should be used to describe in more detail the technique or specifics of a particular application interaction or behavior. Keep in mind that other people may come across a robotics project at some point, and you can try to make the process easier for them to understand.
