Share all details related to your problem, including any error messages you may have received.
Hello All,
I have scenario that if manager attribute value is updated manually from UI or QuickLink it should not refresh or update if new manager values come from account aggregation etc…
Your ask is about manager-correlation, or it is just attribute update that you want to prevent?
If it is just attribute update, then depending upon connector you may prevent it the attribute update in the aggregation rule or customization rule using your business logic.
Just manager attribute want to prevent those values updated manually in IIQ. This manually changes values should not be update after “Refresh Identity Cube Task” if new values come from hr feed file.
And for remaining manager values should be updated from HR file if it is not manaullay changed from IIQ.
Hi @Maruthikumar,
Do you mean identity refresh itself should not update manager attribute when an attempt is made to update via UI or Quicklink ?
As you are saying account has a mapping of manager attribute via correlation from the source of truth application
Do you editable manager attribute via edit identity?
I am reconciling the data from HR Source as Delimiter file.
Its not manager correlation etc… Suppose HR application file one of account First Name as “Raju” and I made changes to First Name as editable from Identity Attribute mapping under Global setting. From UI I have made changes of First Name from Raju to Sai it should not change it again to “Raju” if I aggregate HR Application.
And Same for Manager Attribute I need achieve this can any one have idea help me.
This requirement only for the manager values updated from UI then it should not change again. If is not updated from UI then it should need to change as per HR Application File manager values.
Ideal approach would have been to avoid this update for any non-authoritative source. But let’s say you want to achieve the use and the source is Delimited file then you can use customization rule ,build map rule depending upon your choice.
Logic:
Have a flag in identity attribute when it is updated from UI and then during aggregation just check this flag if it is there then skipping the update from target in the attribute and take value from identity itself which will prevent refresh from over writing it.
Let me know if you are having any query with the mentioned flow.