Workflow States

EntryLayer workflows define the review lifecycle for submissions. A workflow is made of states, categories, allowed transitions, labels, colors, and project-level behavior such as reopen/send-back support.

When to use this page

Use this page when configuring review states through the Workflow Editor, composing UPDATE_WORKFLOW, applying templates, or explaining why a submission is editable or read-only.

Workflow categories

Category	Purpose	Typical behavior
`editable`	Work can be drafted or corrected	Fields can be edited when permissions allow it.
`in_review`	Work is submitted or under review	Fields are usually read-only for submitters.
`approved`	Work has completed approval	Terminal or near-terminal state.
`rejected`	Work needs correction or has failed review	May send work back to editable state.

State labels are configurable. Categories are the stable behavior anchors that the app uses when deciding editability and transition style.

Persisted and virtual states

Persisted submissions store workflow state metadata. Source-connected projects can also show a virtual not_started row state.

State kind	Description
Persisted workflow state	A saved EntryLayer submission with a configured workflow state id/category.
`not_started` virtual state	A source-backed row visible in the project queue before local workflow tracking has started.

not_started is not the same as a persisted submission status. Once a source-backed row is materialized into a submission, normal workflow behavior begins.

Workflow payload example

{
  "states": [
    {"label": "Draft", "category": "editable", "order_in_category": 0},
    {"label": "Submitted", "category": "in_review", "order_in_category": 0},
    {"label": "Approved", "category": "approved", "order_in_category": 0},
    {"label": "Rejected", "category": "rejected", "order_in_category": 0}
  ],
  "within_category_modes": {},
  "allow_send_back": true,
  "allow_reopen": true
}

Apply a replacement workflow only after reading the existing configuration:

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

CALL ENTRYLAYER.API.UPDATE_WORKFLOW(
  'proj_123',
  PARSE_JSON('{"states":[{"label":"Draft","category":"editable","order_in_category":0}],"within_category_modes":{},"allow_send_back":true,"allow_reopen":true}')
);

Templates and cloning

Command	Use it for	Guardrail
`LIST_WORKFLOW_TEMPLATES`	Find built-in or reusable workflow templates	Read-only and safe to retry.
`APPLY_WORKFLOW_TEMPLATE`	Replace a project workflow from a template	Backend may reject unsafe changes when submissions exist.
`CLONE_WORKFLOW`	Copy workflow config from another project	Copies workflow only, not layout, fields, access, or submissions.

Editing and publish visibility

Workflow changes are project metadata, not form draft content. Form design changes still follow the draft/publish lifecycle described in Form Design Model.

When workflow and form design are changed together, use this sequence:

GET_PROJECT_DRAFT
Apply form design changes.
GET_WORKFLOW
Apply workflow changes.
PUBLISH_PROJECT_DRAFT for user-visible form changes.
Verify with GET_PROJECT_LAYOUT and GET_WORKFLOW.

Audit and history

Workflow transitions are part of the audit trail and include the actor, old state, new state, timestamp, and optional comment. Admin inspection can use App Public Views for workflow state metadata and SQL procedures for project-level workflow configuration.

GET_WORKFLOW
UPDATE_WORKFLOW
LIST_WORKFLOW_TEMPLATES
APPLY_WORKFLOW_TEMPLATE
CLONE_WORKFLOW
APP_PUBLIC.WORKFLOW_STATES