Webhook Workflow with Routing to Subworkflows – Flomenco

Introduction

In this guide, we will explain how to structure a webhook-based workflow efficiently by using a facade pattern to handle Fabric Record change events, that are distributed via SNS. This approach ensures that webhook event handling is centralized and scalable by routing requests to sub-workflows based on event type and record category.

Why Use a Facade Workflow?

When dealing with webhook event-driven workflows, creating multiple workflows with separate Webhook Trigger nodes can be inefficient. Instead, we recommend:

Using a single facade workflow that handles all incoming webhook events.

Validating webhook requests to ensure integrity and security.

Identifying the event type and the record category.

Preparing data as needed before delegating processing to a specific sub-workflow based on the event type and category.

This design allows for better maintainability, scalability, and reduces redundancy.

Workflow Overview

Webhook Trigger

The workflow starts with a Webhook node that listens for incoming event notifications.

This example illustrates how to use the Webhook Trigger with a Fabric SNS Topic, but it can be adapted for other event sources such as:

Gracenote API notifications

EIDR record updates

AWS S3 event notifications

Custom internal services sending HTTP webhook requests

Tip: Make sure you subscribe your Fabric SNS Topic to Production URL of this Webhook. This can be done via Fabric Service Desk Portal

Webhook that reacts to Fabric SNS events

Other n8n triggers that can be used for event-driven workflows include:

RabbitMQ Trigger – Listens for messages in a message queue.

Kafka Trigger – Subscribes to a Kafka topic to process streaming events.

AMQP Trigger – Connects to AMQP-based messaging systems.

Polling Trigger – Periodically checks an external API for updates.

Schedule / Cron Trigger – Executes workflows at scheduled intervals.

Email Trigger – Listens for incoming emails to trigger workflows.

Workflow Executed Trigger – Runs when another workflow completes execution.

Extracting Event Data

Extract Event Body from SNS Payload – Extracts the raw message from the SNS event payload.

Javascript Code: return [ JSON.parse($input.first().json.body) ]

Check Event Type – Determines whether the event is a SubscriptionConfirmation, Notification, or other types.

Tip: After Fabric SNS Topic is subscribed to your webhook, you will get SubscriptionConfirmation Event with SubscriptionURL that you need to open in browser. This conditional node allows you to filter out SubscriptionConfirmation event.

Validating Source

Message.source != Flomenco – Ensures that updates that are originating from Flomenco Nodes are not processed.

Tip: We usually do not want to react to Fabric Record changes, that were done by Flomenco WorkFlows. We do this by checking {{ $json.MessageAttributes.Source.Value }}

Parsing and Routing Events

Parse Message – Extracts and structures the message payload.

Javascript Code: return [ JSON.parse($input.first().json.Message) ]

Switch by category – Determines the appropriate processing route based on the record category (e.g., Feature, Season, Episode, Other).

Tip: Here you can also route workflow execution using Switch node based on any other Message field, such as {{ $json.action }}, {{ $json.category }}, {{ $json.release_year }}, etc

Calls the respective sub-workflow based on the category:

Feature: Calls Process Event for Category="Feature"

Season: Calls Process Event for Category="Season"

Episode: Calls Process Event for Category="Episode"

Other: If an invalid category is detected, no further action is taken.

Tip: Please refer to Organise Workflows in Reusable Way page to see how workflows can be split into reusable components.

Summary

This approach ensures centralized webhook management and efficient routing.

By processing event categories separately in sub-workflows, Flomenco can scale and manage integrations effectively.

Future modifications can be handled easily by updating sub-workflows instead of modifying the main webhook listener.