Synchronization Rule Workflow Parameters

You might have noticed that there’s a tab called Workflow Parameters (fig. 1) available during the creation or modification of an Outbound Synchronization Rule (OSR) or a bi-directional Synchronization Rule (SR).  You might also have wondered what this is and how it’s used.  It’s probably more thoroughly documented now than it was during beta and release candidate but as this is something that crops up in customer workshops I’d like to get something out there in the “blogosphere” about it.

The help says the following:

Workflow Parameters – Create user-defined parameters here that can be used in a Workflow with a Function Evaluator activity and a Synchronization Rule activity. The value calculated by the Workflow will be passed to the Synchronization Rule during processing. Click New to add each additional parameter.

The purpose of WF parameters is to provide additional information to your synchronization rules.  Realistically they’re intended to provide dynamic, or computed, information, i.e. information that must be computed or calculated “on-the-fly”.  You define the parameters in the Synchronization Rule (fig. 1) and then utilise them in outbound flow (fig. 2).  As you will see they show up differently in flow –they’re prefixed with a dollar.

Figure 1: Workflow parameters

Figure 2: Outbound attribute flow

Once the Synchronization Rule is created, the Synchronization Rule activity dynamically adds input fields for each Workflow Parameter.  You define the values of the WF parameters in the WF designer.  As stated earlier these are intended to flow dynamic, computed information.  Therefore the values can be expressed as lookup grammar, as depicted in Figure 3.

Figure 3: Synchronization Rule Activity

In the above example you can see I’m retrieving two values from the parent workflow dictionary (they were added there by preceding WF activities) and I’m “hardcoding” two values: 0 for pwdLastSet and 512 for userAccountControl.

To finalise and make things a little clearer, here’s a couple of examples of why you’d want to use Workflow Parameters:

  1. Initial password.  You are provisioning an Active Directory Domain Services (AD DS) user and you want to set an initial, one time (i.e. expired) password.  You have a custom WF activity that generates a random password.  This activity generates a random password, using a set of characters that you define; to a length that you define; and writes the output to a dictionary key of your definition.  You can therefore define a WF parameter, of the type String, to capture this password and flow it to unicodePwd during provisioning.  Furthermore, you can also flow an Integer value of zero, 0, to the pwdLastSet attribute so that the password is immediately expired, i.e. reset password at next successful logon option is defined.  Figure 3, above, illustrates a configured Synchronization Rule activity that utilises WF parameters.
  2. Distinguished name.  As per above, different sets of users require different DNs as they’re (unfortunately) not all lumped into one OU.  So you look-up the OU from an organizational unit (OU) resource type in FIM, linked to users, and add that to the ERE (also depicted in fig. 3).

These are just two examples from a project that I’m working on.  Hopefully this post conveys what workflow parameters are and how to use them.


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM and tagged , , , , , , , , . Bookmark the permalink.

9 Responses to Synchronization Rule Workflow Parameters

  1. Pingback: Regenerating Expected Rule Entry (ERE) resources | Yet another identity management blog

  2. vhs says:

    Should the attribute defined in the workflow parameter be also defined in the portal and tied to the object?

  3. vhs says:

    Thanks! Could you please show what goes in the value expression and target of the first two wf activities? In the 3rd wf, I could see just first part of the attribute names. Where are they defined and how?

    • I no longer have screenshots as that lab is long gone. Essentially the custom WF activities that are not expanded have a text input box intended to store the result of what the WF does, I therefore express a unique key in the WF dictionary using FIM lookup grammar:


      In the SR WF activity that you see I enter the same lookup grammar. Within a single WF instance – the actually WF that runs each of the activities illustrated – a Dictionary object exists that can be read from and added to. This is what we are doing. With the out of box activities most support adding to and reading from this dictionary using the lookup grammar [//WorkflowData/keyName].

  4. DEPOLO says:

    Hi Paul
    Nice work. By the way, can you show us how you generate the value that’s flow in each parameter, can us see the one for password?

    • This solution is long gone. IIRC it was a POC. Passwords were generated using a custom WF activity that used System.Security.Cryptography.RNGCryptoServiceProvider class to generate random numbers and generate a complex password. Generated password was written into the WF dictionary.

      If the question is the more generic “how do you get data into the workflow dictionary” then the built-in function evaluator activity allows you to do this via the following lookup grammar: [//WorkflowDictionary/SomeKeyName]

      Where SomeKeyName is an arbitrary string.

      In WF code it’s just a matter of getting the parent WF and adding an object, with a string key, to the Dictionary exposed. You can find an example here:


      // In order to read the Workflow Dictionary we need to get the containing (parent) workflow
      SequentialWorkflow containingWorkflow = null;
      if (!SequentialWorkflow.TryGetContainingWorkflow(this, out containingWorkflow))
      throw new InvalidOperationException(“Unable to get Containing Workflow”);
      this.Log(“Containing Workflow Dictionary (WorkflowData):”);

      // Loop through Workflow Dictionary and log each attribute/value pair
      foreach (KeyValuePair item in containingWorkflow.WorkflowDictionary)
      this.Log(” ” + item.Key + “: ” + item.Value.ToString());

  5. Russ Lema says:

    I am looking for help getting a workflow to populate a string attribute (msexchAssistantName) with the DisplayName of a reference Value (Assistant) do you have any ideas how to do this?


    • I can’t remember whether or not you can use OOB Lookup Grammar to do this. You could try using the Functional Evaluator to write, for example, [//Target/Assistant/DisplayName] to [//Target/msexchAssistantName].

      If that doesn’t work you need a custom activity that will get the requestor or target from the current request and then allow you to get the data you need and write it somewhere.

      Can you confirm whether or not you are developing this yourself or trying to achieve it without coding?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s