Workflow and Task Orchestration
📖 Best for: Business leaders, process designers, and complex business architects
📖 Reading time: about 8 minutes
📖 In one sentence: A single workflow is one line. Multiple workflows orchestrated together are what enterprise-grade business really needs.
A workflow is YingCore's execution path for a single task—from trigger to completion, step by step through nodes. But real business is far more complex than one workflow: customer onboarding takes 4 workflows (register → provision → train → activate), and data must pass between departments. Task orchestration is what combines these workflows by business relationship into complete processes, both reusable and governable.
Core Idea: From Single Path to Process Network
YingCore's workflows are the basic building blocks. Task orchestration is what builds the castle from those blocks:
Three values of task orchestration: reuse (workflows maintained independently) / composition (complex business decomposable) / governance (cross-process monitoring possible).
Five Orchestration Patterns
Any complex business flow is a combination of these five basic patterns:
| Pattern | Relationship | Use Case | Typical Example |
|---|---|---|---|
| ➡️ Sequence | A → B → C | Strongly dependent in series | Register → Review → Approve |
| ⚡ Parallel | A | B | C | No dependency, simultaneous | Send email, SMS, IM at once |
| 🔀 Branch | A → condition → B/C | Branch on result | Pass goes to B, fail goes to C |
| 🔁 Loop | A → loop → A | Repeat until qualified | Rewrite until review passes |
| 🛑 Exception | A → exception handler | Failure fallback | Any step failure triggers emergency flow |
Pattern 1: Sequence
Workflows execute in defined order. The previous output becomes the next input:
orchestration:
type: sequence
steps:
- workflow: customer-register
output_to: register_result
- workflow: customer-verify
input_from: register_result
- workflow: customer-activate
input_from: verify_result
Pattern 2: Parallel
Multiple workflows start simultaneously and join before moving to the next step:
orchestration:
type: parallel
steps:
- parallel:
- workflow: send-email
- workflow: send-sms
- workflow: send-im
join: all_completed
- workflow: log-notification
input_from: parallel_results
Pattern 3: Branch
Choose different branches based on conditions, with nested support:
orchestration:
type: branch
steps:
- workflow: credit-check
- branch:
if: score >= 80
then: workflow: fast-approve
else:
if: score >= 60
then: workflow: manual-review
else: workflow: reject
Pattern 4: Loop
Repeat execution until the exit condition is met; fall back when limit is hit:
orchestration:
type: loop
workflow: auto-fix-bug
condition: build_status == success
max_iterations: 5
on_exhausted: workflow: notify-human
Pattern 5: Exception Fallback
When any step fails, run the emergency flow to avoid business interruption:
orchestration:
type: try-catch
try:
- workflow: pay-order
- workflow: deduct-inventory
catch:
workflow: rollback-and-notify
notify: [finance, customer-service]
Core Mechanisms: Four Building Blocks of Orchestration
Stable task orchestration depends on four mechanisms:
1️⃣ Variable Passing
Data between workflows is passed via variables, with nesting and mapping support:
{
"outputs": {
"register_result.customer_id": "C-2025-001",
"register_result.email": "user@example.com",
"register_result.created_at": "2025-09-01T10:00:00Z"
}
}
Downstream workflow references:
- workflow: send-welcome
inputs:
customer_id: $outputs.register_result.customer_id
email: $outputs.register_result.email
2️⃣ Context Inheritance
Child workflows automatically inherit the parent orchestration context (project, customer, environment) without passing it again:
3️⃣ Error Propagation
When a child workflow fails, the error propagates upward with full context:
{
"error": {
"workflow": "credit-check",
"step": "query-database",
"message": "database connection timeout",
"context": {
"customer_id": "C-2025-001",
"retry_count": 3
}
}
}
4️⃣ Resource Isolation
Each orchestration instance has its own resource quota, avoiding mutual interference:
| Resource | Isolation Method |
|---|---|
| Database connection | Independent connection pool per orchestration instance |
| Memory | 1GB upper limit per instance |
| Concurrency | Configurable upper limit per tenant |
| Timeout | Global timeout + per-workflow timeout, two layers |
Complete Scenario: Customer Onboarding
A SaaS product new customer onboarding needs 4 workflows to collaborate, plus a delayed analysis workflow:
Full YAML orchestration config:
# customer-onboarding.yaml
orchestration:
name: customer-onboarding
trigger: webhook
timeout: 24h
on_error: notify-admin
steps:
- id: register
workflow: customer-register
input: $trigger.payload
output: customer_info
- id: provision
workflow: resource-provision
input: $steps.register.output
output: resource_info
depends_on: register
- id: training
workflow: user-training
input: $steps.provision.output
output: training_record
depends_on: provision
timeout: 8h
- id: activation
workflow: activation-campaign
input: $steps.training.output
depends_on: training
delay: 1d
- id: analysis
workflow: usage-analysis
input: $steps.activation.output
depends_on: activation
delay: 7d
error_handling:
catch_all:
workflow: notify-admin
notify: [operations, customer-service, technical]
retry_policy:
max_attempts: 3
backoff: exponential
Execution flow at a glance:
| Step | Workflow | Input | Output | Duration | Exception Handling |
|---|---|---|---|---|---|
| 1 | customer-register | webhook payload | customer info | ~10s | enters notify-admin |
| 2 | resource-provision | customer info | resource ID | ~5min | auto-retry 3 times |
| 3 | user-training | resource ID | training record | ~8h | timeout enters notify-admin |
| 4 | activation-campaign | training record | outreach log | ~1min | delayed 1 day trigger |
| 5 | usage-analysis | outreach log | analysis report | ~30s | delayed 7 days trigger |
Key Parameters
| Parameter | Type | Description |
|---|---|---|
orchestration | object | Orchestration config root |
trigger | string | How orchestration is triggered |
steps[].id | string | Step unique identifier |
steps[].depends_on | array | Upstream step dependencies |
steps[].delay | duration | Start delay |
steps[].timeout | duration | Per-step timeout |
on_error | string | Global error handling |
retry_policy | object | Retry policy |
error_handling | object | Exception branch config |
Best Practices
| Practice | Description |
|---|---|
| 🎯 Moderate granularity | Keep one orchestration to 3-7 workflows, split if larger |
| ➡️ Sequence for critical path | Strongly dependent steps must keep order |
| ⚡ Parallel for independent tasks | Save time and improve throughput |
| 🔁 Exception branch required | Every orchestration needs a fallback flow |
| 👤 Reserve human review for critical nodes | Money, compliance, etc. must have human review |
| 📊 Full-chain visibility | Orchestration status queryable in real time, fast issue location |
| 🛑 Two-layer timeout | Global + per-step dual protection, avoid single-point stuck |
| 💰 Resource quota governance | Limit per-tenant orchestration concurrency, avoid resource contention |
| 🔍 Record context on failure | Save context snapshot on error for easy debugging |
| 🔄 Reentrant design | Same orchestration supports idempotent rerun without side effects |
Next Steps
Task orchestration combines multiple workflows into complete business. Learn more about Platform Management and how to govern orchestration permissions, auditing, and resource quotas.