When a business wants to automate a repetitive task, two approaches come up often: robotic process automation, usually shortened to RPA, and custom scripts written in a language like Python. They can solve similar problems and they are different tools with different strengths. Choosing the wrong one is an expensive way to learn the difference.
What RPA is
RPA tools build software robots that imitate what a person does on a screen: clicking buttons, typing into fields, copying values between applications. They are usually configured visually, which makes them approachable for people who are not developers.
They shine where there is no other way in. An older system with no interface to connect to, a vendor portal you can only use through its web pages, or a desktop application that offers nothing but its screen.
What Python and API-based automation is
A script or service talks to systems directly, through their APIs or databases, instead of pretending to be a user. It reads and writes the data itself, without moving a mouse. It needs someone who can write and maintain code.
Where RPA struggles
Because it depends on the screen, it is fragile. If the vendor moves a button, renames a field or changes a login page, the robot breaks. Robots can also be slow, since they work at the pace of the interface, and they can be awkward to test and to monitor. Licensing costs can add up as the number of robots grows.
Where code struggles
Code needs a way into the system. If the application offers no API or database access and only a screen, a script has nothing to work with. It also needs developer skills to build and maintain, which not every business has in house, and changes take longer to make than adjusting a visual flow.
Where code wins
When there is a proper interface, scripted automation tends to be faster, more reliable and easier to test. It can be version controlled, reviewed and monitored like any other software, and it handles errors in a way that can be designed. It is generally less affected by cosmetic changes to a screen.
Questions that decide it
Does the system have an API or give you database access? If yes, use it. How often does its screen change? How much volume will it handle, and how fast must it be? Who will maintain it in two years? How will you detect and recover from errors? And what does it cost over three years, including licenses and the time of whoever looks after it?
A sensible default
Prefer going through an interface when one exists, because it is sturdier. Use screen-based automation as a bridge for systems that give you no other way, and treat it as something that needs watching. Many real solutions combine the two.
Do the groundwork either way
Whichever tool you choose, automating a process you have not described properly causes trouble, which is why we recommend documenting the process first. And any automation needs graceful failure handling, covered in how to make an integration fail gracefully. For the broader question of when code is the right tool, see when to use Python versus a BI tool, and for the basics of interfaces, what a REST API is.
If you have a manual process in front of an older system and are unsure how to automate it, reach out. We will start by checking whether there is a proper way in.
Have a question about this topic? We work with businesses worldwide.
Get in Touch