The Basics and Best Practices of Building RPA Flows

By this point, it should be clear that robotic process automation is going nowhere — and with good reason. The benefits of accuracy, compliance, and low technical barriers are pretty enticing to users. But what does that mean for companies and developers working on RPA? Maybe you're seeing more RPA-related tasks slipping into your sprints, or maybe you're just looking for a change of scenery in your job and want to sink your teeth into RPA.

Well, with that in mind, I reached out to the UiPath's community to get a community member's perspective on RPA. In this post, we'll focus on the basics, best practices, and limitations of RPA flows. In another article, we'll examine how the RPA landscape is changing.

(By the way, this is going to be a useful, but higher-level look at RPA. If you're looking for more of a tutorial, check out our Refcard Getting Started With Robotic Process Automation.)

The Key Components of an RPA Flow

According to a UiPath community member and executive RPA lead, there are four basic stages of RPA flows.

• Initiation: Initialize the process by capturing configuration data and preparing the work environment. You do that by starting up and prepping the applications you need in order to process the relevant data.
• Obtain processing data: Well, you've started up the apps you need to process said data, so now it's time to actually get the transactional data you need to complete the flow.
• Process the data: You've gone through the trouble of initializing the apps you need and gathering the data. So, the next step is to actually process the data.
• Closing/ending the flow: Time to clean up after yourself — clean up the environment, close the apps you used, and make sure everything is ready to run again good as new.

Best Practices for Building RPA Flows

Now onto the good stuff. You know what goes into a solid workflow, but how do you build a good one? Here's what the UiPath community member and executive RPA lead recommends.

• Use good exception handling and retry mechanisms: You need to make your robot reliable, so implementing a good system for when things go wrong is key.
• Break down the workflow into multiple parts: Using multiple workflows helps maintain your code, makes troubleshooting easier, and is much easier for your colleagues to work with once you've gone off to create your own automation startup and left them behind.
• Always include comments and annotations: In the same vein, make sure you clearly mark your code. Obviously, you want to make your code readable, but there's no harm in adding a bit of extra clarity.
• Don't use nested IF conditions beyond two levels: Keep things as simple as humanly possible for your robot. And if, for some reason, you do need to use more than two nested IFs, make sure you make up a flowchart for added clarity and readability.
• Don't start development right after gathering your requirements: Sit down and actually analyze the process. Draw technical diagrams to get a top-down view of what your solution will look like and how everything links together. Granted, this is more of a solution architect's job, but it's important to know how to do this as a developer.

Mistakes Devs Make (and How to Avoid Them) When Building RPA Flows

You know the basics and best practices of building an RPA flow, but what about when things go wrong? It's easy to make mistakes when making a routine, and here are some classic ones the UiPath community have seen. But it's not enough to just know something is a bad practice — they also helpfully offered some advice to fix the problems as well.

•  Trying to develop everything in a single flow: Were... Were you not paying attention earlier? Trying to roll everything together leads to a lot of problems, including running the risk of losing track of what's happening. And, of course, making a small change in a big system can have a big knock-on effect, so you need to put extra effort in to make sure your big flow doesn't break. Know how your solution is designed, how components link together, and break it into smaller processes/workflows.
• Trying to develop before fully understanding the process: Don't do it. If everything goes right, then great, you've saved a bit of time and effort, and that might be fine for simple routines. But for more complex flows, you can't plan in advance for every scenario that might crop up for users. Uncovering something you didn't plan for might lead to major changes to the code you've built, and if you don't inherently understand the process, then you have to reverse engineer it before you can change it. Do it right from the beginning: Plan before you code.

The Limitations of RPA

As RPA becomes more closely aligned and combined with AI, NLP, ML, and similar technologies, it only becomes more useful. But when you only work with hammers, everything starts to look like a nail. 

"RPA isn't the solution to all problems," according to the UiPath community member. Applying a flow to a broken or inefficient process isn't going to be super helpful. "The first step is to ensure such processes are standardized and reassessed for the need for automation."

Defining Done With RPA

And lastly, something near and dear to any Agile guru's heart, let's define "done." To make sure your Ops team still wants to be friends with you, we'll look at it from a testing/user point of view. Obviously, you're going to want to set up monitoring, logging, data handover mechanisms for your transactions. Given that you've read the best practices (right?) and set up solid exception handling and retry mechanisms, you'll track each data item throughout the flow. 

"If an item fails to achieve successful completion, the same thing is retried multiple times automatically," the UiPath team said. "Either way, once the robot completes all the items successfully (without any application-related exceptions), we define the status "'done.'"

Conclusion

So there you have it. You should now have a solid understanding of what goes into a good RPA flow, some best practices for building them, mistakes to avoid, when not to use RPA at all, and how to know when you're finished. With that in mind, up next, we'll take a closer look at the current state of RPA development, what's on the horizon, and how to address concerns users might have.