# How assignment works Assigning a task says **who it is for**. It does not lock anyone else out. Any one of a task's assignees can close it. Someone who is not an assignee can still close it, and the fact that they did is recorded. That is the whole model. ## Assigning a task In the [builder](building-a-workflow.md), select a task and use **Assigned to** in the panel on the right. Start typing and the box offers the people in your organization and any [groups](groups.md) you have defined. Pick as many as you like. The app's own summary of the rule, from that panel: > Any mix of people and groups -- any one of them can close the task. A group means > whoever is in it at the time, not the people in it today. Still a soft gate: > someone else completing it is warned and recorded as an override, not blocked. Assignment is set on the workflow, so it applies to every checklist generated from it afterwards. The one exception is a task with no assignees, which anybody can take on a checklist already running -- see [taking an unassigned task](#taking-an-unassigned-task). ## An empty box means anyone A task with no assignees is open to anyone. This is the right setting for most tasks in most workflows -- it is a default worth keeping, not a gap to fill in. Assigning **narrows** a task. It never widens one. ## Taking an unassigned task Open to anyone is honest about who *may* do a task and silent about who *will*. On the checklist, an unassigned task says how long it has been that way: > This task has been unassigned for 6 days. Press **Assign me** and it is yours. Your name goes on the card, the task moves into your list on [My work](my-work.md), and it leaves the **Open to anyone** section for everybody else. It is still a soft gate. Somebody else can complete a task you have taken, and the checklist records that they did, exactly as it does for a task the workflow assigned. This is the only assignment made on a checklist rather than on the workflow. It changes nothing about the workflow itself, and the next checklist generated from that workflow starts with the task open to anyone again. Press **Unassign me** to give the task back. It returns to Open to anyone for everybody, and anyone can take it after that. Only a task the workflow left open can be taken this way. A task the workflow assigned already says who it is for, and nobody can take it from them -- to change who it is for, change the workflow. ## Any one of them, not all of them If a task is assigned to three people, the first of the three to close it closes it. The other two are not asked, and nothing waits on them. Flightplan has no multi-approval task. If you genuinely need two people to sign off, make it two [tasks](tasks.md), one waiting on the other. ## Groups are resolved when the task is worked Assign a task to a [group](groups.md) -- "Sr. Devs", "Night shift" -- and it belongs to whoever is in that group *at the moment someone works it*, not whoever was in it when the workflow was written. Add someone to a group and its tasks become theirs immediately, including on checklists already in flight. Remove them and the tasks stop being theirs the same way. This is the reason to prefer a group over naming three people: the workflow does not need editing when the team changes. ## It is a soft gate Open a task that is not assigned to you and you get a warning, not a wall: > **This task is not yours.** It is assigned to any Member. You can still complete > it -- it will be recorded as an assignment override on the audit trail. The **Complete task** button still works. Press it and the checklist records that you closed something assigned to someone else. This is on purpose. A hard lock means the one person who can sign off is on a plane and the whole checklist stalls. A soft gate keeps the work moving and keeps the record honest -- you can see afterwards that it happened, and ask why. ## Where overrides show up On the finished [summary](checklist-summary.md), overrides get their own section above the task table: > **Assignment overrides -- 1** > QA sign-off was assigned to any Admin -- completed anyway by Sam Ortiz Nothing is hidden and nothing is flagged as wrong. It is simply on the record. ## Admin and Member badges Some tasks show an **Admin** or **Member** badge instead of a person's name. Those are older assignments, made against your organization's roles before groups existed. They still work -- anyone with that role in the organization counts as an assignee. You cannot create new ones; the picker offers people and groups only. If you are editing an old workflow, replacing a role badge with a [group](groups.md) is the better shape. ## Who can do what else Being an assignee is about tasks. One thing in the app goes by your organization role rather than by assignment: managing **Connections** is limited to organization admins. Everything covered in this help center -- building workflows, generating checklists, working tasks, creating groups -- is open to any member. ## Next - [Groups](groups.md) - [The checklist summary](checklist-summary.md)