I’ve been revisiting the UiPath REFramework template and wanted to get a sense of how others are thinking about it today.
On one hand, I still find it very valuable for transactional automation—especially the built-in robustness around retries, exception handling, and state management.
On the other hand, parts of it feel increasingly tied to older platform assumptions. In particular:
- The heavy reliance on a global Config dictionary (typically backed by Config.xlsx)
- Initialization patterns that assume static environment configuration
- Tight coupling between workflows and centralized config values
With modern Orchestrator features (assets, queues, modern folders, runtime parameters), it seems like some of this indirection may no longer be necessary—or could be handled in a more modular way.
What I’m struggling with is:
- How far to go in refactoring vs. just using the template as-is
- Whether others are moving toward lighter, argument-driven or asset-driven designs
- If there are any “modernized” versions of REFramework (or alternatives) that retain its robustness without the legacy patterns
I’m also trying to understand UiPath’s intended direction here. Is there a broader architectural roadmap that more clearly defines how Studio projects are expected to integrate with Orchestrator features (assets, queues, folders, etc.) in a consistent way?
Curious how others are approaching this:
- Are you still using REFramework as your default?
- Have you modified it significantly (e.g., removing Config.xlsx)?
- Or have you moved to a different architectural pattern altogether?
Would appreciate any examples or patterns you’ve found effective.