Hello Saviynt Experts,
Problem statement: In Saviynt we have a user update rule which is supposed to trigger whenever any update happens to identity through either API/UI/Import but upon identity update through api, the rule has triggered but there were no update task was generated. Hence Identity's data has not been sent to target application.
What changes has come from HR source to trigger the rule?
User profile was updated to "Active" from "Inactive" state. Along with this data at the same time some other changes were also received like manager change, department, custompropertyXYZ, etc.
Initial troubleshooting from my side:
To understand the issue root cause, I did check the rule & user history and understood there was only one task(enable account) was created upon identity update from upstream. I was expecting update account task also to push other attributes changes.
In user's history, could see two rule were triggered for target endpoint i.e.
1. API - Change in User attributes : Responsible to trigger update account task << This didn't trigger
2. API - Rehire Users Greater than 45days: Responsible for enable account task << This triggered and task created
Checking at the rule advance query: It has everything which is require to trigger the rule but still didn't trigger. The update rule works absolutely fine. It triggers and create task in other cases when only update( except status) received from upstream system.
Business concern: This has caused discrepancy in the data between both the system as the target didn't receive the data which Saviynt received from HR (due to no update task in this case). Customer raising concern for same.
Additional Info: This rule is perfectly working fine when the identity change doesn't include status update. If the update comes with status change and other customproperty in that case only update rule is not generating any task.
Upon checking with Saviynt ops on this, here is what they recommended:
1. In case if endpoint api supports to perform updates using enable api, go ahead with same api call in 'enable account json'. Use update account json params in enable account json.
2. In case, target doesn't support update using enable api then you can make 2 calls inside enable account JSON. First - Enable the Identity , Second - Push updates to the target system using "enable account json" itself. However, testing is required to confirm this.
3. To use Analytics to detect the user and their respective account attributes mis-match and based on that trigger the task through analytics.
I understand, all of the above suggested options might work as workaround but these are not sustainable/optimal solution for long term when you have huge endpoints connect with Saviynt.
Also maintaining the update account json at two places is duplicate maintenance and might prone to design failure over time.
1. What are the approach you are following in your project/for your customer to achieve this use case?
2. Did you encountered any issue/challenges following any of the suggested approach by Saviynt(mentioned above) which I should be aware of before standardizing this in my project?
3. Is there any other way we can achieve this use-case?
@rohitkumarraj Additional Info: This rule is perfectly working fine when the identity change doesn't include status update.
If the update comes with status change and other customproperty in that case only update rule is not generating any task.
for the above issue did you check the Include Inactive User and Accounts in Update Account Rules configuration under Global Configurations-->Rules and check once.