Skip to main content

Workflow Forms & Validation

Client validation

Definition creation checks only that key and name are truthy before submission. Delegation suppresses submission when the prompt returns blank. Approval and rejection have no user input validation because comments are fixed.

Service validation

The service trims and requires definition key/name, rejects duplicate tenant keys, validates approver type, applies defaults to unrecognized step type/mode, requires a published definition to start, and requires running instances with pending tasks for decisions. Delegation additionally requires toUser. Missing tenant context is translated to a bad-request response.

Presentation limitations

Action functions do not implement local error handling or field-level error rendering. The shared page loader shows an error/retry state for initial loads, but mutation failures do not have a verified page-specific recovery message. There are no disabled states, confirmation steps or backend validation summaries.

Requires Confirmation

Required field constraints, accessible error association, publish validation and consistent mutation-error handling require confirmation.

Source References

  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsx
  • microservices/src/workflow-service/Application/Commands/WorkflowDefinitionCommands.cs
  • microservices/src/workflow-service/Application/Commands/WorkflowInstanceCommands.cs
  • microservices/src/workflow-service/Api/EndpointResults.cs

See Also

Keywords

Workflow forms, validation, error handling.

Revision Information

Draft source-backed documentation reviewed on 2026-07-20; next quarterly review is 2026-10-20.