Writing canvas-friendly coded workflows

Recommendations for structuring coded workflows so the Low-Code Viewer renders them as clean, readable low-code diagrams.

A little structure goes a long way toward a clean canvas. The recommendations below help the Low-Code Viewer render your coded workflow as readable low-code blocks instead of opaque code blocks. They are ordered by impact, starting with the changes that matter most.

UiPath services over hand-rolled code

Calls to the project's services — system.AddQueueItem(...), excel.ReadRange(...), mail.SendSmtp(...), uiAutomation.Click(...) — render as rich activity cards: a friendly display name, the service icon, editable properties, and a typed output variable.

The same operation implemented from scratch — with HttpClient, System.IO, or a NuGet Excel library — renders at best as an Assign card holding one long expression, and at worst as a code block. Reaching for the activity packages first, and dropping to custom C# only where no activity covers the need, keeps more of the workflow visible.

// Renders as a "Write Range" activity card with editable properties:
excel.WriteRange("C:\\out.xlsx", "Sheet1", "A1", table);

// Renders as an opaque code block:
using var writer = new StreamWriter("C:\\out.csv");

The entry method as an orchestration layer

The Graph view draws only the entry method ([Workflow] or Execute). Every call to one of your own methods becomes a single labeled block, and selecting it drills into the helper.

Keeping the top-level branching, loops, and error handling in the entry method, and moving detailed step sequences into well-named private methods, makes the graph read as a clean, high-level flow — ValidateInvoice → PostToQueue → NotifyFinance — instead of a wall of low-level cards. Each helper also gets its own section in the Workflow view, so nothing is hidden. Intention-revealing names matter double here: the method name is the block label.

Control flow as statements, not expressions

The canvas can only draw branching and looping that exists at the statement level. Logic tucked inside expressions — lambdas, Language Integrated Query (LINQ) chains, nested ternaries, or switch expressions — is compressed into a single card, which defeats the purpose of the visualizer.

The switch distinction is worth noting: a switch statement renders fully, as a Switch container with one arm per case, while the expression form (var label = total switch { ... };) stays compressed inside a single Assign card. The statement form is the better choice when the branching is a process step a reader should see.

// Invisible logic — one code block, the filtering and branching are not drawn:
invoices.Where(i => i.Amount > 1000).ToList().ForEach(i => Approve(i));

// Visible logic — a loop containing a decision containing an Invoke block:
foreach (var invoice in invoices)
{
    if (invoice.Amount > 1000)
    {
        Approve(invoice);
    }
}

A LINQ one-liner is still fine when it is a simple projection whose detail you would happily hide (var names = rows.Select(r => r.Name).ToList(); renders as one Assign card). The rule of thumb: if a reader of the diagram should see the branching, write it as if, switch, or foreach.

Renderable equivalents for fallback constructs

Several common constructs fall back to code blocks. Each has a renderable equivalent that produces visible blocks instead.

Instead of	Schreiben	Because
list.ForEach(x => ...)	foreach (var x in list)	The body becomes visible blocks
Local functions	Private methods	Private methods render as navigable Invoke blocks
using var handle = excel.UseWorkbook(...);	using (var handle = excel.UseWorkbook(...)) { ... }	The block form renders as a scope frame, and lets calls on handle inside it resolve as activities
int a = 1, b = 2;	One declaration per line	Each becomes its own Assign card
string result; ... result = ...; later	A declaration with an initializer at first use	Bare declarations fall back to code blocks

Inline variable declarations, one per statement

A declaration with an initializer renders as an Assign card (or as the output of an activity card) and feeds the per-method Variables panel. A bare declaration renders as a code block. Declaring each variable where its value is first produced keeps it visible.

var asset = system.GetAsset("Config");        // activity card, output: asset
int retryCount = 0;                            // Assign card, typed

Explicit types where the viewer cannot infer them

The canvas labels each output variable with the best type it can find:

• For recognized activity calls, the type comes from the package metadata automatically. var asset = system.GetAsset(...) already displays the real return type, so var costs nothing there.
• For everything else — plain assignments, calls to your own methods, and computed expressions — var displays literally as var. An explicit type puts the real type on the card and in the Variables panel.

var totals = ComputeTotals(rows);        // Variables panel shows: totals : var
DataTable totals = ComputeTotals(rows);  // Variables panel shows: totals : DataTable

Comments that describe intent

A // comment placed directly above an activity, method call, if, foreach, for, switch, try, return, or #region is attached to that block. It becomes the card's description in the Graph view, the row tooltip in the Workflow view, and the Description field in the properties panel. Consecutive comment lines are joined.

// High-value invoices need manual approval before posting
system.AddQueueItem("InvoiceApproval", reference: invoice.Id);

Comments that do not sit above such a statement render as their own small code rows, so one purposeful comment per step reads better than scattered commentary.

Process phases grouped with regions

#region Name ... #endregion renders as a named, collapsible group in both views, and regions can nest. When regions are named after business phases — Login, Process invoices, Reporting — a collapsed graph reads like a process summary, and expanding a region reveals its steps.

Related assignments grouped together

Two or more consecutive assignments fold into a single Multiple Assign card. Initializing related values in one uninterrupted run keeps them in one tidy card instead of scattering them across the flow. Conversely, an assignment that deserves its own card should stand apart from other assignments.

One call per statement

When calls are chained (row.GetValue("col").ToString().Trim()), the viewer can only surface the chain as a single row, and chains on unrecognized receivers fall back entirely. Splitting a meaningful chain into steps with named intermediate variables gives each step its own block. For handle APIs, such as Excel workbooks and mail folders, it also lets the viewer track the handle so follow-up calls render as proper activities.

Recognizable workflow invocations

• workflows.MyOtherWorkflow(arg1, arg2) renders as a dedicated Invoke Workflow card, with each argument badged by direction (In, Out, or InOut) and navigation to the workflow file.
• SharedHelpers.Method(...) calls into another .cs file of the project render as navigable Invoke blocks. Keeping these as a single call per statement, rather than part of a longer chain, is what lets them resolve.

Quick checklist

• Steps use activity services (system., excel., mail., and similar), not hand-rolled equivalents.
• The [Workflow] method is short and orchestrates well-named private methods.
• Branching and looping are statements (if, switch, foreach, for, while, try), with no logic hidden in lambdas or LINQ pipelines.
• Variables are declared inline, one per statement, with an initializer.
• Explicit types are used where the viewer cannot infer one, such as helper-method results and computed values.
• A one-line // comment sits above each significant step.
• Process phases are wrapped in #region.
• Each statement holds one service or helper call, with no long chains.
• Other workflows are invoked through workflows.X(...).
• No grey Code block cards are left on the canvas — each one is a spot where the visual view went blind.

Zugehörige Inhalte

• Low-Code Viewer
• Coded automations introduction
• Best Practices