DEV Community: Muhammad Gharis

The Single All-Purpose AI Agent Is the Wrong Architecture

Muhammad Gharis — Sun, 28 Jun 2026 21:37:04 +0000

Everyone is trying to build one AI agent that does everything.

One agent to understand the request.

One agent to query the database.

One agent to validate the business rules.

One agent to update the ERP.

One agent to write the customer response.

One agent to trigger the downstream workflow.

That sounds convenient.

It is also a weak architecture for serious business systems.

The more responsibility you give to one AI agent, the harder it becomes to debug, validate, secure, and audit.

In production environments, that matters.

The problem with one big agent

A general-purpose AI agent is easy to demo.

Give it access to tools.

Let it reason.

Let it call APIs.

Let it decide what to do next.

The demo looks impressive.

But inside an enterprise system, the question is not only:

Can the agent complete the task?

The real questions are:

Which data was it allowed to access?
Which business rules did it apply?
What happens if it chooses the wrong tool?
What happens if it formats the wrong API payload?
Who reviews high-risk actions?
Where is the audit trail?
Can the failure be isolated?

When one agent owns everything, every failure becomes harder to trace.

Was it a reasoning issue?

Was it a data issue?

Was it a validation issue?

Was it a permission issue?

Was it an execution issue?

That is why a single all-purpose agent becomes risky as soon as it touches real systems.

A better model: agent orchestration

The better pattern is not one agent doing everything.

The better pattern is agent orchestration.

Instead of one large agent, you design smaller agents or services with limited responsibilities.

For example:

Database Query Agent
→ only reads from approved data sources

Validation Agent
→ checks business rules and required fields

Communication Agent
→ formats responses for customers or internal users

Execution Layer
→ performs deterministic API calls only after validation

Audit Layer
→ records every request, decision, and output

Each component has a clear role.

Each component has boundaries.

Each component can fail independently.

That is much easier to control than a single agent with broad access.

Why specialization matters

A database query agent should not also decide whether a vendor payment is safe.

A communication agent should not also update inventory.

A validation agent should not also send customer messages.

These responsibilities should be separated.

That separation gives you several benefits:

Easier debugging
Clear ownership
Better security boundaries
More predictable execution
Cleaner audit trails
More controlled failure handling

This is how backend systems are normally designed.

AI does not remove the need for architecture.

It makes architecture more important.

The handoff is the real design problem

The important part is not only the agent.

The important part is the handoff.

When one agent finishes its task, what exactly does it pass downstream?

Is the output structured?

Is it validated?

Is confidence recorded?

Is the source data attached?

Is the next component allowed to act on it?

Is human approval required?

This is where many AI systems fail.

They focus too much on the prompt and not enough on the boundary between steps.

A strong AI workflow should define:

Input
→ allowed tools
→ expected output schema
→ validation rules
→ failure behavior
→ approval rules
→ audit logging

Without this, the system becomes difficult to trust.

Example: ERP workflow

Imagine a user sends this request:

Please increase inventory for SKU-1001 by 800 units in warehouse WH-01.

A single agent might parse the request and update the ERP.

That is dangerous.

A better workflow:

Request received
→ AI extracts structured intent
→ Validation checks required fields
→ Guardrails check quantity threshold
→ Human approval required because quantity is high
→ ERP update happens only after approval
→ Audit log records the full decision

The AI is useful.

But it is not acting alone.

It is part of a controlled workflow.

Where MCP and A2A-style patterns fit

Protocols and patterns around model context, tool access, and agent-to-agent communication are becoming important because they help define how AI systems interact with external tools and other services.

But the protocol is not the full answer.

The architecture still matters.

You still need to decide:

Which agent owns which responsibility
What data each agent can access
Which actions require approval
How failures are handled
How audit logs are maintained
How business rules are enforced

The technology helps.

The design still has to be intentional.

Frameworks are not the moat

Frameworks like LangGraph, CrewAI, and similar tools can help teams build agent workflows.

But the framework is not the hard part.

The hard part is decomposition.

Where does one responsibility end?

Where does another begin?

Which step should be probabilistic?

Which step must be deterministic?

Which step requires human review?

Which step should be blocked completely?

These are architecture decisions.

Not prompt engineering decisions.

Final thought

The future of enterprise AI is not one chatbot controlling everything.

It is smaller, controlled components working together.

AI should reason.

Validation should enforce rules.

Execution should be deterministic.

Approval should exist for high-risk actions.

Audit logs should capture every meaningful step.

That is the difference between an AI demo and an AI system that can be trusted near business-critical workflows.

For Oracle, Odoo, ERP, and custom backend environments, this is the direction I believe matters most:

Not bigger agents.

Better handoffs.

AI Agents Should Not Touch Your ERP Directly. Build an Execution Layer Instead.

Muhammad Gharis — Sun, 28 Jun 2026 21:31:05 +0000

tags: ai, n8n, fastapi, architecture

Everyone is building AI agents right now.

That is not the hard part anymore.

Writing a Python script that calls an LLM is simple. You can connect an API, send a prompt, receive a response, and call it an agent.

The real problem starts when that agent wants to do something useful inside a business system.

Update inventory.

Create a vendor payment.

Change a CRM record.

Post a transaction.

Trigger a customer notification.

Touch an ERP database.

That is where many AI agent demos become dangerous.

Because a raw LLM is probabilistic.

Enterprise execution needs control.

The problem

Most AI agent examples look clean in a demo.

A user asks something.

The agent understands it.

The agent calls a tool.

The system updates something.

Done.

But in a real ERP or backend environment, that is not enough.

Before an AI-generated action reaches a production system, you need answers to basic questions:

Who approved this action?

Was the payload validated?

Was the user allowed to perform this operation?

Was the vendor active?

Was the amount above the approval threshold?

Was the inventory update within allowed limits?

Was the final API request deterministic?

Was every step logged?

Who owns the failure if the action is wrong?

This is the gap between an AI experiment and an AI-enabled business workflow.

Why direct AI-to-ERP execution is risky

An AI agent should not directly write into an ERP system.

Not because AI is useless.

Because ERP systems contain business-critical data.

They contain customers, invoices, vendors, payments, inventory, payroll, approvals, and financial records.

If an AI agent sends the wrong payload, chooses the wrong record, or skips a business rule, the damage is not theoretical.

It can affect reporting, operations, finance, compliance, and customer trust.

That is why I do not like the pattern where an LLM directly controls execution.

The LLM should help with reasoning.

It should extract intent.

It should summarize context.

It should classify requests.

It should draft responses.

But execution should be handled by deterministic systems.

A better pattern: AI execution layer

The safer architecture is:

Webhook request
→ AI extraction
→ Schema validation
→ Guardrail decision
→ Human approval if needed
→ ERP/API execution
→ Audit log

This separates reasoning from execution.

The AI does not directly update the ERP.

Instead, it produces structured output.

That output is validated.

Then business rules decide whether the action is allowed, blocked, or requires human approval.

Only after that does the workflow call the ERP or backend API.

Where low-code orchestration helps

This is where tools like n8n become useful.

Not because low-code replaces backend engineering.

It does not.

You still need Python, FastAPI, Django, APIs, validation models, databases, and proper infrastructure.

But low-code orchestration gives you a visible execution layer.

You can see the workflow.

You can see routing logic.

You can add approval checkpoints.

You can separate AI reasoning from API execution.

You can log every decision.

You can make the process easier for business and technical teams to review.

That visibility matters when AI starts touching real systems.

Example architecture

A practical setup could look like this:

n8n Webhook
    ↓
FastAPI AI Extraction Service
    ↓
Pydantic Schema Validation
    ↓
Guardrail Evaluation
    ↓
Decision:
    - Allow
    - Require Approval
    - Block
    ↓
Mock ERP / Real ERP API
    ↓
Audit Log

In this architecture:

FastAPI handles the backend service layer.
Pydantic enforces strict schemas.
n8n handles orchestration and approval routing.
The ERP API only receives validated requests.
Every decision is logged.

The AI is useful, but it is not trusted blindly.

Demo scenario

I created a small demo concept around two common ERP-style workflows:

Low-risk inventory update
High-risk vendor payment

The inventory update can proceed if it passes validation and stays within allowed limits.

The vendor payment requires human approval if the amount crosses a defined threshold.

Invalid or incomplete requests are blocked before they reach the ERP layer.

For example:

{
  "request_text": "Increase inventory for item SKU-1001 by 25 units in warehouse WH-01",
  "source": "webhook",
  "requested_by": "operations_user"
}

The AI extraction service converts this into structured intent.

Then validation checks the required fields.

Then guardrails decide whether the action can continue.

Only then does the mock ERP endpoint receive the request.

What the guardrails check

Some simple example rules:

Vendor payment above 10,000 requires approval.
Missing vendor ID fails validation.
Inventory update above 500 units requires approval.
Unknown action type is blocked.
Low confidence AI extraction requires human review.
Payment to inactive vendor is blocked.

These rules are not complex.

That is the point.

The execution layer should be predictable.

The LLM should not be responsible for deciding every business rule at runtime.

Why audit logs matter

If AI is involved in business execution, audit logs are not optional.

You need to know:

What request came in
What the AI extracted
What validation returned
Which guardrail decision was made
Whether approval was required
Who approved it
What ERP action was executed
What response came back

Without this, you do not have an AI workflow.

You have an invisible automation risk.

What this demo is not

This is not a production ERP connector.

It does not claim to solve compliance by itself.

It does not replace authentication, RBAC, rate limits, secret management, monitoring, or proper security review.

Self-hosting also does not automatically make a system compliant.

Compliance depends on implementation, hosting, contracts, access control, logging, data handling, and internal policy.

The goal of the demo is simpler:

Show the architecture pattern.

AI for reasoning.

Deterministic systems for execution.

Orchestration for visibility.

Approval for high-risk actions.

Audit logs for accountability.

Why this matters for ERP systems

This pattern applies well to environments like:

Odoo
Oracle
Django/FastAPI business systems
Internal admin portals
Finance workflows
Inventory workflows
CRM automation
Support ticket routing
Vendor and invoice processing

The more critical the system, the more important the handoff design becomes.

The main question is not:

Which LLM should we use?

The better question is:

Where does the AI stop, and where does controlled execution begin?

GitHub demo

I am preparing a small reference repo for this pattern:

https://github.com/gharisj3/ai-agent-execution-layer-demo

The repo structure includes:

FastAPI backend
Mock ERP endpoints
Pydantic validation
Guardrail rules
Audit log storage
n8n workflow export
Sample payloads
Demo script
Security notes

The demo flow is:

Webhook request → AI extraction → schema validation → guardrail decision → human approval if needed → mock ERP execution → audit log

Final thought

AI agents will become more useful inside business systems.

But they should not be allowed to operate like invisible admin users.

The future is not one chatbot controlling everything.

The better direction is controlled execution layers, clear permissions, validation rules, approval checkpoints, and audit trails.

That is where AI becomes useful for real operations.

Not because it can generate text.

Because it can support business workflows without bypassing the controls those workflows require.

If you are exploring this pattern for Odoo, Oracle, Django/FastAPI backends, or n8n-based automation, I am happy to discuss how it can be adapted to your environment.

I Built a WhatsApp Native Helpdesk for Odoo Community

Muhammad Gharis — Mon, 22 Jun 2026 22:50:14 +0000

I Built a WhatsApp Native Helpdesk for Odoo Community

Most customer support systems still assume that customers want to open tickets by email.

But in many markets, that is not how support actually happens.

In Pakistan, MENA, South Asia, Africa, and many WhatsApp-first regions, customers usually do not start with a support portal or email thread.

They send a WhatsApp message.

That message becomes the real support request.

The problem is that Odoo Community does not provide a complete WhatsApp-native helpdesk workflow out of the box.

So I built an open-source module:

WhatsApp Native Helpdesk for Odoo Community

GitHub repo:
https://github.com/gharisj3/odoo-whatsapp-native-helpdesk

The Problem

Many small and mid-sized businesses already use Odoo Community for CRM, sales, accounting, inventory, and operations.

But customer support often lives outside Odoo.

Support messages are scattered across:

WhatsApp chats
Agent phones
Manual spreadsheets
Email screenshots
Internal notes
Verbal follow-ups

This creates a few serious problems:

No central ticket history
No ownership
No SLA visibility
No escalation process
No clean audit trail
No connection between support and business records

For WhatsApp-first businesses, the support channel is already clear.

The missing piece is bringing that workflow into Odoo Community.

What I Built

I built a WhatsApp-native support desk module for Odoo Community.

The module allows businesses to receive WhatsApp customer messages, create or update support tickets in Odoo, assign tickets to agents, track status and SLA, and reply back to the customer through WhatsApp using n8n as the automation layer.

The core flow is simple:

Customer WhatsApp Message
        ↓
Meta WhatsApp Cloud API
        ↓
n8n Workflow
        ↓
Odoo Webhook
        ↓
Odoo Support Ticket
        ↓
Agent Reply from Odoo
        ↓
n8n Workflow
        ↓
WhatsApp Reply to Customer

The goal was not to build a chatbot.

The goal was to build real support ticketing around the communication channel customers already use.

Why n8n Is Used

I used n8n as the integration layer because it keeps the WhatsApp API handling separate from Odoo.

That means Odoo does not need to store Meta WhatsApp access tokens directly.

n8n handles:

WhatsApp webhook receiving
Payload normalization
WhatsApp Cloud API calls
Status update routing
Future automation workflows

Odoo handles:

Ticket creation
Customer mapping
Agent assignment
Message history
SLA tracking
Status management
Internal support workflow

This separation makes the system easier to extend later.

For example, the same pattern can be reused for:

CRM enrichment
Invoice follow-ups
Order status updates
POS support
Vendor workflows
AI-assisted reply suggestions
Customer satisfaction surveys

Key Features

The current version includes:

WhatsApp-to-ticket creation
Existing ticket update when the same customer replies
Partner auto-mapping by phone number or WhatsApp ID
Agent reply from inside Odoo
Outbound WhatsApp message flow through n8n
Message deduplication using WhatsApp message ID
Ticket stages
Team assignment
Priority tracking
SLA tracking
First response tracking
Failed message handling
Retry action for failed outbound messages
Message status sync
Dashboard views
Docker-based local setup
Importable n8n workflow examples
Postman API collection
Security groups and access rules

Ticket Lifecycle

A normal support flow looks like this:

A customer sends a WhatsApp message.
n8n receives the webhook from Meta WhatsApp Cloud API.
n8n normalizes the payload.
Odoo receives the payload through a secure webhook endpoint.
Odoo checks whether the customer already exists.
If the customer does not exist, Odoo creates a partner.
Odoo checks whether there is an open ticket for that customer.
If an open ticket exists, the message is added to the same ticket.
If no open ticket exists, a new ticket is created.
The support agent replies from Odoo.
n8n sends the reply through WhatsApp Cloud API.
Odoo stores the outbound message and delivery status.

This keeps the full conversation history inside Odoo.

Why This Matters

For businesses that rely on WhatsApp, this kind of workflow can reduce a lot of operational friction.

Instead of support being managed inside individual chat threads, it becomes structured.

Agents can see:

Who owns the issue
What the latest message was
Whether the SLA is at risk
Which stage the ticket is in
Whether a reply failed
Whether the issue was resolved
Which customer record the issue belongs to

That is a big improvement over scattered WhatsApp conversations.

Repository Structure

The repository is organized as a real Odoo addon project:

odoo-whatsapp-native-helpdesk/
├── addons/
│   └── whatsapp_helpdesk/
├── n8n/
│   └── workflows/
├── docs/
├── postman/
├── scripts/
├── docker-compose.yml
├── Dockerfile
├── .env.example
└── README.md

The Odoo source code is not committed into the repository.

The project includes bootstrap scripts and Docker setup so Odoo Community can be cloned and run locally during development.

Tech Stack

The project uses:

Odoo Community
Python
PostgreSQL
Docker
n8n
Meta WhatsApp Cloud API
REST webhooks
XML views and security rules
Postman for API testing

Local Setup

Clone the repo:

git clone https://github.com/gharisj3/odoo-whatsapp-native-helpdesk.git
cd odoo-whatsapp-native-helpdesk

Copy the environment file:

cp .env.example .env

Make scripts executable:

chmod +x scripts/*.sh

Bootstrap Odoo:

./scripts/bootstrap_odoo.sh

Start the services:

docker compose up -d

Then open:

Odoo: http://localhost:8069
n8n:   http://localhost:5678

Odoo Installation Flow

After Odoo is running:

Create a new database.
Activate developer mode.
Update the Apps List.
Search for WhatsApp Helpdesk.
Install the module.
Configure the WhatsApp Helpdesk channel.
Import the n8n workflows.
Test inbound and outbound flows.

n8n Workflow Layer

The project includes example n8n workflows for:

Inbound WhatsApp message to Odoo ticket
Odoo agent reply to WhatsApp
WhatsApp status update sync

The workflows are designed as starting points.

You still need to configure your own:

Meta WhatsApp Cloud API credentials
WhatsApp phone number ID
Odoo base URL
Shared secret
Production webhook URLs

Security Design

A few security choices were intentional:

Meta access tokens are not stored in Odoo.
WhatsApp API calls are handled by n8n.
Webhook endpoints validate a shared secret.
Real credentials are excluded from the repository.
.env.example uses placeholder values only.
Failed outbound messages are logged without exposing credentials.
Internal notes are not sent to customers.

For production, the setup should run behind HTTPS with proper reverse proxy configuration, strong passwords, and protected Odoo/n8n access.

Legal and Compliance Notes

This is an independent open-source project.

It is not an official Odoo, Meta, WhatsApp, or n8n product.

It is not certified, endorsed, or sponsored by those companies.

The names Odoo, WhatsApp, Meta, and n8n are used only to describe integration compatibility and the technologies involved.

Production usage requires a valid Meta WhatsApp Cloud API setup and compliance with applicable WhatsApp Business Platform rules, messaging policies, customer consent requirements, and local laws.

This project does not bypass WhatsApp Business Platform rules.

Businesses are responsible for using approved templates where required and for following customer messaging policies.

Current Limitations

The current release focuses on the core support workflow.

Some items are planned for future versions:

Media attachment handling
WhatsApp template message support
Multi-number routing
Customer satisfaction survey
AI-assisted reply suggestions
Auto-priority classification
Working-hours SLA calendar
CRM and sales order linking
Shopify or WooCommerce lookup through n8n

Why I Built This

I work around ERP, Odoo, backend systems, and automation workflows.

I kept seeing the same gap:

Businesses were running operations in Odoo, but support conversations were happening somewhere else.

For WhatsApp-first markets, that gap matters.

This project is my attempt to make that support flow more structured, traceable, and automation-ready while still keeping it open-source friendly.

GitHub Repository

You can check the project here:

https://github.com/gharisj3/odoo-whatsapp-native-helpdesk

Fiverr:
https://www.fiverr.com/muhammadghar709

Digital products and templates:
https://omniacademy.gumroad.com/

Final Thought

WhatsApp is not just a chat app for many businesses.

It is where support starts.

The next step is making those conversations structured enough to manage, assign, track, and improve.

That is what this project is built for.

Why ERP Go-Live Fails Without a Command Center

Muhammad Gharis — Sun, 14 Jun 2026 08:05:00 +0000

ERP implementation does not usually fail because of one big issue.

It usually fails because many small issues are not tracked properly.

During go-live, teams are dealing with:

open issues
UAT feedback
user sign-offs
cutover activities
data migration tasks
access rights checks
business confirmations
pending reports
integration readiness
support responsibilities

If these items are not clearly tracked, the go-live phase becomes stressful very quickly.

The problem with ERP go-live

A go-live phase needs discipline.

Without a structured tracker, teams may struggle with questions like:

Which issues are still open?
Who owns each action item?
Has UAT been signed off?
Which reports are pending?
Are integrations ready?
Is the cutover plan approved?
Which tasks are critical before go-live?
Who confirmed the final business readiness?

For systems like Odoo ERP, even a small missed configuration, access rule, or data issue can create operational problems after launch.

What a command center should include

A simple ERP go-live command center should include:

go-live checklist
cutover plan
UAT issue tracker
sign-off tracker
open issues log
responsible owner column
priority and status fields
final readiness review

This gives the implementation team and business stakeholders one place to track readiness.

What I built

I created an Odoo ERP Go-Live Command Center Pack.

It is designed for consultants, implementation teams, ERP users, and small businesses preparing for an Odoo go-live.

The pack includes:

go-live checklist
cutover planning template
UAT issue tracker
sign-off templates
open issue tracking structure
readiness documentation format

The goal is to reduce confusion during go-live and give teams a simple structure to manage the final stage.

Who this is useful for

This can help:

Odoo consultants
ERP implementation teams
business users
project managers
SMEs going live with ERP
support teams
functional consultants
technical consultants

I have listed the ready-made pack on Gumroad for anyone working around Odoo ERP implementation or go-live planning.

Check it here:

https://omniacademy.gumroad.com/l/hjacq

Connect with me

Gumroad: https://omniacademy.gumroad.com

GitHub: https://github.com/gharisj3

LinkedIn: https://www.linkedin.com/in/muhammad-gharis-javed-318266202

Contra: https://contra.com/muhammad_gharis_j2g71vgn

Fiverr: https://www.fiverr.com/sellers/muhammadghar709

Email: gharis@omni-academy.com

I Built an n8n Client Intake Workflow Pack with Google Sheets CRM and WhatsApp Follow-Up Structure

Muhammad Gharis — Sun, 14 Jun 2026 08:04:08 +0000

Client intake is one of the most underrated parts of freelancing and agency work.

Many service providers can deliver the work, but their intake process is messy.

A typical flow looks like this:

client sends a WhatsApp message
requirements are discussed in chat
important details get buried
no proper CRM record is created
follow-up dates are forgotten
onboarding steps are repeated manually
client information is scattered across messages, emails, and sheets

This creates confusion before the actual work even starts.

The problem

When client intake is not structured, it affects everything after that:

unclear requirements
missed follow-ups
poor project handover
delayed proposals
weak client experience
no central tracking sheet
repeated manual work

For freelancers and small agencies, this can directly affect sales and delivery quality.

The simple workflow idea

A better client intake system should help you:

collect client details
store them in a tracker
assign status and priority
document requirements
prepare follow-up actions
create a basic CRM-style view
use reusable messages and prompts

This does not always require a complex SaaS tool.

A simple combination of n8n, Google Sheets, WhatsApp follow-up structure, and documentation can be enough for many small teams.

What I built

I created an n8n Client Intake Workflow Pack for freelancers, agencies, consultants, and automation builders.

It includes:

client intake workflow structure
Google Sheets CRM tracker idea
WhatsApp follow-up automation structure
setup guide
client tracking format
reusable workflow documentation

The goal is to help small teams organize client intake without starting from zero.

Who this is useful for

This can help:

freelancers
consultants
small agencies
automation service providers
virtual assistants
business operations teams
people learning n8n workflows

I have listed the ready-made pack on Gumroad for anyone who wants to check it out.

Link:

https://omniacademy.gumroad.com/l/jdbaw

Connect with me

25 No-Code Automation Ideas for Freelancers, Agencies and Small Businesses

Muhammad Gharis — Sun, 14 Jun 2026 08:03:04 +0000

Many people want to start using automation, but they get stuck at the same point:

They do not know what to automate first.

The problem is not always the tool.

The problem is choosing the right workflow.

A freelancer, agency, or small business may use:

WhatsApp
Google Sheets
email
forms
invoices
CRM notes
client onboarding documents
task trackers

But without a clear automation checklist, everything stays manual.

Common manual problems

Small teams usually waste time on tasks like:

copying client details from messages to spreadsheets
sending the same follow-up message again and again
forgetting invoice reminders
tracking leads manually
creating client handover notes from scratch
checking forms and updating sheets
repeating onboarding steps for every client

These tasks are small individually, but together they consume hours every week.

Why I created this checklist

I created a Free AI Automation Workflow Checklist with 25 no-code automation ideas.

The purpose is simple:

Help freelancers, consultants, agencies, and small businesses identify practical automation opportunities without overcomplicating the process.

This is not about building a massive system.

It is about finding small workflows that can save time immediately.

Example automation ideas

Some useful workflow categories include:

lead capture automation
client intake automation
CRM update automation
invoice reminder automation
follow-up automation
onboarding automation
handover documentation automation
Google Sheets tracking automation
AI prompt-based content or data processing

A simple checklist can help you decide what to automate first.

Who can use this

This checklist is useful for:

freelancers
consultants
small agencies
beginner automation builders
no-code learners
small business owners
virtual assistants
operations teams

I have listed it on Gumroad as a free / pay-what-you-want resource.

You can check it here:

https://omniacademy.gumroad.com/l/sexej

Connect with me

I Built a Simple AI Lead Qualification CRM Workflow Pack for Freelancers and Small Teams

Muhammad Gharis — Sun, 14 Jun 2026 07:41:08 +0000

I Built a Simple AI Lead Qualification CRM Workflow Pack for Freelancers and Small Teams

Most freelancers, agencies, consultants, and small businesses do not lose leads because they are bad at selling.

They lose leads because their follow-up system is weak.

A common situation looks like this:

leads come from LinkedIn, WhatsApp, email, forms, or referrals
notes are saved in random chats
follow-ups are forgotten
lead quality is not scored properly
there is no simple CRM pipeline
every new client inquiry starts from zero again

Large CRM tools are useful, but many small teams do not need a complex SaaS system on day one.

They need a lightweight system that helps them:

capture leads
qualify leads
score lead quality
track follow-ups
move leads through a pipeline
reuse AI prompts for lead analysis
document the sales process clearly

So I built a practical AI Lead Qualification CRM Workflow Pack.

What the pack includes

This pack is designed for freelancers, consultants, agencies, and small businesses that want a simple AI-assisted lead qualification workflow.

It includes:

n8n lead qualification workflow idea
lead scoring sheet
CRM pipeline template
AI prompt pack for lead analysis
follow-up tracking structure
simple workflow documentation

The goal is not to replace a full CRM platform.

The goal is to help small teams organize leads before they become messy.

Why I built it

In real freelance and agency work, most missed opportunities come from poor tracking.

A lead may be interested today, but if nobody follows up after 2 days, that opportunity becomes cold.

A simple workflow can make a big difference:

Capture the lead
Score the lead
Add notes
Assign a follow-up date
Move the lead through stages
Reuse AI prompts to analyze intent and priority

This kind of structure saves time and reduces manual decision-making.

Who this is useful for

This can help:

freelancers
solo consultants
small agencies
service providers
automation builders
CRM beginners
people selling digital or professional services

I have listed this as a small paid digital product on Gumroad for anyone who wants to use the ready-made version instead of building it from scratch.

Check it here:

https://omniacademy.gumroad.com/l/pkybo

Connect with me

How I Built an AI Business Automation Workflow Pack with n8n, Google Sheets and JSON Templates

Muhammad Gharis — Thu, 11 Jun 2026 15:30:25 +0000

How I Built an AI Business Automation Workflow Pack with n8n, Google Sheets and JSON Templates

Most business automation ideas sound simple at the start:

“Capture a lead, save it somewhere, send a reply, and follow up later.”

But when you try to build it properly for a real client or business, the workflow becomes more serious.

You need to think about:

How the lead data enters the system
Where the data is stored
What happens if a field is missing
How the AI response is generated
How follow-ups are tracked
What happens if an API fails
How the client will understand and maintain the workflow later

That is why I decided to build a structured AI Business Automation Workflow Pack using n8n-style workflow templates, Google Sheets-style CRM trackers, JSON workflow files, prompt templates, testing checklists, and client handover documents.

This post explains the thinking behind it.

The Problem I Wanted to Solve

Many freelancers and small businesses want automation, but they usually do not need a huge CRM or expensive SaaS setup at the beginning.

They need something practical:

Capture leads from forms or webhooks
Store inquiries in a simple CRM tracker
Draft AI-assisted replies
Follow up with leads
Track invoice/payment reminders
Triage support messages
Deliver the workflow to a client professionally

The real pain is not just building one automation.

The real pain is building a repeatable system that can be reused across clients and projects.

The Core Stack

For this product, I designed the pack around a simple and practical stack:

Webhook / Form Input
        ↓
n8n Workflow Template
        ↓
Data Cleaning / Validation
        ↓
AI Prompt / Reply Draft
        ↓
Google Sheets-style CRM Tracker
        ↓
Email / Follow-Up / Client Output
        ↓
Testing + Handover Documentation

The goal was to make each workflow easy to understand, modify, and reuse.

What the Pack Includes

I structured the product into several parts:

1. n8n workflow JSON templates
2. Google Sheets-style CRM trackers
3. AI prompt templates
4. PDF setup guides
5. Testing checklists
6. Error handling checklists
7. Client handover documents
8. README and license files

The idea is that a freelancer or automation consultant can use the pack as a starting point instead of creating everything from scratch.

Workflow 1: Lead Intake to CRM Tracker

The first workflow is a simple lead intake flow.

The structure looks like this:

Webhook receives lead
        ↓
Validate required fields
        ↓
Normalize name, email, phone, source
        ↓
Assign lead status
        ↓
Save to CRM tracker
        ↓
Return success response

Example lead data:

{
  "name": "John Smith",
  "email": "john@example.com",
  "phone": "+123456789",
  "source": "Website Form",
  "message": "I need automation for my business"
}

The workflow is designed to make sure every lead has a proper structure before it is stored.

Workflow 2: Contact Form to Google Sheets + Email Alert

This workflow is useful for small businesses that receive contact form messages.

The flow:

Contact form submission
        ↓
Clean message text
        ↓
Store submission
        ↓
Prepare internal notification
        ↓
Send email alert

The important part here is not just sending an email.

The important part is keeping a proper record of every inquiry so nothing gets lost.

Workflow 3: AI Email Reply Draft

This is one of the most useful workflows in the pack.

The flow:

Client message received
        ↓
Send message to AI prompt
        ↓
Generate professional reply draft
        ↓
Save draft to tracker
        ↓
Human reviews before sending

I intentionally designed this as a draft workflow, not a fully automatic send workflow.

Why?

Because AI-generated replies should usually be reviewed before sending to a real client, especially in business communication.

Example output structure:

{
  "status": "success",
  "message_type": "sales_inquiry",
  "priority": "medium",
  "suggested_reply": "Thank you for reaching out. I would be happy to understand your automation requirements...",
  "next_action": "schedule_discovery_call",
  "confidence": 0.86
}

This keeps the workflow safer and more professional.

Workflow 4: Client Follow-Up Reminder

Follow-ups are where many freelancers and small businesses lose money.

A lead comes in, the client sounds interested, then nobody follows up.

The workflow logic:

Read lead tracker
        ↓
Find pending follow-ups
        ↓
Check last contact date
        ↓
Prepare follow-up message
        ↓
Update follow-up status

A simple follow-up tracker can include:

Lead Name
Email
Phone
Status
Last Contact Date
Next Follow-Up Date
Follow-Up Message
Assigned Person
Notes

This can be very useful for freelancers, agencies, and small sales teams.

Workflow 5: Invoice / Payment Reminder

This workflow is designed for overdue invoice reminders.

The flow:

Read invoice tracker
        ↓
Find unpaid invoices
        ↓
Check due date
        ↓
Generate polite reminder message
        ↓
Prepare email or message output

Example reminder logic:

If due date is passed and payment status is unpaid:
    Prepare reminder
Else:
    Do nothing

This is simple, but very practical.

Many freelancers do not need advanced accounting software in the beginning. They just need a clean way to track pending payments and follow up professionally.

Workflow 6: Support Ticket Triage

The final workflow is for support requests.

The flow:

Support request received
        ↓
Classify category
        ↓
Detect priority
        ↓
Generate suggested response
        ↓
Log ticket status

Example categories:

Billing
Technical Issue
Feature Request
Account Access
General Question

Example priority levels:

Low
Medium
High
Critical

This type of workflow is useful for agencies, SaaS teams, support teams, and service businesses.

Why I Used JSON Templates

JSON templates make workflow packaging easier because they can be imported, reviewed, versioned, and reused.

For automation builders, this is useful because the workflow is not just a screenshot or idea.

It becomes a file that can be copied, modified, tested, and improved.

A good workflow template should include:

Clear node names
Placeholder credentials
No real API keys
Sample test data
Documentation notes
Error handling path
Clean workflow structure

I used placeholders like:

YOUR_API_KEY_HERE
YOUR_WEBHOOK_URL_HERE
YOUR_SHEET_ID_HERE
YOUR_EMAIL_HERE

Never include real credentials in a template product.

Why I Included Google Sheets-Style Trackers

Not every small business wants to pay for a CRM immediately.

A spreadsheet can work well for early-stage workflows.

The CRM tracker structure includes:

Leads
Contacts
Companies
Follow-Ups
Automation Logs
Email Drafts
Status Dashboard

This gives users a simple place to store and review automation output.

Why Testing Checklists Matter

A workflow is not production-ready just because it runs once.

Before using an automation with a real client, I like to test:

Required fields
Invalid email format
Duplicate records
API failure
Empty response
Wrong data type
Webhook response
Sheet writing
Email output
End-to-end flow

That is why I included workflow testing and error handling checklists in the pack.

A good automation product should not only help users build faster. It should help them build safer.

Lessons Learned While Building This

Here are the biggest lessons from creating this kind of automation pack:

1. Generic workflows are not enough

A workflow is more valuable when it comes with setup guides, checklists, trackers, and handover documents.

2. AI should support humans, not replace review

For email replies, proposals, and client communication, AI drafts should usually be reviewed before sending.

3. Templates need placeholders, not secrets

Never include real credentials, API keys, tokens, or client data.

4. Small businesses prefer simple systems

A clear spreadsheet plus a workflow is sometimes more useful than a complex SaaS setup.

5. Documentation increases trust

If a client cannot understand the automation, they will not feel comfortable using it.

Who This Type of Pack Is Useful For

This kind of workflow pack can help:

Freelancers
Automation consultants
n8n builders
Virtual assistants
Small agencies
Startup operators
Small business owners
Backend developers
AI automation service providers

The main use case is simple:

Build client-ready business automations faster without starting from zero every time.

What I Published

I packaged the full version as a digital product here:

AI Business Automation Workflow Pack — n8n Templates, Google Sheets CRM & Client Automation Kit

It includes:

6 workflow templates
CRM tracker templates
AI prompt templates
PDF setup guides
Testing checklists
Error handling checklist
Client handover documents
README and license files

Disclosure: This is my own digital product from Omni Academy Consulting and Technologies. The article is written to share the build process and structure behind the product.

Connect With Me

You can also connect with me here:

LinkedIn: LinkedIn Profile
GitHub: Github Repo
Gumroad: Omni Academy Consulting and Technologies

Final Thoughts

AI automation is not only about connecting tools.

It is about designing a repeatable business process.

A strong automation workflow should be:

Understandable
Testable
Documented
Safe
Reusable
Client-ready

That is the standard I tried to follow while building this pack.

If you are building automation products or client workflows, my advice is simple:

Do not only build the workflow.

Build the system around the workflow.

Why Your AI-Connected ERP Will Fail in Production And How to Fix It Before It Does

Muhammad Gharis — Wed, 10 Jun 2026 20:56:06 +0000

Most AI + ERP integrations fail in production not because the AI model is weak, but because there is no validation layer between the LLM output and the database.

Raw AI responses should never go directly into ERP fields.

Structure

The demo problem: AI works perfectly in a controlled example
The production problem: real data is messy and LLM output is unpredictable
Example failure: hallucinated vendor name in accounts payable
Why direct AI → ERP writes are dangerous
The fix: FastAPI middleware + Pydantic v2 validation
Code example: validated AI response schema
Code example: FastAPI endpoint returning structured output
Production pattern: AI → validation → workflow → ERP
Error handling: log failure instead of corrupting records
Repo reference: omni-odoo-stack

Suggested CTA

I built this pattern into my open-source Odoo automation repo:

https://github.com/gharisj3/omni-odoo-stack

Post 3

Title

How to Build a WhatsApp to CRM Pipeline with n8n and Odoo 19

Hook

Every WhatsApp message from a potential client should create a CRM lead automatically.

Here is the architecture I use to make that happen with n8n, Odoo, and WhatsApp Cloud API.

Why This Can Perform Well

WhatsApp automation is highly practical.

Odoo + WhatsApp tutorials are limited.

n8n users actively search for CRM, webhook, WhatsApp, and API automation examples.

Core Angle

Show a practical architecture for turning WhatsApp conversations into CRM leads using:

Meta WhatsApp Cloud API
n8n webhook trigger
Odoo CRM
FastAPI AI lead scoring
duplicate prevention
error logging

Structure

Why WhatsApp is a serious business intake channel
What you need:

Meta Business account
WhatsApp Cloud API
self-hosted n8n
Odoo 19
optional FastAPI AI middleware
1. Step 1: WhatsApp webhook setup
2. Step 2: n8n webhook trigger
3. Step 3: parse phone number, message body, and message ID
4. Step 4: duplicate prevention using message ID
5. Step 5: call AI scoring middleware
6. Step 6: create CRM lead in Odoo
7. Step 7: send WhatsApp confirmation
8. Step 8: log success or failure
9. Full workflow JSON available in repo

Important Wording Change

Avoid:

“No Code”

Use:

“No Zapier, No Monthly Automation Fees”

Because the workflow still requires API setup, webhook configuration, and Odoo endpoint understanding.

Suggested CTA

The full workflow JSON is available here:

https://github.com/gharisj3/omni-odoo-stack

Post 4

Title

Self-Hosting Odoo 19 on Oracle OCI Free Tier — Complete Setup Guide

Hook

Odoo hosting can cost $50–200/month on typical VPS or managed platforms.

Oracle OCI Always Free gives developers a powerful free-tier path for self-hosted ERP experiments.

Here is the setup approach.

Important Warning Before Publishing

Do not publish this as a “complete guide” until you have actually deployed and boot-tested Odoo on OCI.

This post will attract people who copy commands directly.

If the guide is not tested, it can hurt your credibility.

Safer Title Until Tested

How I Plan to Self-Host Odoo 19 on Oracle OCI Free Tier

Stronger Title After Testing

Self-Hosting Odoo 19 on Oracle OCI Free Tier — Complete Tested Setup Guide

Structure

Why OCI Always Free is interesting for Odoo
Free-tier limits and what to verify before relying on it
Create ARM VM
Configure SSH access
Open firewall ports
Install Docker and Docker Compose
Deploy PostgreSQL + Odoo with Docker Compose
Configure Nginx reverse proxy
Add SSL with Let's Encrypt
First Odoo login and database setup
Common errors and fixes
Final architecture diagram
Link to omni-odoo-stack repo

Publish Status

Hold until runtime tested.

Post 5

Title

5 Odoo Backend Problems I Fix Every Week And the Code That Solves Them

Hook

These five problems account for most Odoo backend issues I see in real projects.

Here is the symptom, the root cause, and the code pattern that fixes each one.

Why This Can Perform Well

This is search-friendly and practical.

Developers search for specific Odoo issues, not general strategy.

Listicles with code also perform well because readers can scan quickly.

Structure

Problem 1 — Slow Scheduled Actions

Symptom

Scheduled action times out on large datasets.

Root Cause

The job searches too many records at once and processes everything in a single transaction.

Bad Pattern

records = self.env["sale.order"].search([])

Better Pattern

records = self.env["sale.order"].search(
    [("state", "=", "draft")],
    limit=500
)

Lesson

Always filter and batch scheduled jobs.

Problem 2 — Duplicate Records from Webhooks

Symptom

Every webhook creates duplicate CRM leads, invoices, or messages.

Root Cause

No idempotency check.

Better Pattern

existing = self.env["omni.whatsapp.message"].search(
    [("external_message_id", "=", message_id)],
    limit=1
)

if existing:
    return {"status": "duplicate_skipped"}

self.env["omni.whatsapp.message"].create(values)

Lesson

Every external webhook should have a deduplication key.

Problem 3 — Slow Search Views

Symptom

Odoo list view takes several seconds to load.

Root Cause

Frequently filtered fields are not indexed.

Better Pattern

partner_id = fields.Many2one(
    "res.partner",
    string="Customer",
    index=True
)

Lesson

Index fields used in domains, filters, and joins.

Problem 4 — Custom Module Breaks on Upgrade

Symptom

Module works in one Odoo version but fails after upgrade.

Root Cause

Private/internal methods are used instead of stable ORM patterns.

Bad Pattern

record._some_private_method()

Better Pattern

record.write({
    "state": "confirmed"
})

Lesson

Avoid private methods unless there is no alternative.

Problem 5 — n8n + Odoo Authentication Fails

Symptom

n8n returns 401 errors when calling custom Odoo controllers.

Root Cause

The built-in Odoo node uses JSON-RPC patterns, but custom REST controllers often need explicit HTTP authentication/session handling.

Better Pattern

1. Authenticate against Odoo
2. Store session cookie
3. Call custom endpoint with cookie/header
4. Handle errors explicitly

Lesson

For custom controllers, HTTP Request nodes often give more control than the built-in Odoo node.

Suggested Ending

Backend issues in Odoo are rarely solved by adding more automation.

They are solved by better architecture:

batching
validation
idempotency
indexing
clean ORM usage
proper API boundaries

I use these same patterns in my open-source Odoo automation repo:

https://github.com/gharisj3/omni-odoo-stack

I Replaced a $300/month Automation Stack with n8n, FastAPI, and Docker

Muhammad Gharis — Wed, 10 Jun 2026 20:52:43 +0000

Most small business automation stacks start simple.

A form submission goes into a CRM.

A lead gets scored.

An email or WhatsApp message gets sent.

Maybe an invoice gets extracted with AI.

Then one day, the stack looks like this:

Tool	Monthly Cost	Purpose
Zapier Professional	$49	Workflow automation
Make Core	$29	Secondary automation
OpenAI API	$60+	AI processing
HubSpot Starter	$50	CRM
Typeform	$25	Form intake
Airtable Plus	$20	Data storage
Webhook testing / API tools	$20+	Debugging and routing
Extra automation tools	$30+	Glue logic
Total	$280–$300+/month	Fragmented automation stack

The bigger problem is not only the cost.

The bigger problem is fragmentation.

Zapier triggers Make.

Make calls an AI API.

The AI response gets written to Airtable.

A separate sync pushes data into the CRM.

Errors happen silently.

Duplicate records appear.

Nobody knows where the source of truth lives.

I built omni-odoo-stack to explore a cleaner alternative:

A self-hosted, open-source-friendly automation architecture using:

n8n
FastAPI
Docker
PostgreSQL
Odoo 19 Community
Groq / Llama 3
WhatsApp Cloud API
Nginx

The goal was to show how a business automation stack can be designed with fewer moving parts, better validation, and lower infrastructure cost.

Repository:

github.com/gharisj3/omni-odoo-stack

The Replacement Stack

Paid / Fragmented Tool	Replacement	Cost
Zapier / Make / Pipedream	n8n self-hosted	$0
Raw AI API calls	FastAPI + Pydantic validation	$0
HubSpot CRM	Odoo 19 Community CRM	$0
Airtable	PostgreSQL	$0
Typeform	Custom webhook endpoint	$0
Webhook testing tools	n8n webhook trigger + logs	$0
VPS hosting	Oracle OCI Always Free path	$0

The architecture is designed to run on a single Docker Compose stack.

The exact cloud cost depends on provider limits and usage, but the project is designed around a $0/month infrastructure path using open-source and free-tier-friendly components.

The Architecture

At a high level, the system looks like this:

Inbound trigger
Webhook / form / WhatsApp / API
        ↓
n8n
Workflow orchestration
        ↓
FastAPI middleware
AI processing + validation
        ↓
Groq / Llama 3
LLM intelligence layer
        ↓
PostgreSQL
Data layer
        ↓
Odoo 19 Community
CRM, accounting, inventory, HR
        ↓
Outbound action
WhatsApp reply / email / record update

The most important design decision is separation.

n8n handles orchestration.

FastAPI handles AI and validation.

Odoo handles ERP records.

PostgreSQL stores the data.

WhatsApp handles communication.

No single tool is forced to do everything.

Why n8n Beats Zapier and Make for Technical Users

Zapier and Make are excellent products.

If you are non-technical and need something running quickly, they are useful.

But for developers, agencies, and technical teams, self-hosted n8n gives more control.

Problem 1: Per-Execution Pricing Adds Up

Zapier charges by tasks.

Make charges by operations.

That works for small flows.

But once you start processing thousands of records, invoices, leads, or messages, pricing can grow quickly.

Self-hosted n8n removes per-execution platform pricing.

You still pay for server resources, API calls, and external services, but the workflow engine itself is under your control.

Problem 2: Error Handling Needs to Be First-Class

In real workflows, things fail.

APIs timeout.

AI returns malformed JSON.

A CRM rejects a payload.

A webhook gets sent twice.

A database write fails.

A production workflow needs:

retries
validation
logging
duplicate prevention
alerting
fallback paths

n8n gives you enough flexibility to route failures into dedicated error workflows, log them, and notify the right person.

That matters more than people think.

Problem 3: Your Data Flow Should Be Understandable

In many automation stacks, the logic is spread across five tools.

One part lives in Zapier.

Another part lives in Make.

Another part lives in Airtable.

Another part lives inside the CRM.

Another part lives in an AI prompt.

When something breaks, debugging becomes painful.

A self-hosted stack lets you keep the workflow, API layer, database, and ERP integration closer together.

That makes the system easier to reason about.

Why FastAPI Instead of Calling AI Directly from n8n

The biggest mistake I see in AI automation stacks is this:

Call an LLM directly from a workflow tool and write the raw response into a business system.

That is dangerous.

Example of what not to do:

# Dangerous pattern
response = openai.chat.completions.create(...)

db.insert(response.choices[0].message.content)

The LLM can return anything.

Wrong fields.

Wrong format.

Wrong amounts.

Wrong dates.

Invalid JSON.

Hallucinated values.

If that response goes directly into a CRM, ERP, or accounting system, you are asking for corrupted business data.

So I added a FastAPI middleware layer between the workflow and the AI model.

The middleware validates AI output before anything touches Odoo or PostgreSQL.

Pydantic Validation Layer

Here is a simplified example using Pydantic v2:

from typing import Literal
from datetime import date
from pydantic import BaseModel, Field


class LeadAnalysis(BaseModel):
    score: int = Field(ge=1, le=10)
    summary: str = Field(min_length=10, max_length=500)
    next_action: str
    priority: Literal["low", "medium", "high"]


class InvoiceData(BaseModel):
    vendor: str
    amount: float = Field(gt=0)
    date: date
    currency: str = Field(min_length=3, max_length=3)
    line_items: list[dict]

If the AI response does not match the schema, the middleware rejects it.

That means bad data never reaches the ERP.

FastAPI Endpoint Example

from fastapi import FastAPI, HTTPException, Header
from pydantic import ValidationError
import json

app = FastAPI()


@app.post("/analyze/lead", response_model=LeadAnalysis)
async def analyze_lead(lead: dict, x_api_key: str = Header(...)):
    if x_api_key != API_KEY:
        raise HTTPException(status_code=401, detail="Invalid API key")

    response = client.chat.completions.create(
        model="llama3-8b-8192",
        messages=[
            {
                "role": "user",
                "content": (
                    "Analyze this lead and respond only with valid JSON "
                    f"matching this schema: {LeadAnalysis.model_json_schema()}. "
                    f"Lead data: {lead}"
                ),
            }
        ],
        response_format={"type": "json_object"},
    )

    try:
        raw = json.loads(response.choices[0].message.content)
        return LeadAnalysis(**raw)
    except (json.JSONDecodeError, ValidationError) as exc:
        raise HTTPException(status_code=422, detail=str(exc))

This is the safety layer.

n8n calls FastAPI.

FastAPI calls the AI model.

Pydantic validates the response.

Only validated data is returned to the workflow.

Docker Compose Setup

One Docker Compose file can run the core stack:

version: "3.8"

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - omni_net

  odoo:
    image: odoo:19
    depends_on:
      - db
    environment:
      HOST: db
      USER: ${POSTGRES_USER}
      PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - odoo_data:/var/lib/odoo
      - ./odoo/addons:/mnt/extra-addons
      - ./odoo/config/odoo.conf:/etc/odoo/odoo.conf
    networks:
      - omni_net

  ai-middleware:
    build: ./ai
    environment:
      GROQ_API_KEY: ${GROQ_API_KEY}
      API_KEY: ${AI_API_KEY}
    networks:
      - omni_net

  n8n:
    image: n8nio/n8n
    environment:
      N8N_BASIC_AUTH_ACTIVE: "true"
      N8N_BASIC_AUTH_USER: ${N8N_BASIC_AUTH_USER}
      N8N_BASIC_AUTH_PASSWORD: ${N8N_BASIC_AUTH_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - omni_net

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - odoo
      - n8n
      - ai-middleware
    networks:
      - omni_net

volumes:
  postgres_data:
  odoo_data:
  n8n_data:

networks:
  omni_net:
    driver: bridge

Startup flow:

cp .env.example .env

# Fill in your environment variables

docker compose up -d

Four main services.

One network.

One command.

Workflow 1: Lead Intake

This replaces a typical form + automation + CRM workflow.

WhatsApp message / web form submission
        ↓
n8n webhook trigger
        ↓
HTTP Request → POST /analyze/lead
        ↓
Validate AI response
        ↓
HTTP Request → POST /api/omni/lead
        ↓
Create Odoo CRM lead
        ↓
Send WhatsApp confirmation
        ↓
Log automation event

Old pattern:

Form tool → Zapier → AI API → HubSpot → notification

New pattern:

Webhook → n8n → FastAPI → Odoo → WhatsApp

Workflow 2: Invoice Processing

Invoice text or payload arrives
        ↓
n8n webhook trigger
        ↓
HTTP Request → POST /extract/invoice
        ↓
Pydantic validation
        ↓
Create vendor bill in Odoo
        ↓
Send confirmation
        ↓
Log validation failures if needed

The key point is not AI extraction.

The key point is validated AI extraction.

A malformed invoice should never become an accounting record.

Workflow 3: HR Onboarding

New employee form submitted
        ↓
n8n webhook trigger
        ↓
Create employee in Odoo HR
        ↓
Generate welcome message through FastAPI
        ↓
Send WhatsApp welcome message
        ↓
Notify HR manager
        ↓
Log onboarding event

This shows that the same stack can support sales, finance, and HR workflows.

Error Handling Pattern

The single biggest problem with many automation stacks is silent failure.

A workflow fails.

Nobody notices.

Leads disappear.

Invoices are not processed.

Customers never get replies.

Every serious workflow should have an error path.

Every important workflow step
        ↓
Success path → continue normally
        ↓
Error path → log failure
           → notify admin
           → stop workflow safely

In this stack, failures can be logged into Odoo using omni.automation.log.

They can also trigger WhatsApp or email alerts.

That gives the business visibility into what failed and why.

Five Gotchas That Will Save You Hours

1. n8n's Odoo Node Is Not Enough for Every Case

The built-in Odoo node is useful for standard operations.

But for custom Odoo REST controllers, HTTP Request nodes are often better.

They give you more control over:

authentication
headers
custom endpoints
error responses
payload shape

2. Webhook Idempotency Is Not Optional

Webhook providers may retry failed events.

If you do not check for duplicate message IDs or event IDs, you can create duplicate records.

For lead intake, that means duplicate CRM leads.

For accounting, that could mean duplicate bills.

Always store an external event ID and check it before creating new records.

3. AI Rate Limits Need Workflow Design

Free-tier AI APIs can have rate limits.

Do not assume every request will succeed immediately.

For high-volume workflows, add:

wait nodes
retries
backoff
failure logging
fallback behavior

Rate limits should be treated as part of the architecture, not as an afterthought.

4. Odoo Filestore Persistence Is Easy to Miss

Odoo stores attachments in its filestore.

If you do not mount the filestore properly in Docker, files can disappear when containers are recreated.

Use named volumes for persistence.

5. Docker Services Should Talk by Service Name

Inside a Docker Compose network, services should not call each other using localhost.

Use service names instead:

http://odoo:8069
http://ai-middleware:8000
http://n8n:5678

localhost points to the current container, not another service.

This causes many avoidable connection errors.

Before and After

Metric	Before	After
Monthly platform cost	Around $300	Designed for $0/month infrastructure path
Services to maintain	Many separate tools	One Docker Compose stack
Workflow ownership	Spread across vendors	Self-hosted orchestration
Error visibility	Often limited	Central logs and alerts
Data model	Fragmented	PostgreSQL + Odoo
AI safety	Raw responses	Pydantic validation
Vendor lock-in	High	Lower

Important note:

This does not mean there are no external services.

WhatsApp Cloud API and Groq are still external APIs.

The difference is that the workflow engine, database, ERP, middleware, and deployment structure are controlled by you.

Full Repository

Everything is open source and available here:

github.com/gharisj3/omni-odoo-stack

The repo includes:

Docker Compose setup
Odoo configuration
Custom Odoo modules
FastAPI middleware
Pydantic v2 validators
Importable n8n workflow JSON files
Documentation
Setup notes
Architecture notes

Final Thought

The point of this project is not just to replace paid tools.

The point is to show that business automation needs real backend architecture.

A good automation stack needs:

validation
observability
retry handling
duplicate prevention
API boundaries
secure configuration
persistent storage
clean deployment

That is what turns a demo workflow into something a business can actually rely on.

About Me

I am a backend engineer specializing in:

Odoo ERP customization
n8n workflow automation
Python backend systems
FastAPI middleware
PostgreSQL optimization
WhatsApp Cloud API integration
AI middleware with structured output validation

I have 8+ years of production experience across Odoo, Python, backend automation, and ERP integrations.

I am open to remote contract work involving Odoo modules, n8n automation, AI middleware, PostgreSQL optimization, and backend integrations.

GitHub:

github.com/gharisj3

LinkedIn:

linkedin.com/in/muhammad-gharis-javed-318266202

Project repo:

github.com/gharisj3/omni-odoo-stack

How I Built a Production-Grade Odoo 19 + n8n + WhatsApp + Groq AI Stack on $0 Infrastructure

Muhammad Gharis — Wed, 10 Jun 2026 20:43:03 +0000

If you've ever tried to connect an ERP system to real-time messaging, AI processing, and workflow automation at the same time, you know how quickly the architecture can become messy.

You need an ERP.

You need automation.

You need message intake.

You need AI processing.

You need validation.

You need logs.

You need deployment.

And very quickly, what started as “just connect WhatsApp to Odoo” becomes a full backend system.

I built omni-odoo-stack to explore that exact problem.

It is an open-source ERP automation stack built around:

Odoo 19 Community
PostgreSQL 16
n8n
FastAPI
Groq / Llama 3
WhatsApp Cloud API
Docker Compose
Nginx
Oracle OCI Always Free deployment path

The goal was simple:

Build a realistic ERP + automation + AI middleware architecture using open-source or free-tier-friendly tools.

Repository:

github.com/gharisj3/omni-odoo-stack

What the Stack Does

At a high level, the system connects five layers:

WhatsApp Cloud API
        ↓
n8n workflow orchestration
        ↓
FastAPI + Groq AI middleware
        ↓
Odoo 19 Community
        ↓
PostgreSQL 16

When a WhatsApp message arrives, n8n receives the webhook, extracts the payload, sends the data to FastAPI for AI-assisted analysis, validates the structured response using Pydantic v2, and writes a clean CRM lead into Odoo.

The sender can then receive an automated WhatsApp confirmation.

The important part is not just that the flow works conceptually.

The important part is the separation of responsibilities.

Odoo remains the ERP core.

n8n handles workflow orchestration.

FastAPI acts as the AI safety boundary.

PostgreSQL stores the business data.

WhatsApp handles the communication layer.

Infrastructure Stack

Layer	Tool	Cost
ERP	Odoo 19 Community	$0
Database	PostgreSQL 16	$0
Automation	n8n self-hosted	$0
AI middleware	FastAPI	$0
LLM provider	Groq / Llama 3	Free-tier friendly
Messaging	Meta WhatsApp Cloud API	Free-tier friendly
Reverse proxy	Nginx	$0
Deployment	Docker Compose	$0
Hosting target	Oracle OCI Always Free	$0
SSL	Let's Encrypt	$0

Oracle OCI Always Free is useful for this kind of project because the ARM instance can provide enough resources for a small ERP automation stack without needing a paid VPS.

The repo is designed with OCI deployment in mind, but I am being careful with wording here:

This is a production-style portfolio architecture.

It is not yet being claimed as a fully production-deployed system until the full Docker runtime has been boot-tested on OCI.

That distinction matters.

The Four Custom Odoo Modules

I built four custom Odoo modules from scratch. Each module handles a different part of the system.

1. omni_crm

omni_crm extends crm.lead.

It adds:

Computed lead scoring
AI analysis fields
WhatsApp contact shortcut behavior
Public lead intake API
Demo CRM lead data

The key endpoint:

POST /api/omni/lead

This endpoint allows external systems like n8n to create leads in Odoo through a clean REST-style controller instead of forcing all automation through manual imports or UI actions.

2. omni_whatsapp

omni_whatsapp introduces a new model:

omni.whatsapp.message

It stores WhatsApp message activity inside Odoo.

Fields include:

Phone number
Message body
Direction: inbound or outbound
Status
Linked CRM lead
Message history

It also includes webhook endpoints for Meta WhatsApp Cloud API integration:

GET  /whatsapp/webhook
POST /whatsapp/webhook

The GET endpoint is used for Meta webhook verification.

The POST endpoint receives inbound WhatsApp events.

3. omni_ai

omni_ai introduces:

omni.ai.request

This module logs AI requests and responses.

It stores:

Prompt
Response
Model used
Token usage
Status
Timestamp

It also includes an hourly cron job to process unanalyzed leads.

The idea is simple:

Do not let AI calls disappear into the background.

Every AI action should be visible, inspectable, and traceable inside the ERP.

4. omni_automation

omni_automation introduces:

omni.automation.log

This module tracks end-to-end automation events.

It can be used to monitor:

WhatsApp intake
CRM lead creation
AI processing
Vendor bill automation
HR onboarding automation
Failed workflow events

It includes tree, form, and graph views so the automation layer is visible inside Odoo.

That visibility is important.

Automation without logs becomes a black box.

Why the AI Middleware Lives Outside Odoo

This was the most important architectural decision in the project.

A lot of AI-connected ERP implementations put LLM calls directly inside ERP models or controllers.

That works for demos, but it creates problems later.

Problems include:

Prompts become tightly coupled to Odoo modules
Model changes require ERP code changes
Raw LLM responses can accidentally corrupt ERP records
Validation becomes inconsistent
Token usage is harder to track
Swapping models becomes harder than necessary

So I separated the AI layer into a standalone FastAPI service.

Odoo does not talk directly to the model.

n8n and Odoo communicate with the middleware.

The middleware validates input, calls the LLM, validates output, and only then returns structured data.

Example Pydantic v2 model:

from typing import Literal
from pydantic import BaseModel, Field


class LeadAnalysis(BaseModel):
    score: int = Field(ge=1, le=10)
    summary: str
    next_action: str
    priority: Literal["low", "medium", "high"]

Example invoice extraction model:

from datetime import date
from pydantic import BaseModel


class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    total: float


class InvoiceData(BaseModel):
    vendor: str
    amount: float
    date: date
    currency: str
    line_items: list[LineItem]

Every AI response must match the expected schema before it reaches Odoo.

If the response is missing a field, has the wrong type, or produces an invalid value, the middleware returns an error and the workflow can log the failure.

Odoo never receives unsafe data.

That is the entire point of the middleware.

FastAPI Middleware Endpoints

The middleware exposes these endpoints:

GET  /health
POST /analyze/lead
POST /extract/invoice
POST /generate/message

Example flow:

n8n receives WhatsApp webhook
        ↓
n8n sends payload to FastAPI
        ↓
FastAPI calls Groq / Llama 3
        ↓
Pydantic validates structured output
        ↓
n8n writes validated data into Odoo

The middleware is also easier to evolve independently.

If I want to replace Groq with OpenAI, Claude, or another model provider, I can change the middleware layer without rewriting Odoo modules.

That is the benefit of keeping AI outside the ERP core.

The Three n8n Workflows

The repo includes three importable n8n workflow JSON files.

Workflow 1: WhatsApp Lead Intake

Meta WhatsApp webhook
        ↓
Extract contact and message data
        ↓
Call FastAPI /analyze/lead
        ↓
Validate AI response
        ↓
Create CRM lead in Odoo
        ↓
Send WhatsApp confirmation
        ↓
Log automation event

This workflow is designed for businesses that receive leads through WhatsApp and want automatic CRM creation.

Workflow 2: Invoice Processing

Invoice payload or WhatsApp invoice text
        ↓
Call FastAPI /extract/invoice
        ↓
Validate structured invoice data
        ↓
Create vendor bill in Odoo
        ↓
Send confirmation
        ↓
Log validation failures if needed

This flow demonstrates how AI extraction can be placed behind validation before data enters accounting workflows.

Workflow 3: HR Onboarding

Employee onboarding form
        ↓
Create employee in Odoo
        ↓
Generate welcome message through AI middleware
        ↓
Send WhatsApp notification to employee
        ↓
Notify HR manager
        ↓
Log onboarding event

This workflow demonstrates how the same architecture can support HR automation, not just sales or finance.

Five Things I Learned While Building This

1. n8n's Odoo Node Is Not Enough for Every Case

The built-in Odoo node in n8n is useful, but custom Odoo REST controllers often require HTTP Request nodes.

For custom endpoints, the practical pattern is:

Authenticate with Odoo
Store session/cookie
Call custom REST endpoint
Handle response
Log errors

For complex projects, I prefer explicit HTTP Request nodes because they make the flow easier to debug.

2. WhatsApp Webhook Idempotency Matters

Messaging systems can resend webhook events.

If your workflow creates a CRM lead every time it receives the same message, you can end up with duplicate leads.

The fix is to store and check a unique message identifier before creating records.

In real projects, I would always design the WhatsApp intake layer with duplicate prevention.

3. Pydantic v2 Requires Correct Syntax

Pydantic v2 introduced changes from v1.

If you are using it for AI output validation, make sure your models and validators follow v2 syntax.

The goal is not just to parse JSON.

The goal is to reject unsafe or malformed output before it touches business systems.

4. Odoo Filestore Persistence Is Easy to Miss

Odoo stores attachments in the filestore.

If the filestore is not mounted properly in Docker, attachments can disappear when containers are recreated.

For an ERP system, that is not acceptable.

Docker volumes need to be planned carefully.

5. Docker Services Should Talk by Service Name

Inside a Docker Compose network, services should not call each other using localhost.

Example:

Wrong:
http://localhost:8069

Correct:
http://odoo:8069
http://ai-middleware:8000
http://n8n:5678

This sounds basic, but it is one of the most common causes of connection errors when wiring multiple services together.

Nginx Routing

The stack uses Nginx as the reverse proxy.

The intended routing is:

/       → Odoo
/n8n/   → n8n
/ai/    → FastAPI middleware

Example configuration pattern:

location / {
    proxy_pass http://odoo:8069;
}

location /n8n/ {
    proxy_pass http://n8n:5678/;
    rewrite ^/n8n/(.*)$ /$1 break;
}

location /ai/ {
    proxy_pass http://ai-middleware:8000/;
    rewrite ^/ai/(.*)$ /$1 break;
}

The rewrite rules matter because services like n8n and FastAPI may not expect the external prefix in the request path.

About Groq and Rate Limits

The project is designed to work with Groq and Llama 3-style structured AI tasks.

For real deployments, rate limits should always be checked from the current provider dashboard because limits can change.

In production-style workflows, I would add:

Wait nodes in n8n
Retry logic
Backoff handling
Token usage logging
Fallback behavior
Dead-letter logging for failed events

The goal is not just to call an AI model.

The goal is to make the AI call reliable enough for business workflows.

Repository Contents

The repository includes:

Docker Compose setup
Odoo configuration
Nginx configuration
Four custom Odoo modules
FastAPI AI middleware
Three importable n8n workflows
Environment example file
README
Setup documentation
Architecture notes
Phase notes

Repository:

github.com/gharisj3/omni-odoo-stack

What I Would Do Differently

One thing I would change is boot-testing the full Docker stack before publishing the first public version.

The project has been scaffolded, committed, documented, and syntax-checked.

Python syntax, JSON workflow files, and XML structure were reviewed.

But full runtime verification on OCI is still pending.

That is why I describe this as a production-style architecture rather than claiming it is already production-deployed.

That wording matters.

If you deploy it and hit issues, open an issue on GitHub. I am happy to improve the repo based on real runtime feedback.

Who This Is For

This project is useful for:

Odoo developers learning external automation patterns
n8n users integrating workflows with Odoo
Backend engineers exploring ERP automation
Odoo partners evaluating AI middleware architecture
Agencies that need WhatsApp + ERP workflow examples
Developers looking for a free-tier-friendly ERP automation stack

Why This Matters

Most ERP automation problems are not just workflow problems.

They are backend reliability problems.

You need:

Clean data models
Safe API boundaries
Structured validation
Retry handling
Duplicate prevention
Event logs
Database persistence
Deployment clarity

That is what this project is meant to demonstrate.

Not just that Odoo can connect to AI.

But that AI, automation, messaging, and ERP can be designed as separate layers that work together cleanly.

About Me

I am a backend engineer specializing in:

Odoo ERP customization
Python backend systems
n8n workflow automation
PostgreSQL optimization
WhatsApp Cloud API integration
Claude/OpenAI/Groq AI middleware
Pydantic-validated structured outputs

I have 8+ years of production experience across Odoo v14–v19 and backend automation work.

I am open to remote contract work with Odoo partners, SaaS teams, and agencies.

GitHub:

github.com/gharisj3

LinkedIn:

linkedin.com/in/muhammad-gharis-javed-318266202

Project repo:

github.com/gharisj3/omni-odoo-stack

Anti-Subscription Stack

Muhammad Gharis — Mon, 08 Jun 2026 10:39:38 +0000

Most small businesses do not need another monthly SaaS subscription.

They need simple software that helps them run daily operations:

Save customer records
Track leads
Create invoices
Manage inventory
View sales reports
Export data when needed

That is it.

But somehow, even basic business tools have turned into complicated subscription products with multiple pricing tiers, feature gates, usage limits, and dashboards that small teams never fully use.

This is why I think there is still a strong place for lightweight, self-hosted tools.

Especially tools built with simple stacks like:

Core PHP
MySQL
HTML
CSS
JavaScript

No heavy framework.

No paid API.

No complex deployment.

No monthly platform dependency.

The Problem With Overbuilt Business Software

A small shop, freelancer, salon, repair center, consultant, or local agency usually does not need enterprise software.

They need something like this:

Clients
Products
Invoices
Payments
Tasks
Reports
Users
Settings

But many modern tools are built as if every customer is a funded startup with a large operations team.

The result?

Small businesses often end up with:

Too many features
Too many screens
Too many monthly fees
Too much onboarding
Too much vendor lock-in

For basic workflows, this is unnecessary.

Why Self-Hosted Still Matters

Self-hosted software is not dead.

For many use cases, it is actually practical.

A small business owner or freelancer may prefer self-hosted tools because:

They pay once instead of monthly
They can keep their own database
They can customize the system
They can host it on basic shared hosting
They are not locked into one vendor
They can hire any PHP developer to modify it later

This is especially useful for small internal systems.

A CRM, POS, HRM, invoice system, or reporting dashboard does not always need to be a full SaaS platform.

Sometimes a simple admin panel is enough.

Why I Still Like Core PHP for These Tools

Core PHP gets criticized a lot.

Sometimes fairly.

But for small business tools, it still has advantages:

Runs almost everywhere
Easy deployment
Low hosting requirements
Easy for junior developers to understand
No complicated build step
No framework upgrade pressure
Great for CRUD-heavy systems

A clean Core PHP project can still be professional if it uses:

PDO
Prepared statements
Proper validation
Session security
Organized folders
Reusable components
Clear documentation

Bad PHP is bad.

But simple PHP is not automatically bad.

Example: A Lightweight CRM Structure

A simple CRM does not need to start huge.

It can begin with this:

crm/
  config/
    database.php

  modules/
    clients/
    leads/
    tasks/
    invoices/

  public/
    index.php
    assets/

  database/
    install.sql

  docs/
    installation.md

That is enough for a clean first version.

You can add complexity later only when the business actually needs it.

The Most Useful Modules for Small Businesses

If I were building a lightweight business toolkit, I would start with these modules.

1. Client Management

Store customer details, contact info, notes, and status.

2. Lead Pipeline

Track potential deals from new lead to won or lost.

3. Invoice Generator

Create simple invoices with printable HTML templates.

4. Inventory Tracking

Useful for shops, repair centers, and small product sellers.

5. Task Management

Assign daily work and track progress.

6. Reports

Show monthly sales, pending invoices, top clients, and stock alerts.

Nothing fancy.

Just useful.

The Real Opportunity for Developers

Many developers are chasing big SaaS ideas.

But there is a quieter opportunity:

Build small, reliable tools that solve boring business problems.

Boring problems pay because businesses already understand them.

A shop owner does not need to be educated about inventory.

An agency owner does not need to be convinced about invoices.

A freelancer already understands client tracking.

The problem is obvious.

The solution just needs to be simple and affordable.

What I Am Building

I am working on a lightweight Core PHP business toolkit starting with a CRM starter system.

The goal is to make it:

Simple to install
Easy to customize
Cleanly structured
Useful for real business workflows
Suitable for freelancers and small agencies
Free from heavy framework dependency

I am starting small with:

Clients
Leads
Tasks
Invoices
Dashboard
Reports

Then I plan to expand into POS, HRM, and automation modules.

Final Thought

Not every business tool needs to become a huge SaaS.

Sometimes the better product is:

Smaller
Faster
Self-hosted
Easier to understand
Easier to modify
Cheaper to maintain

That is the kind of software I want to build more of.

If you are a developer, freelancer, or small business owner:

Would you rather use a simple self-hosted tool or pay monthly for a SaaS product with more features than you need?

DEV Community: Muhammad Gharis

The Single All-Purpose AI Agent Is the Wrong Architecture

The problem with one big agent

A better model: agent orchestration

Why specialization matters

The handoff is the real design problem

Example: ERP workflow

Where MCP and A2A-style patterns fit

Frameworks are not the moat

Final thought

AI Agents Should Not Touch Your ERP Directly. Build an Execution Layer Instead.

tags: ai, n8n, fastapi, architecture

The problem

Why direct AI-to-ERP execution is risky

A better pattern: AI execution layer

Where low-code orchestration helps

Example architecture

Demo scenario

What the guardrails check

Why audit logs matter

What this demo is not

Why this matters for ERP systems

GitHub demo

Final thought

I Built a WhatsApp Native Helpdesk for Odoo Community

I Built a WhatsApp Native Helpdesk for Odoo Community

The Problem

What I Built

Why n8n Is Used

Key Features

Ticket Lifecycle

Why This Matters

Repository Structure

Tech Stack

Local Setup

Odoo Installation Flow

n8n Workflow Layer

Security Design

Legal and Compliance Notes

Current Limitations

Why I Built This

GitHub Repository

More From Me

Final Thought

Why ERP Go-Live Fails Without a Command Center

The problem with ERP go-live

What a command center should include

What I built

Who this is useful for

Connect with me

I Built an n8n Client Intake Workflow Pack with Google Sheets CRM and WhatsApp Follow-Up Structure

The problem

The simple workflow idea

What I built

Who this is useful for

Connect with me

25 No-Code Automation Ideas for Freelancers, Agencies and Small Businesses

Common manual problems

Why I created this checklist

Example automation ideas

Who can use this

Connect with me

I Built a Simple AI Lead Qualification CRM Workflow Pack for Freelancers and Small Teams

I Built a Simple AI Lead Qualification CRM Workflow Pack for Freelancers and Small Teams

What the pack includes

Why I built it

Who this is useful for

Connect with me

How I Built an AI Business Automation Workflow Pack with n8n, Google Sheets and JSON Templates

How I Built an AI Business Automation Workflow Pack with n8n, Google Sheets and JSON Templates

The Problem I Wanted to Solve

The Core Stack

What the Pack Includes

Workflow 1: Lead Intake to CRM Tracker

Workflow 2: Contact Form to Google Sheets + Email Alert

Workflow 3: AI Email Reply Draft

Workflow 4: Client Follow-Up Reminder

Workflow 5: Invoice / Payment Reminder

Workflow 6: Support Ticket Triage

Why I Used JSON Templates