Understanding Workflows

Overview

In Shift-Left API, 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 API 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.

Home project and run settings

A workflow can call tests from several projects, but it has one home project that owns it. The home is chosen when the workflow is created and is never moved by a save. You can move it with Change under Run settings in the editor sidebar, or by selecting Home: in the header. The Workflows list groups workflows by owned, used and not in a project.

At run time, Run with… lets you pick an environment for each project the workflow uses and shows a preview before anything is sent. The choice is remembered per workflow. Production environments are marked in red. See Creating and Running Workflows for the steps.

When an approved specification change touches an API that a workflow calls, the workflow gets a note asking you to check that its steps still work. Nothing is run or edited for you. A workflow that passed and then failed every run since is also flagged in the list. See Reviewing a specification change.

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