Managing Unconventional Lifecycles Like a Rockstar

Speaker 1:  With that I'd like to introduce Amy Kim. Amy is the senior product manager at Okta for lifecycle management. She has over 10 years of product management experience ranging from cloud services to mobile apps like Skype and Microsoft. Outside of work, she's a private pilot, restaurateur and a oenophile. Amy has a BS in computer science from Carnegie Mellon University. 

Welcome Amy. 

Amy Kim:  Whoa, is this working ... Oh microphone's working. 

Hi guys good morning. I'm going to talk about 'Managing Unconventional Lifecycles Like a Rockstar'. I was telling Shelly earlier, rockstar sounds a little bit funny because I don't know if rockstars are particularly good at managing unconventional lifecycles. Let's do 'Manage Unconventional Lifecycles Better Than a Rockstar', as the title of my session. 

Before we talk about unconventional lifecycles, this is a forward looking statement. You don't have to read it all right now, but I'm going to talk about a lot of things that are on our team's roadmap, which means I have to have this CYA statement here saying, "This is not all arriving tomorrow. Not all of this stuff is in production right now." There you go. 

In order to talk about unconventional lifecycles I first want to talk about conventional lifecycles. What's a conventional lifecycle? This is something that, I think, most people here are probably very familiar with. It is a typical full-time employee that you manage through Okta. 

Does anyone, these all sound familiar to you, Workday, BambooHR, Active Directory? Yeah. 

A lot of your full-time employees usually are stored in what I call, these types of master systems. Sometimes it's HR, sometimes it's Active Directory. One feature that I'll talk about that lot of customers use today to manage their full-time employees will be HR as a master. 

Let's take Workday as an example, which is a very popular HR software. Let's say your full-time employee, you know they're going to start. They get added in Workday. When they become activated in workday, using HR as a master, this employee will get automatically pushed into Okta, their account will be created in Okta and thus begins their lifecycle in Okta. 

When they start they normally get what we call birthright apps. These are apps that everyone in the organization would get. They get access to some of those things but you can also use features like group rules, which based on the attribute of the employee will place the employee into the correct group that has access to various types of apps. 

Let's take, in this example, this employee is going to be in the sales team. Using group rules, and keying off of the fact that their department is the sales team, they'll get access to Salesforce, DocuSign, Concur and potentially a bunch of other apps. 

Taking this employee again, let's say this employee moves from the sales team to the engineering department. Using group rules we'll key off of the user's department attribute again. As it changes from sales team and goes to engineering, they may lose access to certain applications but they'll gain access to some other applications that are necessary for the engineering team. 

Now, at some point this employee will leave the organization and they become deactivated in Workday. Again, HR as a master comes in play here and they'll automatically, their apps will get de-provisioned, and the employees Okta account will get deactivated. 

This is, I wouldn't say, pretty standard but, this is what a lot of our customers use today to manage their lifecycles. 

Let's talk about some other types. 

Contractors. I think this is, when it comes to different types of users, the one that I hear the most. How many of you have contractors in your organization? Yeah, see. Ton of people here. 

What are some challenges that you face today for contractors? For one, a lot of times they're stored in a separate system float from employees. Taking the example earlier, your full-time employees may be in Workday, but one, it's expensive to get Workday license for every single person. Given that a contractor may not need all the different functionalities of Workday, you might not want to give them a license in Workday. 

Another thing is, some tools that I've heard our customers use. One is ADP, because everyone gets paid. Sometimes contractors are in EDP. Another popular tool I've heard is Fieldglass, Then, many times, and this is actually, probably the most popular ... Popular is maybe not the right word but most common is they're not in any system. Yeah, see. Nodding some heads there. 

The second challenge is, contractors need limited access to resources. A lot of customers, a lot of you potentially, that are AD mastered in your organization, well for contractors you might not want to add them to AD, which opens them up to all sorts of resources in your organizations that are not required for a contractor. 

Then, lastly, contractors, they don't always go through HR, they don't always go through IT, they are done by various employees inside the organization that need contractors for a short period of time. Their hiring and departure doesn't get communicated to all the other parts of the organization. 

One way to address this is, we have some customers that use this configuration is using our API's as a master. It's very similar to the full-time employee scenario. I mentioned earlier that Fieldglass is a very popular tool amongst our customers for vendor management. An employee or contractor will get added to Fieldglass. They'll get using our APIs, get pushed into Okta. This is very similarly, when the contractor gets removed from Fieldglass their Okta account will get cycled out of Okta. 

But, not a lot of you nodded your heads when is said, contractors are usually not in any other system. How do you handle those cases? 

Scheduled Suspension. That, you guys heard Todd mention that in the keynote earlier. This is a new feature that is currently in Beta. Went into Beta about couple of weeks ago. Using Scheduled Suspension, you can schedule a suspension date for a specific contractor when you're onboarding the contractor. A lot of contractors come with a contract end date. In this case you can put a date in Okta for that contractor so that they'll be suspended on this date. 

Maybe you have some other things besides removing the contractor's Okta access. Maybe you have to get some equipment from them, there's other things that IT has to take care of, in order to off-board contractors. In that case you can have some notification related to the suspension. This kind of notification can be used, not just for contractors but even your full-time employees. You might want to be notified before they have to be suspended. 

Everyone's favorite. Let's go through a bit of a demo. 

I'll go into 'My Org' here. Go into 'People'. Take this user Chad. Go into his profile. Enable suspension here. Oh oh. Timezone CDT. How do I ... No. Today, right now it's showing ... It's not 1:05 right now. Don't trip. The time zone on this computer seems to be set at a different time but, let's set Chad to expire in two minutes. All right. Now, I scheduled this user to be expired and just for confirmation, I can go here. That shows next 30 days of upcoming suspensions and see that Chad is supposed to expire today. It's 1:06 right now. I'll give it another minute. 

What else can I show you while we wait for Chad?

For those of you that might be wondering, well, I can't go, I don't have time to go in, click, click, click, one by one. You can also create a CSV like this. Here we have suspension date and suspension time. You can bulk upload suspension dates for lots of users in your organization. If you have, 30 contractors that all started one day, this might be how you create user accounts for them. 

Now. Oh still 1:06. I guess Chat is going to stick around for a while, for another minute. Before we go on to Chad, let's look at what we can do for notification. 

This one is currently in development. If you see little monkey things here, we're going to fix it don't worry. We'll have a policy for conoractors. The policy description will say, 'Notify IT of contractor suspension.' This will apply to notifying about contractors. We'll create a policy like this. We'll be able to notify one day before suspension and here we'll notify the IT team. 

Now, for your contractors, the IT team will receive email saying these list of contractors are going to be suspended in the next day. Going back, let's make sure ... Ta-da. Chad as scheduled has been suspended. Cool. 

That's Scheduled Suspension. You can all sign up for Beta here and give us feedback about how it works, whether it fits your use case or not. 

Now let's talk about a different type of employee. Contingent workers. When I say contingent workers here, I'm talking about especially like, if you're a retail based organization, you have, a lot of part-timers that come and go. There's high turnover here. What are some challenges for managing contingent workers. For one, their end dates are unknown. A lot of the come without a contract that says this is how long you're working for and as I talked ... Earlier in my bio I said I'm a restaurateur. As someone who has a restaurant I can tell you sometimes contingent works quit by just not showing up on a day. 

Managers also rarely take steps to remove access for these contingent workers. Part of it is because removing access to resources is maybe not the priority for the manager. Lot of times these managers for contingent workers are not sitting in front of a computer every single day. That's not the top of mind thing for them. Also, with these contingent workers, there's just a lot of high turnover and that can be a big burden even if managers go and tell the IT team of every single contingent worker that comes into the organization, and leaves the organization, it's a lot of burden for a small IT team. 

I'll talk about customers and partners. Does anyone here have customer portals, partner portals for your organization? Yeah. What are some challenges associated with customers and partners?

Well, very similarly as earlier, there's this lack of a master system for customers and partners. Know that a lot of customer and partner portals are built on top of Okta, which means, sometimes Okta could be the only source you have for all your customers and partners. Sometimes access is not always needed for a customer and partners.

Let's say you have all your customers and partners in Salesforce, and you see on there that they are a current customer or a current partner. That doesn't always mean that they need access to these resources. Current partner, or a customer may only need access for two weeks, but they will be persistent in Salesforce as a customer. That's not really always a good source of master. 

Then, a lot of customers, especially in this B2B customer relationship and partners have sponsors in your organization, usually it's an employee. Those sponsors don't always take steps to remove access for these customers and partners because they all have lots of customers and partners they need to deal with. That's not the first thing that they're going to go and do when they are no longer in touch with the customer or the partner. 

In order to address some of these types, I'll talk about activity based lifecycle. Here you can see, this is like your common customer portal, or partner portal use case. When, a user gets created in the Okta through the portal registration possibly as you heard today, we are now supporting self-service registration. If you do self-service registration here and get a customer or a partner into Okta, at some point they may stop accessing Okta because the information they needed for a particular project is no longer needed for them. In that case, ideally you want to take them out of Okta because they no longer need access to resources. 

To show that, let's go back to an earlier demo. 

You would do something like this with our notification policy where you add a policy for customers. Notify of inactive customers. That's relevant to the customer's group. With these customer you might want to notify, let's see, 85 days after last log in. Maybe you want to notify those customers and tell them, "Hey, you haven't logged in for 85 days. Your account is going to be suspended." You create a rule like this. Then, you might want to add another rule that says, '90 days after last log in'. If that customer has been inactive for 90 days to let the IT team know in that case. 

If you create a policy like this ... All right, well that's going to chug along there. If you create a policy like that then you'll be able to get notified for all the inactive users. When that email comes with the list of users that have been inactive, you can take appropriate actions to suspend them. Then you'll also give the chance to the customer to log in so that they can maintain access to Okta and various resources given through Okta. 

Going a little bit further into the roadmap now. As we develop more in this area, you can imagine, we'll add more lifecycle changes. There can be deactivation happening, there can be deletion happening based on activity. We're also working on a way to have user to user relationship. which will enable you to send notification to their manager, let's say or their sponsor. 

I know that maybe getting rid of their entire Okta account for an inactive user, that seems a little bit heavy handed. Then we can introduce a way to remove access just to a specific app based on inactivity. Especially like, a lot of expensive apps, you may want to remove access for if no one's using them. This can be applicable not just for unconventional user types but also your full-time employees as well. 

Let's talk about 'Manager, Sponsor-Certified Lifecycles'. In that contingent worker scenario, let's say they have a manager, or a sponsor who understands when a user is an active user in the organization, when that contingent worker is still working in the organization. For those users what would we do? 

We would do this thing called re-certification. Every 90 days you can send and email to the manager and say, "Hey, this user, the last time this contingent worker was certified was 90 days ago. You need to click here in this email to extend the contingent worker's access for another 90 days." If that manager doesn't reply to that email or click on the link that's in the email, then you would suspend or deactivate their account in Okta. 

You see here you can review a renewal campaign every 90 days. Send this type of email notification to the manager where the manager will have to click, where it says, 'Renew Access'. 

This you can imagine can be used in a lot of different ways besides just the contingent worker scenario. For example, partner self re-certification. Say you have a partner portal. The challenge there is, sometimes an organization may be a partner organization, but the user from that partner organization that has an Okta account may no longer be associated with the organization. Maybe they left the partner organization. How do you make sure they can no longer access your company's resources in that case? 

You may have a re-certification campaign that sends this similar type of, extend your access, email to that user's company email address that's on file in your organization. Then, especially in these customer scenarios where your employee is a sponsor for that customer you can have a sponsor re-certification. Every 90 days, the employee in your organization, that's sponsoring that customer, would get an email that says, "It's been 90 days, should this customer continue to have access to these resources?" 

Those are the different types. I wanted to leave with this final closing note, which is, even if you have all these unconventional different user types, you can increase your productivity and security in these scenarios. One way would be with the activity based lifecycle. This would be most useful for users that don't have managers and sponsors and especially for users that need access to non critical resources but resources that are essential for their productivity. Then, you can use the renewal based lifecycle for users that have sponsors or managers in your organization to cycle through them every 90 days or 180 days, whatever is required for your organization and manage their access that way. 

If you want to go to Okta Help Center, which is, I think a rebranding of our original customer portal or something like that, there will be a chance for you to sign up to Beta Scheduled Suspension. The other feature that I talked about earlier, Notification Policy, you can watch when it drops in our public roadmap, which is on the right hand corner of the Help Center. That's currently in Beta, but it's a way for us to communicate what we're working on with you guys. You can watch out for new features there and look for notification policy there. 

Then, I have here some recommended sessions for our lifecycle management track. Anything that might be interesting to you, make sure to go attend today. Okay. 

I can take some questions now. Yeah, please raise your hand so that we can run a mic to you for a question. 

Audience:  Hi, quick question on the suspensions. Can it or will it be able to also suspend upstream accounts? For example, when it suspends it in Okta, also lock out the AD account or some of the other upstream systems. That's something you can do today or you're considering on your road map?

Amy Kim:  When you say upstream are you talking about AD? Are you AD master?

Audience:  Yeah, for example if we're AD master, we do want to lock out their AD account at the same time we suspend their Okta access or maybe, since the two coincide, since that data is falling from AD to Okta maybe just have it process an AD lock out instead. 

Amy Kim:  We currently, Scheduled Suspension as it is right now, is for Okta mastered users. A user that doesn't come from HR or AD and that's because, when you have multiple sources telling you when someone is to onboarded and when someone is to be off-boarded it's very difficult to tease out which source should be trusted. Right now it's only for Okta mastered users. We won't be able to then go back to AD if you're AD mastered and deactivate the user in AD. 

I've definitely heard that feedback from a lot of customers that say, I want the user to come in from HR or come in from AD but then use the various policies that we're introducing in Okta to then off-board them. That's duly noted. 

Any other question. 

Audience:  [inaudible 00:25:02] hear me.

Amy Kim:  Oh, we want to get it for the recording there. 

Audience:  Are you considering allowing the sponsor, especially [inaudible 00:25:10] relationship between a partner and somebody internally to deactivate accounts as a pseudo administrator or even extend that out beyond Okta too? You got a distributor who's managing their user access and once they come in and deactivate those user's, those users, they're the distributor side or the distributor. 

Amy Kim:  Yeah, eventually. Currently we are going to do this kind of re-certification and IT sets a policy on how long that access can be extended for because when you start opening up to the sponsors doing all kinds of management for this, then it's very difficult to control how long their access, how much power the sponsor has for giving someone access to various things. That's definitely something that I'm looking into so that you're delegating all the administration as much as possible. 

Any other questions?

Audience:  I had a question, regards to the front end for sponsors. Is there a front end where the sponsor can go in there and fill out the information for the person, possibly select groups that the person would be member of?

Amy Kim:  That's something that I believe you can build with self-service registration. Today, you can have a sponsor go and create an account for your customer or partner using self-service registration.

Audience:  Would they be able to fill out information like the person's phone number and their email address, their title, things like that?

Amy Kim: Yeah, that will be all configured through the APIs for self-service registration. 

Audience:  Okay. 

Audience:  These suspensions would they impact the downstream, will it be able to push for the downstream applications too?

Amy Kim:  Currently for Scheduled Suspensions, suspension is just halting access to the system so that you can't log into Okta and therefore any other federated apps that will be associated with Okta. If you want to de-provision all the downstream accounts that has to be done through deactivation. We haven't quite introduced that state yet because deactivation is such a destructive action, right, to get rid of all the accounts. We're right now wanting to get some feedback about how Scheduled Suspension works before we introduce that deactivation state change. 

Audience:  In many of these cases it seems as though some of the managers or sponsors would be managing, in some cases, dozens and even hundreds of people. I noticed you were showing an email that would go to that sponsor. Is there any way to batch it, where they would get a, the person would get a bulk email so they wouldn't get individual emails for hundreds of people?

Amy Kim:  Currently for the notification policy, we are putting a limit of one email per recipient, per day. Definitely the batching will be there. We don't want someone to be bombarded with 200 emails one day when 200 employees need to be certified.

Audience:  On your first slide, I think you had some integration with HR systems, that are not directly [inaudible 00:28:54]. How does this work with service desk where I think the service desk should be more the first integration point with an onboarding process and then, form out the different workflows accordingly, one of them being application user provisioning with Okta. 

Amy Kim:  Right now, our HR as a master functionality onl,y works with handful of HR systems. If you want to integrate it with any other system then it would have to be done through APIs. 

Audience:  Hi. You mentioned sponsors in terms of adds, what about terms in or de-activations and then changing their profiles? I'm thinking, all of us, well most of us have got relationships with partners like E&Y, Deloitte, all those people. 

Amy Kim:  Yeah, we haven't quite gotten that far yet as to allowing basically delegated administration from regular users. That's something that we are looking at but, it's not something that's going to be available in the short term. 

Audience:  What do you have with regards to app level re-certification?

Amy Kim:  Where was that question from? 

Yeah, okay. We haven't quite gotten into app level re-certification yet but, all of these workflows that we're introducing will be something that can be shared at an Okta user account level and also at an application, app user level. As we introduce this and we start validating that these workflows are working with your help, so everyone please keep trying out these features, then, we'll be able to migrate all of these workflows across multiple types of users. That's, in your case it'll be app user. 

Okay. Great. I think I've gotten through all the questions. If you have any other questions, there is a lifecycle management pod at the explore area. Come find us, ask us any questions that you have. 

Thank you very much.