Skip to content

V4 - _test_runner

A simple test harness workflow that accepts HTTP requests with phone numbers, queries, and channel information, then forwards them to a work-in-progress Sifa V4 sales tracking agent workflow for processing and testing.

Purpose

No business context provided yet — add a context.md to enrich this documentation.

This workflow appears to be a testing utility for the Sifa V4 system, allowing developers to easily trigger and test the main sales tracking agent workflow through HTTP requests. It serves as a bridge between external testing tools or applications and the core Sifa V4 functionality.

How It Works

  1. Receive Test Request: The workflow listens for incoming HTTP POST requests on the /sifa-v4-test endpoint
  2. Extract Parameters: It parses the request body to extract three key pieces of information: phone number, query text, and communication channel
  3. Forward to Main Workflow: The extracted data is passed to the main Sifa V4 sales tracking agent workflow for processing
  4. Return Results: The workflow waits for the sub-workflow to complete and returns the results to the original caller

Workflow Diagram

graph TD
    A[Webhook<br/>POST /sifa-v4-test] --> B[Extract Body<br/>Parse phoneNumber, query, channel]
    B --> C[Call V4-WIP<br/>Execute Sales Tracking Agent]
    C --> D[Return Response]

Trigger

  • Type: Webhook (HTTP POST)
  • Endpoint: /sifa-v4-test
  • Method: POST
  • Response Mode: Returns the output from the last executed node

Nodes Used

Node Type Node Name Purpose
Webhook Webhook Receives HTTP POST requests and triggers the workflow
Set Extract Body Extracts and structures data from the incoming request body
Execute Workflow Call V4-WIP Calls the main Sifa V4 sales tracking agent workflow

External Services & Credentials Required

  • Sub-workflow Access: Requires access to workflow ID nyk5AWlf0hTWye5D (V4 - WIP - Francis - SalesTrackingAgent)
  • No external API credentials needed for this test runner itself

Environment Variables

No environment variables are directly used in this workflow. Any environment variables required would be handled by the called sub-workflow.

Data Flow

Input (HTTP Request Body)

1
2
3
4
5
{
  "phoneNumber": "string - Customer phone number",
  "query": "string - Customer query or message",
  "channel": "string - Communication channel (e.g., WhatsApp, SMS)"
}

Output

The workflow returns whatever the called sub-workflow (V4-WIP) produces, as it's configured to wait for sub-workflow completion and use "lastNode" response mode.

Error Handling

This workflow has minimal error handling: - If the webhook receives malformed data, the Extract Body node may fail - If the sub-workflow is unavailable or fails, the Execute Workflow node will fail - No explicit error handling or fallback mechanisms are implemented

Known Limitations

  • No input validation on the incoming request data
  • No error handling or graceful failure modes
  • Depends entirely on the availability and functionality of the sub-workflow
  • No authentication or rate limiting on the webhook endpoint
  • V4 - WIP - Francis - SalesTrackingAgent (ID: nyk5AWlf0hTWye5D) - The main workflow that this test runner calls

Setup Instructions

  1. Import the Workflow

    • Import this workflow JSON into your n8n instance
    • Ensure it's placed in the "Sifa V4" project
  2. Configure Sub-workflow Access

    • Verify that the target workflow "V4 - WIP - Francis - SalesTrackingAgent" exists and is accessible
    • Update the workflow ID in the "Call V4-WIP" node if necessary
  3. Activate the Workflow

    • Activate the workflow to enable the webhook endpoint
    • Note the webhook URL provided by n8n
  4. Test the Setup

    • Send a POST request to the webhook URL with the required JSON structure:
      1
      2
      3
      4
      5
      6
      7
      curl -X POST [your-webhook-url] \
        -H "Content-Type: application/json" \
        -d '{
          "phoneNumber": "+1234567890",
          "query": "Test message",
          "channel": "WhatsApp"
        }'
      
  5. Monitor Execution

    • Check the execution history to ensure the workflow runs successfully
    • Verify that the sub-workflow is being called and completing as expected