Working with Names and Name Based Attributes: Redux

This post is a follow-up to a previous post entitled “Working with Names and Name Based Attributes”. In that post, I discussed various ways of generating unique values for attributes such as AccountName. Since that post, I have had customers with slightly different naming conventions ask about ways to do something similar, but to also include a numeric value. So, in this post, I’d like to provide you with one more method of generating a semi-random unique attribute value. Please note that, as before, I am using a custom activity (WAL) to generate a unique value in this workflow. WAL download and documentation can be found here. While the random number bit could be generated with a standard function evaluator and appended to the end of an AccountName, unfortunately, there is no way with that method to check for uniqueness. In some cases (where there may be a very small set of objects we need to generate this value for), this may be perfectly acceptable. For AccountName, however, I would much prefer to determine uniqueness, either against FIM or AD.

Let’s start by looking at the real meat and potatoes of the activity. Here are two different examples, showing we can make this either basic or slightly more complex.

Here we see FirstInitial + First 15 of LastName + RandomNumber

Example: The Value Expression:


Will result in:

John Smith = JSMITH1234

John Smithstattersoon = JSMITHSTATTERSOO1234


The reason behind trimming LastName to 15 it to give us a total length of 20 (hard limit in AD for sAMAccountName).

Here, we are doing essentially the same thing, only we are now trimming LastName to 14 and including a MiddleInitial, if present. If MiddleName is not present, we pass over it. This will, however, result in an overall length of 19 rather than 20.

Example: The Value Expression:


Will result in:

John Smithstattersoon = JSMITHSTATTERSO1234

John Robert Smithstattersoon = JRSMITHSTATTERSO1234


You will notice in each of the above examples there is a second Value Expression line. In each of these cases, it is the same value with the uniqueness key seed appended.




This is an additional safety to ensure uniqueness should all possibilities be exhausted. Given the above example, there would need to be user objects with account names in the entire range from:


Once this condition has been met, the uniqueness key seed would generate a value containing:



In all reality, however, this scenario seems highly unlikely.


Now, for the sake of due diligence, here is what the entire new user generating workflow activity would look like:

Before firing this workflow, we might have:

Each one may or may not have a First, Middle or Last Name present. If so, cases may be off (i.e. all upper, all lower or any combination thereof). After this workflow activity, however, we would have:

Note that some users are lacking a MiddleName; as such, their AccountName and DisplayName lack it as well. Likewise, users with a populated MiddleName have a MiddleInitial included in both.


Questions? Comments? Love FIM so much you can’t even stand it?



## ##

Comments (1)

  1. Chris Brookins says:

    FIM team giving me options, that is what I like to see.

Skip to main content