MWMS n8n Operating And Deployment Standard

System: MWMS
Document Type: Core Operating Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
Primary Location: MCR
Future Operational Destination: Automation Brain, HeadOffice Brain, AIBS Brain, MWMS Brain, AI Manager, AI Employee Router, Task Executor Systems, Brain Room, Client AIOS Systems
Parent Page: Automation Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-01
Source / Origin: AI Automations by Jack — n8n / Make Conversion / Self-Hosting / Workflow Calls Block
MWMS Classification: n8n Operating Standard / Automation Deployment Governance / Hybrid Make-n8n Orchestration Standard / Self-Hosted Automation Infrastructure Standard
Primary Brain: Automation Brain
Supporting Brains: HeadOffice Brain, AIBS Brain, Data Brain, Operations Brain, Risk Brain, Compliance Brain, SIT Brain, Product Brain, Research Brain
Related Pages: MWMS Automation Build Planning Framework, MWMS Automation Client Demo And Handover Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Dashboard Capability Framework, MWMS Advanced AI Capability Activation Registry, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS AI Operating System Architecture Framework, MWMS Context Engineering Framework
Source Evidence: The absorbed n8n block explains Make modules versus n8n nodes, webhooks, routers/switches, iterators/split-out nodes, aggregators, HTTP request differences, curl import advantage, code node advantage, AI agent differences, Make↔n8n bridging through webhook and HTTP request patterns, n8n self-hosting with Hostinger VPS, Cloudflare DNS, Coolify, n8n with PostgreSQL, native workflow calls, and multi-method webhooks.

Purpose

The purpose of the MWMS n8n Operating And Deployment Standard is to define how MWMS should understand, use, govern, deploy, and scale n8n inside the wider MWMS ecosystem.

This standard exists because n8n is not just another automation tool.

For MWMS, n8n can become a serious orchestration layer for:

AI agent workflows
Supabase RAG systems
client AIOS systems
webhook-controlled automations
database-backed workflows
self-hosted automation infrastructure
advanced data transformation
Make.com hybrid workflows
AI Employee tool calls
dashboard-backed workflows
client-facing automation products

This standard defines when n8n should be used, how it compares with Make, how Make and n8n can work together, how workflow calls should be handled, how webhooks should be governed, and what deployment rules must exist before n8n becomes part of important MWMS or client systems.

MWMS must not treat n8n as a toy or random automation playground.

n8n should be treated as a governed automation operating layer.

Core Doctrine

The MWMS doctrine is:

Use n8n when MWMS needs deeper automation control, workflow flexibility, AI agent orchestration, database-backed workflows, advanced branching, code-level data transformation, self-hosting, or AIOS infrastructure.

Make.com remains useful.

n8n becomes more important when MWMS needs:

more technical control
self-hosting
custom code nodes
advanced loops
AI agent workflows
workflow-to-workflow calls
Supabase/PostgreSQL connection
RAG workflows
webhook-heavy systems
custom API logic
cost control at scale
client AIOS infrastructure

The correct MWMS position is not:

Make is bad and n8n is good.

The correct position is:

Make is excellent for fast, visual, simple-to-medium automations.
n8n is stronger for deeper, more technical, AIOS-style workflow infrastructure.
MWMS should use the right tool for the right job.

Strategic Importance

This block is strategically important because it moves MWMS from “automation user” thinking into automation infrastructure thinking.

The lessons show that n8n can support:

Make-to-n8n workflow migration
n8n-native workflow calls
Make↔n8n hybrid workflows
webhook request/response systems
multiple HTTP methods from one webhook
code node transformations
AI agent workflow tracing
PostgreSQL-backed n8n installs
self-hosted deployment through VPS and Coolify
PDF/file utility workflows
complex client reporting systems
Supabase RAG workflow infrastructure

That matters because MWMS is building toward AI Operating Systems.

AI Operating Systems need more than prompts.

They need:

triggers
workflow routing
tools
databases
memory
logs
webhooks
source retrieval
dashboard actions
approval gates
error handling
human review
deployment control

n8n can become one of the major execution layers for those systems.

Definition

n8n is a workflow automation platform that connects triggers, nodes, APIs, AI agents, databases, code, webhooks, and external services into executable workflows.

Inside MWMS, n8n should be defined as:

A governed automation orchestration platform used for advanced workflow execution, AI agent tooling, database-backed automation, webhook integration, system-to-system routing, and future AIOS infrastructure.

n8n should not be defined merely as:

a Make.com replacement
a no-code toy
a place to experiment endlessly
a client system by itself
a shortcut around governance

n8n is a tool.

MWMS governance decides how it is used.

n8n Versus Make

The course compares Make modules with n8n nodes and explains that both platforms do many of the same things, but with different strengths. Make is more visual and colorful, while n8n is more technical and often more flexible.

Make Strengths

Make is strong for:

fast visual automation building
simple to medium workflows
easy third-party integrations
clean visual scenarios
less technical users
quick testing
many built-in app integrations
client-friendly demos
straightforward data routing
simple webhook automations

n8n Strengths

n8n is strong for:

advanced workflow logic
self-hosting
code nodes
AI agent workflows
deeper webhook handling
workflow-to-workflow calls
PostgreSQL-backed deployments
custom HTTP/API work
curl import
loops and complex branching
AIOS infrastructure
RAG orchestration
Supabase integration
lower long-term control/cost potential

MWMS Rule

Use Make when speed, simplicity, and visual clarity matter most.

Use n8n when control, extensibility, self-hosting, AI agent workflows, database-backed logic, or AIOS infrastructure matters most.

Make Module To n8n Node Translation

MWMS should maintain a practical translation map between Make and n8n.

The course identifies several key equivalences.

Webhook

Make: Webhook module
n8n: Webhook trigger node

n8n has separate test and production webhook URLs.

This is important.

In n8n:

test URL is used while testing the workflow
production URL is used when the workflow is active
the workflow must be activated for production use

Rule

Always confirm whether a webhook URL is test or production before connecting external systems.

Router / Switch

Make: Router
n8n: Switch node or IF node routes

Make routers visually split flows.

n8n switch/if nodes create different paths based on conditions.

Rule

Use switch/if nodes when routing depends on method, type, status, classification, or data value.

Iterator / Split Out

Make: Iterator
n8n: Split Out node

Both turn one array into multiple items.

Useful when processing:

reviews
files
rows
leads
messages
URLs
search results
retrieved chunks

Rule

Use split-out logic when one input contains multiple processable records.

Aggregator

Make: Array/Text/Table Aggregator
n8n: Aggregate node, merge patterns, code node when needed

Both combine multiple items into one output.

Useful when preparing:

reports
summaries
batch emails
PDFs
combined review text
competitor intelligence reports
multi-source AI prompts

Rule

Use aggregation before asking AI to analyze multiple records together.

Set Variable / Edit Fields

Make: Set variable / Get variable
n8n: Edit Fields / Set node

The course explains that Make often needs get/set variable patterns across routes, while n8n generally allows prior node data to be referenced more flexibly, although merges and multiple items can require explicit referencing.

Rule

In n8n, always check whether the current node has one item or multiple items before referencing fields.

HTTP Request

Make: HTTP module
n8n: HTTP Request node

n8n’s HTTP Request node has a major advantage: import curl.

This is very useful when working with API documentation.

Rule

When API docs provide curl examples, n8n should use curl import as the first setup path.

Code Transformation

Make: limited native transformation unless using external tools or formulas
n8n: Code node

The course repeatedly uses n8n code nodes for:

cleaning HTML into text
combining arrays
reshaping data
extracting fields
preparing output for AI
resolving data transformation problems

Rule

The n8n Code node is a powerful data-shaping layer, but code should be documented, tested, and not casually copied into production without review.

AI Agents

Make: Make AI agents are newer and less transparent
n8n: AI Agent nodes, chains, extractors, sentiment, Q&A, summarization, tool calling

The course notes n8n gives more granular visibility into AI agent behavior and tool usage.

Rule

Use n8n AI agent workflows when tool usage, tracing, RAG, memory, or multi-step reasoning needs more visibility.

The Make/n8n Sandwich Pattern

The Make/n8n sandwich is the pattern of using Make and n8n together instead of rebuilding everything in one platform.

The course demonstrates both directions:

n8n calling a Make scenario
Make calling an n8n workflow

This is done with a simple structure:

Webhook receives request → HTTP request sends data → response returns result where needed.

The lesson also distinguishes between two modes:

activation-only call
data-rich request/response call

Mode 1: Activation-Only Call

In this mode, one platform simply triggers the other.

Example:

n8n sends the word “activate” to a Make webhook.

Make receives the webhook and starts a scenario.

The payload is not important.

Use Cases

start a scheduled workflow
trigger an existing Make scenario
fire off a report workflow
activate a legacy automation
avoid rebuilding a working scenario

Rule

Use activation-only calls when the receiving workflow already knows what to do.

Mode 2: Data-Rich Request/Response Call

In this mode, one platform sends variables to the other and expects a result back.

Example:

n8n sends height, weight class, MMA record, and fighting style to Make. Make processes the data and returns an answer.

Use Cases

AI agent uses Make scenario as a tool
Make sends data to n8n for AI processing
n8n sends structured payload to existing Make automation
one platform handles intake and the other handles processing
one platform handles app integrations and the other handles AI logic

Rule

Use data-rich calls when the receiving workflow depends on the incoming variables.

MWMS Hybrid Orchestration Rule

MWMS should not automatically rebuild working Make automations in n8n.

Instead, ask:

Is the Make scenario already working?
Does n8n need to call it?
Does Make need to call n8n?
Is the workflow simple enough to leave in Make?
Does n8n add real control, memory, AI agent tooling, or cost benefits?
Is rebuilding worth the risk?
Could a webhook bridge solve the problem faster?

MWMS Rule

Do not rebuild working automations just to move platforms.

Bridge first when bridging is safer.

Rebuild only when the workflow needs n8n’s deeper control.

Native n8n Workflow Calls

n8n has a native way for one workflow to call another workflow.

The lesson shows the pattern:

Workflow 1 uses Execute Workflow
Workflow 2 starts with When Executed By Another Workflow
the called workflow can accept input data and return output data

This is cleaner than using webhooks when both workflows are inside n8n.

Use Native Workflow Calls When

both workflows are in n8n
internal modularity matters
a workflow should be reused
a sub-workflow performs a standard function
no public webhook is needed
you want lower security exposure

Use Webhook + HTTP When

external systems need to call the workflow
Make needs to call n8n
a front-end app needs to send requests
a Chrome extension needs to trigger a workflow
a client system needs to connect
a public endpoint is required

MWMS Rule

Use native n8n workflow calls for internal n8n-to-n8n workflow modularity.

Use webhooks only when external access is required.

n8n Workflow Modularization Standard

MWMS should not build every automation as one giant workflow.

Large n8n systems should be broken into reusable workflow units.

Examples:

Clean Input Workflow
Extract Transcript Workflow
Generate PDF Workflow
Send Email Workflow
Retrieve RAG Context Workflow
Classify Lead Workflow
Create Dashboard Item Workflow
Generate Client Report Workflow
Log Event Workflow
Human Approval Workflow
Error Handler Workflow

Benefits

Modular workflows help MWMS:

reduce duplication
simplify testing
reuse proven components
isolate risk
debug faster
improve maintainability
build AIOS systems cleanly

Rule

If a workflow step will be reused more than twice, consider making it a callable sub-workflow.

Webhook Governance

Webhooks are one of the most important n8n features.

They are also one of the biggest risks.

A webhook is an entry point into a workflow.

It can receive:

form submissions
app messages
front-end requests
Make requests
client system requests
browser extension data
AI app builder requests
chatbot messages
voice agent tool calls
payment events
CRM events

Webhook Risks

Webhooks can create:

unauthorized access
spam requests
prompt injection
malformed payloads
accidental workflow triggers
external system abuse
sensitive data leakage
cost exposure
tool misuse
public endpoint exposure

Required Webhook Controls

Every serious webhook should define:

purpose
method
test URL
production URL
allowed payload
payload schema
authentication or secret
source system
rate limit where possible
logging
error handling
human approval requirement
external action risk
client isolation
retry behavior
response behavior

MWMS Rule

A webhook is a system doorway.

Do not expose a doorway without rules.

One Webhook / Multiple HTTP Methods Rule

The course identifies a useful n8n feature: one webhook can allow multiple HTTP methods and route them separately.

Instead of creating separate webhooks for GET and POST, n8n can allow multiple methods from the same webhook settings.

Use Cases

This is useful when one endpoint needs to support:

GET test/ping
POST form submission
PATCH update
DELETE removal
different behavior based on method
app builder front-end routing
API-style workflow interface

Required Controls

When using multiple methods, define:

what each method does
which methods are allowed
whether any method changes data
which method is safe for testing
which method triggers workflow actions
what response each route returns

MWMS Rule

Multiple HTTP methods are powerful, but they must be routed deliberately.

Never let GET and POST perform the same high-risk action by accident.

HTTP Request Standard

n8n’s HTTP Request node is a major gateway into APIs.

It may be used for:

Fireflies
Appify
ElevenLabs
PDF.co
Placid
Unipile
VAPI
Supabase REST endpoints
Make webhooks
GoHighLevel APIs
Anymailfinder
Apollo data workflows
Google APIs
custom client systems

HTTP Request Setup Rules

When setting up HTTP requests:

start from official API documentation where available
use curl import when possible
identify method clearly
confirm endpoint
set headers correctly
store API keys securely
understand payload type
test with low-risk data
inspect response
handle errors
avoid hardcoding sensitive values
log response where useful
do not expose secrets in prompts or screenshots

MWMS Rule

HTTP request nodes must be treated as tool access.

They need the same permission thinking as AI Employee tools.

Data Transformation Standard

n8n often needs data cleanup.

The course repeatedly shows data needing to be reshaped before use:

Airtable records cleaned
Fireflies transcript sentences combined
Appify reviews combined
HTML stripped into plain text
arrays aggregated
text transformed into JSON
PDF/image binaries handled
Google Drive links converted
RSS feed data normalized

Transformation Tools

n8n can transform data using:

Edit Fields / Set node
Code node
Aggregate node
Split Out node
Merge node
IF/Switch node
HTTP response mapping
AI extraction
JSON output formatting

MWMS Rule

Do not send messy raw payloads into AI if the workflow can clean and structure the data first.

Clean input improves AI output.

Code Node Governance

The n8n Code node is powerful.

It can solve problems that are difficult in pure no-code.

The course uses code for practical data manipulation, including cleaning HTML and combining review text.

Code Node Benefits

Code nodes can:

clean messy data
reshape JSON
combine arrays
remove HTML
create derived fields
prepare AI prompts
fix edge cases
reduce workflow complexity

Code Node Risks

Code nodes can create:

hidden logic
maintenance problems
brittle transformations
security issues
debugging difficulty
dependency on ChatGPT-generated snippets
unclear ownership

Required Code Node Notes

Each important code node should include:

purpose
input expected
output produced
assumptions
known limitations
error behavior

MWMS Rule

Code nodes are allowed, but important code nodes must be documented.

Merge And Item Reference Rule

n8n can become confusing when multiple items flow into later nodes.

The course shows repeated issues where n8n could not determine which item to use and required .first() or merge adjustments.

This is a recurring n8n risk.

Common Causes

multiple Airtable records
aggregated arrays
merge nodes
split-out items
pinned data
multiple branch outputs
different item counts entering a node

Required Practice

When referencing fields:

confirm item count
use .first() where appropriate
aggregate before AI analysis
merge data deliberately
avoid accidental duplicated emails
test with one item and multiple items
avoid assuming single-item behavior

MWMS Rule

Before sending emails, creating PDFs, writing database records, or triggering client actions, confirm the workflow is operating on the correct item count.

Pinned Data Rule

Pinned data is useful for testing.

But the course shows pinned data can also cause confusion, especially around binary files and node execution.

Use Pinned Data For

avoiding repeated API calls
testing downstream nodes
debugging transformations
preserving sample responses
reducing cost during testing

Be Careful When

binary data is involved
workflow expects live file data
previous node outputs have changed
item count matters
API state has changed
testing production-like behavior

MWMS Rule

Pinned data is for testing convenience.

Before launch, rerun with live data.

Binary File Handling Standard

n8n workflows often handle binary files.

The block includes examples such as:

downloaded dubbed videos
Google Drive uploads
generated PDFs
image files
zipped files
email attachments

The PDF/JPG/ZIP utility lesson shows PDF.co converting PDF pages to images, n8n downloading binaries, using compression to zip images, and emailing the zip file.

Binary Handling Risks

missing binary field
wrong binary field name
pinned data not preserving binary correctly
file permission issues
Google Drive access issues
email attachment errors
file size problems
sensitive file leakage

Required Controls

Binary workflows should define:

file source
binary field name
file type
file name
storage destination
sharing permission
attachment behavior
delete/retention rule
client privacy rule

MWMS Rule

File workflows must be tested end-to-end with real binary data before client use.

Self-Hosted n8n Deployment Standard

The self-hosting lesson covers setting up n8n using:

Hostinger VPS
Cloudflare DNS
Coolify
n8n with PostgreSQL
SSL/HTTPS
domain/subdomain routing
community license activation

This is important because self-hosting may become a future MWMS infrastructure path.

Self-Hosting Benefits

Self-hosting can provide:

more control
potential cost advantages
persistent workflows
PostgreSQL-backed memory/data
ability to install other tools
AIOS infrastructure control
lower dependency on SaaS automation limits

Self-Hosting Risks

Self-hosting creates responsibilities:

server maintenance
SSL/DNS setup
credential security
updates
backups
monitoring
uptime
access control
firewall/security
recovery plan
support burden

MWMS Rule

Self-hosted n8n is infrastructure, not just a tool account.

Treat it like a production server when it supports real MWMS or client workflows.

Coolify Standard

Coolify is useful because it allows MWMS to deploy apps and services on a VPS through a managed interface.

The self-hosting lesson positions Coolify as a way to install n8n and other server applications, including n8n with PostgreSQL.

Coolify May Support

n8n
PostgreSQL
other databases
app deployments
internal tools
future AIOS components
self-hosted services

MWMS Rule

Coolify may become a useful deployment layer, but MWMS should not overload one VPS with too many services without monitoring capacity.

n8n With PostgreSQL Rule

The self-hosting walkthrough recommends n8n with PostgreSQL because it enables database-backed work.

Why PostgreSQL Matters

PostgreSQL may support:

workflow data
execution records
AI memory
app data
internal databases
RAG-adjacent systems
client workflow records
future AIOS infrastructure

Rule

When self-hosting n8n for serious MWMS use, prefer n8n with PostgreSQL unless there is a clear reason not to.

Cloudflare And DNS Rule

The self-hosting lesson uses Cloudflare for DNS and SSL-related setup because DNS changes propagate quickly and Cloudflare provides useful control.

MWMS DNS Requirements

For n8n deployment, define:

domain or subdomain
A record
IP address
SSL mode
proxy status
propagation state
HTTPS setting
Coolify domain setting
n8n service domain setting

Rule

Do not troubleshoot n8n as broken until DNS, HTTPS, SSL, and service domain settings have been checked.

Environment Separation

n8n has test and production concepts.

MWMS should use environment separation seriously.

Separate

test webhook URL
production webhook URL
development workflows
production workflows
sample data
live client data
personal credentials
client credentials
internal workflows
client workflows

MWMS Rule

Do not test risky workflow changes directly on live client data.

Credential Governance

n8n workflows may connect to many sensitive services.

Examples from this block include:

ElevenLabs
Fireflies
Google Drive
Gmail
YouTube
Appify
PDF.co
Placid
Airtable
GoHighLevel
VAPI
Unipile
Anymailfinder
Apollo/Appify exports
Supabase
OpenAI
Cohere

Credential Risks

API key exposure
wrong account used
personal account used for client workflow
revoked credentials
over-permissioned access
shared workflow leaking credentials
copied workflow containing secrets
client offboarding not removing access

MWMS Rule

Credentials must be treated as production assets.

Do not place secrets in prompts, public screenshots, exported blueprints, or client-facing documentation.

n8n Error Handling Standard

Important n8n workflows must include error handling.

The YouTube dubbing lesson uses a loop/wait pattern to keep checking until ElevenLabs dubbing is ready, handling “not ready” responses before continuing.

Error Handling Should Cover

API failure
timeout
rate limit
missing field
invalid payload
no matching record
binary file missing
duplicate record
unsupported language
webhook error
email send failure
PDF generation failure
scraping failure
AI output invalid
tool quota exceeded

Required Error Path

For serious workflows, define:

what failed
where it failed
whether retry is safe
whether human review is needed
whether client must be notified
whether workflow should stop
whether partial data should be saved
what log/event should be created

MWMS Rule

A workflow without failure handling is not client-ready.

Human-In-The-Loop Rule

n8n can automate powerful actions.

But some actions require human approval.

Human approval is required before:

cold outreach launch
client report delivery where claims matter
proposal sending if pricing is involved
public content publishing
campaign changes
voice agent deployment
sensitive customer response
deleting records
changing live databases
sending high-volume emails
using scraped/enriched personal data
client-facing AIOS launch

MWMS Rule

Automation speed must not override approval discipline.

n8n AI Agent Governance

n8n supports AI agent nodes and tool calling.

These are powerful but must be governed.

AI agents in n8n may:

classify leads
retrieve data
call tools
generate reports
summarize transcripts
analyze sentiment
create proposals
route tasks
answer chatbot queries
trigger workflows

Required Agent Controls

Each n8n AI agent should define:

role
input
allowed tools
forbidden actions
output format
validation requirement
memory access
source access
escalation conditions
logging requirement
human review requirement

MWMS Rule

An n8n AI agent is still an MWMS AI Employee or tool-using worker.

It must follow MWMS AI Agent Operations Core.

n8n And RAG

n8n is highly relevant to MWMS RAG systems.

The Supabase RAG framework already identified n8n as a likely orchestration layer for:

file ingestion
chunking
embeddings
vector store writes
retrieval
reranking
AI agent answering
webhook responses
dashboard/chatbot connections

MWMS Rule

When n8n powers RAG, it must follow the MWMS Supabase RAG And Vector Memory Framework.

n8n And Dashboards

n8n can sit behind dashboards.

A dashboard may call n8n to:

retrieve records
trigger automations
create reports
ask AI questions
send data to Supabase
update statuses
generate PDFs
create tasks
route approvals

MWMS Rule

Dashboard-triggered n8n workflows must be permissioned, logged, and protected.

A dashboard button is not “just a button.”

It is a workflow trigger.

n8n And Client AIOS Systems

Future client AIOS systems may use n8n as the backend workflow engine.

n8n may support:

intake workflows
customer support routing
voice agent tool calls
chatbot RAG
lead qualification
report generation
dashboard actions
CRM updates
email follow-up
client alerts
approval workflows

AIBS Rule

Client-facing n8n workflows must be isolated, logged, documented, permissioned, and supportable.

n8n Build Planning Checklist

Before building a serious n8n workflow, answer:

What is the workflow purpose?
Who owns it?
Is it internal or client-facing?
What triggers it?
What data enters?
What systems does it touch?
What credentials are required?
What is the expected output?
What is the handoff destination?
What happens if it fails?
Is human approval required?
Does it touch client data?
Does it send messages?
Does it create public output?
Does it use AI?
Does it need logs?
Does it need source visibility?
Is Make better for this?
Is n8n better for this?
Should this call an existing workflow instead of rebuilding?

n8n Launch Readiness Checklist

Before launching a serious n8n workflow, confirm:

workflow name is clear
owner is assigned
trigger is correct
test webhook replaced by production webhook
credentials are secure
API keys are not exposed
payload schema is known
test data passed
live data passed
item counts are correct
binary file handling works if relevant
error paths exist
retry logic exists where needed
human approval exists where needed
logs are captured
client isolation exists if needed
rate limits are considered
cost exposure is considered
sensitive data is protected
dashboard/action buttons are governed
documentation exists
rollback/disable process is known

n8n Failure Modes

Failure Mode 1: Wrong Webhook URL

Test URL is used in production or production URL is used while testing.

Correction:

Confirm test versus production URL before connecting external systems.

Failure Mode 2: Workflow Not Activated

Production webhook does not work because the workflow is not active.

Correction:

Activate workflow before testing production URL.

Failure Mode 3: Item Count Confusion

Workflow sends multiple emails or creates duplicate records because multiple items entered a node.

Correction:

Check item count, aggregate, merge properly, or execute once when appropriate.

Failure Mode 4: Pinned Data Misleads Testing

Workflow works with pinned data but fails with live binary/API data.

Correction:

Final test must use live data.

Failure Mode 5: Missing Binary Field

File upload/email attachment fails because expected binary data is missing or named differently.

Correction:

Confirm binary field name and source.

Failure Mode 6: Webhook Exposed

Public endpoint receives unwanted or malicious requests.

Correction:

Add authentication, secrets, schema validation, logging, and source restrictions.

Failure Mode 7: Code Node Undocumented

A code node does important work but no one knows what it does later.

Correction:

Document code node purpose and assumptions.

Failure Mode 8: Over-Rebuilding Make Workflows

Working Make automations are rebuilt in n8n without need.

Correction:

Bridge first if bridging solves the problem.

Failure Mode 9: Self-Hosted n8n Without Maintenance

n8n runs on a VPS but no one monitors updates, backups, errors, or credentials.

Correction:

Assign infrastructure owner and maintenance checklist.

Failure Mode 10: AI Agent Tool Drift

n8n AI agent gains too much tool access or performs undefined work.

Correction:

Apply AI Tool Permission And Access Framework.

Failure Mode 11: Client Workflow Not Isolated

Multiple client workflows share data, memory, or credentials incorrectly.

Correction:

Separate clients by database filters, credentials, workflows, projects, or instances where appropriate.

Application To Automation Brain

Automation Brain owns this standard.

Automation Brain should use this page to decide:

when n8n should be used
when Make should be used
when hybrid Make↔n8n is justified
how webhooks should be governed
how workflow calls should be structured
how self-hosted n8n should be handled
how AI agent workflows should be controlled
how client automations should be documented

Automation Brain Rule

No serious n8n workflow should become active without trigger, input, output, owner, permission, error, and logging clarity.

Application To AIBS Brain

AIBS Brain should use this standard when packaging automation products.

AIBS packages may use n8n for:

client dashboards
lead intake
proposal generation
competitor intelligence
voice AI
chatbots
report delivery
CRM workflows
email follow-ups
client AIOS systems

AIBS Rule

n8n should support client outcomes.

Do not sell the workflow.

Sell the business result.

Application To HeadOffice Brain

HeadOffice should use this standard to govern internal automation growth.

HeadOffice should watch for:

too many workflows
unclear ownership
weak logging
duplicated Make/n8n systems
exposed webhooks
tool permission drift
M workload risk
client-facing deployment without governance

HeadOffice Rule

HeadOffice approves n8n expansion when it affects cross-Brain systems or client-facing infrastructure.

Application To Data Brain

Data Brain should govern n8n workflows that touch:

Supabase
PostgreSQL
vector memory
client data
dashboard data
RAG sources
lead records
report records
logs
event tables

Data Brain Rule

If n8n changes important data, the data schema and source-of-truth rules must be known.

Application To Risk And Compliance Brain

Risk and Compliance Brain must review n8n workflows that involve:

cold outreach
scraping
enrichment
customer messages
voice calls
WhatsApp
email sends
personal data
client reports
public content
sensitive data
financial/legal/health-related outputs
external webhooks

Risk Rule

The more external the workflow, the stronger the risk review.

Application To SIT Brain

SIT Brain should test important n8n workflows.

SIT should test:

happy path
missing fields
malformed webhook payload
API error
duplicate input
no matching record
large file
multiple items
wrong client ID
credential failure
rate limit
timeout
no-answer fallback
rollback/disable path

SIT Rule

n8n workflows need workflow tests, not just node-by-node tests.

Future AI Employee Capabilities

This standard supports future AI Employees such as:

n8n Workflow Architect

Designs n8n workflow structure, triggers, branches, data flow, and handoffs.

n8n Debugging Agent

Reviews failed executions, item count issues, webhook errors, and API failures.

Automation Tool Router

Decides whether a workflow belongs in Make, n8n, or hybrid Make↔n8n.

Webhook Governance Agent

Reviews webhook exposure, payload schema, method, security, and response behavior.

n8n Credential Risk Reviewer

Checks tool credentials, access levels, and secret exposure.

n8n Deployment Readiness Reviewer

Checks whether a workflow is ready for production or client use.

Make-n8n Bridge Architect

Designs safe Make↔n8n workflow handoffs.

Future Expansion

This standard may later produce more specific pages:

MWMS Make-n8n Hybrid Orchestration Framework
MWMS n8n Webhook Governance Standard
MWMS n8n Self-Hosting Security Checklist
MWMS n8n Workflow Modularization Standard
MWMS n8n Client Workflow Deployment Checklist
MWMS n8n AI Agent Tooling Standard
MWMS n8n Error Handling And Retry Standard
MWMS Automation Platform Selection Framework

These should only be created when needed.

Strategic Summary

This block makes it clear that n8n is a major future MWMS automation layer.

The important lesson is not simply how to copy nodes from Make into n8n.

The important lesson is that n8n gives MWMS:

deeper workflow control
better AI agent tooling
code-level transformation
native workflow calls
webhook flexibility
PostgreSQL-backed deployment
self-hosting options
RAG orchestration potential
Make hybrid bridging
AIOS backend infrastructure

Make is still useful.

n8n is not a replacement for every Make scenario.

The stronger MWMS strategy is to use both:

Make for speed, visual simplicity, and existing working scenarios
n8n for advanced AIOS workflows, self-hosted infrastructure, database-backed automation, and deeper orchestration

The Make/n8n sandwich is especially important because it means MWMS does not need to throw away previous work.

It can bridge systems.

That protects time, cost, and momentum.

Final Standard

The MWMS standard is:

Use Make for fast visual automation.
Use n8n for advanced orchestration, AI agent workflows, self-hosted systems, database-backed workflows, RAG, and AIOS infrastructure.
Bridge Make and n8n when rebuilding is unnecessary.
Govern webhooks, credentials, workflow calls, item counts, binary files, code nodes, and client data before production use.

n8n is not just a tool.

For MWMS, n8n is a future automation operating layer.

Change Log

Version: v1.0
Date: 2026-06-01
Author: MWMS HeadOffice

Change:

Created the MWMS n8n Operating And Deployment Standard from the AI Automations by Jack n8n / Make Conversion / Self-Hosting / Workflow Calls block.

Captured key lessons from:

n8n Nodes vs Make Modules
The Make/n8n Sandwich
Self Hosting n8n
Making Workflow Calls in n8n
One Webhook / Multiple HTTP Methods
PDF / JPG / ZIP utility workflow examples

Defined n8n as a governed automation orchestration platform for advanced workflow execution, AI agent tooling, database-backed automation, webhook integration, system-to-system routing, and future AIOS infrastructure.

Added Make versus n8n operating guidance, including when to use Make, when to use n8n, and when to bridge both platforms.

Added Make module to n8n node translation sections covering webhooks, routers/switches, iterators/split-out nodes, aggregators, set/edit fields, HTTP requests, code transformations, and AI agents.

Added the Make/n8n Sandwich Pattern, including activation-only calls and data-rich request/response calls.

Added native n8n workflow call guidance using Execute Workflow and When Executed By Another Workflow.

Added n8n workflow modularization rules, webhook governance, one webhook / multiple HTTP methods rule, HTTP Request Standard, Data Transformation Standard, Code Node Governance, Merge And Item Reference Rule, Pinned Data Rule, Binary File Handling Standard, Self-Hosted n8n Deployment Standard, Coolify Standard, n8n With PostgreSQL Rule, Cloudflare And DNS Rule, Environment Separation, Credential Governance, Error Handling Standard, Human-In-The-Loop Rule, n8n AI Agent Governance, n8n And RAG, n8n And Dashboards, and n8n And Client AIOS Systems.

Added n8n Build Planning Checklist and n8n Launch Readiness Checklist.

Added n8n failure modes covering wrong webhook URL, inactive workflows, item count confusion, pinned data, missing binary fields, exposed webhooks, undocumented code nodes, unnecessary Make rebuilds, self-hosting without maintenance, AI agent tool drift, and client workflow isolation failure.

Mapped this standard across Automation Brain, AIBS Brain, HeadOffice Brain, Data Brain, Risk Brain, Compliance Brain, and SIT Brain.

Added future AI Employee capabilities including n8n Workflow Architect, n8n Debugging Agent, Automation Tool Router, Webhook Governance Agent, n8n Credential Risk Reviewer, n8n Deployment Readiness Reviewer, and Make-n8n Bridge Architect.

Purpose of creation:

To create the foundational MWMS operating standard for using n8n as a governed automation orchestration layer across internal MWMS workflows, Make/n8n hybrid systems, self-hosted automation infrastructure, AI agent workflows, Supabase/RAG workflows, dashboard actions, and future AIBS client AIOS systems.