Workflow
Summary
HR Suit contains a Transitional workflow and approval engine. It supports tenant-scoped definitions, immutable published versions, ordered conditional stages, user/role/manager/HR/admin assignments, pending task worklists, approval, rejection, delegation, audit/timeline history and six relayed lifecycle events.
Business Purpose
Provide reusable approval routing for business records without embedding every approval chain inside the originating module.
Actors
Workflow authors, approvers, delegates, process initiators, tenant administrators, product owners, support teams and owners of connected business modules.
Business Flow
A definition is authored as a draft, published, and used to start an instance. The engine opens the first applicable stage, creates tasks, advances after the stage is approved, rejects the instance on any rejection, or completes after the final applicable stage.
Audience
Business users, managers, HR administrators, product owners, implementation partners, QA, support, security reviewers and solution architects.
Overview
Five development definitions demonstrate leave, expense, recruitment requisition, asset and appraisal approval chains. Five corresponding services contain feature-gated Workflow clients, but their switches default off and terminal callback delivery is not performed by Workflow Service.
Responsibilities
Authors maintain valid draft steps before publication. Initiating modules supply a subject and routing context. Approvers act only on applicable pending tasks. Tenant and service owners govern access, integration enablement and operational support.
Business Rules
Definition keys are required and tenant-unique. Publication requires a nonempty draft. Instances start only from a published version. Only pending tasks in a running instance can be approved, rejected or delegated.
Integrations
Workflow Service owns definitions, versions, instances and tasks. Connected modules can synchronously start and read instances when their integration is enabled; lifecycle domain events are persisted to an outbox and relayed as integration events.
Limitations
Notification steps, cancellation and archival are represented in enums or stored models but are not executed. Endpoint policies are empty, the Portal is partial, and cross-module terminal propagation is incomplete.
Requires Confirmation
Production enablement, approver-role naming, upstream access enforcement, terminal decision propagation, notification ownership, retention and operating procedures require confirmation.
Source References
microservices/src/workflow-service/Domain/Workflow/WorkflowDefinition.csmicroservices/src/workflow-service/Domain/Workflow/WorkflowInstance.csmicroservices/src/workflow-service/Application/Commands/WorkflowInstanceCommands.csmicroservices/src/workflow-service/Infrastructure/DevelopmentSeeder.csUI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsx
Related Articles
- Workflow documentation
- Workflow lifecycle
- Business limitations
- Technical documentation
- API documentation
- Database documentation
- Events & integration contracts
- UI, operations, troubleshooting & reference
See Also
- Business rules
- Integrations
- Source map
- Technical source map
- API source map
- Database source map
- Events source map
- UI & operations source map
Keywords
Workflow, approval, definition, version, task, delegation.
Revision Information
Draft source-backed business documentation reviewed on 2026-07-20; next quarterly review is 2026-10-20.