When a screen looks different from what the workflow expects, the bot should stop, record what it saw, alert its owner and leave the data as it was. Guessing and carrying on is the unsafe choice, because a bot that clicks the wrong button does so at machine speed and at volume.
Why screens change under bots
RPA imitates a person using an application's interface. Wikipedia's overview notes that current RPA solutions need ongoing technical support when systems change, and that they cannot adapt on their own, so they sometimes need manual reconfiguration. An update to the target application, a new pop up, a renamed field or a different language setting can all change what the bot sees.
For security, the question is not whether this will happen, but what the bot does when it does.
Failure modes worth designing for
| Change | Unsafe result | Safer design |
|---|---|---|
| A field moves | Bot types data into the wrong field | Check field labels before typing |
| A new confirmation dialog appears | Bot confirms something it should not | Treat unknown dialogs as a stop condition |
| A page loads slowly | Bot acts on the previous record | Wait for a clear marker before each action |
| A login page changes | Bot enters credentials into a lookalike page | Verify the address before entering secrets |
| A success message is missing | Bot assumes success and moves on | Require a positive confirmation |
Design rules
- Fail closed. An unrecognised state means stop, not continue.
- Verify before write. Confirm you are on the right record and the right screen before changing data.
- Make steps safe to repeat. If a run restarts, it should not create duplicate payments or messages.
- Limit the damage. Cap how many records one run may change, and alert if the cap is reached.
- Keep a person in the loop for irreversible actions, such as sending money or deleting records.
- Never print credentials to logs or screenshots when an error occurs.
Test the failure path, not just the happy path
Most testing proves the bot works on a clean day. Add tests that feed the bot an unexpected dialog, a missing field and a slow page in a test environment, and check that it stops and alerts. Run them again when the target application is upgraded, which you can learn about by asking the application team to notify bot owners of releases.
Who gets the alert
An alert to an inbox nobody reads is not an alert. Name an owner and a backup owner, and decide how fast someone must respond. Include in the alert the bot name, workflow version, the step that failed and the screen capture, if you capture screens and can protect them.
Decide what happens to partly done work
If a bot stops halfway through a batch of fifty records, you need to know which ones were changed. Keep a per record status so a person or a restarted run can pick up exactly where it stopped, without redoing finished items.
Where Safeguard fits
Safeguard does not monitor RPA screens. It can help with the surrounding software estate through asset discovery and continuous dependency monitoring for custom code your automation relies on.
Quick check
Should a bot retry when a step fails?
A limited number of retries with a pause is fine for timing problems. An unexpected screen should stop the run instead.
Is screenshot capture on error safe?
Only if the captures are protected and sensitive fields are masked. Otherwise a failure can copy personal data into logs.
Sources
Last reviewed: 19 October 2026.
