Retool Workflows: 4 Proven Use Cases from the Akveo Team

Looking to simplify your business processes and automate daily tasks? We do understand – nowadays that is a hassle. Thankfully, there is a ready-to-go solution, Retool Workflows.

In this article, we will dive into the power of Retool Workflows, showcasing how they can not only interconnect different systems but also boost your overall business process efficiency. You will discover four proven workflow solutions built by Akveo, outlined by our low-code expert. Dmitry Sitnik will guide you through them providing practical insights and real-life examples, and showing how you can use these low-code solutions for your projects.

What are workflows?

If you haven’t dove deep into the Retool Universe yet, you might be curious what a workflow is. The Cambridge Dictionary says that a workflow is the way that a particular type of work is organized, or the order of the stages in a particular work process. Funny enough, as an example of how to use this word, the following sentence is provided: ‘The right software tools can improve workflow and productivity’. In my opinion, Retool is ‘that right software’, both literally and figuratively.

Retool Workflows are a powerful visual tool for creating business process automation, that is complemented by the things we all love low-code solutions for, countless built-in connectors for the commonly used services, APIs, and databases, and the flexibility of custom code – both JavaScript and Python.

In other words, you can draw the actual information flow, connecting the data from one business system to another, enriching, processing, or converting it along the way.

How to use Retool workflows – and when?

The example that we have just discussed might look a bit dull and generic – no fun at all! Yes, workflows are generally tailored to provide a robust unattended interconnection between different systems, but let’s think outside the box! Here are some examples of how we at Akveo use workflows to facilitate (un)common clients’ requests: building a simple API, improving application security, processing scheduled data changes, and handling time- and power-consuming tasks in the background. Now sounds funnier? Let’s see!

Case 1. Building a Simple API with Workflows

I bet that a lot of people starting working with workflows are concentrated on how to get data from external sources and then send them back or further. But what if we need not only to get the data but to be ready to receive it from other systems; or to extract some data from a Retool App to use in an external app, without exposing the underlying data source?

Here’s the answer: alongside a cron-like schedule, workflows can be triggered by webhooks, carrying some payload with them. This data can be operated on – processed, read and written, sent. The external service that triggers our workflow will receive a standard HTTP response – you decide, which and how.

A real-life example. We’ve built a billing system for a company that provides educational services for tons of schools across North America. Invoices are generated inside a Retool App, while payments are processed by Stripe. We use webhooks on this project to get the data from Stripe if a particular invoice was paid to close the business operation and mark the deal as finished.

Case 2. Generating Complex Emails Automatically

Let’s continue discussing the previous setup. Just imagine: you create an application for sales or account managers, with a lot of financial and other sensitive data. At some point, a user of your app decides to send a quote or invoice email to a client. This simple action requires a lot of underlying operations: we need to check, if this client has any unpaid invoices, then create a Stripe invoice to process a future payment, then generate a printable PDF, attach it to the email, send it out – and finally change the deal status to ‘Invoice sent’.

We can do this on the app side. But we really shouldn’t. First, such operations will block the app for a while – depending on the number of external services and integrations. People don’t like to wait. Second, we cannot guarantee data integrity – are we sure that the user won’t close the app or even their laptop lid somewhere in the middle of the operation? People still are… just people.

These are two main reasons why we decided to move this complex operation queue to a workflow. A billing user just presses the button ‘Send’ – the app triggers a workflow that performs all the manipulations in the background. Safe and user-friendly!

Case 3. Processing Scheduled Changes

Sometimes we need to divide by time the moment when a user requests a data change and the moment when this change actually happens. Just imagine, you work in HR. After a performance review of an employee, you get information that his or her salary should be, let’s say, doubled starting next month, let it be January. What will you do? Will you take a note on your phone not to forget to log into the HR software on January 1 and actually change the numbers? Or you can just schedule this change. In this case, a record in the new status just sits and waits for its time – when the time comes, a workflow takes this record and puts it in the data table. Voila!

We use this approach on a huge project for an international company with 10,000+ employees in dozens of countries. The company needs all the operations to be SOX-compliant in addition to the four-eyes operational principle, which means that another person should approve changes before they go live. To achieve this, we never alter data directly from the apps, and store change requests as JSONs. They are put into the actual data tables only when approved and when the desired effective date comes. Yes: this work is done by workflows.

Case 4. Improving App Security

You may have noticed that in the previous example, I mentioned that we never alter data directly from the application. Well, that’s not true: we still need some minor changes to be performed on the app side. But if we speak about sensitive things like creating a request to double someone’s salary, it might not be reasonable to have all the reins of power on the user's side.

Remember, we build web applications, their runtime data can be manipulated. That’s the hard truth: while a web application can run literally on a fridge, it is exposed to vulnerabilities because of this flexibility. That’s why sometimes we need a bit more precautions. For example, instead of writing data directly to a table, you can create a workflow that receives the data from an application, checks it, verifies current user permissions, and only after writes to the database.

This is what we do in the HR suite for That Big Customer. Each change request is packed into a JSON with additional metadata, and then a workflow with this payload is triggered. The workflow checks the input data, calculates the approval level needed, and then creates a record for approval.

Instead of conclusion

As you can see, workflows are not just work and not just flows. I’ve written this dad joke to demonstrate how weak my sense of humor is compared to such a powerful feature as Retool Workflows.  Even on the basic plan, you can have 500 runs a month. That’s enough to start experimenting!

Dmitry is the Head of Low-Code Department at Akveo. With a rich background in media and marketing, Dmitry brings an extraordinary look at the world of IT technologies. He is deeply passionate about finding the most effective and elegant solutions to complex client problems. In our blog articles, Dmitry will share his expertise in Retool and other low-code platforms to offer you valuable insights on Retool to enhance business process efficiency.