About Workflow Studio

Workflow Studio is EmpowerID's integrated development environment (IDE) designed specifically for developers to create, modify, and extend workflows. With Workflow Studio, you gain access to a comprehensive set of tools that streamline the design and customization of workflows to fit the unique needs of your organization.

Key Features of Workflow Studio:

1. Pre-built Workflow Templates – Workflow Studio offers a vast library of pre-built workflows, covering common IAM and SSO scenarios. Developers can leverage these templates to save time and effort, ensuring a solid foundation for their custom workflows.

2. Visual Process Designer – The intuitive drag-and-drop interface of Workflow Studio allows developers to easily design and modify workflows without extensive coding. The visual process designer simplifies the creation of complex workflows and enables rapid development.

3. Extensibility and Customization – Workflow Studio is built with extensibility in mind, empowering developers to create custom workflow activities, integrate with third-party APIs, or develop unique functionality to address specific organizational needs.

4. Version Control and Collaboration – Workflow Studio supports version control and collaboration features, allowing development teams to work together efficiently, track changes, and maintain a history of workflow modifications.

5. Debugging and Testing – Workflow Studio includes debugging and testing tools that enable developers to validate and troubleshoot their workflows before deploying them in a production environment.

By harnessing the power of Workflow Studio, developers can effectively create, customize, and deploy robust workflows that cater to their organization's specific requirements, streamline operations, and enhance overall security and access management.

What is a workflow?

A workflow is a sequence of activities that mirrors the steps in a business process. It provides a logical, orderly representation of the actual tasks carried out by individuals or systems interacting with a business model. In EmpowerID, workflows serve as the primary method for users to engage with IT resources to achieve specific organizational objectives.

There are three primary layers in a workflow:

1. Process Layer – This layer represents the logical flow of the activities within a workflow. It defines the sequence and conditions of tasks, decision points, branching, and parallel execution paths.

2. Data Layer – The data layer captures and manages the information processed throughout the workflow. It includes input and output data, intermediate variables, and any data transformations or manipulations required by the workflow activities.

3. Presentation Layer – This layer is specific to user-centric workflows that require human interaction. It provides the user interface (UI) through which end-users interact with the workflow, input data, or make decisions.

A typical EmpowerID workflow is comprised of a number of components. Depending on the purpose of the workflow, not all of these need to be present.

Forms

Forms offer components that enable users to input information into a workflow, which can subsequently be collected and utilized throughout the workflow. Workflow Studio incorporates form data into a workflow through a compilation and publication process, creating a specific type of activity called a "Form activity." Upon publication, Form activities can be integrated into workflows, where Workflow Studio's drag-and-drop property binding capabilities facilitate the transfer of form data to and from other workflow objects during runtime.

Form Components

Form components in Workflow Studio are divided into two categories: Primitives and RBAC Components. Primitives enable the inclusion of simple objects, such as drop-downs, calendar controls, and fields, on a form. Conversely, RBAC Components allow for the incorporation of properties from objects bound to EmpowerID-protected resources on a form. Each of these RBAC components can be employed to retrieve the properties of protected resources for use within a workflow.

For instance, if you need to capture data specific to a workflow initiator with an EmpowerID identity, you can add an RBAC Component for a Person object to a form. This allows you to integrate only the relevant properties (person attributes) into your form design, according to your data requirements.

Form Types

Workflow Studio offers two types of forms for workflow usage: User Input forms and User Decision forms. The choice of form depends on the desired functionality at a specific point in the workflow.

1. User Input forms – These forms allow users to input information and submit the data back to the workflow for use in subsequent activities. User Input forms appear to any user running the workflow at the point in the process where the form is placed. They can be used anywhere within a workflow and are often the first form encountered. For example, in a workflow that enables users to request resources or other actionable events, you can add a shape derived from a User Input form, allowing users to enter and submit their request details back to the workflow. The workflow then moves to the next step as dictated by the business requirements.

2. User Decision forms – These forms appear within a workflow when the process requires further user input or approval to proceed. Typically, User Decision forms derive their data from a User Input form and are used when a response to that data is necessary. Based on the User Decision Form Base Activity developed by EmpowerID, these forms offer routing options, create workflow tasks for approvers, and send email notifications about the request to all relevant parties. When a workflow encounters a User Decision Form activity, it enters an idle state until a response or escalation occurs. Continuing the previous example, after a user submits a resource request via a User Input form, you could add a shape derived from a related User Decision form as the next step, requiring a user decision for the workflow to advance.

ACTIVITIES

Activities, or shapes, serve as the foundational elements of EmpowerID workflows and encapsulate the logic defining specific steps or processes within a workflow. Workflow activities in EmpowerID can be categorized as Form activities, Lookup activities, or Operation activities.

Form and Lookup activities make up the presentation layer of an EmpowerID workflow, representing the user interface elements that users interact with during the workflow process. EmpowerID captures data entered into form fields or drop-downs, binding it to the workflow in a manner that maintains data integrity throughout the workflow's lifecycle.

Operation activities are based on the EmpowerID workflow authorization framework, which the workflow employs to determine if the current user in a workflow process has permission to execute the code in that activity against a specific object (e.g., changing their own profile picture). If the user is authorized to perform the task, the workflow proceeds; if not, EmpowerID routes the task to designated approvers, who must approve the request for the code execution. Activities are connected by lines, allowing the workflow to advance from one process to another.

In Workflow Studio, activities can be divided into two types: Form activities and Operation activities.

Form Activities

When a form is published in Workflow Studio, a unique "Form activity" is generated and published to the EmpowerID Identity Warehouse. In this activity type, form fields are created as dependency properties, allowing you to leverage the drag-and-drop property binding capabilities of Workflow Studio to send data to and from the form. To incorporate an existing published form in a workflow, simply add the generated activity to the workflow.

Operation Activities

Operation activities, based on the EmpowerID workflow authorization framework, determine if the current user in a workflow process can execute the code within that activity. At runtime, they ascertain if the current user possesses any EmpowerID roles with the necessary operations to perform the attempted action against the target resource(s) and manage any required approval process. Approvals are routed to individuals granted the ability to perform the operation against the target resource. Operation activities safeguard 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 various methods and members implemented by the deriving activities. Workflow Studio offers templates that facilitate the swift creation of diverse operation activities, depending on the number of resources involved in the workflow process. These include:

1. Single Multi-Operation Activity – Utilized for creating Operation activities with one involved resource capable of executing multiple operations.

2. Dual Multi-Operation Resource Activity – Employed for creating Operation activities with two involved resources capable of executing multiple operations.

3. Triple Multi-Operation Resource Activity – Applicable for creating Operation activities with three involved resources capable of executing multiple operations. An example of a triple operation is changing a person's primary business role and location operation. To perform this operation, security is checked on the Person, Business Role, and Location.
   
   

BUSINESS RULES

When developing workflows, business requirements often demand varying outcomes based on the conditions present during workflow execution. For instance, some users may be able to initiate a workflow but lack the appropriate permissions to perform all operations associated with certain activities in that workflow, while others possess all necessary permissions to execute every operation within the workflow. In such cases, outcomes must differ. Users without permissions should have their actions routed for approval before execution and be removed from the process if approval is denied. Users with full permissions should be able to complete each business process task in the workflow without interruption. These requirements are met through the use of Business Rules.

In Workflow Studio, Business Rules are Boolean expressions that you create and apply to the lines connecting activities at points where the process can diverge based on the conditions encountered by the activities. When a Business Rule is applied to an activity line, it sets the conditions that dictate whether the process can flow through that line. If the Business Rule expression evaluates to true, the process flows through the line and proceeds to the next activity; if the expression evaluates to false, the process cannot flow through the line and must follow an alternative path. Generally, one Business Rule applies to any two lines exiting a given activity, evaluating true for one line and false for the other.

Business Rules can only be implemented with Flow Chart workflows, as they allow the creation of multiple exit points on a single activity. Other workflow types require using IfElse activities and branching to achieve a similar effect. The utilization of flow charts and Business Rules enables process flow simplification.

The following image illustrates how Business Rules determine a workflow's outcome. In the image, a user initiates a workflow and encounters the first activity without any issues. The activity executes the code, and the process flows to the Operation Activity, which contains operations against protected resources. To execute the operations, the user must have those operations permitted for the resources targeted by the Operation Activity. If the user is granted or approved for those operations, the code within the Operation Activity executes against the resources, and the process continues to other activities in the workflow. If the user lacks the necessary permissions for the resources and is denied by an approver, the code within the Operation Activity remains unexecuted, and the process flows to the Exit Workflow activity. In both cases, the Business Rule applied to the activity lines serves as the controlling factor for the process flow.

Open

In this example, the same Business Rule is applied to both activity lines, but the evaluation of the rule's logic differs. The logic of the Business Rule might resemble the following code:

This code simply returns the value of OperationExecuted. When using a Business Rule with activity lines, you control the flow by applying the evaluation of the Business Rule to the lines. In the above image, the line connecting the Operation Activity to the other activities has a Business Rule applied with an evaluation of true, while the line connecting the Operation Activity to the Exit Workflow activity has a Business Rule applied with an evaluation of false. This approach ensures that the workflow proceeds based on the user's permissions and the outcomes of the Operation Activity.

ESCALATIONS

In a Workflow Studio workflow application, Operation and Form activities can be configured with rules called Escalations, which direct the workflow to take specific actions when certain conditions are not met within a predefined timeframe. Escalations are scheduled time interval objects designed to trigger specific events within the workflow when the defined time interval expires.

These events can range from sending emails and dashboard notifications to users when a workflow process requires human interaction, to directing the workflow to complete the process if human interaction does not occur within a given period. Escalations ensure that a workflow process does not idle indefinitely while waiting for user input and become disabled when tasks related to them are completed.

Workflow Studio offers several default actions that you can apply to an escalation to define what happens when the Escalations job triggers the escalation. These actions are coded events that occur based on the schedule parameters entered in the wizard, allowing you to define what happens when the escalation is raised in a workflow without writing custom code. These default actions are accessible via the Escalations wizard, and you can add them to an escalation at any time. They include the following:

• Complete Task – This directs the escalation to complete the activity with a hard-coded form decision if human intervention does not occur after a specified amount of time. If a succeeding rule has been added to the activity, you can direct the escalation to override that rule.

• Notify Approvers Manager – This directs the escalation to send an email notification to the manager of the approver if the approver does not respond within a specified amount of time. This requires that the manager be set on an account owned by the person.

• Re-Notify Approvers – This directs the escalation to send a reminder email of the task awaiting their approval if the approver does not respond within a specified amount of time.
  
  

PUTTING IT ALL TOGETHER

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.

Open

In the example provided, the EmpowerID workflow comprises several activities, data bindings, and Business Rules, which work together to control the workflow and its processes. The typical workflow process can be outlined as follows:

1. A user initiates the workflow.

2. EmpowerID presents a form or lookup (the Presentation Layer) to the user, which requires data input.

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 access of the user initiating the workflow before allowing its code to be executed. If the user lacks the authority to proceed, EmpowerID routes the operation to designated approvers, placing a task on their dashboards and sending email notifications as appropriate. At least one approver must approve the request before the workflow can progress.

5. 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 this example, the red line represents the process flow if the approver denies the request, and the green line represents the process flow 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 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) and exits 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 those activities.

8. If the request is approved, the workflow loops back to the Wait activity, where the process outlined in step 6 repeats itself. If the request is denied, the workflow proceeds to the Final activity and exits the workflow.

This workflow example demonstrates how EmpowerID uses various components to manage and control the flow of a typical process, ensuring that tasks are performed as expected and that users with appropriate permissions can execute the necessary operations.