Enforcement
Enforcement is the process during which HelloID Provisioning performs Grant, Revoke, and Update actions on Entitlements.
To get started, manually Run an enforcement, or Add a schedule with enforcement enabled.
Every organization's user accounts go through a "CRUD" lifecycle: Create, Enable, Update, Disable, Delete. These stages correspond to an employee's status in the organization, from onboarding, to role changes, to promotions, to eventual offboarding. In HelloID, this lifecycle is controlled by entitlements. For example, a granted Account entitlement creates an account, and a granted Account Access entitlement enables the account. Oppositely, a revoked Account Access entitlement disables the account, and a revoked Account entitlement deletes an account.
Important
For an enforcement to do anything at all, at least one of the following must be true:
Something in a source system's configuration (source mappings, display name formatting, primary contract & manager determinants) has changed since the last enforcement, and a new snapshot has been generated.
One or more Business rules have been modified since the last enforcement.
If neither of these are true, running an enforcement does nothing. To preview the actions that will occur during the next enforcement, see Evaluation.
Related features include:
Update accounts: writes certain changes into Target systems which are not normally be included in an enforcement.
Retry failed action: retries a single entitlement action that failed during an enforcement, without performing another full enforcement.
Re-enforce an entitlement: re-enforces only a single granted entitlement, without performing a full enforcement.
Run with resources: runs a standard enforcement (Run an enforcement), but additionally processes Resources just prior to the enforcement. If resources fail, there is no stop condition. The enforcement continues and all entitlement actions are still attempted. However, any entitlements which depend on failed resources will also fail.
Every enforcement has three steps: Grant, Revoke, and Update.
In the Grant step, HelloID Provisioning grants all pending entitlements (i.e., grants all entitlements slated for addition as per changes in business rules).
These include:
Account Create
Account Access Enable
Group Membership Add
Permission Add
To manually retry a failed grant entitlement action, Retry failed action. Or, to re-enforce a currently granted entitlement, Re-enforce an entitlement.
In the Revoke step, HelloID Provisioning performs all pending revoke actions (i.e., removes all entitlements slated for removal as per changes in business rules).
These include:
Account Delete
Account Access Disable
Group Membership Remove
Permission Remove
To manually revoke an entitlement, Edit a business rule and/or Edit a condition, such that the relevant person(s) are no longer slated to receive the entitlement. To preview your changes, Run an evaluation. The entitlement will be revoked during the next Enforcement.
Compare to the Unmanage step, which removes the entitlement state from HelloID without removing the actual entitlement in the target system.
Tip
If there is a conflict in which an entitlement would be both unmanaged and revoked during an enforcement, the unmanage action overrides the revoke action.
The Update step is a special step in enforcement. It occurs when at least one of the following trigger conditions are met:
A new snapshot has been generated since the previous enforcement, in which at least one field has changed. See Source snapshots.
A business rule exists which assigns a Permission entitlement, and it has a contract condition (see Contract conditions), and the specific in-conditions (qualifying) contract has changed for at least one in-scope person.
For example, person X was previously qualified for the business rule based on contract Y, but is now qualified for the business rule based on contract Z.
Important
This may occur due to changed data in the contracts themselves, or due to changes in the Conditions of the business rule.
When at least one of these trigger conditions is met during an enforcement, both of the following actions occur:
Any changed data in the latest snapshot is written into target accounts.
For all Permission entitlements in the business rule, the update code is executed (i.e., the Update block if the permission uses a Single permission script with sub-permissions, or the Update permission script if the permission uses Separate permission scripts without sub-permissions.)
The Unmanage step is a special step, which causes an entitlement's state to be forgotten in HelloID, but without removing the granted entitlement itself in the external target system (e.g., the user account or group membership).
It occurs in three situations:
You manually Unmanage an entitlement.
You Remove a business rule and select Delete And Keep Unmanaged.
You Remove an entitlement from a rule and then Publish a rule, with the Unmanage Removed Entitlements toggle enabled.
When an entitlement is unmanaged, all running and pending enforcement actions for it are canceled.
Compare to the Revoke step, which removes the actual entitlement in the external target system, and not merely the entitlement's state in HelloID.
Unmanaging an entitlement does not prevent the same entitlement from being granted again to the same target account in the future.
Tip
If there is a conflict in which an entitlement would be both unmanaged and revoked during an enforcement, the unmanage action overrides the revoke action.
During an enforcement, HelloID performs entitlement actions in a specific order, based on their dependencies. Dependencies can be critical or non-critical.
Critical dependency: An entitlement action must be completed successfully before the dependent action can run. The dependent action will only run once all critical dependencies are resolved (i.e., granted, revoked, or updated successfully).
For example, an Account entitlement will not be revoked until all Account Access and Permission entitlements for that account have been successfully revoked.
Non-critical dependency: A specific entitlement action is preferably completed before the dependent action but not required. The dependent action will proceed when either 1) an attempt has been made to resolve all non-critical dependencies (regardless of success or failure), or 2) 24 hours have passed since the dependent entitlement action was initiated.
For example, an Account Access entitlement will be revoked after an attempt has been made to revoke all Permissions entitlements for that account (whether the attempt was successful or not), or after 24 hours.
Note
Dependent entitlement actions are not immediately triggered upon the resolution of their dependencies. Rather, HelloID Provisioning periodically checks for and runs pending actions in batches.
Tip
To view the current status of entitlement actions, View running & pending actions.
The table below shows the critical and non-critical dependencies of entitlement actions in the same system.
For each entitlement action at the left:
The "Waits for" column lists entitlement actions that must be performed successfully first (critical dependencies).
The "Waits max. 24 hours for" column lists entitlement actions that are preferably performed first but do not prevent execution (non-critical dependencies).
The following table uses the same structure to list additional critical and non-critical dependencies of entitlement actions if the system depends on another system, i.e. when you're using the Share account fields between target systems feature.
Here, system A is dependent on system B.
Dependencies chart
This chart depicts all dependencies of entitlement actions.
The "Grant", "Revoke", and "Update" rows show the dependencies of entitlement actions in the same system.
The "Depends on" row shows how entitlement actions are dependent on entitlement actions in another system.
There are eight solid blocks, divided into three types:
Semi-transparent blocks indicate the dependencies for each of these entitlement actions (which are themselves entitlement actions; hence, the chart depicts the order of entitlement action resolution).
Arrows indicate the type of dependency:
A solid arrow indicates a critical dependency.
A dashed arrow indicates a non-critical dependency.