Complete Task
Built-in Tasks is a concept feature. It's still being developed and can change before it's released. It's available only when the site's license includes the Concept feature Tasks.
Audience:
Low-code EngineersSkill Prerequisites:
Actions,Tokens,Workflows
The assignee completes a task with one of the outcomes of its type. The workflow the type binds to its Completed event then runs.
Typical Use Cases
- Complete a purchase check with Looks fine from a button on your own page
- Assign an unassigned task to the user and complete it in one click
- Complete a task when something else shows the work is done, for example in a workflow that runs when an order is confirmed
Don't use it to
- Stop a task that's no longer needed. Use Cancel Task instead.
- Complete every task of a checklist when a record leaves a state. Set Open checklist tasks on the lifecycle transition instead. See Checklists on Lifecycle States.
Related Actions
| Action Name | Description |
|---|---|
| Assign Task to Current User | The current user takes an unassigned task. |
| Start Task | Moves the task from Open to In progress. |
| Cancel Task | Cancels an open task. |
| Read Task | Reads a task, with whether the current user may complete it. |
| Get Tasks | Lists tasks, for example the other tasks of the same checklist. |
Input Parameter Reference
| Parameter | Description | Supports Tokens | Default | Required |
|---|---|---|---|---|
| Task Id | The id of the task, usually a token such as [Id] in a grid row. | Yes | empty | Yes |
| Outcome | The key or the name of an outcome of the task's type, for example Looks fine. When the type has only one outcome, you can leave it empty. | Yes | empty | Yes, unless the type has one outcome |
| Comment | A comment about the work. It's saved on the task as its completion comment, and the event workflows get it as [Comment]. Required when the outcome has Requires a comment checked. | Yes | empty | See description |
| Assign to Me If Unassigned | When the task is unassigned and the user is a member of its candidate roles, assigns the task to them and completes it in one step. | No | false | No |
| Record Values | The fields of the type's attached record form, as JSON. The task panel of My Tasks fills it with [TaskRecordForm:Json]. Elsewhere, leave it empty. See Attached record form. | Yes | empty | No |
| Output Token Name | The name of a token, without brackets, that receives the task after the change, for example Task. See Task fields in tokens. | No | empty | No |
| On Error | Actions to run when the task can't be completed. [ExceptionMessage] holds the reason. See Errors and refusals. | No | empty | No |
Output
| Token | Description |
|---|---|
[<Output Token Name>] | The id of the task. |
[<Output Token Name>:Outcome], [<Output Token Name>:CompletedBy], [<Output Token Name>:CompletionComment] and the other fields | The completed task. [<Output Token Name>:Outcome] holds the outcome's key, also when Outcome gave its name. See Task fields in tokens. |
Attached record form
A task type can have an Attached record form: fields of the record the task is about, which the person fills in before completing, for example the PO Number and the Expected Delivery of a purchase order. See Task Types.
The form is used when the task is attached to a record of the form's entity and the user may edit that record. Then, before the task is completed:
- The fields are checked. Values in Record Values are used, and fields it doesn't hold keep the record's current values.
- The changed values are saved on the record, with the user's rights.
- The task is completed.
So a required field that's empty on the record refuses the completion, also when Record Values is empty. Nothing is saved until every check passes. In an escalation step's workflow, the form isn't used.
Considerations
- Only the assignee may complete the task. With Assign to Me If Unassigned, a member of the candidate roles may complete an unassigned task too. An escalation step's workflow acts as the system, which may complete any open task.
- Task administrators can't complete a task assigned to someone else. Reassign it to themselves first with Reassign Task.
- Events. The workflow the type binds to Completed runs with the outcome, the user and the comment. With Assign to Me If Unassigned on an unassigned task, Assigned runs first, with the reason
claim. - After completing. The task's escalation steps stop. When the task belongs to a lifecycle checklist, completing the last open task can run a transition on the record. See Checklists on Lifecycle States. A BPMN 2.0 user task waiting for the task continues.
The action can fail with these messages, besides the ones in Errors and refusals:
| Message | Why |
|---|---|
Assign this task to yourself before completing it. | The task is unassigned. Check Assign to Me If Unassigned, or assign it first. |
Only the assignee can complete this task. | The task is assigned to someone else. |
Choose an outcome: <outcomes>. | Outcome is empty and the type has several outcomes. |
"<value>" is not an outcome of <type>. Choose <outcomes>. | Outcome isn't the key or name of an outcome of the type. |
A comment is required to complete with <outcome>. | The outcome requires a comment and Comment is empty. |
Fill in <field> before completing this task. | A required field of the attached record form is empty. |
Check <field> before completing this task. | A required yes/no field of the attached record form isn't checked. |
<field> must be a number., <field> must be a whole number., <field> must be a date. | A value of the attached record form has the wrong type. |
<entity> <record> could not be saved, so the task wasn't completed. <reason> | The record refused the values. The task stays open. |
<entity> <record> was saved, but the task wasn't completed: <reason> | Someone changed the task while the record was saved. The record keeps the new values. |
Examples
To understand how to use the below examples, please see Running Examples.
1. Complete a purchase check
Add this action to a button of a form with a TaskId field and a Note field. It completes the Purchase check task with the outcome Looks fine. If the task is still unassigned and the user is a buyer, it's assigned to them first.
{
"Title": "Complete Task",
"ActionType": "PlantAnApp.Tasks.CompleteTask",
"Description": "The supplier looks fine",
"Condition": null,
"Parameters": {
"TaskId": "[TaskId]",
"Outcome": "Looks fine",
"Comment": "[Note]",
"ClaimIfAvailable": true,
"RecordValues": "",
"OutputToken": "Task",
"OnError": [
{
"Title": "Display Error Message",
"ActionType": "ShowError",
"Parameters": {
"Message": "<p>[ExceptionMessage]</p>"
}
}
]
}
}
2. Complete a General task
The built-in General type has one outcome, Done, so Outcome can stay empty. [CallBack] holds the id of the task, from the Output Token Name of Create Task.
{
"Title": "Complete Task",
"ActionType": "PlantAnApp.Tasks.CompleteTask",
"Description": "Mark the call back as done",
"Condition": null,
"Parameters": {
"TaskId": "[CallBack]",
"Outcome": "",
"Comment": "Called back on [DateTime:Now|yyyy-MM-dd].",
"OnError": []
}
}
Revised 11/12/2026