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

Why one form per entity

Other platforms (Airtable, Notion, custom CRMs) let you build N forms per table — "marketing form", "support form", "ops form". WP-PFManagement intentionally allows only one.

Three reasons:

1. Validation lives at the entity, not at the form

If form A enforces "Email required" and form B doesn't, you have inconsistent data. The form is a UI; the validation rules are properties of the entity. Forcing one form per entity makes that relationship 1:1 and removes a class of subtle data bugs.

2. Auditability

"Who edited this record?" is easy to answer when there is one code path. "Was it edited via form A or form B?" is meaningless extra dimensionality.

3. Cognitive load

Most teams that "needed" three forms ended up confused about which form to use when. One form, with conditional visibility for the parts that don't always apply, beats three forms with overlapping fields.

What to do when you really need different inputs in different

contexts

  • For drastically different shapes: that's a different entity (e.g. lead vs customer, not one contact with two forms).
  • For minor variations: use conditional visibility. The form is the same; what renders depends on context.
  • For automated input (no humans): skip the form entirely and POST to the REST API. The API doesn't go through the form layer — it applies entity-level validation directly.