Cloud Rule iteration failure when assigning sequential unique values

Hi all,

We are encountering an issue with a Cloud Rule that assigns sequential unique values to an attribute based on certain conditions. The logic currently works by iterating through possible values until it finds one that is not in use. However, after approximately 600–800 iterations, the rule fails and throws a full-stack error.
For example, if the user is internal, the value should start at 10000. If 10000 is already taken, then assign 10001, if that is taken then 10002, and so on until an available value is found. This approach works initially but eventually fails when the iteration count becomes too high, and we end up having to manually update the rule after every few hundred identities.

Our question is: how can this be solved without constantly updating the rule? Do other implementations use a base field or some kind of counter that can be updated automatically without changing the rule logic? Are there recommended best practices for this scenario? For example:

Using a persistent counter stored in an attribute or configuration object and incrementing it for each new identity?
Storing the counter in an external system and calling it from the Cloud Rule?
Querying the highest existing value and incrementing from there instead of brute-force iteration?

Thanks in advance,
Antonio

HI @Antoniosanchez

top clearify the issue more, would you provide more context about the following

What rule type is generating the number, and is it writing to an Identity attribute or a target account attribute?

What scope must be unique (global across all identities, per population, or per target system?

Do you require strictly consecutive numbers (no gaps), or just unique and increasing?

Where do you currently check “in use,” and do you have the exact error stack when it fails around ~600–800 iterations?

that will help narrow down the soluation

thanks

Hi @Antoniosanchez

I have same questions as @amrdodani . Please clarify the same. But assuming that you have currently configured Identity Attribute type rule where you create this sequential number at the time of identity creation, it will not work because of race condition. Identities are created in parallel.

It is always better to create any unique attributes at the account level to avoid conflicts and race conditions. having said that if the requirement strictly requires you to create a sequential number, the best way is to create a db table and use in built sequence which inserts value and assigns an sequence number and SailPoint gets that value and assigns to the identity.

It is recommended to create randomly generated number and very easy to implement and check for uniqueness.

Kindly provide more context.

Regards,
Abhi

Hi @amrdodani @abhnaray , first of all, thank you for your interest.

To give you more context, all cases are for the samAccount attribute of the AD account when it is created, so it is always the provisioning of the Active Directory account.
Customers ask us to ensure that the sama does not contain personal data such as first or last names, and they always want it to follow a specific order. In some cases, they want a letter at the beginning to identify the type of employee, but they always ask us to follow a numerical order so that they can tell whether the user was created a long time ago or not just by looking at the sama.

To generate these values, we have created cloud rules that are assigned during creation provisioning. The cloud rules assign a value to the user and check that no one else has it, following a numerical order as requested.

The error we get is this one:

an unexpected error occurred: Error running rule transform:sailpoint.tools.GeneralException: The application script threw an exception: java.lang.StackOverflowError BSF info: Generate sAMAccountnameUnique at line: 0 column: columnNo

I hope that has cleared up your doubts and thanks for your time.

Best regards,

Antonio

Just brainstorming here, but if the identities are created with the samA in numerical order, cant you search for the last created user and do a lookup of the attribute and add 1? ISC does have the created on attribute, or this may be data that you can get from the target source.

It is almost quitting time on a Friday so sorry if you had already thought of this.