Before an RPA workflow goes live or changes, someone other than the builder should confirm six things: the owner, the access it uses, where secrets live, how it fails, how it is logged, and how to roll it back. Put them in a ticket so approval leaves a record.
Why bots need change control
Workflows get edited often, because target applications change and bots need reconfiguring. Wikipedia's overview notes the maintenance burden of RPA when systems change. Frequent edits under time pressure are exactly when mistakes and shortcuts creep in, such as a pasted password or a widened role.
The checklist
Copy this into your change ticket.
Ownership
- Named owner and backup owner.
- Business purpose in one sentence.
- Review date set.
Identity and access 4. Dedicated bot account, not a person's login. 5. Permissions limited to the steps used, with exceptions noted. 6. Sign in limited to the machines and times the bot needs.
Secrets 7. Credentials fetched from the managed store, none in the workflow. 8. Logs and screen captures checked for secrets and personal data.
Behaviour 9. Unexpected screens or errors stop the run and alert the owner. 10. A cap on how many records one run may change. 11. Irreversible actions have a person's approval. 12. Safe to repeat without creating duplicates.
Testing 13. Tested in a non production environment with test data. 14. Failure cases tested, not just the clean run.
Operations 15. Run logs tie actions to bot, version and owner. 16. Rollback steps written, and the previous version is kept. 17. Alerts go to a monitored place.
Who approves
The builder should not approve their own change. A second person from the same team, or from IT operations, checks the list. For bots touching payments, personal data or admin systems, add a security reviewer.
Use version control if you can
Many RPA tools let you export workflow definitions as files. Storing them in a repository gives you history, a reviewer and the ability to compare versions. If you do, a pull request can carry this checklist, and a required review keeps solo edits from reaching production. The same habit helps with custom scripts that bots call.
Emergency changes
Sometimes a fix cannot wait. Allow an expedited route with a named approver, and require the full checklist within a short, agreed time afterwards. Count these in your reviews, since too many signal a fragile process.
What to measure
Track how many changes skip the checklist, how many bots have no owner, and how long a rollback takes in a drill. Those three numbers tell you more than a count of bots.
Where Safeguard fits
Safeguard's pull request gates and policies apply to code in your repositories, such as scripts your automation team keeps there.
Try it yourself
If your team keeps exported workflows or helper scripts in a repository, click through this demo to see how a pull request gate can stop a risky change before merge. Look at what the gate checks and what the reviewer sees.
Click through it at your own pace, or open it full screen.
Quick check
Do small edits need the full checklist?
Use a short version for low risk edits, and the full one when access, secrets or irreversible actions change.
Who should approve emergency changes?
A named approver from IT operations or security, with the full review completed afterwards.
Sources
Last reviewed: 19 October 2026.
