Build End-to-End Workflows Automatically

Overview

An end-to-end workflow tests a journey — create an order, pay for it, fetch the receipt — rather than one call. Building one by hand means choosing the steps, putting them in order, picking a test for each, and wiring the value each step needs from an earlier step's response.

Shift-Left Studio can now do that work for you. It reads the journeys your requirement documents describe, the flows your API specification implies, and the tests you already have, and it proposes workflows that are ready to build. Each proposed workflow arrives with its steps in order, an existing test for each step, and the data connectors between them already wired.

When a journey cannot be built yet, Studio tells you exactly why, step by step — and distinguishes between a step that simply has no test yet (you can generate one) and a step the specification does not declare at all (the document describes a call the API is not documented to have).

Key concepts

Before you begin

• Import at least one API specification into the project (see Import API to Project in the project tree).
• Generate tests for the endpoints you want in your journeys. A step can only be part of a workflow if a test exists for it.
• To build journeys from requirement documents, upload and parse the documents on the Requirements screen and approve the use-case requirements.
• To build a workflow from a sentence, or to generate missing tests and build in one step, the project assistant must be available (an AI provider must be configured).

Where the order of steps comes from

Studio uses evidence, ranked from strongest to weakest:

Note: Building a workflow from the order calls happen in recorded runs or captured traffic is not available yet. Today, order comes from requirements, specifications and your description.

Step 1 — Build journeys from your requirement documents

1. Click Requirements in the top navigation.
2. Open the Gaps & conflicts tab.
3. Scroll below the gaps list to Journeys. Journeys are listed in two groups:
   • Ready to build — every step already has a test (for example, 5 steps, every one of them already tested.).
   • Blocked — with the reason, naming each step that is missing a test or an endpoint.
4. Click Build N workflow tests to build every ready journey.
5. Read the result line, for example Built 2 and updated 0 workflow test(s). A journey that could not be built is listed below with its reason.

Tip: You usually do not need to press the button at all. Whenever you generate tests, Studio checks whether the new tests complete any approved journey, and builds those workflows automatically a few seconds later.

If you see No journeys in this project, no approved requirement records its calls in order. Prose that names no ordered calls cannot become a workflow; the gaps list reports such requirements as narrative only.

Step 2 — Build flows suggested by your specification

1. Click Workflows in the top navigation, with a project selected.

2. Click Generate end-to-end flows. The panel End-to-end flows this project could have opens. Nothing in it has been created yet.

3. Review each suggestion. It shows a name, a description and a confidence label:

   Label	Meaning
   Certain	The order is stated by the specification (for example, an OpenAPI link).
   Inferred	The order follows a strong convention, such as create before read.
   A guess — check it	The order is plausible but weakly supported. Review the steps carefully.

4. Click Show the N steps to see each step in order. A ready step shows the test it runs (runs "…") and the values it passes on (passes on orderId). A missing step is struck through, with the reason nothing tests this yet or the specification does not declare this call.

5. Click Build this workflow on a suggestion under Ready to build.

6. Click Not this one to dismiss a suggestion. It does not come back unless the underlying flow changes.

7. Click Look again after importing a specification or generating tests to refresh the list.

Suggestions that cannot be built yet appear under Not yet — and why, with the reason in words. The Build this workflow button is absent for them.

Step 3 — Understand the data wiring

Every generated workflow is wired before it is created:

1. For each input a step needs, Studio looks for an earlier step whose response contains it — either a field with the same name, or the ID returned by the endpoint the field is named after (for example, orderId from the endpoint that creates orders, whose response contains id).
2. When it finds one, it adds an extraction to the earlier step's test so the value is captured at run time, and adds a data connector to the later step.
3. A value the step's own test already supplies (such as the name and email in a create-user request) is not treated as missing.
4. An input no earlier step produces is reported by name rather than guessed.

Important: Extractions are added to the earlier steps' tests before the workflow is created, and they are only ever appended — an existing extraction is never changed. If one cannot be added, the workflow is not created, because a connector that carries nothing would fail on its first run while looking correct.

After building, open the workflow and click Check workflow to have the Workflow Doctor confirm every binding.

Step 4 — Resolve gaps

Every blocked journey or suggestion names the steps holding it back, and the kind of gap:

Studio never fills a gap with a placeholder step. A plausible but wrong step is worse than a missing one, because it would be run.

Step 5 — Build a workflow with the assistant

The project assistant is a front door onto the same builders. Open the assistant and ask in plain language.

Build a named journey

1. Ask, for example, Build the workflow for REQ-8ECC3DF4.
2. The assistant checks the journey first and shows a card naming the workflow and its steps, including any steps that run from another project.
3. Click to accept. The workflow is built through the same process as the Journeys panel.

Generate the missing tests and build, in one accept

If a named journey is blocked only because some steps have no test, and those endpoints are in the current project, the assistant offers to do both:

1. The card lists the tests that would be generated (a real dry run) and names the workflow that will follow.
2. Accept once. Studio generates the tests, and when generation succeeds, builds the workflow.
3. The conversation reports the outcome. If the tests were created but the workflow still could not be built, that is reported as a failure with the reason — not as done.

This offer is not made when any step is a no endpoint gap, when you ask for every journey at once, or for steps whose endpoints are in another project (those are named and left out).

Build from a sentence

1. Describe the journey, for example A workflow that creates an order, pays it, then fetches the receipt.
2. The assistant maps each part of your sentence to one endpoint, in your order. A part that matches no endpoint is reported as unmatched, never guessed.
3. Test selection and wiring follow the same rules as above. Review the card and accept.

Step 6 — Work with cross-project workflows

A journey often crosses projects — for example, sign-in in an identity project and ordering in a commerce project. Studio searches every project you can already open for the steps' endpoints and tests. A project you cannot open is never searched.

• A suggestion whose steps span projects says Its steps run in N projects, each against its own environment. Each test step runs against an environment of its own project.
• The primary project is the project of the first step. The run is recorded against it, and steps that are not tests (such as Wait or Script blocks) use its environment.
• When the Workflow Doctor offers a replacement test for a step, candidates from every project are listed with the project name.

Tip: Keep environment names consistent across projects (for example, QA in each). A test run pack running a cross-project workflow can also name a different environment per project; see "Automating this".

Workflows as requirement coverage

A workflow built from a use-case requirement keeps a link to that requirement. The gaps list reports such a requirement as covered by a workflow only when it genuinely can be — it records ordered calls. The Workflow Doctor later compares the workflow with the requirement and reports any step the requirement describes that the flow no longer contains.

Troubleshooting

Best practices

• Write use cases in requirement documents as ordered calls (method and path) — that is what makes them buildable.
• Approve use-case requirements before generating tests, so journeys build themselves as tests arrive.
• Prefer suggestions labelled Certain or Inferred; review guesses step by step.
• Run the Workflow Doctor on every generated workflow before its first run.
• Run new workflows in a non-production environment first; a happy-path journey creates real data.

Related articles

• Workflows
• Importing and reviewing requirements
• Requirements traceability matrix
• Test run packs
• Environments
• Project assistant
• Workflow Doctor: Diagnose and Fix a Workflow
• Requirement Gaps and Use-Case Journeys

Automating this

A test run pack accepts a per-project environment map for cross-project workflows. Set it with PUT /api/test-run-packs/:id using the field environmentByProject (an object mapping each project ID to an environment name). Where the map names no environment for a project, the pack's single environment is used.

For administrators (self-hosted installations)