Introduction

Without entitlements, business rules won't do anything. During the enforcement process, entitlements are what business rules give or take away from an end user, based on the specified rule conditions. 

Entitlement types

There are five types of entitlement: Account, Account Access, Group Membership, Permission, and Dynamic Permission. Not all target systems support all five types.

Account

A user account in the target system. When granted by HelloID Provisioning, a new account is created for qualifying Persons. Accounts are created in a disabled state, until access is granted by the Account Access entitlement.

Account Access

Grants access to user accounts after they have been created by the Account entitlement. This is a separate entitlement because organizations frequently want to issue disabled accounts prior to a user's start date, and then only activate the account when the user is onboarded. Read more about the user account lifecycle.

Group Membership

Adds the user account to a selected group in the target system. Most target systems have a separate entitlement per available group. A group is not necessarily a HelloID group—unless HelloID is being used as the target system.

Note that when setting thresholds, Group Membership entitlements are subsumed under Permission threshold settings.

Permission (PowerShell target systems only)

Permissions are custom entitlements for PowerShell target systems. Although you can include whatever arbitrary PowerShell code you want (e.g., to query the target system's API), custom entitlements are typically used to add users to groups in the target PowerShell system. Once created, you can assign custom entitlements like all other entitlements, via business rules. Permissions are defined on the target PowerShell system's Permissions tab.

Dynamic Permission (PowerShell target systems only)

Dynamic permissions are similar to standard permissions, but more powerful. The difference is: 

• Standard permissions only have Grant and Revoke stages. Their entitlements are granted or revoked based on the binary condition of whether a Person is inside or outside of a business rule's scope. Only grant and revoke actions are possible, and they only occur when a Person enters or exits the scope.
• Dynamic permissions, on the other hand, have Grant, Revoke, and Update stages. During the Update stage, they are triggered for re-evaluation. This occurs whenever an enforcement is run and the Person or an in-conditions Contract object has changed since the last enforcement. Thus, their granted entitlements can be "dynamically" modified while a Person remains in-scope of the same business rule. Most often, dynamic permission are used to grant customized entitlements whose details depend on Contract data that is frequently updated in the organization's source system.

For example, suppose you need to assign users to groups in your target PowerShell system, based on the department listed in their primary Contract. Suppose your organization has 20 departments.

• Using standard permissions, you would have to create 20 business rules each with its own standard permission and condition. Whenever a Person's department changes, they would exit the scope of one business rule and enter another. 
• By contrast, you can accomplish the same thing with a single dynamic permission. You simply write a PowerShell script which grants membership to a target group corresponding to the primary Contract's department variable. Then whenever any Person's department has changed during an enforcement, the rule is re-evaluated and group membership is dynamically updated as needed. Throughout this process, the Person remains in scope of the same business rule. The only thing that changes is the specific variation of the granted entitlement (in this example, the target group).

In this way, a single business rule containing a dynamic permission can potentially replace dozens of separate business rules each containing a standard permission. Each variation of the entitlement contained in a dynamic permission is defined in PowerShell, to let HelloID track the state of granted entitlements. The specific variation granted is displayed in the Persons Overview and elsewhere where entitlements are shown in HelloID Provisioning. See Entitlements granted by dynamic permissions.

Dynamic permissions are defined on the target PowerShell system's Permissions tab.

Add or modify an entitlement

You can add or modify entitlements while adding a new business rule or editing an existing one. You can only do so after you've added a target system.

Select the plus (+) button in the Entitlements section. This will bring up a list of your configured target systems.

In the left-hand column, select the target system for which you want to add the entitlement. This displays a list of available entitlements.

Select the plus (+) button next to the entitlements that you wish to apply as part of this business rule. Then select the Close button to confirm. The selected entitlements appear on the business rule page:

Select the Save button to save the rule to draft, or the Save & Publish button. Only published rules will be run during an enforcement.

Delete an entitlement

To delete an entitlement from a business rule, select its trashcan icon, and then the Save or Save & Publish button (see above for more info). The next time the rule is enforced, the deleted entitlement will be removed from the end users (group membership removed, account disabled or deleted, etc).