Setyenv · Docs
  • English
  • Spanish
  • Chinese
  • Japanese
  • Arabic
  • German
  • French
  • Hindi
  • Indonesian
  • Italian
  • Dutch
  • Portuguese
  • Russian
  • Turkish

Events

Every CRUD operation on a record emits an event. Events are the primary mechanism by which WP-PFWorkflow reacts to data changes — and by which custom PHP can subscribe (add_action('pfm.record.created', ...)).

Event taxonomy

Event nameFires whenPayload
pfm.record.createdA new record is saved successfully{ entity, record, user_id }
pfm.record.changedAn existing record's field values change{ entity, record_before, record_after, diff, user_id }
pfm.record.deletedA record is deleted{ entity, record, user_id }
pfm.entity.schema_changedThe Reconciler applies a schema change{ entity, operations, user_id }

Where entity is the entity slug (e.g. "contact") and record is the full record as a structured object.

Two scopes per event

Each event fires twice:

  1. Generic: pfm.record.created — fires for ANY entity. Useful for cross-cutting concerns (audit logging, analytics).
  2. Entity-scoped: pfm.contact.created — fires only for that specific entity. Useful for workflows that care about one entity type.

Subscribe to whichever scope matches your need.

Workflow trigger nodes

In WP-PFWorkflow, the WP-PFManagement category has three trigger nodes:

  • pfm.record.created — entity slug dropdown filters which entity's creations fire this workflow.
  • pfm.record.changed — entity dropdown + optional field-level filter (e.g. "only when status changes").
  • pfm.record.deleted — entity dropdown filters which entity's deletions fire this workflow.

The trigger payload is the record (after the change, if applicable), the diff (for changed), and the acting user.

Custom PHP subscription

Standard WordPress hooks:

add_action('pfm.contact.created', function ($entity, $record, $user_id) {
    // do something
}, 10, 3);

Fires synchronously inside the save request. Don't do heavy work here — push it to a workflow or to a queued job.

Idempotency

Events fire ONCE per logical change. The same record.changed event will not fire twice for the same change even if multiple code paths trigger the save (the engine dedupes within a request).