Common Workflow Activity Types

Activities represent the action or logic for a specific process within a workflow and are comprised of properties and methods that perform the action of a workflow, while maintaining the state of that workflow. This topic provides an overview of the most common activities used in EmpowerID workflows.

When you publish a form in Workflow Studio, a special activity, known as a "Form activity," is generated and published to the EmpowerID Identity Warehouse. When the form is published, EmpowerID generates each form field as a "dependency property" that can be used for capturing and passing user input to other activities in the workflow. To use a Form activity in a workflow, you search for the Form activity in the Activities tree and drag it onto the workflow design surface. Once on the design surface, you can bind dependencies and set any relevant activity properties.

Operation activities are activities based on the EmpowerID workflow authorization framework to determine if the current user in a workflow process can execute the code contained in that activity. They determine at runtime if the current user has any EmpowerID roles with the necessary operations against the target resource(s) to perform the action being attempted, and handle any approval process required if they do not. Approvals are routed using the EmpowerID Rights-Based Approval Routing (RBAR) technology to any individuals, groups, roles, or query-based SetGroups that have been granted the ability to perform the operation against the target resource. The operation activities protect the execution of the "action" code for that activity as designed in Workflow Studio.

Each operation activity is derived from the OperationWorkflowBase activity, which exposes a number of methods and other members implemented by the deriving activities. Workflow Studio provides templates that allow for the quick creation of several different types of operation activities, depending on the number of resources involved in the workflow process. These include:

• Single Multi-Operation Activity — Used for creating Operation activities with one resource involved that could execute multiple operations.
• Dual Multi-Operation Resource Activity — Used for creating Operation activities with two resources involved that could execute multiple operations.
• Triple Multi-Operation Resource Activity — Used for creating Operation activities with three resources involved that could execute multiple operations. An example of a triple operation is the change Person primary Business Role and Location operation. To perform this operation, security is checked on the Person, Business Role, and the Location.

To use an Operation activity in a workflow, you search for the activity in the Workspace tree, drag it onto the workflow design surface and set any relevant properties on the activity.

When setting Operation activity properties, the following have particular importance. These properties are listed by category.

Bubble activities are activities that you can add to workflows to display a desired message to a user, such as whether the operation they attempted succeeded or failed. When encountered in a workflow, users simply click OK to close the message. Once a message is closed, the workflow resumes and either exits or performs some other function depending on the logic that follows the activity. This logic is defined by Line Rules. See the Line Rule section below for more information.

The following image shows an example of two Bubble activities within a single workflow, the CreateUserAndMailbox workflow. This workflow, among other things, allows users to create an AD user account and an Exchange mailbox for that account. Depending on what happens within the workflow, one or the other of the Bubble activities is executed. If an error occurs and the mailbox is not created, the workflow displays a message stating that it was unable to create the mailbox. If the user account and the mailbox are both successfully created, the workflow displays an Operation execution summary, stating the results of the workflow.

To use a Bubble activity in a workflow, you search for Bubble in the Activity toolbox, drag it onto the Workflow design surface and then set values for any appropriate properties. Bubble activities are UI activities, and as such have a lot of properties associated with them. However, of these properties, only a few have relevance for the Bubble activity. These are as follows:

Similar to Bubble activities, Confirm activities are activities that you can add to workflows to display to users a confirmation message with "Yes" and "No" buttons. These activities are often used in situations where resources are being deleted. When a users clicks a button, the workflow logic branches to execute any code associated with the response. Generally this encompasses either deleting the resource, sending the request for approval, or exiting the workflow.

The following image shows an example of a Confirm activity within a workflow, the DeleteMultiplePeopleWF workflow. For this particular workflow, the activity is executed and the message is displayed when a workflow initiator selects one or more people to be deleted. When the activity executes, the workflow waits for the user's input before resuming, following one of two possible outcomes.

To use a Confirm activity in a workflow, you search for Confirm in the Activity toolbox, drag it onto the Workflow design surface and then set values for any appropriate properties. As with Bubble activities, Confirm activities are UI activities, and as such have a lot of properties associated with them. However, of these properties, only a few have relevance for the Confirm activity. These are as follows:

Person p;
this.ConfirmDelete.Message = "Are you sure you want to delete" + p.FriendlyName + "?"

// Check to see if MessagesList is null
if (ConfirmDelete.MessagesList == null)
    ConfirmDelete.MessageList = new TheDotNetFactory.Framework.Common
      .Shared.Common.UnorderedListTree("Do you want to delete the following people:");

return CurrentWorkflow.ConfirmDelete.ConfirmDecision

System Code activities are activities that you can place in a workflow to execute custom code using the ExecuteCode event handler. To use a System Code activity in your workflows, you search for System in the Activity Toolbox, drag the activity onto the Workflow design surface, and then double-click it to generate the stub for the ExecuteCode handler. Once the stub is generated, you add the code you want the workflow to execute when the process reaches the activity.

Account ac;
this.Confirm.Message = "Are you sure you want to delete" + ac.FriendlyName + "?"

System Code activities have a number of relevant properties that you need to set when using them in a workflow. These properties are as follows:

System Parallel activities are activities that you can add to Flow Chart workflows when you need the workflow to execute code in parallel. Often, these activities are used to execute the operations enabled within Operation activities in parallel, such as when adding and removing accounts to and from groups.

The below image shows a System Parallel activity with an Operation activity added to each branch. When the workflow process reaches the activity, it will execute the operations associated with each branch in parallel and then proceed to the next activity. To use a System Parallel activity in your own workflows, you search for SystemParallel in the Activity Toolbox, drag the activity onto the Workflow design surface and then either drag the desired Operation activities onto the branches of the System Parallel activity.

System If Else activities--also known as Rule Decision activities--are advanced versions of System Parallel activities used in situation where conditions or rules need to be applied to parallel branches so that the logic associated with those branches only executes when the rule is met. An example of a workflow with this type of activity is the Update Person Group Membership workflow that ships with EmpowerID. This workflow provides users with the ability to both add and remove users to and from groups.

As shown by the above image, the System If Else activity (named UpdateGroupMembership in the workflow) has two branches, the IfAddAccountToGroupbranch and the IfRemoveAccountFromGroup branch, with each branch conditioned by what the user is trying to do. If the user is adding someone to a group, the logic in the IfAddAccountToGroup branch executes, while the logic in the IfRemoveAccountFromGroup branch executes if the user is removing someone from a group. If the user is both adding and removing someone to and from a group, the logic in both branches executes.

The determining factor for branch execution is the logic applied to the branch's Rule property. For this workflow, the logic is fairly simple, as shown by the below code examples. The first example shows the code for the AddAccountToGroup rule, while the second shows the code for the RemoveAccountFromGroup rule.

//Check to see if the user is adding the account to one or more groups
return CurrentWorkflow.AddAccountToGroupRequest.TargetGroups.Count > 0;

//Check to see if the user is removing the account from one or more groups
return CurrentWorkflow.RemoveAccountFromGroupRequest.TargetGroupAccounts.Count > 0 && CurrentWorkflow.RemoveAccountFromGroupRequest.TargetAccounts.Count > 0;

To use a System If Else activity in a workflow, you search for SystemIFElse in the Activity toolbox, drag the activity onto the Workflow design surface and then set values for any appropriate activity and branch properties. The properties you need to set are as follows:

On the activity itself:

On the activity's branches: