Skip to main content

Task Document

Tasks are independent components that perform specific operations during workflow runtime. Each task can be defined in different types according to its own special purpose and can be executed at different points in the workflow.

tip

Tasks are stored as an independent workflow. They are defined as references to the points where they will be used. A workflow named tasks is created in each domain deployment. All tasks used within the domain are record instances in this workflow.

Task Types

vnext-schema/task-definition.schema.json defines a total of 15 task types. Each is listed below with its number, name, and detail page.

#Task TypeDescriptionDetail
1DaprHttpEndpointDapr HTTP endpoint invocation(detail page in a later phase)
2DaprBindingDapr binding (input/output)(detail page in a later phase)
3DaprServiceDapr service invocation callsDaprService
4DaprPubSubDapr pub/sub messagingDaprPubSub
5HumanTaskTask requiring user interaction(detail page in a later phase)
6HttpTaskHTTP web service callsHTTP
7ScriptTaskC# Roslyn script executionScript
8ConditionTaskConditional logic and branch decision(see mappings)
9TimerTaskTimer (DateTime/Duration)(see mappings)
10NotificationTaskSending notificationsNotification
11StartFlowTaskStart a new instance (subflow/process)Trigger
12TriggerTransitionTaskTrigger a transition on an existing instanceTrigger
13GetInstanceDataTaskFetch a single instance's data(detail page in a later phase)
14SubProcessTaskRun a SubProcess (fire-and-forget)(detail page in a later phase)
15GetInstancesTaskFetch multiple instances by filterGetInstances

Note: Only these 15 task types defined in the schema exist. Task types not on this list are not supported by the system.

Task Usage

Tasks are used by being referenced by other modules. In each task usage, order, task reference, and mapping information are defined.

Example Task Definition

"onExecutionTasks": [
{
"order": 1,
"task": {
"key": "invalidate-cache",
"domain": "core",
"flow": "sys-tasks",
"version": "1.0.0"
},
"mapping": {
"location": "./src/InvalideCacheMapping.csx",
"code": "<BASE64>"
}
}
]

Execution Order

  • order values are grouped among themselves
  • Those with the same order are executed in parallel
  • Those with different orders are executed sequentially

Data Management

  • If tasks have output data as a result of their execution, they increase the master data as a patch version
  • Input and output binding is done with the mapping field

Task Execution Points

Within the workflow:

  • Transition.OnExecutionTasks: Executed when transition is triggered
  • State.OnEntries: Executed on first entry to a stage
  • State.OnExits: Executed on first exit from a stage

Outside the workflow:

  • Functions.OnExecutionTasks: Executed within platform services
  • Extensions.OnExecutionTasks: Workflow record instance tasks

Standard Task Response

All task types use the same standard response structure:

public sealed class StandardTaskResponse
{
/// <summary>
/// Data returned from task execution
/// </summary>
public dynamic? Data { get; set; }

/// <summary>
/// Status code for HTTP-based tasks
/// </summary>
public int? StatusCode { get; set; }

/// <summary>
/// Whether the task execution was successful
/// </summary>
public bool IsSuccess { get; set; } = true;

/// <summary>
/// Error message in case of error
/// </summary>
public string? ErrorMessage { get; set; }

/// <summary>
/// Response headers for HTTP-based tasks
/// </summary>
public Dictionary<string, string>? Headers { get; set; }

/// <summary>
/// Additional metadata about task execution
/// </summary>
public Dictionary<string, object>? Metadata { get; set; }

/// <summary>
/// Task execution time (milliseconds)
/// </summary>
public long? ExecutionDurationMs { get; set; }

/// <summary>
/// Task type identifier
/// </summary>
public string? TaskType { get; set; }
}