---
title: Assign an Owner
slug: assign-owner
kind: pattern
summary: Exactly one named person is responsible for a record at any moment, visible on the record and filterable across the collection.
problem: >-
  Work that belongs to everybody belongs to nobody. A shared list gets read by
  four people who each assume one of the others has it, and the item sits until
  it becomes urgent — at which point the first question is still "whose is this?"
family: [coordinate, workflow]
data_shape: [record, collection]
principles: [orientation, surface-dont-bury]
interaction: [selection, decision]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - More than one person can act on the same records.
  - Items can sit without anyone noticing.
  - People ask "who is dealing with this?" out loud, and nobody can answer it.
avoid_when:
  - One person does all of it. The field is noise.
  - The work is genuinely a pool that anyone picks from on demand — use a queue with a claim instead.
  - Assignment would be theatre, with no authority attached to it.
alternatives:
  - slug: review-queue
    when: Work should be pulled by whoever is free, not pushed to a named person.
  - slug: handoff-workflow
    when: Ownership moves between teams at defined points, and the transfer is the important part.
ask_leo: |
  Add an owner to this record type.

  - One owner at a time, a real person, not a team. Watchers and collaborators
    are separate fields — the owner is the one accountable.
  - Show the owner on the record header and as a column in the list, so
    "whose is this" never needs asking.
  - Make the collection filterable by owner, and give people a one-click
    "assigned to me" view. That view is what makes the field useful rather than
    decorative.
  - Allow unassigned as an explicit state, show it distinctly, and surface how
    many unassigned items exist. Unassigned work is the thing this pattern
    exists to make visible.
  - Record every reassignment in the record's history with who changed it and
    when.
  - Notify the new owner when something is assigned to them, and let them see
    everything they own in one place.
  - When someone is deactivated, do not silently orphan their records. Surface
    them for reassignment.
related:
  - title: Activity Timeline
    url: /patterns/activity-timeline
    summary: Where reassignments are recorded, and how ownership disputes get settled.
  - title: Lifecycle Status
    url: /patterns/lifecycle-status
    summary: Owner answers WHO; status answers WHAT NEXT. Most records need both.
---

## Anatomy

```
  Unassigned (4)  ← surfaced as a count: this is the point of the pattern
  ─────────────────────────────────────────────────────────
  JOB-118  Framing level 3      ○ Unassigned      6d old
  JOB-121  Riser boarding       ● Dana            2d old
  JOB-124  Second fix           ● Priya           1d old
                                 ↑ one person, filterable, in the list
```

Three properties, and the third is the one that makes it work:

1. **One person**, not a team. A team owner is the same ambiguity with a
   different label.
2. **Visible in the list**, not only on the record. Ownership you must open a
   record to see cannot be scanned.
3. **Unassigned is an explicit, counted state.** The value of the field is
   almost entirely in making the gap visible.

## Why it works

Diffusion of responsibility is a real and well-documented effect: the more
people who could act, the less likely any individual does. Naming one person
removes the ambiguity that the effect depends on.

The "assigned to me" view is what converts the field from data into behaviour.
Without it, ownership is something you can look up; with it, ownership is a
worklist, and people work their list.

Making unassigned visible and countable is the other half. In most teams the
useful number is not who owns what — it is **how many things nobody owns**,
because those are the items that will surprise someone later.

## Owner is not status

These get conflated and they answer different questions. **Owner is who; status
is what next.** A record can be owned and blocked, unowned and urgent, owned and
finished. Folding them into one field — an "Assigned" status — loses one of the
two answers, usually the one you needed.

## Getting it wrong

- **A team as the owner**, which reproduces the original problem.
- **Multiple owners**, same.
- **Owner only on the record**, so it cannot be scanned or filtered.
- **Unassigned hidden or treated as an error state**, so gaps stay invisible.
- **Assignment with no notification**, meaning the owner does not know.
- **Assignment with no authority**, where the named person cannot actually
  decide anything — this is the version that breeds cynicism fastest.
- **Orphaned records** when someone leaves, discovered months later.

## Exemplars

**Linear** treats assignee as a first-class field with a keyboard shortcut and a
default "my issues" view, which is why assignment is habitual rather than
administrative.

**Intercom's conversation ownership** shows the pattern in a shared-inbox
context: the assignment is what stops two agents replying to the same customer.

**GitHub issues** demonstrates the counter-case honestly — assignment is
optional and often unused on open-source projects, and the result is exactly the
diffusion this pattern prevents. It works there because the maintainers are the
implicit owners; in a business, implicit ownership is the problem.

The extractable rule: **the value of an owner field is the unassigned count.**
If nobody ever looks at what is unowned, the field is administration rather than
coordination.