Sections vs. Custom Field: Modeling a Five-Stage Pipeline
A marketing ops team runs campaign production in one project. Work moves through five stages: Brief, Draft, Review, Approved, Published. Each task also belongs to one of six campaign types (Email, Social, Webinar, Paid, PR, Event) and is owned by one of nine people. The team currently uses sections for the five stages and a single-select custom field for campaign type. They want to add a second dimension: a 'Workstream' (Brand, Demand Gen, Lifecycle) that cuts across stages. A teammate proposes converting the five stages into a single-select 'Stage' field and using sections for the three workstreams instead, arguing 'sections are just another field.' Leadership wants a board view grouped by stage, plus a calendar of publish dates, plus a per-workstream workload count.
1. Evaluate the proposal to swap sections and stage. Which structure best serves the three required views, and why?
Read the worked answer
The proposal inverts the two constructs and makes the required views harder, not easier.
The key asymmetry: a task lives in exactly one section, but can carry many custom fields. Sections are a single partition of the project; custom fields are orthogonal metadata. The team has two cross-cutting dimensions (stage and workstream) plus campaign type. You can only put one of them in sections.
Which one belongs in sections? The dimension that is (a) the primary axis people scan by, (b) changes most often as work progresses, and (c) benefits from being the literal container in list and board views. That's stage - it's the pipeline, and 'where is this?' is the dominant question.
So: keep the five stages as sections, add Workstream as a second single-select field alongside campaign type. Then:
- Board grouped by stage → works natively, since stage is the section.
- Calendar of publish dates → needs a date field regardless; unaffected by the section choice.
- Per-workstream workload → a filtered/grouped count on the Workstream field. This is easier with workstream as a field, because you can group and filter by it without restructuring the project.
If workstream were the section, the board-by-stage requirement would force a grouping that fights the container, and every stage transition would become a field edit that doesn't move the task between visible columns.
2. The team says 'sections are just another field, so it doesn't matter.' Identify the concrete behaviors where sections and single-select fields diverge, and explain which divergence matters most for this team.
Read the worked answer
They are not interchangeable; the divergences:
| Behavior | Section | Single-select field |
|---|---|---|
| Cardinality per task | Exactly one | One value per field, but many fields coexist |
| Moving a task | Drag between containers; task physically relocates in list/board | Edit a value; task stays put unless a view groups by it |
| Automation triggers/actions | Rules can move tasks between sections; section membership is a common trigger condition | Rules can set field values; field changes are triggerable |
| Forms | A form can target a specific section on submission | A form can pre-set a field value |
| Templates | Template tasks can be pre-placed in sections | Template tasks can carry pre-set field values |
| Multi-dimension | Consumes the one container slot | Unlimited orthogonal dimensions |
Which matters most here: the container slot. The team has three dimensions and only one section axis. Choosing stage for sections preserves the ability to slice by workstream and campaign type simultaneously; choosing workstream burns the container on a secondary cut and forces stage into a field that then has to be re-grouped in every view. The 'it doesn't matter' claim is only true for a project with a single dimension.