Workflow Validation
Summary
Validation is distributed across command methods, domain methods, state guards and database constraints. No WorkflowValidator or validation-library registration exists.
Input validation
Creation requires key and name. Approver type must parse to a supported enum. Unknown or missing step type/mode falls back to defaults. Start requires definition identifier or key. Delegation requires a destination.
Domain validation
Definition creation repeats key/name checks. Published versions reject step replacement. Publication requires a current draft with at least one step.
State validation
Approve, reject and delegate require a Running instance and Pending task. These checks return conflict results for duplicate or late decisions.
Persistence validation
Unique indexes protect tenant/key and definition/version combinations. Required columns and maximum lengths apply at persistence time.
Error translation
Application result categories become success, bad-request, not-found or conflict responses. Some persistence and serialization errors are not explicitly normalized.
Limitations
There is no declarative validator, step-order range validation, duplicate step validation, condition-operator whitelist, assignment completeness check, caller-assignment validation or concurrency validation.
Requires Confirmation
Validation ownership, standardized error details and stricter authoring rules require confirmation.
Source References
microservices/src/workflow-service/Application/Commands/WorkflowDefinitionCommands.csmicroservices/src/workflow-service/Application/Commands/WorkflowInstanceCommands.csmicroservices/src/workflow-service/Domain/Workflow/WorkflowDefinition.csmicroservices/src/workflow-service/Api/EndpointResults.csmicroservices/src/workflow-service/Infrastructure/WorkflowDbContext.cs
Related Articles
See Also
Keywords
Workflow architecture, approval engine, Workflow Service, technical foundation.
Revision Information
- Status: Draft
- Last reviewed: 2026-07-20
- Next review: 2026-10-20