Updating Attributes Based on a Detected Name Change

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.

clip_image002

Similarly, create your binding:

clip_image004

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.

clip_image006

clip_image008

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.

clip_image010

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.

clip_image012

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

clip_image014

And another:

clip_image016

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

clip_image018

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

clip_image020

clip_image022

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.

clip_image024

clip_image026

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:

clip_image028

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.

clip_image030

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

clip_image032

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.

clip_image034

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.

clip_image036

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.

clip_image038

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

clip_image040

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:

clip_image042

clip_image044

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

clip_image046

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.

clip_image048

Base their SIP address off their email:

clip_image050

And write the new values into ProxyAddressCollection:

clip_image052

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.

clip_image054

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.

clip_image056

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.

clip_image058

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

clip_image060

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

clip_image062

The transition set will be the set we created earlier.

clip_image064

And finally, firing our second workflow.

clip_image066

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.

Here is an example of a user before the process:

Name: Jane Doe

Display Name: Jane Doe

Account Name: jdoe

Primary SMTP: jdoe@contoso.com

Secondary smtp: jane.doe@contoso.com

Based on the Last Name changing in HR from “Doe” to “Smith”:

Name: Jane Smith

Display Name: Jane Smith

Account Name: jsmith

Primary SMTP: jsmith@contoso.com

Secondary smtp: jane.smith@contoso.com

Secondary smtp: jane.doe@contoso.com

Secondary smtp: jdoe@contoso.com

Here’s what the process actually looks like in practice:

image

image

Now, let’s give Mr. Burr a name change.

image

If we check the search requests, we can see this is in process and see the workflows firing.

image

When the process completes, we should see something like:

image

image

Questions? Comments? Love MIM so much you can't even stand it?

EMAIL US - WE WANT TO HEAR FROM YOU!

## https://blogs.msdn.com/connector_space # #