Let me trace a single event through a WordPress site that runs Project Flash — one WooCommerce order, all the way to a file generated on the company's own machine — because the interesting part isn't any one plugin, it's that the whole thing happens inside the site's own WordPress, with the data never leaving it.
1. The order (WooCommerce)
A customer buys a product. That's a native WordPress event — no connector polling "new order" from a cloud. Everything downstream hears it directly.
2. It becomes a ticket (WP-PFManagement)
The order opens an incident in a ServiceNow-style low-code platform: a typed record with fields that mean something (impact, status, the linked order, the customer). It lands in a real service desk — a queue with row- and field-level permissions — not a spreadsheet. Agents see their tickets; nobody sees fields they shouldn't.
This is the low-code layer: entities, forms, business rules, all modelled without writing code, running in the same wp-admin the team already uses.
3. A workflow reacts (WP-PFWorkflow)
The new incident is an event, and a visual workflow is listening. On a real canvas — triggers, conditional branches, function calls, error boundaries — the workflow decides what happens: check the order, branch on product and customer, and if the situation calls for it, ask for help.
Because it's a graph and not a linear recipe, the awkward cases (an API is down, the product is out of policy) are just other edges you drew, not walls you hit.
4. The AI agent triages (WP-PFAgent)
For the judgment call, the workflow hands off to the AI agent (open source, bring-your-own-LLM-keys). It reads the ticket and the order, classifies the issue, and proposes the next step against the platform's documented schema — and it asks for confirmation before it writes anything. It's leverage, not a black box: what it produces are real records you can inspect.
5. The work leaves PHP (wp-executor)
The resolution needs a file generated on the company's own machine — an RMA document, say. WordPress can't (and shouldn't) do that inside a web request, so it publishes a job to a queue. A single-binary Rust worker running on the company's own hardware leases the job, runs it under a local allowlist, generates the file, and reports back. Nothing transited a third party; the worker only ever talked to this WordPress.
6. Resolution
The generated file attaches to the ticket, a business rule closes the loop, and the customer gets their answer. One event, five plugins, one database — the customer's own.
Why do it this way
Every step above ran as a plugin inside the site's own WordPress. No external SaaS in the path, no per-task billing, no telemetry — the order, the ticket, the workflow state, the AI's output and the executor's result all live in one database the business owns.
Two of the five are open source and free (the AI agent, GPL-2.0; the Rust worker, MIT/Apache-2.0). The workflow engine and the low-code platform are commercial — licensed per domain, not per task, and refundable — and on sale now: register, buy and self-host today.
See the whole thing as real screenshots at project-flash.com/use-case. Docs at /docs.
Happy to answer anything about any hop in the chain — the data model, the workflow graph, the REST+HMAC queue, or the executor's allowlist.
Top comments (0)