Workflow sequencing in Postman - Deep Dive

Overview - Workflow sequencing

What is it?

Workflow sequencing in Postman is the process of arranging API requests in a specific order to simulate real user or system interactions. It allows testers to automate a series of API calls where the output of one request can influence the next. This helps in testing complex scenarios where multiple steps depend on each other. It ensures that APIs work together correctly as they would in real use.

Why it matters

Without workflow sequencing, testing APIs would be limited to isolated calls, missing how they interact in real life. This could lead to bugs in how data flows between services or how state changes over time. Workflow sequencing helps catch these issues early, saving time and preventing failures in production. It makes automated testing more realistic and reliable.

Where it fits

Before learning workflow sequencing, you should understand basic API requests and how to use Postman to send them. After mastering sequencing, you can explore advanced topics like environment variables, scripting tests, and continuous integration of API tests.

Mental Model

Core Idea

Workflow sequencing is like following a recipe where each step depends on the previous one to create a complete dish.

Think of it like...

Imagine baking a cake: you must mix ingredients, bake the batter, then add frosting. You can't frost before baking. Workflow sequencing is the same for APIs, where each request is a step that must happen in order.

┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ Request 1     │ → │ Request 2     │ → │ Request 3     │
│ (e.g., login) │   │ (e.g., get    │   │ (e.g., update │
│               │   │ user data)    │   │ profile)      │
└───────────────┘   └───────────────┘   └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding API Requests in Postman

Concept: Learn what an API request is and how to send one using Postman.

An API request is a message sent to a server asking for data or action. In Postman, you create a request by entering the URL, choosing the method (GET, POST, etc.), and sending it. The server replies with a response you can see in Postman.

Result

You can successfully send a single API request and view its response in Postman.

Knowing how to send and receive API requests is the foundation for building any workflow sequence.

2

Foundation

Using Variables to Store Data

Concept: Learn how to save data from one request to use in another using variables.

Postman lets you save parts of a response (like a token or ID) into variables. You write simple scripts in the Tests tab to extract data and store it as environment or global variables. These variables can then be used in later requests by referencing them with {{variableName}}.

Result

You can capture a value from one response and reuse it in the next request URL or headers.

Variables connect requests by passing data along, enabling the sequence to behave like a real interaction.

3

Intermediate

Chaining Requests with Tests and Variables

🤔Before reading on: Do you think you can run multiple requests in order automatically in Postman? Commit to yes or no.

Concept: Learn how to run requests one after another by using tests to set variables and control flow.

In Postman Collections, you arrange requests in order. After each request, you write test scripts to save needed data. When you run the collection, Postman uses these variables to feed the next request. This chaining simulates a workflow where each step depends on the previous.

Result

A collection run executes requests sequentially, passing data between them automatically.

Understanding chaining is key to automating realistic API scenarios that depend on previous responses.

4

Intermediate

Controlling Workflow with Pre-request Scripts

🤔Before reading on: Can you modify request data dynamically before sending it? Commit to yes or no.

Concept: Learn how to use pre-request scripts to prepare or change data before each request runs.

Pre-request scripts run before a request is sent. You can write JavaScript code here to set or update variables, calculate timestamps, or modify headers. This lets you customize each request dynamically based on earlier results or time.

Result

Requests can adapt their data on the fly, making workflows flexible and powerful.

Pre-request scripts give you control to shape each step, enabling complex and realistic test flows.

5

Advanced

Handling Conditional Workflows and Errors

🤔Before reading on: Do you think Postman can skip or repeat requests based on conditions? Commit to yes or no.

Concept: Learn how to create workflows that change path or handle failures using scripts and test results.

Postman allows you to write tests that check response status or data. Based on these, you can set variables that control which requests run next using the Collection Runner or external tools like Newman with scripts. You can also retry failed requests or stop the run early.

Result

Workflows become smarter, reacting to success or failure and following different paths.

Handling conditions and errors makes your tests robust and closer to real-world usage.

6

Expert

Integrating Workflow Sequencing in CI/CD Pipelines

🤔Before reading on: Can Postman workflows run automatically in software delivery pipelines? Commit to yes or no.

Concept: Learn how to run Postman collections with workflows in automated environments like Jenkins or GitHub Actions.

Using Newman, Postman's command-line tool, you can run collections with workflow sequences in CI/CD pipelines. This automates API testing on every code change. You can generate reports, fail builds on errors, and integrate with other tools for full automation.

Result

API workflows run automatically during development, catching issues early and improving software quality.

Embedding workflow sequencing in CI/CD bridges testing and delivery, making quality a continuous process.

Under the Hood

Postman executes workflow sequencing by running requests in the order defined in a collection. After each request, test scripts extract data and store it in variables within the environment or global scope. Subsequent requests access these variables to customize their inputs. Pre-request scripts run before each request to prepare or modify data. The Collection Runner or Newman executes these steps sequentially, managing state and flow control through scripting.

Why designed this way?

This design allows flexibility and power without hardcoding dependencies. Using scripts and variables lets users create dynamic workflows that adapt to changing data. It separates request definitions from control logic, making workflows easier to maintain and extend. Alternatives like fixed static sequences would be less flexible and unable to handle real-world API interactions that depend on runtime data.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Request 1     │─────▶│ Test Script   │─────▶│ Save Variable │
│ (Send API)    │      │ (Extract data)│      │ (Store token) │
└───────────────┘      └───────────────┘      └───────────────┘
        │                                         │
        ▼                                         ▼
┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Pre-request   │◀─────│ Use Variable  │◀─────│ Request 2     │
│ Script (set   │      │ in request    │      │ (Next API)    │
│ headers)      │      │ (URL, headers)│      │               │
└───────────────┘      └───────────────┘      └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Postman automatically run requests in parallel by default? Commit to yes or no.

Common Belief: Postman runs all requests in a collection at the same time to save time.

Reality: Postman runs requests sequentially in the order they appear in the collection unless explicitly configured otherwise.

Why it matters: Believing requests run in parallel can cause confusion when variables set in one request are not available in the next, leading to test failures.

Quick: Can you use variables from one environment directly in another without copying? Commit to yes or no.

Common Belief: Variables set in one environment are automatically available in all other environments.

Reality: Variables are scoped to their environment or global level; they do not transfer automatically between environments.

Why it matters: Assuming variable sharing leads to tests passing locally but failing in different environments, causing unreliable workflows.

Quick: Does Postman retry failed requests automatically during a collection run? Commit to yes or no.

Common Belief: Postman automatically retries any failed request to ensure success.

Reality: Postman does not retry failed requests by default; retries must be scripted or handled externally.

Why it matters: Expecting automatic retries can cause overlooked failures and false confidence in test results.

Quick: Can you control complex branching logic inside Postman collections without external tools? Commit to yes or no.

Common Belief: Postman collections can natively handle complex branching and loops within the app interface.

Reality: Postman has limited native branching; complex workflows require external runners like Newman with scripts or separate collections.

Why it matters: Misunderstanding this limits test design and leads to overly complex or fragile workflows inside Postman.

Expert Zone

1

Variables set in test scripts are asynchronous and may not be immediately available in the next request unless carefully managed.

2

Pre-request scripts can access and modify environment variables dynamically, but improper use can cause race conditions in parallel runs.

3

Using collection-level variables versus environment variables affects scope and can cause subtle bugs when running the same collection in different contexts.

When NOT to use

Workflow sequencing in Postman is not ideal for extremely complex orchestration requiring parallel execution, advanced branching, or stateful session management. In such cases, dedicated API testing frameworks or orchestration tools like Karate, JMeter, or custom scripts in CI/CD pipelines are better suited.

Production Patterns

In production, teams use Postman collections with workflow sequencing integrated into CI/CD pipelines via Newman. They parameterize environments for different stages, use monitors for scheduled runs, and generate detailed reports. Conditional tests and error handling scripts ensure robustness. Workflows often simulate user journeys like login, data retrieval, and updates to validate end-to-end API behavior.

Connections

State Machines

Workflow sequencing models API interactions as state transitions triggered by requests and responses.

Understanding state machines helps grasp how workflows move through different states based on API responses, improving test design.

Continuous Integration/Continuous Deployment (CI/CD)

Workflow sequencing in Postman integrates with CI/CD pipelines to automate API testing during software delivery.

Knowing CI/CD concepts clarifies how automated workflows catch issues early and maintain software quality.

Assembly Line Manufacturing

Workflow sequencing is like an assembly line where each station (request) performs a step that depends on the previous one.

This connection shows how breaking complex tasks into ordered steps ensures quality and efficiency, both in manufacturing and testing.

Common Pitfalls

#1 Not saving response data to variables before the next request.

Wrong approach:

pm.environment.set('token', responseBody.token); // Missing or incorrect script

// Next request uses {{token}} but it is undefined

Correct approach:

const jsonData = pm.response.json();
pm.environment.set('token', jsonData.token);

Root cause:

Misunderstanding how to extract and store data from responses causes later requests to fail due to missing inputs.

#2 Hardcoding values instead of using variables for dynamic data.

Wrong approach:

POST https://api.example.com/user/12345/profile
// User ID is fixed and does not change

Correct approach:

POST https://api.example.com/user/{{userId}}/profile
// userId is set dynamically from previous response

Root cause:

Not using variables reduces flexibility and breaks workflows when data changes between runs.

#3 Running requests manually one by one instead of using Collection Runner.

Wrong approach:

Manually clicking each request in Postman to simulate sequence.

Correct approach:

Use Collection Runner to execute all requests in order automatically.

Root cause:

Lack of knowledge about automation features leads to inefficient and error-prone testing.

Key Takeaways

Workflow sequencing arranges API requests in a specific order to simulate real interactions and dependencies.

Variables and scripts connect requests by passing data, enabling dynamic and realistic test flows.

Pre-request and test scripts control data before and after requests, allowing flexible and conditional workflows.

Postman workflows run sequentially and can be automated in CI/CD pipelines for continuous quality assurance.

Understanding workflow sequencing prevents common mistakes and enables robust, maintainable API testing.

Practice

1. What is the main purpose of workflow sequencing in Postman?

easy

A. To encrypt API requests for security

B. To create visual charts of API responses

C. To automatically generate API documentation

D. To run multiple requests in a specific order and share data between them

Solution

1. Step 1: Understand workflow sequencing

   Workflow sequencing means running requests one after another in a set order.

2. Step 2: Identify the purpose in Postman

   It allows passing data from one request to the next, making multi-step testing reliable.

3. Final Answer:

   To run multiple requests in a specific order and share data between them -> Option D

4. Quick Check:

   Workflow sequencing = ordered requests with data sharing [OK]

Hint: Think: run requests step-by-step sharing info [OK]

Common Mistakes:

• Confusing workflow sequencing with documentation generation
• Thinking it creates charts or encrypts requests
• Believing requests run randomly without order

2. Which Postman script command is used to call another request inside a test script for workflow sequencing?

easy

A. pm.callRequest()

B. pm.sendRequest()

C. pm.executeRequest()

D. pm.runRequest()

Solution

1. Step 1: Recall Postman scripting commands

   Postman provides a method to send HTTP requests programmatically inside scripts.

2. Step 2: Identify the correct method for calling requests

   The correct method is pm.sendRequest(), which sends a request and handles its response.

3. Final Answer:

   pm.sendRequest() -> Option B

4. Quick Check:

   Call requests inside scripts = pm.sendRequest() [OK]

Hint: Remember: sendRequest sends HTTP calls inside scripts [OK]

Common Mistakes:

• Using non-existent methods like pm.callRequest()
• Confusing with pm.executeRequest() or pm.runRequest() which don't exist
• Misspelling the method name

3. Consider this Postman test script snippet inside Request A:

pm.sendRequest('https://api.example.com/token', (err, res) => {
  pm.environment.set('token', res.json().access_token);
});

What will be the value of token in environment after this runs?

medium

A. The access_token value from the JSON response of the called request

B. Undefined, because pm.sendRequest does not set environment variables

C. An error, because pm.sendRequest cannot be used inside test scripts

D. The entire JSON response as a string

Solution

1. Step 1: Understand pm.sendRequest callback

   The callback receives the response object res, which can be parsed as JSON.

2. Step 2: Extract and set environment variable

   The script sets token to res.json().access_token, which is the access token string from the response.

3. Final Answer:

   The access_token value from the JSON response of the called request -> Option A

4. Quick Check:

   pm.sendRequest sets env var = access_token value [OK]

Hint: pm.sendRequest callback can set env vars from response JSON [OK]

Common Mistakes:

• Assuming pm.sendRequest cannot set variables
• Thinking the whole JSON is stored instead of just access_token
• Confusing asynchronous callback behavior

4. You wrote this Postman test script to run Request B after Request A:

pm.sendRequest('https://api.example.com/data', (err, res) => {
  pm.environment.set('dataId', res.json().id);
});
pm.sendRequest('https://api.example.com/details/{{dataId}}', (err, res) => {
  console.log(res.json());
});

Why might the second request fail or use an empty dataId?

medium

A. Because pm.sendRequest cannot be called twice in the same script

B. Because environment variables cannot be used inside pm.sendRequest URLs

C. Because pm.sendRequest is asynchronous, the second request runs before dataId is set

D. Because console.log is not allowed inside pm.sendRequest callbacks

Solution

1. Step 1: Analyze asynchronous behavior of pm.sendRequest

   pm.sendRequest runs asynchronously, so the second call may start before the first finishes.

2. Step 2: Understand timing of environment variable setting

   The variable dataId is set only after the first request completes, so the second request may see it as empty if it runs too soon.

3. Final Answer:

   Because pm.sendRequest is asynchronous, the second request runs before dataId is set -> Option C

4. Quick Check:

   Async calls need chaining to ensure order [OK]

Hint: Async calls run out of order unless chained properly [OK]

Common Mistakes:

• Thinking environment variables can't be used in URLs
• Believing pm.sendRequest can't be called multiple times
• Assuming console.log is disallowed in callbacks

5. You want to test a multi-step user signup flow in Postman using workflow sequencing. The steps are:
1. Create user (returns userId)
2. Verify email (needs userId)
3. Set user preferences (needs userId)

Which approach correctly sequences these requests and shares userId between them?

hard

A. Use pm.sendRequest inside the test script of each step to call the next, setting environment variables for userId

B. Run all requests manually in any order and copy userId between them

C. Use separate Postman collections for each step without sharing variables

D. Call all requests simultaneously using pm.sendRequest without waiting for responses

Solution

1. Step 1: Understand multi-step flow needs ordered execution

   Each step depends on the previous step's userId, so requests must run one after another.

2. Step 2: Use pm.sendRequest with environment variables to pass data

   Calling the next request inside the previous request's test script and setting userId as an environment variable ensures correct sequencing and data sharing.

3. Final Answer:

   Use pm.sendRequest inside the test script of each step to call the next, setting environment variables for userId -> Option A

4. Quick Check:

   Chain requests with pm.sendRequest and env vars for data flow [OK]

Hint: Chain requests with pm.sendRequest and env vars [OK]

Common Mistakes:

• Running requests manually without automation
• Not sharing variables between requests
• Calling requests simultaneously causing race conditions