Hello, I have configured a web service connector in which we marked the attributes that dictates if the account is active or not as an entitlement. We then configured automatic roles to enable/disable the account (in this case the operations executed will be add/remove entitlements).
Therefore we have 2 roles that are opposite, and when a person changes condition it will jump from one role to another.
My question is: how does the provisioning plan consider these operations?
Are they two separate account request created? Do they have a specific order and which one will be executed before the other?
Has anyone done a similar configuration? and if yes what are your recommendations?
Role A : Activate Account - ‘active’ is configured as entitlement
Role B : Disable Account - ‘inactive’ is configured as entitlement
If your user satisfies and jumps between criteria’s for these roles, then ensure to have Add Entitlement and Remove Entitlement HTTP operations configured to handle the addition/removal of this role - Update the HTTP body in such a way that wherever you’re referring to ‘active’/‘inactive’ in the JSON, just add $plan.<attribute holding the status on account schema>$ in the JSON body. The connector would execute the HTTP operations by pulling attributes from provisioning plan and fill up the placeholder values from the plan which is ‘active’/‘inactive’.
Similarly, if you would like the LSC to disable/enable the account, then you need to handle it without the placeholder values as above and have actual values in the JSON body config of Enable Account and Disable Account operation. (Note : Ensure to have configure changes > Disable/Enable account configured on lifecycle states)
Hello Arshad,
thank you for your reply, we have already taken into consideration what you mentioned.
Our real concern is the following, using Role A and B you mentioned as an example:
User jumps from Role A to Role B. my question here is the following:
Will two account request be created? one to remove entitlement of role A, and another to add entitlement of role B or will it all be in the same account request?
Is there a way to know which account request is created and executed first? is there a way to force a specific order of execution other than having specific membership rules in the roles?
Oh okay, I now understand.
It is dynamic in nature and IdentityNow should group them together into a single account request. But I’ve also seen instances where the account requests were split it into two. Also, I’m afraid you cannot force an order of execution for the roles as once the Identity refresh kicks in, the role memberships on your tenant are evaluated in bulk and is asynchronous in nature.