First comes the diagram. Then comes real life.
Everything starts with a BPMN diagram.
It is not a “picture for a meeting.” It is the blueprint of a process. A business analyst or process owner models BPMN so you can see who does what, in what order, under which conditions, where data goes, and where decisions are made.
But a modeled process is not yet a working process. It is an intention.
The interesting part begins when that BPMN process comes alive in a BPMS. What was drawn becomes executable: tasks are assigned, timers fire, gateways choose paths, documents are generated, and notifications are sent.
Then low-code builders digitize the surrounding experience:
- Forms and interfaces are assembled visually — Elementor on the public side, BPMS forms internally.
- Integrations connect the process to CRM, ERP, email, messengers, and other systems.
- Services add capabilities such as PDF generation, 360° tours, and external APIs.
- Portals present process results to customers or employees in a branded, usable form.
The chain is simple:
BPMN (intent) → BPMS (process execution) → low-code builders (digital experience) → integrations (connection to reality)
BPMN describes the process. BPMS executes it. Low-code builders and integrations make it part of the company’s digital ecosystem.
Why BPMS and website builders belong in the same conversation
Platforms such as ELMA and Comindware are BPMS products that support BPMN 2.0 and visual process modeling. Their core job is internal process automation: approvals, document workflows, task routing, and integrations.
Elementor and WPBakery are page builders for WordPress. Their core job is external presentation and customer interaction: landing pages, forms, product showcases, and lead capture.
These worlds are often owned by different teams, but in a real business they are two parts of the same value chain. The public interface collects an intention; the process engine makes sure something useful happens afterward.
Scenario 1: a website form starts a BPMS process
This is the most direct integration scenario.
A visitor submits a request through an Elementor form. Without integration, the data may simply be stored in WordPress and emailed to someone.
When the form is connected to BPMS, the submitted data can automatically start a BPMN process: assign an owner, set a due date, notify the right roles, and record the approval result.
Technically, Elementor can send a webhook after form submission, while BPMS platforms expose REST APIs for receiving data and starting processes.
Elementor is the entry point; BPMS is the engine. The user sees a clean form, while a controlled business process runs behind it.
💡 Important: Elementor itself does not execute business processes. It collects and transmits data. The business rules, routing, and approvals belong in BPMS.
Scenario 2: the BPMS interface is also a builder
BPMS platforms have their own form designers for user tasks. They use the same low-code idea: drag fields and components onto a form, configure their behavior, and connect them to process data.
The audience is different. Elementor is designed for public-facing experiences and brand presentation. BPMS forms are optimized for employees, approvers, and operators who need to complete structured work efficiently.
That distinction matters: the best-looking public interface and the most efficient internal form are rarely the same thing.
Technical boundaries: why one tool should not do everything
Elementor does not execute processes. It has no BPMN engine, task distribution, SLA reminders, process versioning, or complex conditional routing. It is a page and form builder.
BPMS is not a marketing-site builder. Its form designers are optimized for internal efficiency, not for public brand presentation and content marketing.
But they combine extremely well. That is the point of a low-code ecosystem: each tool does what it is best at, and APIs and webhooks connect the layers.
| Criterion | Elementor / WPBakery | BPMS |
|---|---|---|
| Audience | External users and customers | Employees and process participants |
| Main function | Pages, forms, lead capture | Process execution, tasks, approvals |
| Output | Web pages and submitted forms | Process instances, tasks, audit trail |
| Connection | Webhook, REST API | REST API and integrations |
What this means for us
This directly affects how we build digital products.
Do not sell “just a website.” If an Elementor form only sends an email, the lead can disappear. If it starts a managed BPMS process, the lead enters a traceable system.
Do not treat BPMS as an isolated IT project. It is a business tool, and business users can participate directly in configuring processes.
Presentation quality is part of the process. Professional 360° tours and PDF publications are not decoration; they shape customer decisions and the quality of subsequent interaction.
The strongest result is the connection. A branded Elementor front end + a controlled BPMS process + high-quality digital content gives more value than any of those tools alone.
