WorkFlow Technical

Work Flow — Technical Overview

This page summarizes the current technical structure of the WorkFlow module and, more importantly, clarifies which capabilities are already executable and which are still only modeled or partially implemented.

Module

• Module: Work Flow
• Version: v1.0
• Last updated: 2026-03-10

---

1. Technical Approach

The current implementation follows a stable pattern:

• Maintain reusable catalog entities such as events, gateways, user tasks, service providers, responsibilities, and responsibility locators.
• Bind those entities to nodes on the workflow canvas.
• Publish the designed graph into an immutable release snapshot.
• Run execution instances only against the released snapshot.

This pattern is the recommended best practice for the module and should be kept.

2. Current Capability Matrix

Domain	Modeled	Validated	Published	Executed
Events	Yes	Partial	Yes	Partial
Exclusive Gateway	Yes	Yes	Yes	Yes
Parallel Gateway	Yes	Yes	Yes	Yes
Inclusive Gateway	Yes	Partial	Yes	Partial
Event-based Gateway	Yes	Yes	Yes	Partial
User Task	Yes	Partial	Yes	Partial
Service Task	Yes	Partial	Yes	Partial
Service Provider	Yes	Yes	Yes	Partial
Responsibility	Yes	Yes	Indirect	Partial
Responsibility Locator	Yes	Partial	Indirect	No

---

2. Implementation Notes

2.1 Surface

• Design entry: lib/modules/work_flow/export.dart
• Key services: gRPC clients under lib/grpc/client/* for model, gateway, event, user task, service provider, release and execution management

2.2 Capabilities

1. Workflow modeling: node and connection management, event/gateway/task configuration.
2. Persistent Process Issues panel in the design UI: structural errors and warnings appear here; panel has fixed initial height and resizable divider.
3. Publishing flow: design → snapshot publish → execution instances.
4. Runtime engine: start workflow, handle event/activity nodes, dispatch message and timer events, execute service tasks, and advance from gateways.

2.3 Gateway Rules (Client-side)

• Gateway must be bound to a valid GatewayEntity.
• Forbid trivial gateway structures with 1-in and 1-out.
• Forbid ambiguous many-in and many-out gateway structures.
• Normal gateways must be either 1-in many-out (split) or many-in 1-out (join).
• Event-based gateways must be 1-in at least 2-out and all outbound targets must be intermediate-catch events.

---

3. Usage Notes

• The design canvas will run a local validation pass before layout operations; errors will block automatic layout while warnings will be shown but not block the action.
• Connection lines can carry a branch_key value used by exclusive gateways at runtime to select the outbound path.
• Message events and timer events already have a basic in-process runtime path, but production-grade cross-process infrastructure is still pending.
• Inclusive gateways, event-based gateways, service tasks, and responsibility-based assignment are available in a basic runtime form, but still need stronger governance, observability, and recovery strategies.

---

4. Integration

• The module integrates with responsibility and service provider modules for task assignment and service tasks mapping.

5. Recommended Reading

For concept-by-concept documentation, see:

• 06_events.md
• 07_gateways.md
• 08_user_tasks.md
• 09_service_tasks.md
• 10_responsibility_locator.md