Okta Lifecycle Management Roadmap

George: Hi everyone. I like that intro, "Welcome to the future of Lifecycle Management." It's like you're in the future of Lifecycle Management right here. How's everyone's Oktane going? Good? Kind of end of the day. I wanted to do one thing, I haven't done this before but since it's a pretty spread out room. Let's all stand up, I feel like we're in the seventh inning stretch of a baseball game, you know what I mean? Let's all stand up and do one of these. Raise your arms in the air, maybe do one of these neck things. Deep breath. Okay, nice.

I think we're ready to go, I think we're ready to go. I'm feeling good. You guys feel better? Was that good? All right, okay. Thank you for coming. I love these sessions, I love talking about the Lifecycle Management product, the problems we solve, what's new, where we're going and I'm really excited on behalf of the product managers and the engineers who work so hard to build this product to share with you guys the future. Quickly legalese on forward looking statements, I'm going to be talking about the future, don't take me too seriously. And let's dig in. Todd, this morning, talked about identity being kind of the challenge of our generation and we're all in this room today because we envision a better future around identity management, around Lifecycle Management, quick day one access, fewer tasks and manual workloads, no more orphaned accounts or accounts that have been sitting here for 30 years that you don't know about. This future is what we all strive to get towards. Now, let's take our heads out of the clouds here for a second. Modernization is hard. You know, we all have what I'm calling identity debt. I'm not an IT practitioner by day but I build software, I work with engineering teams to build software and in software engineering we have this concept of technical debt. It's a similar thing, it's decisions you made five years ago that in present day are kind of like, "Oh, I wish we hadn't done that," and they're holding you back. And it's things in the Lifecycle Management space like aging technologies. You've got 20 different identity silos. You've got integration maintenance because your predecessor hired a PS company to build a custom, one-off integration and it's breaking every day. This is the identity debt that holds us back from that future. And this is the reality with Lifecycle Management that we're helping our customers break through. We're helping you break through it in three ways, we kind of have a three step program so to speak. The first is building a single source of truth for all of your identities, whether that's an employee, contractor, customer identity, we want to help you bring all those identities in one place so you have a single pane of glass and a single point of integration.

The next piece of the Lifecycle Management solution is once you have those identities in a single place, automate their lifecycle. Those onboarding and off boarding processes, how can you drive more automation around that lifecycle so that it's less manual work, more compliant, more secure? And finally, integrating all the things on top of identity, right? Whether that's provisioning or down-stream workflows. How do you connect all of your different business processes and workflows to those identities? So I'm going to talk through each of these over the course of this session. I'll do a couple quick demos. I'll talk about what's new, what's coming, starting with single source of truth. So what do I mean by single source of truth? Well, we're all coming from different places. For some of you, you might be building an identity system for the first time, most of you have a number of different existing directories you're trying to bring together. So this might be as simple as connect AD to Okta, and you've got an HR system integration behind that. Or maybe it's multiple directories. You've acquired companies over time, you've consolidated business units. Bringing those together in to a single cloud based directory in Okta. And maybe you've had the opportunity for your company to acquire new HRIS, and that becomes a great opportunity to directly master these users in the cloud. Having a kind of joiner mover lever process through Okta and still provisioning out to that AD directory or LDAP directory that you need to keep around. And for those external identities, maybe these identities are an LDAP and you're synchronizing that Okta, but maybe you've taken the opportunity to have those identities natively in Okta. So, whatever your setup, whatever your situation, whatever your maturity level, Okta is helping you solve these problems. Our vision for the future, here, is three investment areas. The first is connecting to any system of record. HR, on print, on the cloud, RingCentral for your phone numbers, legacy directories, how can we connect to anything to really build that single source of truth? The second is simplifying identity synchronization. As you guys all knows, these are complex processes, it's not just about connectors. How do we make that simple and out of the box for you? And finally, how do we build and deliver a cloud directory that can serve as the future for all of your identities. Maybe you're not ready to have those natively in Okta quite yet but knowing that you're on a journey and investing in a platform where that can be the case in the future. So, to support that story of connecting to everything, to any system of record, as you all know we support deep integrations with AD and LDAP and systems of record like HR, cloud systems of record like RingCentral, SuccessFactors, Salesforce, and we deliver these all out of the box in our Okta integration network. We really can connect to anything and we provide a couple different ways to do that. We have a comprehensive set of user management API's that if you're so inclined you can connect to, to write crud users in the directory. We also have a flexible on premise agent that can get behind the firewall and connect to your database or legacy system of record. And on that latter point, we're making some investments in our on premise agent. We're going to support an interface to pick up a CSV file, whether that's behind the firewall or in the cloud really is the catch all for connecting to any system of record, any HR system, get that connected in to Okta to drive user creations and updates. This is being worked on as we speak and we'll be excited to announce a beta in the coming months.

And I mentioned, identity sync isn't just about integrations. It's not just about connecting to these different systems, it's data transformation, mappings, it's mastering rules for who owns what attributes. It's getting matching and linking right when you have many systems of record collapsing down in to a single source of truth. This is something Okta does very well out of the box. We have mappings, we have matching rules, and looking forward as our larger and larger customers trust Lifecycle Management to build that single source of truth, we have customers who have a hundred different business units and directories they're synchronizing in to Okta. We're investing in continuing to make this easy for large scale identity so we'll have some import in job management functionalities like clearing your import queue, a simple but much requested feature. Supporting more advanced matching rules. You might have a globally unique identifier, you may not, but that you want to use as your linking logic, and so being able to match on all those imports on not just first name, last name, username, email, but any attribute is going to be a big important investment for us, to help you build that system of record. And this last one is one that comes up a lot, which is I have two George Kwans coming from different directories, from different parts of the world and I'm trusting Okta to generate a unique identifier or login. How can they do that in an automated way? What we envision here is supporting a set of rules for automatically generating unique usernames to avoid those conflicts, and so that will be another enhancement that we add to this synchronization engine. So, I've talked a lot about synchronization and systems of record and connecting them, but what about those other onboarding workflows for your external users? For a contractor or partner, maybe they're not synchronized from LDAP, maybe you want to manage that onboarding workflow in Okta. Whether that's an admin flow or even a self-service registration flow. So, I'm happy to announce that as of now, self-service registration is now EA, which means you can go home today, enable this in your production orgs, and enable a self-service registration experience for any of your identities. Now this might be your external users, internal users, and I want to take the opportunity to demo this. I know it's been shown in a couple sessions but let's switch over here to my Okta instant and I'll give you a quick tour of how self-service registration works. So, if we could switch over, I don't know if that's showing. Any luck? Can exit full screen. Now? Okay. Let me try exiting Presenter, is that better? Okay, cool. So what we've got here is a simple set of configuration for enabling self-service registration in your organization. You edit this policy, you enable, you specify a group that your users will be put in to after registration, and this group also serves a purpose of defining the password policy that will be enforced when your users register. So I've picked this group, partner registrants, and if I go over to my password policy you'll see I've created a policy for those registrants where I'm requiring just a lower case letter, upper case letter, eight characters for a password.

So, using our out of the box password policy that will be used in your registration experience, I then have a simple way to grab attributes that are configured in my org and UD and have those show up in my registration form. So I'm going to require email, password, first name, last name, I could easily add additional fields here but I'll keep it pretty light. And then the last step is this check box of whether I want my users to have to verify their email address before they're activated in an active user Okta. So I've got this all setup, I'll show kind of the before which is my Okta org here. The typical sign in, log in experience that you've come to know. No registration. So I come back to here, and I have to do one last step which is enable registration in that sign in widget. I'm leveraging some new customization features, allowing me to customize that sign in widget directly from the admin UI. I enabled that feature and now if I go back to my login in experience and refresh I now have this sign up link. So, my users are now not only able to authenticate but I have an out of the box registration experience. This registration experience is leveraging that password policy, so as I type a password here it's telling the user what if they've met those requirements, so all fully integrated. If I add additional fields they'll show up here as a live site. So, pretty cool. I think, as I jump back to the deck, this is really the first step for us and we're excited to announce this as being EA for your external identities. What's next? Well, for secure applications and for partner access to external user access, you don't necessarily want the whole world to be able to register for your org. So, we're working on a few capabilities to secure or add additional steps to that registration experience. So the first is a simple email white list. Only allow people form a certain domain or company to register, maybe filter out personal email addresses. The second is thinking about how we add approvals to registration. And the first step will be to stage users and require manual intervention. We'll be looking at how we can leverage maybe some of the approval workflows we use for application requests in this flow, that way you can drive kind of an approval process during registration.

And then extensibility. So, we have cases where customers have said, "I'd like people to register and before we validate their registration, we want to check whether their partner ID is in Salesforce, and do a call out to that Salesforce system." Extensibility is going to make that possible, if you're willing to write a little bit of code. All of this, the synchronization, registration, is all backed by a universal directory and as I mentioned, this is a cloud based directory that can support any identity. It has a flexible schema, users and groups, API surface area. We've added a few things, we've taken off the restriction to have first name and last name required. We're supporting more flexible usernames that aren't necessarily an email type. A numerated values, you could specify a role as three or four numerated values and have that show up in a pick list when you're setting that attribute. We support relationships between two users in UD and an LDAP interface which I don't go in to depth here, it'll be covered in other sessions, but allowing you to connect applications that speak LDAP to UD.  And the reason I mention this is with registration, with universal directory, with LDAP interface, you can really imagine-

George: Universal Directory with LDAP interface, you can really imagine how Okta becomes your first class directory for external users; how you can start to retire LDAP for that extended enterprise and start to move forward on a more modern solution. So, we're really excited about that. Okay, so transitioning. Single source of truth, this is your foundation. That's your starting point on top of which your modernization endeavors will start. The next step is with those identities in Okta, how do you automate the user lifecycle, that joiner, mover, leaver process for any identity? That process may look something like this if you squint your eyes, and everyone's process is probably a little bit different, but you establish an identity, it's onboarded and assigned resources. There's mover processes, there's offboarding processes. So, how do we help you automate more of this process? Well, with step one of onboarding the user and getting them set up in the right resources. Well, first I'll mention kind of the key components that are automating that lifecycle, there are three. There's how do you take identity context, automations, and human workflows and marry those together to create a more fluid automated user lifecycle? These are the three areas we think about as we build out our functionality. As I was saying, the first step here to driving that automated lifecycle is getting your users set up with the right initial set of resources. So, our first investment here a few years ago was group membership rules. This automates the process of getting your users into groups based on their attributes or other group memberships. Groups are really important. They're powerful because they decide what applications you have access to, they dictate what policies apply to you as a user. They may even put you into AD groups with group push. So, it's a very powerful concept and is a great way to get your users started inside your directory. We've added support for multiple groups in a rule. Now, this is available now to help you reduce the number of rules that you're maintaining. If you have the same condition for multiple groups, this'll definitely be your friend. We're looking at lifting some of our group rules limits for some of you kind of heavy power users of group rules. So, we're making a lot of progress here. As part of that onboarding process, we support self-service workflows for requesting application access. Not everything can be defined in a rule out of the gate, and so being able to extend self-service to your users to request things is really powerful. We've made some UX improvements here to consolidate the self-service experience. We've added notes so that requesters can see a custom note before they request an application.  The future here is really going to be driven by the feedback from all of you. We've had a lot of great interest in this feature over the years, and we've heard things like, "I need to be able to scope requests. I need to be able to have my users request groups, other things beyond applications. I need managers to be able to approve." These are all the types of things that our product team is considering on the road map. Reach out to us and let us know which of these things are most important to you, and we're building out the road map this year and next. So, I covered a bit of that onboarding, steps one and two, right. You've got your users set up, they're in their groups and apps and policies. What about these mover and offboarding scenarios? Well, for employees, it's pretty simple, and maybe even your contractors.  You connect their lifecycle to an HRIS state, right. You've got workday, you've got success factors. Maybe you have an attribute in that CSV file. But you link the user's state in HR to Okta to drive that offboarding process, and we do that today out of the box. You can suspend or deactivate a user when they're terminated in an HR system. But for those extended enterprise users, or if you have a use case where you've got 30 lifecycle states in HR and you want to more flexibly map that into Okta ... I'm really excited about this functionality, which is our evolution of rules that we're calling triggers and actions. Triggers and actions is an automation engine that is going to drive a lot more automation across that lifecycle. 

Some examples. You've got external users who have been inactive for 90 days, and you want to suspend those accounts. Your solution to this today is probably a quarterly meeting to pull down a spreadsheet, look at inactivity, and go through your governance audit process. With triggers and actions, you can set up a trigger to say when users are inactive for 90 days, suspend account. One step better, you can create another trigger and action to say when users are inactive for 80 days, why don't you notify them that they're about to be suspended? So, these are just some of the use cases that we're going to be able to support with triggers and actions. How many people were at the session earlier today where Encore was demoing this feature? Did we get most of the people in the room? Okay. 

I'm going to quickly go and show this to the folks that weren't at that session, just to show you kind of the power of triggers and actions. So, I'm going to jump back over to my browser here. Under lifecycle automation, we have these automation rules, and I have two set up here already today. Let's see, maybe I'll make that even bigger. The first is that rule that I just mentioned, inactivity-based suspension. What I have here is the ability to scope this rule to people within a group. Right now I have this set to everyone. I'm also able to define the schedule on which this is evaluated and checked. I've got every day at 11:59 p.m., and I have my condition here of users inactive for 90 days. On the right, I can add a simple action of suspending those users. So, again, no more spreadsheets, no more manual review, an automated process to drive that user lifecycle. I mentioned no one likes to get suspended by surprise, so I have another rule here. Same schedule, maybe at 7:45 in the morning when people are checking their email. When they're inactive for 83 days, seven days before that suspension, I can send them a message saying, "Your account's about to be suspended if you don't log in." This is really just the beginning. I'm hoping you guys are seeing the power of this framework. The next step for us is to continue adding a catalog of triggers and actions, including things like ... Let's bring in that raw state from HR and use that as a trigger, whether you're terminated, on leave, on parent leave, et cetera. Use that as a way to drive any number of actions on the right. Not only suspension of accounts, but things like move user to group, which will push it down to AD and put them into a certain policy. Or, remove them from a group to suspend their access to certain specific applications. The world is our oyster here. The product management team is looking for your feedback. How do you want to see yourself using triggers and actions to automate more of that lifecycle? We anticipate a beta in the coming months and getting to EAG later this year. So, we're really excited about this one. 

I'd like to end on this third pillar, so you've got all your identities in a single source of truth. You've got your employee, contractor, customer, partner identities on an automated lifecycle with rules and HR mappings and triggers and actions. What's the next step? Well, what about all the downstream action that happens off of that lifecycle? Things like provisioning accounts, things like establishing or onboarding additional resources during the onboarding process. For us, this is where connecting everything is really important, off of identity. You've got Okta, you've got all these identities, you've got these events. As you all know, we have an Okta integration network that does a really good job of integrating the key systems tied to identity, so those systems of record, applications for provisioning, and even other best of breed platforms like your ITSM platforms like ServiceNow for driving more workflow and tasks.  Or, maybe SailPoint. Maybe you have a governance process on top of a really sensitive application and you want the review of those entitlements to happen in SailPoint. We have that fully out of the box, Okta Integration Network, to really complete those end-to-end use cases. But we also support open protocols like LDAP and SCIM. I'll talk a little bit about the success that we're seeing with Okta driving forward the SCIM standard with provisioning. We also support a set of APIs. If you're willing to write a little code, read or develop our dot com documentation, you can develop interesting integrations on top our events and APIs.  So, our vision here, standards-based provisioning. Use our great, out of the box connectors, but also connect to any app with SCIM. Best of breed integrations around the identity lifecycle, whether that's ITSM, governance, other systems of record, and developer extensibility and APIs, always giving you the choice and surface area to come up with your own custom integration requirements. The OIN is growing. This is really exciting. We now have 130 provisioning integrations in the OIN. 53% of these integrations were built by our ISV partners. So, I'd say it's safe to say that Okta's transition from this world that Todd talked about of Okta building integrations to now the ecosystem seeing the value of building provisioning on top of SCIM and getting that in the catalog. As a result, we are adding upwards of six integrations per month to the catalog, so some really exciting acceleration and breadth here for all of you to take advantage of. 

I'll mention on this ... Go to your admin UI, go into the catalog, filter an app sets we're provisioning. You'll see all the apps there. Follow our release notes. We mention every month new integrations that are being released. Keep a close eye on that to find what you can take advantage of. This isn't just about breadth, it's about breadth and depth. So, provisioning for Okta means crud of users, it means scheme of discovery, it means license management on offboarding, and group synchronization. Being able to master core IT managed groups in Okta and have that pushed out to all your systems like AD and LDAP, maybe your productivity and collaboration apps.  I mentioned our investment in SCIM, and this is coming to fruition in a couple ways. One, our ISV partners are building SCIM-compliant interfaces. We're also exposing in the admin UI a wizard. You're all familiar with the SAML or SWA wizard to create SSO integrations. We're now adding support for SCIM. So, if you have an internal application, you want to support SCIM, you can create an instance of that in Okta, turn on SCIM, configure the connections, and now you're provisioning to your SCIM-compliant apps. Pretty cool, so no excuse not to connect everything to Okta. We've got the integration network, and now SCIM wizard. 

I talked a little bit about developer extensibility and those integration points in our APIs. Webhooks has been something that has been asked for quite a long time. We have an events API in Okta that generates events for everything happening in Okta. User was created, user was suspended, user was added to group. Customers have been pulling that log and creating integration scenarios off of that. One step better is to allow you to subscribe to specific evens. Subscribe to group membership changes or user creation changes. We'll post to your server, your backend so that you can complete an integration scenario like creating a ticket in ServiceNow, or kicking off an email in your favorite email service.  So, this requires you to write some code, but now you have a way to receive real time notifications from Okta on top of the events that matter for your use case. Pretty exciting stuff. This is in development right now. Extensibility, I mentioned this a bit earlier around registration. The out of box approval workflow, the domain white listing, these are great out of the box features. But for your external user use case, you might need to do a more complex check. So, user registers, I mentioned their partner ID. Before that registration is complete, inset a break point in the Okta registration flow, be able to call out to your CRM system or wherever you keep your partner identities, and do that validation that they're indeed a partner, and come back and complete the flow. 

So, these break points, this extensibility, not just on top of Okta events, but in the middle of core identity flows like registration and authentication are going to give the developers out there, your teams the upmost flexibility to use our out of the box offering, plus your custom flows and logic. Great, so we've kind of reached the end here. I've talked about the journey that you're all on to reach for that future of modernized IT, getting past that identity debt and working past kind of the things holding you back in that three-step process. First, developing a single source of truth for your identities. Then, automating the user lifecycle around those identities, and finally, connecting all those downstream workflows with Okta and those identities. Doing that for your employee, contractor, partner, customer, identities. I want to close by kind of just mentioning your journey and your adoption of lifecycle management is going to be different from the person next ... 

George: Journey in your adoption of lifecycle management is going to be different from the person next to you. We have customers who are completely green field, 50 person organization that needs Ideny for the first time who's adding users in our admin UI. We have people who have so much directory sprawl that their first step with Okta is to consolidate those Idenys and create a single source of truth. We have people who come to lifecycle management because they bought Work Day or they bought Success Factors and they don't want to go through the process of integrating that with their Legacy System and maintaining that HR integration for another ten years. And so, they adopt lifecycle management to drive that process. Other use cases like your external users and actually this is becoming a popular path for people to adopt Okta, which is I have my external users in universal directory, they're less tied to my identity debt, let's move those users to the cloud. So, whatever your use case, start somewhere and know that you can grow with Okta across all your different identities. Lot of great stuff I talked about in GA, EA, Beta, things that are real, not hand wavy coming at some point. We've got GA features. We've got self-service registration EA, multiple groups for group rules, requester notes, new provisioning integrations. We're going to be announcing a Beta of riggers and actions soon that exciting automation engine that I spoke of. So, go back home, soak it in, talk to your CSN, and try this new functionality and then of course reach back out to the product team, we'd love to hear what you think and your thoughts on the future for lifecycle management. So, with that I'll end and probably take some questions. Anyone in the room, don't be shy. Okay, yeah right here.

Speaker 1: Thanks very much George.

George: Yes.

Speaker 1: My question is about Salesforce.

George: Okay.

Speaker 1: Okay, so you talked about crud.

George: Yep, they're 130 applications that are directly. I've got to remember the specifics of sales force.

Speaker 1: I must be a corner case, sales force is so small.

George: Yeah.

Speaker 1: No one else here uses it, do you? So, we tried implementing it and as we had people on board to implement it with us, we found that Okta only provisions new hires.

George: Mm-hmm (affirmative)

Speaker 1: It does not provision updates and terms. And I look at the ideas and try and work within the ideas framework and there's been an ability to freeze sales force users ID out there since March 16.

George: And are you talking about using sales force as a system of record or for provisioning to sales force?

Speaker 1: I'm just provisioning from Okta's sales force.

George: Yep.

Speaker 1: And then there's been a sales force provision bypass role mapping, which prevents the profile changes from being feed to sales force since September 2016.

George: Got it. Got it.

Speaker 1: I've heard nothing about them.

George: Yeah.

Speaker 1: Any news?

George: Sounds like we should talk after this conference and figure out how to solve that. We'll talk. Come join me up here afterwards. I'd love to talk about it.

Any other questions? Yeah.

Speaker 2: Hi, on the EA, you showed that there was self-service application, I guess for employees to opt into applications. One of the things that I've seen as sort of a pin point is if employees can go to their Okta dashboard to do an IDP push into a given application, they can only see the applications they're already authorized for and often this results in employees not realizing we've already subscribed to a given vendor and their team or their group just doesn't have access into that vendor. So, they don't see it in their Okta dashboard.

George: They haven't been assigned the application, is that what you're saying?

Speaker 2: Mm-hmm (affirmative) That's right.

George: Okay.

Speaker 2: So, does this tool help where I can essentially say here's the things where you're already authorized to get into and then here's a bunch more that you could request.

George: Yeah.

Speaker 2: And essentially give them this directory of here's the vendors we've already signed with, we're just maybe we're paying per seat so we haven't-

George: Yeah, yeah exactly. So-

Speaker 2: Authorized you personally yet and aide in that discovery for employees to find the services that we've already signed for that will help them in their job.

George: Yep. So, let me take a stab at that and then if we want to double click, we can come talk after. So, you're exactly right. There's applications in your organization that everyone has. Email, collaboration, etc. That you can pre provision using groups or rules or assign to everybody, right? You have other applications that might be line of business specific or based on your role. You could do that through rules if you know that business logic or you can make it available for self-service and you can decide in the admin UI which applications to enable for self-service and then your users can request those apps and if necessary, go through approval.

We even have customers who turn off approvals and they just want to make everything self-service, so there's a little bit of friction to do you really need this and they'll add a note saying this is costing your IT team a 100 dollars a month. Are you sure you need this? So, all of those different scenarios are possible. Yep.

Yeah, in the back there in the middle.

Speaker 3: Thank you, great session. Do you ever think about group life cycles. So, I'm talking about when you create a group, putting an expiration date if the group is for a project that's six months, do you think about groups are empty? Giving them an expiration date or automatic delete, so the system Okta itself doesn’t delete the different groups out there.

George: 60,000 groups.

Speaker 3: Having an owner for the group and if the owner leaves the company, the group is orphaned.

George: Yeah.

Speaker 3: Do you think about all of these?

George: Yeah, we think about it a couple of ways. So, the first is that groups as first class objects might eventually have profiles and metadata associated with them. To your point, lifetimes, owners, etc. I think the first step for us is we've talked about how triggers and actions can drive group membership changes, those rules, based on whatever your input or your business logic is for when that group membership should expire, being able to configure that in rules. We talked about supporting self-service and approvals through groups, but I hear what you're saying. We have suspension on user identities, we do not yet have that on groups. But there are some ways you can automate the memberships over time.

Any others? We've got a few more minutes. No, okay yeah, up here. Our friends from APAC.

Speaker 4: Hi George.

George: Yes, hi.

Speaker 4: Great session. I've got a couple of questions. The first one is around the SCIM framework.

George: Yeah.

Speaker 4: So, does Okta purely relies on SCIM framework for customs connectors, custom integrations.

George: Mm-hmm (affirmative)

Speaker 4: Is that the only available road map for custom connectors? Is there any plan to introduce any other than SCIM?

George: Yeah, I talked about a few things. So, the first is SCIM. SCIM, two dot oh, crud. If you have a SCIM compliant interface, you're good to go. We also talked about our on-premise agent, right? And we're bringing that back up, investing in that. First, using that as a connector to system of records, so more in the import side. But OPP is something you can use provision on-premise applications behind the firewall. We'll be looking at how we make that development interface a little bit nicer, right now it's like a SCIM 1 interface, so we know about that. The third piece I mentioned is our API's and web hooks, right? So, if you think of SCIM as essential a scheme and a set of events, we'll support on top of any of that in Okta, group user created, added to group, etc. instead of events. That could drive a downstream work flow or integration. You might connect that into an integration platform that you've already invested in to drive further integration. So, yes there are a number of ways beyond SCIM to drive provisioning and downstream workflow, absolutely.

Speaker 4: Thank you, because we have a lot of limitations to SCIM, especially around group management of this provisioning-

George: Absolutely.

Speaker 4: And group membership management.

George: Yeah. We think of SCIM as kind of an 80/20 standard, right? It's not going to be there for your deep integration requirements and so it's good for that and our other interfaces are good for those more complex scenarios.

Speaker 4: Okay and the second question is around group push.

George: Okay.

Speaker 4: Are there any announcements?

George: Yeah.

Speaker 4: For group push, other than multi groups-

George: Yeah.

Speaker 4: It's mainly around groups of master directories and target-

George: Yeah.

Speaker 4: But Okta manages their memberships and which at the moment isn't possible.

George: Yeah, yeah, so- 

Speaker 4: You have to go to the admins route or have some sort of word cut out using a string array- attributed in the user profile?

George: Okay, I'm not sure about that specific work around or if I know what you're talking about, but in general with group push, we've done a lot of work recently over the last six months to improve how we do group push, the main enhancement is with a prior generations of group push, we mainly supported groups in Okta getting created in a downstream application. And from a deployment standpoint that's challenging, because you have a lot of existing groups in your apps, your directory, etc. that you want Okta to take over in terms of management. So, what we've done is enhance group push for some of our top integrations and we're filling out support for this. So, for AD, G Suite, Box, we're working on service now in Slack to be able to say I'll import groups from Box, Slack, AD, so that Okta knows about them. I'll then allow an interface for you to take over management of specific groups. 

Now, kind of the next step is there's some details in how we update group memberships. Do you want that to be a master, etc.? Those are some finer grain details that we'll look into, but that linking capability, that take over capability is really the big enhancement that is now GA across a few of those integrations that I mentioned and we're rolling that out to others.

Yeah, great.

Speaker 4: Just one more, last question. 

George: One more, hold on. Before you ask you're third, I don't know. That's like-

George: Anyone else in the audience have a question before we run out of time? Okay, yeah. One up here. We'll come back to you if there's time. Yep. Three questions, man.

Speaker 5: Well, I'll just keep it with one.

George: Okay, good.

Speaker 5: The CSVs have certain limitations based on imports for the general was just mentioning, arrays.

George: Mm-hmm (affirmative)

Speaker 5: The enumerated feature is really good, but we as a partner are running into the problem that arrays are not going to be imported from CSVs.

George: Yeah.

Speaker 5: Especially, if you're saying we're doing automations on them-

George: Yeah.

Speaker 5: You want to have those in there as well.

George: Yeah, for sure. Yeah, with comma separated files, arrays are kind of challenging. We're looking at supporting other delimiters and then at that time, being able to start being able to parse out array data. So, not out of the question. Not supported out of the gate as you mention. For people who have those advancement requirements, often they use our user's API to create users with more advanced data types. Like arrays, if you've got additional validation, or enumerative values, etc. So, that's kind of where we are today, but there's ways to work around that. Cool. I think I'm out of time. I think ... but come here if you have additional questions. Chat with me and I look forward to interacting with all of you guys the rest of Okta and have a good rest of the day. Thank you.