The core UIPath product: automating manual stuff
The main value proposition of UIPath – and their core product – is the ability to record your manual tasks, save them as a process, and replay them whenever you want, instantly. Here’s their app for recording tasks (UIPath Studio):
You can read a basic tutorial on how to do recordings here. And beyond recording, you can also build workflows visually by choosing available apps and options and chaining them together on certain conditions.
UIPath also lets you do other important stuff, like automatically filling out forms, using business logic like loops and conditions, and working with external data like APIs.
How automation generally works
Automation is the buzziest of buzzwords, so it’s worth getting into what it actually means, and more importantly, how people (developers?) tend to make it happen.
Software (well, most software) is built on top of APIs. There’s a nice user interface with buttons and fields and text, but every time you actually do something (load a page, submit a form, move things around), there’s probably a server involved, and your app is interacting with it via APIs.
(Stolen from the original What’s an API post)
Companies design their user interfaces around what problems they think they’re solving, and what they think their users want to do. When Google designed Gmail, they figured that people would usually want to send emails, adjust their settings, and search their inbox – and so that’s what the Gmail app lets you do.
But the APIs that power the Gmail app are much more robust than that – developers tend to design them very granularly, and they can be more powerful than what the Gmail UI lets you do with them. The Gmail UI, for example, doesn’t really let you mail merge (send the same email to multiple people and templatize content) – but the APIs that power Gmail can do it very easily. The problem is just that you’re limited to interacting with those APIs via the Gmail user interface.
With that distinction in mind, automation is usually just interacting with APIs directly. If there’s a Gmail API that sends an email to an intended recipient, you could just write a simple Python script that hits that API in a loop until all email addresses in a list have an email sent to them. The key is just being able to write code (lol), since APIs are programmatic interfaces, and as such, they require programming.
The problem with API-first automation is that not every app gives you access to the APIs that you need! That can manifest in two different ways:
- The app doesn’t give you access to its APIs – this is more common than not, and happens for many legitimate reasons (e.g. they’re not secure enough).
- The app doesn’t really work via APIs – apps like Excel build most of the application logic into the frontend itself, so there are few or no APIs so speak of.
So if you’re working in Excel, moving files around on your Mac, or filling out a document, how do you automate that?
While companies may not expose their APIs for general use, you can often and . You won’t know much about how they’ll behave and won’t have documentation to read, but it’s worth noting that some developers do this anyway.
