Human Oversight
Part of Robotic process automation
Checking whether a user-interface bot is appropriate
Review a proposed UI bot’s authority, screen reliability, runtime conditions, result checks and exception route before a pilot.
A user-interface bot is a candidate only when its action is authorised, it can identify the right screen and its business result can be checked. Hold the proposal if it would have to guess at a decision, use inappropriate access or repeat an action whose result is unknown. This review concerns a defined UI action after the task itself has been chosen.
Establish why the screen is needed
Name the exact action, such as entering an approved value into an application and saving the resulting record. Ask the application owner whether a supported API or connector can do it. If so, compare the access methods for that action. If the screen remains necessary, record why and confirm that automated use is permitted.
Keep the bot’s authority narrow. State which cases it may open, which fields it may change and which decisions must already have been made. Reaching a button does not authorise a bot to use it for every case.
UI bot vs API/connector: Access method comparison
- Method
- UI automation (bot)
- Reliability
- Depends on stable UI; may fail if elements change
- Access control
- Requires explicit permission for each screen and field
- Maintenance effort
- Higher – requires updates when UI changes
- Alternative method
- API or connector (preferred where available)
- Recommended use case
- When no supported API exists
Inspect the screen and runtime
Ask the technical owner how the bot will find each control and distinguish it from similar controls. UI selectors may use element attributes that change between runs. Review pop-ups, multiple windows and views that differ by user role. Confirm how the saved result can be found again by a business reference.
Check the conditions of the proposed runtime. Microsoft says an unattended Power Automate desktop flow normally uses a remote desktop session and, on Windows 10 or 11, an active user session can prevent a run even when locked. Its documentation also describes a configurable session-reuse feature. Confirm the applicable machine, session and product settings rather than applying one configuration’s rule to every bot.
Resolve uncertain outcomes before building
Situation / Decision to settle
- Required information is missing.
- Who corrects it, and how is the item held?
- The screen is unfamiliar.
- Does the bot stop and alert an owner?
- Save reports an error or times out.
- How will the destination state be checked?
- The same item appears again.
- What reference prevents an unintended second action?
- The bot’s access changes.
- Who checks its permissions and the next run?
Keep an uncertain item and its current state visible to an owner. A retry must not turn an unknown result into a duplicate record. These responses need to be agreed with the process and application owners for the proposed action.
Steps to validate a UI bot before pilot
- Confirm authorised access and scopeDefine which screens, fields and decisions are permitted
- Verify selector stability across sessionsCheck that UI elements remain identifiable under runtime conditions
- Define outcome verification methodEnsure the result can be confirmed via reference or status check
- Set exception handling protocolAgree on actions for missing data, errors, or repeated items
- Document assumptions and risksRecord dependencies that could invalidate the bot’s operation
Decide whether to proceed
A bounded UI pilot is reasonable when there is a named business owner, authorised access, a reliable way to find the target, a check of the business result and a route for uncertain cases. Record assumptions and application changes that could invalidate the decision.
Revise the proposal if a missing control can be supplied, such as a completion check or narrower permission. Hold it if the action needs unresolved judgement, automated access cannot be authorised or the team cannot tell whether an attempted write succeeded. Task stability is a separate pilot-selection decision; this review determines whether using the interface is an acceptable way to perform the action.
