Joiner Mover and Leaver Processes

Owned by Phillip Hanegan
Last updated: Aug 09, 2021
5 min read

EmpowerID automates the lifecycle of identities through the Joiner, Mover, and Leaver phases. These events are typically detected and triggered based on changes occurring to the employee record in an HR or other authoritative system through an inventory connector. HR account records are initially inventoried into the system as orphan accounts lacking a related Person object. The EmpowerID Account Inbox permanent workflow and queue processes these orphan accounts to determine if they can be joined to an existing Person object or if a new Person object should be created. Changes in the authoritative system for job title, job role, and/or location code, country, department or other fields may trigger a Mover event based on logic configured in location mappings. EmpowerID handles Mover events such as these through the Business Role and Location Recompiler Job. Unplanned Leaver events can be initiated manually via an EmpowerID workflow, while planned Leaver events are most often triggered by the VaildUntil date set on Person objects by HR and processed by logic in a permanent workflow.

Joiner Process

Because of the key role of Person objects in EmpowerID, the process by which EmpowerID joins inventoried accounts to these objects is foundational to how EmpowerID manages your user identities. As mentioned in the Inventory topic, when EmpowerID inventories a resource system with user accounts, it does more than just write a copy of those user accounts to a table in the EmpowerID Identity Warehouse. It evaluates those accounts to determine whether or not they are owned by users, and based on that evaluation it does one of the following three things:

  • It ignores them;

  • It joins them to existing EmpowerID Persons;

  • It provisions new EmpowerID Persons, joining those new Persons to the accounts

Mover Process

The Mover process occurs when a person in an organization changes his or her job function and or the organizational location in which they work. The Mover event is important, as access should be reevaluated to ensure that any missing access required for the new role is provisioned and that access no longer needed is removed. A Mover event can be initiated manually using one of a variety of workflows to change a person’s primary Business Role and Location in EmpowerID. These workflows constitute a move and will trigger the reevaluation of RETs and other types of access policies. More commonly, Mover events are triggered based on changes to a person’s job title/code or department ID assignment in the HR system. Typically, these changes flow into EmpowerID via the connector as changes to the External OrgRole (Business Role) and External OrgZone ( Location) assignments for the person's user account. When these change, the EmpowerID Business Role and Location Compiler Job leverages the mappings of these external roles and locations to determine which changes should occur to the person’s internal EmpowerID Business Roles and Locations. If changes need to occur, the job adds the changes to a queue to be processed by the Business Role and Location Processor job.

In some cases, this default mechanism is not adequate to handle the logic for determining a Mover event. As an example, in some organizations an external location change within a business unit does not constitute a Mover event.

Leaver Process

EmpowerID provides organizations the ability to automate the disabling and eventual deletion of EmpowerID Persons and all user accounts linked to those Persons based on the value of the ValidUntil attribute set on those Persons. This type of termination automation, known as the "Advanced Leaver" or "Planned Leaver" event differs from unplanned Leaver events, which are typically performed by an administrative user via the EmpowerID web user interface.

The process involves a number of account store and resource system settings, EmpowerID system settings, workflows, Sets and SetGroups. Each of these settings can be enabled and configured to run based on your own particular security needs. Sets and SetGroups are configured out of the box but can be customized as needed.

  • Directory Clean Up Enabled — This setting specifies whether the Submit Account Terminations permanent workflow should claim the account store for processing account terminations. When enabled, accounts in the account store that meet the qualifications are moved into a special OU within the external directory and disabled.

  • Report Only Mode (No Changes) — When enabled, EmpowerID generates a report of what the Directory Clean Up process would do if it was fully implemented. The process itself is ignored and all accounts are set to Termination Pending.

  • OU to Move Stale Accounts — This setting specifies the external directory in which to move accounts marked for termination. This setting only appears on account stores with OUs, such as Active Directory.

The below image shows the Directory Cleanup Settings on an example account store.

 

Pre-Termination Process:

  1. The GUID of the LeaverTerminationPreTerminationSetGroupGUID account inbox setting is used to claim people marked for termination.

  2. The PreLeaverThresholdOnPerson setting account store setting is used as a threshold to compare with the number of people claimed above.

  3. If the number of people claimed for termination reaches the threshold, an approval task is created and sent to all people belonging to the Management Roles configured in the PersonTerminationsAdminManagementRoleGUIDS setting.

  4. SubmitPersonTerminations permanent workflow runs continuously, calling the Person.GetPendingTerminationNotProcessed stored procedure to collect all EmpowerID Person objects meeting the below criteria:

    • ValidUntil IS NOT NULL

    • AND ValidUntil < GETUTCDATE()

    • AND TerminationBusinessProcessTaskID IS NULL

    • AND Deleted = 0

    • AND IsNUll(PersonOrganizationStatusID, -1) <> 8

  5. Any Person objects meeting the above criteria The EmpowerID Persons—and all user accounts linked to those EmpowerID Persons—are disabled and the PersonOrganizationStatusID field for each qualifying Person is updated to 8, meaning Termination Pending.

  6. Next, any Person object with an ValidUntil date greater than the number of days configured for the PersonTerminationGracePeriod EmpowerID System setting is submitted to the “TerminatePersonAdvanced” workflow using the identity set for the TerminsatePersonAdvancedInitiator EmpowerID System setting.

  7. As a last step in the permanent workflow logic, the workflow calls the Custom_Person_GetPendingTerminationNotProcessedPendingTermination stored procedure to collect any Person objects matching reactivation criteria. These criteria are as follows:

    • ValidUntil IS NOT NULL AND ValidUntil > GETUTCdate()

    • AND TerminationBusinessProcessTaskID IS NULL AND Deleted = 0

    • AND IsNUll(PersonOrganizationStatusID, -1) = 8

    • AND TerminationDate IS NULL