EmpowerID Workflow

In EmpowerID, the workflow is the primary means by which your users and your IT resources converge to accomplish specific organizational tasks. All workflows have at least two layers, a process layer that represents the workflow and how it functions in a business environment and a data layer that represents the information being captured by the workflow. Workflows using these layers are generally automated and initiated by pre-determined processes and can be used to capture data for reporting, compliance, and other needs. Other workflows are user-centric. They do not occur in response to automated system events, but require human interaction, whether that involves simply clicking a button to initiate a workflow or entering and manipulating data at various points throughout a workflow's lifecycle. Like automated workflows, user-centric workflows comprise process and data layers, but they contain an additional layer as well — the presentation layer. As the name suggests, the presentation layer is that part of the workflow that presents itself to the end-user. Known as the form or lookup, the presentation layer gives users functional access to a workflow by providing the interface that allows them to work with business objects and data.

A typical EmpowerID workflow is comprised of a number of components that when joined together make it possible for you and your users to work with your IT resources. Depending on the purpose of the workflow, not all of these need to be present; however, in most cases you will find that the workflow you are initiating has most, if not all, of these components built in.

These components are as follows:

  • Activities - Activities, or shapes, are the building blocks of the EmpowerID workflow and contain the logic that defines a specific step or process within a given workflow. In EmpowerID, workflow activities can be either Form activities, Lookup activities, or Operation activities. Form and Lookup activities comprise the presentation layer of an EmpowerID workflow. They are what users see and interact with when working in a workflow. EmpowerID captures the data entered into the form fields and/or drop-downs of these user interface elements of a workflow, binding it to the workflow in a way that ensures the integrity of the data is maintained throughout the workflow lifecycle. Operation activities are activities based on the EmpowerID workflow authorization framework that the workflow uses to determine at runtime if the current user in a workflow process can execute the code in that activity against a specific object (such as changing his or her own profile picture). If the person can perform the task, the workflow continues; if the person cannot perform the task, EmpowerID routes the task to any designated approvers, who must approve the request before EmpowerID allows the code to be executed. Activities are joined to one another by lines to allow the workflow to progress from one workflow process to another.

  • Business Rules - Business Rules are Boolean expressions applied to the lines connecting workflow activities to one another to determine whether a workflow can progress from one activity to another based on how the rule evaluates at the time the workflow process reaches the line. If the Business Rule evaluates to true, the process flows through the line and on to the next activity; conversely, if the Business Rule expression evaluates to false, the process cannot flow through the line and must take another path in the workflow.

  • Escalations - Escalations are special rules that can be applied to Operation and Form activities to direct a workflow to take specific actions when conditions required to complete a business task process do not occur within a specific timeframe. These actions can range from the sending of emails and dashboard notifications to users when a workflow process requires human interaction to continue, to directing the workflow to complete the process if human interaction with does not occur within a given period of time. Escalations ensure that a workflow process does not idle indefinitely while waiting for user input and become disabled when tasks pertaining to them are completed.

Using these components, the process of a typical EmpowerID workflow could look like that depicted below. In the image, the Presentation Layer is separated from the Data and Process Layers to allow you to more easily see what happens when a workflow is initiated. Although we have separated the layers for depiction purposes, in reality, all three layers contain elements of one another and are inseparable in the workflow process.

From the image, we can see that the workflow contains a number of activities, data bindings, and Business Rules. Each of these workflow components work together to direct what happens in a workflow, and how it happens.

  1. The workflow is initiated by a person within EmpowerID.
  2. EmpowerID presents the workflow initiator with a form or lookup (the Presentation Layer), which requires the workflow initiator to enter data.
  3. The data entered in the form or lookup is bound to a second activity, which uses the data to perform some type of work.
  4. The workflow progresses to an Operation activity, which checks the delegations of the person initiating the workflow before allowing its code to be executed by that person. If the workflow initiator lacks the authority to proceed, EmpowerID routes the operation to any designated approvers, placing a task on their dashboards and sending email notifications as appropriate. At least one approver must approve the request before the initiator can proceed.
  5. At this point, the process flows to one of two activities based on the response of the approver and the logic of the Business Rule applied to the lines connecting the Operation activity to those activities. In our example, the red line depicts where the process flows if the approver denies the request and the green line depicts where the process flows if the approver approves the request.
  6. If the request is approved, the workflow proceeds to the Wait activity (designated by the diamond shape), which idles the workflow for a predetermined period of time to allow the initiator to perform some tasks. If the request is denied, the workflow proceeds to the Final activity, designated by the oval shape, which then proceeds to exit the workflow.
  7. Once the idle time passes, the process flows either to the second Operation activity or the Final activity depending on the logic of the Business Rule applied to the two lines connecting the Wait activity to the those activities.
  8. If the request is approved, the workflow loops back to the Wait activity where the process outlined in step 6 above repeats itself. If the request is denied the workflow proceeds to the Final activity and exits the workflow.