What this screen is for
Areas divide a project by subject rather than by time: which component, module, site or team a piece of work belongs to. They are arranged as a tree, so a root area can hold child areas beneath it, and each row shows how many work items are filed against it.
You choose a project first, then add root areas and children within them. An area that has child areas, or that still holds work items, cannot be deleted, which prevents work being orphaned.
When to use it
Set areas up once a project is large enough that "which part of it?" is a useful question. Once they exist, the Area filter on the work-items grid and the Area column on each row become meaningful.
What you see on this screen
Areas are shown as a tree rather than a table. Each row carries:
- Area name — indented to show its depth, so a child sits beneath its parent.
- A count — how many work items are filed against that area.
- Three actions — Add child, Edit and Delete.
Filters and actions
Choose a project first; until you do, the page simply says to select one. Root Area adds a top-level area, and Add child adds one inside an existing area. The form takes a single area name and shows the parent path above it, so you can see where the new area will sit.
There is no search or filter here, and no bulk actions. Deleting refuses where an area has children or still holds work items, which is what stops work being left with nowhere to belong.
Related
- Iterations — the same idea applied to time rather than subject
- Work Items — where areas are assigned and filtered on