Previous Pending Values

[Former Member]

Does anyone know where to find old pending values in IDM v7.2? I've been looking in a bunch of the oentries views and I can't find any old, applied or deleted pending value entries at all. I know there have to be some out there. I haven't ever had to look for them in this version of IDM so I'm not sure where to look.

[terovirta · Accepted solution]

In 7.2 the pending value only lives through the execution of it / while the pending value pends. No way of digging them up from historical views etc AFAIK. They're get deleted once they're processed or expired.

regards, Tero

[Former Member · Accepted solution]

So once the pending value is applied, there's no historical record of the MX_PENDING_VALUE entry type at all? Man, that's kind of silly that they would wipe it completely out of the system in even a historical sense but if that's the case, I suppose that's the way the ball bounces. 

Thanks for the information.

[terovirta · Accepted solution]

I suspect that the PVO delete has to have something to do with the 7.2 Provisioning Framework as the whole provisioning runs on pending values plus the HCM-integration creates PVOs on future attribute values send by HCM.

Were you after any specific PVOs? If it's just provisioning then the link-tables in 7.2 are big improvement and you can detect the pending privilege/role-assignments or failed provisioning from the link-tables.

regards, Tero

[Former Member · Accepted solution]

What's happening is, when a user leaves the company, a pending value is created for MX_INACTIVE. After a year, should the user not be rehired or anything like that, the pending values applies and, as a result of now being inactive, the accounts are deprovisioned from the target repositories.

What was happening was the pending value was not being removed in the event a user was rehired. Then, a year after their original leave date, the accounts were being deleted. We believe we have it fixed but I want to show a record of the pending value having existed in the first place on a user who left then came back.

Not a big deal as we can show it's still being created on more recently departed users. I just wanted that evidence on users that had been rehired also.

[terovirta · Accepted solution]

You should be fine if you delete the MX_INACTIVE-attribute off the user with the attribute operator that  deletes the pending values too.

If you have tested the inactivation and seen the PVO for the MX_INACTIVE, noted it's MSKEY, run the re-hire and the PVO with that MSKEY cannot be found (and user is not inactive) there is not much more you can test.