In the maintenance dialog, you can customize which entities you want to keep, and for how long. There is a 'snapshot' choice there and I can tell you that it will remove data from the following tables:

• account_change
• application_summary
• entity_change
• perm_change_changed_ext_attrs
• permission_change
• snapshot

What I don't know is if any of these tables contain the data that you want to keep - the historical requests and changes of users.   You could possibly take a look at those and see if they hold what you need.

I'm a fan of having a separate archival database that is used solely for reporting, if you have a need to keep things longer than the life of a review.   That is to say, I'm a fan of keeping the operational database as small as possible, pruning very aggressively to ensure peak performance, but I'm also used to LOTS of applciation data and accounts/permissions, so keeping it lean is important.   With archiving, you could setup a separate data source in reporting (or even an entirely new reporting instance that just points at the archive)  and use that archive DB just for historical reasons, but you cannot point the interface at the archive.   That means if you want users to leverage the out of box interface to see their historical data, you need to keep it all in the operations database.   Once you move anything over to archive, its now useless in the UI.

--Jim

Hi Jimbot,

Sorry for the late reply, I was on holiday for a few weeks...

Thanks for the detailed feedback! It somewhat confirms the "worries" I had.

I will have to take a look at the tables you mentioned, play with the maintenance configuration/setup and see if/how the data changes after the cleanup/archivation.

It is very unfortunate that it seems to be quite complex to provide users with historical data (changes). I mean, we are talking about identity "governance" here, so these should be very basic features/configurations one should think. But that is another topic...

Anyway, thanks again for your help! will share the information once I come up with a setup that works for us.

Regards,
Philipp

If data to support audits is what you need, you can achieve that with pdf reports that save the data outside of the DB.  I've used that technique a few times to capture what needs to be retained and continue with regular cleanup maintenance.

It sounds like you are looking more for investigative support, or ad hoc/on the fly lookup of how/why someone received a permission.

--Jim