Studio Workflow Examples

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 activity 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 or automation 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 in a task or a condition in an automation. This allows for you to translate complex real world scenarios into a workflow in Studio that can accurately represent conditional activities.

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

Example use cases

Below are 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 cases

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 two example of some forms this kind of process can take; an automated clearing house (ACH) dispute process and a credit card dispute process.

Automated clearing house dispute

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 this 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 activities in Studio:

Credit card dispute

This process is similar to the ACH dispute process one above, but includes a workflow automation.

Like the ACH dispute process, this process begins with a customer submitting a dispute. However, instead of going directly to a manual review of the dispute like the original dispute process, the credit card dispute process first uses a workflow automation.

This workflow automation conditionally routes the dispute to different groups for review based on the dispute's dollar amount and credit card type. The dispute then follows a similar path to the ACH dispute process; the workflow includes tasks for reviewing the dispute validity, gathering more information, issuing refunds, and initiating arbitration. In both dispute processes, once a verdict has been reached, the customer is notified and the case is closed.

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

Workflow details

This workflow makes use of tasks, tasks blocks, and milestones, workflow automations, branching, and looping.

Here, the automation has conditions that check the values of the dollar amount and credit card type data fields and specifies which way to route the dispute based on the field values. The dispute is then sent to the groups responsible for disputes of high or low value or those involving certain types of credit cards.

This allows for the correct groups to be involved in the dispute, without requiring a human to personally sort through all disputes and manually route them based on the set criteria.

Here is a screenshot showing the details of the activities 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 this 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 activities in Studio:

Feedback