`usernameGenerator` behavior when a `substring` token is null in a pattern

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

Hi everyone,

I’m implementing an email usernameGenerator pattern sequence like:

  1. $firstname.$lastname@domain.com
  2. $f1.$lastname@domain.com
  3. $f2.$lastname@domain.com
  4. $f3.$lastname@domain.com
  5. …

Where f1, f2, f3, etc. are built with substring on firstname (begin=0, end=1/2/3...).

From the substring docs, I understand an out-of-range end can return null.

My questions are:

  • If a token in a usernameGenerator pattern (for example $f5) is null, is that pattern skipped automatically?
  • Or is null converted into a literal string or empty string and still evaluated?
  • Is this behavior officially documented and stable across ISC versions?

Thanks!

2

Hi @anas_sahel

If firstname is null and a token like $f5 attempts to take a substring of the first five characters, it will result in an error. This is expected - just like in any code, applying a substring operation to a null string trigger a null‑pointer exception.

To avoid this, apply a null‑check. In transforms, this can be handled using a firstValid operation. In standard scenarios, firstname should not be null; if it is, its a bad data and the process should ideally fail to flag the underlying issue

3

Hello @rpriya,

Thanks for your answer.
Do you mean that f6 (if there is an f6) won’t be reached if f5 throws an error caused by substring?

4

@anas_sahel - Yes, it won’t reach f6, as firstname itself is null. In fact, with your current pattern sequence, the first pattern that includes $firstname.$lastname@domain.com will produce something like .$lastname@domain.com. The generator will attempt a uniqueness check on that value. If it finds no conflict, that malformed value would be used as the username. If a conflict does exist, it then proceeds to the next pattern—such as $f1—which would fail because firstname is null and it won’t process other patterns with f2 f3 etc.

How do you want to handle this usecase where firstname or lastname is null? A better approach is to ensure firstname is never null at the pattern level. Typically, when firstname is missing, preferredFirstName is used as the fallback. You can implement this with a firstValid transform, making preferredFirstName the secondary option, accordingly the remaining logic can be updated.

5

Thank you @rpriya, it’s clear :slight_smile:

I’m willing to implement an email generation by relying on the usernameGenerator.
The pattern we use in the company is:

  • firstname.lastname@domain.com
  • f.lastname@domain.com
  • fi.lastname@domain.com
  • fir.lastname@domain.com
  • …
  • firstname.lastname${uniqueCounter}@domain.com

With what you’ve explained, I can use firstValid with substring with the full firstname as a fallback, thus if at the first place firstname.lastname@domain.com failed, then it will go down until it reaches the uniqueCounter pattern.

I’m just assuming that a firstname won’t or we don’t allow it to exceed x chars

6

@anas_sahel
In ISC, a usernameGenerator pattern is not automatically skipped just because a token evaluates to null. Null values are generally treated as empty during evaluation, but if a transform throws an error the generator can fail and stop processing further patterns.

This behavior isn’t explicitly documented.
Best practice: avoid null tokens by using firstValid/fallbacks (and only then apply substring) so patterns always generate valid candidates.

Regards
SathishKumar.N