Workflows

A workflow is a directed graph of nodes that runs when its trigger fires. Stored as a WordPress custom post type (pfw_workflow), so it gets WP's versioning, search, drafts, revisions and capability checks for free.

Anatomy

Every workflow has exactly one of each:

• Title — human-readable, free-form.
• Slug — URL-safe identifier, auto-derived from title but editable. Used in the REST API to reference the workflow.
• Status — active or inactive. Only active workflows run.
• Trigger — exactly one node tagged as a trigger.
• Graph — zero or more action / condition / control-flow nodes wired with edges.

And optionally:

• Description — internal notes, not shown to end users.
• Tags — for filtering in the workflow list.
• Capability — minimum WP capability required to view or edit the workflow (default pfw_manage_workflows).

Lifecycle

draft (when first created) → active (when you toggle the switch) → paused (manual deactivation, can re-enable any time) → archived (soft-deleted; can be restored from the WP trash).

Versioning

Every save creates a WordPress revision. You can view the history under Setyenv → Workflows → [your workflow] → Revisions and roll back to a previous version. The active version (the one the engine runs) is always the latest published revision.

Capability model

• pfw_manage_workflows — required to create, edit, delete a workflow. Mapped by default to manage_options (admin).
• pfw_run_workflows — required to manually trigger a workflow. Mapped by default to edit_posts (editor).
• pfw_view_executions — required to browse the execution timeline. Mapped by default to pfw_manage_workflows.

Override these in wp-config.php or via the pfw_capabilities filter to fit your role setup.