Introducing the future of workforce management: Rippling Unity

This is, of course, a homage to the concept of a "Social Graph" popularized by social networks 15 years ago. Instead of navigating from one person to another based on social relationships, in Rippling’s employee graph, you can start with support tickets from Zendesk, navigate to the employee responding to those support requests, from there move to that employee's most recent timecard and the number of hours they worked during the pay period in which they responded to those support tickets, from there to the person that signed off on the overtime they worked, and so on and so forth.

Unity sits on top of and taps into this employee graph to give Rippling customers, third-party developers, and our own internal product development teams powerful new capabilities.

The Unity launch includes five separate products that are built on top of this employee graph.

Workflow Automator

Workflow Automator is a "no-code" system that lets you create custom triggers which then kick off automated system actions in Rippling and in third-party apps connected to Rippling.

For example, you can create a workflow to automatically detect and notify HR of potential pay inequity via email or Slack.

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.  

And because Rippling understands your org and who your employees are across every system, it can automatically figure out who is eligible for a bonus and how much to pay them. 

You might also want to create a report with shift-level data such as hours worked, and shift date, from your time-tracking system, and then add information about the insurance plans each employee is enrolled in from your benefits administration system, and then data about company contributions to those insurance plan premiums from your payroll system. 

Why would you want to look at this data together? Well, it turns out that is the information you would need, for example, to calculate your company's liability for Healthy San Francisco taxes, an annual rite of passage for many finance teams that is challenging to calculate precisely because it requires data from so many different and—before Unity—disconnected systems.

That data—daily shift data from time tracking, insurance enrollment, and payroll—come from three very different systems and the data is at three very different levels of resolution—at the daily level for shifts, the pay-period level for employer contributions, and at the employee level for benefits enrollment status. But, as a user, you don't have to worry about that. Rippling seamlessly handles the data transformations and joins between these datasets to produce the report you're looking for, and does it in seconds even across surprisingly large datasets.

Before Unity, a company that wanted to report on these different datasets together would have to build out a complex data and analytics pipeline, incorporating ETL / ELT tools like Fivetran for data transformations, a data warehouse like Snowflake, and Analytics / BI tools such as Tableau. But Rippling condenses all of that, by standardizing all the data transformations and joins around the employee and the employee graph.

The net result is that if you can install Candy Crush on your phone, you can install third-party apps in Rippling—and once you do that, you can report on data from those apps just by selecting the fields you want from the employee graph.

RQL and Formula Fields

As part of Unity, we are launching a scripting language inside of Rippling called RQL, which you can use to create Formula Fields inside of our analytics suite, and extend functionality elsewhere across Rippling.

Any advanced Excel user will be familiar with RQL's syntax—it borrows many core concepts and syntax from Excel. But, we've also incorporated some powerful capabilities from SQL such as "select" statements, as well as some elements from Python such as advanced support for lists.

If you download data from your HRIS system, and then analyze it in Excel or a third party analytics suite like Tableau, you might find that unnecessary going forward, because you can set up the same analysis and Formula Fields directly inside of a Rippling report.

What's more, you can use RQL to create persistent Formula Fields that show up everywhere across Rippling. For example, I have created a new formula field that shows up on timecards for hourly employees in Rippling, which shows a simple ratio of the number of Zendesk tickets an employee closed out during a pay period, divided by the number of hours they worked in that pay period. 

It's a rough measure of efficiency—but one that's impossible to create inside of Zendesk, which doesn't know how many hours an employee has worked or what pay schedule an employee is on. But, when you join Zendesk tickets into the employee graph, it's also joined to other systems that are connected to that graph, such as your time tracking system—and once you have set up this unified schema, it's easy to calculate and analyze data across multiple business systems.

Supergroups

Supergroups let you apply policies, membership, and configuration to any business system (within or outside of Rippling) from one place.

Part of the daily drudgery of managing point SaaS products is configuring employees’ access within those systems. You might need to add employees to email lists in Google Workspace and to the right channels in Slack. You’ll need to set up the right “license types” for employees in Salesforce, Zoom, and Zendesk. You’ll add employees to the right spending policies in your corporate card or spend management system, the right PTO policies in your PTO system. And, you’ll manage group memberships, configuration, and access across dozens of other systems.

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.

Role-based Permissions and Approvals

Unity lets you set up role-based permissions and relationship-based approval requirements, which are then honored across Rippling.

For example, I have set up our own company so that any manager at level 7 and above should be an admin in Rippling for their direct reports. If someone is promoted to that level within the org, they will automatically inherit these permissions for their direct reports. If reporting structures change, all permissions will adjust accordingly.

Instead of having to configure administrative permissions one person at a time, I can set up rules for who should be able to do what within the system using Supergroups, and Rippling will automatically make sure everyone has the right access going forward.

And, these permissions apply everywhere in Rippling—these admins can build their own reports and analytics, set up their own workflows, and create RQL expressions based on the employees and data fields they have access to in Rippling.

Further, you can set up approval requirements for any changes these admins make, based on relationships between employees across Rippling’s employee graph—for example, I have specified that any changes in Rippling need to be approved first by a director above this manager in the org chart, then the executive team member above that person, and then finally by me, before taking effect.

You can even configure approval requirements based on any data in Rippling’s employee graph and any custom logic you want to apply to it—for example, you can say that any increase in annual salary by more than 20% requires additional approval from finance before it takes effect.

Learn more about role-based permissions and approvals here.

What Unity means for the future of workforce management

These five Unity products share some common themes.

First, they are all built on top of Rippling’s employee graph.

Second, they use this employee graph to join together—to unite—data across multiple business systems, and allow you to act on, analyze, and manage these different point-SaaS systems in a single place.

Third, these products are all highly configurable—in fact, we think of them internally less as specific features in their own right, and more as “frameworks” that allow you to build your own functionality inside of Rippling, without code, to match our system to your company’s own bespoke needs.

And fourth, role-based permissions are embedded in the fabric of each of these products, so that these capabilities can be distributed broadly across your organization. Every manager in your company can create reports, build out workflows, use Supergroups and write out RQL expressions.

Beyond that, we view each of these products as "platform capabilities"—they are useful products on their own, but they are also capabilities that will be embedded into every future Rippling product going forward.

This is the promise of Unity: A single employee system and source of truth that can be activated for nearly any task with any connected tool. What we’re launching today is the foundation, and there’s a lot more to come.