RPA & Selenium
A robot that drives software through its screen, exactly as a person would.
RPA stands for Robotic Process Automation, which sounds far grander than it is. A program clicks the buttons and fills the fields that a person would. Selenium is the best-known tool for doing that inside a web browser.
It matters because of a problem every SME hits eventually: the system holding your data has no proper way to talk to other software. Old accounting packages, supplier portals, government sites, that one industry tool nobody has updated since 2014. No API, no export worth having, and the vendor is not going to build one for you.
RPA is the way in. If a person can do it on a screen, this can usually do it too — at 6am, every day, without getting bored on the fortieth record. It is also the most fragile thing on this page, and anyone who tells you otherwise has not maintained one.
Every morning someone logs into three supplier portals, downloads a stock file from each, opens them, copies the columns that matter into a master sheet, and fixes the formatting. Forty minutes, and it is the least interesting part of their job.
At 6am the robot has done all three and left one clean file where the reporting picks it up. Your person opens a finished sheet. On the day a portal changes its layout, they get an email instead of a surprise.
Why this exists at all
RPA occupies an odd position. It is simultaneously the least elegant thing we build and sometimes the only thing that works, and it is worth understanding why that tension exists.
Software is supposed to talk to other software through an API — a proper, documented connection designed for the purpose. When one exists, we use it, every time. It is faster, it does not break when someone redesigns a page, and it tells you clearly when something has gone wrong.
The problem is that a great deal of the software Malaysian SMEs depend on has no API. Accounting packages from the 2000s. Supplier portals built for humans. Government submission sites. That industry-specific tool nobody has updated in a decade. The vendor is not going to build you an API, and replacing the system costs more than the problem is worth.
So the remaining option is to drive the screen: a program that opens the browser, logs in, clicks, types and reads exactly as a person would. It is inelegant and it is often the difference between forty minutes of daily copying and none.
Building one that does not break constantly
The reputation RPA has for fragility is deserved when it is built carelessly, and largely avoidable when it is not.
The fragile way is to record a person's clicks and replay the screen positions. That works until any layout shifts by a few pixels — a longer product name, a new banner, a different screen size — and then it silently clicks the wrong thing. Recorded macros are why people think RPA does not work.
The durable way is to anchor to things that have meaning rather than position: the field labelled "Username", the button whose text is "Export", the table cell in the column headed "Quantity". These survive redesigns far better, because the words on a page change much less often than its layout.
Then it needs to check its own work. Did the page actually load? Is the downloaded file a plausible size? Does the total roughly match yesterday's? A robot that stops and emails you is a minor inconvenience. One that fails silently and feeds you empty data for a fortnight is a genuine problem, and the difference between the two is entirely in how carefully it was built.
Where this goes wrong
Some sites prohibit automated access in their terms, and banking portals in particular take it seriously. We check before building, and we will tell you if something looks like it crosses a line rather than quietly doing it.
If there is a documented connection, driving the screen instead is slower and far more fragile for no benefit. Worth asking the vendor once more before assuming there is none.
This is the one item on the site that genuinely needs ongoing attention. Expect a small touch once or twice a year per portal, and treat anyone who promises otherwise with suspicion.
How we actually build it
-
01
We watch someone do it once
Every click, every field, including the bits they do without thinking.
-
02
We script exactly that
Anchored to stable things on the page rather than pixel positions, so a small layout change does not break it.
-
03
We add checks
Did the page load? Did the number look sane? Did the save actually save? A robot that fails loudly is far better than one that fails quietly.
-
04
We schedule and monitor it
It runs on its own and emails you if the site changed under it.
- The system has no API and the vendor will not build one
- Someone logs into a portal every day to copy the same numbers out
- A supplier or bank site has to be checked on a schedule
- A proper API exists — always use it, it is faster and far less fragile
- The screen layout changes often; the robot breaks whenever the page moves
- It needs a login you are not permitted to automate. Check the terms first
- A login the automation is permitted to use
- Confirmation that automating it does not breach the site's terms
- A person to call when a source system changes
1–2 weeks per portal. Budget a little ongoing time for maintenance — this is the one that needs it.
What people ask about this
Is this allowed?
Usually, for your own accounts and your own data — but check the terms of any third-party site first. We will raise it if something looks like it crosses a line rather than build it quietly.
What happens when the website changes?
It breaks, and it tells you. That is why we build the checks. Expect a small maintenance touch once or twice a year per portal.
Often paired with
Would this work for you?
The first call is free, and we will say plainly if this is the wrong tool for your problem.
Book a free call