Bringing it All Together

Arvil: I'm really excited to be co-presenting with Bibu Mohapatra. He's a principle engineer at Palo Alto Networks, and he's an identity architect there. 

We're going to be talking a lot about Joiner, Mover, Leaver and our HR as a Master product. Basically, how do you use HR to trigger events in downstream systems, consolidate directories. And Bibu's actually going to walk you through Palo Alto's journey and how they adopted HR as a Master from actually a couple systems. This basically says don't trust anything I say, actually.  I don't know if you guys attended last session, George gave a roadmap presentation all around lifecycle management and he really hit into that three core pillars that we're trying to solve for within our lifecycle management product. Acting as a single source of truth, automating all parts of the user lifecycle and connecting to everything. We do this not only for employees but we do this for contractors, partners and customers.

And I'm going to talk about one specific flow about how you can master and import from your ultimate system of record, but this is just reminding everybody that our lifecycle management product is much broader.

We're going to start a little bit around Joiner Mover Leaver. How many people have heard these terms before? Okay, all right, so people know some things here. So, this is the framework that we're going to be using throughout the presentation to talk about all the core components around a user lifecycle. The first process is around Joiner, this is really around user onboarding.

We think about this as sourcing identity from third party systems. That could be an HR system like Workday, Success Factors, UltiPro. It could be your IT directory such as AD or LDAP, or it could even be our self-service registration feature. How do we source those users from a third party system and bring them into Okta?

Once those users are brought into Okta, how do we make sure that through a set of rules and contexts that they're assigned to the right set of resources? Right, that could be birthright apps or it could be modeled through our access request workflow to now enable users to basically request apps on their own.

Second we have mover flows, right. Name changes, leave of absences, marriage, things like that. How do we manage that in an automated fashion within an organization? And finally we have leaver flows, how do we securely remove access from users once they leave the organization? There are kind of two flavors to this that we will discuss. We have immediate as well as scheduled.

So what is Okta's solution for this today? Throughout this presentation I'm going to talk about kind of what are we doing today, what's on the cart, how does it work, Bibu will present to us and tell us a little bit about Palo Alto’s journey, and then we'll talk about road map. But our HR as a master product basically allows you to source identities from your source of truth, your HR system. We know lots of architectures model this differently with something like active directory, but we find that if you can connect more deeply to your HR system and have HR kind of be the ultimate moderator of data fidelity, then we can enable that data to basically be pushed into downstream systems.

We have pre-integrated out of the box connectors to things like Workday, UltiPro, Bamboo, Success Factors as well as Namely. We also have APIs for you to mimic this functionality on your own and we also have a lightweight agent based model that can do this. But this is basically the architecture that we've seen hundreds of customers adopt. HR directly connects to Okta, AD in your OnPrem systems are downstream with bidirectional sync and your users being assigned to all the cloud or OnPrem apps are basically downstream of that process.

I wanted to touch a little bit more on our agent based model. We have something called Okta's on premise provisioning agent. And what that does is it's very similar to our AD agent, how many people have used our AD agent before? Okay, everybody pretty much. Very lightweight, very easy to set up. This is basically an agent based model that can consume custom code. It sits behind a firewall, you can install multiple agents for high availability, and most importantly it can connect to anything. Cloud apps with native SCIM support or OnPrem applications that you can basically write custom code for. So we've seen a lot of customers have success with this. If you happen to have a system that doesn't have an out of the box connector today.

So why should you care about this, why are you in this session today, why is HR as a master important? First of all for IT, we see when we talk to customers there are an enormous number of legacy systems. We saw a large healthcare customer of ours be able to basically kill off six separate systems that they're able to achieve with HR as a master. And all the maintenance costs and ownership cost that came as a result of that. 

You're able to improve productivity through automation as well as decreasing security risk by automating that off boarding process. For HR because this is not IT doing this in isolation, when customers are successful with this, this is a real partnership. You're able to enhance kind of the data fidelity and accuracy because you're in charge of the onboarding process and how that data is disseminated across systems. Reduce back and forth tickets, emails, et cetera. And we've actually seen with customers, you don't pay people longer than you should, turn off payroll, right? When someone leaves the company. This could save you a lot of money.

Finally, for employees, we've all felt this right? We've onboarded and it hasn't been the best process. Make sure that everybody has access to what they need on day one, right? Avoid delays by giving people a self-service option and give them a consolidated place or HR system for them to update all of their information on their own. You are not alone, this is not a new product, right? This is just a sample of some pretty logos I pulled off our website actually of people that have adopted HR as a master, right? This is just a subset, though.

So while this is not new, we found that it's valuable for people to be reminded of both the value in how it works in case this could be beneficial for your own architectures. So we'll go into a little bit more detail as to how this works today and how we solve sort of these joiner, mover, leaver problems starting with joiner. Manual onboarding processes do not scale, how many people have some version of this process, right? Recruiting to HR an email, a ticket, a form, very manual, right? Or two hands, you have two processes that have that exact thing, right?

IT is burdened with all of these requests from all of these systems, right? And you guys are miracle workers in being able to sort this out in getting everything a user needs to be successful on day one, right, but we do not want to be this Dilbert cartoon, right? This is a high touch process. It does not scale as your business grows and we all know everybody in this room has invested in Okta and all of your businesses are growing immensely as a result, right? This is a huge burden for IT and a loss of user productivity as this increases and exacerbates.

Is anybody's complexity going down here in their user environments? No, I didn't really think so, right? So what does Okta do to help support this? This is just a sample flow from our success factors as a master integration. So what we do today is we basically schedule imports into Okta on a recurring basis, those imports are basically a download of all the users from that third party system. Once that user is brought into Okta they get this ... I keep calling this a beautiful activation email, I don't know if it's beautiful really, but if you've seen onboarding through AD, this is magnificent, you know.

They get an email, they don't have to ... no one time password is generated actually. They get an activation email, they get to set their password as part of the onboarding process. Once that activation email is sent and the user is activated basically through a set of group rules we can provision integration or simply assign users to integrations downstream including active directory. We realize that certain attributes are not created by Okta or created by IT ... or sorry, created by HR.

So for things like email and phone which might be modeled and created in a downstream system, we actually have functionality that writes back these attributes back to Okta and then back to the HR system so that your HR system continues to be the source of truth for user data within your organization. So this is just a sample flow for how this works, there's a lot more complexity here but I thought I'd give you guys an overview for how onboarding works.

We'll now move onto Mover. There are a lot of changes that happen with an organization. People get married, people switch departments and get new jobs and they need access modeled as a result of that differently. You could be a full time employee but you maybe were a contractor in the past, right and IT seeks to automate this entire process. How do we do this today? Group rules. Through basically attribute based access control we basically model access as a function of the attributes on a user. If you guys saw Unker's presentation earlier today this is getting more complex and more sophisticated in how we model things but this is our primary mechanism today to model all these changes that occur.

Finally let's talk about Leaver. While similar to joiner, this has a lot more security risk, right? And this is where the manual processes really fall down, right because employees leave the company and they still have access to the things that they shouldn't have access to, right. This is a big, big problem. Using Workday master as an example, we basically have two models of this today. We basically still operate on a model of a scheduled import for some deactivations. For Workdays for example we can actually trigger deactivation based on two separate dates, because people want to model differently how you cut off access versus when an employee leaves a company. So they use things like last day of work.

Based on those scheduled imports we'll basically deactivate the Okta user and as a result we'll deactivate all downstream accounts including AD. You also with workday have the ability to do an immediate deactivation. It's unfortunate but sometimes, you know, terminations are sensitive, they need to happen immediately. And with that we have a real time sync functionality which basically through a set of business processes within Workday you can basically turn off access immediately at a specific time. And so if someone has an exit interview you can make sure all their access is cut off immediately after that.

So that's a little bit about basically the product, I'll hand it over to Bibu now and then after he's done I'll talk a little bit about where we're headed moving forward.

Bibu: Thanks Arvil for the great start to the session. Hi everyone, good afternoon, hope you are enjoying the session so far. Arvil started his session saying you know he's the one standing between you and President Obama's speech, now two of us are standing between you and the next keynote session. So we'll try to make it really useful for your time.

So my name is Bibu Mohapatra I work in Palo Alto networks in the information technology group and you know today I want to spend the next few minutes to take you through our Palo Alto Networks journey for the user identity management using Okta's platform. Before we do that we just wanted to you know I wanted to talk to you about who we are.

So Palo Alto Networks we are a leader in cyber security. Some of you might be already using our products, so key thing for our company is protecting the digital way of life. And we provide you know automation platform for security. 

Also we're a pretty global company with close to 50,000 customers and around 5,000 strong employee workforce worldwide. So let's talk about why did we you know ... what was the user identity management process we had before we moved to Okta? And we'll talk about the challenges there.

So basically the legacy system. So we have two different HR data sources, you know one for our employees, one for the contractors. So there are multiple ways we were getting the data out of that, we were showing that sometimes you had manual reports coming from some HR systems, sometimes you write a script to get it, and once you do that then you feed it into a script that you have which then since the data or active data entry the user account is created or updated. 

Then that will spin off a lot of support tickets or emails which I'm pretty sure you all have seen it and then either somebody from the IT team, somebody from the HR team or business apps team, they will take it and grant the required access. So a lot of manual activities there.

So as you already see a lot of manual activities, a lot of human intervention, so whenever there is human intervention there is you know ... that's more prone to errors, that's time consuming, also if you have a new hire and they have ... you know you have that nice slide showing it takes six weeks to set up somebodies network access as per Dilbert, we were not taking that long to do it but it used to take some time. And then also it is inconsistent process for the user, the new hire comes in they don't know when their access will be set up.

So there are challenges with the legacy approach. Along with that there were other factors that forced us to consider our strategy for user lifecycle management. Let's talk about some of those. It's going by the joiner, mover leaver team in Arvil's slide. So, we are a very fast-moving company, we have been growing multiple times in the last four or five years, so we wanted to go with the speed of business and you know we needed a ...

Bibu: And we needed an identity management process, which would support that growth. We wanted to give our new hire consistent day one experience. They are coming to your company, joining your company, and we want to make sure that they hit the ground running on day one. Give them all the right level of access. 

I understand there will be challenges along the way. It's not like 100% of the apps, but at least make sure to all the critical apps they get access. Then for movers, ours is a pretty dynamic company. People take up challenges, and it's nothing unique to our company, but people want to move around, they want to take new roads. And then there are changes in their information because of their legal status, their manage, whatever happens. Their data changes.

So you want to make sure that the target applications have all the right data, and also the right access. So you want to take care of that. Last but not least, Leaver. When somebody leaves the company, you want to make sure the access is terminated on time. Whether it's the end of the business day or right away, because some unfortunate inordinate action in force happened, or somebody had to be let go. So you have to take care of that.

Those were all our business case to revamp our identity management process, so why did we go to Okta for this? When we started looking at it, we definitely had our choices. There are multiple Window products we looked at. Then we decided to go for Okta. And some key decisions are, as I mentioned, we have a growing number of clients in the last few years, so we wanted a partner which is also running at the same pace, which is moving at the same speed and they provide quick and easy integration platform.

Ours is a combination, it's a hybrid application, so we have a lot of apps in the cloud and few in the on premise, so we want a platform which will cater to both of those. And also, we want a partner that will go with us hand in hand if we have an issue, they will respond to us faster. Then incidentally, we started moving both our SSO and user provisioning into Okta at the same time, so it made a perfect time for us to capitalize on the Window maximization and from a relationship management standpoint.

And also, we being a cyber-security company and providing end point security, we have a product level partnership with Okta, so a lot of our products us Okta for multi-factor authentication. So it made perfect sense for us to go with Okta.

We looked at our Legacy user life cycle management, let's take a quick look at how it looks with Okta. We still have the same two HR data sources. I don't have any manual processors now getting to data out of HR, so for Workday, we have direct integration. We are using Okta out of box connector, we are using both their scheduling ports as we realize a real-time thing, getting the data, and we have another HR data source, which is used for contractors. We are getting the data through [rest paced 00:18:35] API calls, but we are using Okta on provisioning connector, so we are taking advantage of the scheduling port.

So the data comes over to Okta, and from there we send the data for new hires, we send it over to most of our critical applications and some applications, we use Okta only for the mover and leaver, the reason being that those the applications have just in time provisioning, so to optimize the licensing cost and all, so we do not want Okta to create the account, but we still want Okta to keep the user information up to date and they're getting the access cut off at the right time.

Just to summarize that, what we are getting using Okta. Using the Okta directly, we are getting a single view for the user. Now where the user data is, now we have one place where all the data is. Previously, it was all the data in HR system, some in active directory, now it's all in one place. So if I have to go in that system, I can get a single view for the user. I just spoke about, we're using Okta provisioning connector. Lately that has become a good friend of ours to integrate with some cloud apps, it helps. I'll talk on that a little in my next two slides, as well.

It helps with timely user onboarding and off boarding. And it gives a consistent, seamless experience to the users to they come on board, they get all their access set up right on time. They don't have to go through support cases to get it done.

And also, we reduced our manual processes. I cannot quantify it right now, we didn't take the time to quantify is it 60%, 70%? But I would say it's definitely more than 50% we have reduced the number of manual tasks, because IT admins, business admins, HR admins now they can focus on their job at hand. They can do other things in setting up user access.

So we have been doing it for the last 18 months to two years, so it's not been a completely smooth journey, I would say. It's a very nice journey, but not completely smooth. So along the way we learned a few tricks, so I would like to share some of those. I'm pretty sure it won't be a surprise to any of you, but I just wanted to speak about those.

Collaboration, any program you do, you need to collaborate within the team and outside of the team. All IM engineers, we know that any program we do in identity access management, or single sign on, it is not within one group. You are talking to multiple groups, because that's how the IM process is. So you need to have good collaboration. In this case, for HR as a master, make sure you have very good collaboration with your HR and IT at the leadership level so that they will help you to move faster, make decisions really quickly, and remove any road blocks. So ensure that.

Make HR, IS team as your good friends. They understand the HR business process, whichever HR application you use, they understand the process. You need to know that to implement that in Okta. 

And last but not least, your IT admins who had been setting up this user access manually for so long they learned about, they know about the new essence of some of the target apps. They might be doing something special for certain applications. You need to understand that to automate it. Then, I highly recommend you using the Okta system integration partners. We used Active Cyborg. They come with, their expert is on both Workday and Okta, I'm pretty sure they have experience in other areas, but this is what we use them for. And when you go live, speaking from experience, and I'm sure all of you agree that in production, you'll always find one extra thing that you did not see in the test environment. Something new that comes up always in production. You need somebody who has done it many times before, and they will help you along the way.

I want to talk about one or two technical things. User ID uniqueness, because if you are not using any IM product right now, your user data is so widespread, your people have multiple identities, so now you want to make sure when Okta creates the user identity, using data from your HR, it is always a clearly unique ID, so you have to make sure all the information is fed into Okta ahead of time.

The next one is, actually, it's a challenge for mainly the future hires. When you get a future hire how do you timely, and securely communicate their credentials and make sure that their user ID is not misused ahead of time because they are not yet your employee? How do you take care of that? If you have more questions about that, I'll be happy to discuss after the session about how do we take care of it.

Initial phases, we had been focusing on HR as a master. I believe that we achieved our target there, and also we have been focusing on the critical apps. Day one onboarding apps for users. So we have some success there, so where do we go from here?

We want to extend our automation framework where we want to do more and more application onboarding using Okta. This is where we realize the potential of on plan provisioning connector, because Okta can only do so much. Some target application, they have their own business logic, they all have custom implementation. I don't know how many of you have seen a [ERP 00:24:50] system with no customization at all? Okay, alright. I see one hand. That's great!

I would love to talk to you about how you did that, but most of the customers, I would say more than 90%, we see custom implementation. So you need a place where you can write your own code, your own business logic. That's where OPP connector provides you that framework. That flexibility to do it. So that's where we want to expand further, and also we want to create our own access request framework for on demand user access. You'll be using a third party work floor orchestration engine. And we'll use upper, I mean the orchestration engine will take care of the user approval process, and once it is done, you'll hand over the data for Okta for the final provisioning.

This is our journey in the last two years, and this is where we have ended up. It's been a pretty exciting journey using Okta as a platform. I hope I shared some information that you'll find useful, and if you have any questions, I'll be available during the Q&S session, as well as after this to answer any question. I'll be happy to do that. Over to you Aru.

Arvil: That was amazing. Thanks Bibu. We didn't even have to pay him to do that, he volunteered, weirdly. They're some good customers. I now want to talk about what we've kind of built in the recent past. Our road map, and then we're kind of moving forward. Just by a quick show of hand, there's kind of two buckets. “Hey, I'm thinking about deploying HR as a master.” Verus, “I've already deployed.” Who's in that first bucket here, thinking about it? And who's already deployed? Okay, alright. Cool.

Workday as a master. So I'll go through some of our integrations in terms of what we've shipped recently, and we can go into these features in more detail. This is a good one to take a picture of. We will get you these feature flags. 

Concurrent real time sync, so if you guys are using RTS and you're using scheduled imports, you now have the ability for those to run concurrently. Prior to that, they would basically run serially and get backed up behind one another. Now we have the ability for you to continue to fire those RTS jobs while an import is running.

The second feature is really around us upgrading the latest version of Workday's API. And most importantly, when our email and phone write back feature is heavily, heavily used. Some customers prefer a more secure web service, maintain contact info. If you get into kind of a tussle with HR sometimes about API tokens and scopes, this will help you convince them that those scopes are pretty much reduced when we're writing attributes back into Workday. So that is also an EA feature, currently.

The third one that I think is also very widely requested; so for customers that have distributed work forces due to some limitations on Workday's side, all the de-activations were actually occurring at midnight PST, the next scheduled import, yeah, he is smiling at me! He knows, he knows this issue. Now actually, we will fetch the location of the end user, and we will de-activate that user based on their specific time zone. So no more delays between having a user in California and a user in Sydney, for example. That will be EA very shortly.

We also have really improved some of our mover flows, so we now have a really seamless process to transition contingent workers to full-time workers and have that access modeled pretty seamlessly. That's a recent enhancement that is currently EA.

We're also really striving to make our system more performant, and to reduce import times. So incremental imports is EA currently, as well as batch imports, which will help with some memory issues that we've seen with some complex deployments. 

We also recently made success factors as a master generally available, right. This is an enterprise wide HR system owned by SAP, and this just went life kind of late 2017, so we're really excited. We've already got a number of customers live on the integration. It's very robust, it supports things like pre-hire interval, post-termination interval, post phone and email write back, as well as a really large number of attributes including both base, as well as custom attributes that you're able to import.

Next year, automotive, I don't know if any of you guys went to the [Cecil 00:29:43] of next year automotive session, but he actually talked about how they deployed success factors as a master. He even was talking about some stats. They actually were able to quantify a 75% reduction in password reset requests as well as a reduction in security breaches.

Finally, in terms of our integration enhancements-

Arvil: Finally, in terms of our integration enhancements we've actually just made Namely, as master, generally available. Now, this is actually very unique, because this is actually built on top of the SCIM protocol. SCIM is mainly known as a standard for how we can provision the third party systems once they support that standard, but it could also be used for import use cases. 

We've already got a number of customers live here, this is my plug. If you've got an HR integration where they do not support SCIM and you'd like them to connect to Okta for these types of use cases, go ask them to adopt SCIM. We're seeing hundreds of vendors, basically come to the network that are SCIM compliant now and I think it's going to take everybody in this rooms help to try to kind of promote this standard and to get more vendors to realize that it's really important.

Like with our other integrations, it's got a robust set of attributes as well as it supports right back. I'll now talk a little bit about the platform side. Independent about what integration you've got, there's a set of core flows that we need to improve on. It turns out our product is not perfect, news alert. The first set of features are really around sourcing identity from more systems. 

I'll talk a little bit more in detail about what we're calling CSV's master, we'll talk about the process by which you can more uniquely and flexibly create unique IDs, as well as define your own ability to match users across systems. 

In terms of the resource assignment lens, we're going to improve upon how we deliver credentials. That could be an activation email, it could be a password if AD or AD DevOp is involved. As well as reduce import times. 

Really, on mover and lever, I think what we're trying to do is more flexibly cater to your own business process. We have a lot of out of the box functionality, but we realize we need to do a better job of making our product more flexible to your own workflows. 

In terms of CSV as master, our goal is really to connect to anything. Right? I talked about that lightweight, agent based model that supports SCIM natively, but what we're actually building right now is an out of the box support for CSVs. 

Do people have CSVs that have user data that's transferred across systems? Because, we hear this a lot actually, in terms of this sometimes being the lowest common denominator for how HR and IT are able to communicate with one another. 

The way it will look is it basically will allow you to define a file path for an on prem folder. You can define your delimiter, you can define your unique user name. You basically install a lightweight agent on prem and it will pick up these CSVs on a scheduled basis. It will look and act like Workday.

We're really excited about this providing more flexibility to people that maybe don't have an out of the box connector or don't want to go through the work of building their own custom integration. Secondly, we've got import matching roles. 

Right now, when you import users from third party systems and you want to link it to an existing Okta user, we have some logic today in terms of how you can match those users. Okta username, their email, first name/last name, or some combination of those attributes. We're basically going to allow you to define any attribute on the user profile and allow you to match on that attribute.

The big request that we get is something like employee ID. A unique ID that's generated within your organization that you want to match on that you haven't been able to in the past. This is something we're actively working on. In terms of timeline, CSV as master will be in beta in the next quarter or so and this is roughly the same timeline. 

Unique ID creation, who knows who this is? Any guesses? Zero people know. Michael Bolton, 80s singer. Very famous. If you guys have seen office space, this is also Michael Bolton. The problem is, is he's a rap fan and his bosses are always confusing him with musical Michael Bolton. 

You've got musical Michael Bolton, he comes into your organization. What do you do? You have to create his identifier. Create his Okta username, create his email. This happens to be "[email protected]." You've got office space Michael Bolton, he enters the company. What happens? Email is taken, conflict is generated. Right? 

We realize that as you use HR systems, sometimes the identifier isn't created in the system and Okta needs to do a better job of helping in that process. What are we going to go build? We're basically going to go build an ID creation engine that will allow you to more flexibly define that unique identifier. 

Through EL or through some other mechanism you could basically provide, "How do I want to construct that email, or username, or ID? What are my fallback options should a conflict arise?" We're really excited about this, we're hoping to get to this, this year. 

Finally, I think this has been a theme throughout all of our lifecycle management sessions, is really what we're calling, "Triggers and actions." What you're able to do ... This is basically use case, which if you've been to other systems that basically says if someone is inactive for 30 days ... They haven't logged into Okta, then suspend the user. 

That generic, if then functionality can be extended towards HRs and master functionality. If user lifecycle and work day equals maternity leave, then I want to process these series of actions. Including a lifecycle state changed or potentially a move to another group. This will be customizable and it will be bundled with some of the out of the box functionality that we have today.

That was just a little bit of our roadmap, there's other things we're working on. I want to now talk about what's our vision with HR as a master. We really want to easily connect to any user store, whether that's Cloud or on prem. I'm going to repeat, whether Cloud or on prem. We have a long legacy of being a Cloud first company, but we realize that a lot of systems we need to connect to are on premise. 

We want to provide users an amazing day one experience, we want to be your onboarding interface for every single user at your company, we want to securely and quickly terminate all users to prevent rogue access, want to make sure you guys are compliant, and provide more flexibility to accommodate your organization's business processes. 

We want to marry all of the great, out of the box, ease of use with just a little bit more flexibility as to how this can work for your organization. That's it. It's been great sharing about what we're building and we'll open up for questions. Thanks so much ... Any questions? Yeah. We got a few in the front here. Yeah. Just grab the mic here. 

Speaker 3: You talked about the import matching. Is that coming to EA soon?

Arvil: That is currently just starting development, I would expect that to be in beta probably late Q2, early Q3. And then, hopefully EA maybe sometime in Q3, but those are very tentative. Once we get to beta we'll have a better sense. 

Speaker 3: Cool. Thank you.

Arvil: Cool. 

Speaker 4: Hi. I have a question about your mobile portion, where username changes and their email changes. Especially, when they get married or not. We see that some major challenge in this whole system, because as we are more and more adept to Okta, anywhere username changes it happens ... Last name change happen and email name change happening to the ID. 

It gets replicated to Okta also, but it does not go to the downstream app properly. Some accepts email change, some does not accept the last name change. I'll give you an example, Office 365 email doesn't ... We have to manually change it. 

Arvil: Got it. 

Speaker 4: For Zoom and Slack, the user ID gets created with the new name when you change it. Do you see this kind of challenges? What are the solution? 

I have some cases open with your support and with Zoom Slack and everyone and we are getting different answer, doesn't work well. I see this is a growing question, because as we are more and more ... Instead of reducing the work, we are increasing the work by manually changing those. 

Arvil: Yeah. We definitely hear about these use cases. I think one of the things we're actively looking at is how do we disentangle what is a unique ID from someone's email and username. 

I unfortunately don't have a good solution for you right now, we can certainly help with the vendors if there are vendor specific issues and trying to nudge them in the right direction. But, we're definitely thinking about that problem statement for sure. 

Any other ... Oh. Yep?

Speaker 5: Yeah. Related to that, what did you end up using as your immutable identifier for users since email seems like it's ... As a company grows it gets more and more unreliable, could we use a unique identifier?

Bibu: The unique identifier, definitely we create based on the user's name. I can certainly relate to the question asked before, but we run into the same challenge, there is no automated process right now. We have to take care of some of the applications manually, because if you generate user ID using somebody's last name their last name could change. We do run into that, it's a mix of manual as well as ... It's a semi-automated process.

Speaker 6: To add to this, we don't change the user IDs. In our case, we use Workday as a master and Workday generates a user ID. It has the uniqueness checks, so it will never generate the same ID twice. The user changes the name, we change the email. There could be challenges with changing email in downstream applications, but we do not change the user ID. That's it. 

I do have a question on a contingent worker to employee conversion. Can you elaborate on that, how that's going to work, and when is that going to be in the EA?

Arvil: It's already EA and the reason that, that issue was occurring was that Workday changes a worker IDs when someone moves from a contractor to a full-time employee even though it's the same person. We worked around Workday. That will now seamlessly, basically transition even though those worker IDs change. 

You will need to implement what Workday calls universal ID and assign a universal ID to all of your users in order for that to work. Basically, we talk about immutable IDs. Worker ID changes, which it should not be. There's basically a more global identifier that we're now taking advantage of. Yep?

Speaker 7: Hi. I'm curious how you get all of the entitlements and permissions right in all of those downstream SAS apps. What source data in a system like Workday do you use to power that? Specifically, our hypothesis is that matrix orbs within Workday could be a good source. I'm curious what you think.

Arvil: I think we see two models of this. Either people use provisioning groups within Workday itself and they allow HR to model how ... Almost be a more active participant in how, basically access is defined within Workday itself or we see basically attributes, including both base as well as custom attributes being populated as part of the worker profile. 

And then, those being directly imported into Okta in a set of group rules basically triggering access rights as a function of those. We kind of see two models or a combination of those in use today. Probably one last question. Yep? Right here. 

Speaker 8: Do you have anything on the roadmap for reporting on group membership? Because, the attributes ... How can I see who's in the group? How can I prove when somebody says, "Was my day one user onboarded correctly?" How can I report to find this?

Arvil: You want a consolidated report above and beyond CIS Log? Is that it? 

Speaker 8: Correct. CIS log is not valid here. Literally, if I have an attribute based provisioning system, everybody in sales with title pre-sales goes to these groups. How do I output those group numbers? 

Arvil: That one I'll have to ... The quick answer is, no. Not at the moment, but let's maybe talk offline about that one. 

Speaker 9: Well, a couple years back. The video we got in our email is that this is very common. You don't want to check your ID and pull up the members. Ideally, you want to see how many users have this app assigned in current time. This is for any app. It's very basic stuff and I think we struggled a lot with that. With recording documentation. 

Arvil: Yeah. 

Arvil: You just need to add export to CSV for every single thing.

Arvil: Yeah. Okay. I'll be in the back if people have more questions, but thanks, guys.