22.4 Coded Automations: Structure, Arguments & Invoking Workflows

22.4 Coded Automations: Structure, Arguments & Invoking Workflows

Core Concept: Coded automations let you write automations in C# inside a Studio project, next to low-code .xaml workflows. They use services, which correspond to activity packages, and their coded automation APIs, which correspond to activities. Coded and low-code workflows can invoke each other.

---

The Three Types

Coded automations are available only in Windows and Cross-platform projects. Types defined in code, such as enums, can also be used as inputs in low-code workflows.

---

Structure of a Coded Workflow

using UiPath.CodedWorkflows;

namespace MyProject
{
    public class ApproveLoan : CodedWorkflow
    {
        [Workflow]
        public bool Execute(double loanRate)
        {
            Log($"Evaluating rate {loanRate}");
            return loanRate < 0.08;
        }
    }
}

• Namespace: generated from the project name, plus the folder name for files in folders ("My project" becomes Myproject, and a file in folder "place" uses Myproject.place).
• Base class: coded workflows and test cases inherit the CodedWorkflow partial class from the UiPath.CodedWorkflows package, which inherits CodedWorkflowBase. Because the class is partial, you can extend it in a code source file, for example to add properties for custom services.
• Entry point: the method is named Execute() by default and attributed [Workflow] or [TestCase]; you can rename it as long as the attribute stays. Only one entry point is allowed per file.
• Package: UiPath.CodedWorkflows is added automatically when you create a coded file, or when a new project uses version 23.10 or later of packages such as System, Testing, or UIAutomation activities.

Useful base-class members

---

Arguments

Arguments are declared on the entry point method:

An argument named Output is always treated as In/Out.

---

Invoking in Both Directions

Low-code to coded

Use Invoke Workflow File and select the .cs file. In Windows projects, change the file filter from workflow files to All Files to see .cs files. With System.Activities 24.10 and later, the coded workflow's arguments are imported automatically into the activity.

Coded to low-code (or coded)

• workflows object: strongly typed calls to the project's workflows, for example int result = workflows.Increment(random);.
• RunWorkflow: pass the file path and a dictionary of inputs; the result dictionary holds the outputs:

var outputs = RunWorkflow("Workflows\\OpenTerminal.xaml",
    new Dictionary<string, object> { { "in_TransactionNumber", "TXN-88412" } });
var token = outputs["out_SessionToken"].ToString();

---

When to Choose Coded or Low-Code

Most projects mix both: low-code for the process skeleton, coded workflows or source files for the heavy logic.

---

Worked Example: Moving Validation Logic into Code

An invoice performer has a 60-activity low-code workflow that validates line items with nested loops and If activities. The team:

1. Creates a code source file with an InvoiceLine class and a LineValidator helper that returns a list of problems.
2. Creates a coded workflow ValidateInvoice.cs whose entry point is public (bool isValid, string reason) Execute(DataTable lines), so it has one In argument and two Out arguments.
3. Replaces the old workflow in Process.xaml with Invoke Workflow File pointing to ValidateInvoice.cs; the arguments lines, isValid, and reason are imported automatically.
4. Throws a BusinessRuleException in Process.xaml when isValid is False, so REFramework still marks the item as a business exception.
5. Adds a coded test case that feeds sample lines to the validator and checks the result with the testing service.

The process flow stays visible in low-code, while the validation logic becomes shorter, testable, and easy to review in Git.

---

Limitations to Remember

• Coded automations cannot be remote debugged.
• One [Workflow] or [TestCase] entry point per file.
• Coded automations require Windows or Cross-platform projects, not Windows - Legacy.