Handle long-term leaves and former employees safely

Table of Contents

Test behavior of your midPoint configuration regarding leavers—be it people on long-term leave or former employees.

What awaits you in this module

In this guide, long-term leave stands for cases like parental leave. Such users and their accounts should be disabled. It is important, though, to avoid deleting their accounts, because the employees are expected to return and use continue using their accounts thereafter.

You will confirm that focal objects (users) and their Active Directory projections (accounts) are disabled as required when the HRIS user status changes to Long-term leave. Subsequently, you will check that the users have their accounts reactivated when they return from the long-term leave.

In the second part of the module, you will test your midPoint configuration for former employee handling (i.e., true leavers). Accounts of former employees need to be disabled and then deleted after a defined period of time automatically. For this delayed delete, midPoint uses the disabled instead of delete and delayed delete activation rules you have set up earlier.

1. Employee goes on long-term leave

The first case we are to cover is when employees leave on long-term leave. You will update the leaving employee in the HR information system and observe how midPoint handles the case.

1.1. Update the user in HRIS

As always, all changes are initiated in the HRIS. To update a user in the HRIS, use the same steps as in link.

  1. Pick a user to update, e.g., Martin Knight (employee number: 1006).

  2. Update their Status to Long-term leave.

  3. Export HRIS users to CSV.

1.2. Let automation handle the updates

Wait for the recurring HRIS reconciliation task you have already up and running to pick up the changes.

1.3. Check the results

Verify how the change was handled using the same steps as in link.

These should be the results:

  • The Lifecycle state of the user Martin Knight is set to Suspended.

  • The user’s Effective status is Disabled (displayed in the top-right corner of the screen).

  • In the user’s profile, go to Projections, select the AD projection, and check that the Administrative status is set to Disabled.

  • You can also check the user directly on the AD server. The disabled status is mapped there to the roomNumber user attribute because AD does not support user activation natively.

User Martin Knight is suspended due to his long-term leave
Figure 1. User Martin Knight has been suspended due to going on long-term leave

Users who are on the long-term leave in the HRIS are suspended in midPoint. Users inactive in midPoint, in turn, have their AD accounts disabled. That is because they should not have access to the accounts, but you cannot delete them because the users are expected to return back to work at a later time.

1.4. After the employee returns

When their long-term leave ends, employees are about to return to work. They need their accounts back as they were before they left.

  1. Update the returning user in HRIS—set their Status back to In.

  2. Export HRIS users to CSV.

  3. Wait for the recurring reconciliation task to run.

  4. Check the particular user’s Lifecycle state and Effective status, and the Administrative status of their AD projection. They should be Active and Enabled.

2. Employee leaves for good

The second exercise in this module is similar to the first but with some added points. Pick a user on which to simulate leaving the employment. In examples herein, we use Martin Knight (employee number: 1006) again.

2.1. Update the user status in HRIS

  1. In the HRIS user interface, modify the user’s Status to Former employee.

  2. Export HRIS users to CSV.

  3. Wait for the recurring HRIS reconciliation task to pick up the change.

2.2. Verify the user is deactivated and waiting for deletion in AD

Once the reconciliation task picks up the changed employment status of the user, you have configured midPoint to:

  • Set the user’s Lifecycle state to Archived.

  • Set the user’s Effective status to Disabled (displayed in the top-right corner of the screen).

  • Disable the account on the AD resource (mapped to the roomNumber user attribute).

  • Set up the trigger for delayed deletion of the AD resource account.

When you are on the user profile screen, it is not enough to refresh the page to see the updates made by the reconciliation task to the user (such as changed lifecycle state). You need to go Back to the user list, and open the user profile again.

2.3. Check the delayed delete trigger

The delayed delete activation rule places a trigger on accounts that are to be deleted instead of having them deleted right away. In laymen terms, the trigger says, for instance, "delete this AD account on 2026-04-23 07:57:19".

To act on triggers, there is a trigger scanner task which periodically scans objects with triggers. Once it discovers an object with a trigger the time of which is in the past, it performs the action specified in the trigger.

For a trigger to be fired, its time stamp must be in the past. That means triggers are never fired earlier than at the time specified by their time stamp. On the other side, the action may be delayed depending on the schedule of the trigger scanner task.

By default, the trigger scanner task is scheduled to run every 5 minutes. In the Docker image prepared for this guide, it is set to 1 minute. You can check and change the schedule in Server tasks > System tasks > Trigger scanner > Schedule. You can also use the Run now button there if you do not want to wait for the next scheduled run.

Trigger scanner schedule configuration screen
Figure 2. Trigger scanner schedule configuration screen

The trigger is stored in the midPoint shadow object corresponding to the resource account. It is not stored in the user’s focal object nor in the actual account on the remote resource.

Once the trigger is in place:

  1. Go to the user’s profile in midPoint.

  2. Click Projections.

  3. Select the AD resource.

  4. Hover your mouse over the account icon to see the timer.

The AD account for user Martin Knight is pending deletion
Figure 3. The AD account for user Martin Knight pending delete

If you are on the Docker images prepared for this guide, you can check accounts with triggers using the AD account notices dashboard:

  1. Under Dashboards, select AD account notices.

  2. Click More info on the Users with accounts with triggers tile to list users with triggers on any of their accounts.

  3. Click More info on the Accounts with triggers tile to list accounts with triggers.

  4. Click More info on the Users without AD accounts to list users without an AD account.

    • This number will grow by one once the grace period for Martin Knight’s AD account expires.

AD notices dashboard showing one account is pending delete
Figure 4. AD notices dashboard showing one account is pending delete
If you have renamed your AD resource…

The dashboard widget for showing the number of accounts without an AD account depends on the resource name. If you have renamed the AD resource to anything other than AD, the dashboard would wrongly show that all users in midPoint are without an AD account.

Should that be your case, either rename your AD resource to AD, or adjust the object collection used in the dashboard as follows:

  1. In Object collections, find and open for editing the collection Users without AD accounts.

  2. Click Edit raw.

  3. Edit the filter part of the collection:

    <filter>
    <q:text>
        linkRef/@ not matches (
        . type ShadowType
        and resourceRef/@/name = "AD" (1)
        and kind = "account" )
    </q:text>
</filter>
    1 Rewrite the quoted string so that it matches exactly the name of your target (AD/LDAP) resource.

  4. Click Save and go back to dashboards. The dashboard should show accurate data now.

Refer to Introduction to dashboards in midPoint to learn more about dashboards.

2.4. Confirm the AD account has been deleted

After the grace period elapses, the trigger scanner task catches the trigger and midPoint deletes the AD account projection for Martin Knight who is no longer entitled to have one because he left the company. For the account to be actually deleted on the resource, the recurring HRIS reconciliation task must run as well.

To verify the AD account has been deleted, check Projections for user knight in midPoint. He should have only the one for the HRIS; the AD projection should be deleted.

User Martin Knight’s projections contain only the HRIS now
Figure 5. User Martin Knight’s projections contain only the HRIS now

You can also use the AD account notices dashboard—the Users without AD accounts tile should now show one more account than before.

Finally, you can also access the AD/LDAP server directly to verify the account is not there anymore.

The user knight remains in midPoint because in the setup we use in this guide, we keep track of all users who have ever been part of the company, similarly to how a university keeps track of all students who have ever enrolled at the university.

Next steps

In the next module, you will test how the existing configuration copes with adding a new outbound mapping to the target resource.

link

Was this page helpful?
YES NO
Thanks for your feedback