- 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
- Control Flow
- Object Repository
- Logging
- The ScreenScrapeJavaSupport Tool
- Studio testing
- 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

Studio user guide
Introduction
Coded automations allow you to create automations using code instead of drag-and-drop activities, allowing collaborative work on complex projects. In coded workflows and test cases, you can use UiPath services (equal to activity packages), coded automation APIs (similar to activities), external.NET NuGet packages, and your custom C# classes in UiPath Studio. This makes it easy to integrate with external systems, databases, APIs, and other services.
Coded workflows behave just as standard workflows, meaning that they can also be invoked from standard UiPath workflows, and vice versa, using the Invoke Workflow File activity.
Additionally, types defined in code, such as enums, can be used as inputs in standard UiPath workflows.
Coded automations can be of three types:
-
Coded workflows – used for designing workflows in code.
-
Coded test cases – used for designing test cases.
-
Code source files – used for creating code that you can later call in other coded file types.

Using coded automations
To create coded automations in your project, you typically have the UiPath.CodedWorkflows package pre-installed. The package comes with the CodedWorkflowBase base and CodedWorkflow partial class.
The package is pre-installed when:
- You create a new project with at least version 23.10 of System.Activities, Testing.Activities, or UIAutomation.Activities, or any other activity package that has coded workflow support.
- You create a new Coded Workflow, Coded Test Case, or Code Source File in your project.
If you can't use coded automations in the stated scenarios, download the package from the Manage Packages menu.
Benefits
Here are some of the benefits of using coded automations:
- Enhanced productivity – If you’re familiar with coding or scripting you can leverage your skills and increase your productivity. Working within a familiar coding environment allows you to develop more efficient automations.
- Complexity management – Coded automations provide a flexible solution for managing complex automation scenarios. By using code, you can implement custom logic, manage exceptions, and create reusable functions.
- Hybrid automation – You can use coded automations interchangeably with low-code automations. This promotes seamless integration between the two approaches, enabling you to create flexible automation solutions.
- Improved performance – Coded automations empower you to optimize your automation workflows to enhance performance. By using code, you can implement specific algorithms to make your automation executions faster.
- Readability – Coded automations allow you to create structured code, resulting in code readability. If you organize your code and document it, you can easily maintain it and share it with other collaborators.
Structure
Coded automations feature a structured design with namespaces, helper classes, and entry point methods. The framework of coded automations allows you to write the automations using the C# programming language.
Follow the detailed structure of a coded automation as described in the following sections.
Namespaces
When you create a coded automation, a namespace is automatically generated using the name of the Studio project. For instance, if your Studio project is named "My project", the namespace for all coded automations will be "Myproject".
Additionally, if you create a coded automation inside a folder in your Studio project, then the namespace will be the name of the project and the name of the folder. For instance, if your Studio project is named "My project", and the folder is named "place", then the namespace will be "Myproject.place".
Base class
Both coded workflow and coded test case automations use the CodedWorkflow partial class from the UiPath.CodedWorkflows package. This class gives the automation access to necessary interfaces for services (equal to activity packages), based on the installed activity packages in your project.
The UiPath.CodedWorkflows package is automatically included when you import an activity package that supports coded automations, such as UiPath.System.Activities 23.10 or higher.
CodedWorkflow
Coded automations inherit the CodedWorkflow partial class, creating a relationship of type CodedAutomationExample : CodedWorkflow. This means that the CodedAutomationExample class inherits attributes, methods, and functionality from the CodedWorkflow class. Essentially, it can access and utilize the features defined in the CodedWorkflow class, which provides a foundation for the coded automation, making it easier to build upon and customize the automation's behavior.
The CodedWorkflow class is declared as a partial class, allowing you to extend its functionalities by defining the same partial CodedWorkflow class in a code source file. This way, you can add new fields and methods to further customize the behavior of your coded automations. You can use this approach to implement a Before and After interface, specifically for coded test cases.
Additionally, the CodedWorkflow partial class inherits the CodedWorkflowBase class.

CodedWorkflowBase
The CodedWorkflowBase class holds the built-in functionalities that a coded automation inherits. This class contains methods and specific properties for managing workflow instances, runtime access, handling service containers, and configuring environment contexts. The CodedWorkflowBase class also offers another separate method for logging that you can customize yourself.
In the Code Editor Settings, select Enable Source Decompilation to view the CodedWorkflowBase class.
Check out the CodedWorkflowBase methods in the table below:
| Method | Description |
|---|---|
serviceContainer(ICodedWorkflowServiceContainer) | Provides access to the dependency injection container that is specific to the current coded workflow. This container, known as the service container, allows you to retrieve instances of services that have been registered within it. |
GetRunningJobInformation() | Retrieves information about the currently running job within the context of the coded workflow. The method accesses the RunningJobInformation property of the executorRuntime object, that holds information about job status, progress, parameters, and timestamps. |
Log(string message, LogLevel level = LogLevel.Info, IDictionary<string, object>``additionalLogFields = null) | Adds additional log fields to log messages with specified attributes. |
RunWorkflow(string workflowFilePath,``IDictionary<string, object> inputArguments = null,``TimeSpan? timeout = null, bool isolated = false,``InvokeTargetSession targetSession = InvokeTargetSession.Current) | Provides a structure to execute a workflow within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments. |
RunWorkflowAsync(string workflowFilePath,``IDictionary<string, object> inputArguments = null, TimeSpan?``timeout = null, bool isolated = false,``InvokeTargetSession targetSession = InvokeTargetSession.Current) | Provides a structure to execute a workflow asynchronously within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments. |
DelayAsync(TimeSpan time) and DelayAsync(int delayMs) | Suspends execution for a specified period of time asynchronously. |
Delay(TimeSpan time) and Delay(int delayMs) | Suspends execution for a specified period of time. |
HttpClient BuildClient``(string scope = "Orchestrator", bool force = true) | Builds an HTTP client with a specified scope and access token. |
RegisterServices``(ICodedWorkflowsServiceLocator serviceLocator) | Registers services (activity packages) to the coded workflow's service locator. You can override it when you want to inject custom services into the dependency injection container. Learn how to create and use custom services (coded activity packages) here. |
Related articles
Entry points
The entry point method for both coded workflows and coded test cases is named Execute() and is attributed as either Workflow or TestCase. You can change the name of the method, as long as you attribute it to either Workflow or TestCase.
You can only use one Execute() method ([TestCase] or [Workflow]) inside a file, that inherits the Coded Workflow class.
In this method, you can add input and/or output arguments, which are equivalent to In, Out or In/Out arguments in low-code automations. Go through the Working with Input and Output arguments tutorial to learn how to use arguments in coded automations.
This entry point method serves as the starting point for running the automations. This makes coded workflows and test cases easy to identify as entry points due to their Execute() method.

Project compatibility
You can use Coded automations only in Windows and Cross-platform projects.
Services
To design coded automations, you can use services, that are equal to activity packages. For example, System.Activities is not only an activity package in low-code automations, but also a service in coded automations. Similarly to the activities inside an activity package, a service has APIs that you can use to create coded automations.
The services available to use inside coded automations are the following:
| Service | Version |
|---|---|
| System.Activities | 23.10 and higher |
| UiAutomation.Activities | 23.10.7 and higher |
| Testing.Activities | 23.10 and higher |
To use activity packages in coded automations, perform the following steps:
- Download the activity package, equal to a service, similar to how you would in low-code automations. This provides you with a collection of APIs to use in your code.
- Call the APIs within the services using the format: service.API. For instance, if you want to use the GetAsset API, you would call it as
system.GetAsset. - APIs have parameters instead of properties. After calling an API, you can configure its parameters by providing values between parentheses. For example, if you have an asset in the Orchestrator instance that you’re connected to, called
Email Address, then you can pass this asset’s name as aStringto the API:system.GetAsset("Email Address").Tip:Inside coded automations, you can also use any .NET class libraries available to download from the nuget.org feed.