Skip to main content

Workflow Business Limitations

Summary​

Workflow is a capable approval foundation with material gaps in authorization, execution semantics, notifications, reporting, administration and terminal integrations.

Business Purpose​

Make unsupported behavior explicit so implementation maturity is not overstated.

Actors​

Workflow authors, approvers, delegates, process initiators, tenant administrators, product owners, support teams and owners of connected business modules.

Business Flow​

Workflow definitions​

  • No clone, delete, archive command, owner, effective date, version comparison or rollback.
  • Notification steps and modes are stored without distinct execution.

Execution​

  • No cancellation, pause, timer, timeout, escalation, retry, compensation or reopen.
  • Conditions support only case-insensitive equality/inequality and silently skip stages.
  • StepMode does not change engine behavior.

Tasks​

  • No all-task search, completed history, priority, due date, claim or reminder.
  • Rejected instances retain other stage tasks as Pending.

Assignment​

  • Decision commands do not enforce caller assignment.
  • Manager fallback can create an unresolved placeholder.
  • Delegation has no chain, expiry or proxy policy.

Notifications​

  • No Workflow Notification Service mapping or templates.
  • Notification step type is a Foundation placeholder.

Reporting​

  • No business reports, aging, throughput, bottleneck, SLA or export.
  • Dashboard completed/delegated/rejected labels use a pending-only source.

Administration​

  • Portal authors one step only and cannot edit versions or conditions.
  • No confirmed Gateway Workflow route.
  • Backend endpoint policies are empty.

Integration​

  • Five starting clients default off.
  • Terminal callback endpoints exist in source modules, but Workflow does not invoke them.
  • No verified consumer bridges terminal events to source records.

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​

Unsupported enum values and callback comments are not treated as implemented capabilities.

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​

Security ownership, production integration flags, callback/event orchestration, business continuity, notification policy and compliance retention require confirmation.

Requires Confirmation​

Security ownership, production integration flags, callback/event orchestration, business continuity, notification policy and compliance retention require confirmation.

Source References​

  • microservices/src/workflow-service/Domain/Common/Enums.cs
  • microservices/src/workflow-service/Application/Commands/WorkflowInstanceCommands.cs
  • microservices/src/workflow-service/Api/Policies.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsx
  • microservices/src/notification-service/Application/EventNotificationResolver.cs

See Also​

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.