Updating Attributes Based on a Detected Name Change

[アーティクル]
04/12/2018

Scenario:

In a MIM environment, a user goes through a name change (marriage, divorce, etc.) and they have several attributes which need to be updated accordingly. Common examples include DisplayName, Email and Mail Aliases. While it is possible, and relatively easy, to build these values directly in the inbound user synchronization rule from the authoritative data source (such as the HR database), this is problematic in that it will be building these values, whether they have changed or not, for every user on every sync. In a large environment with many thousands of users, this can result in a significant performance hit. While more complex, I’d like to present an alternate solution that shifts the workload into the portal, and occurs only on those users for whom a name change has been detected.

Configuration:

This process utilizes a customer portal attribute and binding, a set, two workflows and two management policy rules (MPRs). In the interest of time, I will not cover the process of creating attributes, sets, etc. and will instead only provide screenshots.

For a detailed look at creating and binding custom attributes, please see this post.

To begin, create your custom attribute. In this environment I called it “DetectedNameChange”, but you may name it however you like.

Similarly, create your binding:

As with any custom attribute, remember to update your management policy rule(s) and filter permission(s) accordingly.

Next, we must create a set based on this attribute.

After the set has been created, we need to create the first of two workflows. In this environment, I named them “_UpdateAttributes_LastNameChange1” and “_UpdateAttributes_LastNameChange2”, but again, you may name these however you like.

This is a stacked activity workflow, meaning it has multiple individual steps (activities). For ease of reading, I have split each activity into a separate image. These are sequential and are represented here in the same order in which they occur in the actual workflow.

The first activity creates a value (I called it “Former Primary1” but this can be named anything) and passes it into WorkflowData rather than a defined attribute.

Again, a simple function evaluator passing a value into WorkflowData:

And another:

Here we use an update resource activity to remove two values and add another for ProxyAddressCollection.

Here we have a function to create a new Display Name.

The custom expression I am using is:

IIF(IsPresent(MiddleName),Left(MiddleName,1)+". ","")+IIF(IsPresent(PreferredName),"'","")+IIF(IsPresent(PreferredName),PreferredName,"")+IIF(IsPresent(PreferredName),"' ","")

This allows the workflow to account for any combination of first, middle, last or preferred name.

This step is optional and many will choose not to do this. Since we typically flow AccountName in MIM to sAMAccountName in AD, you may not wish to update this based on a name change. However, I am including it here so you have it as a resource if you choose to incorporate this. *PLEASE NOTE* In many environments, this will result in a change to the sAMAccountName in Active Directory.

My value expressions:

Left([//Target/FirstName],1)+Left([//Target/LastName],15)+RandomNum(1000,9999)

Left([//Target/FirstName],1)+IIF(IsPresent([//Target/MiddleName]),Left([//Target/MiddleName],1),"")+Left([//Target/LastName],14)+RandomNum(1000,9999)

Left([//Target/FirstName],1)+IIF(IsPresent([//Target/MiddleName]),Left([//Target/MiddleName],1),"")+Left([//Target/LastName],14)+RandomNum(1000,9999)+[//UniquenessKey]

With a new and globally unique AccountName built, we’ll use a function evaluator to lower case it:

Here I am creating an update mailNickname based on AccountName. However, if you chose *not* to recreate account name, you will need to modify this workflow accordingly.

Likewise, if you are not updating account name in the above activity, you will need to modify this one as well.

Finally, we need a mechanism of triggering our second workflow. The easiest way to do this is via set transition, and the easiest way to affect a set transition to set a value in a custom attribute.

Setting this attribute will cause the user to fall into the set we created earlier and, based on that, the MPR (which we have yet to create) will fire workflow #2. So, onward to workflow #2.

Again, these workflows can be named anything you like, but I personally try to name them sequentially so I know they belong to the same process.

Having dropped into the set and caused a set transition workflow to fire, we no longer need the value we previously set. So, while the last step in WF1 was setting this, the first step in WF2 will be clearing it. The easiest way to do this is by passing a null with an update resource activity.

Next, we’ll use a custom expression to build their new mail alias:

And the custom expression:

IIF(IsPresent(PreferredName),"smtp:","")+IIF(IsPresent(PreferredName),PreferredName,"")+IIF(IsPresent(PreferredName),".","")+IIF(IsPresent(PreferredName),LastName,"")+IIF(IsPresent(PreferredName),"@contoso.com","")

And alias #2:

IIF(IsPresent(MiddleName),Left(MiddleName,1),"")+IIF(IsPresent(MiddleName),".","")

As a carry over from the previous workflow, if you did not rebuild the account name, you will need to update this accordingly to build the email with the correct attribute.

Base their SIP address off their email:

And write the new values into ProxyAddressCollection:

The final piece is to create the two management policy rules. The MPR for WF1 is a request type (as it detects a change to the LastName attribute.

Since any user can have a last name change, we’ll use the default All People. However, this could be narrowed to a specific set of users if you so desire.

Again, we can restrict the target resources to specific users if desired. Also note that we want this to only apply to one specific attribute – Last Name. Based on this, any user with a detected change to the value in their Last Name will have this workflow applied to them.

And here we see the selection of the actual action workflow.

Rather than a request type, MPR #2 (firing WF#2) will instead be a set transition.

The transition set will be the set we created earlier.

And finally, firing our second workflow.

Explanation and walk through:

A user has her or his last name changed in an authoritative data source and that value is brought into MIM. MPR#1 detects the change in the LastName attribute and triggers WF#1. Among the other stacked activities, WF#1 sets a “true” value in the custom attribute we created. Based on this value, the user then drops into the set we created. From this set transition, MPR#2 fires WF#2 and completes the process.