Record

A record is one row of an entity. If the entity is contact, a record is one specific contact.

Anatomy

Every record carries:

• id — auto-increment primary key, scoped to the entity's table.
• uuid — globally unique identifier (UUIDv7), used in REST and in event payloads. Stable even if the id changes between environments.
• Field values — one per field in the entity's schema. Typed (a Number field gets an int, a Date gets a date, a Relation gets a foreign uuid).
• created_at, updated_at — UTC timestamps, written automatically.
• created_by, updated_by — WP user ids of who made the change.

Plus optional fields if your entity enabled them:

• Revisions: every save creates a row in wp_pfm_revisions so you can see who changed what and when, and roll back to a previous version of a record.
• Approvals: changes go to a pending queue and require a second user with a higher capability to approve before they take effect.

Querying records

Three ways:

1. List view (humans) — what you see in the admin.
2. EQL — the structured query language used by lists and workflows. See EQL for the grammar.
3. REST API — GET /wp-json/pfw-management/v1/records/{entity}?eql=.... The agent's record.query tool wraps this.

Validation

Validation runs at SAVE time (both via the form and via the REST API). Field-level validators (e.g. "email must look like an email") run first; if any fail, the save is rejected with a structured error list. Cross-field validators (e.g. "end date must be after start date") run next as PHP predicates registered by the entity.

If validation passes, the save goes through, the appropriate event fires, and any workflows listening to the event begin.