The code behind Rippling’s no-code workflow automation tools

For those engineers who work in a larger organization with a separate HR department or where managers handle HR tasks, allow me to illustrate the behind-the-scenes process of doing something as simple as changing an employee’s address.

Step 1: An employee changes their address

Step 2: An HR representative sees the change, sighs, and bangs their head against a desk

Step 3: They proceed to change the employee’s address in all of the relevant business systems and send out emails across the company to all stakeholders in order to comply with policies or change stuff in other systems

The exact process may vary, but imagine how many thousands of hours are wasted across your organization for simple changes like these. And that is assuming everything goes as planned—what happens when no one sees the change or someone misses one of those other emails?

“Why isn’t all this automated?” you ask; great question!

You can probably guess where I am going with this: We’ve built a product at Rippling to eliminate the busy work of administering a company while being customizable enough to adapt to the many permutations of systems and policies seen across organizations.

With Workflow Automator, organizations can, for example:

• Configure a Slack message to be sent to a manager who attempts to hire someone into the engineering department with a salary below a certain threshold

• Send a reminder via email to an engineer with more than 5 open pull requests

There are countless possibilities, and you can read more about Workflow Automator here, but today, we’re going to be taking a look at one of the underlying systems that makes this a reality. Several major in-house technologies, including our new scripting language, went into building Workflow Automator; here we’ll be highlighting the workflow engine that glues everything together.

First, we’ll define what a workflow is, and then we’ll take a look at what the workflow engine actually does and some goals it sought to address before wrapping up with a brief discussion on its implementation.

So, good news, a workflow is pretty much what you are thinking of right now. It is a series of events that needs to be run as a result of some launch trigger, whether that be some new data point matching a query or someone clicking a “start” button on a webpage. In the context of Workflow Automator, it is the former—something like “if an employee’s salary changes to above $60,000, send an email to the finance department”. In the most general case, a workflow is an “if, then” series of events, and the workflow engine is a framework that 1) monitors the state of the if condition and 2) manages the execution of any follow up events while facilitating the transfer of data between these events.

There are two types of events in a workflow:

• Trigger: an event that launches a workflow

• Action: an operation that is performed after a trigger fires (the canonical workflow step)

In most cases, the sequence and dependency tree of events is formatted as a directed acyclic graph (DAG). I say most cases as you can nest workflows, which breaks the traditional definition, but that is an implementation detail beyond the scope of this discussion.

There is something important that we have failed to mention here—something that derives from the fact that actions have dynamic dependencies. For example, if you want to send a Slack message, you need to know where to send it, and to make this workflow even half useful, that recipient is probably related to something in the trigger. So at runtime, you need to be able to pass data through this DAG.