Manually overriding lifecycle state

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

The documentation for Setting Up Lifecycle States contains the following note:

The manual setting is applicable as long as the underlying value on the source doesn’t change. When the value on the source changes, the Lifecycle State field gets reset to an automatic value.

Is this also the case when a cloud rule is to develop the cloudLifecycleState value?

Thanks

2

Hi @joseph_casale

This says if you do any changes manually to the cloudLifecycleState value it will change there. But if any transform or any rule is there it will trigger that and it will change the value automatic of the cloudLifecycleState.it will change when identity refresh is done.

Thank you!

1 Like
3

Hi @joseph_casale ,

Please check the below screenshot for your reference.

image
image888×355 14.7 KB

Please check the link below:

Thank you!

5 Likes
4

Hi @Abhishek_1995
We are reading the same note from the same document.

I am hoping to confirm the behavior is consistent and does not vary between the following two examples:

  • The cloudLifecycleState identity attribute is directly mapped to a source (the simplest case).
  • The cloudLifecycleState identity attribute is set with a cloud rule (a complex case).
5

Hi @Abhishek_1995 Lifecycle state value is the one which you assign it. What I mean is that if you have map it from some source (directly, using a transform, or using a rule), the value will change everytime it has to change. You can manually update it, but next time source/transform/rule changes its value, LCS will change also.

In order to you understand better this case, we have a client which he wanted to manually “override” LCS value that was coming from some web service. To achieve that, client had to develop a web service endpoint that informs HR that LCS was manually updated. From ISC side, we develop a workflow, that every time lifecycle state changes mannually to some value X, it performs an HTTP Request to this endpoint. So from this point and on, HR web service will stop sending LCS state for that particular user. This is common when users goes on vacation, then status turns to some inactive value, but admins needs to temporarily reactivate some user.

6

HI @jsosa ,
I think the nuance here is that if for example:

  • Your cloudLifecycleState is mapped directly to an account attribute
    • If you manually change the lifecycle state, the docs read such that your change will persist until the value in the source changes.
    • For example, you are currently active in the source, and someone transitions you to leave, you will remain on leave until the source changes to anything other than active.
  • Your cloudLifecycleState is derived from a cloud rule
    • This is unclear to me, will the product detect the rule is producing the same value as it previously did and ignore it?