We are writing this one in July for a particular reader: whoever has just been handed an automation estate and been asked what is in it. Most automation estates are undocumented. The people who built them have moved on, the design documents were never written or were never updated, and the current owner inherited a folder of projects and a schedule. The usual response is a round of interviews, which produces an account of how people believe the processes work.
Our position is that interviews are the wrong thing to do first. The estate itself holds a more direct record. A UiPath process is a set of .xaml files, which are XML documents describing activities, arguments, variables and control flow. Power Automate desktop flows and Blue Prism releases export to comparable structured formats. Read at scale, those files describe what the automation actually does rather than what anyone remembers about it.
What the files contain
Here is what we pull out of a read, and what each piece is good for.
An activity inventory. Every action in every workflow, typed and counted. Reading activity types tells you how a process interacts with the world: whether it clicks screens, calls HTTP endpoints, runs database queries, manipulates Excel, or invokes custom code libraries. Watch the proportions, because a process built almost entirely from UI activities is coupled to interfaces somebody else controls and changes on their own schedule.
A call graph. Workflows invoke other workflows and pass arguments. Following those invocations builds a directed graph of the estate, which shows shared components, processes that depend on a single library, and the sequences that will need to be migrated together. That last group decides the shape of a migration plan, so we want the graph in hand before anyone proposes a sequence.
A selector map. Every UI selector names the application and the control it targets. Collected across an estate this yields the full list of systems the automation touches, including the ones nobody mentions in interviews. It also exposes the fragile ones: selectors relying on generated identifiers, index positions, or image anchors. We build this map early, because it tells you which interface changes outside your control can stop the estate.
Configuration and credential references. Projects carry configuration files, asset names and credential store references. Reading them shows which service accounts are in use, which processes share credentials, and where a secret sits in a configuration file or a variable default outside the credential store. That last case is the one we go looking for first.
Queue and transaction structure. Queue names, transaction item schemas and retry settings describe how work moves through the estate and how failures are handled. Two processes writing to the same queue is a dependency the owners often do not know about, and it is the kind of thing an interview will not surface because nobody thinks to mention it.
Error handling and its absence. Try and catch blocks, retry scopes and their configured limits are all visible. So are the paths with no handling at all. An unhandled exception path in a process that has already written a partial record is a specific risk with a file name and a line number against it.
Hardcoded values. File paths, server names, email addresses, thresholds and dates appear as literals in the XML. Each one is a maintenance liability and a clue about the environment the process assumes.
Dependencies and versions. Project files list package dependencies and versions, which shows what is pinned to an old activity package and what would need updating in any platform upgrade.
What that adds up to
From those inputs we produce a design document per process describing what it reads, decides and writes, in a form an engineer who has never seen it could work from. We produce a dependency and call graph across the estate, a risk register ranked by consequence, and a ranked view of which processes to modernise first. The whole pack comes out of the code, which means it describes the estate as it is on the day we read it.
What source code cannot tell you
We should be equally plain about the limits, because there are three questions the files will never answer for you, and they are the reason interviews still have a place.
The code cannot tell you whether the output still matters. A process that runs cleanly every night can be feeding a report nobody reads, and only the people downstream from it know.
The code cannot tell you why a rule exists. A validation threshold set to a particular number, or a step that skips a supplier, records a decision somebody made for a reason that is not written down. Some of those rules are load-bearing and some are historical accidents, and you cannot tell which from the XML. The difference decides whether the rule survives the rebuild.
The code cannot tell you who approves what. Automations frequently encode an approval as an email to an address, which describes the mechanism without describing the authority. Rebuilding the process properly means knowing who actually holds the decision.
Why we start from the code anyway
Interviews after a code read are a different conversation. The questions are specific ones about what the code cannot answer, asked with the documented behaviour of the automation already in hand. That takes fewer meetings, and the record it produces is consistent with what the software does.
If you are about to commission an estate review, that is the thing worth asking about. A proposal that opens with a fortnight of stakeholder workshops will build its picture of your estate out of recollection, when the workflow files that run every night are available to read on day one.
Back to the blog