We have a requirement to generate unique Account Name on creation of an account for the delimited source. This Account Name holds the name of the application followed by random 6 character. I am generating this using an Attribute Generator Rule on the Create Account. This source is integrated with SDIM. The Account Name is successfully getting generated and can be seen on the UI (search page). The problem here is, on every Identity refresh the system is retrying the Create Operation and hence logging a Snow Ticket since the 1st ticket is still in pending state i.e. not closed completed in SNOW. Is this an expected behaviour and what is a possible solution to avoid logging/creation of multiple RITM for account creation? Also, when I am removing the Attribute Generator rule from the create Account it is not retrying the create operation. So I assume it is because of the Attribute Generator rule that the system is retrying provisioning.
Without knowing specifics, my first guess is that the account isn’t aggregated back to the identity for some reason and then on the next Identity Refresh it tries to create the account again and then it fails based on a duplicate value.
@edmarks , the issue arises after an access request is approved but before fulfillment is completed. During this interval, the ServiceNow (SNOW) ticket for account creation remains in a pending state. If an ‘Identity Refresh’ is triggered in SailPoint during this period, it initiates the account provisioning process again.
This results in SailPoint generating a new RITM in SNOW with a newly generated accountName—using the Cloud Rule defined in the “Create Account” policy. Consequently, duplicate tickets are logged for the same user.
Once any of the tickets gets approved, the account gets provisioned in SailPoint. The core issue, however, is the creation of multiple tickets for the same request.
Interestingly, when I remove the Cloud Rule from the Create Account policy, SailPoint no longer creates duplicate tickets, even if the original SNOW ticket is still pending. This leads me to believe that the Cloud Rule is the root cause of the issue.
Additionally, since the account name format includes the application name followed by a random 6-character string, using an Identity Attribute Generator rule is not a viable option.
The objective is to prevent duplicate ticket creation while retaining the required account name logic.
I’d check the ticket “status” in SNOW and ensure it’s defined properly in the SDIM integration portion as “Queued”. If so, this should prevent ISC from generating another request on identity recalculation.
To confirm it’s something specific in the cloud rule itself - I’d hardcode the expected value directly in the create profile as a “static” value and try to reproduce the issue. This should allow you to isolate the cloud rule as the issue.
Also - Ensure it’s ONLY this one identity that is being recalculated (forced recalculation only to verify). It’s possible 2+ identities are being recalculated via normal recalculation processes/triggers which could be giving you a false positive on this.
Yes, this behavior is expected if the attribute generator produces a new value on each refresh, causing a perceived delta in the account attributes. ISC treats any change in a synced attribute as a reason to retry provisioning. Since the Account Name keeps changing, the system assumes the previous operation failed or was incomplete and triggers a new create request. To avoid this, generate the account name once and store it persistently (e.g., in an identity attribute). Then have the attribute generator return that stored value instead of generating a new one each time. This will prevent repeated provisioning attempts and duplicate RITMs in SNOW.
