Assignment

Problem Context

• Assignment may appear on issues, pull requests, tasks, tickets, comments, documents, forms, cases, approvals, incidents, projects, or queue rows.
• Assignable targets may include one person, several people, a team, a role, a bot, an automatic default owner, or an explicit unassigned state depending on product policy.
• The assignee may be responsible for doing the work, taking the next action, shepherding completion, merging, responding, or coordinating a handoff.
• The assignment change may notify the assignee, update assigned-to-me views, change queue membership, affect workload dashboards, or fail if permissions or membership are missing.
• Assignment often sits near mentions, reviewers, approvers, watchers, collaborators, owners, and permission grants, so the difference must be visible.

Selection Rules

• Choose assignment when the primary action is setting or changing who is accountable for a specific work item.
• Use mentions when the user only needs attention in a comment or discussion and no responsibility record should be created.
• Use review queue when assignment is one action inside a larger workload triage surface with queue counts, reasons, stale-row checks, and next-item behavior.
• Use approval workflow when the person is asked to make an approve/reject decision under a route rule rather than own the work item.
• Use task list when users are scanning fixed service tasks and statuses; an assignee may appear in each row but does not define the list.
• Use object picker for the reusable search-and-select control, but add assignment-specific eligibility, responsibility, notification, and reassignment rules around it.
• Use permission sharing when the change grants access; assignment should either require existing access or explicitly handle access-grant side effects.
• Use activity feed and notification center to communicate assignment changes, but keep the source of truth on the assigned item.
• Show current assignee and unassigned state before asking users to choose a new person.
• Distinguish single-owner accountability from multi-assignee collaboration and state the product's limit or policy.
• Preview bulk assignment scope, current owners, hidden selected items, ineligible items, and notification count before applying.
• Prefer explicit automatic assignment labels when defaults come from component, team, project, or space settings rather than a user's direct choice.

Required States

• Unassigned item state.
• Assigned to one person state.
• Assigned to multiple people state where product policy allows it.
• Assigned to team, role, bot, or automatic default owner state.
• Self-assign state.
• Reassign state with previous assignee visible.
• Clear or unassign state.
• Eligible candidate search and no matching eligible assignee state.
• Ineligible candidate due to permission, membership, workload, availability, or policy.
• Bulk assignment preview with selected count and exceptions.
• Notification sent, notification suppressed, and notification failed states.
• Assigned-to-me view synchronization state.
• Handoff note or reason-required state.
• Assignment conflict or stale item changed since load state.
• Mobile compact assignment row state.

Interaction Contract

• Opening assignment shows the current assignee, candidate eligibility, and whether the item supports one assignee, multiple assignees, teams, bots, or automatic assignment.
• Selecting an assignee updates the work item's assignment record and any assigned-to-me, queue, activity, and notification surfaces governed by the product.
• Self-assign, reassign, clear, and bulk assign controls apply to the named item or previewed item set only.
• The product refuses or warns before assignment to people who cannot access, cannot act, are outside policy, or are not valid candidates.
• Reassignment preserves previous owner, time, actor, and optional handoff note in activity or history.
• Bulk assignment previews selected count, hidden filtered rows, existing owners, ineligible rows, notification recipients, and partial failures.
• Assignment does not silently grant permissions, invite users, approve requests, request review, or mention people unless the UI says so.
• A stale assignment save checks whether the item owner changed since the picker opened and offers refresh or override recovery.

Implementation Checklist

• Define assignment semantics for each object type: single responsible owner, multiple assignees, team assignment, role assignment, bot assignment, automatic owner, or unassigned allowed.
• Model assignment separately from creator, reporter, reviewer, approver, watcher, subscriber, mention, collaborator, and permission roles.
• Build an eligibility query for candidates based on membership, permissions, role, team, availability, workload, project scope, blocked users, external guests, and automation accounts.
• Add controls for self-assign, search/select, reassign, clear, automatic default, handoff note, notification toggle when allowed, and bulk assignment preview.
• Synchronize assignment changes with assigned-to-me lists, review queues, activity feeds, notifications, object history, workload views, and API responses.
• Handle no eligible candidates, stale assignment conflicts, partial bulk failure, permission loss, deleted users, suspended users, team removal, automatic default drift, and notification failure.
• Test keyboard search and selection, screen-reader names, duplicate display names, long team names, multiple assignee wrapping, mobile layout, high zoom, bulk preview, and assignment updates from another user.

Common Generated-UI Mistakes

• Treating a mention as an assignment.
• Using assignment as an access grant without explaining permission changes.
• Hiding whether the product supports one assignee or many.
• Mixing assignee, reviewer, approver, owner, watcher, and collaborator in one unlabeled people list.
• Allowing assignment to people who cannot open or act on the item.
• Silently auto-assigning work without naming the default rule.
• Bulk assigning hidden rows without count, current-owner, or exception preview.
• Removing prior owner and handoff context during reassignment.

Critique Questions

• What responsibility does the assignee take on, and how is that different from a mention, reviewer, approver, watcher, or collaborator?
• Who is eligible to be assigned, and what happens when a candidate lacks access or is outside policy?
• Does the product support one owner, many assignees, teams, bots, or automatic defaults?
• What notification, assigned-to-me, queue, workload, and activity changes happen after assignment?
• Can users see previous owner and handoff context after reassignment?
• How are bulk assignment, stale owner changes, deleted users, no eligible candidates, and notification failures handled?