Setting Up Lifecycle States - SailPoint Identity Services

Lifecycle states describe a user's status in the organization, which you can use to drive access changes for your users. For example, when a new employee joins your company, Identity Security Cloud can grant them the required access for active employees. When someone leaves the organization, their access can be automatically revoked or their source accounts disabled.


This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html

Hi Team,

Can we add a note for Disable operation for lifecyclestate with a screenshot & explanation.

“Account wont be disabled if the source also has access profiles in the access profiles to grant list below”.

Thanks!
Regards
Arjun

Hi Arjun! We’ve created a ticket so that we can investigate and document this behavior: SAASDOCS-9054. We’ll update this thread when the work is complete. Thank you for helping to improve the docs!

2 Likes

Hi @arjun_sengupta. I’m looking into your request to see whether the documentation can be improved. To assist this process can you please provide further details on “Account wont be disabled if the source also has access profiles in the access profiles to grant list below”, in particular “…has access profiles in the access profiles…”.

Can you please also kindly confirm the section and/or step on the page where you feel the addition of the note would be beneficial.

HI @GraemeF

Setting Up Lifecycle States - SailPoint Identity Services - Configuring Lifecycle states - After Step 5, there is a Note.

This can be added there.

Regards
Arjun

Hi @arjun_sengupta. Thank you for helping us improve our documentation. Based on your feedback, we’ve updated Configuring Lifecycle States.

Hi @saas_docs_team,

It seems that lifecycle states have priority levels assigned now.
We saw this in production with newly created lifecycle states.

We then checked get-lifecycle-state | SailPoint Developer Community, which has a bit of documentation on it, but we do not understand what it is trying to say.

Note that we do know priority levels in identity profiles. Which is to determine which identity profile is used in case you have an account in multiple authoritative sources.

But once this is clear and you have just one identity profile, you can also have only one lifecycle state.

Can you please check if this new fields was perhaps a mistake, or if this is not the case, add documentation in documentation.sailpoint.com as well on this matter, and check why this value can not be seen or set in the UI?

Kind regards,
Angelo

Hi, @angelo_mekenkamp! Thank you for your input. We’ve created a Jira issue (SAASDOCS-10156) to track this effort, and we’ll update the comment thread when it’s been addressed.

Hi there @angelo_mekenkamp! Thank you for your patience! It turns out the description for the priority attribute in the API documentation was incorrect. It has now been updated. Please let me know if the new description makes sense or if we can add more detail to better explain it.

As always, thank you for helping us improve our documentation.

Hi @kaitlyn_stockton, thank you for the update and for adding the description there. The description is quite clear, but it does surprise me that this is the description and I wonder if something is missing.

To clarify my point: Identity profiles have a priority assigned as well. And the effect of priority in identity profiles is that if you have one identity with accounts in different authoritative sources, (sources linked to different identity profiles) that the priority of the identity profile is then used by ISC to determine which identity profile mapping should be used to populate the identity attributes for this identity.
That is the purpose of the priority there, and then it makes sense that we can read/write this priority on identity profiles and it would make sense that we can get all identity profiles and sort by this priority.

Since lifecycle states now also have a priority assigned. I wonder what the purpose/effect is of this field, perhaps if ISC performs an identity refresh it will start with identities whose lifecycle state has the highest priority, or something like that? Then if this purpose is known, it would make sense to have APIs available for us to read/write this priority and to get all lifecycle states of an identity profile sorted by this priority.

Does such a purpose/effect exist? If so, it is missing from the documentation (not only in the API documentation, but also in documentation.sailpoint.com). If not, I am not understanding yet for what use case SailPoint has built this functionality for specifically lifecycle states.

Can you please clarify this?

Kind regards,
Angelo

Hi @angelo_mekenkamp ,

Priority for identity profiles is different from priority for the lifecycle states. We recently expanded the list of out-of-the-box Lifecycle states from Inactive/Active to PreHire/Active/LeaveOfAbsence/Terminated/Archived - and we wanted these Lifecycle States to appear in that particular order, which necessitated the addition of a priority field, and the UI now uses the API with ?sorters=priority to maintain order.

Customers can also benefit from this if they wish to see Lifecycle States appear in the UI in a particular order by patching the priority field and setting the desired order.

2 Likes

Hi @NataliaYunusov,

Thank you for your response! This definitely clarifies it. :slight_smile:
I do see the reason to have the UI display the lifecycle states in the order determined by the customer, where the initial order for the out of the box lifecycle states can also be updated to the customers needs (or even delete those lifecycle states if other custom lifecycle states are used).

So the fact that the UI uses this field to display them in this order was what I was looking for. This fact is not documented yet. It would be nice if this can be documented in the below location, with the mention that the order as seen in the UI can not be changed through the UI, but would depend on using the API, with a link to the API documentation:
Setting Up Lifecycle States - SailPoint Identity Services.

Personally, I would have chosen a different attribute name (like orderIndex?) since priority would now suggest that the lifecycle states have an order of “importance”, while this is not the case here. I hope this will not confuse customers.

One last thing is that I tested this and I found a bug regarding this functionality. The attribute priority is a number, yet sorting by it will not sort it as if it were a number, but as if it was a string. As a consequence, so the UI will now show this wrong order of priority:
10,110,120,20,30,40,50,60,70,80,90 instead of the expected 10,20,30,40,50,60,70,80,90,100,110.

Can you please fix this @NataliaYunusov?

Thanks again for the clarification!

Kind regards,
Angelo

@angelo_mekenkamp I’ll start working on adding that content to the documentation. Thank you for all your feedback!

1 Like

Great catch @angelo_mekenkamp !:detective: We will fix the bug.

1 Like

Hi @angelo_mekenkamp! The Defining Lifecycle States documentation has been updated to mention and link to the Update lifecycle state API documentation.

Thank you for your help!

Thank you @kaitlyn_stockton, this documentation looks complete and good now. I am sure this will be helpful for many customers! :smiley:

Kind regards,
Angelo

1 Like

Hi @NataliaYunusov, Please note that the bug is still present. Calling the API to sort by priority still sorts as string instead of as integer.

In addition we discovered that although the API documentation to PATCH lifecycle states specifically states that priority was a patchable field, we saw this was not actually possible. We reported this second bug and that bug has since been fixed and we can now assign priorities to lifecycle states ourselves. Then as test, I took a look at the UI again, but see that the UI is now sorting lifecycle states by name again, not by priority as per your comments:

Has SailPoint rolled back this functionality? If so is this temporarily until the sorting bug is resolved (Is there an ETA for this?), or will this stay permanent?

Should the documentation that mentions that the UI sorts by priority be updated since it seems to sort by name now? (@kaitlyn_stockton).

Kind regards,
Angelo

Thank you for your feedback, @angelo_mekenkamp.

I will let @developer_advocates know about the API documentation issue. :slight_smile:

For the sorting bug, I’ll work with @NataliaYunusov and engineering to resolve this and update the documentation accordingly.

Thank you!

1 Like