DEV Community: Federico

From Google Sheets to WhatsApp and Monday.com: Building a WordPress Plugin That Connects Elementor Forms to an Automated Webhook Pipeline

Federico — Thu, 09 Jul 2026 14:22:19 +0000

The Problem

Our company uses Monday.com as our CRM. We also rely heavily on Elementor Pro forms on our WordPress site to collect leads, registrations, and inquiries. The issue? Data lived in two separate worlds — form submissions landed in Google Sheets, and there was no automated way to push them into our CRM or notify our team in real time.

Operators had to manually copy data from Google Sheets into Monday.com and then separately reach out to leads via phone or WhatsApp. It was slow, error-prone, and wasted hours every week.

We needed a bridge.

The Infrastructure

The solution relies on four components working together:

WordPress + Elementor Pro — Forms are built visually with Elementor. The plugin hooks into Elementor's submission lifecycle to capture data before it hits any other handler.
Custom WordPress Plugin — Developed from scratch. It intercepts form submissions, prepares the payload, and fires a POST request to an n8n webhook.
n8n (self-hosted via Docker) — Deployed on a private server. It receives the webhook, processes the data, and routes it through different branches based on the form configuration. n8n acts as the orchestration layer.
OpenWA (self-hosted via Docker) — An open-source WhatsApp API gateway deployed as a separate Docker container. n8n talks to OpenWA's HTTP API to send templated messages automatically to the phone number submitted in the form.

Every piece of the pipeline is self-hosted. No third-party SaaS for the automation layer, no reliance on external WhatsApp business APIs — everything runs on our own infrastructure.

How the Plugin Works

Phase 1: Google Sheets Only

The plugin started simple. When an Elementor form was submitted, the plugin would:

Hook into elementor_pro/forms/new_record
Extract the form fields and their values
Append a row to a Google Sheet via the Google Sheets API

This worked fine for a while. But soon the team needed more.

Phase 2: Adding WhatsApp Notifications

We added an n8n webhook step. Now, on submission, the plugin fires a POST request to an n8n workflow endpoint. The workflow:

Receives the form data (name, email, phone, message, etc.)
Calls OpenWA's REST API with the recipient's phone number and a pre-built message template
OpenWA delivers the message via WhatsApp automatically

The beauty of this is that any Elementor form with a phone field can trigger a WhatsApp notification — no extra configuration needed beyond setting up the workflow once in n8n.

// Simplified example of the plugin's webhook call
add_action('elementor_pro/forms/new_record', function ($record, $handler) {
    $form_data = $record->get('fields');
    $webhook_url = get_option('n8n_webhook_url');

    wp_remote_post($webhook_url, [
        'body' => json_encode([
            'form_id' => $record->get_form_settings('id'),
            'fields'  => $form_data,
            'actions' => ['whatsapp', 'monday'], // configured per form
        ]),
        'headers' => ['Content-Type' => 'application/json'],
    ]);
}, 10, 2);

Phase 3: Adding Monday.com Integration

This was the most complex part. The requirement was: when a form is submitted, create or update an item in a specific Monday.com board, mapping form fields to board columns.

The challenge? Monday.com boards can have dynamic columns, and the target board might not have the exact columns we needed. So the plugin's n8n workflow implements a self-healing column mapping:

Check if the group exists — If not, create a new group on the board
Check if the required columns exist — Iterate over the form fields and, for each one, verify a matching column exists on the Monday.com board
Create missing columns — If a column doesn't exist, create it with the appropriate type (text, date, phone, email, etc.)
Map form fields to columns — Build a column values payload matching the form data to the board columns
Create the item — Insert the item with all mapped values

This process was completely automated with n8n nodes using monday pre-built blocks

Why I Kept the Excel-Like Logic in the Plugin

You might wonder: shouldn't the column mapping logic live in n8n instead of the WordPress plugin?

Ideally, yes. But there's a practical reason it stayed in the plugin. The original Google Sheets implementation already had a robust field-to-column mapping system baked in. When we added Monday.com, it was faster and safer to reuse that same mapping logic in the plugin rather than duplicating it in n8n.

The plugin sends the already-structured payload to n8n, which acts more as a router and action executor — it doesn't need to understand the form structure. This keeps the n8n workflows simpler and more generic: they just receive a well-defined JSON object and act on it.

Could the logic be moved to n8n? Absolutely. But unless there's a compelling reason (like supporting multiple sites with different plugins), the current approach works well and keeps complexity centralized in one place.

The Full Flow

Here's the complete lifecycle of a form submission:

User submits Elementor form
        │
        ▼
WordPress plugin hooks into elementor_pro/forms/new_record
        │
        ├──► Google Sheets (append row — original behavior)
        │
        └──► POST to n8n webhook
                  │
                  ├──► Branch: WhatsApp
                  │         └──► OpenWA API → WhatsApp message to lead
                  │
                  └──► Branch: Monday.com
                            ├──► Check/create group
                            ├──► Check/create columns
                            └──► Create item with mapped values

Each form in Elementor can be configured to enable WhatsApp notifications, Monday.com sync, or both — all from a simple settings panel in the plugin.

What I Learned

Self-hosted automation is liberating. Running n8n and OpenWA on our own Docker infrastructure means no per-message fees, no rate limits imposed by a third party, and full control over the data pipeline.

Bridge technologies are the real heroes. WordPress doesn't need to know about Monday.com's GraphQL API. OpenWA doesn't need to know about Elementor forms. n8n sits in the middle and translates between all of them, and the plugin just speaks one language: HTTP.

Start simple, then expand. The Google Sheets integration was built in a day and delivered immediate value. WhatsApp and Monday.com came later, each adding a layer of automation that compounded the ROI. If we had tried to build the whole thing at once, we'd probably still be designing it.

Future Improvements

Move the column mapping logic to n8n for multi-site support
Add two-way sync — when an item updates in Monday.com, notify the WordPress user
Template-based messages — let admins edit WhatsApp message templates from the WordPress admin panel
Error handling dashboard — log failed webhook calls and retry with a queue system

Built with WordPress, Elementor Pro, n8n, OpenWA, and Monday.com — all glued together by a custom plugin and a lot of JSON.

Building a Modular Panel-Based Management Software with React 19, TypeScript, and Dockview 5

Federico — Thu, 09 Jul 2026 14:01:16 +0000

Building a Modular Panel-Based Management Software with React 19, TypeScript, and Dockview

Introduction

This article documents my experience designing and developing the frontend of a management software for a manufacturing company in the leather processing industry. The company had been using a legacy application developed over 20 years ago with outdated technologies — a slow, insecure Windows XP-era tool with a dated interface that had become increasingly difficult to maintain.

The goal was clear: replace the old system with a modern, web-based solution without disrupting the established operational workflows that operators had been using for decades.

The Project at a Glance

The client needed a fast, modern web application accessible from any browser. The key requirements were:

Modular panel interface: Operators needed to work with multiple modules simultaneously, just like a desktop environment
Modern UI: Clean, intuitive, and responsive with dark/light theme support
Performance: Low latency for loading and saving data
Security: Two-factor authentication and granular permission management
i18n: Full support for Italian and English
Keyboard shortcuts: Speed up frequent operations like create, edit, save, and cancel

Tech Stack

The frontend was built entirely with modern tools:

Layer	Technology
UI Framework	React 19
Language	TypeScript 5.9 (strict mode)
Build Tool	Vite 7
Router	react-router v7
Server State	TanStack React Query 5
Client State	Zustand 5
HTTP Client	Axios 1
UI Library	Material-UI (MUI) 7
Panels	Dockview 5
Forms	react-hook-form
Tables	material-react-table (MRT)
i18n	i18next + react-i18next
Notifications	notistack
Dates	dayjs

The backend (handled by a colleague) was built with Symfony (PHP), MySQL, and RESTful APIs with JWT cookie-based authentication.

Architecture: The Modular Panel System

The core of the application is a Dockview container that hosts all open panels — think of it as Visual Studio Code's tab system but for a business management app. Each panel corresponds to a specific business entity (contacts, batches, orders, etc.) and is built from three reusable generic components.

The Three Generics

GenericPanel — The container component providing panel context and layout structure (list on top, form on bottom).
GenericList — A wrapper around material-react-table offering selection, sorting, and filtering out of the box.
GenericForm — The most complex component: it orchestrates the full CRUD lifecycle including button states, permissions, keyboard shortcuts, and confirmation dialogs.

This abstraction was a game-changer for productivity. Instead of writing CRUD logic from scratch for each of the 50+ panels, I defined these three generics once, and each specific panel only declares the variable parts: table columns, form fields, API endpoint, and translations.

src/
├── apps/
│   └── default/          # Entry point (main.tsx, provider hierarchy)
├── features/
│   ├── auth/             # Login, OTP, logout
│   ├── authz/            # Permissions (resource-action based)
│   ├── panels/           # Dockview panels (the heart of the app)
│   ├── password-reset/
│   ├── profile/
│   ├── routing/          # Router and guards
│   ├── search/           # Global search
│   ├── settings/
│   └── user/             # User and role management
└── shared/
    ├── api/              # Axios layer, useApi, query keys
    ├── ui/               # Reusable UI components
    ├── themes/           # MUI light/dark themes
    ├── helpers/          # Utilities (language detection)
    └── interfaces/       # Shared TypeScript interfaces

Factory Pattern for API Hooks

One of the most impactful patterns I implemented was a Factory Method for generating CRUD API hooks. The createPanelApiFactory function automatically generates five TanStack Query hooks for any REST endpoint:

export const batchApi = createPanelApi<IBatch>({
  baseEndpoint: "/batch",
  queryKey: "BATCH"
});

This single declaration produces:

useGetList() → GET /batch
useGetDetail(id) → GET /batch/:id
usePost() → POST /batch
usePut() → PUT /batch/:id
useDelete() → DELETE /batch/:id

Each hook handles caching, automatic cache invalidation after mutations, and error handling. The factory completely abstracts HTTP complexity so the developer can focus on business logic.

Isolated State Management with Zustand

A tricky architectural challenge: users can open multiple panels of the same type simultaneously. Each instance must maintain its own independent state.

The solution combines React Context with a Zustand factory. Every panel gets wrapped in its own React context, inside which a dynamic Zustand store is instantiated:

Panel "Batches" #1 — context #1 → Zustand store #1 — { selectedId: 5, formEnabled: false }
Panel "Batches" #2 — context #2 → Zustand store #2 — { selectedId: 12, formEnabled: true }
Panel "Contacts" — context #3 → Zustand store #3 — { selectedId: 3, formEnabled: false }

This guarantees complete state isolation: modifying a form on one panel never interferes with another.

Cross-Panel Communication

Here's my favorite feature. Imagine an operator is in the Create Order form and needs to select a contact that doesn't exist yet. They press Enter on the contact select field, and the system opens the Create Contact panel automatically. Once they save the new contact, the ID flows back to the original order form — without the user having to re-select anything.

This was implemented using React Query's cache as a communication bus. The creating panel writes the newly created entity ID to a special query key (LAST_CREATED), and the receiving panel subscribes to changes on that key via a useSubscribePanel hook. No direct coupling between panels — the architecture stays modular and decoupled.

Keyboard Shortcuts

To match the operators' muscle memory from the old system, I implemented keyboard shortcuts:

Key	Action
F4	Enable editing on selected item
F9	Create new item
F10	Save current form
Esc	Cancel operation / close floating panel

Shortcuts only fire on the focused panel to avoid conflicts when multiple panels are open.

Permission System — Three Layers of Security

The authorization system operates on three levels:

Component level — Buttons and sections are conditionally rendered based on permissions.
Hook level — Permissions are verified before executing any operation.
Engine level — A centralized policy checker enforces rules globally.

Users belong to groups (Admin, Staff), and each group has specific permissions on business resources (contacts, production, orders, etc.). The menu and routes are filtered automatically — operators only see what they're allowed to use.

Results

After three months of development, the frontend reached:

50+ functional panels across 10 business areas
35,000+ lines of TypeScript code
3 reusable generic components (GenericPanel, GenericList, GenericForm)
Full CRUD on every entity
Cross-panel communication via React Query cache
Keyboard shortcuts for all CRUD operations
Italian/English i18n with real-time switching
Light/dark theme persisted in user preferences
Granular permission system with three-level verification

Challenges Faced

No project is without its struggles. Here are the main ones:

Unclear requirements. The client provided the legacy software without a structured analysis. Many features were discovered and implemented day by day. I often had to infer expected behavior by observing the old system.

Backend coordination. APIs frequently returned data in different formats than agreed upon, or threw unexpected errors that required last-minute fixes.

Domain complexity. The leather processing industry has highly specific production workflows. Understanding batch management, tanning stages, product composition, and leather logistics was essential to building an interface that truly matches how operators work.

Technical challenges. Implementing isolated panel state, cross-panel data passing, concurrent cache synchronization, and multi-panel keyboard shortcuts — each problem pushed me to find creative solutions.

What's Next

The modular architecture makes it easy to extend. Future possibilities include:

Automated tests — Unit, integration, and E2E tests for robustness
Performance optimizations — Virtual scrolling, lazy loading, query optimization
Custom layouts — Let users save their own panel configurations
AI assistant — A chatbot that can perform CRUD operations via natural language

Final Thoughts

Working on this project was an incredible learning experience. Having full autonomy over the frontend architecture meant every decision — from library choices to design patterns — had a direct impact on the final product. The result is a production-ready application used by real operators every day, replacing a two-decade-old system with a modern, performant, and maintainable solution.

This article is based on my graduate thesis project for the Web Developer Full Stack program at ITS Digital Academy Mario Volpato.