Introducing the future of workforce management: Rippling Unity

Or create a cross-system workflow to notify engineering via Slack that an engineer can’t resolve a high-priority ticket in JIRA because they are out on PTO.

If you're familiar with Zapier or IFTT, Workflow Automator is like those products, in that you can write out logic in the form of "if this arbitrary set of conditions becomes true, then do this thing." 

Actions can include alerts, tasks, Slack notifications, approval requirements, and more, and the conditions can really be any conceivable logical condition based on data in Rippling or in a third-party system you've connected up to Rippling.

But, Workflow Automator is supercharged because it's built on top of Rippling’s employee graph:

• Workflow Automator has a built-in understanding of cross-system identity, which means you can set up a workflow where the "action" in a workflow targets the same employee that was the subject of the trigger, but in a completely different business system.As one example, you can set up a workflow in Rippling so that when a pull request fails in your CI system, it notifies the engineer that raised that pull request, and their manager, in Slack. That seems obviously useful—but it's hard to build outside of Rippling because GitHub and Slack have incompatible identity systems, so it's hard to figure out that the handle "CodeGuy37" in GitHub is actually "jsmith@rippling.com" in Slack. But this is trivial in Rippling, because we already map identities in all these different systems back to specific employees in Rippling.

• Workflow Automator has a built-in understanding of the data model of a company. It understands that you have employees, pay runs, computer devices, timecards, departments, work locations, and it understands how these things relate to one another, and you can take that understanding for granted when you're building workflows in Rippling.

• Workflow Automator also understands all the dimensional values for your specific company—it knows what departments you have, where your work locations are and which ones are in the United States and which ones are abroad, what employment types you use, what the levels and teams in your company are, and all of this understanding can be built into the workflow logic you set up in Rippling.

Read more about Workflow Automator here.

Unified Analytics

As part of Unity, we are launching an analytics suite that has been re-built from the ground up to support analysis of very large datasets, with arbitrary joins and data transformations across multiple different datasets and even business systems.

This all starts, of course, with Rippling’s employee graph. You can use the employee graph to identify data you want to add to a report or analysis—which can include any data in Rippling, but also data from third-party business systems like Greenhouse, Zendesk, Github, Jira, Salesforce, Google Workspace, and more. That way, you can easily create a report with data that originates in multiple different datasets or even business systems. 

For example, many companies pay their employees referral bonuses when they hire candidates that they referred to recruiting. Normally, you have to export data from multiple systems—like Greenhouse or Lever and your HRIS—into Excel to figure out who to pay, how much to pay, and if they’re eligible for a referral bonus.

But with Rippling, you can view, add, and report on all of that data in one place.  

Supergroups in Rippling eliminates all of this, because it lets you write out complex business logic—including using logical expressions written in RQL—for which employees should be included in a group, policy, configuration, license type, and more in each of your business systems.

These group memberships can then be used to control different HR, IT, and Finance policies like:

• Systems access in third-party business systems outside of Rippling—for example, engineers with more than 6 months of tenure, above a level 6, and with an active hardware security key on their account should get administrative access to AWS.

• Which employees should be added to a particular email list or Slack channel—for example, everyone who is a manager, and in the sales department, should be on the "salesmanagers@rippling.com" email list.

• Spending limits on corporate cards—for example, employees at the VP level should have one set of spending policies that apply to them, and below that level, a different set of policies apply.

• Membership in PTO policies—for example, full-time employees in India get one holiday policy, employees in work locations in the United States get a different holiday policy.

• Keycard access to your office—for example, only employees who have been fully vaccinated for COVID should get keycard access to your office.