Form Design Model

EntryLayer form design is versioned. Builders edit a draft, then publish the draft when the form should become visible to users.

When to use this page

Use this page when Cortex or an admin is managing build-seat work: creating sections, moving fields, setting validations, creating rules, managing primary keys, or deciding whether a whole-draft replacement is safe.

Draft vs published layout

Concept	Meaning	SQL API
Published layout	Current user-facing form design	`GET_PROJECT_LAYOUT`
Draft	Editable design that may differ from published layout	`GET_PROJECT_DRAFT`
Form version	Versioned container for structure and metadata	`LIST_PROJECT_VERSIONS`, `REVERT_PROJECT_VERSION`
Publish	Promotes draft to the user-facing layout	`PUBLISH_PROJECT_DRAFT`
Discard	Removes unpublished draft changes	`DISCARD_PROJECT_DRAFT`

Structure hierarchy

Project
  FormVersion
    DraftStructure
      Section
        Row
          Field
      Rules

Stable identifiers matter for automation. Use returned section_id, row_id, field_id, and rule_id values instead of matching by title.

Field registry rules

Rule	Why it matters
Field ids are stable	Cortex can safely reference a field across validation, rule, move, and publish calls.
Field ids are never reused	Archived fields should not be treated as available ids for new fields.
`field_type` is immutable after creation	Type changes require creating a replacement field and archiving or hiding the old one.
Source-backed fields are protected	Do not archive source-backed fields unless the SQL API explicitly allows the operation.

Safe editing sequence

CALL ENTRYLAYER.API.GET_PROJECT_DRAFT('proj_123');

CALL ENTRYLAYER.API.CREATE_FIELD(
  'proj_123',
  PARSE_JSON('{"title":"Reviewer Comment","field_type":"Text","description":"Notes for approval"}'),
  PARSE_JSON('{"available":true}')
);

CALL ENTRYLAYER.API.SET_FIELD_VALIDATION(
  'proj_123',
  'field_reviewer_comment',
  PARSE_JSON('{"required":true}')
);

CALL ENTRYLAYER.API.CREATE_FORM_RULE(
  'proj_123',
  PARSE_JSON('{"name":"Require comment for open items","enabled":true,"expression":"{Status} = \"Open\"","target_field_id":"field_reviewer_comment","target_property":"required"}')
);

CALL ENTRYLAYER.API.PUBLISH_PROJECT_DRAFT('proj_123');

Validations

Validations are field metadata, not a separate table. Common validation/config keys include:

Field behavior	Common keys
Required fields	`required`
Numeric limits	`min`, `max`, `precision`, `format`
Dates	`include_time`, date defaults
Select values	`values`, `allowed_values`, cascading parent settings
Defaults and read-only fields	`default_value`, `read_only`, formula metadata

Use CLEAR_FIELD_VALIDATION to remove selected validation keys safely. Publish the draft before expecting users to see validation changes.

Form rules

Form rules can target field visible, enabled, or required behavior. The SQL API validates target field ids, target properties, expression syntax, enabled state, and unknown field references.

Use GENERATE_FORM_RULE for assistance, but do not include PII, source row values, submission values, credentials, or secrets in the prompt.

Whole-draft replacement

SAVE_PROJECT_DRAFT is powerful and should be reserved for complete design replacement. Prefer targeted procedures for small changes:

CREATE_SECTION, UPDATE_SECTION, REMOVE_SECTION, MOVE_SECTION
CREATE_ROW, UPDATE_ROW, REMOVE_ROW, MOVE_ROW
CREATE_FIELD, UPDATE_FIELD, ARCHIVE_FIELD, MOVE_FIELD
SET_FIELD_VALIDATION, CLEAR_FIELD_VALIDATION, SET_PRIMARY_KEYS
CREATE_FORM_RULE, UPDATE_FORM_RULE, SET_FORM_RULE_ENABLED, DELETE_FORM_RULE

When using SAVE_PROJECT_DRAFT, pass options.expected_updated_at from GET_PROJECT_DRAFT to avoid overwriting someone else’s draft work.