Oktane18: First Impressions Last: Improving the Activation Experience Through Okta API’s

Aaron: Afternoon everybody. Thanks for joining us. Really excited to be Oktane it's the first Oktane for our team. So we're from Flinders university in south Australia so quite a distance from here. I think it takes us about 22 hours to get here. We're really excited to share a little bit about our identity program journey over the past few years. This is just a snippet of some of the functionality that we've gone live with. So, I'm pretty much going to jump straight in. 

A university's quite a complex environment in terms of the users that we manage. So we manage about 38,000 identities or active users. 60,000 users in total. We have a mix of staff, students, and also affiliates so as a university we're partnering with a lot of third parties and industry to build the best graduate programs that we can. So it's important that we have as an underpinning a really good onboarding process. So that's what our focus of today is going to be, making that first impression last for our students, and staff, and affiliates.

So Flinders is quite a young university at 52 years old. And we're going through quite a bit of change at the moment in terms of restructuring and rethinking our organization. So looking for efficiencies and improving student experience and also de risking where we can along the way. We have over a hundred thousand alumni across the world now. And as I mentioned before we partner quite closely with industry, so we have a lot of incubators in Adelaide south Australia where we try and get startups happening, collaborate with researchers and academics as well as part of that process.  So as a university we're growing quite significantly and we'll continue, hopefully, to do so in the future. 

So, I started with the university about five years ago and we had a number of issues with, I guess, the commencement process and we commence about 6,000 users per year and as part of that we winna make sure that those users are onboarded. With the previous experience that we had in place it was quite onerous for users to commence. The first issue for us was really the lack of personalization. So a lot of our services didn't really integrate well with identity. They required students or staff to fill out little forms to then present the right information to them. So, identity was kind of later on in the commencement process. That was a big problem for us. With the activation process that was in place it was quite a legacy solution, and I'll show you some screen shots. I think you'll agree it's pretty bad, our starting point. But you had to basically combine certain reference numbers as student, as an example, together with your birthdate to then activate your account.

So the activation process took anywhere from 20 to 40 minutes. So when you think about it, a student's just got an offer to come and study with us and the first thing they see is this 20 to 40 minute process that they have to get their way through. I guess because students were hit with so much information to start with they were just overwhelmed. And as a result they were hitting our service desk and our support teams pretty quickly.  So we knew that that process really had to be rethought from the ground up. 

So just to give you a flavor of what the legacy experience looks like, or looked like should I say, as a student you get an offer from our tertiary admissions center, for example, and it was in email.  And that email contained some information, it was already too much information at that point, I haven't put that up on the slide. But what the student would get to is this welcome to Flinders. And as you can see there's a bunch of form fields that you need to fill in so a reference number, birth date, course that you're offered, to then get your personalized five steps of Flinders which kind of look like this. 

So five steps. We nicknamed this internally 87 steps to Flinders. So I think we should've almost handed out degrees based on if you could wield your way through this. Each step had multiple sub steps to it. So, the detail that was in there was kind of ridiculous. And the identity component, which we call our Flinders authentication name, or FAN, was in the second step. It was kind of buried in there as part of that process. 

I guess when we started to think about this we wanted our students to commence as quickly as possible so they could accept an offer with us. So, any barriers to that, any friction, any issues along the way kind of hampers that first impression that they have of us. And working your way through this amount of detail is not a good start. So again they got even more information, they got other things sent to them in the mail as well about what their student number is, which who knows what a student number is, what a FAN is, who cares what your user ID is from a student perspective, but that information was all in there.

And then by the time you get to activating your account you had to combine that user ID that you just got with an initial password which was a merging of a bunch of data that you had to put together. So as you can tell it was pretty bad. Also the date format was Australian. So day, day month, month for birthdate the part that you had to add into to create your initial password. So for international students that didn't work quite well either. So they were ringing our service desk, our support teams, and asking how do I get started at Flinders? How do I get going? 

And I guess the other bit is these are all digital interactions so many students may never set foot on campus at all. They may set foot on campus for an open day and then choose to come to Flinders.  But the first kind of interaction is that digital experience that they have and we wanted to move identity to the front of that if we could.

So the vision that we had, and we had a myriad of other problems that we're trying to solve as well with Okta. is to look at the first and last parts of the identity cycle. So how can we improve that online activation experience and bring it down to something around sub four minutes? That was our kind of initial. We figured going from 20 to 40 minutes to 4 is still pretty ambitious. We could do better probably but that was a starting point for us. 

The other thing to mention is all the screens I showed you aren't mobile friendly. So they didn't format on a device at all.  So a lot of students would have got an email with their offer, went to click on the link, and they would have gone to a full desktop view of that commencement process. So again pretty poor user experience.

I guess with the work we've been doing with Okta is trying to get the right aps to our students, and staff, and other stakeholders at the right times, so using roll information. So that was another goal for us at least to get the core applications that a student needs to commence and that focused around our student system as well. So having those aps kind of provisioned automatically on their Okta dashboard as soon as they've set their password is something we're after.

And as a result I guess after talking to a number of students about that process and how kind of annoying it was to commence we wanted them to walk away from the new process not really thinking too much about it. So it was kind of we wanted it to be familiar, similar to how you sign up for any other online service, or even better if we could make it better. So that was kind of our vision to make that change. 

And I guess the rest of the identity cycle we've been working through over the past few years to improve. So we've got 80 aps on Okta now and we're continuing to provision more probably at a rate of one or two every couple of weeks that we're seeing.

So, I'm going to invite Jan Marie Davies up just to talk us through the solution that we came up with. Thanks Jan Marie.

Jan Marie: Thanks Aaron. That's pretty loud. That's better. Hi everyone. So as Aaron mentioned we had a really old, verbose process. We had a joke within our team that if a student could get through the commencement process they would succeed in their studies at Flinders University. It was a real test for them. It was a real test for us. I actually did it when I first came on board and I was like, "Whoa." It took me 20 minutes to get through.

So our challenge was an identity challenge. We wanted to know up front who we were dealing with. We have students, we have staff, we have externals. But within students we have applicants, we have offered students, we have PhD students, research and higher degree. So we actually use Okta to help us manage those roles based on attributes we get from our administrative systems. 

So as Aaron mentioned it took 20 to 40 minutes for a student to activate and we reduced that to under 60 seconds. And I'll take you through how exactly we did that. So we're looking at a streamlined approach. Lucky there's four steps in here and not five cause that would be ironic. So we worked with the tertiary admissions center to personalize an email with less information that went out to our students with their offer. And in that email were some really basic instructions about what they needed to do to activate their account, and then where they actually needed to go once they activated their account so they could check their courses, and their topics, and their enrollment status.

So they'd click on an email, a link inside the email, and they would got to the activation landing page which is an application that we built internally so we could customize the content to the different cohorts of users that we have at Flinders. From there they would click on an activation button which was an activation link generated by the Okta users API. And that would take them straight through to their account set up where they would put in their security information and their self-service password reset, hopefully. We have about 80% of students that do that which has had a really positive impact on our service desk, as you can imagine.

And then they'd go straight through to their Okta dashboard. So here is the landing page of the application that we built that calls the Okta API. So as you can see it's personalized its, hi Peter, new student, and welcome to Flinders University. Very, very different from the amount of content that you saw in our legacy process. So, it tells them what their FAN is, so that's something that we're going to work on because we don't believe that we actually need to explain what your user ID is, but that's legacy and we're working on that as well, and how important that is. And then they click to activate their account.

And as you can see they go straight through, they set up their details and they know what Okta is. They get through to their dashboard and we have the information that they need to start their enrollment and their study at Flinders University. All the tools that they need. 

So we've got some instructions in that initial email that goes out from the tertiary admissions center. It's got My Flinders and My Flinders is the second part to the commencement process where the users need to go and check their course, make sure it's all correct, enroll in the subjects. And that's personalized content so we partnered up with a student experience group at Flinders University and we SSO'd the application to provide a more streamlined experience. They just go in, they click on it. The dashboards also got some other important information for new students. You can see orientation, so that chiclet hangs around until orientation week passes. So the dashboards are customized for our particular cohort of users. So students see what students need to see. Different types of students see only what they need to see. Staff only get what they need to do their jobs, and so do affiliates, and IT vendors, and visiting High School students, and all the different types of users that we have at Flinders. 

So for example, our staff process is a little bit different. So a new staff member gets put into our HR system, and from there we send them an SMS with a link to our activation page. Here they enter their payroll number and their date of birth, and then they go straight through to activate. So we actually have the manual, enter your credentials here, for the other types of users in case there's a problem. And that's currently what we do with staff. We're looking at replacing our HR and payroll system so we can have a more advanced process and send them straight through to Okta. So we're working on that this year, which will be very exciting. So even then it's a really quick process for new staff. They get a text message, they click on there, they can do it all on their mobile phone. Previously they would not be able to do this. 

So using the Okta API and how it actually changed our life. We use the lifecycle attributes and activation within the users API. So the PHP application that we built makes an arrest call to Okta and determines their status. Depending on that status, we'll return a particular link to guide them through the next steps. So this is really easy. The other thing about it is we're actually changing our technology platform. So we built the activation application in PHP at the time, that's with the skills we had, and the support, and et cetera, et cetera. The framework. Now we're using Rails for our other development. So we're finding it quite easy to transition our applications with the Okta APIs, and easy to decouple because they're so flexible.

So just to recap the different types of users that we've got. I talked about staff. So we have our faculty. We have casuals. We have academic status holders. We have professors that come in and guest speak, and all that sort of thing. We've got administrative staff. We've got professional staff. So, we've got about seven thousands of those users. In our student system, we've got about 50 thousand users. So we have eApplicant, which is an online portal where you can apply for a post grad course, and it doesn't go through the admissions center. We've got international students. We've got honorary degrees, and there's quite a few users in our student system, and we've also got a lot of affiliates and externals. 

So we built a sponsored identity application within our team. Which has a slightly different, more automated, activation process, but we've got about three and a half thousands of those users. And we have temporary access. We have IT vendors. We have agency contractors. We have visiting High School students. So we have a technology center where we do cool things like robotics, and we have High School students that come through, and they might be there from one day to two weeks, and we can easily generate them an account on the fly, so that's been great. So we provision users into our identity vault where we do some matching, and we generate an authentication name, and then we send those users into Okta. 

So the activation logic, at a pretty high level is how it works. So like I said, there's a different process for different types of users, so this is back to the new students that get an offer from the tertiary admission center. So they click on a link in the email, and we pass particular parameters from that link to our activation page. So there's no need for them to string together an initial password and their credentials, et cetera. We took that away. So what we first do is we check the user state. So, we make a goal into our identity vault and ensure that the record exists first, cause it's got to exist there before it goes down to Okta. Then we make our first call to Okta, a rest call, where we check the user ID. We check their application state. So whether they're provisioned, deactivated, et cetera. We return that state then to the PHP page. So all the students has done so far is click on the link in the email.

So then we commence the actual activation process, and depending on the state that was returned from Okta in the first call, is depending on the link that's returned. Most new students have not been to Flinders before, so their provisioned. So this returns an activation link. It displays that personalized page that I showed you a little bit earlier with Welcome Peter, Welcome New Student, Welcome New Staff Member. And they click on the link, and they activate their account. And that's it, it completes the activation process. So we've worked really hard to remove those barriers and streamline that process. A lot of work happened in the background, but now it's a really smooth process for students.

I'll pass you back to Aaron who'll talk about the impact.

Aaron: Thanks Jene Marie. Cheers. So as you can see, the activation process has improved quite a bit. And it's one of those things, how much can we measure the impact of the change that we made? I guess up front we didn't spend a lot of time planning how we're going to collect data on it, so we did some analysis after the fact and compared it to previous years, which I'll show you in a sec. I guess anecdotally talking to students out there, is that they found the new activation process, so we launched this in 2017, for the 2017 first semester. And it was, the impact was quite significant from an anecdotal perspective. 

The focus groups that we engage with through My Flinders, and some other commencement projects, was that it just felt easy. Students were almost annoyed that we were asking them about it because they found it kind of easy. It's like, well it only took 60 or so seconds, so they didn't really remember that experience so much. But they just found it quick to get started. So that was kind of good feedback and made us feel like we were on the right track. I guess at the same time we made this change as well, within a 10 week period we migrated, at the time, 35 thousand users across Okta, and launched 10 single sign on apps at the same time. So we and all these changes happening at once and this is just one part of it. 

So just looking at the data, so this graph is the volume of students commencing, as soon as they get their offer from our tertiary admission center. And as you can see on that first day, the difference between 2016 when we had the old process, versus the new process in 2017. It's almost double on that first day. And I guess what that represents is just an easier process. So we could, we had basically live dashboards as well. We were drawing data in through the Okta API and Splunk, our security platform. Analyzing that data from a security perspective, but also giving our business back dashboards, so they can monitor the commencement process. 

They could also see, up front, what kind of support, if they needed to scale up their support teams during that period as well, based on the amount of people activating. They could also see things like what device they were using to activate and all this other rich data that we can mine as well to use for further improvements. So on that first day we went from, originally in 2016, 712 activations to 1530. So that's quite a significant increase on that first day, and it kind of evened out after that pretty well, as we normally expect. Until orientation week for us, and then it ramps up a little bit more with students coming on a bit later. 

On the support side, so we had about 2600 less support calls on our student support center. And we had 468 less support cases raised between the years. So again, there was a number of other changes made to that commencement process, but the big one was putting the identity to the front of that process and allowing personalized commencement information to be presented to our students. So that also had a huge impact. What we got back from our support teams was that it just flattened it out, that whole support cycle, at the start of the year. And that's a big compliment from them, so they were pretty happy with that. 

I guess also the nature of the inquiries that they used to get in 2016 was, "How do I get started?" "What's a fan?" Just those really basic questions just started disappearing from the conversations. And what was resulting was more difficult questions. So things like, "Can I do a double major?" "Can I enroll in a different course?" All those kinds of things come into it. So I think that was a good sign that we headed in the right track with the change.

So just to wrap things out. We learn a lot from our projects, so this is a snapshot of the learnings from across the entire program of work, so that we've been running over the past few years. I think one of the big things for us at Flinders is we're pushing very heavily into Cloud hosting, software as service primarily, so every app that we're buying from this point on we're checking to see, "Does it have SAML open ID connect integration? And does it have SKIM as well?" So we're looking from vendors, and we're pushing vendors pretty hard if they don't have that integration. 

So, particularly in education, some app vendors probably haven't been asked about that kind of functionality, so we're really working with our vendors closely to make sure that we've got that integration ready to go. And I guess our push to Cloud, more modern, best of breed app services we've seen in other sessions while we've been at Oktane, is really lessening the time to integrate with those apps, and provision them out to users. So anything that's in the Okta integration network is great. And that's probably the first question we do ask when we're procuring apps as well, is making sure that they're in the network, so we can start to use them straight away.

The other one that we found, I guess we've got three sources of truth for identity data, which does add a bit of complexity, and we do all this complex matching. Data quality is key to it. So Jene Marie touched on some of the rails work as well, and to be able to do that rails work, you need to rely on your sources of truth. So, our students information system and our HR system, we worked with ours.

Aaron: Truth, so our student information system and our HR system we worked with our business stakeholders on improving that quality over the years. And by implementing our affiliate kind of management system or sponsored user system called Access Now, we're able to improve the quality of that data as well. So as we implement more granular roles, and those roles also then translate into security policy. So you might have more significant password strength requirements on one particular role over another. Then we can implement those with confidence, because the data is correct. So our entire security architecture is built around identity. And I think yeah, having that quality right is critical to moving forward. 

The third point here is user experience. So, we kick this off, and you're probably wondering why Sizo is presenting about a student commencement experience. We had a lot of trouble selling our identity program to start with. And the reason for that, is we're purely focused on risk. I came in as a first security manager for the university and we weren't in a great state at the time. So, to get that uplift I knew that identity was going to be key to it. But the way we sold it and the conversations we were having were purely about cyber. And that didn't really gel with management at the time. So we changed the conversation fairly quickly. We started to just tell a story about how identity would make the processes that we have better. And how the user experience would improve as a result of that. 

So I think having that story to tell, even though it might be a bit visionary and not 100% correct necessarily. We're able to get a lot of people engaged and thinking about this project and really excited about it as well. And when you tell your staff cohort and your student cohort they're getting single sign-on, as you didn't have that previously, they get excited anyway. You just got to kind of contain that a bit. 

The last one, just about the Okta API. I think we've barely scratched the surface on what the API can actually do. I think with each release that's coming out now, we're seeing more functionality. So we've only used it in quite a small way. We're looking to use it more extensively. We mentioned that we're moving the interface, the activation pages across to Ruby on Rails so we can do that with confidence with the API so that we can go through Okta to get. As we build more constant functionality and cloud host that, we can be confident that we can rely on these APIs into the future as well. We think that's really powerful for us going forward in the program. 

Thank you. That's pretty much all we had for the session. I just wanted to ask team ... We're going to have team down in the front here as well that have traveled with us and I'd like to invite you after as well to come up and talk to us about some of the other projects that we've been working on. I've got Mark Kay. He's our senior identity specialist. [Jamie Arnfield 00:24:43], our identity consultant, and Lyndon Warren, our identity specialist and test lead. Just right up the front here so see these guys. Yeah feel free to come up and ask us any questions that you've got, but what we might do because we've got plenty of time is if you've got any questions for us, we would love to hear from you now. You winna ... Jamie?

Thanks.

Speaker 1: Questions?

Aaron: Cool. Down here.

Speaker 2: I think it's fairly obvious to see the productivity increase, but I'm wondering what KPI is used to talk about the financial impact and how this really impacts overall your university because smoothing out the process is convenient for the IT people and the help desk, but how are you convincing the powers that be that this was necessary? The startup costs and everything.

Aaron: Yeah, good question. We didn't actually focus too much on savings. I mean the self-service password reset we did some analysis on that, how much time we saved. But I guess what we as a university ... we're not necessarily looking to save money on staff, we just want staff to be working on high value, more productive activities. The questions coming out from students around what is a fan? That's quite a basic question. If we can remove that from the mix and then provide counseling and support for cost information then that's an outcome to satisfy our executive enough. We didn't actually focus a lot on the savings up front. I guess as we're getting more mature in the process, as we start to decommission old legacy components of our identity platform because we had a lot of ADFS. We had some old legacy LDAP as well, so we turned off a lot of services as we went with the implementation and we'll continue to turn off more of those services as well. 

When we do that with the next set of projects, we are going to put up business cases where we will have a direct saving on staff time and actual licensing costs too, so we can then attribute that. But at the time we weren't very focused. It was more just on improving that student experience. We've got a pretty bold strategy for 2025 to become quite a world-leading university, so part of that was to improve the student experience significantly. So, any projects that kind of focused on that student experience and told that good story were getting funded, so that's how we managed to push this along. Thanks.

Anything else? Yeah.

Speaker 3: So, the activation token and the activation email which you showed in the slide, did you use the Okta's email activation template or you built your own?

Jan Marie: No, the email that we showed you in the example was something that's sent out from a third-party. It's SATAC. So, the South Australian Tertiary Admissions Centre. There's so many ways to import into our sources of truth for identity that that was just one of them that we showed you. We didn't use the Okta activation email. We couldn't personalize it for the various roles that we had. We've raised that with Okta. We'd actually like to do that, but we have different ways so the experience is personalized for each different identity that we have. That's essentially why we built the application to deal with those differences.

Speaker 3: Okay, and the vault that you are showing, is that third-party vendor or do you have custom logic to contact Okta with checking any duplicates and so on?

Jan Marie: Sorry, that was the application?

Speaker 3: The identity vault.

Jan Marie: The identity vault is a NetIQ product for authentication, so we're looking at simplifying our architecture. That's a very simplified version of our very complicated architecture so we're simplifying that as we go on. We've delivered this project in a really Agile manner. So, the first one was to give the benefits to the customer. I think this is a good sort of segue into the question that Aaron was asked before that the benefits realization for us isn't necessarily financial at the beginning. It's about experience and that's how we retain students. 

We specialize in medicine and computer science and technology and that sort of thing. These students are quite bright and they get lots of offers. We want them to accept the one at Flinders, so what is important for us and I guess there's a monetary value in that. The government pays per student that you get, right? We don't measure that. I don't really care about that side of it either. I'm in the technology side of it, so that's his job. Basically, we're looking at simplifying our architecture even more and getting even more better experience to our customers because at the end of the day, we focus so much in our tech team on technology, but what is it really there for? It's to facilitate an outcome for our customers.

Speaker 3: And the last question I have is did you face any issues or any observations on the Okta transaction and state model or did it fit into your design completely? 

Jan Marie: We definitely took advantage of the simplicity of Okta and we let that drive some of our processes. At the same time, we had to work within some constraints and Okta have been quite in working with us and we raise an idea and getting it onto the roadmap and that sort of thing, just looking for a little bit more granularity around the groups and having different sort of access and controls for those particular groups. So, I guess to answer your question in short, we did a little bit of both.

Speaker 3: And something else struck to my mind. How did you find duplicates between a student system or some agency contractors and so on. Because there could be just one attribute which is different than all the others could be the same, right?

Jan Marie: That's a good question. Yeah, look, I think most people in this room would understand the detriment of having multiple identity records for a single identity. It's not fun consolidating and archiving later. We have a lot of complicated logic that sits in the input drivers for the identity vault. So that's what we've got there. We've got matching rules and we're looking at updating those matching rules so we're pretty excited that Okta's looking at introducing that matching and generation functionality because we'll look at provisioning our users in a completely different way. 

Also, the time that we did this we were very new in the technology space and we didn't have a robust integration platform. Now, we use DoBumey so it's a lot nimbler in the way that we can call APIs and provision users. Ideally, we'd like to start with different cohorts of users to reduce the risk. Unfortunately, as you know that you can only provision one way or the other in Okta. So, it'll be great if there's someone from Okta in the room if we could do both ways or we could do 3,000 users first instead of 70,000 in one hit would be great. But yeah.

Aaron: Sorry, just to add to that as well. I think our goal overall is to get rid of the vault so it's a bit of technology that we don't want to maintain. It's on premise as well which doesn't really fit with our cloud delivery model and it costs money. So if the Okta can do the work and it can do it in a more modern and flexible manner then we'll use that tool for it.

Jan Marie: Yeah, and it's helped us sort of decouple particular things, notifications, certain logic bit by bit. So, when we do pull out this beast of a thing, it's not going to be so difficult. 

Aaron: Yeah. Any other questions? Thanks a lot.

Speaker 1: No, great. Thank you so much. Reminder to fill out your card and drop it off at the back if you don't mind.

Aaron: Thank you.

Jan Marie: Thanks so much.

Aaron: Great.