on Feb 17, 2016Is there any other way apart from the below one (without manual intervention) to pull the multilingual data from HRMS system and to be published in Active Directory in English during the auto provisioning.
Now, we are generating a rule to send the provisioning form to AD admin team(single user) to update those attributes in English. After receiving those inputs, we are doing auto provisioning in Active Directory with the updated attributes value.
You can create roles which are assigned based on the membership rule from the role by a role missing membership rule. Populate said roles with AD Groups and you will have an automated way to provisioning active directory accounts with the groups you require.
if you have a list of known values (not dynamic values) in the source then you can do the following:
In the fulfillment workflow you can create several nodes which will check the source values and then modify the values accordingly to be sent to the AD using a AFXCUSTOM prefix.
An example to your use case will be helpful to understand what you are trying to do.
I've seen the use of the AFXCUSTOM prefix several times now, what is the exact purpose of the prefix, is there any documentation available on it?
you have several posts in the community about it:
Re: Read user DN without account collection in Workflow
Re: Can workflow variables be referenced by AFX connectors?
and also in Appendix B: Adding Custom Business Logic to AFX Processing with Workflow Variables
in the AFX_Guide (official documentation)
Boris, but it is unrealistic to use all the values in several nodes to achieve this.
Usecase: we are having few attributes in Arabic from HRMS database view which we need to collect and get the corresponding values in English only then we can provision the user identity in AD's corresponding OU.
Attributes like Department are in Arabic, so we are sending the provisioning form to AD Admin team to fill the values in English. Based on their input value on department, user's exact OU will be decided and provisioned into AD accordingly.
how many values in Arabic do you have?
You mentioned that you are collecting from DB view
Let's put aside the fact that you need to place them in a different OUs
You can create a SQL query (for the identity collector) that looks like this:
select column1, column2, column3, case when department_in_arabic = 'Value#1 in Arabic' then 'Sales' When department_in_arabic = 'Value#2 in Arabic' then 'Finance' Else 'Generic' end as Translated_department from HR_DATA
Store the original department value and the translated department value in a custom attributes for the user.
Now you have the translated values without any manual intervention
Can this work in your scenario?
Exactly Mate... This is the one I was looking for. Now I can remove the unnecessary rule which sends a form to AD Team.
how many values in Arabic do you have?
You mentioned that you are collecting from DB view
Let's put aside the fact that you need to place them in a different OUs
You can create a SQL query (for the identity collector) that looks like this:
Store the original department value and the translated department value in a custom attributes for the user.
Now you have the translated values without any manual intervention
Can this work in your scenario?