Provisioning Policy Configuration by Resource Type
This reference provides resource-specific configuration details for provisioning policies in EmpowerID. Each section focuses exclusively on what is unique to that resource type. For universal procedures on creating and assigning policies, see Creating and Managing Provisioning Policies.
Active Directory User Accounts
Object Type Selection
When creating an AD account provisioning policy:
- In the Object Type To Provision dropdown, select AD Account.
Prerequisites
- EmpowerID must be connected to Active Directory
- RET provisioning and RET deprovisioning must be enabled on the Active Directory account store
General Configuration
Directory
Select your Active Directory domain in which accounts are to be provisioned. The dropdown will be filtered to show only Active Directory security boundaries.
Object Class
Select User for standard user account provisioning. In some LDAP-based AD implementations, you may select inetOrgPerson.
Creation Path
Optional. Click the Select an External Location link to browse and select a specific OU. If left blank, EmpowerID uses RBAC mappings between EmpowerID Locations and AD OUs.
Best Practice: Leave blank to leverage RBAC mappings, providing flexibility as organizational structures change.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the account as RET-managed without modification
- Move — Moves the account to the OU specified by the policy or RBAC mapping
- Delete and Recreate — Deletes and recreates the account
- Publish Workflow Event — Executes custom workflow code
On Transform Action:
- Do Nothing — Updates RETID only, no other changes
- Move — Moves the account to the OU specified by the new policy
- Delete and Recreate — Deletes and recreates the account with new settings
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; account becomes unmanaged
- Deprovision — Permanently deletes the account
- Disable — Disables the account but does not delete it
- Disable and Move — Disables the account and moves it to a specified OU (typically "Disabled Users")
- Publish Workflow Event — Executes custom workflow code
Advanced Configuration
OU to Move Disabled Users (Available when Revoke Action = "Disable and Move")
Specify the target OU for disabled accounts. Use the Browse function to select the appropriate container.
Creation Location Path Resolver Assembly / Type
Leave empty unless using a custom resolver assembly for dynamic OU determination based on complex business logic.
Exchange Mailbox (On-Premise)
Object Type Selection
When creating an Exchange mailbox provisioning policy:
- In the Object Type To Provision dropdown, select Exchange User Mailbox.
Prerequisites
- EmpowerID must be connected to Active Directory
- You must have an Active Directory with an Exchange Organization
- RET provisioning and RET deprovisioning must be enabled on the Active Directory account store
General Configuration
Mailbox Load Balancing Group
Enter the mailbox load balancing group name. This determines which Exchange server will host the mailbox.
If unsure, consult your Exchange administrator for the appropriate load balancing group.
Exchange Organization
Enter the name of your Exchange Organization. This is typically the name configured during Exchange deployment (e.g., "Contoso," "First Organization").
Depends on Resource System
Select the Active Directory domain with the Exchange Organization. This specifies that the user must have an AD account in that domain before provisioning the mailbox.
Exchange mailboxes require an existing Active Directory account in the same domain. Ensure AD account provisioning policies are in place and have higher priority (lower priority number) than Exchange policies, or that accounts already exist for target users.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the mailbox as RET-managed. If a mailbox already exists, it is simply claimed without modification.
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; mailbox remains active
- Deprovision — Permanently deletes the mailbox
- Disable — Disables the mailbox (mailbox is hidden from address lists and cannot be accessed)
- Publish Workflow Event — Executes custom workflow code
Transform Action is not applicable to Exchange mailboxes and is not displayed during policy creation.
Office 365 User Accounts
Object Type Selection
When creating an Office 365 account provisioning policy:
- In the Object Type To Provision dropdown, select Office 365 Account.
Prerequisites
- Your organization must have a licensed corporate Office 365 account
- You must have a licensed corporate Office 365 account and have connected EmpowerID to Azure AD
- RET provisioning and RET deprovisioning must be enabled on the Azure AD account store
General Configuration
Tenant
Enter or select your Office 365 tenant identifier. This is typically your organization's domain name (e.g., "contoso.onmicrosoft.com").
Office 365 Subscription
Select the subscription from which licenses will be assigned. After selecting the subscription, you can choose specific licenses to be granted to users provisioned by this policy.
Available licenses are displayed based on your subscription. Select all licenses that should be included for users provisioned by this policy.
Users can be assigned multiple licenses through a single policy. Select all licenses that represent the standard entitlement for the target population.
Email Suffix
Select or enter the appropriate email suffix (domain) for user accounts. This determines the UPN suffix and primary SMTP address for provisioned users.
Example: @company.com or @subsidiary.company.com
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the account as RET-managed without modification
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; account remains active
- Deprovision — Permanently deletes the Office 365 account
- Disable — Disables the account (blocks sign-in)
- Publish Workflow Event — Executes custom workflow code
Transform and Move actions are not applicable to Office 365 accounts, as Office 365/Azure AD does not use an OU structure.
Home Folders
Object Type Selection
When creating a home folder provisioning policy:
- In the Object Type To Provision dropdown, select Windows Home Folder.
Prerequisites
- EmpowerID must be connected to Active Directory
- RET provisioning and RET deprovisioning must be enabled on the Active Directory account store
- A File Server must be added to EmpowerID as a managed resource system
General Configuration
Directory
Select the inventoried Active Directory account store. Home folders are typically provisioned in conjunction with AD accounts.
Profile Drive Letter
Select the drive letter where home folders created by the policy are to be mapped on user workstations.
Share Folder
Specify whether the folder should be created as a shared folder accessible via network path.
Options:
- Yes — Folder is created as a network share
- No — Folder is created as a local directory only
Typical Configuration: Yes (to enable network access)
Share as Hidden
Specify whether the share should be hidden (ends with $ to hide from network browsing).
Options:
- Yes — Share name will be suffixed with
$(e.g.,JohnDoe$) - No — Share is visible in network browsing
Security Note: Hidden shares do not provide security; they only prevent casual browsing. Rely on NTFS permissions for actual access control.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the home folder as RET-managed. If a home folder already exists at the expected path, it is claimed without modification.
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; home folder remains in place
- Publish Workflow Event — Executes custom workflow code (typically used for archival or data retention workflows)
Deprovision and Disable actions are not applicable to home folders. Folder deletion is typically handled through custom workflow events to ensure proper data retention and backup procedures.
Salesforce User Accounts
Object Type Selection
When creating a Salesforce account provisioning policy:
- In the Object Type To Provision dropdown, select Salesforce Account.
Prerequisites
- You must have a corporate Salesforce account and have connected EmpowerID to Salesforce
- RET provisioning and RET deprovisioning must be enabled on the Salesforce account store
General Configuration
Directory
Select the inventoried directory for your Salesforce account. This represents the Salesforce instance (production, sandbox, etc.) where accounts will be provisioned.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the Salesforce account as RET-managed without modification
- Delete and Recreate — Deletes and recreates the account
- Move — Marks the account as RET-managed (Move has limited applicability in Salesforce)
- Publish Workflow Event — Executes custom workflow code
On Transform Action:
- Do Nothing — Updates RETID only, no other changes
- Delete and Recreate — Deletes and recreates the account with new settings
- Move — Updates RETID (limited applicability)
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; account remains active
- Deprovision — Permanently deletes the Salesforce account
- Disable and Move — Deactivates the Salesforce account (Salesforce uses "Deactivate" rather than "Disable")
- Publish Workflow Event — Executes custom workflow code
In Salesforce, accounts are "deactivated" rather than "disabled." A deactivated user cannot log in but the account and associated records are retained. The "Disable and Move" action translates to account deactivation in Salesforce.
Microsoft Dynamics AX User Accounts
Object Type Selection
When creating a Dynamics AX account provisioning policy:
- In the Object Type To Provision dropdown, select Default.
Prerequisites
- EmpowerID must be connected to Microsoft Dynamics AX (DAX)
- RET provisioning and RET deprovisioning must be enabled on the DAX account store
Dynamics AX (DAX) has two types of users: Active Directory users and Claims users. By default, DAX provisions all users as Claims Users. To create both types of users through RET policies, create separate policies for each type and use Configuration Parameters to specify the account type.
General Configuration
Resource Type
Select User Account.
Resource System
Select your inventoried DAX User resource system from the dropdown.
Object Class
Enter User.
Creation Path
Optional; typically left blank for DAX accounts as they do not use a hierarchical structure like AD.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the DAX account as RET-managed without modification
- Delete and Recreate — Deletes and recreates the account
- Move — Marks the account as RET-managed and applies any necessary updates
- Publish Workflow Event — Executes custom workflow code
On Transform Action:
- Do Nothing — Updates RETID only, no other changes
- Delete and Recreate — Deletes and recreates the account with new settings
- Move — Updates RETID and applies policy changes
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; account remains active
- Deprovision — Permanently deletes the DAX account
- Disable — Disables the account
- Disable and Move — Disables the account (Move is not typically applicable in DAX)
- Publish Workflow Event — Executes custom workflow code
Configuration Parameters (Required for Active Directory User Type)
If you are creating a provisioning policy for DAX users with an Active Directory user account type (rather than Claims users), you must add a configuration parameter:
- On the policy View page, expand the Add Configuration Parameters accordion.
- Click the Add button.
- Enter the following information:
- Name:
accountType - Configuration Value:
Active Directory User
- Name:
- Click Save to save the parameter and close the pane.
- On the main page, click Save.
If this provisioning policy is for DAX users with the Claims user account type, you do not need to add any configuration parameters. Simply save the policy after configuring the general and lifecycle settings.
ServiceNow User Accounts
Object Type Selection
When creating a ServiceNow account provisioning policy:
- In the Object Type To Provision dropdown, select Default.
Prerequisites
- EmpowerID must be connected to ServiceNow
- RET provisioning and RET deprovisioning must be enabled on the ServiceNow account store
General Configuration
Resource Type
Select User Account.
Resource System
Select your inventoried ServiceNow resource system from the dropdown. This may represent a production instance, sandbox, or other ServiceNow environment.
Object Class
Enter User.
Creation Path
Click the Select an External Location link and then search for and select your ServiceNow location. This typically represents the ServiceNow instance or organizational structure within ServiceNow.
Available Lifecycle Actions
On Claim Action:
- Do Nothing — Marks the ServiceNow account as RET-managed without modification
- Delete and Recreate — Deletes and recreates the account
- Move — Marks the account as RET-managed and applies any updates
- Publish Workflow Event — Executes custom workflow code
On Transform Action:
- Do Nothing — Updates RETID only, no other changes
- Delete and Recreate — Deletes and recreates the account with new settings
- Move — Updates RETID and applies policy changes
- Publish Workflow Event — Executes custom workflow code
On Revoke Action:
- Do Nothing — No changes; account remains active
- Deprovision — Permanently deletes the ServiceNow account
- Disable — Deactivates the account (ServiceNow uses "active" flag)
- Disable and Move — Deactivates the account
- Publish Workflow Event — Executes custom workflow code
ServiceNow accounts are controlled by an "active" boolean field. The Disable action sets this to false, preventing login while retaining the account record and associated tickets, tasks, and history.
Other Resource Types
This reference covers the most commonly configured resource types in EmpowerID (Active Directory, Exchange, Office 365, Salesforce, ServiceNow, Dynamics AX, and Home Folders).
For resource types not detailed above—such as Azure AD User, WebEx Account, Box Account, SAP ABAP User, LDAP Account, SharePoint User Profile, Universal Connector Account, and others—follow the standard policy creation procedures in Creating and Assigning Provisioning Policies.
Configuration Approach
Configuration fields are context-sensitive and display based on:
- The selected Object Type To Provision
- Your configured account store connections
- The capabilities of the target system
Common configuration patterns apply across all resource types:
| Configuration Element | What to Specify |
|---|---|
| Directory / Resource System | Select the target system from your configured account stores |
| Object Class | Specify the appropriate class (e.g., User, inetOrgPerson, system-specific classes) |
| Creation Path | Specify where resources should be created, or leave blank to use RBAC mappings |
| Lifecycle Actions | Configure Claim, Transform, and Revoke actions based on system capabilities |
Lifecycle Action Availability
The availability of specific lifecycle actions (Claim, Transform, Revoke options) depends on the capabilities of the target resource system and the EmpowerID connector. Most systems support:
- Claim: Do Nothing, Publish Workflow Event
- Transform: Do Nothing, Publish Workflow Event
- Revoke: Do Nothing, Deprovision, Disable, Publish Workflow Event
Account-based systems (AD, Azure AD, LDAP) typically support Move and Delete/Recreate actions as well.
Custom Workflow Events
For systems requiring specialized provisioning logic, use the Publish Workflow Event option in conjunction with custom workflows developed in Workflow Studio. This provides flexibility for:
- Integration with external APIs
- Multi-step provisioning processes
- Complex approval workflows
- Data transformation and validation
- Post-provisioning configuration tasks
Resource Type Comparison Matrix
| Resource Type | Claim Actions Available | Transform Actions Available | Revoke Actions Available | Requires Dependencies | Creation Path Applicable |
|---|---|---|---|---|---|
| AD Account | Do Nothing, Move, Delete/Recreate, Workflow | Do Nothing, Move, Delete/Recreate, Workflow | Do Nothing, Deprovision, Disable, Disable/Move, Workflow | No | Yes (OU structure) |
| Exchange Mailbox | Do Nothing, Workflow | N/A | Do Nothing, Deprovision, Disable, Workflow | Yes (AD Account) | No |
| Office 365 Account | Do Nothing, Workflow | N/A | Do Nothing, Deprovision, Disable, Workflow | No | No |
| Home Folder | Do Nothing, Workflow | N/A | Do Nothing, Workflow | Typically (AD Account) | Yes (File Server path) |
| Salesforce Account | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Deprovision, Disable/Move, Workflow | No | No |
| Dynamics AX | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Deprovision, Disable, Disable/Move, Workflow | No | No |
| ServiceNow | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Delete/Recreate, Move, Workflow | Do Nothing, Deprovision, Disable, Disable/Move, Workflow | No | Yes (Instance/Org) |
Dependency Management
Some resource types require other resources to exist before they can be provisioned. Understanding and configuring these dependencies is critical for successful automated provisioning.
Specifying Dependencies
When creating a policy for a resource type that has dependencies, use the Depends on Resource System field in the General configuration section.
Example: An Exchange Mailbox policy should 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.
Common Dependency Chains
Basic Employee Provisioning Chain:
- Active Directory Account (no dependencies)
- Exchange Mailbox (depends on AD Account)
- Home Folder (typically depends on AD Account)
- Application Accounts (may depend on AD Account for authentication)
Priority Configuration for Dependencies: When multiple policies have dependencies, configure priorities to ensure proper provisioning order:
- AD Account Policy: Priority 10
- Exchange Mailbox Policy: Priority 20
- Home Folder Policy: Priority 30
- Application Accounts: Priority 40+
This ensures resources are provisioned in dependency order when a user is assigned to a role.
Handling Dependency Failures
If a dependent resource is not available when a policy attempts to provision:
- The provisioning action will fail with an error in the Resource Entitlement Inbox
- The error message will typically indicate the missing dependency
- Once the dependency is satisfied, the Resource Entitlement Recalculation Job will retry provisioning
- Administrators can also manually retry failed items from the Errored Items tab
Related Articles
- Provisioning Policies Overview - Conceptual information about how provisioning policies work
- Creating and Managing Provisioning Policies - Step-by-step procedures for creating and assigning policies