Skip to main content
A FieldRule stores a workspace-scoped AI grounding configuration for a single column (field_key) within a record root (e.g. invoices, companies). It carries three optional JSONB payloads — rules_config, formula_config, and format_config — each represented as a rich-text document tree (Tiptap/ProseMirror) or a plain-text prompt string. The entity is owned by the user: it is created or replaced via PUT /v1/field-rules/:root/:fieldKey and soft-deleted via DELETE on the same path. A partial unique index on (workspace_pk, root, field_key) WHERE deleted_at IS NULL enforces one active rule per field per workspace.
Internal object. Not currently exposed on the public REST API. The operations below describe the intended contract.

API operations

Data model

Attributes

Relationships

System-computed

  • field_rule_id: generated by gen_random_uuid() on insert; never client-provided
  • created_at: set by MikroORM onCreate hook to new Date() at insert time
  • updated_at: set by MikroORM onCreate and onUpdate hooks; reflects last write timestamp
  • deleted_at: written by FieldRuleService.deleteRule() for soft deletion; not a client-settable field
  • Partial unique index idx_field_rules_workspace_root_field_key enforces exactly one active rule per (workspace, root, field_key) when deleted_at IS NULL; soft-deleting a rule releases the slot for re-creation
  • Upsert semantics in FieldRuleService.upsertRule(): finds existing active rule by (root, field_key, workspace); updates in-place if found, creates a new row otherwise
  • On upsert, FieldRuleService.fireAndForgetRecompute() is triggered automatically to re-run AI extraction for affected records — this is a side effect not visible in the API response

Example

Source: apps/api/src/database/entities/FieldRule.ts · domain: workspace · tier: Infrastructure