Oktane20: 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 the Safe Harbor statement at your convenience. Also, I'd like to point out to you that there's a Q&A functionality within the presentation. So, 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.I'm joined today by Arvil Nagpal, also a product manager at Okta working on the WorkFlows platform, and Paul Reyes, chief information security officer and VP of risk cybersecurity and compliance for Vistra Energy.

Ryan Bradley: Now, some of you may be familiar with Okta 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, and 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, and Leaver.

Ryan Bradley: So, 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 users access changes as a result of events like job changes promotions, or leaves of absence. And 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 implement legacy identity management solutions such as, OIM, CA Site Minder, 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 SSL. 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'd prefer to invest in a cloud first architecture, connecting their HR system directly to their identity system Okta. Now, Active Directory can sit downstream of Okta, and Okta can be responsible for authentication. We refer to this architecture as HR as a Master. So, 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. Could be HR systems like Workday, or PeopleSoft. Cloud applications like ServiceNow, Box, Office 365 or exchange on prem, or directories like AD and ELDA.

Ryan Bradley: HR as a Master is Okta's architecture that brings all of these technologies together to drive joiner mover and lever processes which determine your end users access based off of changes to your information in your source of truth, your HR system, and what do we integrate with? 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 in 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 De Force PeopleSoft and Fieldglass, and 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 off boarding users starting with creating a comprehensive day one experience for your employees.

Ryan Bradley: 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 roles, 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. Some, such as email or phone number, might live elsewhere, whether it's an AD, Office 365, or your phone system. So, Okta's 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.

Ryan Bradley: In this example, take a user, Steve, from our sales org. Steve decides he wants to move to marketing and once this 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. 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. And finally, we know how important it is to maintain security well off boarding your users. Whether it's on your employees last day works 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 and 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: So, 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 illuminated 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 Master.

Paul Reyes: How are you doing, folks? Again, my name is Paul Reyes. I work with this Vistra Energy. I'm the chief information security officer for the company. We're headquartered in Irving, Texas, and we do three main functions, one we provide generation to 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 and we're global as well with footprints in Japan and Canada. We also have around 10,000 users that access our systems, with about 5 million retail customers. So, what I'm going to talk to you about is, is really what was plaguing us when we looked at identity access management.

Paul Reyes: The challenges that we had were really around managing our user provisioning and de-provisioning, making sure they were within compliance for regulatory requirements and trying to fix the exhaustive error prone items that human resources were challenged 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. And then, on top of that, when we did our controls, created deficiencies when somebody didn't do their control appropriately and on time. And then secondly, wrapping around people, people still represents the largest risk to companies just simply because it's error prone and anytime you leave with manual efforts, you end up with excess configurations that weren't completed and maybe you had resource turnover, and then that resource didn't get appropriately instructions on how to terminate folks on a timely basis. So, we were all challenged with those. And in our process trying to get to HR as a master we had to target those fixes.

Paul Reyes: So, when we look at what we had the challenges that we had in our legacy environment. So, I'm sure a few of you are maybe still on a mainframe, but back then, in 2009, when we migrated over we were on the mainframe. And som we were provisioning RACF IDs back then, over to a batch job that then incorporated that into our Active Directory environment. And 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. And with that, that same process have either a manual batches or custom code jobs that somebody would execute and then anytime somebody left that 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 proven. They or not.

Paul Reyes: And so, 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 the roles and ended up with a lot more stuff than they needed. And then so the new person that came in ended up right off the bat having more access than they required. So, we always had a challenge with making sure that it was least privilege in our environment. So 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. They ended up not being able to see that change unless somebody told them that they had wrong access. Again, we wouldn't find it out until we add a control in there and says, "Hey, is this person supposed to be in these groups."

Paul Reyes: 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. When somebody left a group or 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, and of course as you look at when we terminate a user, we're still back to a mass termination email. So, HR would send out this mass termination email would either say, "Remove these people on this time, or remove them at a future timeframe." And we were in trusting that, one, the distribution list was accurate. Two, the people were trained in that distribution list. And 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 then transition their knowledge base over to the next person responsible.

Paul Reyes: So, 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. We had that for a bit. And then when we decided to go move that into with Okta, we had it in a for released model, and we've kind of just described this as there is 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 through up sub application provisioning. So, in our first release, we really just wanted to get WorkDay, being the master shipping that data over to Okta, and Okta provisioning and 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 were SSL enabled and thought that they could be pretty easily enabled into our environment to do single sign on. So, there was a group of lists of application 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 stirred is because we really had a challenge with our first time that we tried to release multi factor authentication with another partner, and it was really painful. 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 the plan.

Paul Reyes: As I said, and you probably just saw it, 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. In our last release was to then do server provisioning and de-provisioning into or sub applications. And so, we targeted these applications here, Salesforce, WorkDay, office 365, ServiceNow, Box, and then we also have Zscaler for perimeter protections, and more applications are being deployed as we go through in our further releases now. So, 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, then Okta, then directionally provisions that into Active Directory. Active Directory then shoots it over to Exchange On Prem, but Okta directly move that data into provisioning for Office 354 and all their other applications as we grow them. And that goes really well because it works to our process very quickly. The struggle that we had is we definitely should have put MFA up front.

Paul Reyes: We had several breaches throughout that first part, where when we started putting things in the cloud with single factor authentication, it challenges us tremendously. We had a lot of CSIRs, cybersecurity incident response plans going up because of the single sign on. And so multifactor should have been day one. So, as a lesson learned, I would also recommend it to anybody else when you go through this process, and enable into Okta, definitely start with MFA. The second piece is, we're still struggling with role based security, or as we use it, capability based security, making sure that you define the roles up front so that your downstream provisioning becomes very easy. And in that time, we didn't plan for all of them so only the new cloud enabled applications became easy. All the rest of, our legacy applications were real struggle. I'll talk to it a little bit more in a bit.

Paul Reyes: So, as we go through here our flow in which we drive this provisioning, is we went from WorkDay, to our Okta in environment, and in that assigning resources we provided birth rights. We provided birth rights to our common application like office 365, Box, and WorkPlace. So, we provisioned 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. 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. We should have defined all the roles and the different provisioning access rights that they should have had and marry those out with our Okta provisioning areas. 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 up front. We would have probably also simplify the process. We still have legacy batch jobs that we're trying to pull into sub applications and other custom codes that were pulling it, and we've probably should have just simplified the process and says 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.

Paul Reyes: The second piece is as we go through our mover, when we still went to the movers that worked fine for those that were auto provisioning to. So, 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, the error is human. When somebody gets an email that says this person switched a role, we're depending on that resource to de-provisioning them from that environment. And so, we wouldn't catch that until we have the controls that went through and says, "These people the right people to be in there." Or we've caught it within the audit. So, lesson learned. 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 scheduled leaving. And when those occurred, that worked really good from the applications that we have provisioning for. What we struggled with, with the areas where we had compliance up front. So, those that had to have a four hour turnaround, or a 12 hour turnaround for regulatory requirements such as, and we're in the generation space, so the NERC CIP, that was a struggle. So, we had to stop and go back and automate those functions and get them involved and get those rights connected up so that they could auto provision in those timeframes, and now they weren't great. They're automated and configured.

Paul Reyes: 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 expert for those applications to understand the rights of those apps and be able to map those up to an Okta provisioning role based security. So, I would probably suggest lesson learned. Make sure you know what your 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 Okta in groups.

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

Paul Reyes: Secondly consolidate access to a central control. All your sub applications, they want to manage their own user accounts, bring those interest 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. 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 up front, and not have to fight for them at the end at the end. That's my story. Hope you leverage it as much as we have. It's really good functionalities to automate these provisioning and we're always building and learning for new applications as we go along. I'm going to turn it over to Arvil for next view.

Arvil Nagpal: Cool. Thanks, Paul. 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 kind of what our capabilities are today. Paul gave you a great deep dive into how history energy has seen value from employing the product. Hopefully that was a little bit helpful to you guys as you plan out your own HR as a Master. Talk about where we're heading as a product and a set of capabilities, especially as it relates talk to Okta WorkFlows. 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 in the core Okta processes in helping to provide prescriptive paths to automate the joiner, mover and leaver flows. But as we've talked to more and more customers organizations want more flexibility.

Arvil Nagpal: We think about these customizations in sort of 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. Second, is timing, this is more of the when. For example, when an employee moves roles I'd like them to retain the access levels for their old role for a few weeks while they transition, and 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. And so, 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.

Arvil Nagpal: And so 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. We've got these products underlying them will be a set of platform services, which includes Okta WorkFlows. So, as we think about the future, the future really is off the WorkFlows, and what is Okta WorkFlows? Okta WorkFlows is an 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 it is today. For example, every flow starts with an event. So, 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 through the security channel, and then do actions in 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. And so as we think about these use cases they really primarily are oriented towards Lifecycle Management. 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 we'll be able to extend certain use cases. And 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.

Arvil Nagpal: I wanted to talk a little bit about how that transition will occur. This past year we've really been focused on improving scalability and performance of our top integrations, especially WorkDay. And then this year, 2020, we're really going to continue to focus on the speed of synchronization, especially for the largest enterprises. We're going to 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%, but we're also going to be making significant inroads towards this future WorkFlows vision. We'll be launching a beta 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. So, 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 end-to-end solution next year.

Arvil Nagpal: So, let's go into a little bit of the specific use cases. I mentioned two use cases up front. I want to really deep dive into how we're thinking about these specific use cases. So, the first one is resolving identity creation conflicts. So, a lot of times, especially in 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 username is taken. And so 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 user name, or another attribute. That conflict resolution logic can be built directly into WorkFlows to iterate, let's say, username 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 back to Okta, and that user will be successfully imported.

Arvil Nagpal: This is also really, really important for creating GUIDs. 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 is unique, and then finally, at the end of the flow, you can actually update the user profile in Okta. So, 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.

Arvil Nagpal: The second use case that I want to talk through is really around importing users from the Flat File. 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 to on a scheduled basis, bringing users. NTT has actually taken advantage of this with the first use case where we're importing contractors and employees from a Google Sheet. So, 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. And then for every user, maybe you want to notify their manager as well. So. 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.

Arvil Nagpal: The other use case might be M&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 and Okta. And so, while it doesn't include some critical capabilities like profile mastering or attribute level mastering, we think that WorkFlows can really take and make kind of connecting the Flat Files and these disjointed user populations much, much easier. I'm not going to hand it off to Ryan and we'll kind of go through a quick demos 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, DunderMifflin, has recently been acquired by Sabre. Sabre wants to provide all former DunderMifflin 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. 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.

Ryan Bradley: So, 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:00am pacific time. I want to read in a list of all DunderMifflin employees for 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'm going to get the associated attributes with that new user in Okta there, such as their first name, their last name, and their username and create a new Okta user with these attributes. 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 build airflow. So, I'll pause again here and highlight three important concepts and WorkFlows events, app actions, and functions.

Ryan Bradley: Events are what start your flow. This could be a schedule, as in our case, a call from another flow, or an event in October, are another application. App actions allow you to connect with and integrate to Okta and other applications such as Salesforce, Box GSuite, and more. Finally functions are tools within WorkFlows that allow you to control the execution of your flow and manipulate data. Let's start with the event that will start our flow. As I mentioned, we want to scheduled flow to start on Fridays at 9:00AM pacific time. Next, we want to read in all the user information from this Google Sheet that I showed you before. So, 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 it will read in all the user information from that Google Sheet. I'll specify my Google Sheet in the relevant tab and you can see the output is a list of rows, which are the users that I want to create in Okta, as well as all of the associated user data in the columns.

Ryan Bradley: Pausing here, let's save our flow so that we can actually test it out so I'll name it Import Users Parent Flow and I'm gonna 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, create a new user in Okta. To do this, I'm going to use a 4H loop in workflows. This allows me to call a child flow that I specify on each item in a list.

Ryan Bradley: So, I'll specify for each, and you can see I pass in a list, in this case, the users that I want to create an octet. 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 serve my flow is a call from another flow, so I'll specify a child flow, and I need to specify the inputs. From my parent flow I see that the input is the rows are the users to be imported, so 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, enabled 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. So, going back to my parent flow, before we test it again let's specify what the child flow is. Now I need to do one more thing which is specify the values from each item in the lists that are passed in.

Ryan Bradley: So, 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. And now we'll go into the child flow and take a look at our flow history to see that, yep, we had a bunch of successful executions of the child flow, one for each user in the Google Sheet, and one for each item in the list that I pass to the child flow. Looking at this specific information here, I can see that the child flow is passed just the user information, or just the item, from the list that I want to create a user for. So, what do I do next? Well, I've got this JSON object with all of my user information. Now I need to pluck 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.

Ryan Bradley: I need to get my first name, last name and other attributes. So, 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 passed through the child flow. And then I need to specify what values to grab, and 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.zero-first name, last name as columns, .1-last name, and so on and so forth. So, let's enter these in.

Ryan Bradley: Great, we specified all the attributes I need. 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. I can see that Kevin Malone is his appropriate first and last name, as well as username and email, and he's from the accounting department. So, 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, 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.

Ryan Bradley: 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. 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. So, first name goes to first name, last name to last name username to username, 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 it as soon as possible. Now, should be done with my flow. It should be ready to go. So 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 universal directory we can see that, yep, all of our friends from DunderMifflin, 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, Jo and Gabe, and he has access to all the applications that he needs as a member of the management group. So, 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 octave functionality like group rules, which can be used to drive app assignments. Hope you're as excited as I am.

Ryan Bradley: So, 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 skill, sorry. We're also exploring more how workflows can deeply address HR as a master of 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.

Ryan Bradley: Thank you for attending today's session on automating onboarding and off boarding from your HR system. We have a few other sessions at this year's octane that we think you'll enjoy. Hope you get a chance to check them out. Thanks and enjoy the rest of the conference