Why three plugins, one suite

Setyenv is intentionally split into separate pieces — three WordPress plugins plus an open-source runner — rather than one big one. The split matches the way most teams want to adopt this kind of tooling — usually one piece at a time.

The three roles

WP-PFWorkflow is the engine. It runs what happens when X. It has triggers, conditions, actions, and a real execution engine with queue, retry, replay, timeline and idempotency. It can stand on its own — many users only ever need this one.

WP-PFAgent is the conductor. It turns a sentence ("when a WooCommerce order is over 200 EUR, draft a thank-you note with the customer's history") into a workflow in the Engine. It uses the Engine's REST surface as its toolbox. It needs Workflow installed to be useful.

WP-PFManagement is the low-code platform. Without writing code you model your processes, assets and services — entities, fields, forms, lists, permissions and business rules — so you can build real apps (ITSM, CRM, asset/CMDB, service desk) inside WordPress instead of an external SaaS. Workflow listens to its record events as native triggers, and the Agent can design whole schemas from a sentence.

wp-executor is the open-source runner. It takes your workflow events and runs them on your own machine, in your own tools — shell commands, scripts, the filesystem, your local apps and integrations — bridging WordPress automation with your own environment (it polls the Engine's queue over a secure HMAC channel). A standalone binary, dual-licensed MIT/Apache-2.0 and free on GitHub; no Setyenv license is needed to run it, only the WordPress side that publishes work to it.

Why split this way

1. You can adopt one piece at a time. The pack gives you all of it, but nothing forces you to use it all at once — many teams start with Workflow, run a few automations, then bring in Management and the Agent as they need them.
2. One pack, one price. The two commercial plugins are licensed together as the Setyenv PF Pack — one subscription, monthly or annual, by the number of domains you run it on. The Agent is included free, and the runner is open source. (See Licensing model.)
3. Each piece is observable. A workflow is a diagram you can open and read. An agent's actions are confirmed before they happen and recorded after. An entity is a SQL row you can SELECT from your own database. Whatever the plugin is doing on your behalf, you can see it.

When all three together

The most interesting use case is the Agent driving Workflow that reacts to Management entities. You describe a process in natural language → the Agent designs the entity, generates a form, wires a workflow that triggers on record events, and confirms before activating. From sentence to working app in minutes, with you confirming every side-effect along the way.