Overview

Workflows can represent an entire case management process and as such, can be complex and look intimidating. It might seem hard to know where to start, especially if your workflow requires input and tasks from multiple teams and people.

This page aims to introduce you to some of the key concepts and aspects of workflows, as well as provide you with examples of two common workflow use cases; a dispute process and a loan application process.

Looping and branching in workflows

Looping and branching are two common aspects of workflows that allow you to create flexible, no-code workflows that fit your real-world case management processes.

Looping

Looping is going back to a previous task or step in the workflow. This both allows steps to be re-done or updated with new information and can help to simplify the design of your workflow, reducing the need for multiple flows to cover the same task.

When designing workflows, it is a best practice to carefully define the loop so that the workflow doesn't get stuck in an infinite loop that constantly goes down the same path.

For example, in a loan management workflow, customers have the opportunity to update an incorrect loan application, which restarts the processing of the loan application. If you don't set up a decision task to limit the number of times that a loan application can be modified and re-reviewed, the process could loop indefinitely.

Branching

Branching is when a workflow breaks off into multiple, separate paths depending on the result of a decision or task. This allows for you to translate complex real world scenarios into a workflow in Studio that can accurately represent conditional tasks.

Branched workflows can stay on their own separate paths or reconverge as needed. If multiple branched paths converge into a single task, it is a best practice to require that the dependent tasks are completed before starting the converged task. This helps you to better control the workflow and reduce confusion.

Example use cases

Below are two examples of common use cases and workflow configurations. Use these to help you get an idea of how real world use cases can be translated visually and programmatically into workflows in Studio and how the different aspects of the workflow chain together.

Dispute process use case

Disputing claims or payments is a necessary part of many case management processes and allows you to reach the most accurate and satisfactory solution possible. Let's take a look at an example of one form this kind of process can take; an automated clearing house (ACH) dispute process.

This process for disputing ACH payments begins with a customer submitting a dispute form that provides personal and account information, as well as information about the dispute. The intake form kicks off a process that evaluates if the dispute is valid and within the bounds of the ACH network, before informing the relevant parties, such as case managers. Depending on the type of dispute, the case manager can resolve the dispute on their own or include merchants, who can either accept or dispute the claim. Claims can either lead to a win for the customer or a win for the merchant. Once a verdict has been reached, the customer is notified and the case is closed.

If you're interested in trying a tutorial that uses this use case, head over to the Studio Workflow Tutorial for complete details.

Here is a visualization of what that process might look like when turned into a workflow:

Workflow details

This workflow makes use of tasks, tasks blocks, and milestones, as well as including branching and multiple loops.

Here, the multiple loops allow you to account for the multiple possible paths that converge and diverge at different points in the dispute mitigation phase of the process.

The branching allows you to account for the decisions on the validity of the dispute and the decisions made regarding its judgment.

Here is a screenshot showing the details of the tasks in Studio:

Loan management and application process use case

Submitting applications is a vital first step in many case management processes and can be a user's first experience with an organization. Let's take a look at an example of one form this kind of process can take; a personal loan application process.

This process begins with a customer filling out a loan application with their personal details and financial information, before it's sent to the first part of a multi-step review process. If the loan is rejected in the first review, the process can either end, or the applicant can submit an appeal to reopen the request. If the application originally makes it past the first review, it is sent to pass bank and credit checks, get more information, and evaluate the loan risk before being sent back to the applicant. The loan can be rejected at any of the above decision points, with the option to be sent to the applicant appeal stage.

Here is a visualization of what that process might look like when turned into a workflow:

Workflow details

This workflow makes use of tasks, tasks blocks, and milestones, as well as including branching and looping.

Looping in this process allows for the process to converge at the customer appeal task from multiple different branches.

The branching in this process accounts for the many paths the process can take depending on the decisions made about the loan application and at what point they are made.

Here is a screenshot showing the details of the tasks in Studio: