- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-021 - Hardcoded Timeout
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- ST-USG-032 - Required Tags
- ST-USG-034 - Automation Hub URL
- Variables
- Arguments
- Imported Namespaces
- Coded automations
- Trigger-based Attended Automation
- Recording
- UI Elements
- Control Flow
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Citrix Technologies Automation
- RDP Automation
- Salesforce Automation
- SAP Automation
- VMware Horizon Automation
- Logging
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Test Suite - Studio
- Extensions
- About extensions
- SetupExtensions tool
- UiPathRemoteRuntime.exe is not running in the remote session
- UiPath Remote Runtime blocks Citrix session from being closed
- UiPath Remote Runtime causes memory leak
- UiPath.UIAutomation.Activities package and UiPath Remote Runtime versions mismatch
- The required UiPath extension is not installed on the remote machine
- Screen resolution settings
- Group Policies
- Cannot communicate with the browser
- Chrome extension is removed automatically
- The extension may have been corrupted
- Check if the extension for Chrome is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and Incognito mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Chrome
- Chrome Extension on Mac
- Group Policies
- Cannot communicate with the browser
- Edge extension is removed automatically
- The extension may have been corrupted
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Edge
- Extension for VMware Horizon
- SAP Solution Manager plugin
- Excel Add-in
- Troubleshooting
Best practices
To ensure that your coded automations are efficient, maintainable, and scalable you need to follow their best practices. This section provides an overview of key best practices to remember as you embark on your journey of leveraging code to build automation solutions. Adopting these best practices will help you design coded automations, specifically when structuring your code, implementing error handling strategies, or creating reusable components.
Parallelism improves performance, and implementing it in coded automations is easier. A For Each loop can increase the speed with which an automation executes.
Coded automations (CS files) don't support using or invoking variables or arguments from nested classes within low-code automations (XAML files). If you try to invoke these type of arguments using an Invoke Workflow File activity, or to create such arguments in XAML files, then you'll receive errors. We recommend using variables and arguments from nested classes only within other CS files.
CodedWorkflow
, ParentFile
(an intermediate
class that inherits CodedWorkflow
and contains a custom method),
and MyCustomWorkflow
along with
AnotherCustomWorkflow
(derived classes that inherit
ParentFile
). The table below shows how inheritance between
these classes and files works:
Coded automation | Description | Code |
---|---|---|
CodedWorkflow (read-only partial class)
| This class serves as the foundation for all coded workflows. It
contains essential methods and properties that are common to all
workflows, inherited from the CodedWorkflowBase
class. In this example, it is the class from which all other
workflows ultimately inherit.
Important: The file you want
other workflows to inherit must also inherit the
CodedWorkflow and implicitly the
CodedWorkflowBase classes. This ensures
all workflows inherit essential functions and work as
expected.
|
|
ParentFile (code source file containing an
intermediate class and a custom method)
| This class inherits from CodedWorkflow and adds
custom methods and functionality. In this example, it includes a
custom method called CustomMethod , which performs
specific actions, such as starting a job in Orchestrator.
|
|
MyCustomWorkflow and
AnotherCustomWorkflow (coded workflows that
inherit the code source file)
| These classes inherit from ParentFile and
further customize the workflow by overriding methods or providing
different parameter values. In this example, we have
MyCustomWorkflow and
AnotherCustomWorkflow , both of which inherit
ParentFile .
|
|
ParentFile
inherits from
CodedWorkflow
, any class that inherits from
ParentFile
indirectly inherits the functionality and methods of
CodedWorkflow
. In other words, both
MyCustomWorkflow
and AnotherCustomWorkflow
inherit the core functionality from the CodedWorkflow
partial class
through the intermediate ParentFile
, along with other custom
classes, such as CustomMethod
.
To enhance your coded automations, using custom logic, you can register custom services that you later use in your coded automations. Visit Registering custom services to learn how to register your own custom service.
Within test cases, the Before and After contexts allow you to execute certain actions before and after the test case is run. These contexts are commonly used to set up and tear down resources, perform logging, and manage the test environment. Visit Before and After contexts to learn how the contexts behave and how to implement them.
- We recommend that you do not make any changes to namespaces.
- Store an action inside a class and reuse it throughout your project, so you avoid duplicating code.
- You can remove namespaces that you imported during design time, but aren't necessary anymore.
- If you need to get data from multiple applications, separate the phases of the coded automation, so you don't mix data coming from various sources.