Remove Access on Birthright Failure Not Triggering for Users with Access Assigned via File Import

[gokul]

Hi, We have encountered an issue where the "Remove Access if the Birthright Fails" functionality is not working as expected for users who received their birthright access through a file import.

We have configured delegation only for certain user types by creating a separate SAV role for delegation, which we assign to users using the SAV4SAV connection through a technical rule. This works perfectly for new users, and the "Remove Access" task triggers correctly when the user fails the birthright condition.

However, for existing users, we attempted to assign this SAV role via file import, along with the corresponding SAV4SAV account. Despite the user meeting the birthright condition and possessing the access granted by the technical rule, when we update the user to fail the birthright condition, the "Remove Access" task is not created as expected, even though the checkbox to remove access on birthright failure is enabled.

For users whose accounts and access were created via the technical rule, the "Remove Access" function operates as expected. We are trying to understand whether this is the expected behavior or if it is a defect in the product.

Can anyone help us on this.

Thanks in advance!!

[rushikeshvartak]

Does assignedfromrule flag is updated in account_entitlements1 table for users uploaded via file upload ?

[gokul]

@rushikeshvartak  Thanks for responding.
I tried creating an account alone through CSV file import, and then added the entitlements via actionable analytics. I checked the account_entitlements1 table, and the technical rule ID is listed under assignedfromrule. However, when I break the condition, the remove access task is still not getting created.

[rushikeshvartak]

Validate logs

[gokul]

@rushikeshvartak 

I have observed a behavior in the technical rule's "Remove Birthright Access" when the rule condition fails. I created a technical rule with the condition: a.statuskey = 1 AND a.employeeType = 'ABC'. The rule triggered correctly, and access was added based on the rule. However, when I failed the rule condition by changing the employeeType to a value other than 'ABC', remove access tasks were created for the added access. Conversely, when I failed the condition by setting the user's status to inactive (statuskey = 0), no remove access task was triggered.

Is this expected behavior? Does a status change not trigger the removal of birthright access?

Regards,
Gokul.

[rushikeshvartak]

Did you enable the below flag in global configuration?

[gokul]

@rushikeshvartak - I tried enabling both options, but even when only the status changed, the removal of access wasn't triggered, despite it breaking the condition of the technical rule.

Regards,
Gokul.

[rushikeshvartak]

Validate logs