Low Code Viewer Extension Release

News Release Notes
1

:waving_hand: Hey Community!

We’re excited to announce the Low-Code Viewer — see and edit your coded workflows as a visual workflow, side by side with the C# source code.

If you’ve ever opened a coded workflow and wished you could read it the way Studio shows a classic RPA workflow — this one is for you. Open a coded workflow and a visual canvas opens right next to the code. The two stay in sync at all times: the canvas follows your code as you type, and edits you make on the canvas are written back into the source.

hero-canvas-beside-code
hero-canvas-beside-code2654×1070 331 KB

Why we built it

Coded automations are powerful, but they raise the bar for everyone who needs to read them. With the Low-Code Viewer:

  • RPA developers get a live visual map of the workflow while writing C# — great for keeping the big picture and navigating larger files.

  • Teammates who prefer the visual designer can understand a coded workflow — and even tweak activity properties — without parsing every line of code.

What you get

Two views of the same workflow

  • Workflow view — a Studio-style tree of the whole file: each method gets a section with its variables and one row per statement, with nested containers for If, For Each, While, Try/Catch, and Switch.

  • Graph view — a flow chart of the workflow’s entry point. Conditions become decision nodes fanning out per branch, loops get iterate edges, and calls to your helper methods appear as Invoke blocks you can click into. Flip the layout between left-to-right and top-to-bottom.

two-views-graph
two-views-graph538×930 28.8 KB

Always in sync — in both directions

  • Move the cursor in the editor and the matching block is selected on the canvas.

  • Click any block and the editor jumps to its line — including helper methods defined in other files of your project.

  • Edit a property in the properties panel and the change is written back to your C# as a minimal, surgical edit — comments and formatting are untouched.

sync-demo

Your project’s real activities

The activity palette — icons, display names, and property editors — is sourced live from the activity packages your project references. Add or update a package and the canvas picks up the new activities automatically.

Your code is never lost

The viewer never rewrites code you didn’t touch. Anything it doesn’t recognize is rendered verbatim as a Code block card and round-trips unchanged — so it works on any existing coded workflow, and you can adopt it gradually.

The little things

  • #region blocks become named, collapsible groups in both views.

  • workflows.MyWorkflow(…) calls render as Invoke Workflow cards with In/Out argument badges.

  • Variable declarations, assignments, increments, returns, and throws all get dedicated cards.

  • The canvas follows your theme, light or dark.

Tips: writing canvas-friendly coded workflows

Any coded workflow works out of the box, but a little structure makes the canvas shine:

  1. Prefer service calls (activities) over hand-rolled code. excel.WriteRange(…) renders as a rich activity card with editable properties; a custom StreamWriter renders as an opaque code block.

  2. Keep your entry method an Orchestrator​. The Graph view draws the entry method — move detailed step sequences into well-named private methods and the graph reads as a clean high-level flow: ValidateInvoice → PostToQueue → NotifyFinance.

  3. Express control flow as statements, not expressions. if / foreach / switch statements are drawn as containers and decision nodes; logic hidden inside lambdas or LINQ chains collapses into a single card.

How to get it

  • Install from the Open VSX marketplace — this first iteration is not shipped in the Studio installer.

  • Requires the latest Studio STS build for the coded-editor preview to work correctly.

For more information, refer to Low-Code Viewer and Writing canvas-friendly coded workflows.

We’d love your feedback

This is our first release and we’re actively building. Tell us:

  • How does the canvas handle your coded workflows? Did anything render as a code block that you expected to be a first-class card?

  • Which edits would you like to make from the canvas that you can’t today?

  • What would make this indispensable for your team?

Reply below with feedback, questions, or screenshots of your workflows on the canvas — we’re listening. :rocket:

Happy automating!
The UiPath Studio team

6

The next logical step would be to entirely abandon XAML file format and store workflows as C# code, right?

Cheers

7

C# code comes with some benefits over XAML: unit testing, easier code review and friendlier to coding agents. On the other hand, the activities UI offer a rich experience guiding users on which configuration is valid. I am not aware of any plans to drop XAML in the near future, but depending on user feedback we might implement a migrator that converts XAML workflows into coded workflows.

8

I like that I’m seeing more and more support for C# in UiPath. I think having it as an option for the interface is a huge benefit of UiPath over other automation platforms.

I think a lot of us who have used RPA technology for a while to see the benefit of being able to put logic in code. Especially in the era of AI-assisted development, where it makes it much easier to use LLMs.

9

Hi @andreea.oprita nice release

the thing that sells it for me is the code review side, reviewing xaml diffs in a pull request is painfull and you usually end up opening Studio just to see what changed. Coded workflows plus a canvas people can read solves that without forcing everyone into c#

one question, does Workflow Analyzer run over coded workflows the same way it does on xaml? in a bigger pipeline thats what keeps the rules enforced before publish, and mixing both styles gets tricky to govern if it doesnt

hope the feedback helps :slight_smile:

10

so does it mean , when this step will be implemented , we will not able to use drag and drop features and we will be not able to use flowcharts or what does it mean by abandon xaml file format?

11

It was just an idea… XAML is just a convention how the “visual” code is stored.
If the Low-Code Viewer can interpret the C# code as a visual workflow I can imagine the opposite way - save visual workflow as C# code.

But as I said - just an idea. This could involve a number of pitfalls.

Cheers

12

Thanks. I was thinking that since UiPath started as a low-code/no-code platform, it built its community around that core philosophy. Because it required minimal coding, it gave many QA professionals and people from non-development or even non-IT backgrounds an opportunity to enter the IT industry and build successful careers.

Now, however, UiPath seems to be moving more toward a code-centric approach. While this will likely attract more developers and experienced programmers to the RPA domain—which is certainly beneficial for UiPath as a company—it may create challenges for those who transitioned into RPA with limited coding knowledge.

Of course, upskilling and learning programming is always a good idea, but the reality is that becoming a strong developer is a long and demanding journey. Not everyone can make that transition easily or quickly.

In the long run, I believe this shift could reduce the number of people using UiPath, especially when combined with the increasing licensing costs. In my opinion, UiPath should continue to embrace its low-code/no-code identity, as that has always been one of its biggest strengths and a key reason for its widespread adoption.

13

Coding agents have changed the landscape a bit. More people find it easier to write prompts in plain English to express what they want and the coding agents produces the code for them. The problem this creates is that the generated code is hard to understand for non-developers. This low-code extension comes to bridge this gap a bit by offering RPA developers a familiar view that they can use to inspect and understand this generated code.
It is also a bit easier for coding agents to write c# code than xaml and it gives them more freedom to write helpers where no activity exists.

Where xaml workflows shine, in my opinion, is the curated experience for activities like GSuite or any connector activity, where it guides the users, with pre-populated drop-downs, to select the right folders and filters they want. These activities do the heavy-lifting of calling the underling APIs and present the user with human-readable information regarding the configuration of the activity.

Ultimately, we encourage users to pick the right tool for the job, which is why we try to offer more flexibility in this choice.