Automate Onboarding and Offboarding from your HR System

Ryan Bradley: Hi everyone. Welcome to today's session on automating onboarding and offboarding from your HR system. Before we get started, I'd like to remind you that Okta is a public company and any forward-looking statements are subject to change. Please read this safe harbor statement at your convenience. Also, I'd like to point out to you that there's a Q and A functionality within the presentation. If you have any questions that come up during the presentation, please feel free to ask them here. My name is Ryan Bradley. I'm a product manager at Okta, working on lifecycle management.

Ryan Bradley: I'm joined today by Arvil Nagpal, also a product manager at Okta, working on our workflows platform and Paul Reyes, chief information security officer and VP of risk, cybersecurity, and compliance for Vistra Energy. Now, some of you may be familiar with Okta's lifecycle management solutions. For those of you who aren't, these broadly fall into three buckets, provisioning, identity lifecycle, and access grants. Provisioning is how you manage your critical cloud applications at scale, automating end user creation, update and deactivation. Identity lifecycle is how you automate key end user access processes based on changes to information in your source of truth.

Ryan Bradley: Access grants are how you determine who has access to what, all with the goal of reducing the burden on your help desk and manual processes. During today's portion, we'll focus on identity lifecycle and when we think about identity lifecycle, we typically think about processes within your organization that fall into one of three buckets, joiner, mover, or leaver. What exactly are joiner mover and leaver processes? Well, joiner is the means by which identities are sourced from a third party and end users are on-boarded. Mover is the mechanism by which your user's access changes as a result of events like job changes, promotions, or leaves of absence.

Ryan Bradley: Leaver is how you remove access from employees and contractors after they leave your organization to maintain your security posture. Stepping back, traditionally how have organizations handled these joiner, mover, leaver processes? Well, historically, most organizations relied on AD and many still do as the system of record for their internal identities. Identity flowed from on-prem HR systems into active directory which among other things, handled authentication into on-prem applications and devices. However, AD couldn't fulfill all use cases, especially those around lifecycle management. That's why customers still had to implant legacy identity management solutions such as OIM, CA SiteMinder and even custom scripts.

Ryan Bradley: Architectures have changed as organizations migrate more and more to the cloud. That's where Okta entered the picture, downstream of active directory to handle authentication to cloud applications through SSO. Recently, we've seen more on-prem HR systems migrate to cloud-based HR systems and as a result, companies don't want to maintain the legacy piping and infrastructure from HR to active directory. Rather, they prefer to invest in a cloud first architecture connecting their HR system directly to their identity system, Okta. Now active directory can sit down stream of Okta and Okta can be responsible for authentication. We refer to this architecture as HR as a master.

Ryan Bradley: What exactly is HR as a master? Well, HR as a master is how you bring together different technologies which you might see in your organization today, whether they're on-premise or cloud-based. It could be HR systems like Workday or PeopleSoft. Cloud applications like ServiceNow, Box, Office 365 or Exchange On-Prem or directories like AD and LDAP. HR as a master is Okta's architecture that brings all of these technologies together to drive joiner, mover, and leaver processes which determine your end user's access based off of changes to your information in your source of truth, your HR system. What do we integrate with?

Ryan Bradley: Well, we have our out-of-the-box integrations with HR systems like Workday and SuccessFactors, integrations built by our partners with technologies like ADP and Oracle HCM, our CSV directory which enables you to import and synchronize users from any CSV file, and tooling like our on-premise provisioning agent and Skim app wizard which allows you to connect to other systems. For example, our on-premise agent has been used to connect to systems like Ceridian Dayforce, PeopleSoft, and Fieldglass. What can you do with HR as a master? Well, there's a range of possibilities, but during today's presentation, I'd like to focus on three, comprehensive onboarding for new users, automating manual changes from HR, and maintaining security while offboarding users.

Ryan Bradley: Starting with creating a comprehensive day one experience for your employees. In this case, you have a new hire in your HR system on the left. You bring that new hire's identity into Okta using a scheduled import. Then on their first day of work, Okta sends them this customized activation email welcoming them to your organization as well as providing them with instructions to access Okta, set up their password, and set up MFA. Using groups or rules, you can assign that end user access to the applications that they'll require in their new job. If provisioning support, you can even create accounts for them in the downstream applications, and we recognize that not all attributes live in your HR system.

Ryan Bradley: Some such as email or phone number might live elsewhere, whether it's in AD, Office 365 or your phone system. Okta is able to write those back from their source to the HR system giving you a complete comprehensive view of your end user. We also understand how difficult it is when data changing in your HR system leads to manual effort for IT. That's why Okta can help you automate these changes using our group functionality. In this example, take a user Steve from our sales org. Steve decides he wants to move to marketing. Once his change is approved, Steve's department and cost center is updated in Workday. This change when brought into Okta triggers a group rule in Okta which will remove Steve from the sales group and reassign him to the marketing group.

Ryan Bradley: Then Steve is provided with access to all the new apps he'll require as a member of the marketing org, such as Marketo so he's ready to hit the ground running in his new role, all without manual effort from IT. Finally, we know how important it is to maintain security while offboarding your users. Whether it's on your employees last day worked or their termination date, we remove access to Okta and revoke access and licenses in downstream applications, even deactivating the user in active directory if necessary. We know that some terminations are much more time-sensitive. That's why we have features like our real-time sync functionality with Workday which can take this action immediately to maintain the security of your organization.

Ryan Bradley: You've seen a little bit about some of the capabilities of HR as a master, but what are the benefits that organizations actually see when they use it? Well, benefits range across reduced costs eliminated back and forth between HR and IT and a seamless day one experience for your employees and other users. That's why we use HR as a master at Okta where accurate employee data from our Workday implementation is used to automate our key business identity processes, and we're not the only ones. Other customers such as Allergen, News Corp and Post use HR as a master as well. Now I'd like to hand it off to Paul Reyes from Vistra Energy to talk more about his organization, their journey with Okta and how they use HR as a...

Paul Reyes: How you doing folks? Again, my name is Paul Reyes. I work with Vistra Energy. I'm the chief information security officer for the company. We're headquarters in Irving Texas, and we do three main functions. One, we provide a generation to the United States. We produce over 40,000 megawatts of power across the United States. We have several retail organizations that sell power, and that's across six of the seven competitive market spaces in the United States. We're global as well with footprints in Japan and Canada. We also have around 10,000 users that access our systems with about five million retail customers. What I'm going to talk to you about is really what was plugging us when we looked at identity access management.

Paul Reyes: The challenges that we had were really around managing our user provisioning. Provisioning and de-provisioning, making sure they were within compliance for our regulatory requirements, and trying to fix the exhaustive error-prone items that human resources were or our challenges with. It took us a lot of people to go and take this mass termination email list and ensure that every application was decommissioned appropriately. Then on top of that, when we did our controls created deficiencies when somebody didn't do their control appropriately and on time. Then secondly, wrapping around people. People still represents the largest risk to companies, just simply because it's error-prone.

Paul Reyes: Anytime you leave with manual efforts, you end up with access configurations that weren't completed. Maybe you had resource turnover and then that resource didn't get appropriately instructions on how to terminate folks up on a timely basis. We were all challenged with those and on our process trying to get to HR as a master, we had to target those fixes. When we looked at what we had, the challenges that we had in our legacy environment. I'm sure a few of y'all may be still on a mainframe, but back then in 2009, when we migrated over, we were on the mainframe. We were provisioning RACF IDs back then over to a batch job that then incorporated that into our active directory environment.

Paul Reyes: Then with that active directory environment, then we had manual folks that would go and create the various user accounts, and then provision those into sub-applications when necessary. Then with that, that sync process had either manual batches or custom code jobs that somebody would execute, and then anytime somebody left who was writing that code and somebody else had to come back in and go update that code and fix it when they didn't work. We would only find those out when we were in a controlled fix action when we went and found deficiencies in the controls we did to go find out if the users were supposed to be provisioned there or not.

Paul Reyes: We were also getting user requests that says, "Hey, I need to be having access like John," and then John would have two or three jumps of moving their roles and ended up with a lot more than they needed. Then so the new person that came in ended up right off the bat having more access than they're required. We always had a challenge with making sure that it was least privilege in our environment. Of course, that leads into the challenge with our role change status. When somebody changed from one role to the next, we had a lot of contractors go to employees or somebody got promoted and went from a producer of a purchase order, and then now approves a purchase order.

Paul Reyes: They ended up not being able to see that change unless somebody told them that they had the wrong access. Again, we wouldn't find it out until we had a control in there and says, "Hey, this person's supposed to be in these groups." Sometimes we would get it right and catch it then. Other times, we would find it out when an auditor came in and said, "Hey, you have people crossing two lines." Then when we went into de-provisioning and somebody left the organization was to be the same issue. We ended up not filtering something from HR all the way down into the roles and the sub-applications that are needed because they weren't all tied together.

Paul Reyes: Of course, as you look at when we terminate a user, these were still back to a mass termination now. HR would send out this mass termination email. It would either say to remove these people on this time or remove them at a future timeframe, and we were in trusting that the distribution list was accurate to the people who were trained in that distribution list. Then you ended up growing that distribution so big because you didn't want to miss anything, and you would still end up having impacts when groups didn't transition their knowledge base over to the next person responsible. Then in our journey, when we went and said, "Hey, how do we go from where we're at to cloud service," we now have HR as Workday.

Paul Reyes: We've had that for a bit and then when we decided to go move that into with Okta, we had it in a four released model. We just described that says there's going to be four releases as we go through this journey, and then in that, we will be able to hit from just user provisioning day one to all the way throughout sub-application provisioning. On a first release, we really just wanted to get Workday being the master, shifting that data over to Okta and Okta provisioning both Office 365 and our on-premise active directory, so that was our release one.

Paul Reyes: Then in the plan, we said, "Hey, we're going to go over and knock out our single sign-ons," and we had several applications where SSL enabled and thought that they could be pretty easy enabled into our environment to do single sign-on. This is a group of lists of applications that we targeted for single sign-on. Then once we said we had that big application list, we were then going to go and enable multi-factor authentication. We're going to go enable multi-factor authentication. We would transition those users, and the reason it was third is because we really had a challenge with our first time that we try to release multi-factor authentication with another partner, and it was really painful.

Paul Reyes: A lot of friction to the end users and so shifting this back on to this process said, "Hey, let's first get into Okta and then we'll turn it on on the third release," so that was a plan. As I said and you probably just saw it in that clip that was definitely a bad mistake when I go walk through the flow. I'll describe what challenges that we had in that multi-factor authentication. Our last release was to then do server provisioning and de-provisioning into our sub-applications. We targeted these applications here, Salesforce, Workday, Office 365, ServiceNow, Box and then we also have Zscaler for our perimeter protections.

Paul Reyes: More applications are being deployed as we go through in our further releases now. As we looked at this whole landscape of our projects, we ended up with our current flow today which is our model where we go from Workday over into Okta, and then Okta then by directionally provisions that into active directory. Active directory then shoots it over to exchange on-prem, but Okta directly moves that data into provisioning for Office 365 and all the other applications as we grow them. It goes really well because it works through our process very quickly.

Paul Reyes: The struggle that we had is we definitely should have put MFA upfront, and we had several breaches throughout that first part where when we started putting things in the cloud with single factor authentication, it challenged us tremendously. We had a lot of CSIRPs, cyber security incident response plans going because of the single sign-on and so multi-factor should have been day one. As a lesson learned, I was recommending to anybody else, when you go through this process and enable into Okta, definitely start with MFA. The second piece is still struggling, we're still struggling with role-based security or as we use it capability-based security.

Paul Reyes: Making sure that you define the roles upfront so that your downstream provisioning becomes very easy and at that time, we didn't plan for all of them, so only the new cloud enables applications became easy. All the rest, our legacy applications were real struggle. I'll talk through it a little bit more in a bit. As we go through here, our flow in which we drive this provisioning is we went from Workday to our Okta environment and in that assigning resources, we provided birthright. We provided birthright to our common application like Office 365, Box and workplace. We provision in those immediately and our users got access right off the bat right when they were entered in Workday because they were a new resource.

Paul Reyes: The challenge with that is we really didn't stop and build for the future. We went and tried to tackle it as we went when we should have defined all the roles and the different provisioning access rights that they should have had and married those up with our Okta provisioning area, so that way day one, we could have had a lot more applications. We struggled and it took a lot of time for each one of those integrations to occur because we didn't plan them all upfront. We would have probably also simplified the process.

Paul Reyes: We still have legacy batch jobs that we're trying to pull it to sub-applications and other custom codes that were pulling it, and we probably should have just simplified the process and say, "Let's centralize all of that and let Workday do all the capabilities that Workday can do, and then it do the creation of the accounts and then push that down rather than us trying to backfill it because we had old processes in place." The second piece is as we go through our mover, when we still went to the movers, that worked fine for those that we're auto provisioning too. As we get and did our auto provisioning pieces to Office 365 or Box and so forth, those worked really well, but where they didn't was our sub-applications that didn't have those provisioning rights set up.

Paul Reyes: Fair as human, when somebody's gets an email that says this person switched the roll, we're depending on that resource to be provisioning them from that environment. We wouldn't catch that until we have the controls that went through and says, are these people the right people to be in there, or we've caught it within the audit. Let them learn. Start with your users, figure out what roles and rights they need, provision those and get those updated with your subject matter experts in each of those apps, and match those as you start building out that provisioning.

Paul Reyes: Next is the leavers, and so the leavers for us is when we either terminated somebody or they left the company. There was either two areas that we were able to provision really, really quick is one, immediately people leaving or schedule leaving. When those occurred, that worked really good from the applications that we had provisioning for. What we struggled with were the areas where we had compliance upfront, so those that had to have a 4-hour turnaround or a 12-hour turnaround for regulatory requirements such as, and we're in the generation space of [inaudible 00:21:52]. That was a struggle, so we have to stop and go back and automate those functions, get them involved, and get those rights connected up so that they could auto provision in those timeframes.

Paul Reyes: Now they work great. They're automated and configure. We still have a few mass emails that go to sub-applications, things like PeopleSoft or SAP, big legacy environments that have a ton of rights, and that seems to be the biggest issue when you need subject matter experts for those applications to understand the rights of those apps, and be able to map those up to an Okta provisioning role-based security. I would probably suggest make sure you know what the compliance obligations are, automate as much as possible, and get your subject matter expert for those applications that are the biggest hit items, and get them involved to map those to your operating groups.

Paul Reyes: In summary, I think what you find if I would have to give you any thoughts for how you do this because definitely it helps building for the future and build that upfront, know where you're going and where your biggest hits are. First stop and understand where your new hires the most come in to. For instance, technology is a group that a lot of new hires come in into and our finance group and our marketing group, they might have had the biggest groups. Probably do role-based security for them first and get them done, so that every new hire, you're not keep bleeding on this. You'll stop the bleeding by every one of those being done appropriately, and get your automation done.

Paul Reyes: It alleviates your on-premise folks from having to do redundant tasks. Nobody wants to sit there and do reoccurring, redundant tasks. They really want to work on future state, target state items. This alleviates that redundancy. Secondly, consolidate access to a central control. All your sub-applications that want to manage their own user accounts, bring those in to a central repository so that you can manage those all from Okta, and then you can provision those and de-provision on the fly. That eliminates a lot of friction for the users in the long run as well as headaches for your admins and then lastly, don't underestimate the work.

Paul Reyes: You're going to need subject matter experts for those applications that have a lot of roles, and so make sure that they're in conjunction with you mapping those roles, so that you can put them upfront and not have to fight for them at the end. That's my story. I hope you leverage it as much as we have. It's really good functionalities to automate these provisionings, and we're always building and learning for new applications as we go along. I'm going to turn it over to Arvil Nagpal for our next view.

Arvil Nagpal: Cool. Thanks Paul. Oops. I'm going to talk a little bit about workflows and HR as a master now. Ryan gave you a little bit of an overview of what our capabilities are today. Paul gave you a great deep dive into how Vistra Energy has seen value from implementing the product. Hopefully, that was a little bit helpful to you guys as you plan out your own journey or plan on modifying your own HR as a master [inaudible 00:25:12] talk about where we're heading as a product and a set of capabilities, especially as it relates to Okta workflows.

Arvil Nagpal: When we think about what we do today, customers really value HR as a master because of its ability to be prescriptive, easy to use, easy to set up, and really deeply integrated into core Okta processes in helping to provide prescriptive paths to automate the joiner, mover and leaver flows. As we've talked to more and more customers, organizations want more flexibility. We think about these customizations in three different ways, logic, timing, and actions. In terms of logic, when we think about what customers are requesting, it's really the how and the why. For example, I'd only like to import specific groups of users from Workday, so putting more logical components into how things occur in automating your joiner, mover, and leaver processes is really critical.

Arvil Nagpal: Second is timing. This is more of the when. For example, when employee moves roles, I'd like them to retain the access levels for their old role for a few weeks while they transition. Lastly, it's really around multiple application actions. Okta is not the only thing that you're trying to automate or key off of. For example, people want real-time methods to deactivate certain sensitive users like involuntary terminations and implement actions and downstream systems. These are all the requests that we've gotten over the years in what customers need in terms of better utilizing the HR as a master capabilities that Okta has. As we think about a lot of what was discussed during the keynote, Okta's very much in the middle of a product to platform transition.

Arvil Nagpal: We've got these products underlying them will be a set of platform services which includes Okta workflows. As we think about the future, the future really is Okta workflows and what is Okta workflows? Okta workflows is a identity specific automation platform that helps you automate the joiner, mover, leaver processes without needing to know how to code. This no code platform allows you to implement that degree of customization that's never before been possible to the extent that is today. For example, every flow starts with an event. When a user is terminated in Workday, you may need to implement logical conditions, like was this an involuntary or voluntary termination?

Arvil Nagpal: If it was voluntary, notify a set of admins for the security channel, and then do actions and downstream systems which could be Okta, like killing active sessions. This flow is completely customizable and will really take our HR as a master capabilities to the next generation. We're being super hyper focus on what use cases we're addressing this year. As we think about these use cases, they really primarily are oriented towards lifecycle manager. I want to say that directly this is part of the advanced lifecycle management skew. There's no current capability if you own advanced mastering as a skew to get these workflows capabilities, but we really think that workflows this year will be able to extend certain use cases.

Arvil Nagpal: We'll talk about these in more depth. While we're not explicitly tackling the full HR as a master flows including HR integrations, we think there are two key use cases that we think workflows can help extend HR as a master capabilities. Those are resolving identity creation conflicts and then time-based policies to manage identity lifecycle. I wanted to talk a little bit about how that transition will occur.

Arvil Nagpal: This past year, we've really been focused on improving scalability and performance of our top integrations, especially Workday and in this year 2020, we're really going to continue to focus on the speed of synchronization, especially for the largest enterprises when we roll out enhancements we've been working on for quite a long time that we think will reduce overall import and synchronization times by 80%. We're also going to be making significant inroads towards this future workflows vision. We'll be launching a beta, a proof of concept for workflows for HR as a master this year, and then next year, you can expect an early adopter program in production for workflows for HR as a master.

Arvil Nagpal: This is a little bit of a cadence about what we're doing this year, how we can extend workflows for HR as a master in the interim, but you'll see a more fully featured and then solution next year. Let's go into a little bit of the specific use cases. I mentioned two use cases upfront and I want to really deep dive into how we're thinking about these specific use cases. The first one is resolving identity creation conflicts. A lot of times especially large enterprises as part of creating users, you need to create an identity, that's such a core concept within large enterprises. One thing that happens all the time though is there's conflicts. John Smith already exists, that user name is taken.

Arvil Nagpal: Through workflows by utilizing the import inline hook, when a user import is scheduled from something like Workday, Okta will actually notify you that there is a conflict that's been detected with a unique property like username or another attribute. That conflict resolution logic can be built directly into workflows to iterate let's say username by adding a number or by adding a middle initial to someone's email or username. You can then run that logic, pass the revised username or email back to workflows to back to Okta, and that user will be successfully imported. This is also really, really important for creating GUIDs.

Arvil Nagpal: We hear all the time from customers that as part of creating an identity, it's not just about email or username, but you need to create let's say an employee ID and that has specific parameters like depending on the type of user or the mix of letters and numbers that you'd like to have in a string. Through workflows, all of that customized logic can be built. It can be validated that GUID as unique and then finally at the end of the flow, you can actually update the user profile in Okta. This is an end to end solution for how you can tackle both of these use cases using our existing HR as a master capabilities plus workflows. The second use case that I want to talk through is really around importing users from the flat file.

Arvil Nagpal: Ryan mentioned before we have capabilities today like CSV directory that allow you on a scheduled basis to import users from a CSV file with a lightweight agent. Now we can actually integrate with any kind of CSV or flat file system on a scheduled basis bringing users. NTT is actually taking an advantage of this with the first use case where we're importing contractors and employees from a Google sheet. Every day at 5:00, let's say you read a sheet if the user is a contractor, then proceed and then for every user in that sheet, you can actually create them in Okta. Then for every user, maybe you want to notify their manager as well.

Arvil Nagpal: It's a really, really lightweight way to connect to any kind of disjointed set of users which we know from talking to customers happens quite frequently. The other use case might be M and A. Let's say you've acquired a company and you've got a one-time import use case for newly acquired companies. Instead of a Google sheet, you can import a CSV directly, create those users in Okta, and then potentially through a lookup table like our tables functionality, you can actually fetch their group memberships and then assign them to the correct groups in Okta. While it doesn't include some critical capabilities like profile mastering or attribute level mastering, we think that workflows can really take and make connecting the flat files in these disjointed user populations much, much easier.

Arvil Nagpal: I'm now going to hand it off to Ryan and we'll go through a quick demo of what workflows plus HR as a master looks like.

Ryan Bradley: Thanks Arvil. Let's take a look. Now let's take a closer look at that last example using a demo. In this example, my favorite paper company Dunder Mifflin has recently been acquired by Sabre. Sabre wants to provide all former Dunder Mifflin employees with access to the applications that they'll require by creating new accounts for them in Sabre's Okta organization. Then Sabre will use existing group rules that they have based off of employee department as you can see here to assign each user with access to the applications that they require. Let's see how workflows can be used to help them in this case. First, I'm going to go into the workflows console from the admin dashboard.

Ryan Bradley: Next, I'll create a new folder for my flow. We'll call it Sabre and before I start building my flow, I just want to pause and take a second to outline what we'll accomplish with this flow. I've built a bit of a summary here. I want to schedule this flow to execute at a certain time. In my case, Friday at 9:00 a.m. Pacific time. I want to read in a list of all Dunder Mifflin employees who are now new Sabre employees from a Google sheet that I have here that also has their associated necessary employee information. Then for each employee in the list, I want to get the associated attributes with that new user in Okta, such as their first name, their last name, and their username and create a new Okta user with these attributes.

Ryan Bradley: Finally, I want to use my existing group rules to assign access to the necessary applications for each user which you just saw. Now that we've done that, let's start building our flow. I'll pause again here and highlight three important concepts in workflows, events, app actions, and functions. Events are what start your flow. This could be a schedule as in our case, a call from another flow, or an event in Okta or another application. App actions allow you to connect with and integrate to Okta and other applications such as Salesforce, Box, G suite and more. Finally, functions our tools within workflows that allow you to control the execution of your flow and manipulate data.

Ryan Bradley: Let's start with the event that will start our flow. As I mentioned, we want a scheduled flow. Let's start on Fridays at 9:00 a.m. Pacific time. Next, we want to read in all the user information from this Google sheet that I showed you before. Let's add in an app action for Google sheets. Looking at the support actions, read all rows looks exactly like the action that I want as if it'll read in all the user information from that Google sheet. I'll specify my Google sheet in the relevant tab, and you can see that the output is a list of rows which are the users that I want to create in Okta as well as all the associated user data in the columns.

Ryan Bradley: Pausing here, let's save our flow so that we can actually test it out. I'll name it. I'll call it users parent flow and I'm going to save the data for debugging purposes. Then I'm going to save the flow and let's test out this flow using workflows test flow functionality, so that we can see what the output of this Google sheets read all rows action is. Looks like it's read all rows and you can see it executes successfully. It read each row and stored them in this list of JSON objects, and each JSON object has all the necessary user information from my Google sheet, so that's great. Now if you remember, my next step was to iterate over this list and for each user in the list to create a new user in Okta. To do this, I'm going to use a for each loop in workflows.

Ryan Bradley: This allows me to call a child flow that I specify on each item in a list. I'll specify for each, and you can see I pass in a list. In this case, the users that I want to create in Okta and now I choose a child flow. Now I haven't created my child flow yet, so I'll hit new flow and create that. In this case, the event that will start my flow is a call from another flow, I'll specify a child flow. I need to specify the inputs from my parent flow. I see that the input is the rows or the users to be imported, so I'll specify rows as my input to my child flow. Next, I'm going to save this flow. I'll call it import users child flow and enable data saving for debugging, and I'm going to turn it on so that we can actually see what the input to this child flow looks like.

Ryan Bradley: Going back to my parent flow. Before we test it again, I'll specify what the child flow is. Then I need to do one more thing which is specify the values from each item in the list that are passed in. You can see here, I can pass in the full item, pass in just specific columns, specific values from that item. In this case, I want to pass in the full item because it has all of the user information, so saving. Let's test this flow and see what the input to the child flow looks like, and everything ran successfully there. Now we'll go into the child flow take a look at our flow history to see yup, we had a bunch of successful executions of the child flow, one for each user in the Google sheet or each item in the list that I passed to the child flow.

Ryan Bradley: Looking at the specific information here, I can see that the child flow has passed just the user information or just the item from the list that I want to create a user for. What do I do next? Well, I've got this JSON object with all of my user information. Now I need to plug the specific values from that JSON object, so that I can pass them to the create user action in Okta that I'm going to use later. I need to get my first name, last name and other attributes. Workflows provides a handy function for this called get multiple in the object category. It allows us to get several values from an object at once. In this case, I'll specify my input as the object pass to the child flow, and then I need to specify what values to grab.

Ryan Bradley: This is a little bit tricky because I need to know the syntax. From the get multiple help card as well as seeing the format of the object that's passed in flow history, I can see that if I want to get the first name of the user, I would specify it as columns .0 - first name, last name as columns .1 - last name and so on and so forth. Let's enter these in. Great, specified all the attributes I need now. Now let's test the parent flow one more time to make sure that I did everything correctly and I'm able to get the values I need. Everything ran correctly once again. Let's look at the flow history for the child flow, and you can see here that I was able to get exactly the values I need.

Ryan Bradley: I can see that Kevin Malone has his appropriate first and last name as well as username and email and he's from the accounting department. The final step I need to do in this flow is just create this new user in Okta. I can do that using an action from the Okta connector. In this case, I'll specify that I want to create a user, and I'm going to specify creating user without credentials because I want my users to establish their own credentials. Now I see what attributes I can include in my create user action. In this case, I want to choose the four required Okta attributes, first name, last name, username, and email which are selected by default, but I also want to add the department as that's required for my group rules.

Ryan Bradley: Now that I have all the attributes that will be passed into Okta to create the user, I just drag and drop each attribute from my get multiple cards outputs to the appropriate input on the create user action. First name goes to first name, last name to last name, username to user name, email to email, and department to department. Finally, I'm going to specify to activate my user right now because I want them to have access to Okta as soon as possible. Now should be done with my flow, should be ready to go. Let's see, let's try it out. We'll test the parent flow one more time and everything executed correctly, but how are we going to know that it executed correctly?

Ryan Bradley: Well, we'll go back to our Okta tenant and if we go into a universal directory, we can see that yup, all of our friends from Dunder Mifflin including Jim, Pam, Kelly, Michael, Meredith and more are all in Okta now, but did our group rule execute correctly? Let's go to groups and let's see if Michael really got added to the management group. Yes, he did. He is now part of the management group along with existing Sabre management Joe and Gabe, and he has access to all the applications that he needs as a member of the management group. Now we've just seen how you can import users into Okta from a flat file such as a Google sheet or a CSV using workflows and integrate that with existing Okta functionality like group rules, which can be used to drive app assignments.

Ryan Bradley: Hope you're as excited as I am. If you're interested in learning more, workflows will be GA by the end of April. If you're interested, please contact your sales rep or CSM about getting access to workflows. As Arvil mentioned, you'll need the advanced lifecycle management SKU, sorry. We're also exploring more how workflows can deeply address HR as a master scenarios. As Arvil mentioned, we're looking at starting a beta later this year. If you're interested in learning more about this beta program, please sign up at the link you see on your screen. Thank you for attending today's session on automating onboarding and offboarding from your HR system.

Ryan Bradley: We have a few other sessions at this year's Okta and that we think you'll enjoy. I hope you get a chance to check them out. Thanks and enjoy the rest of the conference.