Integrating Active Roles with HR using Starling Connect

[MUSIC PLAYING] Welcome to this session on Active Roles and Automating Identity lifecycle. My name is Chris Rudd and I've been with One Identity for the last 16 years. And during this time, I've had the pleasure of working with Active Roles quite considerably. In this session, we're going to learn how to automate Identity lifecycle by integrating Active Roles with a SaaS based HR system via Starling Connect. Before we get started on the actual configuration, there's just a couple of things that I want to take you through. So the agenda for today is where-- it's going to be a quick intro. There's some preparation that you should do before you start integrating Active Roles with HR, and then we'll look at some of the configuration things that we'll be covering during the session. So today's session, we're going to connect Active Roles to success factors, and we're going to walk through the configuration process step-by-step just to see how it can be done. Now, obviously, not all environments are the same. There will be differences, schemas things like that. So what I'm going to try and do is point out what you need to look for and be conscious of when you try and do this type of integration. Before starting the actual configuration work, it's important that you prepare for the integration. So one of the first things that you'll need to do is engage with your internal team. So when you integrate HR with Active Directory, there's going to be an impact on several parts of the business. So, obviously, one is HR. So when HR's authoritaty for data, they should make any changes to that data. So you'll have to engage with the HR team to understand what their processes are, understand the impact that these changes are going to make. You will also need to engage with the service desk because, typically, for AD changes, people go to the service desk and say, oh, can you just change my name, or can you just change my department because it's wrong? In this case, they're going to need to know to go to the end user. So it's important that the service desk don't try and change attributes that HR authoritative for directly in AD because these will get overwritten. Lastly, of course, and not forgetting the end users, they need to know who to go to when they do want changes made. Another important thing to prepare before starting is really identify the use cases that you want to support. You don't need to do everything. Just be sure about what you're going to do and what you're not going to do. And, equally, you don't need to do everything in one go. So we generally recommend breaking down the work into several phases. Pretty much goes without saying, focus on what brings the most benefit first. Pick the low hanging fruit. Take away the pain points. As that will give benefit to the business sooner rather later. And, lastly, make sure you understand what data you need when and under what conditions because within the HR system, there's going to be business processes that run and that's going to have an impact on data and you need to understand what you get and when you get it. So engaging with the HR SME is really, really important. In terms of the configuration, really, there's a couple of steps we're going to do. First is we're going to set up the SuccessFactors HR connector install in Starling Connect, and then we're going to verify that we're getting data from that. Then we're going to look at what we call effective data sync, and that's basically the current values as of today. Bearing in mind that there might be some changes coming down the pipe, which are already sitting in the HR system but haven't been effective yet. So what we're going to do is first focus on just taking the current values. And then we'll look at what we call future data sync, which is looking at syncing and changes that are coming in the future. So you might have a new joiner that's starting in two weeks time. You may want to create the account in advance, and we refer to this as future dated sync. So we'll cover that after we've done the effective dated sync. Let's get started. The configuration prep consists of setting up the SuccessFactors HR connector in Starling Connect. Before we dive into that, let's take a quick look at the environment that we'll be using for this deep dive session. I have three VMs in this environment. The first is the domain controller and exchange server combined into one single VM with all the standard admin tools on it. The next machine is a SQL server hosting the Active Roles and sync service databases. And last, and definitely not least, is the application server that we'll be using. It has Active Roles and the sync service installed. So it's got Visual Studio code and Postman on it. So I've got a couple of tabs open in Edge already, so we can connect to Starling and to log into SuccessFactors when we come to it. I've created an OU specifically for this deep dive. I've got a couple of standard policy objects within Active Roles and a couple of basic workflows that we will use a bit later. Apart from that, it's all fairly clean. In terms of the sync service, there's no configuration. There's no connections. There's no mapping. There's no sync workflows. And in Visual Studio Code, I've got a couple of script snippets that you're going to use in some of the sync rules a bit later on. And lastly, in Postman, I've got a collection for success factors. And it's just got a couple of endpoints configured so we can validate the data. Now let's get started on the configuration. The SuccessFactors connector configuration is all done in Starling Connect. So let's get going. First of all, I need to sign into Starling, select the Connect service, and then select the SuccessFactors HR connector. For those that are wondering of the difference between the SuccessFactors connector and the SuccessFactors HR connector, it's really about the endpoint. So HR is looking at the employee, whereas SuccessFactors is looking at the user endpoint. So let's select SuccessFactors HR. Now, for this one, we need version 8 because that's what's been tested for compatibility with the sync service. We'll select Development. I'll leave the default name. Now, there's a couple of options that we need to set. So because we're going to focus initially on effective dated records, we're going to enable this. And we will separate out effective and future dated records. So let's do that. And now what we need to do is just grab a couple of details and paste them in. So let's start with the OData URL because that one's nice and easy. We'll grab our username and our client ID and our private key. Now let's test the connection. That was successful. That's great. So now we can save the connector. We will need the SCIM URL, so I'm going to copy this and save it for later use. I will quickly drop it into Postman so I don't have to worry about that later. Now if we scroll back up, we can see that I've got a SuccessFactors HR connector. It is telling me there is an update. But because the SCIM connector has been verified with version 8, we're going to stick with version 8 for today's session. Let's dive in. Now, I know I need to make a couple of changes, as not all the attributes that we try and pull back are in our schema in SuccessFactors. And if we try and pull them back, then we'll get an error. And we can see this in Postman. Just to show you what I mean, we'll quickly run a query in Postman. So first, I need to get a new token, so I'll grab a new access token. Yes, I want to use it. And then we'll call Get Employees. And then we'll just execute it. And what it's telling me is it can't find workingTimeDirective, and that's one of four attributes that we pull back in the connector that we don't have in our schema. So you might see some of these. And the actual attributes that you're using may differ. But it's always worth checking in Postman to make sure that you can get everything back. And if you get an error, it's simple to fix. So let's dive back into the connector. So now we need to edit-- constantly forget. Enter our username, client ID, and we need to grab our client [INAUDIBLE] again. I have these values stored in a document on another screen just to make it easy. Now, what you'll notice is the connector's automatically saved as soon as we enter the credentials. Now every change we make will automatically be saved. So there's actually four attributes I need to change. So the first one is workingTimeDirective. Here it is. Let's disable this one. The next one is retired, then pensionProtection. It would be nice if these were in alphabetical order, but there you go. And the last one is hazard, so let's disable that. And because we've separated effective dated operations and future dated operations into two different objects, I'm going to quickly go and repeat this for future dated employee objects so I don't have to worry about this later on. All these changes are automatically saved. So we're pretty much done now with the configuration. So now if we try and repeat the request-- hopefully, our access token's still good-- and there, we've got a list of the employees. And this is all we really need to do to set up the connector. We've established the connection between the connector and SuccessFactors, we've configured the schema, and we've defined how we want to get the data back. And, of course, more importantly, we've tested it and validated that it works. So now it's time to configure the sync service. We don't have any connections. But in order to add connections, we're going to have to have an immutable ID. Now, before we actually jump in and do the configuration, there's something I want to highlight to you. So HR systems are like any other systems. The data is not always as good as it should be. So HR might tell you differently, but sometimes it's worth checking. And just to give you an example, if we take a look at the SQL server, what I've done is create a little database to load the data on the ID in the personIdExternal, which are two possible IDs we could use as the immutable ID. And I run a little query just to check the data quality. And what I found is there's no duplicates on id, which is great. That says it should be. But personIdExternal, which is what SuccessFactors seems to use internally to reference other data tables, seems to have some duplicates. So I think we want to avoid personIdExternal and stick with ID. Now, certainly with customers that I've worked with and had discussions with, HR data hasn't always been clean, and this is one of the things that you can fall down on. There's an easy way to get this data into SQL. Just create a table, use the sync service, use the SQL connector, and pull it in. And then you can look at what data that you're working with and then run some queries. It might save you a lot of time. Setting aside that digression for a second, let's get back to the configuration of the connections. In order to synchronize any data, we need at least two connections, a source and a target. So let's get started with the first connection. This is actually going to be our target connection, the AD connection. Let's call it Active Directory. And for, this we're going to use the One Identity Active Roles Connector. Let's go next. We need to give it the name of the administration service. It's actually this computer, but that's fine. We're going to use the sync service account. Let's test the connection. Everything's OK. That's great. Before we finish, let's just dive back in because there's one thing I want to do. I use my lab for various things, so I'm just going to go in and set the scope on the connection just to make sure it's only focused on the OU that I've specifically created. So let's take this off. And then what we do is we go down to Resilience, Barcelona, Accounts, and Users and just save that. So that means when the sync service is looking at it, it's only going to look in that container, and it's not going to interfere with any of the other testing I'm doing in other work. Now it's time to add the connection to Starling Connect. Let's click the Add Connection. I will call this one SuccessFactors. And I'm going to use the Generic SCIM Connector. Let's click Next. So I need the URL, which I copied earlier. So let me paste this in. And then I'm going to choose an authentication scheme. We have Starling supported at this moment. So let me get the token URL. I also need the client ID and a client secret. I need to choose a implementation plugin, and we only have one at the moment, Starling batch 1, so let me choose this. And then what I need to do is scroll all the way down and test the connection. Connection is good, so we can now click Finish. The next step in the process is to establish a relationship between the two connections. Let's go to Mapping. In the mapping, we'll choose a connector. And it really doesn't matter which one we choose. Really, it's a two-stage process. So first, we need to define an object pairing. So we're going to use the employee object from SuccessFactors and match that to a user object in AD, so SuccessFactors and employee. There are different object types, so make sure you've got the right object type selected. And then, obviously, we need the other half of the mapping, which is going to be the AD connection, and that's the user. So we now have employee mapped to users. But now what we need to do is actually create a mapping rule. Now, you can have more than one mapping rule. In my case, I'm just going to go very simply and say I'm going to use the ID and map it to the employee number on the user object in AD. So I'll just take a second, so attribute, and I'll choose ID. On this attribute, I have chosen to use employee number. Click OK. Now that we've defined the rules, we can simply map. So let's do a full map. Now, bearing in mind, it's only looking in our specific users OU within AD, so there should be something like 1,350-odd unmapped employees. It'll take a second. It needs to connect to SuccessFactors, read the data, do the same from AD. And as you can see, not mapped objects, 1,357, which is what we were expecting. So let's commit that, which saves it to the database. And that's the mapping complete. Next up is the creation of the sync workflow. So first, we go to sync workflows, then click the Add Sync Workflow button and just give it a name. Now, I use this fairly basic naming convention of source to target. As I'm starting with a clean environment, the first thing I want to do is add a synchronization step for the creation of user objects. So let's get started. I need to ensure that Creation's selected. I need to specify my source system, which, of course, is going to be SuccessFactors. I want to make sure Employees object is selected. Now, it would take about 15 minutes to create all of my users in SuccessFactors, so I'm just going to add some creation criteria just to limit it. And what I'm going to do is just limit it based on surname, so anyone who's surname starts with C or D. And I'm going to add in a couple of managers because that's going to come in handy later. [UPBEAT MUSIC] Now we've limited the scope a little bit, now we can move on and configure the rest of the synchronization step. We need to specify the target system, which for us is going to be AD, of course. It's going to be a user object. I want to put my users in a specific OU, so I'm just going to select that one. I need to add a rule for generating the object name. Now, unfortunately, this isn't as flexible as the policies within the administration service. The important thing is to make sure it's unique. So I'm just going to use a simple rule based on last name, first name, and ID, just to generate a unique ID. Now, there are other strategies you can use. You could just use the ID itself and then have a workflow to rename it within Active Roles based on what you think is a better structure. So let's configure a rule. Oops, that's a mistake. Rule. Let's start adding the details. And so, first of all, I want the family name. I'm going to take all the characters of this. Then I want some text, comma space. Then I want the given name. And I'll take all characters of that. Then I want some more text to be space, open brackets. Then I want the ID, and finally, the closing bracket. So this is going to create a unique object name for me. Let's go and hit Next. Now we need to actually set up the rules for the data that we're going to sync. Obviously, as we're mapping on the ID, we need to make sure that we have the ID map. So let's bring this across. And if you remember, from the mapping, we used employeeNumber. So it's important that we get that right. Now let's just bring across a couple of other attributes. [UPBEAT MUSIC] I need to set an initial password. Now, normally, you wouldn't do this. And by default, I do that just because it's my lab. One of the things you would have noticed, I hadn't added manager in there. And I've done that for a specific reason. Because I'm creating everything new, the managers won't exist at creation time. So I'm going to leave the manager update to an update step. Now we've configured the provisioning, let's run it and see what happens. So I want to make sure I've got the step. I'm going to do a full run. And it's going to go away and look at the data in SuccessFactors, look at what's in Active Directory, and then tell me which objects it needs to be created. And now we have 138 objects. Let's dive in and actually have a look before we save the changes. So here, we have our users. And if we just look at a couple of them, you'll see-- so some of the users have spaces in the names, which is fine for an object name. But as soon as you rely on the last name for, say, log or name generation, that's going to become a little bit of a problem. So we don't want to have that. Could also be a problem in the UPN prefix. So we need to do something about spaces in names. Also, I happen to know that our data can contain some duplicates, so this would be a problem as well. Now, the object name is covered, so that's not a problem. However, with the first name and last name, it's going to be an issue for generating a UPN and things like that. And lastly-- oh. So let's go back, sorry-- if we scroll all across to the right, you'll notice some of the attributes are coming across strangely, like company, department, and office. And that's because SuccessFactors actually stores the ID. But there's a workaround to this as well, which we'll cover shortly. So let's close this. We're not going to save the changes. What we're going to do is dive in and fix some of the problems one by one before we actually run the workflow for real. The first issue we're going to tackle is the spaces in the names, and there's a fairly easy fix to this. If we go to the MMC, let's just have a look at some configurations. So what I did to prepare, I've created a couple of virtual attributes. And you'll see them, last name formatted and first name formatted. And what we're going to do is strip out any spaces. We could also change any diacritic characters or do any other processing that we want. But for now, I'm just going to strip out the spaces and store them in these attributes. So let's go to our policy object-- Resilience, Barcelona. Let's take the logon name generation rule first and edit it. So what we want to do, Generation Rules, where we [INAUDIBLE], and give a name. We want to replace this with the new virtual attributes. So edit this, change this to formatted last name. Change this one as well. OK, so that part is done. Let's save that. Then we want to go to the sync service config and into the creation rules. And then what we're actually going to do is add a couple more rules, but they're going to be forward sync rules. But it's going to be generated by a PowerShell script. So here's one I did earlier. It's just a simple script to strip out the spaces. And this one's for first name. And we put it in the virtual attribute. Then we just repeat this process for the surname. Go back to the console, paste that in. Specify the attribute. Click Save and Continue. And if we now run it-- do a full run again. But it's always better to limit the scope when you're initially setting things up, making sure that you've got a variety of different employees so you can check the various combinations. So it's thinking about it. Let's have a quick look at the data. And if we take our friend Stephanie again-- and then just scrolling across, you'll notice there's no more spaces. So that's a good first step. Let's cancel that. We're not going to commit at this stage. The next issue we're going to tackle is the duplicate UPNs. Now, I'm not going to solve this in the sync service. I'm actually going to solve this in the MMC. So if we go across, what I've got is a Workflow, Standard User Creation. And what I've done is I've created an activity for this to generate a unique UPN. Let me drag that cross. And then I just need to set the suffix. And this relies on the two virtual attributes that we've created. So the spaces will already be stripped out, and then it will just generate a unique number. So let's save this. Now let's fix the issue with the ID-based attributes. In this case, we're going to address this by making a configuration change in the SuccessFactors connector in Starling Connect. We can do this because SuccessFactors happens to use a concept of navigators to allow to go from the employee to pull data in from other tables. So we can use these navigators to create custom attributes, and that'll pull back the data that we want. Now, this is why it's really, really important to engage with an HR SME to make sure you do understand what data you're getting and how you're getting it and when you're getting it. So let's go into the connector. We're going to connect. Choose the connector. We have to edit it. Of course, we have to enter our credentials again. That's accepted. So now what we can do is use the custom attributes. So the one we want is company name dot nav. Now, for SuccessFactors, it is case sensitive. If you get the case wrong, then it won't work. Let me save that. Add another attribute for department, departmentNav, Department Name, save that. And lastly, one for location. Scroll down and save that. So we're all good on this side. Let's minimize that. Now we need to go into here into the sync workflow and change the creation rules. So where we have Company, we need to edit this. We change this attribute for the navigator attribute. Luckily, they're in alphabetical order, and this suits our particular attributes. So we do Department next. Lastly, we do Location. The names do look a bit strange, but we're the only people that are going to see them so it's not really a big deal. Now we're in a position to run it, so we'll run it again. Again, this takes 30 seconds or so whilst it works out all the changes, what objects have got to be created. And then once it's successfully worked out what it's got to do, we'll have a quick look, make sure the data is there as we expect it, and then commit the changes. So 138 users to be created. And if we scroll across, you'll see that we've got company, department, and location now. So let's close this, and let's commit the changes. It takes approximately a minute, a minute and a half to create all the user objects. So we'll just let this run. Hopefully, assuming I haven't missed any steps, we'll see 138 created. The creation is almost finished, just the last 20 objects to create. But as you can see, it's run through pretty smoothly with no errors. Great, all done. So let's close this. And obviously, to prove it, we'll just go to the MMC, we'll go to our Users OU. We'll refresh it. And then we have all the users created, as per the configuration. Now that we've covered off on the creation of user objects, let's work on updating them. First, we need to add a new synchronization step, and this one will be an update. It's pretty much going to be very similar to the creation. So we'll just go through this. Most of the rules will actually be the same. We're just going to add manager to it. We don't need to worry about the updating criteria because in this case, it's only going to update the users we've already created. We don't need to worry about the ID because the ID should never change. But all the other attributes, we do want to change. So let's start with given name. [UPBEAT MUSIC] And we're going to add manager into the mix now. So I'll take the managerId, and I've created a virtual attribute to store this. I'm not going to worry about moving objects or renaming objects at this time. This is just standard functionality. Let me click Finish. Now, the managerId, we will get an ID. So what we've got is a workflow configured-- and I'll quickly show you this-- if we come to here and we go to Policies, Workflow. I've just got a simple workflow to set the manager-- or clear the manager, if that may be the case. It's basically going to look at the ID, search for the user object. If it can find it, it's going to update it. If not, it's going to leave it as is. Let's go back to the sync console, and now we're in a position to test it. Let's run the sync. Click the Run Now button. We'll deselect the creation because we just want to test the update. We're going to do a full run. So it's going to go and work out the changes, of which I would expect 138 updates because managerId is being brought across now. It's got all the data from AD, so it's just pulling it from SuccessFactors. It's 138, as expected. Let's have a look. Now, we haven't actually changed any of the data within SuccessFactors, so that's not really a problem. But if we just scroll across, what we'll see is the managerId. So let's close that. And let's commit these changes. And that's completed successfully, as expected. And just to show that it's worked properly, let's find one of the users that's had their manager updated. So I happen to know Colombo-- if I can find him-- here he is. He has one of the managers. And as you can see, that's been set properly. So that's been updated. So the update is working fine. Next step will be to configure the provisioning. The deprovision step's pretty easy to configure. So let's get started. We go back to the sync console. We're going to add another synchronization step. This time, we choose deprovision. No surprises, but we choose SuccessFactors as a source connector. We wait for it to come up with an Employees. And this time, we're going to select the option to make sure it gets deleted or if it goes out of scope. But I'm going to cheat. I'm going to add some criteria so I don't delete everything. It's just really to show you that it works. So what I'm going to do is just limit it just to show you-- is exactly-- let's see-- have that one, click OK. So really, it's only going to deprovision any users with this job title, of which I happen to know I've got one. So let's go next. AD's target system, of course, User, next. And I'm just going to say initiate deprovisioning. I'm not going to worry about any of the other settings. And just click Finish. Now we can test it. So we do a run now. Let's just test the provisioning. As with all these things, it takes a little while. It takes about 30 seconds or so. And as expected, we have one user to be deprovisioned. And this is Luis Cabrera, happens to be the first entry in the OU, so that's nice and easy. Let's just commit it, hoping well it won't take very long. And that's been deprovisioned, so we can close that. Now we can go back to the OU and check. Just do a refresh. And we can see Luis has been deprovisioned. This completes the configuration of an effective dated sync. And effective dated, as I mentioned earlier, is just about the current values. All we would need to do now is schedule the workflow and let it run according to the schedule. In the next session, we're going to start looking at the future-dated sync and the complexities that come with that. Future-dated sync is all about thinking changes that have been made but are not yet effective. For example, someone may change department in one month's time. That will be seen as a future-dated sync. Now, in terms of Active Roles, there's probably only a few use cases that we're interested in, and I'm going to take you through what some of these could be. The SuccessFactors HR connector provides future-dated sync in the form of a separate object. If you can remember, in the beginning, we actually enabled the flag to separate effective and future-dated objects. Let's start by setting up a mapping. So for this, we need to go back to the sync service console. Go to Mapping. We go to the SuccessFactors Connector. And now we're going to add a mapping pair. So in this case, we're going to select a different mapping. And we're going to say future-dated employees. Click Next. Then for the target, it's going to be AD again. Finish. Now, if we drill into this, we'll add a mapping rule. Now, it's important that we add the same mapping rule that we did for employee to make the transition from a new hire that's coming down the pipe into an employee seamlessly. So we pick ID. And we take employee number again. Now we can run the mapping, and we'll do a full map. Now the mapping has completed. You'll see we've got 138 objects it's found that we need to map. Now, bearing in mind, this is separate from the employee, so it's a separate mapping, which is why we're seeing 138. Let's commit these changes. Now we've done that, we can start on the sync workflows. In order to create the sync workflow, it's exactly the same as we did for the employee. We just go to Workflows, Add Sync Workflow, and give it a name. I'm going to call this one SuccessFactors Future Dated to AD. A future-dated sync may be a new hire, it may be an update to an existing employee, or it could be a termination. One of the more useful use cases for the future-dated sync is pre-creating an account so the manager can either add access or order a computer or do some other things that he needs to do to ensure that everything is fully up and running by the time the employee starts. So let's start with a creation-provisioning step. So add synchronization step. Now, this is basically the same as we've done before. We select Creation. We select SuccessFactors as the source system. Now it's important that we change this to FutureDatedEmployees. We don't need to specify any creation criteria because any existing users will be mapped to the employee. So therefore, any user that doesn't exist, by definition, must be a new hire. Target will be AD. And, of course, it will go to the user. It's thinking about it. So now we'll select the same details that we had before, including the OU we're going to provision into. So it's Resilience, Barcelona, Accounts, Users. We're going to use the same rule, so this is going to be a rule, starting with the family name. OK, adding comma space, then the given name. [UPBEAT MUSIC] And then we click Next. The rules for the future-dated employee are going to be the same as we did for the normal employee, so let's configure these now. We're going to use the same initial password-- not recommended for production environments, of course. For user account options, I'm just going to leave them default. User must change password at next logon, and account is disabled. Now, if we leave it disabled, you're going to need to bring across the hire date and make sure you've got a process in Active Roles to detect when the hire date is reached and enable the account. But that's standard Active Roles configuration, so we're not going to cover that today. And that's the creation step completed. Now we're going to look at updates of future-dated objects. So in my opinion, it's only worth updating the user object if you're still in the prehire phase. You don't want to make changes if the employee exists already. They might be changing department in two weeks' time, so you don't want to change it today. So what we're going to do is we're going to set up an update, but we're going to limit it to only the prehires. Because things may change. They may change department. They may change the date they start. The line manager might change. All kinds of things can happen during the recruitment process. So when the object becomes live, when the employee actually starts, you want him to have the latest information. So let's create the first update step. SuccessFactors is going to be the source system, of course. We need to make sure we're using FutureDatedEmployees again. But this time, we're going to specify some updating criteria, and we're going to add a condition. And in this case, we're going to use a scripted condition. And I have a little function called isPrehire. And all this function does is check today's date versus the hire date. Let's go back. Let's paste this in. Now we can click Next. Now we can specify the target, which is going to be AD, user object. And now we're going to specify all the rules that we did for the employee. So bear with me for a minute. As before, I'm not going to bother with any move objects or rename objects at this time. That's standard functionality. And that's the update. So this is an update for a prehire. Now, I don't see any benefit in adding an update if they're already an existing object because that should be covered by the employee object. However, there is one exception to this, and we're going to cover that in a second. The exception to the update is really just to determine if a prehire has been terminated. So the hire could be rescinded, the guy might decide he doesn't want to join. All these things can happen during the recruitment process. When the object disappears, we don't want to use a deprovisioning step because that would remove the employee object. So what we'll do is we'll add another update step, but we're going to add some criteria again. So let's add a new synchronization step. Again, it's going to be Update. Again, it's going to be from SuccessFactors and the FutureDatedEmployee. And this time, we're going to add some criteria to determine if it's a hire rescinded. So again, we're going to use a little script to do this. And based on my testing, if you create an employee that hasn't started yet and then you terminate that employee, SuccessFactors sets the termination date to be the same as the hire date. So that's what we're going to check for in case of this script. So it's just a case of getting the hire date and the end date of the object to work out is this going to end before the hire date, in which case it's termination. It's exactly-- let's set that value to true. And this will filter out. And next. In terms of the target system will be AD, of course. It's a user object. But in this case, we only want to set one attribute. Oh. Actually, we don't want an attribute. We want some text. And it's going to be 1. And the attribute we're going to do is edsva deprov type. And that will trigger the deprovision. So if we pick up there's a hire rescinded, then it's going to trigger deprovision of the precreated account. Now, obviously, in the Active Roles workflow, you can send a notification to that manager, but one assumes that he's getting that from HR anyway. This concludes the session on syncing HR data to Active Roles using Starling Connect. I hope you found it useful. The key takeaways are, it's really not that difficult, but you do need to work with your HR people, you do need to engage with the HR SMEs, and you really do need to understand the data that you're getting, including the data quality, what data you get and when you get it. I hope you found it useful. Any questions? [UPBEAT MUSIC]