Identities in Inactive state do not have IndentityNow account disabled in the Accounts list so are these identities still available for log in?
This is available to all commercial sandbox and production tenants. This is available in FedRAMP sandbox tenants. It will roll out to FedRAMP production tenants on Wednesday, April 24.
1 Like
1 Like
Yes, @lukas_ceremeta.
I think it’d be great to do the following:
When identities move to INACTIVE_LONG_TERM, disable their ISC account.
Does this sound good to you?
Are there others in the community who would find this useful?
1 Like
Thanks, @beth_wu ,
What do you think about birthright roles (roles that were received based on membership criteria)?
Should we also remove those when the identity goes to INACTIVE_LONG_TERM?
Thanks, @richard_craig,
What do you think about birthright roles (roles that were received based on membership criteria)?
Should we also remove those when the identity goes to INACTIVE_LONG_TERM?
I believe you should. You go INACTIVE_LONG_TERM, i would suggest birthright roles be removed as well.
1 Like
For IDN accounts, my team is working on a loopback to do this now, would be nice to have it done automaticaly thorught this new process.
1 Like
Yes, because if they are removed from picklists and teamlists then their account should be disabled. You could just add it as a checkbox under the identity state selection in provisioning.
1 Like
I believe there should be an option for this or just add a criteria that can detect such users.
There could be an exception where you want a role that does something to users with this identityState.
I like this too a lot ! Because it makes more sense to also “block” attribute sync on every front. We are migrating from IIQ on which it was configured with no attr sync for inactve user and this was a pain point in IDN and seen as a kind regression.
1 Like
if Inactive identities are not processing roles and access profiles. when will roles be removed assuming an identity switches from active to inactive? (or will they process roles one final time before they become inactive?)
An identity gets processed after their LCS changes. It’ll drop them out of the roles then. This assumes you’ve got the roles configured to do something like Identity Attribute > Lifecycle State Does Not Equal Inactive.
1 Like
Hi,
There’s a lot of great comments here and I’m not sure if I’ve missed this aspect but for some organisations, the implied license allocation that I’ve been told is linked to this has a potentially huge impact for some.
Here, we have more than 2/3rds (20k ish) ID’s that have absolutely no access being managed for them. They are managed mostly in an IIQ deployment. However, they sometimes need access to systems managed by our IDN. For this, they make an Access Request and are provisioned with some access. Previously, paid for licensed users needed at least one piece of access being managed by IDN (excluding the ID source in RO mode). (in fact, it was documented 1-5 accounts requires Lite license and above that is Full, excluding user who use the UI to perform recerts, regardless of access). So, when a user was provisioned access via a Request they then required a licence. We hold a headroom of 800 users for these (very) odd occasions.
But now, to avoid them being excluded from the drop down we will have to mark these as Active and pay for a license in IDN, just in case they need access in our part of the organisation. This is a huge amount of money and, if this turns out to be the case, will force us to look for alternative solutions to this issue. What’s doubly frustrating is that, no such exclusion exists in the API (yet) so if we build an alternative request solution we can use that without an issue. This will add tech debt etc and is completely contrary to the reasons we select SaaS over an on-prem solution.
I can see all the useful reasons this makes sense but it was introduced to me, by SailPoint as a new way to better count licenses some 2 months before it came out.
This isn’t just a rant. Our org will not pay licenses in this way and that may mean I a) develop a new Access Request solution (any takers? 
) or b) have to take part in a long and tedious rfp to migrate away from IDN… I really don’t want to do either of those
Hello @kirby_fitch. Any news about this ? Is it considered to be implemented soon or is it in a long-term plan ?
Hello,
This is really nice feature to have. Thank you.
1 Like
Hello Kirby.
Thank you for the presentation.
I tried to configure this changes on our sandbox, but it doesn’t seem to be working.
Neither the identity state is updated on the identity details nor the attribute ‘identityState’ shows up on the search query.
Are we missing something on our sandbox?
Thank you.
1 Like
OK, on the identity I can already see the new Identity State:
But on the search query builder I don’t have access to the attribute:
We’re hoping to prioritize this within the next couple months.
1 Like
Hi @fpdias, it doesn’t auto-complete but I can confirm that using attributes.identityState:ACTIVE will work.