Introduction to Workflow Management

Applies To: Forefront Identity Manager 2010

Microsoft® Forefront Identity Manager 2010 Workflows define an activity or activities that must occur during the processing of a Management Policy Rule (MPR). FIM 2010 installs several default Workflows that can be used as is, or as a basis for a custom Workflow.

Known issues in FIM 2010 Release Candidate 1 (RC1)

Cannot edit a workflow that has an imported file

In this release, you cannot edit a workflow that has an imported file. To workaround this issue, delete the workflow and create a new workflow. You can then import the file in the new workflow.

Import XAML crashes if the duration field for Approval is set to less than one day in a Custom Workflow

For this release, do not set the duration field in a custom approval to less than 1 day. Durations set to integers will only use the digits to the left of the decimal point. For example, if the integer is 2.5, only the number 2 is used. In this release, only use whole numbers with a value range of 1 to 100.

Need to add quotes in a custom activity for Lookup parameters

In the function activity you can select a "Custom Expression" that will allow entering a function expression directly. To reference Lookup parameters, they must be added in quotes (unlike all other activities). A correct example to reference the display name in a custom expression is "[//Target/DisplayName]".

Overview of Workflows in FIM 2010

While they are optional components, Workflows are closely tied to Management Policy Rules in FIM 2010. Whenever a Request event occurs FIM 2010, for example browsing the members of a group, or creating a new user, the appropriate Management Policy Rule is invoked. If the request only needs permissions, such as browsing the members of a group, then the MPR will allow the request and processing is completed. However, if further actions are needed then the MPR will call or invoke any Workflows that are assigned to it. For example, when processing a request to create a new user, if the MPR determines that the requestor has appropriate rights to create the user, then a Workflow could be processed that might assign an initial password to the new user, or send an automated notification to selected recipients. Some other examples of Workflow activities:

• Send an automated e-mail to request approval

• Restrict the attributes that a user can see during a custom search

• Validate a new group against Active Directory or FIM 2010 guidelines

• Add or remove the object from the scope of a Synchronization Rule

Workflows

In FIM 2010 there are three types of Workflows:

• Authentication – Authentication activities are used to perform additional user identity validation before continuing with the request.

• Authorization – Authorization activities are used to validate a request through a sequence of activities, such as obtaining necessary outside approval before processing a request.

• Action – Action activities are used to process any further activities after the original request has been completed successfully.

Activities are the elemental unit of a Workflow. An activity can perform a single action, such as writing a value to a database, or it can be a composite activity and consist of a sequence of activities.

Authentication

An Authentication Workflow uses a sequence of Authentication activities to validate the user’s identity. These can be used for Password Reset processes or authentication for general requests. These activities associated with an Authentication Workflow:

Lockout Gate

The Lockout Gate activity is used to automatically lockout the user from running the authentication workflow in which the lockout activity is configured based on certain parameters. An example of this would be when a user tries to reset their password and fails to pass one of the challenges. The configurable parameters of a Lockout activity are:

• Lockout Threshold – The number of times that the user can fail the authentication activity of the Workflow.

• Lockout Duration – The length of time that the user is locked out once the Lockout Threshold has been reached.

• Permanent lockout – The number of times that the user can reach the Lockout Threshold before being permanently locked out. Once a user is permanently locked out, an administrator will need to unlock the account.

Lockout Gate activities should occur first in any Authentication Workflow to ensure that the user cannot proceed any further with the Workflow until the Lockout check is completed.

Password Gate

The Password Gate activity is used to authenticate the user for their Active Directory Password.

QA Gate

The QA Gate activity presents a series of questions that the user provides answers for when the user first registers. Upon subsequent authentications, the user must provide correct answers to complete the request. The QA Gate can be configured for:

• The total number of questions in the QA Gate

• The number of questions displayed to the user during registration

• The number of questions required for registration

• The number of questions randomly displayed to the user during an authentication process

• The number of questions that must be answered correctly

Registration questions should be short, closed-ended, and easy for the user to provide a unique answer that only they would know. Some examples:

• “What color was your first car?”

• “What is your favorite pet’s name?”

• “What was the street name of your childhood home?”

Authorization

Authorization Workflows contain activities that serve to further validate a request before allowing the request to commit its operation. The most common activity in an Authorization Workflow is the Approval activity, although this may be sequenced with other activities. For example, an Authorization Workflow for modifying a security group may have an activity that requires an approval from a manager, as well an activity that validates the group, and an activity that notifies the group owner. There are five default activities available for use in an Authorization Workflow:

Approval

An Approval activity sends an e-mail to a specified user, or users, requesting approval for the desired process. For example, a Management Policy Rule and Workflow may be configured to allow a user to change their last name with approval from the user’s direct manager. When the user submits their name change request, a pre-configured e-mail will be sent to the users’ manager, and the request will remain “pending” until the manager approves or rejects the request. The configurable parameters of an Approval activity are:

• Approvers – These are the users and groups that can approve the request and will receive the e-mail. Members may be selected by browsing the available users and groups, or by configuring a Workflow Lookup, which acts as a token or variable that is evaluated when the Workflow is processed. For more information, see Workflow Lookups in this document.

• Approval Threshold – The number of approvers that are required to approve the request. For example, if the Threshold is set to 2, and the Approver list contains a group with 10 members, that request will be approved as soon as any 2 members approve the request.

• Duration – The number of days before the e-mail request times out and is escalated. If no one on the Approvers list responds to the e-mail request within the specified Duration period, the request is sent to the users and groups on the Escalated Approvers list.

• Escalated Approvers - These are the users and groups that can approve the request and will receive the e-mail after the Duration threshold has been reached.

• E-mail Templates – E-mail Templates are pre-configured e-mails that can be created for the different phases of an Approval: Pending Approval, Pending Approval Escalation, Completed Approval, Rejected Request, and Timed Out Request.

Filter Validation

A Filter Validation activity specifies a Filter Scope, which contains a list of attributes and membership references that a custom search filter may contain. You can use a Filter Validation activity to ensure that users are creating custom filter searches and dynamic memberships for Groups and Distribution Lists that are valid. For example, if you have defined a Filter Scope that limits users to searching only by the attributes DisplayName and Department, a search that also includes Job Title will not pass the Filter Validation, and the request will be denied.

Function Evaluator

A Function Evaluator activity calculates an attribute value based on another attribute, a number or string value, or another custom expression or function. The configurable parameters of an Function Evaluator activity are:

• Activity Display Name – The display name for this activity.

• Destination – The object and attribute where the calculated value will be stored, typically [//Target/<attribute name>]. Click Lookup to create a Workflow lookup. For more information see Workflow Lookups in this document.

• Value – The calculation for the value or values to be written to the Destination attribute. Value can be expressed as an attribute, a constant value, a function, or a custom expression.

Group Validation

The Group Validation activity validates a group create or modify request against different directory scenarios:

• FIM - This activity evaluates a request and fails authorization if the request would leave the group with properties that are unsupported by FIM 2010 group management, for example, adding an explicit member to a group whose membership is dynamically calculated.

• Active Directory - This activity evaluates a request and fails authorization if the request would leave the group unable to be represented consistently between FIM 2010 and Active Directory, based on membership, group type, and other behaviors of AD.

• Multiple Forest - This activity evaluates a request and fails authorization if the request would leave the group unable to be represented consistently between FIM 2010 and Active Directory, based on Active Directory rules for multiple forest environments.

Notification

The Notification activity sends an e-mail notification to the specified users or groups when the request is processed. In cases where an approval may not be required, for example when someone adds themselves to a Distribution List, you can configure a Notification activity to send an e-mail to the Distribution List owner when the request is processed. The configurable parameters of a Notification activity are:

• Recipients – These are the users and groups that will receive the e-mail. Members may be selected by browsing the available users and groups, or by configuring a Workflow Lookup, which acts as a token or variable that is evaluated when the Workflow is processed. For more information, see Workflow Lookups in this document.

• E-mail Template – Select a pre-configured or custom e-mail template. E-mail Templates are pre-configured e-mails that can be specified for different notifications.

Requestor Validation

The Requestor Validation activity restricts a requestor’s ability to add or remove members from groups they do not own.

• Allow owner to add or remove groups they own - This activity authorizes a group owner to add or remove a group they own from a group they do not own.

Action

An Action Workflow is the last step in a request process and performs additional actions after the request has been processed successfully. For example, after a request to create a user has been approved, the user account can be added to the scope of a Synchronization Rule to provision to Active Directory. There are four default activities available for use in an Action Workflow:

Function Evaluator

A Function Evaluator activity calculates an attribute value based on another attribute, a number or string value, or another custom expression or function. The configurable parameters of an Function Evaluator activity are:

• Activity Display Name – The display name for this activity.

• Destination – The object and attribute where the calculated value will be stored, typically [//Target/<attribute name>]. Click Lookup to create a Workflow lookup. For more information see Workflow Lookups in this document.

• Value – The calculation for the value or values to be written to the Destination attribute. Value can be expressed as an attribute, a constant value, a function, or a custom expression.

Notification

The Notification activity sends an e-mail notification to the specified users or groups when the request is completed. In cases where an approval may not be required, for example when someone adds themselves to a Distribution List, you can configure a Notification activity to send an e-mail to the Distribution List owner when the request is completed. The configurable parameters of a Notification activity are:

• Recipients – These are the users and groups that will receive the e-mail. Members may be selected by browsing the available users and groups, or by configuring a Workflow Lookup, which acts as a token or variable that is evaluated when the Workflow is processed. For more information, see Workflow Lookups in this document.

• E-mail Template – Select a pre-configured or custom e-mail template. E-mail Templates are pre-configured e-mails that can be specified for different notifications.

Active Directory Password Reset Activity

The Password Reset activity sets the length of the randomly generated password as part of an Active Directory password reset process. The only configurable parameter is Password Length, which can be between 0 and 128.

Synchronization Rule Activity

The Synchronization Rule activity manages how the target object is affected by the selected Synchronization Rules. For example, after a request to create a user has been approved, the user account can be added to the scope of a Synchronization Rule to provision to Active Directory. The target object can either be specifically added to or removed from the scope of the Synchronization Rule, or added or removed based on an attribute value.

Workflow Lookups

FIM 2010 Workflow Lookups are a design feature that let you create Workflows that handle data under a variety of circumstance. Lookups act as a token or variable that is evaluated when the Workflow is processed. For example, when you request to join a group, a Workflow can send an approval e-mail request to the owner of the group. Instead of specifying the owner directly, you can create a Lookup that will send the e-mail to //Target/owner. This will ensure that if the owner of the group changes, the Workflow will still send e-mail to the appropriate user or group. Lookups consist of a Workflow Parameter and a Parameter Attribute.

• Request – contains information that is associated with the Request that launched the current workflow. The available parameter is CreatedDate, which contains the date that the Request was submitted in the regional setting used by the server.

• Requestor – This is the FIM 2010 resource that submits the request. This is usually a user resource type. All the attributes of the available objects are available to reference.

• WorkflowData – A custom expression whose attribute values are used only inside a Workflow instance, for example //WorkflowData/ExchangeServer or //WorkflowData/InitialPassword.

• Target – This is the FIM 2010 object that is currently being modified or deleted. This parameter is empty for Create scenarios. All the attributes of the available objects are available to reference, for example //Target/manager, //Target/DisplayedOwner, //Target/MemberToAdd, etc.

• RequestParameter – This is used to read the Parameter attribute on the request object.

• Delta – The Delta parameter is used strictly during modify operations, and contains changes that are being requested to the target. The available parameters are ExplicitMember/Added and ExplicitMember/Removed.

Summary

Along with Management Policy Rules and Synchronization Rules, FIM 2010 Workflows and their activities make up the core structure of an FIM 2010 request process. To create a Workflow in the context of a Management Policy Rule, see Introduction to Management Policy Rules, and to create a Workflow in the context of Password Management, see Introduction to Password Management, both in the FIM 2010 documentation set.