Skip to main content
curl --request PATCH \
  --url https://sisx.thesqd.com/webhook/mmq

MMQ

 
curl --request PATCH \
  --url https://sisx.thesqd.com/webhook/mmq

​
Trigger: Webhook

The trigger for this workflow is a webhook endpoint listening on path “mmq” accepting GET and PATCH methods. When triggered, it initiates the processing sequence for task updates within the MMQ system.
  • Path: “mmq”
  • HTTP Methods: GET, PATCH
  • Response Mode: Use “responseNode” to send back responses based on further processing
  • Multiple Methods: true (supports both GET and PATCH)
  • Response: Managed through the “responseNode” during workflow execution

​
Node: Sticky Note (”# Logo”)

A visual annotation node indicating a section labeled ”# Logo,” primarily used for workflow organization.
  • Color: Blue (2)
  • Dimensions: Width 1000, Height 320
  • Content: ”# Logo”

​
Node: Webhook (“WebHook”)

This node captures incoming PATCH requests at “/mmq” and triggers the workflow.
  • Webhook ID: “39f76862-e004-479d-92d0-76297a0defa3”
  • Path: “mmq”
  • HTTP Methods: GET, PATCH
  • Response Mode: “responseNode”
  • Supports multiple methods: true
  • ResponseMode: “responseNode”

​
Node: Postgres (“Check if account has room”)

Queries account capacity and status with "SELECT * FROM get_account_task_stats({{ $json.account }})" joined with the accounts table to verify current task load and capacity.
  • Query: "SELECT * FROM get_account_task_stats({{ $json.account }}) JOIN accounts a ON a.account = {{ $json.account }}".
  • Credentials: “SquadData - N. Cal Replica”
  • Always outputs data, even if query returns nothing (onError: continue)
  • Used to determine if account can accept more tasks

​
Node: Switch (“Switch2”)

Routes processing based on the presence of task id or account info in incoming data.
  • Conditions:
    • If query.id exists and query.account does not: route accordingly (e.g., to task handling)
    • Else, perform alternative branch
  • Fallback output: “extra”

​
Node: Webhook (“Webhook - PATCH”)

The primary webhook triggering the workflow with PATCH method on “mmq”.
  • Path: “mmq”
  • Methods: GET, PATCH
  • Response Mode: “responseNode”
  • Multiple: true

​
Node: Postgres (“Get Account1”)

Retrieves the account data based on the parameter from the incoming webhook query or payload.
  • Query: "SELECT {\"account\": \"{{ $json.query.account }}\"}"
  • Output used for subsequent logic

​
Node: Set (“Get Account1”)

Sets the account value from the webhook query data into the workflow context as account.
  • Assignments:
    • account: "{{ $json.query.account }}"

​
Nodes: Processing Tasks and Statuses (Various Postgres & Set nodes)

Sequences that manage task states, including:
  • Loading current task data (Postgres7, Postgres11, etc.)
  • Updating task status in ClickUp (ClickUp, ClickUp1, ClickUp4)
  • Managing task queue and prioritization (Postgres13, Postgres14)
  • Handling task details, dates, and department info (Postgres16, Postgres17)
  • Logic branches for different task actions like pause/play, update, reorder, close, etc.

​
Example: Pause/Play actions

  • Nodes like Switch4, Switch5, process “pause” or “play” actions coming from webhook payloads.
  • Based on action, update task status in ClickUp and Postgres.
  • Set additional fields like due date and active status.

​
Node: Webhook (“Respond to Webhook”)

Sends a JSON response indicating whether tasks were found or not.
  • Response Body: {"tasks_found": false}

​
Node: Merge (“Merge2”)

Joins data streams related to tasks, consolidating incoming task info.

​
Node: Postgres (“Postgres12”)

Loads tasks based on account and other criteria, enabling further processing of task data.
  • Query: Pulls current task info including related comments, updates, and history.

​
Node: Webhook (“Webhook3”)

Simulates a webhook call for play/pause or task state updates via external triggers.
  • Path: “play-pause”
  • Method: PATCH
  • Payload includes action, task_id, position.

​
Node: ClickUp (“ClickUp” / “ClickUp1” / “ClickUp4”)

Updates task status in the external ClickUp system based on workflow logic:
  • Fields updated: status, dueDate
  • Credentials: “TheSquad” API key
  • Example: Set status to “on hold” or revert to previous status

​
Additional nodes

Multiple Postgres nodes assist in refreshing views, recording history, and managing task queue order, such as:
  • Postgres16 for refreshing materialized views
  • Postgres17 for executing complex SQL queries involving task status and date logic
  • Postgres18 for converting images or files when needed
  • Postgres13, Postgres14 for updating logs and queue ordering dynamically

​
Summary

This workflow handles task updates via a webhook trigger, coordinating information between Postgres, external task management systems (like ClickUp), and internal process queues. It supports pausing, playing, updating statuses, and managing task queue positions, ensuring data consistency across systems. It responds with status messages to webhook callers, enabling external systems to trigger and monitor task states.
Note: The detailed node configurations, SQL queries, and execution data illustrate the workflow’s extensive data handling and conditional routing logic, ensuring precise task management aligned with external triggers and internal state changes.