Handle long-term leaves and former employees safely

Last modified 26 Nov 2025 13:43 +01:00
Table of Contents

In this module, you will test behavior of your midPoint configuration regarding leavers—be it people on long-term leave or former employees.

In this guide, long-term leave stands for cases such as 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 after their leave ends.

In the second part of the module, you will test your midPoint configuration for former employees. Accounts of former employees need to be disabled and their accounts should be deleted after a defined period of time automatically. You will use disabled instead of delete and delayed delete activation concepts of midPoint to first disable such users and their AD account, and plan the later deletion of the AD account.

What awaits you in this module

  1. Verify long-term leave handling

    1. Set a user status in the HRIS to Long-term leave

    2. Verify the user is Suspended in midPoint and Disabled in LDAP.

    3. Set the user status in the HRIS back to In and verify they are back to Active and Enabled in midPoint and LDAP.

  2. Confirm leavers are safely deleted from the LDAP server after a grace period.

    1. Set a user status in the HRIS to Former employee

    2. Verify the user is Archived in midPoint and Disabled in LDAP.

    3. Check the delayed-deletion trigger placed on the LDAP account.

    4. Confirm the user’s LDAP account has been deleted after the set grace period.

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 HRIS and observe how midPoint handles the case.

1.1. Update the user in HRIS

As always, all changes are initiated in the source HR information system. To update a user in the HRIS, use the same steps as in Verify handling source system data updates.

  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 Verify handling source system data updates.

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 LDAP projection, and check that the Administrative status is set to Disabled.

  • You can also check the user directly on the LDAP server. The disabled status is mapped there to the roomNumber user attribute because LDAP 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 LDAP accounts disabled. That is because they should not have an access to the accounts, 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 user who is returning in HRIS—set their Status back to In.

  2. Wait for the recurring reconciliation task to run.

  3. Check the user’s Lifecycle state, Effective status, and Administrative status of their LDAP 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. For this work, pick a user on which to simulate leaving the employment. In this module, 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 on LDAP

Once the reconciliation task picks up the changed employment status of the user’s account, 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 LDAP resource (mapped to the roomNumber user attribute).

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

    • If you have used values suggested by this guide, the grace period before the account is actually deleted is five minutes.

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 2025-11-23 07:57:19".

To act upon triggers, there is the 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 LDAP 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/LDAP 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 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.

Was this page helpful?
YES NO
Thanks for your feedback