Kapow vs. UiPath, Part I: Foundation and Robot Design


It’s hard to ignore the hype about Robotic Process Automation (RPA), so please reserve me a seat on the bandwagon: this is the first part of a series where I will take a closer look at two RPA solutions: Kofax Kapow and UiPath Community Edition. I am going to cover certain aspects of both products, such as the general foundation and technology behind them, the process of building, deploying and running new robots, and most important for some of you – their capabilities regarding typical RPA requirements such as web or desktop automation.

Can they live up to their promises? And even more important, which tool is more up to the task? Spoiler alert: if all you have is a hammer, everything looks just like a nail. Both UiPath and Kapow are formidable solutions, with the former one being the rising star according to Everest Group’s 2018 RPA PEAK Matrix and impressive Desktop Automation capabilities, and Kapow having a long history in and a wide variety of features specifically designed for Web Automation.

So, here’s my table of contents for the upcoming weeks. I’ll try to release one article per week, some may take longer or shorter than expected. This TOC is subject to change, and if you think that there’s something missing, just let me know.

  • Part I: Foundation and Robot Design
  • Part II: Web Automation
  • Part III: Desktop and Citrix Automation
  • Part IV: Working with Files
  • Part V: Integration: Web Services and Emails
  • Part VI: Scheduling and Managing Robots

Each part will consist of a short introduction of the methodology used to compare both products, (hopefully many) hard facts, and of course, there’ll be a winner (it’s my Blog in the end, so my opinion). Please note that I’m more interested in providing a broad overview of all features relevant to RPA, so there is little depth in each section (I could talk about PDF automation alone for quite some time). If you disagree, find a mistake, or have something else to contribute, please get in touch with me – I’m looking forward to sharing your experiences.

This article has been updated for the following versions:

  • UiPath 2018.1.3 Community Edition
  • Kapow


Let’s look at the very foundation first:

  • Kapow: if the Design Studio reminds you of the Eclipse IDE, then you’re right: it’s built upon the JDT, and just reading through the third party licenses gives you a very good idea of its foundation: the basis is Java and several Apache products. In fact, Kapow can run on Apache Tomcat, uses Velocity templating, an Apache Derby DB for development, and so on.
  • UiPath: Windows Workflow (WF) foundation is the very basis here. UiPath lives and breathes .NET, making it very easy to understand and extend it if you already are familiar with either WF or VB.NET.

There are some limitations here: UiPath will naturally only run on Windows machines, while Kapow could also run on Linux or macOS. However, since the Desktop Automation part of Kofax also requires a Windows client, it’s impossible to proclaim a “winner” in this regard. There are two different flavours, and I’m not willing to start a religious war between Java and .NET fans.

Design Studio versus UiStudio


This is where you start building your robots. Please note that whenever I refer to a Robot, what I essentially mean is a process that is being automated, but not the machine itself that then will execute this process. I know some (other) vendors use this word synonymously for an individual computer, so let’s get this out of the way.

Here’s an overview of both Studios (left: Kapow, right: UiPath).

Both programs are well designed and allow access to all actions you will ever need. I like the way how Kapow includes a (headless) browser, exposing the DOM directly in studio – while UiPath relies on the UiExplorer with external programs such as the Internet Explorer or other browsers for web automation. On the other hand, there are features in UiPath that I want to see in Kapow, too: searching through all available actions, for example. It’s a small thing, but it can save you a lot of time in the long run. Plus, I like how UiPath automatically makes screenshots for you, tying them to the actions wherever possible – that will help anyone to understand what is going on in a specific step.

The most striking difference is the way the robot is being presented: Kapow goes for a vertical approach, while UiPath depicts them horizontally, just like a waterfall. Here’s another significant difference that’s not too obvious, posing a pitfall for many starters: while UiPath’s robots can be seen as true flowcharts or sequences, a Kapow robot essentially is a binary tree.

Conclusion & Verdict

I like working with both Studios, and I find myself missing features in Design Studio that are there in UiStudio, and the other way around. There isn’t any loser here – I call it a draw.


Your robots will have to store data. Be it just temporary or for a long time – here’s where variables come into play. Both Kapow and UiPath offer a wide variety of types: you can store strings for text, integers, longs, and more.

Kapow has the ability to create internal types that you can reuse in different robots.  This is quite handy for abstract entities, for example an Account Type as depicted below:

Also, there’s the unique ability to directly store types in a database table and retrieving them with a simple action. Kapow can even create the tables and pick the most relevant column data types for you. There are some special types in Kapow that are to be used for certain file formats, representing not only the binary file, but also its very structure: Excel, PDF, JSON, XML. Not only can they be stored, but also viewed and manipulated: right out of Design Studio, in the embedded viewer.

Each robot then most likely has some variables assigned to it, and each variable can reuse a custom type, for example our Detailed Account from above. There’s also the ability to declare variables as Input – in which case they will be exposed automatically to the so-called synthetic API, but more about that later. One confusing thing for beginners: the Global flag means that a variable’s value isn’t lost when in iterations (loops). But again, there’s more about Control Structures to come.

UiPath’s approach to variables is a bit different. While there’s no type that you can create, variables are always tied to certain elements, a sequence for example. This helps you structure your robot and keeping it lean by tying variables to the scope in which they are needed. While this may be confusing for starters, I really like the concept and the way UiPath makes sure you cannot access a variable defined outside of the current scope. You can even achive something similar then in Kapow: defining a type and reusing it over different robots. Just create a skeleton structure, e.g. an empty sequence, and paste it over to any other Sequence or Flow Chart.

There are, however, two things that set UiPath apart from Kapow: one is its ability to store collections such as Lists and Arrays and the DataTable type, which is perfect for storing 2-dimensional data, i.e. a table with x columns and y rows. Even more impressive is the other feature: you can just use any .NET type, either being part of the .NET core or part of your custom libraries. Take a look at the screenshot above – I am using a SecureString for storing the password, a .NET class that is part of the System.Security namespace.

In addition, UiPath supports a data type called GenericValue –  nice for beginners since it can hold anything and automatically decides upon the required type during runtime (boolean, strings, integers). I don’t like it too much since I’m a fan of strictly typed languages, but as said – it’s great for anyone just trying to build their first robots.

Conclusion & Verdict

This is a tough one – I really want to have the best of both worlds. Specific variables for file types such as Excel, JSON and PDF are fantastic because Kapow interacts natively with them – there’s a GUI for browsing, manipulating, iterating – you name it. The concept of custom reusable types is great, too. Still, UiPath offers such a wide variety of options simply because you can include any .NET type, including custom ones. And since this includes Collections which Kapow does not, I will call this a very narrow victory for UiPath.

Control Structures

Before we dive into control structures, let’s remember the pitfall of workflows versus binary trees I mentioned earlier. While a workflow such as a flowchart has always a very clear sequence, binary tree traversal can be a little bit tricky to understand. In fact, let’s use a simple if-then to explain one fundamental difference between Kapow and UiPath. We want set a Assign 10 to a variable, and then check its value in i==10? (in which case we’ll output true, false otherwise). At the end, we will always output finished:

In UiPath, even absolute beginners who never heard of control structures can immediately pick up what’s going on just by looking at the workflow.

It’s a whole different story in Kapow. A binary tree is being traversed from the beginning to the end – and you can see three end nodes here (the tiny circles with the x inside them). Whenever such an end is reached, the next branch is traversed. After all branches have been visited, the traversal ends – technically not at the last end node, but at the very start of the tree. Without keeping that in mind someone might easily think that i = 10 and Write finished are executed in parallel – yet, that is not the case. The branch with Write finished will be executed once the upper branch was fully executed its end has been reached. It gets even more confusing with the optional branch and the Write false node: this one is only executed when the i==10? action throws an exception – as indicated by either the small blue arrow, and then by the dashed connection that makes up the optional branch after a try node. One important lesson is to be learned here: Kapow does not provide you with a prepared action for if-then: it is entirely up to you to build that structure out of the the steps, actions, and branches that are at your disposal.

Another control structure is the switch statement. Its objective is to switch between the outcome of an expression. Think of a customer rating for example, ranging from 1 to 5 stars, being expressed as a number – we want to translate it into a textual description. Here’s how UiPath solves this in with a flowswitch (actually, it’s Windows Workflow Foundation):

Again, it’s absolutely clear what will happen, and under which circumstance it will happen. Let’s compare that to Kapow:

Much clearer than the if-then statements this time, mainly thanks to the node names and the arrow indicators which tell us the tree will be traversed back to the diamond, a so-called a try node. Again there is no prepared action for a switch statement: I created it from scratch using a try, test element actions, and error handling.

Lastly, let’s look at loops since iterating over elements is the bread-and-butter in RPA. Repeat one action for each file. Iterate over divs encountered in HTML. There are many different types of loops available in UiPath, such as the Do, Do While, but also For Each – which is incredibly useful if you need to iterate over items in any collection. Here’s how a simple loop looks in UiPath, exiting after a total of 10 iterations:

The same in Kapow, and now there are two specific actions: the Repeat and Next node. Creating the exit condition is entirely up to us, but this also gives us the flexibility of moving it to the very start, essentially turning the loop into a Do (depicted is a Do While).

Conclusion & Verdict

Understanding and building control structures in Kapow can be difficult for beginners, especially when considering global variables, branching, and when potentially nested loops being present at a time. UiPath’s approach is much clearer to grasp, and sometimes even quicker to build. With Kapow I find myself having robots prepared just filled with control structures where I would just copy & paste steps onto a new robot, when I would just drag and drop loops directly UiPath since it’s so easily done. However, the real beel lies within looping over complex elements: UiPath shines with its For Each loop that can work on any type, even custom ones. I like that a lot. However, since control structures in Kapow can be just as powerful and it will take you only a little time to understand binary trees (which is not tied to control structures by itself), I call it a draw here.

Robot Execution

Another difference is the way the robot execution while being designed. After adding an action in Kapow the result can be immediately observed just by clicking on any element beyond it (another one in the same branch, or by clicking on the end node). One could also select just any node, in which case Kapow will execute the robot to that very step. There are different modes at your disposal that will either take the shortest path or fully execute loops, and in general this allows for testing robots at the very same time as you create them – without explicitly switching to Debug Mode.

UiPath offers a Recorders to create the required steps for you that works with anything (Web, Desktop, Citrix). That’s good for beginners and even great for selling the product, yet I’m not particulary fond of recorders – but more about that later. The point here is that as soon as the elements are clicked, the robot is being executed. Well, technically speaking, it’s the other way around – you click, and UiPath just watches, creating actions and selectors for you. Apart from that, the robot is not being executed in UiPath while designing it.

Conclusion & Verdict

UiPath’s recorder is impressive, but then again – this section is just about Robot Execution during design time. Why is that important, you ask? Well, especially when it comes to Web Automation, it is Kapow’s time to shine – it will automatically reset the browser to precisely that step you select, even across different branches. You don’t have that in UiPath, which means you’ll find yourself moving back and forth in the browser a lot. Kapow’s behaviour to execute the robot while you add and click through the actions may require some time getting used to, but it will immediately tell you what is going on in the GUI, and why the selected action cannot be reached. And it’s not just web automation – the same applies to working with PDF, Excel, JSON and XML files. You’re actually debugging the robot while building it, and as this usually saves me a lot of time, Kapow is the clear winner here.

[Updated: over at the LinkedIn group, Thomas pointed out that this view is flawed as retaining state isn’t working in the same way when dealing with Desktop Automation – he is right, there is none (neither in Kapow nor UiPath).]

Robot Debugging

When you can’t wrap your head around why you Robot keeps failing, debugging will be your best friend. The ability to set breakpoints, execute robots step by step, log meaningful messages – it is all there, and that is true for both Kapow and UiPath.

The screenshots above shows both Studios in Debug Mode, with a breakpoint set and hit. UiPath shows both the variable and log at the same time, while Kapow requires you click to another tab to see the current variables. What I miss in either product is the ability to add variables and expressions to a watch window as only predefined variables can be observed, or log messages have to be written by hand.

One feature that really sets Kapow apart is its ability to directly jump from the debugger into design mode, in which case all variables and iterations will be retained. So, if you robot fails to scrape item #61 from Ebay that was on the third page, a single click will immediately take you there allowing you to quickly identify the root cause for the issue. Jumping back into debug mode is just another click.

Conclusion & Verdict

With the exception of watch windows, conditional breakpoints and some more advanced debugging tools, all basic features are at your fingertips: both debuggers are decent. UiPath has a neat feature for Desktop Automation that highlights elements found graphically, but the one feature that makes Kapow the winner here is the ability to easily switch between design and debug mode, retaining the current state of your robot.

[Updated: again, Thomas’ feedback is valid – for Desktop Automation, there is no state retention. So, if you want the majority of your robots interacting with Desktop applications, this would be a draw.]


When this article was written, there were over 150 actions available in Kapow, and over 200 activities in UiPath – and that’s just the core package. But what it this isn’t enough?

Kapow isn’t too flexible in that regard. The closest you get is a Convert using JavaScript, which adds some extensibility – for example, you could sort a list of items there. If the existing actions and any combination of them aren’t precisely what you need, you have to resort to other methods to add functionality. Since I am a fan of Python and Flask I usually create a small web service that provides me with whatever functionality I need – check out this article for an example.

UiPath, on the other hand, is all about extensibility. They encourage you to create your own custom activities, and you can share them as a package. Need to deal with a proprietary file format? Go on, write your custom DLLs in .NET, turn them into actions, sell the package to others – nothing will stop you. Just as impressive is the Invoke method action:

Here, we call the NewGuid method of the Guid structure, assigning it to a variable Guid (of type System.Guid). There’s not a single line of code involved, thanks to Windows Workflow Foundation everything can be done in the GUI – you can even pass in arguments. And if that’s not enough, you can call code that either resides in an external code file, or – for very short statements – directly in the Invoke code action.

There’s not much to say here but: UiPath is the clear winner. The ability to add custom activities, import packages from UiPath and even third parties, and invoking any .NET method gives you maximum flexibility, something that I dearly miss in Kapow.

Conclusion and Outlook

This covers the first part of the Kapow vs. UiPath series. Now you may know a bit more about the general architecture, robot design, and about my specific approach.

  • General: Neutral
  • Variables: UiPath+
  • Control Structures: Neutral
  • Robot Execution: Kapow++
  • Robot Debugging: Kapow+
  • Extensibility: UiPath++

Next week we will be covering Web Automation – so stay tuned.