Case-Sensitive Matching Not Enforced

Feedback Bugs
1

Expected Behavior: Lifecycle State values should only map when the synchronized value exactly matches the lifecycle state’s technical name, including case.

Actual Behavior: Lifecycle State values are mapped even when the synchronized value differs from the technical name only by case. The Lifecycle State is assigned successfully, and the corresponding Identity State is applied after identity reprocessing.

Example:

  • Technical Name: legalhold
  • Synced Value: LegalHold
  • Result: Lifecycle State still maps successfully.
1 Like
2

Hello Reena. Based on my testing, I do not think the behavior you are seeing in the Lifecycle State field itself is a bug. The case-sensitive matching appears to be working correctly in my tenant. The confusing part is that the Lifecycle State attribute can still display the mapped value even when it does not successfully match a configured lifecycle state’s technical name.

So seeing LegalHold on the identity does not by itself mean the configured legalhold lifecycle state was actually assigned.

The important thing to check is the Identity State. SailPoint documents that the Lifecycle State value must match the technical name and that this evaluation is case-sensitive, and it defines a specific condition for this: “Lifecycle State Does Not Match Technical Name Case.” It also states that an identity’s Identity State is automatically set to Active when the identity does not have an assigned lifecycle state (Lifecycle States).

So if legalhold is configured with an Inactive Identity State, but the identity receiving LegalHold remains ACTIVE, then the case-sensitive matching is being enforced. The attribute has the value, but the configured lifecycle state was not actually assigned.

I tested both a case mismatch and a value that does not correspond to any configured lifecycle state in my tenant. I will share those results below.

1 Like
3

Here is what I tested in my demo tenant. I first created a lifecycle state with:

  • Display name: test Disabled
  • Technical name: testDisabled
  • Identity State: Inactive (short-term)

image
image2048×1142 362 KB

I then mapped testdisabled to an identity. The identity shows testdisabled in the Lifecycle State field, but the Identity State remains ACTIVE.

image
image2048×821 143 KB

So even though the value appears in the Lifecycle State field, it did not match and apply the configured testDisabled lifecycle state. If it had matched, the Identity State should have changed to Inactive (short-term).

I then tried another value, Reena. There is no lifecycle state with technical name Reena configured in this Identity Profile.

image
image620×1340 39.7 KB

The identity still shows Reena in the Lifecycle State field, but its Identity State remains ACTIVE.

image
image1858×680 119 KB

So in my testing:

  • testDisabled vs testdisabled → case mismatch, lifecycle state not assigned
  • Reena with no configured lifecycle state → value displays, but lifecycle state is not assigned

In both cases, the Identity State remains ACTIVE, which also lines up with SailPoint’s documented behavior that an identity with no assigned lifecycle state is automatically set to Active (Lifecycle States).

That is why I think the Lifecycle State field itself can be a little misleading here. The value can be present without the corresponding configured lifecycle state actually being assigned.

If your identity with LegalHold is actually changing to the same Identity State configured on legalhold, then that would be different from what I am seeing in my tenant and would be worth investigating further.

1 Like