Trello card completion vs a Done list: define one closure policy

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Define what done actually means

A list called Done is a team convention; a card completion indicator is a separate piece of state. Decide which signal represents acceptance and which is simply a workflow location. Without a policy, a card can look finished in one view while an owner still regards it as awaiting review. This guide helps board administrators establish a consistent closure rule without deleting work.

Documented behavior to account for

Trello supports marking ordinary cards complete even without a due date; template and separator cards are exceptions. Completion has a green indicator and can be used in filters. Automation supports a completion trigger and a mark-complete action. Atlassian says older due-date-completion automations also apply to card completion, including cards without dates. The documentation includes a rollout caveat, so compare the described controls with the experience available in your Workspace.

Example: a design review board

Consider Draft, Review, Accepted and Delivered lists. A designer moving a draft into Review has finished drafting but the client has not accepted the deliverable. Recommend using card completion for the agreed terminal outcome, such as delivery after approval, and using lists to show intermediate progress. If the business instead wants acceptance to be terminal, document delivery as separate work. The right answer depends on what the card promises, not on the label of its rightmost column.

Audit existing rules before adding another

Inventory rules that react to a move into Done, a completed checklist, a completed due date or a completed card. Record the intended outcome of each: move, archive, notify or mark complete. Older wording can conceal a trigger that now fires on an undated card. Rehearse with one dated and one undated sample so a newly adopted completion convention does not unexpectedly archive work or send a duplicate notification.

Verify four cases

First, move an incomplete sample to the terminal list and inspect its completion state. Second, complete a sample elsewhere and inspect where it ends up. Third, reopen a completed sample and check whether its workflow location makes sense. Fourth, complete a recurring sample and inspect the next occurrence. Record the observed result against the written policy; these checks are a proposed procedure rather than tests we have run in a customer account.

Close without hiding unresolved work

Choose a single deliberate entry point for normal closure, such as reviewer acceptance followed by completion. Keep archiving as a separate housekeeping decision unless the team has explicitly agreed otherwise. Preserve an owner-readable explanation when reopening accepted work, and check that filtered views expose the items people still owe. A reliable policy makes contradictory states easy to identify and repair rather than merely making the board look tidy.

Continue with the Trello implementation guides.