Managing Inactive Identity Cubes in IdentityIQ (delete, archive or other)

I wanted to see what strategies IdentityIQ administrators are using to manage the number of Identity Cubes in the UI. Currently my organization is keeping all identity cubes of former employees and contractors. Our leaver workflow is to disable the account and remove all entitlements.

For efficiency, I’d like to avoid having inactive identity cubes showing in the IdentityIQ User Interface since it would speed up processing and reduce confusion on picking the wrong identity cube. Is it a best practice to delete inactive identity cubes after 2 years (excluding any identities that have a legal hold) or would be it be better to archive the identity cubes to a location outside of Identity IQ?

Best regards,

Hi @jacosta
It all depends on your Organization’s Compliance Policy to retain the identities.

Based on my previous experience I had an opportunity to archive the information at Database level. Also we were archiving the Identity Request objects by exporting them since we had large volume of access requests created every quarter

You can run prune identity cubes to delete identities from IIQ that no longer have link object referenced. However maintaing the identities itself in the system should not affect any performance as long your other jobs like refresh identity have filters set to exclude such identities. Can you confirm what’s the identity population in IIQ today and the only time old identities does help is with rehire if there are references to the identity you would like to review from audit aspect and retain policy

Hello Rajesh,
Archiving at the database level makes sense. I’ll have to consult with my senior management for data retention policies. IdentityIQ tends to store its data as an xml. Did you run into any difficulty accessing archived identity objects and identity request objects once they were archived?


Hi Suresh

We do have the refresh tasks set to exclude inactive identities so that is reassuring regarding system performance. The prune identities task may provide a solution although our current leaver strategy is to disable link accounts.

The identity population is about 5000 identities. I don’t have an identity in mind to review at the moment. We have only had IdentityIQ for about a year and are looking ahead to keep it reasonable for faster search queries.

Thank you for your insights

Hi Joey,

The data of IdentityIQ is not stored as XML It might look like it when viewing the objects via debug or exporting the objects, but this is an abstraction of the real database data (using hibernate to perform the abstraction). When looking directly at the database it looks a bit different.
The best way to show how the data is stored it to look at the IdentityIQ Object Model and Usage

– Remold


For a database 5000 objects is peanuts :wink:

To really keep search up to speed is not limit the amount of objects, but how the indexes are setup on the tables and which attributes are used.
Please take a look at Hibernate Mapping Files and see how the indexes are configured (/can be adjusted).

Next to indexes the amount of snapshots per identity is affecting the speeds of opening identities and certifications. Take a look at this old post for a small FAQ on snapshots :slight_smile:

– Remold

1 Like

Also if you are concerned about identity picklist during access request or manage accounts, look for options to modify OOTB IdentitySeclector rule to filter inactive.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.