Share all details about your problem, including any error messages you may have received.
Hello,
We’re implementing a joiner process where the manager must approve the department assignment for a new employee.
To support this, we created a Lifecycle Event: Onboarding – Manager Approve Department.
Initially, we attempted to use a rule-based trigger for this event. However, since identities are imported from our HR system, the previousIdentity object is no longer null after the first refresh. This makes it difficult to define a reliable trigger condition based on identity creation.
As a workaround, we configured the Lifecycle Event with the Create type. This leverages the needsCreateProcessing flag, which is automatically set when an identity is first created and cleared once the event is processed.
The issue we’re facing is that after the manager approves the service, the needsCreateProcessing flag is being set again on the identity. As a result, any subsequent refresh of that identity retriggers the joiner event — which is not the desired behavior.
Ideally, we want the joiner event to trigger only once per identity creation, regardless of downstream approvals or updates.
Is there a way to prevent the needsCreateProcessing flag from being re-applied after the initial event has been processed?
If you want to use this approach, then I would suggest to add the logic to clear the needsCreateProcessing flag from the identity in the last step of your Joiner workflow. In this way, you will get rid of this attribute from the identity if it is not getting cleared automatically.
If you want to go with this solution, I would suggest you to add a step in the workflow, to check if the joiner already triggered. create a rule and Reference the rule in the workflow, which basically checks, if joiner triggered , You can make use of query options, return the size from the rule, say if the size is greater then or equal to 1, joiner already triggered, and transition that step directly to stop step. If you want to throw an error, create a failure step, transition it to failure and throw the error that “joiner already triggered”.
Manually removing the needsCreateProcessing flag after the event resolves the issue — but this feels more like a workaround than a proper solution.
When we use a Business Process without an approval, the flag is cleared automatically as expected. This leads us to suspect that the presence of an approval step might be interfering with the flag’s lifecycle.
Could it be that IIQ creates a snapshot of the identity state at the time the approval is initiated, and then restores that snapshot upon approval completion — including the original needsCreateProcessing flag?
Just to clarify, with this solution, would the Lifecycle Event still be triggered every time the identity is refreshed, and then immediately transition to the stop step if the rule detects that the joiner has already run?
We actually use an attribute called Lifecycle State to trigger events. The tricky part is when identities come in from the HR app, we expected previousIdentity to be null on the refresh after the first aggregation, but instead it’s equal to newIdentity. So we couldn’t really use a trigger rule to catch the creation properly.
When we create an identity manually from the UI, the trigger rule works just fine.
That’s why we ended up relying on the needsCreateProcessing flag and the Create-type event.
If the value is not getting cleared in approval case. Can you raise a SailPoint case and get the proper details from them for this issue.
I was under impression that needsProcessing value was not getting cleared in any scenario. I would suggest raising a case to get the full information about this.
No, it won’t create any lifecycle events, create that step at the top post initialize/start step and then directly transition to stop or failure. It will not create any lifecycle events.
