# Understanding Workflows

> Workflows are integration tests: visual flows of API and logic nodes that chain calls, pass data between steps, and validate with per-step and workflow-level SLA assertions.

Source: https://totalshiftleft.ai/help-center/product-documentation/understanding-workflows

## Overview

In Shift Left Studio, **Workflows** are **end-to-end integration tests**: you design them as a visual graph of steps (nodes), run them like other tests, and review outcomes in a **Workflow Execution Report**. "Workflows" and "Integration tests" are two names for the same feature — the **Workflows** page header reads *"Create and manage end-to-end workflows/Integration tests."* Explore the capability at [integration test workflows](/features/test-execution/integration-test-workflows).

## Before you begin

- Reach workflows from the top navigation **Workflows** entry. The page's main table is titled **Integration Tests**.
- You need at least one project with tests to place on the canvas; the flow editor's **Test Library** reads existing tests from your projects.
- For the click-by-click builder, see [Creating and Running Workflows](/help-center/product-documentation/creating-and-running-workflows).

## Two surfaces you will use

| Surface | Purpose |
|---------|---------|
| **Workflows list** (the **Integration Tests** table) | See all workflows, search, **Run Selected** / **Delete Selected** in bulk, **Add Test** to create one, and per-row **Run**, **View Test Result**, **Edit Test**, **Copy workflow**, and **Delete Test**. |
| **Flow editor** | Build and save the flow: a left sidebar with **Test Details**, **Test Library**, and **Node Types** tabs; a canvas; and a header with **Save**, **Launch Workflow**, and **Exit**. |

## What a workflow contains

A workflow chains **API test nodes** (dragged from the **Test Library**) together with system and logic nodes from the **System Blocks** palette. Every flow begins at a **▶ Start** node (its subtitle reads *"Entry point"*) and ends at a **■ Stop** node. The palette is grouped into categories:

- **Variables & State** — Create Variable, Set Variable, Get Variable
- **Data Operations** — String Operation, Number Operation, Date/Time Operation, Array Operation, JSON Operation, XML Operation, Data Source Operation
- **Advanced Control Flow** — IF/ELSE, Run if, FOR EACH, WHILE, BREAK
- **Assertions & Validation** — Assertion, Data Compare
- **Execution Control** — Start, Stop, Wait/Delay, Skip, Inconclusive
- **Utilities** — Script, Log/Debug
- **Workflow-Level Gates** — Post-Run SLA Gate (a post-run gate, not a canvas node)

Nodes are connected by dragging between handles. The editor validates that the graph has a proper **Start → Stop** structure and blocks saving (and warns on exit) when it doesn't.

## Passing data between steps

Each API test node can define **Variable Outputs** — values extracted from its response and reused downstream. An extraction has a **Variable Name**, a **Source Type** (**Response Body**, **Response Header**, **Status Code**, or **Status Text**), a **Path**, an **Array Strategy** (**First Item**, **Last Item**, **All Items**, or **By Index**), an optional **Transform**, and a **Required** flag that fails the test if extraction fails. The **Variables & State** nodes (Create/Set/Get Variable) let you manage variables explicitly across the flow.

## Assertions

Shift Left Studio validates a workflow at two levels:

- **Per-step assertions** — the **✓ Assertion** and **⚖ Compare** (Data Compare) nodes validate a specific step. Operators include equals, not-equals, contains, greater/less than (and or-equal variants), schema match, exists, is-empty, is-type, and matches. An API test node also carries its own assertions (status code, response contains/matches regex, response is JSON/XML, response time, field exists/equals/type).
- **Workflow-level SLA gates** — the **Post-Run SLA Gate** opens the **Workflow Assertions** editor. These are evaluated against aggregate metrics across all API calls in the run — performance (response time / latency at percentiles p50, p95, p99, avg, max; throughput; error rate; SLA compliance) and status code (equals, not-equals, in-range, one-of). A failing gate downgrades the run from **PASSED** to **FAILED**.

## Reporting

Running a workflow opens a **Workflow Execution Report**. You start on a high-level view and drill into a detailed, per-node report. Workflow executions also surface in [Test reporting](/help-center/product-documentation/test-reporting) with **Run type** **Workflows**, and drill through [High-level test report](/help-center/product-documentation/high-level-test-report) → [Workflow execution details](/help-center/product-documentation/workflow-execution-details) → [Detailed Test Report (Workflow)](/help-center/product-documentation/detailed-test-report-workflow).

## Best practices

- Keep flows **readable**: give the workflow and its nodes clear **Name**s and add a **Description** and **Tags**.
- **Capture** tokens and IDs as **Variable Outputs** instead of hardcoding them.
- Add **Assertion** or **Compare** checks on critical steps so a failure points at the right node.
- Include **cleanup** or idempotent steps when a workflow mutates data.
- Use a **Post-Run SLA Gate** when the whole run must meet latency/error-rate targets, not just individual steps.

## Related articles

- [Creating and Running Workflows](/help-center/product-documentation/creating-and-running-workflows)
- [Workflow execution details](/help-center/product-documentation/workflow-execution-details)
- [Test case](/help-center/product-documentation/test-case)
- [Data-driven testing](/help-center/product-documentation/data-driven-testing)