HelloID

Read the current person's sub-permissions from $entitlementContext ($eRef) (PowerShell v1) or $actionContext.CurrentPermissions (PowerShell v2) and write them into $currentPermissions.

Defines the sub-permissions which will be granted to the current person, for the current standard permission in this permission set.

Since group membership control is the most common use case, the $desiredPermissions block in the PowerShell template is pre-configured for it. It reads the Department.ExternalId and Department.DisplayName from each in-conditions contract, and writes them into $desiredPermissions.

Note that these keys & values are merely used by HelloID to track the state of the sub-permissions. Your business logic goes in the Compare and grant, Compare and revoke, and Update blocks.

Check $desiredPermissions against $currentPermissions to determine which desired permissions must be granted. Write them into $subPermissions, then grant them using API calls into the target system in the if not $dryRun block.

Check $currentPermissions against $desiredPermissions to determine which current permissions must be revoked. Write the remaining permissions into $newCurrentPermissions, then revoke the others using API calls into the target system in the if not $dryRun block.

If the current operation is update ($operation in PowerShell v1, $actionContext.Operation in PowerShell v2), then update each permission in $newCurrentPermissions using API calls into the target system in the if not $dryRun block.

The update block is the "engine" of sub-permissions. It is where you dynamically select the specific sub-permissions granted to the current target account, for the current standard permission.

In PowerShell v1, you must return $subPermissions to HelloID inside $result. This lets HelloID track the state of the sub-permissions.

In PowerShell v2, HelloID automatically parses $outputContext.SubPermissions, and you should not explicitly return it.