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.
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.
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:
- 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.
- 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.