- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
CREATION_DATE is not updating recent value in T_AV_EXPLODEDUSERENTITLEMENTS table
CREATION_DATE is not updating with recent value in T_AV_EXPLODEDUSERENTITLEMENTS table if App role/entitlements/group gets deleted.
If app role/entitlements/group gets revoke from account then DELETION_DATE will be updated in T_AV_EXPLODEDUSERENTITLEMENTS and same app role/entitlements/group if we collect in the feature then deletion_date will update as null and creation date will not updating as newly collected date and it's remains old value when first time mapping date.
How can we collect the recent collection date in T_AV_EXPLODEDUSERENTITLEMENTS table under CREATION_DATE ?
- Tags:
- Community Thread
- Data Collection
- Discussion
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- IG&L
- IGL
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi Muneendra,
When deleted as you stated, the record within the database itself isn't deleted but rather softy deleted by populating the deletion_date column to the date it was deleted at.
Upon collecting the previously deleted record, the deletion_date is set back to null, but the creation_date stays the same (as within the first collection before it went missing).
While I can agree with you that this might be a bit confusing and also constraining some conditions that you may want to apply accordingly, I believe this is functioning by design and this behavior isn't only with entitlements, but rather account mappings, group/role memberships & role definition entitlements as well (removing + adding an entitlement to a role definition presents the same behaviour). I highly suggest you open a support case to firstly confirm that this is functioning by design then submit an idea for this on RSA ideas:
https://community.rsa.com/community/products/governance-and-lifecycle/ideas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
RSA Customer Support is unable to comment publicly on structure of RSA internal database tables.
Can you formulate your question in terms of what RSA Identity Governance & Lifecycle functionality is not working as you desire?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi Muneendra,
When deleted as you stated, the record within the database itself isn't deleted but rather softy deleted by populating the deletion_date column to the date it was deleted at.
Upon collecting the previously deleted record, the deletion_date is set back to null, but the creation_date stays the same (as within the first collection before it went missing).
While I can agree with you that this might be a bit confusing and also constraining some conditions that you may want to apply accordingly, I believe this is functioning by design and this behavior isn't only with entitlements, but rather account mappings, group/role memberships & role definition entitlements as well (removing + adding an entitlement to a role definition presents the same behaviour). I highly suggest you open a support case to firstly confirm that this is functioning by design then submit an idea for this on RSA ideas:
https://community.rsa.com/community/products/governance-and-lifecycle/ideas
