This article explains how HelloID Provisioning entitlement actions correspond to the familiar CRUD user account lifecycle, and provides additional information about them.
All entitlement actions described here take place during enforcements. Enforcement is the process during which entitlements are granted/revoked/updated, thus moving Persons' target accounts through the lifecycle stages. A single enforcement may include target accounts in all different stages of the user lifecycle.
The "Create," "Enable," "Disable," "Update," or "Delete" designations are not explicitly built into HelloID Provisioning. You will not find these designations anywhere in the Provisioning dashboard. Rather, in HelloID these stages are implied by the current status of relevant entitlement actions.
The User Account Lifecycle
Otherwise known as "onboarding", account creation happens when a Person is granted an Account entitlement. When this happens, a new account is created in the target system, in a disabled state.
A target system account is enabled when the Account Access entitlement is granted. The user can now log in to the account.
To give users immediate access to new accounts, grant the Account and Account Access entitlements together, in a single business rule.
Otherwise known as "offboarding", an account is disabled when the Account Access entitlement is revoked. The target account is deactivated and the user is subsequently denied access to it.
Entitlement (Group Membership / Permission) Grant
When a group membership entitlement is granted to a Person, the target account is added to the corresponding user group in the target system.
When a permission (custom entitlement) is granted to a Person, the permission's Grant PowerShell script is triggered.
To manually retry a failed grant action, see Retry grant.
The Update stage is a special stage of enforcement. It occurs not in response to specific entitlement grants or revokes, but rather when certain trigger conditions exist.
There are currently two trigger conditions:
- A new snapshot has been created, in which fields have changed in Person or Contract objects.
- A business rule which grants a permission (a custom entitlement) has been set to filter on Contract data, and there has been a change in which Contract(s) qualify a Person for the business rule. For example, a Person was previously qualified for the business rule based on Contract 1, but is now qualified for the business rule based on Contract 2. This can happen as a result of changed data in the Contracts themselves, or as a result of edited filter criteria in the business rule.
When at least one trigger condition exists, the following two actions occur:
- Any changed fields in Person or Contract objects which are mapped to target systems are updated in the target account(s), accordingly.
- The Update scripts are executed for permissions in the involved business rules. Typically, these permissions are configured to use sub-permissions, and the update scripts alter which sub-permission(s) the Person has been granted.
Entitlement (Group Membership / Permission) Revoke
When a group membership entitlement is revoked from a Person, the target account is removed from the corresponding user group in the target system.
When a permission (custom entitlement) is revoked from a Person, the permission's Revoke PowerShell script is triggered.
To manually revoke an entitlement, outside of the normal enforcement process, see Unmanage.
An account is deleted when the Account entitlement is revoked. The account is permanently removed from the target system.
Entitlement action order (dependencies)
The following chart shows the order in which HelloID resolves entitlements during an enforcement.
There are eight solid blocks, divided into three types:
- Grant: Account Grant, Account Access Grant, Permission Grant
- Revoke: Account Revoke, Account Access Revoke, Permission Revoke
- Update: Account Update, Permission Update
These are the eight entitlement actions in HelloID. They are described in relation to the CRUD lifecycle in the above section, The User Account Lifecycle.
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 resolution).
Arrows indicate the type of dependency:
- Critical (solid arrow): The dependent entitlement action will not be run until all dependencies have been successfully resolved (i.e., successfully granted, revoked, or updated, as appropriate for their type). 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 (dashed arrow): The dependent entitlement action will not be run until either 1) all dependencies have been resolved regardless of result (i.e., success or failure), or 2) 24 hours have passed since the dependent entitlement action was initiated.
Note that dependent entitlement actions are not immediately triggered upon the resolution of their dependencies. Rather, HelloID Provisioning periodically checks for and runs pending actions.
This status of all entitlement actions is reflected on the Entitlements Overview.
The final section in the chart, "Depends on," describes the order of entitlement resolution when you're sharing data between target systems.