Efecte Provisioning Engine Orchestration

The Efecte Provisioning Engine (EPE) provides the possibilities to orchestrate the following activities: All connectors activities

For Active Directory:

• Activate/deactivate user.
• Add/Remove a user to/from a group(s).
• Create group.
• Creating a new user.
• Delete group.
• Delete user.
• Managing ProxyAddresses.
• Remove user attribute.
• Reset user password.
• Unlock user.
• Update group.
• Update user information.
• Update user Distinguished Name Value.
• Verify group.
• Verification of a user request before creating a new user.
• Verify group membership.

The Efecte Provisioning Engine uses Lightweight Directory Access Protocol (LDAP) interface for Active Directory and also towards OpenLDAP and IBM LDAP. Most of the Active Directory activities mention above are also available for these LDAP directories, depending on the EPE version in use.

For Microsoft Entra (Azure Active Directory):

• Activate/deactivate user account.
• Add/Remove a user to/from a group(s).
• Create group.
• Creating a new user.
• Delete group.
• Delete user.
• Reset user password.
• Update group.
• Update user information.
• Verify group.
• Verification of a user request before creating a new user.
• Verify group membership.

The orchestration node always has two possible outcomes: either the orchestration is completed or there has been an exception and the orchestration action could not be performed. Different follow up actions can be defined in case there is an exception such as an incident being recorded or a notification to the service desk to complete the action manually. Exceptions can also be that the attribute that should be affected in the external system is not present or the external system cannot be reached. For troubleshooting please take a look of ITSM logs and EPE (master and workers) logs.

To connect the Efecte Service Management tool and Efecte Provisioning Engine, it is necessary to configure several settings in the Platform Settings in Administration UI.

By default the properties which are needed to connect to Efecte Provisioning Engine are fetched from consul. This is why you have to set consul.enabled property to true. Then you can make sure, that “provisioning.configuration.consul” is enabled as well.

Efecte Provisioning Engine – Platform settings for consul:

When Consul is enabled all the needed configurations are defined for the Efecte Provisioning Engine:

Efecte Provisioning Engine - manual connection configuration:

Orchestration Activities for Active Directory

Activate/Deactivate User Account

Efecte Provisioning Engine AD orchestration node for activate/deactivate user account:

In the screenshot above admins choose the correct Active Directory “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. Inside this same node, administrators are able to choose the action what they are prefer to use “Activate” or “Deactivate”.

Activate/deactivate user account notes:

•  ‘Activating/Deactivating’ functionality here refers to setting 'useraccountcontrol’ Active Directory attribute to ‘512/514’ value (Enable/Disable)
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Add/Remove a User To/From a Group(s)

Efecte Provisioning Engine AD orchestration node configuration for removing user from a group(s):

In the screenshot above, the Person attribute configuration should point to the template where the orchestration node finds the user’s data. The Role attribute needs to be configured to define where the orchestration node finds the available roles (AD groupswhere the user should be removed). There might be single or multiple attribute groups configured in a “Role attribute”.

The list of available registered AD Tasks is fetched from the EPE-master. It is required to select the AD Task, because the Efecte Provisioning Engine orchestration node will use identity and access rights fields mapping to know, under which attribute code,  the user’s and AD group distinguished names are stored. Hence the mapping for distinguishedName JSON field, for both Identity and Access Right is required. If mapping won’t be found then the orchestration node will result in an “Exception” state.

Add/Remove a user to/from a group(s) activity notes:

• The result of a node will be in the “Completed” state only in the case when all user’s group memberships will be updated successfully. In the case when, for example, the user will be successfully removed from 5 out of 6 groups then the result of a node will be in the “Exception” state.
• The attempt to remove a user from a group which they do not belong will end as a failure.
• The attempt to add a user to a group to which he already belongs will end as a failure.
• Details about successfully/unsuccessful updated user’s group membership can be found in logs.
• From the EPE version 2020.2.0 forward there aren’t need to configure template codes for workflow.orchestration.personTemplateCode and workflow.orchestration.roleTemplateCode from system settings. Correct attributes, can be chosen directly from the node.
• Provisioning and group membership exceptions are optional properties on this workflow node. Admins can configure this properties in use where exceptions can be written if any exceptions exists during the provisioning actions.

Creating a Group 

Efecte Provisioning Engine AD orchestration node for creating a new group:

In the screenshot above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Access Rights Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The creating new user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

It is important to be sure, that Access Rights Mapping, being used in Create Group orchestration node, contains at least two additional Active Directory mappings: for “cn” and “sAMAccountName” attributes. Without them, Provisioning Engine will not calculate proper DistinguishedName for newly created group, and return with error. New Distinguished Name’s for groups are created based the given Common Name (CN) in the workflow and base search provided for “Target AD*”. Thus was, it is to recommended to have LDAP configuration with only one Search Base defined. If the given Common Name already exists in the AD, the workflow must include logic to create new unique CN for the user in question.

In 2025.1 release and newer, workflow editor Orchestration node  "Create group" activity, you can now directly set created entity's id directly to attribute (Created Entity Id), without using separate “Read Group's data” activity:

Create group orchestration activity notes:

• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Creating a New User 

Efecte Provisioning Engine AD orchestration node for creating new user:

In the screenshot above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The creating new user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

It is important to be sure, that Identity Mapping, being used in Create User orchestration node, contains at least two additional Active Directory mappings: for “cn” and “sAMAccountName” attributes. Without them, Provisioning Engine will not calculate proper DistinguishedName for newly created user, and return with error. Note: if those two mappings are missing on a given configuration, it will not be presented on a drop-down.

New Distinguished Name’s for users are created based the given Common Name (CN) in the workflow and base search provided for “Target AD*”. Thus was, it is to recommended to have LDAP configuration with only one Search Base defined. If the given Common Name already exists in the AD, the workflow must include logic to create new unique CN for the user in question.

In 2025.1 release and newer, workflow editor Orchestration node  "Create user" activity, you can now directly set created entity's id directly to attribute (Created Entity Id), without using separate “Read User's data” activity:

Creating new user activity notes:

• There are two ways to create the password for a new user for their first login.
  • Define “Default” password in the Provisioning Task -configuration view.
    • That password will only be used by users, when they login into the system for the first time.
  • Generating random password in the workflow and select into which attribute on Identity Mapping data-card it was written to.
  • In both cases the first time password “pwdLastSet” value is set to zero (0) to force a user to change their password after the first login.
  • From the EPE version 2020.3 forward we have implemented possibility to choose if the password must change at the first login or not. Administrators can make the selection for this directly from the workflow User Creation orchestration node.
• There are different ways to provide password for the first login for the end-user. Depending on customers needs it is possible to use workflow functionalities to send the password directly to the end-user via email or sms. Another option is to send the password for first login to the manager, who will provide it for the end-user. EPE’s Orchestration node itself DO NOT provide that functionality, it needs to be defined elsewhere.
• The configuration of “Target” is done in the provisioning task configuration view. For creating new users, admins needs to make sure that there exists only one LDAP userbase / LDAP userfilter in order to avoid conflicts on the workflow.
• From the EPE version 2019.4 forward we have implemented feature to filter out LDAP configs with duplicate mappings when using Create or Update User activity in the workflow.
  • With this improvement we are able to avoid errors from AD when creating/updating users. If there would be duplicate mappings, AD wouldn't know which attribute use to fill in it's properties.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.
• From release 2025.1 forward, Orchestration nodes "Create User" and "Create group" activities, you can now directly set created entity's id to attribute, without using separate “Read User's data” activity.

Delete Group

Efecte Provisioning Engine AD orchestration node for delete group:

In the screenshot above administrators can choose the correct Active Directory “Target”. The delete group orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

Delete user activity notes:

• For Active Directory-based configurations, 'Role group attribute' should contain group’s distinguishedName name.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Delete User

Efecte Provisioning Engine AD orchestration node for delete user:

In the screenshot above administrators can choose the correct Active Directory “Target”. The delete user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

Delete user activity notes:

• For Active Directory-based configurations, 'Person Attribute' should contain User's distinguishedName name.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Manage ProxyAddresses

Efecte Provisioning Engine orchestration node for managing proxyaddresses:

In the screenshot above administrators can choose the correct Active Directory “Target”. The Manage Proxyaddresses orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

There are three different possibilities: Set, Update and Remove proxyaddresses.

• Set: admin selects one attribute in ESM's Workflow UI (can be single or multivalue attribute) - Then Workflow Node, contacts AD, finds user account and set's the value into proxyAddresses (this action is used to set the value to proxyAddresses the first time - previous value in AD is null).
• Update: admin selects two attributes in ESM's Workflow UI - one for CURRENT value, and the other - the NEW value. Then Workflow Node, contacts AD, finds user account and updates the existing proxyAddresses, finds the CURRENT value in the list, and changes its prefix from: SMTP: to smtp: - and adds NEW value with prefix SMTP: (the other values remain in proxyAddresses).
• Remove: admin selects one attribute in ESM's Workflow UI (can be single or multivalue attribute) - Then Workflow Node, contacts AD, finds user account and removes the value from proxyAddresses list (the other values remain in proxyAddresses).

Manage ProxyAddresses activity notes:

• It's also possible to manage proxyaddresses with "Update user" orchestration activity, 
  but with this own activity we are able to handle project-specific use-case, which previously required more complicated Workflow solution.
  •    Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Remove User Attribute

Efecte Provisioning Engine AD orchestration node for remove user attribute:

In the screenshot above administrators can choose the correct Active Directory “Target”. The remove user attribute orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

In the property “Attribute(s) to remove” administrator can define the attribute, which will be removed from the Active Directory.

• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Reset User Password

Efecte Provisioning Engine AD orchestration node for reset user password:

In the screenshot above administrators can choose the correct Active Directory “Target”. The Reset user password orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. The Person and Password attributes should point to the template where the orchestration node finds the user’s data.

Reset user password activity notes:

• User password value “pwdLastSet” is set to zero (1), which means that a user doesn’t need to change their password in the first login.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Unlock User

Efecte Provisioning Engine AD orchestration node for unlock user:

In the screenshot above administrators can choose the correct Active Directory “Target”. The unlock user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

Unlock user activity notes:

• It’s important to take into account in the configurations, that 'Person Attribute' should contain User's distinguishedName name.
  •   Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Update a Group

Efecte Provisioning Engine AD orchestration node for update group:

In the screenshot above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Access RIghts Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The update group orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

Updating group activity notes:

• The configuration of “Target” is done in the provisioning task configuration view. For updating groups, admins needs to make sure that there exists only one LDAP groupbase / LDAP groupfilter in order to avoid conflicts on the workflow

Update User Information

Efecte Provisioning Engine AD orchestration node for update user information:

In the screenshot above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The update user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

Updating user activity notes:

• User password update is not supported on this orchestration activity.
• The configuration of “Target” is done in the provisioning task configuration view. For updating users, admins needs to make sure that there exists only one LDAP userbase / LDAP userfilter in order to avoid conflicts on the workflow.
• From the EPE version 2019.4 forward we have implemented feature to filter out LDAP configs with duplicate mappings when using Create or Update User activity in the workflow.
  • With this improvement we are able to avoid errors from AD when creating/updating users. If there would be duplicate mappings, AD wouldn't know which attribute use to fill in it's properties.
• EPE version 2020.2.0 provide new orchestration activity to “Manage ProxyAddresses” in order to clarify the actions. It’s still possible to use this activity for this feature. Please check more details from “Manage Proxyaddresses” activity description in this document.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Update User Distinguished Name Value

Efecte Provisioning Engine AD orchestration node for Update user Distinguished Name Value:

In the screenshot above administrators can choose the correct Active Directory “Target”. The Update user Distinguished Name Value orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

In the field “Current Distinguished Name Value*” admin must select, from which attribute on given template/data-card, ‘old’ name of AD location will be read. Field “New Distinguished Name Value* selects attribute from given template/data-card, which will be used as a name of new AD location.

Update user Distinguished Name Value Unit notes:

• With This activity admins are able for example to limit update action to ‘commonname’ attribute, but It’s required to give whole Distinguished value, example:
  Current Distinguished Name Value: CN=DemoAccount,OU=DemoUsers,DC=testad,DC=local
  New Distinguished Name Value: CN= DemoAccount,OU=OldDemoUsers,DC=testad,DC=local
• From EPE version 2020.2.0 forward this orchestration activity name has been changed from “Name of current Organization Unit” to “Update user Distinguished Name Value”.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Verify a Group

Efecte Provisioning Engine AD orchestration node for verification of a group request before creating a new group:

In the screenshot above, the Access Rights Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Access Rights Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Access Rights Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the group exists. It’s possible to select as many attributes from the Data Card as needed to confirm the uniqueness of a group. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successfull LDAP query results are saved, “true” if group was found or “false” otherwise.

Administrators has possibility to “check” Include OU subtree -property on this orchestration node to verify if group exists in the defined Organization Unit -subtree. If this administrator doesn’t select this option, orchestration node will only check the specific OU defined in the configuration.

Verify group activity notes:

• Verify Group activity - checks if all of the configured items for IF expression were already present in Access Rights Mappings.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Verification of a User Request Before Creating a New User

Efecte Provisioning Engine AD orchestration node for verification of a user request before creating new user:

In the screenshot above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Identity Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Identity Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the user exists. It’s possible to select as many attributes from the Person Data Card as needed to confirm the uniqueness of a user. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successfull LDAP query results are saved, “true” if user was found or “false” otherwise.

Administrators has possibility to “check” Include OU subtree -property on this orchestration node to verify if user exists in the defined Organization Unit -subtree. If this administrator doesn’t select this option, orchestration node will only check the specific OU defined in the configuration.

Verify User activity notes:

• Verify User activity - checks if all of the configured items for IF expression were already present in Identity Mappings.
• From EPE version 2021.1 forward it’s possible to It’s now possible to use multiple user search bases when using verify user orchestration activity.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

For example, if admin configured Identity Mapping like:

and in Orchestration node, chooses IF expression as:

Then, when Workflow runs, it reads Person's Title and Full Name (let's assume they were 'Test' and 'Me'), 
and asks Active Directory of User's existence with following query:

(&(name='Test')(cn='Me'))

Key point to understand this node's mechanics is - while forming IF expression, admin needs to use Template's attributes, but in fact, values read from them, will be translated (mapped) to proper Active Directory attributes, according to Identity Mapping configuration and will be passed to Active Directory as a search query.

Verify Group Membership

Efecte Provisioning Engine AD orchestration node for verify group membership:

In the screenshot above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Identity Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Identity Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the group exists. It’s possible to select as many attributes from the Data Card as needed to confirm the uniqueness of a group. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successfull LDAP query results are saved, “true” if user was found or “false” otherwise.

Verify Group Membership activity notes:

• Depending of the selected Role Attribute, you can choose, Single string value or Multi string value.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Orchestration Activities for Azure AD

Activate/Deactivate User Account 

Efecte Provisioning Engine orchestration node for Activate/deactivate user account in Azure AD:

In the screenshot above, admins choose the correct Azure AD “Target” and are able to view the Identity Mappings which are configured for selected Azure AD task. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view.  Inside this same node, administrators are able to choose the action what they are prefer to use “Activate” or “Deactivate”.

Activate/deactivate user account in Azure AD notes:

• ‘Activate/Deactivate’ functionality here refers to setting 'accountEnabled’ true if the account is enabled; otherwise, false.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Add/Remove a User To/From a Group(s)

Efecte Provisioning Engine orchestration node configuration for removing user from a group(s):

In the screenshot above, the Person attribute configuration should point to the template where the orchestration node finds the user’s data. The Role attribute needs to be configured to define where the orchestration node finds the available roles (Azure AD groups where the user should be removed). There might be single or multiple attribute groups configured in a “Role attribute”.

Add/Remove a user to/from a group(s) activity notes:

• The result of a node will be in the “Completed” state only in the case when all user’s group memberships will be updated successfully. In the case when, for example, the user will be successfully removed from 5 out of 6 groups then the result of a node will be in the “Exception” state.
• The attempt to remove a user from a group which they do not belong will end as a failure.
• The attempt to add a user to a group to which he already belongs will end as a failure.
• Details about successfully/unsuccessful updated user’s group membership can be found in logs.
• Provisioning and group membership exceptions are optional properties on this workflow node. Admins can configure this properties in use where exceptions can be written if any exceptions exists during the provisioning actions.

 
Create Group

Efecte Provisioning Engine orchestration node for creating new group to Azure AD:

In the screenshot above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Azure Active Directory “Target” and are able to view the Access Rights Mappings which are configured for selected Azure AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view.

It is important to be sure, that Access Rights Mapping, being used in Create Group orchestration node, contains at least four additional Azure AD mappings: for “displayName”, “mailEnabled”, “mailNickname” and “securityEnabled” attributes.

Create group orchestration activity notes:

• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.
• From release 2025.1 forward, Orchestration nodes "Create User" and "Create group" activities, you can now directly set created entity's id to attribute, without using separate “Read User's data” activity.

Creating a New User

Efecte Provisioning Engine orchestration node for creating new user to Azure AD:

In the screenshot above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Azure AD “Target” and are able to view the Identity Mappings which are configured for selected  tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The creating new user orchestration node read attributes from Data Cards in question and execute API call to Azure.

It is important to be sure, that Identity Mapping, being used in Create User orchestration node, contains at least three additional Azure AD mappings: for “displayName”, mailNickname and “userPrincipalName” attributes. Note: if those two mappings are missing on a given configuration, it will not be presented on a drop-down.

Creating new user activity notes:

• There are two ways to create the password for a new user for their first login.
  • Define “Default” password in the Provisioning Task -configuration view.
    • That password will only be used by users, when they login into the system for the first time.
  • Generating random password in the workflow and select into which attribute on Identity Mapping data-card it was written to.
  • In both cases the first time password “pwdLastSet” value is set to zero (0) to force a user to change their password after the first login.
  • From the EPE version 2020.3 forward we have implemented possibility to choose if the password must change at the first login or not. Administrators can make the selection for this directly from the workflow User Creation orchestration node.
• There are different ways to provide password for the first login for the end-user. Depending on customers needs it is possible to use workflow functionalities to send the password directly to the end-user via email or sms. Another option is to send the password for first login to the manager, who will provide it for the end-user. EPE’s Orchestration node itself DO NOT provide that functionality, it needs to be defined elsewhere.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.
• From release 2025.1 forward, Orchestration nodes "Create User" and "Create group" activities, you can now directly set created entity's id to attribute, without using separate “Read User's data” activity.

Delete Group

Efecte Provisioning Engine orchestration node for delete group:

In the screenshot above, administrators can choose the correct Azure Active Directory “Target”. The delete group orchestration node read attributes from Data Cards in question and execute API call to Azure.

Delete group activity notes:

• For Azure Active Directory-based configurations, 'Role group Attribute' should contain Group's uniqueID.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Delete User

Efecte Provisioning Engine orchestration node for delete user to Azure AD:

In the screenshot above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Azure AD “Target” and are able to view the Identity Mappings which are configured for selected Azure AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The delete user orchestration node read attributes from Data Cards in question and execute API call to Azure.

Delete user activity notes:

• For Azure-based - it should contain UPN (User Principal Name) of the User.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Reset User Password

Efecte Provisioning Engine orchestration node for reset user password:

In the screenshot above, admins choose the correct Azure AD “Target” to choose the Identity Mappings which are configured for selected AD task. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The Person and Password attributes should point to the template where the orchestration node finds the user’s data.

Reset user password activity notes:

• User password value “pwdLastSet” is set to zero (1), which means that a user doesn’t need to change their password in the first login.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Update Group

Efecte Provisioning Engine orchestration node for update group:

In the screenshot above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Azure Active Directory “Target” and are able to view the Access RIghts Mappings which are configured for selected  Azure AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The update group orchestration node read attributes from Data Cards in question and execute API call to Azure.

Updating group activity notes:

• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Update User Information

Efecte Provisioning Engine orchestration node for update user information:

In the screenshot above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Azure AD “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. The update user orchestration node read attributes from Data Cards in question and execute API call to Azure AD.

Updating user activity notes:

• User password update is not supported on this orchestration activity.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.    

Verify Group

Efecte Provisioning Engine orchestration node for verification of a group request before creating new group:

In the screenshot above, the Access Rights Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Azure Active Directory from “Target” and are able to view what Access Rights Mappings are configured for the selected Azure AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Access Rights Mappings admins panel, admins are able to provide “IF” expression, which will form a query to verify if the group exists. It’s possible to select as many attributes from the Data Card as needed to confirm the uniqueness of a group. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate Azure AD attributes according to the “Target*“ Azure Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding Azure AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successful query results are saved, “true” if group was found or “false” otherwise.
Verify group activity notes:

• Verify Group activity - checks if all of the configured items for IF expression were already present in Access Rights Mappings.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

 Verification of a User Request Before Creating a New User

Efecte Provisioning Engine orchestration node for verification of a user request before creating new user:

In the screenshot above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Azure from “Target” and are able to view what Identity Mappings are configured for the selected task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Identity Mappings admins panel, admins are able to provide “IF” expression, which will form API call to verify if the user exists. It’s possible to select as many attributes from the Person Data Card as needed to confirm the uniqueness of a user. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate Azure AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding Azure AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successful API call results are saved, “true” if user was found or “false” otherwise.

Verify User activity notes:

• Verify User activity - checks if all of the configured items for IF expression were already present in Identity Mappings.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Verify Group Membership

Efecte Provisioning Engine AD orchestration node for verify group membership:

In the screenshot above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Identity Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node.

Within the Identity Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the user exists. It’s possible to select as many attributes from the Person Data Card as needed to confirm the uniqueness of a user. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successful LDAP query results are saved, “true” if user was found or “false” otherwise.

Verify Group Membership activity notes:

• Depending of the selected Role Attribute, you can choose, Single string value or Multi string value.
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.