Tasks runtime automation
Use the Tasks services in the Net Operation Project for operational automation.
The installed developer-surface catalog and
Tasks XML reference determine
the interfaces available in that installation. The runtime below includes
Tasks automation contract 2.0.0 and Tasks SDK 5.0.0 behavior; check installed
versions before using newly added members.
Tasks also exposes the same application operations through
/api/workspace/tasks/runtime/... in the installed
/openapi/moltaro-public-v1.json. Resolve every route against
WORKSPACE_API_BASE_URL, never moltaro.com. HTTP requests use the caller’s
Workspace bearer token or service API key and retain the same current Task,
Worker, Queue and Definition permission checks. Configuration is documented
separately in /openapi/moltaro-config-v1.json. Older installations may need
an update before their public documents include Tasks.
HTTP operations
Section titled “HTTP operations”| Flow | Route under /api/workspace/tasks/runtime |
|---|---|
| Create or list Tasks | POST /tasks, GET /tasks |
| Read a Task and its history | GET /tasks/{taskId}, GET /tasks/{taskId}/history |
| Discover and execute lifecycle actions | GET /tasks/{taskId}/command-options, POST /tasks/{taskId}/commands |
| Request one Queue assignment | POST /queues/{queueId}/request-work, then GET /queues/{queueId}/request-work/{operationId} |
| Request dispatcher distribution | POST /queues/{queueId}/selection/evaluate, then GET /queues/{queueId}/selection/operations/{operationId} using the returned diagnostic row ID |
Use the HTTP DTOs from OpenAPI; C# facade DTOs are not interchangeable with HTTP requests. PascalCase properties, exact retry keys and current row versions remain part of each command’s contract. A successful submission of asynchronous assignment admits work; poll the returned operation until its terminal state as described below. Reading a Task or notification never starts or completes it.
Commands and reads
Section titled “Commands and reads”Prefer ITaskInstanceAutomationCommandService and
ITaskInstanceAutomationQueryService from Moltaro.Package.NET.Tasks.Automation.
They share current authorization, Task/Part validation, capacity, concurrency,
history and replay with the Tasks interface. Read the
instance SDK examples for creation,
data/property edits, assignments, lifecycle commands and Queue work.
The facade uses a separate application transaction. It does not join an authored
GeneratedWorkspaceContext transaction. Direct EF access remains a trusted
database path: it does not synthesize command authorization, history, receipts
or notifications. Do not use it to bypass a rejected application command.
Instance services support Action, Command, HttpEndpoint, Job and TriggerHandler phases. Validation and BeforeSaveMutation cannot call them. Human invocations retain their current rights; host-authenticated Job/trigger execution carries system provenance. Supplying an actor string does not create authority. Self-service Take needs the caller’s Worker; a system invocation cannot take work for itself.
For a new mutation, read the current Task and required Part RowVersions. Preserve
OperationId, payload and versions for an exact retry after an unknown outcome.
Use a new key for a new intention. Success can omit a Task snapshot if current
View is absent; that does not authorize repeating the effect. A rolled-back
command that exhausts native transaction retries can return
tasks.runtime.retryRequired; do not treat an unknown transport outcome as proof
that the command rolled back.
Choose an operation
Section titled “Choose an operation”The following members belong to the instance query/command pair above, unless another service is named. Read projected options instead of reproducing actor, state or capacity rules in a client.
| Intention | Supported entry points |
|---|---|
| Discover visible work and load | ListAsync, GetAsync, ListQueuesAsync, GetQueueWorkloadAsync. |
| Prepare and create work | GetCreateFormAsync, GetCreateWorkingCapabilityAsync, GetCreateContextCandidatesAsync; CreateDirectAsync or CreateQueueAsync. |
| Edit properties or owned data | GetEditOptionsAsync, GetDataAsync, GetContextCandidatesAsync; EditDetailsAsync, ChangeDueDateAsync, ChangePriorityAsync, ChangeContextAsync, EditInputDataAsync, EditWorkingDataAsync. |
| Assign participants or release Queue work | AssignOwnerAsync, AssignResponsibleAsync, AssignExecutorAsync; ReturnToQueueAsync. Use the request’s nullable participant only where the installed command permits removal. |
| Execute or finish work | GetCommandOptionsAsync; StartAsync, StopAsync, PauseAsync, ResumeAsync, BlockAsync, the explicit block/postponement return methods, CompleteAsync or CancelAsync. |
| Change shared order, Queue or availability | GetRoutingOptionsAsync; MoveInQueueAsync, ChangeQueueAsync, ChangeAvailabilityAsync. Transfer does not clear an Executor for you. |
| Read instructions and history | GetInstructionsAsync, GetHistoryAsync; content mutations use the admitted shared content owner and its services. |
| Request algorithm assignment | The separate Queue assignment services below. |
Creation writes both owned Parts atomically. A later Part edit needs both Task and Part versions. Context and collaboration have their own current access; a Task view or assignment cannot open a protected business record, file or content owner. See Definition setup for the configured rules and SDK examples for request construction.
Related Tasks on business records
Section titled “Related Tasks on business records”A Task can reference an admitted Entity Instance or Board Item as its Context.
Subject is the task title, not a resource link. This reference does not yet
provide a related Tasks list on the Entity Instance or Board Item details page
or preview drawer. The supported instance-list query currently has no canonical
Context filter; filtering a downloaded page in the client produces incomplete
results and incorrect counts.
Related Tasks sections on all four host surfaces, with an authorized Context query, paging, counts and Task navigation through HTTP API and C# SDK, are planned product work. They are independent of future Case management and Task Orchestrator capabilities. No release date is assigned here. A Board Item and its target Entity Instance remain different Context identities; access to one does not grant access to the other or to a related Task.
Asynchronous Queue assignment
Section titled “Asynchronous Queue assignment”Inject ITaskQueueAssignmentAutomationCommandService and its query counterpart.
These operations admit background work rather than wait for assignment:
| Command | Poll through the query service |
|---|---|
RequestWorkAsync(queueId, new TaskQueueAssignmentRequest(operationId)) | GetWorkRequestAsync(queueId, operationId) for the same actor’s submitted key. |
EvaluateAssignmentAsync(queueId, request) | GetAssignmentDiagnosticAsync(queueId, result.Id) using the opaque receipt row ID. |
RetryAssignmentAsync(queueId, failedRowId, request) | Read the returned diagnostic; retry uses a distinct operation key and current authority. |
Pending and Running are non-terminal. Succeeded, NoWork and Failed are
terminal for that receipt. Use bounded polling and inspect ReasonCode. Request
results can include ExistingWork; Succeeded with Task = null means the
committed result is currently unavailable, not that another assignment is needed.
Diagnostic summaries deliberately omit Task/Worker and selector payload details.
Assignment commands require the current actor and the relevant Worker or Queue capability. The owning Worker runtime evaluates configured selection and schedule rules and revalidates proposals before committing. Cancelling a client wait does not cancel an admitted intent; there is no public assignment-cancel command. The algorithm assigns but does not Start work. A new request is a new intention; polling or replaying the old key never allocates another task. In both Auto-assignment and Assignment on request, a new Worker request attempts one new assignment; previously assigned work does not replace that request. Both modes also permit authorized dispatcher evaluation. Automatic causes are specific to Auto-assignment.
Signals and notifications
Section titled “Signals and notifications”Task snapshots expose current authorized signals: Warning before a deadline,
Danger near the deadline, Overdue at the due instant, and applicable blocking or
participant/Queue problems. Severity values are Info 0, Warning 1, Danger 2
and Overdue 3. Configure deadline thresholds and notification policies through
Signal Profiles.
The Definition profile takes precedence over the Queue profile; overdue remains
available without a profile.
Work Inbox delivers configured real transitions to currently authorized people. Repeated polling or projection rebuilding does not send old notifications again. Core owns exact-occurrence acknowledgement where supported; it does not complete work or resolve its cause. Use ordinary Task commands and History for handling work. Signals do not automatically change priority or transfer a Task.
For Queue request/poll helpers, see Tasks asynchronous recipes.
Agent authoring checklist
Section titled “Agent authoring checklist”- Start from the existing access kit and inspect the installed developer surface. Do not provision access or grant roles to make a command pass.
- Choose configuration or instance services explicitly; Configuration Management does not authorize Task operations or signal acknowledgement.
- Keep stable operation keys only for exact retries. Preserve versions and inspect a queued receipt before reporting the effect as complete.
- Use runtime queries for current authority and permitted actions. Do not infer rights from Owner/Admin labels, a cached grid row or an Inbox audience.
- Keep custom selectors inside their admitted Queue invocation. They propose assignments from admitted facts, not direct state changes or cross-Queue work.
See Tasks configuration for profiles, selection and schedule policy, and the user workflows for the corresponding behavior in the interface.