Automate Lifecycle Mangement: The Right Resources, at the Right Times, for the Right People

Ankur Datta:I am really excited to be here. It's a pretty good turn out, so thanks for attending this session. My name is Ankur Datta, I'm a senior project manager at Okta. I've focused on two areas, lifecycle automation and accessibility. In the next 40 minutes I want to make sure that you guys learn about the cool stuff my team is building to automate the different processes, which are security outreach, risk management leader, configures while managing the entire life cycle of a user while managing the identity all the way to the access. 

We'll talk about a number of different new capabilities, some enhancements that we have worked on in the recent past and this will cover actually a broad spectrum of user segments, all the way from employees, contingent workers, B2B use cases, and at the same time, we'll try to talk about the different use cases that one encounters while managing the employee identity, right from day zero, when the employee or the contractor starts working with your company, all the way to the last day when they off-board.

But before I deep-dive into all those capabilities, I'd like to introduce you to Adnan Sancak from Arcelik. Arcelik is one of our customers. And Adnan will talk to you about how they are using Okta, what are the day to day challenges that they face, and then we'll deep-dive into the different capabilities or how we'll help address those challenges. Over to Adnan.

Adnan Sancak:Hi, everyone. Can everyone hear me? Well? Okay. So have you heard of Arcelik before? Hands? Yeah, that's what I was expecting.

So, Arcelik is one of the biggest home appliances provider in the world. Arcelik is our company name, also a brand that we use only in Turkey so therefore, I wasn't expecting anyone here to know Arcelik. And we are try to go up, of course, for the challenge and trying to produce smart, and low-energy consumption products in this industry.

As Arcelik we have 11 brands, 33 marketing offices in the world. Our production facilities are mostly in Turkey, Romania, and in the Asia-Pacific region. Our brands are sold in 145 countries and our employees are 30,000 people. 

So, as I said, you may not know Arcelik, but maybe you are familiar with the brand Beko or Grundig, so these are our brands. Or maybe in U.S. Blomberg is also in the market. So these are our brands. I just wanted to introduce you. 

Of course, I'm not a marketing manager, I'm not going to introduce you our brands or our company. Today I was going to introduce you our B2B network and the challenges that we have. 

So our B2B network consists of four main organizations. First of all, in Turkey, we have a domestic dealer network. These people are not part of Arcelik, they have their own shop and their own companies and there are around 3,000 retailers that we have. Also, their stuff is included because we are serving the software to these people in our B2B network. 

We have international distributors as well, so we are selling our brands in more than 100 countries. So there are around, again, 2,000 distributors in the world.

We also have private technicians. Those are the people that help when a product is broken or whenever any product is bought and has to be installed in a house. We are talking about the refrigerators or washing machines.

And lastly, one of our important B2B players is suppliers for the production. These suppliers are providing materials or finished goods for our production facilities. 

So these people are using our systems and we are managing their identities in our systems as well. So before Okta what we were doing is we have an on-prem identity solution, I don't want to give it away now, but you can ask me later. What we are doing is lifecycle management, so we are creating our users mostly in active directory, lDAP, SAP systems, we have lots of SAP modules, and some of the other applications that meets user identities to be created in their application user store.

We are also providing password synchronizations between those application, so every user is using a single password. And there's a custom developed SAAS service password management portal to manage the password. 

So I already told that we have 30,000 employees, our B2B users are around 40,000, and we also have B2C users that we sell online. So there are more than 300,000 people in this category. 

So our challenges are mostly password related, so, implementing a password policy is hard because we are provisioning users to many different user stores and applications that using these user stores are, might not implement the desired password policy in that matter. Also, I am almost sure that everyone faces this password sync issue. So, you change the password, it synced in most of the applications but when it's not synced to one application, that makes user very angry. So this is a day-to-day challenge that we have. And also, having an on-prem identity solution is . . . Sorry. Meaning that, you have to manage that solution yourself and if you don't upgrade it regularly, in the end, you end up with a solution that cannot connect with new technologies, only cloud platforms. So that is another challenge that we face. 

When we meet with Okta actually starts with the omnichannel program that we have. So with this program we are trying to improve our customer experience in every channel and there was a need to have an identity access management solution in the heart of this program.

We look for the solutions in the market and our primary factors, or primary objectives, were we wanted a solution that can provide single sign-on, not for the customers but also for the enterprise level. So wanted to do both. We wanted to have any kind prod integration, so that was another objective. Managing access management access application is very hard so managed service is a top priority. Also, we are also operating in the EU region, therefore GDPR is also very important for us. Considering these objectives and the market about the identity access management, we decided to go with Okta and what we gained was a unified authentication experience. So we have several applications that have different authentication interfaces, different login pages. Now we have only one Okta login page which it's operating for every application that we have, that we connected to Okta. As I've mentioned before we are using lDAP and active directory currently, so we just configured the directory integration and it was up and running in a short period of time, that was a good thing for us. 

Also, I mentioned about the cloud integration, so, in the omnichannel program we switched many applications to cloud like Salesforce, Success Factors, SAP Hybris, et cetera. So we were very switch to implement these kind of applications in Okta and we also had the opportunity to apply multi-factor authentication to these applications.

So considering this scenario, there are also other channels that we have currently. We are trying to implement this solution with Okta. Firstly, I want to say that we are a global company and mostly people are leaving their current position for another one in another country and sometimes in different countries there are different systems or applications. So we are really looking for a solution where we can have all the rights, permissions, authorizations of the users removed whenever the user is repositioned in another company or in our country. 

Also, managing the lifecycle status sometimes very hard because we have different application source like lDAP, active directory. We have Okta as well. So, when you don't have the single place of truth it becomes hard to manage these kinds of statuses. So that is another challenge that we have. 

Also, with Okta, we are now provisioning our B2B people in the applications that we started to use like Office 365. So we assigning our domestic details directly to Office 365's dynamic CRM application with the proper license. But sometimes when we decided to not work with that retailer, we have to manually off-board these people from the applications. So I think from now on Ankur will show us how we can improve these areas with Okta, so I'm leaving the stage for him.

Thank you for listening.

Ankur Datta:Okay, so how many people can relate to this, some of these challenges that are not mentioned. Wow, that's quite a few hands. Okay let's see how we can solve each of these things, one-by-one. 

Alright, so, yeah, just to recap. Adnan talked about how they are using different directories. Directories that are to set up the source of truth, integrating with Okta, and now we are going to talk about how we can help them automate the processes and streamline those downstream workflows. 

So, pretty much every Okta customer, they start with groups. So, I'm sure if you guys are using Okta, you must be familiar with groups. So groups are mainly used to organize a group of users and then once you have organized those group of users you can assign that group to, or assign applications, policies, different resources to that group.

So, like the example Adnan was mentioning that because they are a global company, they might have groups such as "Employees in Turkey", "Employees in Sweden", "Employees in Germany", et cetera. And then when employees move across different groups, there can be a new set of challenges. How do I make sure that they get assigned to the right resources when they move across the company, and so on. 

So, that can one issue.

Ankur Datta:... So that can be one issue. The other issue could be that, even let's say if someone is within the same geographic location, they might move different departments or if someone is a contractor they might become an employee later. So how do we make sure that we are able to get these folks productive ASAP, like without any manual intervention and so on?

So to handle this, at Okta, we built Group Rules. So Group Rules are pretty easy to configure. You define an "if" condition. For example, you can say if the employee's costs enter as finance department, for example. And if that's true then you can assign the user to a particular single group or multiple groups. You can also exclude certain users if you don't want them to be part of this Group Rule execution. And while configuring the rule, we also provide review functionality, so you can enter the names of different users and check whether the rule is applicable to them and so on.

So we constantly try to improve Group Rules, because we have been noticing that the cool part of Okta usage. So one of the things that we have been focusing on a lot recently is to increase the scalability of Group Rules. So those of you who are using Okta Group Rules currently, you might be familiar with this rule limit that we impose limit of maximum hundred rules per org. So that's one thing we are trying to ... I wouldn't say entirely get rid of, but definitely increase that limit significantly, so that our customers can run a lot more rules.

And in addition this feature where a rule can be used to assign the users to multiple groups, that'll also help you reduce the number of rules. So that's one thing we are looking into. And we anticipate that, as more Group Rules are created, there will be an additional set of use cases where the IT admins might want to batch the rules, sequence the rules, based on a certain pre-defined order. They might not want to run all the rules immediately. Things like that. So we are still exploring those use cases, and you'll hear more from us on that regards in the coming months.

So Group Rules are great. Like they'll help you assign the apps for new employees when they get started in a new department in your company. Now that's great for assigning Birthright apps, but what about those apps which require special approvals, or which, let's say, usually involve some kind of a training, or they're expensive applications, so you want some application owner or a resource owner to review the quest and then allow someone to access that app? Now in this use case, I would say they work with different B2B partners, different suppliers and stores across the country, and they want to give them access to, let's say, Sales Force or Office 365, to do invoicing, ordering, et cetera, but then not everyone should have access to that app. So that goes through some approval and request workflow. And that's what we have built at Okta. 

So our approval and request workflow features, which are already in early access, so they allow you to delegate the access decisions. So you can configure the approval logic for a particular application, and we'll take care of the rest. We'll make sure the right approvals get notified, and if there are back and forth during the approval process, we keep a track of all that. We try to make sure things are fast, at the same time transparent. 

The other great thing is that, because things are automated, you can pre-configure them. So you'll notice a significant number of ... Significantly less the number of tickets created for the IT department from the different users. And yeah, as I mentioned, the goal is to make sure the employees get productive fast. 

Couple recent enhancements that our team has been working hard towards. So firstly, a big shout out to our design and engineering team. Over the last six, seven months, after we did the Beta for our first iteration of access records work flow, we got a lot of really good feedback, and we figured that it makes sense for us to simplify the whole advent experience for ourselves. So now in the single pane, single panel, you can configure whether an app should be self service, which means that it doesn't require approval, or if it requires approval you can also configure the approval logic in the same space. So this simplifies the experience in general, because you don't have to go to multiple places, and also it makes the whole experience a lot more streamlined, so we can give you more educated, intuitive warning messages when certain things are not configured properly, et cetera.

Another thing that we ... It's a smallish feature, but it's very important, and we've got many customers requested for this. So this is called requester notes. So the idea is that when an end user is requesting for an app, which let's say requires training or is an expensive app. As an admin I can configure some messages that I want to display to the user. It's basically another way of adding an additional step of friction before approving access to a particular app. 

We'll continue focusing on approval and request workflow in the coming months. The two features I mentioned in the previous slide, they'll be at the level of early access in June, so please sign up for those. Contact your customer success manager to help you get set up. But yeah, in parallel we'll continue improving this feature, both in terms of breadth and depth. So right now one can request access to only applications, but we are looking at other use cases, such as can we ... Can a person a request any resource using the Okta approval and request workshop?

At the same time, we are looking into adding additional levels of layers of approval, logic or flexibility, in the sense that you can reconsider adding manager as an approval. So manager can be both a request and an approval. So for instance, let's say, going back to Arcielik’s use case that, if they have a B2B supplier, or a B2B partner who's owner of a store, and they have staff members who need access to Office 365 to do orders, or submit invoices, et cetera. So if the supervisor of that store can request access on behalf of those office employees, then maybe we can just, you know, approve it right away. So that's one functionality we're considering.

And in addition we are also looking to other delegation and escalation use cases in the approval flow. 

So we talked about Group Rules, we talked about how they help new employees get set up, we talked about how access records work flow helps you get access to additional resources which require special approvals. But then we came across a lot of other use cases, too, while working with non-group approvals access request, where a customer said that when certain conditions are true in the user's life cycle state, I want to perform certain actions. 

So there were a number of examples. One was where we had this customer in South Polo They wanted to revoke access of certain employees if they had been inactive for 90 days. Now in the past they had to manually check which employees are inactive for 90 days, and then update their status manually one by one. Or some do it other ways. He mentioned one example where they have a B2B partner who's trying to access a certain app, but let's say the partner ends the contract with Arcelik So they want to immediately revoke access to the app for this person. 

There are other use cases too, where when certain conditions occur, I want to send periodic reminders. Password expiration is a classic example. That you want to send reminders to employees seven days, three days, one days in advance for instance. 

So how do we set up all this? So to adjust these uses cases at Okta, we developed this new solution called Triggers & Actions. With Triggers & Actions, the idea is that across the entire user's life cycle, you can identify the different break points of your interest, and you can configure those as conditions, and take actions so as that you are able to respond immediately. I'll show you a couple of examples in a few minutes, but the idea is pretty simple. So we have this feature. Like, on the left panel we have the different conditions, so I can specify which group this particular policy is going to apply to, I can set up a schedule in terms of how regularly this thing should run, and then I can satisfy other conditions that ... Or am I interested in users who are inactive for 90 days, users whose password is expiring in seven days, and so on. And once those conditions are true I can take several independent actions. So I can update the life cycle state of the user, I can send a message, and there other actions we are exploring right now.

So let me do a very quick demo, and show you how this thing works. 

I guess you guys can't see my screen ... Yeah, is that better? Cool.

So this feature's still in beta, so we are still working on the ... Like this is not the finished product yet, but it will give you an idea of how this thing works. So I'll start creating one automation. I'll call it, let's say, B2B staff members. Yep. And the first thing I want to do is, I want to identify the group of users on whom this is going to be applicable. So I don't want to apply to all of my users, so I'll just look for a specific group. So in this case it is the B2B staff members. And I want to make sure I run this thing, let's say, daily. I can also run it once. I'll run it at 8AM every day, not in Pacific time, so these users are, let's say, they are based out of Turkey, so I want to make sure I run it at the local time zone. So, I'll search for the particular time zone. Save this. 

Then let's say I'll just look at inactive users in this example for now. So, if my users are inactive for 90 days, then I want to perform the following action. So, the first thing I want to do is update the life cycle state of the user, so I'll update it to suspended. We are working towards adding support for other life cycle states too, in this particular action. Once I've configured this, I can also send an email to the user that ... Something like, "Hi user, you'll get logged out." That's it. And after this you can activate this particular automation and every morning at 10AM ... Oh, someone didn't save the right time. But yeah, it will run at a particular time every day, and identify those users who are inactive for 90 days, and then from the subsequent actions. 

Now, going back to my presentation ... Cool. Yeah.

So, this feature is going to be in beta sometime in June. We already have about 40 to 50 customers signed up for this feature, so it will be great if we get more sign ups and more feedback from all of you. So in the beta version of this feature you get to configure triggers on inactivity, password expiration. You can send ... Configure actions on sending emails, updating life cycle states. But then we are looking at a larger number of use cases too. We're looking at other use cases such as, if let's say my B2C users, they were trying to access my portal, but they did not complete the registration. So periodically I can identify these users, and clean up incomplete registrations.

Similarly we are looking at use cases where we can look at the user state in different HR systems, and perform actions based on that. 

I talked about actions, they are sending an email. But then we also want to add support for other actions such as sending a web gook some end point, so that you can configure your own action and send, let's say, "Okay, your ticket's in service now." Send a mail email campaign. The possibilities are endless. 

So my request is that, please go to this URL. There's a very short form. It has only two questions. And I'd love to hear more use cases from you guys that, when this happens, I want to do this. And feel free to share additional feedback. But as we get the different requests from you guys, we'll start prioritizing them, and you'll hear more about the enhancements in this feature in the coming months.

So what I've talked about, most of these automations which are occurring within Okta. So, like, in Triggers & Actions, I am-

Ankur Datta:So, like in Triggers & Actions, I'm able to send an email to the user, update the life cycles, save it in Okta. But what if I want to do something outside of Okta? That's where we started, since we realized this, as an important use case so we started focusing on Webhooks support. So, very quickly, for those of you who are not familiar with Webhooks, it's pretty straightforward. The way it works is that in Okta there are different kinds of Events that occur, and we publish those Events. That's where you can subscribe to certain Events of your interest. When those Events occur, immediately we'll send a Webhook payload to some endpoint, and you can use that payload to create a record in Salesforce, for example, or use some custom logic in your own application and so on.

Some of the early use cases that we are still considering are these Events. We are, let's say, for Group Membership changes of a particular user. It could be, let's say, a highly sensitive group of, let's say, the board members in a company. We want to send an email. We can send a Webhook payload, which can be used to send an email to the group admin.

Similarly, we are looking at other Events such as certain catastrophic Events and some import job fairs. If there are job fairs, then you can create a ticket to ServiceNow using this Webhook payload and so on. So we are still working on these features. You'll hear more announcements from us in the upcoming months of the Beta year, and so on. Again, please feel free to share your feedback on what other kinds of actions you'd like us to take using Webhooks. 

So, when can one start using these features? As I mentioned earlier, Triggers & Actions is going to be available in Beta in June. The Simplified UI of Approval of Records of the admin experience that is currently in beta, but it will be available also in June. The functionality to create or use a single approval to assign users to multiple groups, that's already available. We have seen some customers already starting using it, and we've got some really positive feedback. If you have group approvals set up, please start using that.

That's all I have to share, so I was asked to make sure that you complete the survey card, and I guess we can take questions now. 

Ah, there's a handle there.

Speaker 1:I'm just curious about the Self-Service and approval workflow, maybe I'm just unaware, but is there any way to scope access to that specific groups. For example, I don't want certain types of employees to even be able to request, like contractors.

Ankur Datta:I see. Yes, At present that's not possible, but I'll keep that use case in mind. Yeah.

Speaker 2:Thank you, on the same subject, is there a way for self-registration to have an approval cycle around it? Meaning, you allow them to self-register, but you still approve the users after they don't already have access to whatever application.

Ankur Datta:Can you elaborate on that use case? Can you give a specific example when that would be-

Speaker 2:Let's say you allow them to sign on to a help center, but you would like to approve them according to their support contract, if they're allowed to access, not allowed to access, what areas they're allowed to access. So you allow the users into the system, but you don't activate them perhaps?

Ankur Datta:I see. Okay. Currently the Approval and Records work is not entirely used for that use case. Maybe I can discuss this with you offline. There are a couple of other possibilities, other solutions in Okta, which can be more useful for this one, like the groups concept and the EPAs that can be used for that possibly.

Speaker 3:We have a use case where we need users to answer a few questions before they are given the access, besides people approving it. They actually need to answer those questions. It's not like an occasional note, and oh, by the way. It's a do you do this? do you do that? Yes or no?

Ankur Datta:Okay. So currently you can still pose those questions for the users using the request for notes feature, so they can potentially go to an ... you can add a URL in that section where you've configured the notes. Users can potentially go to the URL to answer those questions, but how to evaluate the response and use that in the downstream decision to approve or deny a request, that's not currently supported, but that's an interesting use case. I'll check if there's more demand for something like that. I can see there are certain applications where you want some functioning like that.

Speaker 4:I had a quick question about the integration that you currently have with ServiceNow, and how that would play into Triggers & Actions? I know that you currently have a fairly good relationship with ServiceNow. How would using Triggers & Actions, how would that benefit the end user later down the road?

Ankur Datta:Okay. One thing that can be potentially done is that when certain conditions are true, and you want to perform a certain action, one action could be sending a Webhook, or creating a call back, which can create a ServiceNow ticket, or run some ServiceNow workflow. That's one thing that might be possible. We have just started looking into these scenarios, so I'll probably have a better update for you next time.

One more question.

Speaker 5:I'd like to reiterate what the young lady there had to say. In order to approve a request for an app you need to know what type of access they need. So, for the Salesforce, need to know which role, which profile. If there's any auto discovery out of Salesforce, pull back the valid roles and profiles fabulous, otherwise our admins can type them in to an edited list. That's number one.

The other one is, thank you for putting Self-Service for groups, right. We have a push for groups based on policy. We need a bunch of one-off exceptions for members to groups. Does Okta capture the group owner as in Google groups? We need them approved by the group owner.

Ankur Datta:I'm not 100% sure about the group owner concept, but if I go back to that slide where I talked about our ambitions to use Approvals and Requests for any resource. So when we do that we'll have to have a consider for resource owner. Right now, even for apps, I don't think we have a consider for app owner specifically configured in Okta, but it's definitely possible to configure that. We just add them as an approval in the logic, but not explicitly say hey, this is the approval.

Speaker 6:I had a question about approvers for the access request workflow, as well. We have a similar system in place right now, and we would be interested in switching to Okta once that's rolled out, but a common problem we have with our current approval system is that if the approving manager is out of the office, we will need to manually override it and submit approval to someone else. Do you have any plans for any kind of automation of that?

Ankur Datta:Yeah, so we are looking at, very quickly you mentioned that, but I can elaborate on that. We are looking into different delegation and escalation use cases. Now the delegation can be when someone is out of office, or someone is really busy, so they should be able to configure that. Now how exactly that final feature is going to work, that is something we are still discussing within our team, so please stay tuned for updates on that feature.

Speaker 7:Hi, I had a question about one of the Triggers that you mentioned, and I think this is coming in possible changes in HR status? Like either they change role, or I guess you could think of termination as well. So in our Okta instance, LDAP is our Directory Master and our Source of Truth, and our feeling is we want to keep it that way. Would it be possible to still have LDAP be the Source of Truth, but input some of that data from Triggers that are happening in HR in our HMS and have Okta automate actions based off of that?

Ankur Datta:Sure. It's funny, because a man who has called specifically mentioned that exact same use case. They also use LDAP. Yeah, the answer is yes, we definitely want to support those kinds of Triggers. How and when? That is something I need to discuss with the teams who work on directories and how they synchronize information from that into Okta. Once that information is there, definitely it should be possible to create actions based on those conditions. Yeah.

I think I can take one more question, one last, maybe it's 12:45 almost.

Speaker 8:My question is we have users requesting access, but in our stores, the store managers may go out for vacation, and they want to give a request where one of the employees gets elevated permissions or access to certain apps while they're out. We want to enable them when they're out, but then again revoke that access when they're back. So an effective date period, where from this date to this date you can do it, but after that date it automatically goes back without him having to put another ticket to do that. Do you guys have any types of plans to do something like that?

Ankur Datta:That's a very interesting use case. I can give you a very quick answer. It's sort of related to the delegation question that someone mentioned, so I guess what we can do to address your question, what we can do is we can track those delegation Events when let's say if I set up someone else to delegate on my behalf, I can track that Event, and I can also track an expiry date for that delegation, so that the moment that delegation expires then we can trigger, that can be one of the conditions in Triggers & Actions and we can perform certain actions like revoking the access of the user, so yeah, that's a very good question, that you mentioned. While we currently don't support it, that's one action we can take. Yeah.

Speaker 9:Just a quick one. Is there any way we can read up on these future features in more detail?

Ankur Datta:Yeah, so we have recently published release notes, we have a new internal road map that you can access and when we make some of these big announcements when products move from beta to here, we publish blog posts, and a lot of more detailed documentation in our Help Center. You'll definitely get a lot of information there. For some of the interesting features like group approvals and access request workflow, there's already a lot of detailed documentation available in Okta's Help Center. 

Also, I think we are out of time. I would love to take more questions, but I'm sure my email information must be somewhere with my address, so please feel free to reach out. Thank you.