Business Cases
Part of Robotic process automation
RPA versus application integration
Compare API or connector integration with a UI bot for the same transaction, including access, result checks, failures and mixed routes.
Choose the access method by examining the action a system must perform. An API or connector can call a supported application function directly; a UI bot acts through screens.
If both routes are available, compare permissions, validation, errors, result checks and maintenance for the same transaction. A bot workflow can also combine the methods.
Compare one transaction
Write down the input and verified output. For a hypothetical approved request, the action might be to create a record in another system and return its identifier.
Ask the destination application owner whether a supported integration can create that record, which fields it accepts and what response it returns. Then ask whether the screen offers the same action and how a bot would confirm the record was saved.
| Decision point | Integration route | UI bot route |
|---|---|---|
| Access | Requires an available, authorised API or connector action. | Requires authorised application access and a usable interface. |
| Input and result | Check documented fields, validation and the returned response. | Check what the screen accepts and what the destination record shows. |
| Failure | Examine the error and destination state. | Examine the bot error, screen state and destination record. |
| Change | Track changes to the interface contract and permissions. | Track changes to screens, selectors, session and permissions. |
Neither route guarantees a reliable outcome. A connector may expose only some application functions. A screen may show a success message before all downstream work has finished.
Integration route vs UI bot route: key decision factors
- Access
- Requires an available, authorised API or connector action.
- Access
- Requires authorised application access and a usable interface.
- Input and result
- Check documented fields, validation and the returned response.
- Input and result
- Check what the screen accepts and what the destination record shows.
- Failure
- Examine the error and destination state.
- Failure
- Examine the bot error, screen state and destination record.
- Change
- Track changes to the interface contract and permissions.
- Change
- Track changes to screens, selectors, session and permissions.
Steps to evaluate integration vs UI bot for a transaction
- Define input and verified outputFor a hypothetical approved request, identify the action (e.g., create a record) and expected identifier.
- Check for supported API or connectorConfirm with application owner if the system supports direct creation via API or Power Automate connector.
- Assess screen-based alternativeDetermine if the UI can perform the same action and how a bot would verify success.
- Compare reliability and maintenanceEvaluate permissions, error handling, validation, and change tracking for both routes.
- Decide on combination approach if neededUse API for initial check, bot for unsupported actions, and confirm outcome via API again.
Pros and cons of integration vs UI bot
- Integration (API/connector)
- Direct, reliable, scalable, easier to maintain, better audit trail.
- Integration (API/connector)
- Limited by what the API exposes; may not support all business actions.
- UI Bot
- Can act where no API exists; works with existing user interfaces.
- UI Bot
- Fragile to UI changes; harder to debug; requires ongoing maintenance.
When integration is a candidate
Examine a supported API or connector first when it can perform the required action under the organisation’s approved access model. Check field coverage, application validation and the information returned for reconciling the transaction.
Ask who owns changes and how failures are reported. An endpoint that can be called is insufficient if it cannot carry out the approved business action.
In Power Automate, connector actions use authenticated connections and connection references. Each connection is specific to a user and requires authentication.
Confirm what the chosen platform actually provides instead of assuming that a listed connector covers the task. Document any missing action before adding another method.
Checklist: When to use integration vs UI bot
- ✅ Check if a supported API or connector is availableEnsure it’s part of the organisation’s approved access model.
- ✅ Confirm field coverage and validation rulesVerify the API supports required fields and business logic.
- ✅ Validate error reporting and response formatEnsure errors are meaningful and outcomes reconcilable.
- ✅ Document missing functionality before adding alternativesDon’t assume a connector covers every action — validate each use case.
- ✅ Verify connection ownership and authentication requirementsPower Automate connections are user-specific and require auth.
Key stats: Integration and UI automation in Australian businesses
- Common failure point in UI botsScreen changes breaking selectors
- Most common reason for choosing integration over RPABetter long-term reliability and compliance
When a UI bot may be justified
A UI bot may fit when staff can perform the authorised action through an application screen and no suitable supported integration is available for it. The bot needs a dependable way to identify the item and controls, and to verify the saved result.
Confirm with the application owner that automated use is permitted, which identity the bot should use and what interface changes are expected. Send ambiguous business decisions to a person. The presence of a field must not be treated as approval.
Combine routes with a clear handoff
A workflow could receive eligible items through a connector, use a UI bot for an unsupported action and check the destination through an available API. Use a shared business reference and record status at each handoff.
If the UI action times out, check whether the record was created before retrying. Decide which system is authoritative when the routes disagree.
Choose the route for each required action. Record the material limitation of any alternative considered and the evidence that will show completion. Revisit the decision if the application adds a supported function or changes its interface.
