I have a JDBC source for which i have written the provisioning rule as per the below example. I want to know if the modify operation mention in this example is for a single valued entitlement or a multivalued entitlement?
When i send a modifying access request for my single valued entitlement it modifies the entitlement using the update query but an identity refresh tries to reset it back to the old value.
My question is old entitlement automatically revoked or i need to do a revoke request first and then send a new create request for my single valued entitlement.
And i think example that you mentionned is for a signe value.
Fot this example, In the users table login must be unique and we have one entry per user. If the role columun is update, existing value is overwrited.
After rule execution, IdentityNow will do a single aggregation on account by reading entry in database. Existing entitlement is automatically removed by replaced by new entitlement.
Well, that is the expected behaviour. But for some reason that is not happening. In my case a series of identity refreshes resets my new entitlement by the old one right after the access request.
This is because of something called attribute assignment when access is granted using access requests. View my other response here where I explained this concept for IIQ and Salesforces, but it is most likely the same in IDN for your single-valued entitlement attribute.
Looks like this phenomenon is identity specific. Is it possible that this happens with all identities? No matter even if i pick a fresh identity everytime the result is the same.
It will happen with all identities. Think of it like a role with two entitlements from this application. It will provision one and then the other one will show as not provisioned on the account anymore, so it will provision it, which removes the original one. They are constantly flip flopping.
The entitlements are sticky in IDN and would always require an entitlement revoke request (certification or an entitlement revoke API will also do) to unlink it from the identity if they were originally requested with an entitlement access request.
You can try out creating access profiles for every entitlement and rely on an access profile request as these are not sticky in nature. The JDBC rule should contain an UPDATE command to replace the new entitlement with the odd one in case of a modify operation.