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.

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.

Two surfaces you will use

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 with Run type Workflows, and drill through High-level test report → Workflow execution details → Detailed Test Report (Workflow).

Best practices

• Keep flows readable: give the workflow and its nodes clear Names 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
• Workflow execution details
• Test case
• Data-driven testing