Getting Started with the UiPath REFramework

RPA & Automation#uipath#reframework#best-practices


When I started building UiPath automations, most of my early workflows were a single linear sequence: open the app, do the thing, close the app, done. That’s fine for a proof of concept, but it falls apart the moment something breaks in production — a popup appears, a website times out, a file is locked — and there’s no structured way to recover, log, or retry.

The Robotic Enterprise Framework (REFramework) solves this by giving every process the same skeleton:

  • Init — open config, connect to apps/queues, validate everything is reachable
  • Get Transaction Data — pull the next unit of work (a queue item, a row, a file)
  • Process Transaction — do the actual work for one transaction
  • Set Transaction Status — mark it successful or failed, with a reason
  • End Process — close applications, release resources, send a summary

The part that took me longest to appreciate was the distinction between business exceptions and system exceptions. A business exception (“this invoice has no PO number”) should be logged and the transaction skipped — the robot keeps going. A system exception (“SAP didn’t respond”) should trigger a retry, and if retries are exhausted, kill the current app cycle and restart clean via the Kill and Recover flow. Getting that split right is what makes a robot resilient instead of something that needs babysitting.

A few things I’d tell past-me:

  1. Use Queues from day one, even for “simple” processes. It gives you retry counts, SLA tracking, and a clean way to requeue failed items without re-running the whole batch.
  2. Config.xlsx is not a dumping ground. Keep selectors, credentials (via Orchestrator assets, never hardcoded), and business rules separate from each other.
  3. Log the transaction identifier on every single log message. When something fails in production at 2am, that’s the one thing that lets you find the right row without guessing.

Next up, I want to write about moving selectors out of individual activities and into a shared “Object Repository”-style approach — happy to expand on that if it’s useful.