← Back to Recording

Summary

Overview

This course session provides a comprehensive, hands-on tutorial on using Postman Flows to automate API testing workflows without writing code. The instructor demonstrates how to design, build, and debug visual, drag-and-drop automation workflows in Postman to sequence API requests (e.g., create customer → retrieve orders → ship product) and integrate them with environment variables and CI/CD pipelines. The session includes live troubleshooting of common issues such as missing environment variables, incorrect file paths, and repository misconfigurations, emphasizing zero-code automation, proper environment management, and validation through CI/CD checks.

Topic (Timeline)

1. Introduction to Postman Flows and Automation Use Cases [00:00:02.960 - 00:04:06.880]

  • Instructor introduces the concept of automating API workflows in Postman as an alternative to manual scripting.
  • Compares manual testing (e.g., sending requests one-by-one) with automated visual workflows.
  • Identifies a real-world use case: automating a customer order flow — capturing customer data, retrieving products, and determining shipping details.
  • Emphasizes that Postman Flows enable “visual programming” for non-developers to orchestrate multi-step API sequences.

2. Building a Visual Workflow in Postman [00:04:07.300 - 00:12:58.260]

  • Step-by-step guide to enabling Postman Flows in a workspace: navigating to Configure Workspace → enabling Flow → creating a new flow.
  • Demonstrates the flow editor interface: blocks include Send Request, Delay, If/Else, Collect, Repeat, and Eval.
  • Constructs a workflow to:
    1. Send a GET request to retrieve customer data.
    2. On success, send a GET request to fetch order details using the customer ID.
    3. On success, send a GET request to retrieve product information.
    4. On success, send a GET request to determine shipping details.
    5. Add a 1–2 second delay before printing final output.
  • Shows how to connect blocks via drag-and-drop, handle success/failure branches (e.g., log errors on failure), and chain requests using dynamic data (e.g., customer ID from response).
  • Highlights that no scripting is required — all logic is visual and configuration-based.

3. Running, Debugging, and Environment Configuration [00:12:58.520 - 00:21:55.300]

  • Demonstrates running the workflow and encountering errors due to missing environment variables (e.g., MAC_API, user_id).
  • Identifies root cause: environment variables not properly exported or defined in the active environment (not global).
  • Guides learners to:
    • Create or update environment variables in Postman.
    • Export the environment as a JSON file.
    • Overwrite the previous environment file to ensure consistency.
  • Emphasizes testing workflows locally before CI/CD integration: if it fails locally, it will fail in production.
  • Reinforces that environment variables must match exactly what the collection expects (case-sensitive, correct names).

4. CI/CD Integration and Repository Management [00:21:55.300 - 00:28:43.660]

  • Explains the role of .git in managing Postman collections and environments in version control.
  • Troubleshoots common Git issues:
    • Missing .git folder due to hidden file settings.
    • Incorrect working directory (e.g., using . incorrectly in paths).
    • Renaming or deleting .git folder accidentally.
  • Guides learners to:
    • Clone the repository fresh.
    • Switch to the correct branch.
    • Copy and paste the Postman collection and environment files into the correct directory.
    • Use git add, git commit, and git push to update the remote repository.
  • Stresses that Postman Flows must be saved and version-controlled alongside collections and environments for CI/CD to validate them.

5. Workflow Design for Open Bank Account Use Case [00:28:45.840 - 00:37:41.640]

  • Assigns a practical activity: build a Postman Flow to simulate “Open Bank Account”.
  • Defines the required sequence:
    1. Create customer (POST) → returns customer ID and email.
    2. On success, create passbook (POST) → uses the same email as the linking key.
    3. On success, retrieve customer details (GET).
    4. On success, retrieve passbook details (GET).
    5. Display both responses as final output.
  • Emphasizes data consistency: email must be the primary key between customer and passbook records.
  • Notes that the workflow must be linear and sequential, not parallel, to ensure data dependencies are met.
  • Instructor reviews learner submissions via DM to validate correctness and enforce CI/CD validation principles: automated checks will catch misconfigurations in environment or schema.

Appendix

Key Principles

  • Zero-Code Automation: Postman Flows allow API workflow automation through drag-and-drop visual blocks — no JavaScript or scripting required.
  • Environment-Driven Testing: All API requests must reference environment variables (e.g., {{base_url}}, {{user_id}}) — hardcoding URLs breaks portability.
  • Local-First Validation: Always test workflows locally before pushing to version control or CI/CD pipelines.
  • Data Linking via Keys: Use consistent identifiers (e.g., email) across related resources (customer → passbook) to enable chained requests.

Tools Used

  • Postman (Flows, Collections, Environments)
  • Git (for version control of Postman assets)
  • CI/CD pipelines (automated testing on push — e.g., GitHub Actions)

Common Pitfalls

  • Missing or misnamed environment variables → requests fail silently.
  • Accidentally deleting or renaming .git folder → breaks repository tracking.
  • Using global variables instead of workspace-specific environments → inconsistent behavior across team members.
  • Not testing workflow locally → errors only appear in CI/CD, delaying feedback.

Practice Suggestions

  • Recreate the “Open Bank Account” flow using the provided data schema (customer + passbook linked by email).
  • Export your environment and collection, then re-import into a new workspace to verify portability.
  • Intentionally break a variable name and observe how CI/CD flags the error.
  • Build a flow that handles failure cases (e.g., if customer creation fails, log error and stop).