Taking over an RPA bot whose builder has left

The person who built the bot was transferred. Or they left the company. The bot keeps running every morning anyway, until one day a business partner’s screen changes and it stops. Only then does anyone notice that nobody knows what is inside. Companies that have run RPA for a few years know this story well.

Advice on “rogue bots” (野良ロボット in Japan) is almost always about rules to set before bots are built. What teams actually struggle with is the bots already running whose builders are gone. This article walks through how to take such a bot over without stopping it, and how to make sure it does not happen again. It applies to bots built with any RPA product, whether WinActor, UiPath, Power Automate, or BizRobo!.

Why bots end up fixable only by their builder

The steps exist only inside the scenario: you cannot tell what a bot does without opening the scenario in the RPA tool’s editor, and even then the builder’s intent is not written down
Procedure documents live apart from the scenario: the document written at the start has not kept up with later changes
Bots are built in departments the IT team does not know about: IT has no record of the bots a department built for itself
Bots run on a person’s PC or account: when the builder moves, the bot’s home moves with them, or disappears

None of this is a problem while the builder is still around. It becomes one when they are gone.

Before you start: do not stop it on the spot

Stopping a bot just because nobody understands it is risky. Other work, or other bots, may depend on the files it produces or the records it enters. Decide whether to stop it after you know what it does.

On the other hand, if you suspect it is processing data wrongly, stop it at once and investigate the impact. When in doubt, ask the team that receives its output.

Step 1: Find the bots

First, find out where and how many unowned bots are running. Look in these places:

Where to look	What you find
The RPA management server (WinActor’s WMC, UiPath’s Orchestrator, and so on)	Registered bots, schedules, and run history
Task Scheduler on the PCs that run bots	Bots started on a timer without going through the management server
Shared and personal folders	Scenario files, settings files, and output files
Sign-in history of bot accounts	Which systems they sign in to, and when
Interviews with business teams	What the receiving side remembers, such as “this file appears every morning”

As you find bots, list them right away, even if all you have is a name and where it runs. This list becomes your ledger later.

Step 2: Work out what each bot does

Take the bots one at a time, in this order:

Read the run history: when it runs, for how long, and whether it succeeds or fails
Pin down its inputs and outputs: which files or screens it reads, what it creates, and where it enters data
Check the screens and accounts it uses: which systems it signs in to with which account, and whether passwords are written into the scenario
Watch it run: in a test environment if you have one, or with the business team present if not
Ask the people who use its output: what they use it for, and what would go wrong without it

Pinning down inputs, outputs, and how it runs gives you the picture faster than reading the scenario line by line. Read the scenario only once you have decided it needs fixing.

Write down what you find as you go. Details slip away if you leave the writing for later.

Step 3: Assess the risk

From what you found, judge each bot on these points:

Impact of a stop: whether work is merely delayed, or payments and customer communications are affected
Impact of an error: whether it could enter a wrong amount or send something to the wrong recipient
Credentials: whether passwords sit in plain text in the scenario or settings files, and whether it runs under the account of someone who has left
Fragility: whether it operates systems, such as outside services, whose screens change without notice

Move on to step 4 starting with the bots whose impact is largest.

Step 4: Decide to keep, fix, replace, or retire

Decision	Suits a bot that
Assign an owner and keep it	Runs reliably and operates an internal system whose screens rarely change
Fix it and keep it	Stops for a clear reason and should be stable once fixed
Replace it	Operates screens that change often, faces many exceptions or judgment calls, or has nobody available to fix it
Retire it	Serves work that no longer exists, goes unused, or handles so few items that doing them by hand is enough

When replacing a bot, prefer an API or data integration if the system offers one. If the work can only be done on screen, choose automation that is easy to fix when the screen changes. The criteria are laid out in “Keep, fix, or switch to AI RPA” on RPA problems.

Step 5: Keep a ledger and handover notes

Whether you keep a bot or replace it, record what you found in two places.

In the robot ledger, give every bot one row: its name, run cycle, the work it does, inputs and outputs, owner and operator, what to do when it stops, and so on. A draft of the RPA implementation guide by FISC (The Center for Financial Industry Information Systems) says the ledger must be prepared before a bot goes live and updated whenever the bot is changed or its owner changes. Japan’s Ministry of Internal Affairs and Communications, in its guidebook for local governments, likewise warns that if changes made during operation are not reflected, handover becomes difficult when staff are transferred. The columns and how to fill them in are explained in How to build a robot ledger for RPA, and we provide an Excel template you can use as is.

In the handover notes, write what does not fit in a ledger row:

What the bot is for (its business purpose)
A summary of its steps, and where a person checks the work
What made it stop in the past, and how it was fixed
How to do its work by hand while it is down
The teams involved, and whom to contact

Keep the handover notes in the same place as the bot, and update them whenever the bot is fixed. Notes kept somewhere else by someone else soon drift from reality.

Step 6: Make sure it does not happen again

Once the handover is done, put rules in place so that a builder leaving no longer causes trouble:

No bot runs unless it is in the ledger: make a ledger entry a condition for running a new bot in production
Assign two people: separate the owner from the operator, and always update the ledger when someone is transferred
No bots on personal accounts or PCs: use bot accounts and a managed environment to run them
Update the ledger and handover notes with every change: whoever approves a change checks that they were updated
Take inventory once a year: compare the ledger with the bots actually running
Make sure every stop reaches someone: send failure alerts to a team, not to one person

Handing over in Kitewell

Descarty’s Kitewell is business automation software designed so that work can be fixed after its builder is gone.

The steps stay in the language of the work: steps such as “Enter the invoice amount” are themselves readable sentences
The assistant writes the knowledge: as the AI assistant builds and fixes a workflow, it writes down in the workflow’s knowledge what the workflow is for, why it was built that way, and how to fix it when it breaks, and it reads that knowledge before answering the next question
The ledger exports: every workflow’s name, run cycle, description, the Excel files it reads and writes, the systems it connects to, and its knowledge export to Excel as a robot ledger following FISC’s management items. Columns people decide, such as the owner and the error policy, are left empty
Every run and change is recorded: what ran and when, how each workflow changed, and which step stopped

To replace the RPA bots that stop most often, see How to switch from RPA to AI RPA.

Summary

Do not stop an unowned bot on the spot. Start with its inputs and outputs, how it runs, and the people who use its output
Starting with the bots whose impact is largest, decide to keep, fix, replace, or retire each one
Record what you find in a ledger and handover notes, kept with the bot and updated with every change
Ledger registration, two people per bot, managed environments, and a yearly inventory keep it from happening again

Sources

FISC (The Center for Financial Industry Information Systems): Draft of the RPA implementation guide (study material, December 2019, in Japanese)
Ministry of Internal Affairs and Communications: RPA guidebook for local governments (July 2025, in Japanese)