Theshold for deactivating users in based on ExitDate

We also don't delete users in the HR-sync but we use the Update-quota on the Identity manager side in the sync from HR.

Hi Henrik,

Thank you for the reply. We should be able to handle mass-updates on other fields, like Phone, but not EndDate. We could create a separate mapping for EndDate and have quota on that, but I don't think that would be an ideal solution for us.

How do you update ExitDate today?

In our data model, an employee can have several employments (with different managers etc.) represented by objects in PersonInDepartment. One of these employments are marked as primary, and data from this primary employment is then pushed to Person with a table script. 

In the sync we are inserting and updating ExitDate (and other field relevant to the users employment) from HR to custom fields in PersonInDepartment. Then data from the primary employment is pushed to Person.

In our data model, an employee can have several employments (with different managers etc.) represented by objects in PersonInDepartment. One of these employments are marked as primary, and data from this primary employment is then pushed to Person with a table script. 

In the sync we are inserting and updating ExitDate (and other field relevant to the users employment) from HR to custom fields in PersonInDepartment. Then data from the primary employment is pushed to Person.

If you want to use a sync what yuou could do is do a sync between PersonInDepartment and Person and therefore take advantage of the quota in the sync. Otherwise you need to do that in the script that updates Person from PersonInDepartment..

We also have employees with multiple employments in our data model. We sync from HR to a custom table and then from that table to Person.

I haven't thought about this possibility. Are there any other advantages of using sync between two tables vs. a table script? The table script is updating Person immediately when there is a update on PersonInDepartment. With sync this would be on a schedule, right?

Sync is on a schedule, yes. I was told to be careful how to implement table scripts.

Do you get new information from HR once a day or regularly?

I mean, how do you get updates on PersonInDepartment? Isn't that done with a sync?

Yes, we have a sync from HR to PersonInDepartment that runs every 15 minutes

Let's say you set a quota that is 10% of all employees. Since the sync runs every 15 minutes, doesn't that mean that if the update quota comes in at 9% for more than one sync you won't be able to catch that?

Regarding the table script: that will run once for each update, and that's gonna be hard to catch if there are an unusual amount of updates..

Yes, therefore my initial thought was to implement this check in the VI_Person_Deactive_ExitDate_Expired script, which runs every morning.

You know what they say, there's two ways to skin a cat..