Robotic Process Automation
Automation that works through an application's own screens, the way a person would, for systems that have no suitable API or other direct integration. Used when a supported integration is unavailable or impractical, and built with monitoring and clear points for people to step in.
Some systems offer no usable API, charge heavily for one, or sit with a vendor who will not change anything quickly. The work still has to happen, so a person logs in, clicks through the same screens and downloads or re-keys the same records.
A deliberate trade-off
Robotic process automation can remove repetitive manual work. It is generally a more fragile method than a supported API or other direct interface, because it depends on screens, selectors and timing intended for people. A change to the user interface can break the automation even when the underlying business process has not changed.
We prefer a supported API, file interface or other direct integration where one is reliable and appropriate. RPA is useful as a transitional or constrained option, or where replacing the underlying system is not currently practical. It should not be treated as equivalent to a supported integration, and it should not be used to bypass access controls.
Where it can still be the right choice
No usable direct interface
The vendor does not offer an API, or the available interface does not cover the part of the system that is needed.
A temporary path while a better one is developed
A direct integration is possible later, but the manual work cannot wait, or access is months away.
A process that lives in one person's click path
The work stops when that person is away, and the steps exist only as habit.
What we do
Where a direct interface becomes available later, the automation can be reduced or replaced.
Document the manual process
Every step, screen and exception is recorded before anything is automated, so the automation matches the real process.
Automate the stable parts
We identify the parts of the interface that rarely change and automate browser or application interactions through them.
Validate results and detect failure
Inputs and expected results are checked, sessions are handled, and common failures such as a changed screen are detected.
Define where people step in
We agree what happens when the automation stops, who is told, and how evidence of completed and failed work is kept.
What you end up with
An automation that records its work
Evidence of completed and failed runs, so staff can see what was done and what needs attention.
Alerts when a screen changes
Monitoring that stops the run and tells someone when the interface no longer matches what the automation expects.
A written description of the process
The manual steps and rules documented, which is also the starting point for a direct integration if one becomes possible.
How a typical engagement works
01Document
Document the manual process
We record each step, screen and exception as the process actually runs.
02Direct route
Check for a direct route
We look again for an API, a database or a file interface, because those are more reliable when they exist.
03Build
Build with guardrails
Write steps are limited, the run stops when the screen does not match, and evidence is kept for every run.
04Monitor
Monitor and review
Alerts reach someone able to act, and the arrangement is reviewed as the underlying system changes.
05Revisit
Revisit when a direct route appears
When a direct interface becomes available, the automation can be reduced or replaced.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.