Tasks and Kanban

#Assignment model

A single "assignee" field has three options.

Option	What happens
Orbi (the Orchestrator)	The task is split and handed out to the right agents. Use this when more than one specialism is needed.
A specific agent	The planning layer is skipped and that agent works directly. It is faster and cheaper when you know exactly what you want.
A human team member	This is the classic Jira flow, and there is no agent execution.

#State device

flowchart LR
  B["Backlog"] --> T["To Do"]
  T --> Q["Queued"]
  Q --> I["In progress"]
  I --> R["Review"]
  R --> D["Done"]
  R -.->|"feedback"| Q
  I -.-> E["Error"]
  E -.->|"requeue"| Q
  D -.->|"reopen"| T

The states are fixed across every workspace and cannot be customised. The price is flexibility and the gain is consistency. Review means the same thing everywhere, which makes reporting and automation dependable.

Errors that happen during execution drop the card into a separate Error state, and from there requeue takes it back to Queued.

The diagram above is the usual course of work, not a list of permitted moves. You can move a card from any state directly to any other. To mark a waiting job as done in one go, or to put a completed card straight back into work, you do not have to pass through the stops in between.

Done is a closing, not a wall. A completed task can be reopened. Reopening is a deliberate action and not something that happens on its own.

#What the owner of a card can change

A state describes what is happening right now. That is why who may set the execution states depends on who the card is assigned to.

Who the card is assigned to	What you can do
Orbi or an agent	Every state except In progress and Review, so queueing, taking it out of the queue, approving in review, putting an errored card back in the queue and reopening a completed one
A human	All of them, because you are the one doing the work anyway

On a card assigned to AI you cannot set In progress and Review by hand, because they are set by the agent doing the work. Otherwise the board would say "an agent is working" while nobody is working, or "there is output waiting for review" while there is no output. If you are taking the job over yourself, assign the task to yourself first, then move it to the state you want.

#Exactly four things trigger execution

1. A task being moved to Queued
2. An @agent.<name> mention in a comment
3. A flow trigger (cron/reminder/event)
4. An HTTP POST from an outside system to an inbound trigger (Collaboration)

Nothing else runs an agent. Writing a record to a collection, uploading a file and editing a card do not start execution. When a run you expected does not happen, this list is the first thing to check.

#Drag and drop on the board

By dragging a card you can both move it to another column and place it wherever you want in the column it is in. The order you set is permanent, so the card is still there the next time you open the board, and on your teammate's screen as well.

That order is yours. Cards sit in the order you put them in rather than by creation date, so you can say "this one first" and show what the team should pick up first on the board itself.

Dragging does not loosen the rules. A move you cannot make with a button, you cannot make by dragging either.

• You cannot drop a card assigned to AI into the In progress or Review column, because the ownership rule above applies. That column dims while you drag and states the reason inside it, so you see it before you try.
• Dropping a card into the Queued column is the same thing as the "Move to Queued" button, and the agent starts working.
• Dropping into the Done column follows the same rule as the button. A card in review whose checklist is finished moves without a question. If the card has not reached review, has open checklist items, or its agent is still working or its computer is still open, Orbi asks first and says why, because a done card cannot be undone.

#The board helps you while you drag

Dragging keeps the mouse busy, so you cannot use the wheel while you are holding a card. The board therefore does three things.

• It scrolls by itself. As you bring the card near an edge, the column scrolls up or down and the board scrolls left or right. The closer to the edge, the faster it goes. You do not have to drop the card to move it from the bottom of a crowded column to the top.
• The other columns step back. Columns other than the one the card will land in fade, and the column that will not accept it fades the most. You see where you are dropping at a glance.
• The drop position is clear. The line showing where the card will go is set apart from the cards' own edges by the ring at its start.

Dragging is a shortcut, not the only way. The quick action buttons on the card and the state picker in the drawer keep doing the same job.

#Moving a task to another board

A card opened on the wrong board is not lost. From the Board row in the card drawer it moves to another board. It keeps its card number (@task.<no>), its state, its comments and its history exactly as they were, only its board changes, and the move is written to the activity log. If the target board is in the same space, the card moves right away. If you pick a board in another space, a move report opens first: whose access changes and which flow the moved card will trigger (Spaces). Agents do the same inside one space with the move_task_to_project tool (available under the same name on the MCP surface for clients that connect from outside); changing the space goes through the report in the app.

#Priority, tags, dependencies

• Priority can be low, medium, high or urgent, and each is shown with its own icon (a double arrow up for Urgent, a single arrow up for High, two horizontal lines for Medium, a single arrow down for Low). The icon is a deliberate choice, because badges that differ only by colour say nothing to a colour-blind user or in a greyscale screenshot, while a shape does.
• Tags are free text and are used for categorising and filtering. You write them both when creating a card and on the Tags row of an open card. Typing a tag and pressing Enter adds it, the cross next to a badge removes it, and every change is saved right away. Tags already used on the same board are suggested as you type. Whitespace is trimmed and two spellings that differ only in case count as the same tag. Agents can change the same tags with their own tools.
• Dependencies set up the "blocked by" and "depends on" relation, and the dependency graph is shown in the card drawer.
• The due date is optional. The picker that opens when you click the date box has ready options such as Today, Tomorrow, Friday, Next week. You can choose a day from the calendar or type it directly (12.08, 12 august, tomorrow). A due date that has been set is removed with Clear the date. A due date has no value of its own by default, because a date nobody set would produce cards that look overdue on the board. A date that is set also shows on the calendar.

#Creating a task

You can open a new card from anywhere in the app with Shift+N, and on a board page the New task button in the header opens the same form. If you are on a board page the card is written to that board, and if you are on another screen you pick the board from the list in the form's header, where your choice is remembered for next time.

The form has two layers. At the top you write what is to be done, meaning the title and the description. In the description you can link an agent, a collection, a task or a person with @. Below sit the card's properties, which are the assignee, the starting state, the priority, the due date and the tags. These rows have the same shape as the rows on the card's own screen, so a field looks the same here as it does when you open the card.

The starting state and the assignee are decided right here. If you want an agent to start work straight away, picking Queued as the state is enough, and you do not have to open the card first and move it afterwards.

You can attach files to the card as well. Pick them with the Add file button in the Attachments row, or drop a file anywhere on the form. What you picked is uploaded once the card is created and shows up in the card's Attachments section. If a file cannot be uploaded, a notice appears in the corner, and you open the card and upload that file again from its Attachments section.

Enter in the title creates the card, and ⌘/Ctrl + Enter does the same while you are inside the description. If you are opening several cards in a row, tick the Create another box. The form stays open, the title, description and attachments you typed are cleared, and the board and properties you chose stay as they were. A card you opened with the shortcut does not take you away from the screen you are on either. Once the card is created a short confirmation appears in the corner, so you click it to go to the card or ignore it and carry on. If you are on a board page the card also appears in the column.

You do not have to write the card yourself, because you can also ask Orbi to open it in chat. Either way, the precondition for good output is a clear definition.

#A good task definition

Agents work well with good briefs, just like people. Write three things.

1. What you want. Give a concrete output, such as "a comparison table for 5 competitors".
2. In what form. Say whether it is a file, a collection record or a comment.
3. What to follow. State the required sources, the tone of voice and any length limit.

If it builds on existing work, link it with a mention such as @task.142, @collection.rakipler or @file.marka-rehberi.

#Checklist, comments, history

• The checklist holds ordered steps. Each step's state and an output summary are kept, and the cycle it was completed in is marked. Steps are never deleted, and a step that failed is marked as an error. You can see progress without opening the card: a segmented bar sits at the bottom of the card on the board and in the list row, one segment per step. A completed segment is green, the one being worked on is blue, a failed one is red, and the counter next to it gives the number of completed steps. A failed step does not count as completed. When there are many steps the bar becomes a solid strip instead of segments. A card without a checklist shows no bar. The steps themselves live on the card's Checklist tab, which appears only when the card has steps. Clicking the progress bar above the Summary tab opens that tab too.

• Comments are written by agents and people alike. @user and @agent mentions work, and replies can be threaded. The button next to the heading sets the reading order: newest first by default, one click for oldest first. Your choice is kept in your browser and applies to every card you open. With newest first the writing box sits above the list, because that is where your new comment lands.

• You can attach files to a comment: pick them with the paperclip button under the box, drag them onto the box, or paste a screenshot straight from the clipboard. A comment can be just a file with no text. An attached image shows as a thumbnail under the comment and opens full size on click. The agent working on the card sees these files together with the card's own attachments. Deleting the comment keeps the file in Files and only removes the link.

• You talk to the card's agent through comments; the card has no separate chat tab. Your comment reaches the agent live while it works. Chats you opened on a card earlier were not deleted and stay in your chat list. When you ask an agent in a chat to "write this on the card as a comment", that comment carries a From chat mark, so the card's history keeps it apart from a comment someone typed by hand.

• History puts the card's whole life on a single timeline. Two kinds of record flow together.

  • Activity says what happened to the card. The state changed, the assignee changed, a comment was written, edited or deleted, a checklist step was added, output arrived, a dependency was set, the card was archived. Every line says who did it and when.
  • Agent cycles say what the agent did. A "here is what I did in this cycle" summary sits there with a diagnostic trail (which agent ran with which model, whether there was a fallback, sub-agent runs, token consumption).

  The chips at the top of the tab filter the flow as All / Activity / Agent cycles.

  The activity log cannot be deleted or edited. The text summary of a deleted comment stays in the log, because that is the one thing needed for the sentence "this comment was deleted" to mean anything. Automatic moves that cannot be attributed to anyone (a worker's error transition, a flow trigger) appear as System.

  These lines do not stay inside the card. The Activity page in the left menu gathers the same lines for the whole workspace, so you do not have to open a card to read its history. More in Activity.

#Pull request status on the card

When GitHub is connected (Settings → Integrations, details in Tools), the pull requests that mention a card are linked to it on their own. If a PR's title or branch name contains @task.12 or orbi/task-12, it is linked to card number 12; one PR can mention several cards. The PR description is not scanned: referring to another card there, giving an example or writing "unrelated to 12" creates no link. Coding agents already follow this rule, and you can write it in the title of your own PR too.

• A PR icon sits in the card's top strip. Grey means a PR mentioning the card is still open; green means the PR was merged; red means it was closed without merging. With several PRs, it is grey if any is open, otherwise green if any was merged, otherwise red. The same icon sits next to the row title in list view, in the backlog list and in the completed list; the PR state stays visible whichever way you list the cards.
• The card's Pull requests tab lists every PR with its number, title, state and author; clicking a row opens the PR on GitHub.
• Reviews written on the PR in GitHub land on the card as comments. The review verdict (Approved, Changes requested, Commented) sits at the top of the comment; inline comments arrive one by one with their file and line number. The author appears with their GitHub username and a "GitHub" badge; clicking the name opens the comment on GitHub. If the review is edited on GitHub the card comment is updated, if it is deleted it disappears. These comments do not count as human comments: even if they mention an agent, the agent does not start working. An agent already working on the card sees the comment in its context and reads a "changes requested" note on its next turn.
• Merging does not close the card. Moving a card to done is a human decision; when a PR is merged only the icon turns green, and the call stays with you.
• Open PRs are scanned once when the connection is made. PRs opened before you connected are linked to their cards too; old closed PRs are not scanned.
• If a PR title is edited, the link follows. Remove the mention and the PR drops off the card's list; add one and it appears.

#GitLab, Bitbucket and a code host on your own server

There is no connection for code hosts other than GitHub; the link is written by hand. An agent connected to the board, such as Claude Code, writes the PR or merge request link to the card the moment it opens it (the link_pull_request tool, details in Working together). You can do the same from the card: in the card's Pull requests tab press Link and paste the URL; the section is visible even when no PR is linked yet. The link is the only required field, the state (open, merged, closed) is optional. GitLab cloud and self-hosted GitLab, Bitbucket cloud and server, Gitea and Azure DevOps links are recognised; an unrecognised link is refused with a message listing the accepted formats. The card shows the link in the same section with the same icon, and the provider's name sits at the start of the row.

That link was written by an agent or by you, not by a provider; nobody has confirmed its state. So the icon is drawn with a dashed border and an "Unverified" suffix. If the agent merged the PR before handing the card to review, it records that on the link; the icon turns green, but the border stays dashed, because we do not show something we cannot know as certain. A manually written link to a PR on GitHub is confirmed by the GitHub connection on its first event, and the border becomes solid.

If you merged later yourself, fix the state on the card: open the menu at the right of the unverified row and pick Mark as merged or Mark as closed. The same menu offers Remove link for a link written by mistake. A verified row has no such menu; the provider manages its state and it cannot be changed by hand. A manually written link is not removed on its own even when the PR title does not mention the card; only this menu or the agent (unlink_pull_request) removes it.

#The review loop

Review is the human checkpoint. Approval is not asked step by step during execution, and control is gathered here.

If you are not happy with the output, write your feedback as a comment. Feedback does not go to the working agent directly but to the Orchestrator first, and it decides which steps are to be repeated. That way a "the third section is weak" comment does not restart the whole job.

#Retry, requeue and locking

• Automatic retry makes one attempt if an error occurs. If it fails again the task drops into the Error state and waits for a manual requeue.
• Requeue carries the task on from where it stopped, and completed checklist steps are not done again.
• Work that was not saved does not look done. If the agent tried to write something, got an error and did not write it again successfully in the same run, the card goes to Error instead of review, and the summary names the write that failed. So a report that says "updated" cannot hand you work that was never saved.
• A run that delivered nothing does not reach review. If the agent only read and ticked a few steps, the other steps are still open and it wrote no output, comment, record or file, there is nothing to review. The card goes to Error without a retry, and the history shows the agent's own summary next to the reason. A run that closes the whole checklist does reach review.
• Optimistic locking gives every task a version. If two people (or one person and an agent) edit at the same time, the conflict is detected instead of one silently overwriting the other.

#Work on the agent's own computer

In workspaces where this feature is on, an agent can do its work on a computer set aside for it: it writes files, runs commands and brings the result back to the card. The card, and the chat above the message box, then show a single status line. The computer icon at the start of the line says the work is done on the agent's own computer; hovering it reads "The agent is working on its own computer".

Line	Meaning
Waiting in line	The work starts on its own when there is room. In a chat the line says so plainly if the wait gets long.
Getting ready	The work's computer is starting.
Working · time	The agent is working; the time counts from its first step.
Waiting for an answer	The agent asked a question and waits for your answer. The question also shows under Details.
Finished · time	The work is done.
Stopped: reason	The time limit was reached, the memory limit was exceeded, the safety limit was reached or someone stopped it.
Could not start	The work never started; you can queue the card again.

Details opens the time spent, the credits the work has used so far and the agent's last step. Workspace admins see all of this work together on the Runtime page.

On whose behalf. Work on the computer is done on behalf of a person: whoever queued the card, or else the card's owner. A card opened by an externally connected agent belongs to the person who set up that agent's connection; it runs on their behalf and comes back to them for review. A card with no owner does not start on the computer; queue it yourself and it runs on your behalf.

Credits. Work on the computer is charged in credits like any other run: the price of the agent's model, with the part read from the cache at a discount. If the workspace has its own API key, the work runs on that key and uses far fewer credits. When credits run out no new work starts; work in progress finishes. The card's total cost shows on the small line under the card's properties (tokens and an approximate amount). Work done on the computer is added to that row when the computer closes; while it runs, the computer line shows the spend. In a squad, each member's spend is counted and added to the total.

Safety limit. Each computer gets a high upper limit that stops work gone out of control. Normal work stays well below it; work that reaches it stops with "the safety limit was reached", and the files written so far are kept.

Long work. One computer stays open for at most 2 hours. If the agent is still working when that time is up, the work does not stop: it goes on in a new computer with the same folder and the same conversation, and the status line keeps saying Working. It goes on only if the last stretch made progress and the card's cycle limit allows another cycle; otherwise the card goes to review and its next run continues where the work stopped. The same holds for a squad on its shared computer: each member that was working continues its own conversation on the new computer.

Memory. Each computer has a memory limit; work that goes past it closes the whole computer. Orbi then opens the next computer on the same folder with twice the memory (1 GB, 2 GB, 4 GB) and continues the work once by itself, without waiting for you to write. The chat or the card shows a line such as "The agent's computer ran out of memory; the work goes on by itself on a bigger computer". The larger memory stays for the later work of that card or chat. If the bigger computer is not enough either, the work stops and says why; for work that does not fit even the highest limit (4 GB), make the job smaller, for example ask for less data at once or split the work into parts. The files in the folder are kept either way.

Who chooses the computer? You do not choose anything. When the card starts running, the agent decides first: a simple question it can answer at once from what it has gets an answer right away; real work such as research, writing, a presentation, files or analysis goes to its computer. When it is unsure, it picks the computer. If a file is attached to the card or to your comment, or the work is code in a repository, the work starts on the computer without that decision. A comment that mentions the agent on a card is answered the same way; the last message of the agent working on its computer is posted as the reply to your comment.

In a channel. When you mention an agent or a squad in a channel, the same decision is made. Work in a channel is done on behalf of the channel, not of a person, because every reader of the channel sees it. Nobody's personal connections are used. Only files every reader of the channel can see reach the computer: files in the channel's space, in Genel and in open spaces. A file from a space only you can read does not reach the computer, even if you attach it in the channel. Credits are charged to the workspace. The agent's answer is posted in the channel. The agent hears the channel while it works; where it cannot decide, it asks the channel and waits at most 10 minutes, and if no answer comes it writes what it assumed in its answer (see Calling an agent). Anyone who can write in the channel, or an admin, can stop the work.

Stopping. The menu next to the line has the same two choices as device runs:

• Stop after this turn: the agent finishes the step it is on and does not start another.
• Emergency brake: the agent stops at once; the work may be left half done. The files written so far are kept, and if the work starts again it continues from there.

The person who started the work, people who can edit the card and workspace admins can stop it. Every stop is written to the audit log.

The web and connected services. From its computer the agent can read public web pages. Requests that send data go only to the allowed addresses. The connected services you opened to the agent (mail, calendar, Slack and the like) work on the computer too, and the agent reaches them through Orbi, so the account's credentials never enter the computer. On its computer the agent can do everything it could do if the same work ran in Orbi, and nothing more. On its own card it can open a card, delete it, change its state, send an email or share a file. A squad member working on the squad's card cannot delete cards or change their state, as in Orbi. In a chat, creating a card, a flow, a collection, a new mind model or a new file in Files needs your confirmation. The computer cannot ask for it, so ask for those in the Orbi chat. A file the agent makes on its computer still reaches the chat as an attachment.

The work runs with the permissions of the person who started it. It uses your personal connections only in work you started: a card you queued, or a chat where you wrote. A card an agent queued runs with its owner's permissions but uses nobody's personal connections. A scheduled flow uses your personal connection only if you allowed unattended use on that connection. On a card Orbi opened on its own, actions that write outside Orbi do not run on the computer. Nobody is asked during the work.

#Talking to the agent while it works

You can write to the agent while it works on its computer; you do not have to wait for the work to end.

• On a card: write a comment. It reaches the working agent at once, and the agent takes it into account at its next step. If you wrote just as the work ended, the agent answers your comment on the same computer and goes on.
• In a chat: send your message. Each message of the agent arrives in the chat as a reply of its own, and a message you send while it works reaches it at once.

When the agent asks. When the agent reaches a point it cannot pass without your decision, it asks. On a card the question shows as the agent's comment with "❓", in a chat it arrives as the agent's message, and the status line says Waiting for an answer. No email or notification is sent for this; you see it when you open the card or the chat. Write your answer as a comment on the card or a message in the chat, and the agent goes on from where it stopped.

When the answer is late. The agent waits 20 minutes for an answer. If none comes, the computer closes, but nothing is lost: the card goes back for review with the question and the line keeps saying Waiting for an answer. A comment you write later gives the card back to the agent that asked, and the work goes on with the same folder and the same conversation. In a chat too the computer stays open while the conversation goes on and closes after 20 minutes in which nobody writes; your next message opens it again with the same folder.

A question in work without a computer. The agent can also ask while it does simple work without opening a computer, for example when the card says "ask me before you start". The question shows as a comment that starts with "❓" too, the card goes back for review and the same status line says Waiting for an answer, without the computer icon. No email or notification is sent for this either. Write your answer as a comment; you do not need to mention the agent: the card goes back to the agent that asked and is queued again. The new run reads your answer and decides again whether the work needs a computer.

A comment that is not the answer. On a card that waits for an answer, with or without a computer, a comment that mentions another agent or a squad goes to them, and the question stays open. If you assigned the card to someone after the agent asked, it stays with that person and your comments no longer go back to the agent.

#Files and agent context on the computer

Before the agent starts, two things are put on its computer, and the agent reads them without asking for them.

Attachments. Files you attached to the card and to your comments (in a chat, the files attached to your messages) land in the inputs folder on the computer under their own names. Two files with the same name become report.pdf and report (2).pdf. If you attached a new version of a file, the agent gets the newest. Later work on the card sends only new or changed files. There is a limit to how much one start can send; a file that does not fit is not put on the computer, and the agent reads its text from Orbi instead.

Agent context. When knowledge every piece of work should have (a brand voice, writing rules, a product glossary) lives in a collection or a file, you can mark it as agent context. Marked collections and files are written to the context folder on the computer, and the agent reads the relevant ones before it starts.

• Collection: on the collection's Settings screen, turn on Give to agents as context in the Agent context section. The collection's purpose, its fields and its most recently updated records (up to 200) go.
• File: open the file and turn on the same switch in the details on the right. The file's text goes; a small file without text (a logo, for example) goes as it is. The mark covers every version of the file, and the agent always gets the newest.

Example: if you keep your brand voice in a collection called marka_sesi, turning the switch on in its settings is enough. From then on, every agent that writes knows those rules from the start.

Only workspace admins change the switch, and it shows only where the agent's own computer is turned on. The mark gives agents no new access: a piece of work gets only the collections and files in spaces that the work's owner can see and that the agent reaches from that card. A collection in a closed space does not go to work on a card in another space.

#Files the agent delivers

When the agent finishes a file on its computer (a Word document, an Excel sheet, a presentation, a PDF, an image), it delivers the file to Orbi. A delivered file lands where the work is:

• Card: it is added to the card's attachments and shows on the Files screen.
• Chat: it is posted in the chat as a message of the agent with the file.
• Flow: it is saved on the Files screen with the trace of the flow run; the agent names the file in the step's result.

Only the files the agent delivers leave the computer; drafts and notes stay in the work folder. The agent can deliver a file while the work is still running. A file delivered again under the same name becomes a new version of that file. A file can be at most 50 MB and counts toward the workspace's storage; when storage is full or a file is over the limit, the agent is told and either makes the file smaller or tells you.

#The open card is marked on the board

When you click a card, it opens in the column on the right of the screen. If you pinned the column to the right, it sits beside the board and the columns stay visible. If you did not, it opens on top of the board. The card whose drawer is open is marked on the board with a light purple background, a purple border and a raised shadow. So what you are reading in the drawer does not lose its place on the board. The same marking applies in the List, Backlog and Completed views, where a thin strip appears on the left edge of the row.

That marking deliberately looks different from the rows whose checkbox you ticked for a bulk action. A ticked row is neutral grey and the open card is purple. When one screen holds two different kinds of "selected", the two must not speak in the same colour.

If a card reached from a shared link (?task=), from global search or from a notification falls outside the visible area, the board brings it into view by itself.

#The right column: cards and chats in tabs

The cards and chats you open sit side by side as tabs in one column on the right of the screen. Clicking another card on the board opens a new tab and the earlier ones stay where they are. If you open a card or a chat that is already open, no second tab appears and that tab comes to the front. Each chat has its own tab, and the + button in the strip starts a new chat. A half-written answer or a chat that is still streaming is not lost when you switch tabs.

As tabs pile up they get narrower, and when they no longer fit the strip scrolls sideways. The ▾ menu in the strip lists every open tab, along with All chats…, Close others and Close all. Right-clicking a tab gives the same close options, and a middle click closes it. Open tabs are remembered for each workspace, so they are still there after a reload or when you come back from another workspace. The tab of a deleted card or chat closes on its own.

The pin button at the top right of the column pins it to the right.

• When pinned, the column sits beside the page and pushes the page to the left. Whether you move to the board, the calendar or any other screen, the column stays open in the same place.
• When not pinned, the column opens on top of the page. When you close it the page is exactly as it was.

This browser remembers the choice, so you do not have to pick it again each time. If your screen is narrower than 1280 pixels the column opens on top of the page even when pinned, because beside it the page would not have enough room left to use.

You set the column's width by dragging the handle on its left edge. Double-clicking the handle restores the default width, and the arrow keys work too. This browser remembers the width as well, and all tabs share it. While pinned, the column widens only as far as the page still has room; a wider choice applies again when the column opens on top of the page.

The card's number and title are written on the tab. While the card tab is in front, clicking the number copies the card's mention (such as @task.12) to the clipboard. Focus, full screen and the ⋯ menu sit in the column's strip, across from the tabs. To close the card or the chat, press the × on its tab. ⌘K (Ctrl+K on Windows) brings the chat tab you looked at last to the front, or opens your last conversation if no chat is open. If a chat tab is already in front, it closes it.

You change the card's state from the state label in its header. Clicking the label lists where the card can go from that state, with the most common move on top. Remove from board and Delete task are in the ⋯ menu in the strip.

Attachments on the card, in comments and in chats do not open inside the card. Clicking a file opens the detail window of the Files screen over the page, with editing, sharing and version history. A file mention such as @file.report in a description or comment opens the same window; an address that points to a mind model node opens it with that node selected. Closing the window leaves the card open. Details: The file manager.

#Opening a card full screen

The expand icon in the drawer's header opens the card on its own page. On that page the card's working area (the checklist, the comments, the outputs) takes the full width, and properties such as assignee, priority and due date sit in the right-hand column.

Opening the card full screen closes its copy in the right column, because the same card open in two places at once makes it unclear which view you are writing in.

The two surfaces do not replace each other, they are for different jobs.

• The drawer is for glancing at a card while you look at the board. The columns stay visible and Esc closes it.
• The page is for sinking into a single card, meaning writing a long comment, going through the checklist and reading the outputs. Here Esc does not take you off the page, and you go back to the board with the back button in the header. This is deliberate, because a stray key closing the page while you write a long comment was exactly the problem full screen is meant to solve.

The page has its own address, so you can send a card to a teammate as a direct link.

#Display options

Three separate things sit at the top of the Tasks screen, and they should not be confused.

• Scope says which tasks you are looking at, and it can be Active, Backlog or Completed.
• View says how the active tasks are drawn, and it can be Board (drag-and-drop columns) or List (a table with bulk selection). It appears in the Active scope only, because Backlog and Completed are lists already. Both views show the same tasks, only the drawing changes.
• Flows are not tasks but a separate kind of thing, which is why they sit apart from the scope tabs. The list here holds the flows of the project you are in, while the Flows row in the left menu shows the flows of every project together.

#Filters

The Filter button at the top right opens a single filter row. That row starts closed, because a filter bar that stayed open all the time took up screen space and pulled attention.

The same filter applies in all three scopes, so you do not have to search separately for Active, Backlog and Completed. Your selection is kept when you change scope, so picking a person and switching to Completed shows what that person has finished.

• Search searches within the card number, the title or the description.
• Assignee picks whose work you are looking at. People and agents sit in the same list, because the board hands out a task from a single list too.
• State appears only in the List view of the Active scope. On the board the columns themselves are the states, and Backlog and Completed each consist of a single state.

Filters can be used together. Pick a person and set the state to Review and you get "that person's tasks waiting for approval".

Even when you close the filter row, the number of active filters stays as a badge on the Filter button, and in the Active scope it also says how many tasks are left. Clear filter removes all of them at once. This is deliberate, because a user who sees no cards has to be able to tell "the board is empty" from "a filter hid them".

Filters belong to the project you are in. If you have more than one project, the red badge next to the project name in the left menu shows how many jobs are waiting for you in that project, so you see at a glance which board to open.

Filters show "what is mine". Seeing "what came from this flow or card" is the job of a separate tool, and that tool is Focus. The two work together, so filters stay available while focused.

#The table in List view

The columns run number · state · priority · assignee · title · due date · updated. The short fields come first and the one long field (the title) follows them, so that a scanning eye does not have to jump over a wide piece of text on every row.

You can sort by clicking any column header. A second click reverses the order and a third removes it.

#Archiving

Finished (Done) tasks can be archived in bulk. Archiving clears the board but does not delete data, so the task's history and outputs are kept.

The Completed list groups tasks by the day they were completed. Today, Yesterday and older days sit under separate headings, with the number of tasks finished that day next to each heading. The time on the right of the row shows when in that day the task was completed. So you can answer "when did we finish this" without reading the list line by line.

A task is stamped the moment it is completed. If you reopen a task and complete it again, it appears in the list with the latest completion date. In older versions of the product the completion time was not recorded, so a few very old tasks may not carry this information. They are gathered at the end of the list under the heading "Completion date unknown".