Introducing role-based permissions: Get complete control over the data and apps that your team can manage

Ensuring you have the right permissions governing data and systems access for your employees is critical to building a secure and high-performing organization. 

But, maintaining those permissions is a hard, and manual, task in most software systems.

You promote each user to admin status, in each system, one at a time. And when someone leaves, or their role changes in a way that requires that their permissions change, you have to make those updates manually as well. 

This gets harder to manage when admin permissions aren’t binary, and require you to specify the scope of someone’s authority. For example, you might be an admin, but only for a certain part of the organization. Or you can make changes, but others need to sign off on them to take effect. 

In systems where “approval” is required—whether it’s for a raise, an expense reimbursement, a new computer, or access to a system—that approval is always implicitly about “role” and each employee’s organizational “relationship” to others in the company. For example, you might need approval from your manager, your HR Business Partner, the VP of your department—but who each of these people are will change and evolve as your role within the company changes.

As your team grows, so does the effort required to maintain these permissions, and it’s inevitable that people won’t have the permissions they’re supposed to have.

That’s why we’re excited to introduce our latest feature: role-based permissions—a new, better way to manage permissions across your company, built on top of Rippling’s game-changing employee graph.

Role-based permissions: a better way to control employee access  

Role-based permissions let you ‘set and forget’ your policies for admin access, approvals, and change management—all from one place. 

You select the criteria that govern:

• which employees get admin access to your systems based on high-level employee attributes (e.g. their department, level, team memberships, location, etc.)

• the subset of the organization their permissions apply to (e.g. only their department or direct reports)

• the types of data they can access and actions they can take (both in Rippling and your integrated business systems)

• when additional approval is required for attempted changes, and from whom (e.g. ‘their HR Business Partner’ or ‘their department’s VP').

For example, you could create a ‘Support Managers’ permission profile that applies only to Support managers Level 6 and above, and lets them access information only for their direct reports. 

From there, Rippling identifies which employees match your criteria, and automatically grants them the right permissions.

Because every manager's LMS results are housed in the Employee Graph, Rippling is able to identify which managers satisfy those conditions, and Rippling assigns those advanced permissions automatically.

And unlike other platforms, Rippling’s role-based permissions extend across the entire Rippling suite (e.g. Payroll and Time & Attendance) as well your third-party integrations (e.g. Jira and Zoom). 

For example, you can allow Sales Managers to manage access to key apps like Gong and Zoom for their direct reports, view their sensitive employment-related information (e.g. compensation), and terminate their employment—all within a single permission profile.  

Take the pain out of permissions management

Setting up admin profiles for new hires, and updating those permissions when responsibilities change, is manual work that takes time away from your more pressing responsibilities. 

But as we mentioned above, with role-based permissions, you only need to set up your permissions profile once, and Rippling takes on the busywork of assigning and removing permissions based on the parameters you set. 

When setting up the approvals process in your permissions profile, you’ll be able to define: 

• who the approval requests should be routed to

• whether approval is needed from just one or multiple approvers

• whether a single or multi-step approval process is needed (e.g. the decision needs to be approved by both the employee’s manager, and the manager’s manager as well)

And because you can assign approvers based on the title they hold rather than their individual name (e.g. 'VP of Employee’s Department' vs. ‘Daniel Cornfield’) you don’t have to worry about updating your permissions if the person holding that role later changes.

It also means that your permissions profile can apply equally to someone in Sales or Marketing without issue—in the former situation, the approval request will go to the VP of Sales, while in the latter, it would go to your VP of Marketing instead. Which means you have the flexibility to assign permission profiles across teams and departments as well.