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?
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?
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.
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
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
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.
