When reviewing the entitlements on a source, I am seeing that the numbers of entitlements on the source is 1.5x the number of entitlements returned by the Entitlement Aggregation. I would like to put together a list of the entitlements that are coming from other avenues than the Entitlement Aggregation, but I do not see any attributes that denote how the entitlement was found, nor can I seem to extract a list of the entitlements that came in the aggregation.
Is there a way to get this information?
The only workaround I can think of would be to do an Entitlement Reset, then do the Entitlement Aggregation, export the entitlements, then do the Account Aggregation and bulk upload (If any. none in our case). This has a lot of downsides to it since we have to re-setup all the roles and access profiles after too.
I recently saw something similar. We had a source where the initial aggregation was run prior to the entitlement aggregation. We noticed that the number of entitlements was too small so we ran an entitlement aggregation. When we were done, we had more than the number of entitlements generated. It was like the ones that were collected from the account aggregation did not align with the ones picked up from the entitlement aggregation. We ended up resetting the entitlements and the accounts and then redoing the aggregation entitlements first and then accounts.
I don’t have that source again that I can use. However, I did have an AD source. For the entitlements that were gathered through aggregation, we don’t have any attribute data just {}:
However, when I did entitlement aggregation, another attribute had that section filled in;
You might see if you see something similar. I think the problem will be though even if you identity them what do you do next since a reset would create a lot of work.
There is no attribute for how the entitlement was created
There is no option to remove/delete the entitlement in IDN unlike in IIQ
Not having deletion make sense as, If you upload the entitlements through a File and if you remove any entitlements in next upload, the same entitlements will be deleted.
Similarly entitlements should be deleted at source side (just like deletion in file which is the source here)
Since we cannot create Entitlements at IDN unlike in IIQ, there is no need of deletion
However I agree with you that If there is a way to delete entitlements then you don’t need source reset which will prevent the removal of entitlements in Roles/AccessProfiles.
As a best practice, check the data before you create any access, do the resets or entire source deletion as many times as you want before continuing to the next step which is Access Model.
I was noticing this as well, that when they came from the Aggregation, they would have the additional attributes (if configured) and when they came from the Account Aggregation, they did not. This might be the easiest way to check is to see if they have an attribute set from the Entitlement Aggregation, but it is not fool-proof.
Yeah, in this case, I jsut wanted to remove specific entitlements that were incorrect. We ended up having to go through support to have them fix 3 entitlements, so this process likely would not have resolved them anyways.
I agree that this is a best practice when configuring new sources, however it is not always possible in the real world. In this case, the source and access was already existing, and we identified that the original configuration was too broad and pulled in additional values that were not needed for the system. This is a good point to make for others though who might find this post.
