Notion Status vs Select: Which Property Fits Project Tracking?

Use Status for a project’s progress and Select for a single category, such as project type or priority. Status organizes its options into three progress groups: To-do, In Progress, and Complete. Select gives you one choice from a list without those progress groups. These are separate meanings in Notion’s property definitions, and a project database can use both.

I’d start a new project tracker with Status for progress. Keep Select for answers that remain true while the work advances: a website migration is still a migration when it moves from drafting to review.

Choose by the field’s meaning

Select holds one category; Multi-select allows several tags. A field that mixes “Migration” with “In review” needs separate classification and progress properties before it needs a different color.

A Kanban layout does not settle the choice. Notion boards can group by Select as well as Status. An existing Select-based board can remain useful if its labels and views already answer the team’s questions.

Status groups give custom stages a common meaning

Status has two levels: the fixed progress group and the detailed option selected for a record. You can add custom options within each group, but the three main groups cannot be changed.

For a small delivery workflow, you could put “Not started” in To-do; “Drafting” and “Awaiting approval” in In Progress; and “Delivered” in Complete. Here, awaiting approval still counts as ongoing work. That definition matters more than the label’s color.

Agree on the ambiguous options before adding them. “Blocked” might mean work cannot start, or that work has started and then stopped. Put it in the group that matches your definition and write down the distinction for the team.

Completion also needs a clear meaning. If a canceled project and a successfully delivered project both require no more work, you might classify both as terminal, then store the result separately in an Outcome Select property. Keep successful delivery distinguishable from cancellation in reports. If the field represents a classification that does not fit the three progress groups, Select remains the cleaner choice.

Set up progress and project type separately

Use two properties with names that describe their purpose: Project status and Project type. An example record could read “Website migration,” with Project status set to “Awaiting approval” and Project type set to “Migration.” A person reviewing it can tell both the kind of work and the next concern.

1. Open the database settings and select Edit properties, then New property.
2. Name the progress property Project status and choose Status.
3. Add the detailed status options under the appropriate progress groups.
4. Add Project type as a Select property and define its categories.

This uses the current property-management controls; the older Status guide shows an earlier menu path. Keep the category list small enough that each option has a distinct meaning.

If you are organizing clients, projects, and tasks as separate records, keep this choice within that model. The client project tracker guide explains the relationships between those databases.

Use groups for an overview and options for the next action

Status helps when the team needs a broad view of progress without losing detailed stages. In an ongoing-work view, filter the Status property by the In Progress group. Notion’s Status guide documents this group filter. Your “Drafting” and “Awaiting approval” options can both belong to that overview.

For a review queue, use the specific “Awaiting approval” option so it answers a narrower question. Check the view’s filter settings when adding a stage: a filter for one option and a filter for its entire group represent different scopes.

Status can also display as a checkbox. I’d retain the detailed label in a project review, where “Awaiting approval” calls for a different action from “Drafting.” Use the compact display where the completion check is enough.

Check the views against a small record set

Before applying the setup throughout a database, use a few records whose meaning is easy to inspect. This example uses the custom options defined above:

With no other restrictive filters, an In Progress group filter should include Homepage copy and Website migration. An Awaiting approval option filter should include only Website migration. Staff workshop belongs in neither of those views. These expectations follow the documented group-filter behavior.

If a record appears in the wrong view, inspect its selected option, that option's assigned group, and the view's full filter condition. Changing a Project type value should not be your repair for a progress-group mistake. Add a blocked or canceled sample from your own workflow when those meanings matter, and compare it with the definitions the team agreed on.

Keep an existing Select until the replacement is ready

Switching types is a schema change. Make it for a concrete benefit, such as filtering all ongoing stages together. Preserve the old values and document the current rules before changing live records. An export is useful for reference, but a Notion backup needs more planning than an export alone.

When there is room for another property, I recommend adding Status alongside the existing Select. Map each old progress option to its new option and group; move category values into their own field. Check representative records before updating the rest, including a completed item and any blocked or canceled item. Keep the original field until the new values and dependent views have been checked.

Review rules that read the old property, including templates, automations, and formulas. A group filter does not make a formula’s label comparisons equivalent: Notion’s overdue-project example compares Status with the exact option “Done”. A new “Delivered” option requires a deliberate review of that condition, even if you place it in Complete.

Before retiring the old field, inspect both the broad ongoing-work view and the detailed review queue. Confirm that the same representative records appear where expected and that completed or canceled work follows the definitions the team agreed on.