Tasks
The Tasks section gathers in one place everything waiting on you: the tasks already assigned to you and the ones available to your group.
Managing your tasks
The screen has two views, picked with the button in the top right corner:
| View | What it shows |
|---|---|
| Board | Three columns — TO DO (no assignee yet), IN PROGRESS (already claimed) and DONE |
| List | One row per task, with the columns Task, Process, Status, Assignee and Actions |
| Task state | Description |
|---|---|
| Assigned to me | Tasks already directed to you. You can work on them right away. |
| Assigned to the group | Tasks available to your work group. You have to Claim them before working on them. |
Manager, Admin and Super Admin see every task in the tenant, not only their own and their group's — the same rule the Instances screen applies, and the two screens agreeing is deliberate. A User sees the tasks assigned to them, the ones they are a candidate for, and the ones offered to a group matching one of their process roles.
How to claim a group task
- Open Tasks in the sidebar
- Find the task you want to work on in the list
- If the task is assigned to your group, click Claim
- The task is now reserved for you and can be worked on
TIP
Only claim tasks you are really going to do. A claimed task is locked to the other members of the group until you release or complete it.
How to complete a task
- Find the task you want in the list
- Click the task's action button (e.g. 📋 Form ▼ or ✓ Complete)
- If the task has a form attached, it opens automatically with all its fields
- Fill in the fields as instructed — required fields are marked with
* - Click Submit inside the form to complete the task
If the task has no form attached, use the ✓ Complete button directly.
INFO
Form answers are saved as process variables and stay available to the later steps of the process and in the instance history.
A blank required field does not complete
With a required field missing, completion is refused and the task stays open. The check is not the screen's alone: it also runs on the server, against the very version of the form you are looking at, and it honours the conditional rules — a field hidden by a rule is not demanded. That holds for whoever completes the task through an integration, without going through the screen, too. Details in Forms → Where "required" is actually checked.
Fields that arrive already filled
When the process turns pre-fill on, opening a task of yours — or claiming one — may show some fields already filled, tagged Pre-filled. They are values that held in almost every comparable case; hover the field to see the count ("696 of 698 cases"). A banner above the form says how many there are and asks you to check them before completing. Each field has a clear button and the banner has Clear all; editing the field drops the tag. A field you cleared stays empty after you save — the suggestion does not come back. Only empty fields are filled — what you typed is never replaced — and nothing is saved until you save or complete. Details in Smart Autofill.
Fields filled by AI
When an agent step of the process wrote a field of your form, the field shows the label Filled by AI. Hover over it to see which step and which agent wrote it, when, and the passage of the document the agent said the value came from — shown as text, the way the agent wrote it.
- Changing the value removes the label; going back to the agent's value brings it back. Once you save a value of your own, the label does not come back on it.
- Saving or completing with a different value records the agent's write as replaced by you; completing without changing it records that you confirmed the value.
- Autofill does not replace a field filled by AI: if history suggests another value, the suggestion goes to the review list, and you decide.
Filtering and searching tasks
The bar above the tasks holds five controls:
| Control | What it does |
|---|---|
| Search... | Filters by the task name or the process name |
| Your user picture | Toggles between only mine and show all |
| Type | Narrows to process (BPMN) or case (CMMN) tasks |
| Priority | High, medium or low |
| Process | Narrows to one of the processes present in the list |
The ✕ next to the filters clears them all at once. There is no sort control: open tasks always come newest first, by creation date.
The list comes in pages, and the footer takes you to the next ones
The screen does not bring the whole queue at once: it shows 100 open tasks and 100 completed ones per page, newest first. The footer holds two page controls — one for the open tasks and one for the completed ones — each with its own next-page button and its own choice of how many rows to bring at a time: 25, 50, 100 or 200. The two lists move independently: turning the page of the completed ones does not touch the open ones.
The footer is the same in both views. In the Board, the TO DO and IN PROGRESS columns show the current page of open tasks and the DONE column the current page of completed ones; in the List, the two pages appear one after the other.
The only mine filter differs from the others: it is applied at the source, so it switches the whole queue of open tasks — not merely what was already on screen. Turning it on or off sends the open tasks back to the first page. The completed ones are not affected by it.
Search, Type, Priority and Process, on the other hand, act on the page that is open, not on the whole queue. With more than one page of tasks that matters: filtering by process will not surface a task sitting on the next page — advance the page to reach it.
Completed tasks follow the same visibility rule as open ones
The DONE column and the completed rows in the List obey the same rule as the rest of the screen: Manager, Admin and Super Admin see the completed tasks of the whole tenant, and a User sees the ones they completed, the ones they took part in, and the ones offered to a group matching one of their process roles. For the full history of an instance — including the steps nobody in your group touched — keep using Instances.
Task status
| Status | Meaning |
|---|---|
| To do | No assignee yet — waiting for someone in the group to claim it |
| In progress | Claimed by someone and being worked on |
| Completed | Done, and the process moved on |
A missed deadline is not a status: an overdue task stays To do or In progress and gets a visual highlight, described just below.
Checking the deadline (SLA)
Tasks with a configured deadline show the due date on the card and on the task screen, in three highlights:
| Highlight | When |
|---|---|
| Neutral | More than 24 hours left |
| Amber, with ⏱ | Less than 24 hours left |
| Red, with ⚠ | The deadline has passed |
The 24-hour warning exists so a task looks different before it becomes a problem. It is visual only: "due soon" raises no notification.
When the deadline passes, an Overdue task notification reaches the bell of the task's assignee — or, while it has none, its candidates and whoever holds the candidate role. It arrives once. If the process sets escalate after and the task stays overdue that long, Managers and Administrators get Delay escalated, also by e-mail. Moving the due date later resets the delay. Details in Notifications.
Overdue tasks are highlighted, to make prioritising easier.
Attachments
The Attachments button, at the bottom of the task, opens a side panel with every file on the instance. The number next to the icon shows how many there are.
In the panel, each file offers:
- View — opens a preview in a window, without leaving the task. Available for PDF, images (JPEG, PNG, GIF, WebP) and text (TXT, CSV, XML, Markdown). Word, Excel and ZIP have no viewer and can only be downloaded.
- Download — saves the file to your computer.
Process attachments cannot be deleted. A document that entered the process is part of its record. When a file needs to be corrected, it is replaced: the previous one leaves the list but stays stored as history, linked to the one that took its place.
How files get in
That depends on how the process was configured (see Process Catalog):
- Form only — a file comes in only through the file field on the task form. The attachments panel is read-only and shows a notice.
- Ad hoc — besides the form, anyone with permission can attach directly from the panel.
Who can see them
Viewing and replacing attachments depend on your role in the process. If you don't see the view button, or you get a permission notice, it is because your role is not in the list configured for that process. Administrators always have access.
Task form and versioning
When a task has a form attached, Flowi Agentic:
- Locks the published version of the form at the moment the task is created
- Always shows that locked form — later changes to the form do not affect tasks already open
- On submit, the data fills the instance's process variables
This guarantees the user always fills in the right form for that step, whatever updates the administrator made afterwards.
What the copilot knows about the open task
When you open the copilot chat inside a task, it receives, on top of the process and the instance variables:
- that task's locked form — each field's key (which is the process variable name), the label shown on screen, the field type and, for choice fields, the full option list. That is what lets you ask "what do I fill in here?" and get the names and options that actually exist on the screen, rather than an approximation;
- the mined history of that step — once self-learning has found a pattern for a field, the copilot answers "what is usually filled in here?" with the same count the autofill shows: "in 641 of 645 comparable cases", plus the condition when the pattern only holds for one slice ("when categoria=TI").
With no history, it says so
If the step has no mined pattern yet — because it is new, because it has few completions, or because learning is switched off for the process — the copilot answers that there is no history for that field. It does not estimate a distribution or describe "what is usually filled in" with no number behind it.
What it never sees
A field classified as personal data (CPF, CNPJ, CEP, e-mail, phone) and a password field stay out of what the copilot receives, under the same rule that keeps them out of mining. Asking the copilot about those fields does not bring them back: it answers that it does not have that data.
Which model answers the copilot
The copilot chat — on the task, on the board and in the modeler — shows a Model selector when the platform offers more than one choice. It starts on the Copilot's default model and remembers your choice in this browser; a choice that is no longer offered is dropped and the chat goes back to the default. With a single choice the selector does not show.
When the model's provider fails before any answer, the turn is answered once by the fallback model, and the message shows a notice such as "Answered by Claude Sonnet: Gemini Flash hit its rate limit". If the failure happens after part of the answer showed or a tool changed something, the turn is not repeated on another model and the error message says why.