Argh, my process can’t be automated!

In some instances when the process is broken, incorporates large quantities of unreadable and unstructured data or simply doesn’t return an acceptable ROI, perhaps the right thing to do is to politely decline the opportunity to automate. It simply isn’t worth it.

But what do you do when you are asked to build an automation and something technical is preventing you from doing so? Do you give up or try to find another solution?

A developer with a good understanding of technology beyond the core RPA tool is more likely to overcome technical barriers and find solutions to problems.

Here is an example that I worked on recently which may also be helpful to my readers.

In UK healthcare we use applications called Patient Portals to communicate with patients for all sorts of reasons such as confirming outpatient attendance, booking and rescheduling appointments, sending letters or gathering data via online or SMS text message based surveys.

Some of these solutions offer direct integration to back-end clinics systems through HL7 interfaces or via APIs but where that functionality does not exist, we have to rely on humans to perform the back-end transactions which wastes time and slows down responses to patients.

A few weeks ago i needed to write a simple automation that logged into a patient portal, downloaded the responses from an online patient survey and passed this data over to the informatics team for ingestion into a reporting tool.

The portal has a traditional web browser based login page requesting email address and password but then uses two factor authentication (2FA) by sending a unique six-digit pin code to a designated mobile phone number. Remember our robots don’t have any hands so here is the first barrier to my automation.

Thinking it an easy solution to ask the supplier to remove two-factor authentication to our designated robot account - I thought wrong.

“No we can’t change it!”

Not the unhelpful response I expected.

Still undeterred a good colleague of mine did some research and found an SMS to email provider who were so helpful and within minutes I was receiving authentication codes into my mailbox.

Writing some code to read the incoming SMS email and extract the six-digit code was simple enough. With the constant desire to write efficient code, the incoming SMS to email message arrived from the portal within a few seconds or within a few minutes so if the bot moved on too soon the code would be missing and I would get a system exception or too slow, then the code may expire or the process run longer than needed.

So what did I do?

I created a simple loop that checks for an incoming code every 10 seconds and tries for a maximum of 10 minutes before raising a system exception.

Unexpected Surprises

The next challenge with automations are the unexpected surprises along the way and the additional automation steps required because the application doesn’t perform in the way you need it to.

In this example, the downloaded data contained ALL the historical patient responses and not just those from the previous day. Using the excel VBO I was able to filter out yesterdays patient responses for passing onto the informatics team.

What is the point of this post?

If an automation appears impossible to do, don’t be afraid to explore others technical solutions to achieve your goals.

If the process isn’t quite where you want it to be, use RPA to take you to your happy place.

I will update this post later this week with a video demo (when the mobile signal in South Wales allows me to!)

Happy Automating!