Title: Idea & Request for Feedback: Convert REFramework Config into a Strongly-Typed Object (with Autocomplete) + Optional JSON

Help Studio
,
1

Hi everyone,

I’m exploring an improvement to the REFramework and I’d love your thoughts or contributions.

I want to build a workflow that loops through the Config dictionary and converts its content into either:

:white_check_mark: Option 1: A Strongly-Typed Object/Class

So instead of accessing values like:
Config("Asset1").ToString

We could access them with full IntelliSense, e.g.:
MyConfig.Asset1
…and get autocomplete for all config fields (Assets, Settings, Constants, etc.).

This would make config usage cleaner, reduce typos, and improve refactoring.

:puzzle_piece: Option 2: JSON Object

Also optionally generate a JSON object version of the Config for cases where structured or external usage is needed.

Idea I’m Considering

I thought of creating an Entity in UiPath Data Fabric that mirrors the config fields, then auto-mapping the config into that entity so it can be referenced centrally, possibly even shared across processes.

Before I proceed, I wanted to ask the community:

:small_blue_diamond: Has anyone already built something similar for strongly-typed Config access in REFramework?
:small_blue_diamond: Any suggestions on the best way to implement the strongly-typed object?
• Class? Record? Template + Codegen? Data Service entity?
:small_blue_diamond: Would you find this useful as a reusable component for Marketplace?
:small_blue_diamond: If so, would anyone like to collaborate on building it?

My goal is to make Config values easier to use, more maintainable, and less error-prone — especially for larger or multi-automation setups.

Any feedback, ideas, or interest in contributing is appreciated! :blush:

2

My perspective is, remove that damn config altogether. I hate needing to use the REFramework and messing around with it.

Its a legacy from the early RPA days and not a good option anymore.

There are two major things it gets used for in my opinion, getting the assets, and configuring things like the queue etc.

For the assets, you are actively making it harder by adding them to a config etc, its adding multiple points of failure and prevents the Orchestrator from validating that all the assets are available when you publish a process or move it between tenants.
If you need to use an asset, just use it in that workflow, keep the scope small and you are done. Stop putting them in a config.

After that you have some configuration things like the Queue Name, location of screenshots etc.

Again, this is an outdated approach and not embracing good coding concepts.

Take the queue stuff.
Instead of loading it via a config etc, why not have a workflow called ‘Get Transaction Item’ that, by default, only have the Get Queue item activity in it and its intended to be customized in the same way you customize the Application Start workflow.

In this manner you can just directly select the Queue name, reducing typos etc and letting the Orchestrator auto validate, but whats even better, is you can now actually add custom logic as required.
An example I had recently was that I had a difficult Citrix app where restarting didnt always clear an error, so before I grab the transaction I check if the application is ‘clean’, this is easy to do in this small, dedicated workflow now as custom ‘Stop logic’.
There are so many things you could do though, use it to dispatch items etc by looping over files in a mailbox for example. Basically you fix a ton of limitations and inflexibility that is forced from the Config.

Same is true for screenshots, the config forces you to store them locally. If you follow my approach you can save them where you like, be that Sharepoint, Storage Bucket, Locally, or even a combination of them.

So, TLDR, get rid of the config, in my experience people really struggle to accept this, its too radical for them and they are too invested in it. But believe me, its better without one.

1 Like