Downstream Data: Letting Information Flow from BambooHR Through Okta

by Aaron Zander Sr. IT Administrator at Massdrop

An All Too Familiar Problem

How many times a day does this happen in your org: Employee A, let’s call her Danielle, had a job adjusted every so slightly and now they need access to a few new tools. Danielle can’t give herself access, HR can’t give her access, her manager can’t help either. So they open a ticket with IT. IT is swamped, it’s the middle of the week and that big rollout is coming up this weekend. It’s not that they don’t want to help Danielle, but it takes 10 minutes just to make sure Danielle’s permissions are correct and they don’t want to interrupt what they’re doing right now for a “low priority issue”. So Danielle waits half a day she could be learning about her new Job just so a busy IT person to have the time to make all the changes to Danielle’s account so she can finally get to that tool she needs.

Sounds all too familiar right? I’ve been on both sides of this problem more than once. I waited a month once to get access to a tool I needed for my job at Apple. It’s not that IT didn’t have the time, but something was broken with my ACL rules and they didn’t have a senior person with enough time to fix it. When I worked at Sitecore, we had so many systems and so few of us who knew them intimately, that getting your ticket assigned to the right person could take a few days, add in a day for timezone issues and your week could slip by.


Let’s be honest, if anyone could “do security” we wouldn’t have jobs right? It’s not like you want to give Joe Cubical access to Active Directory and say “hey here you go, add people to whatever group you want, it’s easy”. Nothing about Active Directory is “easy” for most people, it’s a foreign tool, and that’s even assuming you have Active Directory, which at Massdrop, we do not.

In my last post about Okta, I outlined our use of BambooHR and Okta’s Universal Directory to provide seamless access to our users automatically from day one, until the day their accounts are automatically shut down by HR. The entire process is hands off from IT, and more importantly any changes from BambooHR flow into Okta and out into our other connected tools. But BambooHR can control more than just some one’s name or their best personal email, what if I told you it can control fined grained ACL rules too? Using Okta’s Universal Directory, and BambooHR’s easy customization the job is pretty easy.

Let’s get back to poor Danielle. Danielle has just been promoted from Associate Buyer to Merchandiser, congratulations. She’s also expanding her reach to work with 2 Communities on our site, Hobby Shop and RC, lastly Danielle will also be needing to access our readonly database to pull more information on product performances in her communities. So in total Danielle needs the following:

  • Access to our in-house Merchandising tool
  • Access to our Redshift DB in the office and on the VPN
  • Automatic filtering for her two communities, Hobby Shop and RC
  • Elevated permissions to open and close drops etc.

In the past the way a lot of this would have been adjusted is running SQL updates in our DB to elevate or adjust access and permission. If you thought AD was bad, try running SQL updates on a live database with all the minutia you need. It’s not fun. It also required either myself, or one of a select few engineers to do this for you, which also made it difficult. Something needed to change.

Note: While this post specifically relates to BambooHR, this can be applied to many apps you use with Okta including custom ones and Workday


In my last job, we used BambooHR as a great information source. New hire documentation was literally created in BambooHR. Computer Assets were assigned in BambooHR, seating assignments, etc. You name it we could make a field, or section or entire tab for in an employee’s profile. But that’s also where that flow of information stopped aside from helpful emails for new employees or other change requests. At Massdrop, we already had the integration going, we were already ingesting all of that data and using it already. Depending on what department you were in, we were assigning applications already. So why not take it one step forward.

In BambooHR we created a section in the “Job” tab for all employees. Here we have 2 drops down menus titled ACL Group and Level of Responsibility and a section of checkboxes representing each community we have on the site. For Danielle, all I have to do is make the appropriate changes and click save, it takes almost no time at all, it’s also extremely clear who has what access. Within the hour all these changes will be imported into Okta and spread out through all our apps in seconds.

Not convinced? Here’s a gif; it’s 12 seconds long and I wasn’t exactly hustling.

Adjusting permissions in BambooHR using Custom fields

Adding fields in BambooHR is pretty easy, send them a support ticket with what you want the field to be called and the type of field you want [Blank Text, Drop Down Menu, Radio Buttons etc]. Once created you can add or remove any items you need to through the admin panel in just a few clicks.


So BambooHR has information it’s sending to Okta, but we need to teach Okta where to put it. In Okta’s Universal Directory, any App that can import data can have that data mapped onto a profile. When using a provisioning master like BambooHR this goes directly into the primary Okta profile. The first step is opening the Profile Editor, and editing the Okta user profile. What we’re doing here is mapping out the default skeleton for all users we’ll later skin with profile data from BambooHR. Default attributes include obvious things like first and last name, email department etc. We’ll setup a new attribute with the “Add Attribute” button and fill it out, here’s an example of what our VPN group looks like:

Adding a custom user attribute to the user profile in Okta’s Universal Directory

With the base user profile adjusted to have the new field(s) we can move on to mapping the attribute from BambooHR to the new bones in Okta.

We’ll need to open our BambooHR provisioning profile and add an attribute here too. Unlike the Okta Profile, we don’t create a new attribute, we bring an attribute in from BambooHR. Click the “Add Attribute” button again and find the attribute you had BambooHR add for you (If you don’t see your attribute, try refreshing the list). Custom fields are typically named custom<group name> for example customACLGroup is the name of our VPN ACL group. Select it and add a display name.

At this point we’ve done the following:

  • Created a bucket in Okta to accept new user data
  • Added new employee details in BambooHR that will be sent to Okta
  • Told Okta that we want to be able to use that data from BambooHR in user profiles

All that’s left is to actually map the data from BambooHR source to the Okta, so Okta can use it and share that data down the line to other tools.

We’ll open the attribute mapping tool by clicking the “Map Attributes” button. The flow goes from right to left. Data on the left side represents information in BambooHR, fields on the right side represent the name of the attribute you’ll be mapping onto in Okta. For this example we’ll be doing a 1:1 mapping. 1 attribute from BambooHR to 1 attribute in Okta. If you wanted to you could use Okta’s expression language to do much more complex mappings if you have the need.

Find the new attribute we want to map to on the right side, and in the left side drop down either type in or select the corresponding attribute in BambooHR.

That’s it.

Seriously, you’re done. Here’s some of what Massdrop’s custom fields look like:

Mapped custom attributes from BambooHR (right) to Okta (left)

I recommend testing it by pulling up a user in the preview field at the bottom, if everything went smoothly (and really, it should) it will look like this:

Data pulled from BambooHR Attributes (left) and what the data “looks” like in Okta (right)


Let’s take a look at relevant data that we’ll use to give Danielle, or any employee her permissions

  • Department: Merchandising
  • Communities: RC and HobbyShop
  • ACL Group for the VPN: Database
  • Level of Responsibility: Employee

Here’s how all that maps onto our tools and groups:

  • Our Merchandising App is assigned to anyone in the Department `Merchandising` after it was changed from `Buyer`
  • The communities information, department, and level of responsibility are passed onto our internal tool set
  • Her change permissions are set based on responsibility level Employee upgraded from Associate
  • Her communities are pulled from a data set of Hobby Shop, RC
  • Her Department Merchandiser assigns her subset of tools in the app
  • Redshift access is granted to any one in the ACL group Database
  • The VPN app, Pritunl, given to those users with this set to anything but null using Okta UD Rules
  • The attribute is passed to Pritunl so the user will be sent to the correct subnet on the VPN
  • Redshift user access is generated based on this profile data as well

She’s also assigned to several email groups, other tools and assets all based on these attributes. Using the Groups and Rules section of Okta’s Universal Directory makes a lot of these tasks easy, and repeatable with very low effort. Add in expressions and you can zero in on just the right people to give the right tools.


So far so good, in our new system, once the data is updated in BambooHR Danielle has everything she needs as soon as it automatically populates in Okta. But we’re still back at the beginning. Danielle still needs to ask IT, or maybe HR to help her out. But what if she didn’t have too? Her manager knows the tools she needs, shouldn’t they be able to help her?

This is the primary reason why I use BambooHR for this in the first place. I could do all of this in Okta, it wouldn’t be that much harder, maybe less visible, but for me no big deal. Managers need to manage their employees, They already use BambooHR for their own needs as well as monitoring and approving employee requests like time off. Keeping everything in the same toolset retains familiarity and cuts down on confusion. Your BambooHR admin can give different groups of people different responsibilities. Managers at Massdrop are given the ability to update some fields for their employees.

A look a the group settings for our People Managers in BambooHR

The change logs on both BambooHR and Okta gives us visibility into rogue changes (not that we’ve had any) and the permissions are variable, large companies can add more fields and more user groups with more granular settings, so a low level manger can’t give their employee C-Level access. Empowering employees is a large part of my personal philosophy for IT. I trust the people I work with; we’re a small, flat organization and arrangements like these allow me to run every level of IT from laptops and TV’s to VPN and user groups, by myself. For me, Okta allows me to empower my coworkers and lighten my workload on a day-to-day basis, maybe it can help you do the same.

To learn more about Okta, and Single Sign On visit

To learn more about Bamboohr, and their HRMS tools visis

Visit Massdrop at

If you’re interested in joining Massdrop, check out our Careers Page

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.