Skip to main content

Provisioning Policies Overview

Provisioning Policies, also known as Resource Entitlements (RETs), are policies that govern how resources—such as Active Directory accounts, Exchange mailboxes, Office 365 accounts, home folders, and application accounts—are automatically granted to users based on their organizational identity attributes. These policies enable organizations to automate the provisioning, moving, disabling, and deprovisioning of resources throughout the identity lifecycle.

When provisioning policies are in place, EmpowerID evaluates them each time a person is provisioned or newly assigned to any of the following actor types:

  • Business Role and Location (BRL) — Commonly derived from HR data, defining job functions and organizational placement
  • Management Role — Functional responsibilities that can be assigned to BRLs or directly to individuals
  • Group — Security or distribution groups that determine resource access
  • Query-Based Collection (SetGroup) — Dynamically generated groupings based on attribute filters
  • Individual Person — Direct assignments when needed (not considered true birthright)

When a policy is targeted to an actor, every person belonging to that actor receives the entitlements specified by the policy. Users receive all Resource Entitlements assigned at or above their primary and secondary Business Roles and Locations. When multiple policies of the same type apply, a priority value determines precedence, with lower numbers having higher priority.

Common Scenario

If your company employs contractors along with standard employees, you could configure RET policies to automatically provision an Active Directory account, a mailbox, and a home folder each time a new employee is onboarded, but only provision an Active Directory account (within a different OU) and a mailbox for contractors. In the event a contractor becomes a standard employee, or an employee becomes a contractor, these policies could take the appropriate action and do things like move the user accounts for those people to the OU that corresponds to their role as well as provision or de-provision resources accordingly.

Policy Target Visualization​

The following diagram illustrates how a provisioning policy can be assigned to multiple RBAC actor types:

The RET policy in the center can be assigned to any or all of these RBAC actor types. When a policy is assigned to an actor, all people who belong to that actor automatically receive the resources specified by the policy.

Flexible Assignment

Provisioning policies can be targeted against any number or combination of Management Roles, groups, Business Roles and Locations, Query-Based collections, as well as individual people.

How Provisioning Policies Work​

Policy Evaluation and the RET Inbox Process​

Provisioning policies rely on a two-step processing system to evaluate and enforce entitlement rules systematically across all applicable systems.

Step 1: Resource Entitlement Recalculation Job​

The Resource Entitlement Recalculation Job runs on a scheduled basis and scans all defined provisioning policies to determine:

  • Who now qualifies for a new entitlement and should be provisioned
  • Who no longer qualifies and should be deprovisioned
  • Whether any users need their resources moved or transformed due to role changes

For each user-resource relationship identified, the recalculation job generates a record and places it into the Resource Entitlement Inbox. This inbox serves as a holding queue that tracks all provisioning events awaiting action.

Step 2: Resource Entitlement Inbox Processor Job​

The Resource Entitlement Inbox Processor Job processes each inbox item and carries out the necessary action, whether that's provisioning a new resource, moving an existing one, disabling it, or fully deprovisioning it based on the policy configuration.

Resource Tracking with RETIDs​

When resources are provisioned through provisioning policies, EmpowerID stores the RETID (Resource Entitlement ID) of the policy as a property on the resource. EmpowerID also "claims" existing resources and stamps them with the RETID of the policy that would have led to them being provisioned if they did not already exist.

For example, if a person already has an Exchange mailbox and moves into a role with a policy that calls for mailboxes, EmpowerID will update the ResourceEntitlementID field for that mailbox in the Identity Warehouse, stamping it with the RETID. The RETID is then used to:

  • Track why resources have been provisioned
  • Determine when they should be moved or deprovisioned
  • Identify when a person is lacking resources that should be provisioned

If a Resource Entitlement is deleted, any provisioned resources automatically have their RETID set to NULL and are considered "normal" resources. These resources will be ignored by the RET Inbox and remain joined to their Person objects. New policies created later will claim those resources rather than provisioning new ones.

Process Status Codes​

EmpowerID maintains detailed information about any RETs processed by the Resource Entitlement Inbox processor. The Process Status codes provide feedback on the current processing status:

  • 0 — Not processed
  • 1 — In progress
  • 2 — Completed
  • 3 — Error
  • 4 — Ignored

Policy Actions: Claim, Transform, and Revoke​

Provisioning policies define specific actions that occur at different stages of the identity lifecycle. Understanding these actions is essential to configuring policies that align with organizational requirements.

On Claim Action​

Claiming occurs when EmpowerID discovers a person with a resource that matches a policy they're assigned, but the resource is not marked as having been provisioned by a RET. The Claim action marks the resource as RET-managed and triggers the specified Claim Action.

info

Because RETs require users to have accounts, EmpowerID enables any disabled user accounts it finds during a claim action if that account is linked to an EmpowerID Person meeting the claim condition.

Available Claim Action options:

  • Do Nothing — No changes are made; the resource is simply marked as RET-managed
  • Move — For user accounts, moves the object to the OU specified by the RET or as determined through RBAC mappings
  • Delete and Recreate — Deletes and recreates the resource (not available for all resource types)
  • Publish Workflow Event — Executes custom workflow code for advanced scenarios

Example: If a user already has an Active Directory account and is placed in a Management Role targeted by an AD account policy, EmpowerID marks that account as RET-managed. If the policy's Claim Action is set to "Move," the account will be moved to the appropriate OU.

On Transform Action​

Transforming occurs when a person with a resource provisioned by one RET policy receives an equivalent RET from a different policy. This typically happens when a person changes their Business Role or Location. The Transform Action marks the resource with the new RET policy number and triggers the specified Transform Action.

Available Transform Action options:

  • Do Nothing — No changes are made
  • Move — Moves the resource to the location specified by the new RET policy
  • Delete and Recreate — Deletes and recreates the resource with the new policy settings
  • Publish Workflow Event — Executes custom workflow code

Example: An employee moves from "Sales Representative in New York" to "Sales Manager in Chicago." Both roles have AD account policies, but with different OU targets. The Transform Action set to "Move" will relocate the user's AD account to the Chicago OU without deleting and recreating it.

On Revoke Action​

Revoking occurs when a person who received a resource via a RET no longer receives the RET policy, typically due to a change in Business Role, Location, or termination.

Available Revoke Action options:

  • Do Nothing — No changes are made to the resource
  • Deprovision — Deletes the resource
  • Disable — Disables the resource but does not delete it
  • Disable and Move — Disables the resource and moves it to a specified location (e.g., a disabled users OU)
  • Publish Workflow Event — Executes custom workflow code

Example: When an employee is terminated, their Business Role and Location assignment is removed. If the AD account policy's Revoke Action is set to "Disable and Move," the account will be disabled and moved to the "Disabled Users" OU.

Workflow Event Actions​

For each of the three action types (Claim, Transform, Revoke), you can optionally specify a Workflow Event that triggers custom workflow logic. The RET action will "fire" this event, which then initiates all workflows that subscribe to the event.

Requirements for event workflows:

  • Must have an input property of type Resource named "resource" (case sensitive)
  • The RET process passes in the Person's RET resource (Account, Home Folder, Exchange Mailbox, etc.) for further processing

This enables advanced scenarios such as:

  • Custom notifications to managers or security teams
  • Integration with external ticketing systems
  • Complex deprovisioning logic that archives data before deletion
  • Compliance reporting triggers

Throttling and Approval Controls​

EmpowerID provides throttling and approval mechanisms to prevent large-scale automatic changes and ensure governance over sensitive operations.

Throttling Settings​

Administrators can configure thresholds to suspend batches that exceed specified limits:

  • All Provisions Require Approval — Every provisioning action requires manual approval before execution
  • All Deprovisions Require Approval — Every deprovisioning action requires manual approval before execution
  • Require Approval if Provision Batch Larger Than Threshold — Sets a numeric value that triggers approval requirements when exceeded in a single run
  • Require Approval if Deprovision Batch Larger Than Threshold — Sets a numeric value that triggers approval requirements when exceeded in a single run

Example: If the deprovisioning threshold is set to 100, and the Recalculation Job identifies 150 accounts for deprovisioning, the entire batch will be suspended and flagged for manual review in the Resource Entitlement Inbox. Administrators can then approve or reject items individually or as a group.

Resource Entitlement Inbox​

The Resource Entitlement Inbox provides visibility into all provisioning events and serves as the control center for approval workflows. The inbox is organized with filters and tabs:

  • Pending Approval — Items requiring administrative review before processing
  • Pending Batches — Groups of actions suspended due to throttling rules
  • Approved/Rejected — Historical logs of reviewed actions
  • Errored Items — Failed provisioning attempts with error messages for troubleshooting

Each record includes:

  • Entitlement type (e.g., AD account, Exchange mailbox, Salesforce account)
  • Associated resource system
  • Action being taken (grant or revoke)
  • Current status and any error messages

Administrators can:

  • Approve entire batches with a single action
  • Selectively approve or reject individual records
  • Export data for offline reporting and compliance audits

Account Store Configuration Requirements​

For provisioning policies to function, the target account stores must have RET provisioning and deprovisioning enabled. These settings are accessible from the configuration screen for the account store in Configuration Manager.

Allow RET Provisioning​

This setting allows or disallows the Resource Entitlement Inbox process to auto-provision accounts for users who receive RET policy-assigned accounts but have not yet had them provisioned.

When enabled, EmpowerID will automatically create accounts in the target system based on policy assignments.

Allow RET Deprovisioning​

This setting allows or disallows the Resource Entitlement Inbox process to auto-deprovision accounts for users who still have RET policy-assigned accounts but no longer receive a policy that grants them an account.

warning

Deprovisioning only occurs if the deprovision action on the Resource Entitlement policy is set to Deprovision. If set to Disable or Do Nothing, accounts will not be deleted even if this setting is enabled.

Naming Conventions​

For account provisioning via RETs or in workflow processes, EmpowerID ensures logon name uniqueness automatically by adding a sequential suffix (01, 02, etc.) to the end of the generated name when a collision is detected.

Naming convention workflow shapes in the creation workflows for major object types (Person, Account, Group) can be completely customized in Workflow Studio. RET provisioning of new accounts is not handled by workflow processes but can still be customized through:

  • Custom naming convention plugins
  • Creation location path resolvers
  • Attribute mapping configurations

AD/LDAP Account Creation Location Logic​

When provisioning users automatically via RET policies into Active Directory or LDAP directories, EmpowerID must determine into which OU a person's account should be provisioned.

Default Logic​

The default logic follows the RBAC mapping for the Location portion of a Person's Business Role and Location to create the account in the Account Store OU mapped to that EmpowerID Location.

Example: If "Sales Representative in New York" is mapped to OU=Sales,OU=NewYork,DC=company,DC=com, accounts for users in that BRL will be created in that OU.

Custom Creation Path Resolvers​

In cases where the default logic is not suitable, EmpowerID allows the creation of a custom plugin in Workflow Studio to handle unique RET AD/LDAP Account Creation Location logic.

Custom resolvers can implement business rules such as:

  • Provisioning based on department codes combined with geographic regions
  • Dynamic selection of OUs based on user attributes
  • Complex multi-factor logic that considers job role, manager hierarchy, and cost center

To use a custom resolver:

  1. Develop the assembly in Workflow Studio
  2. Specify the Creation Location Path Resolver Assembly and Creation Location Path Resolver Type in the policy configuration
  3. The resolver will be invoked during provisioning to determine the target OU

Priority and Policy Conflicts​

When a person qualifies for multiple Resource Entitlements of the same type through different assignments, EmpowerID uses a priority value to determine which policy takes precedence.

How Priority Works​

  • Each policy assignment to an actor includes a priority value
  • Lower numbers have higher priority (e.g., priority 10 takes precedence over priority 100)
  • The policy with the highest priority (lowest number) is applied
  • If priorities are equal, the system uses the first policy assigned

Setting Priorities​

When assigning a policy to an actor (Business Role and Location, Management Role, etc.), you specify the priority for that assignment. This allows you to create a hierarchy of policies.

Example: A person who qualifies for multiple policies will receive the resource defined by the policy with the highest priority (lowest number).

Dependencies and Prerequisites​

Some resource types have dependencies on other resources. Understanding these dependencies is critical for successful policy implementation.

Specifying Dependencies​

When creating a policy, you can specify dependencies using the Depends on Resource System field. This ensures EmpowerID provisions resources in the correct order.

Example: An Exchange Mailbox policy would specify:

  • Depends on Resource System: Active Directory Domain (the domain where user accounts exist)

This ensures EmpowerID will only provision Exchange mailboxes for users who already have AD accounts in the specified domain.

Summary​

Provisioning Policies (RETs) provide powerful automation for identity lifecycle management in EmpowerID:

Core Capabilities:

  • Automatically grant birthright access based on organizational identity attributes
  • Maintain consistent resource provisioning across multiple systems (AD, Exchange, Office 365, applications)
  • Respond dynamically to identity lifecycle events (hire, transfer, termination)
  • Track and audit all provisioning through RETID stamping

Key Mechanisms:

  • RET Inbox Process — Two-step system (Recalculation Job + Processor Job) evaluates and executes provisioning
  • Lifecycle Actions — Claim, Transform, and Revoke actions manage resources through role changes
  • Throttling Controls — Approval workflows prevent unintended mass changes
  • Priority System — Resolves conflicts when multiple policies apply to the same person

Implementation Requirements:

  • Target account stores must have RET provisioning/deprovisioning enabled
  • Policies must be assigned to RBAC actors (BRL, Management Role, Group, Query-Based Collection)
  • Dependencies between resource types must be configured (e.g., AD account before Exchange mailbox)

By combining proper lifecycle action configuration, throttling controls, priority management, and dependency handling, organizations can implement robust automated provisioning that scales with business needs while maintaining security and compliance.

Next Steps: See Creating and Assiging Provisioning Policies for step-by-step procedures.