On a web service connector we have different operations that use the same endpoint (enable/disable/update/add entitlements/remove entitlements). We have a before provisioning rule to add in the plan some mandatory attributes used by these API calls.
Our calls work on the target application but the changes are not reflected directly in IDN and we have to wait for the next aggregation to get the real attribute values in our accounts.
This poses a risk because if between an operation and an aggregation we have another operation, IDN will push wrong data via the API call. This can lead to IDN pushing entitlements we removed in a previous operation or disabling an account that we enabled before.
We are trying to find a way to force an aggregation right after those operations to avoid the risk mentioned. Is there a way to solve this issue?
Hi,
Haven’t tried this and perhaps i misunderstood your flow but you could utilize an Event Trigger in Workflows like Provisioning Action Completed | SailPoint Developer Community and then trigger an aggregation via HTTP-call to IDN. Think that is a CC API:
{{api-url}}/cc/api/source/loadAccounts/{id}
This could probably be built in SaaS Workflows, but haven’t tried it yet
The way IdentityNow provisioning works is if provisioning plan is committed it reflects the changes on idn side. e.g. If enable provisioning plan comes as successful then it marks account as enabled on idn side. In WS source, response code plays important role so if your end system is returning different response code then what you have configured then identitynow would not consider operation as committed.
Check provisioning logs from search and see if it’s actually successful or failing.
Hi,
Maybe I wasn’t very clear with what I meant. The target application relies on an account attribute called “isActive” which is a boolean to define the status of the account.
When I enable the account in IDN, IDN shows that the account is enabled but the account attribute “isActive” stays as false (dectivated state) and the change is reflected only after the next aggregation; only then “isActive” becomes “true”.
This is why I am looking for a way to aggregate the account after an enable in order to directly have the right value for this account attribute.
For other operation I am sure that idn reflects changes made on end source on platform side(in idn ui) but for enable/disable and that also on the account status attribute(which is “isActive” in your case) I am not sure. It does reflect account status as enabled/disabled on idn side after successful provisioning which you have confirmed and that is working as expected.
Coming to the actual problem you are worried about:
“This poses a risk because if between an operation and an aggregation we have another operation, IDN will push wrong data via the API call. This can lead to IDN pushing entitlements we removed in a previous operation or disabling an account that we enabled before.”
This would not happen because account status is still reflected properly , it’s just account status attribute is stale.
To overcome the problem you can increase aggregation frequency as much as possible.