Target Mapping is used to synchronize the attributes from SailPoint to Target applications.
For example, Job title
Transformation Rule: As the name indicates, if you need to transform the value.
For example, if Job title is Senior Analyst but your target system would like to have the value as Sr. Analyst, then you need to write some script to change the value accordingly.
Another example is manager, we have manager Employee ID in SailPoint but Target Application like Active Directory needs manger distinguished name, so you need to get that value in the Rule.
Provision All Accounts: Incase if user has more than 1 account in your Target application, then SailPoint doesn’t know in which account it needs to update. So you select that checkbox, so that it will update in all the accounts under same target application for that user.
Import this Rule in SailPoint and select the same in your Target Mapping under Transformation Rule dropdown.
Rule looks good, but logic doesn’t make any sense.
If user last name is Davis/Miller then last name will be updated to Employee ID if not then old value which will be user last name.
Run Refresh Identity cube Task with synchronize attributes option enabled, you will see provisioning requests in your Refresh Task result.
If user last name in SailPoint and last name in Target app (link/account) is same then there will be nothing to update, so request will be filtered. You don’t see any provisioning request in your Refresh Task result.
So I modified my rule, what i want to do is the as you mention
If user last name is Davis or Miller then status will be updated
if not then old value which will be user last name. (i change the varialbe to lastname)
so i would like to change the satus of those from A to I
@MVKR7T i follow up all your steps, thank you for the time to explain to test the status, the only step missing was after update the hr .csv It must be run the aggregration of hr application to update the change from false to true, then run the refresh identiy cube, to update the status in the target mapping
Yes you should run HR aggregation, not sure how you are setting status of identity. I mean what is your source mapping for inactive attribute.
One common case is, if your HR source is a delimited file, add a status attribute. Pass Active/Inactive status.
Add source mapping for inactive attribute as Application Rule, script for the Rule is.
String status = link.getAttribute("status"); //status attribute name in your HR app
boolean flag = false;
if (status != null && status.equalsIgnoreCase("Inactive")) {
flag = true;
}
return flag;
When you mark status as Inactive for a user in your CSV, run aggregation, user gets inactive. Run Refresh task with synchronize attributes option.
Alternative is,
you can mark the user inactive through debug page, just add below entry in attributes map you find in the top along with your firstname, lastname. This is to mark your identity as inactive temporarily. <entry key="inactive" value="true"/>
Run Refresh Task with Synchronize attributes option and don’t enable refresh identity attributes option.
This is just for quick testing purpose to save time.
Feel free to ask any concerns or issues, happy learning
@MVKR7T
what is the difference to add or not add the rule in source mapping? because i tested with and withouth the rule and i get the same result, user get disable in hr application
String status = link.getAttribute("status"); //status attribute name in your HR app
boolean flag = false;
if (status != null && status.equalsIgnoreCase("Inactive")) {
flag = true;
}
return flag;
for the time to explain to test the status, the only step missing was after update the hr .csv It must be run the aggregration of hr application to update the change from false to true, then run the refresh identiy cube, to update the status in the target mapping