Notion Select and Status columns not showing correctly in Framer

What a Framer Option field actually stores

A Notion Select property looks like free text. It is not. Each option in Notion is an object with a stable id and a display name, and Notion stores which option a row has by that id.

Framer CMS Option fields work the same way: the field owns a fixed list of cases, each with its own id and name, and an item points at one of those case ids. An Option field is a closed set decided when the field is created, not a text column that accepts any string you send it.

Framer's Notion plugin bridges the two by copying Notion's option list into the Framer field's case list at the moment the field is created, keeping Notion's ids as the case ids (data.ts). When it later syncs a row, it sets the value to the Notion option's id and lets Framer resolve it against that stored case list.

Everything below follows from that one design decision. It is a reasonable decision — it is what makes renaming an option in Notion not break every row — but it has three consequences nobody mentions until they bite.

Consequence 1: options added after setup do not appear

The case list is captured once, when the field is created. Add a new option to the Select in Notion afterwards — a new Status, a new property Type, a new Category — and that option has an id which is not in the Framer field's case list.

Rows using the new option now carry a value Framer cannot resolve. The column is not broken and the sync does not fail; the mapping simply has no entry for the value, so nothing about it is correct on the live site.

This is the usual explanation when a Select column worked fine for weeks and then started going wrong for new rows only. The rows that predate the new option are still right, which makes it look like a data problem in a handful of rows rather than a field-level one.

• Fix: re-run the field mapping so the case list is rebuilt from the current Notion options. In Framer's plugin that means opening it and stepping back through Manage → Import to the field mapping screen.
• Prevention: define every option you expect to need in Notion before you map the field. Adding options later always costs a re-map.
• If options change constantly — a tag list that grows weekly — an Option field is the wrong shape for that data. Map it to a plain text field instead and accept losing the dropdown.

Consequence 2: an empty Select silently becomes the first option

This is the one worth reading even if nothing on your site looks broken.

When the plugin cannot produce a value for a mapped field on a given row, it fills in a default rather than leaving the field empty. For text that default is an empty string, for a number it is zero, for a checkbox it is false — all harmless. For an Option field, the default it uses is the first case in the list (data.ts).

So a Notion row with the Select left blank does not arrive in Framer as blank. It arrives as whatever option happens to sit first in your Notion list. A property with no Condition set displays the first Condition. A post with no Category set displays the first Category.

Nothing errors. The sync reports success. The site shows confident, specific, wrong information, and it looks exactly like data you entered on purpose — which is why this can sit on a live site for months. It is also why a row using an option added after setup (Consequence 1) does not show as empty: it falls into this same path and comes out as the first case.

• Check for it: in Notion, filter the database to rows where the Select is empty. Then look at those exact rows on your site. If they are showing a value, this is what is happening.
• Fix it in Notion: give every row an explicit value. The cleanest way is to add an option named "None", "Unspecified" or similar, and set it on every row that would otherwise be blank, so the blank state is a real value you chose.
• Make the failure visible: if you cannot fill every row, order the Notion options so the first one is the safest possible thing to display by mistake. Putting "Unknown" first turns a silent wrong answer into an obvious one.

Worth being clear about our own position here: KnotCMS hit this exact bug in its own sync and fixed it in September 2026, so an empty Select now arrives as a real "None" rather than the first option. We are not describing someone else's mistake from a distance — we made the same one.

Consequence 3: renaming an option leaves a stale label in Framer

Because rows are matched by option id rather than by text, renaming an option in Notion does not break anything — the ids are unchanged, so every row still resolves to the right case. That is the upside of the design.

The downside is that the case name was copied into Framer when the field was created and is not refreshed by a sync. Rename "In Progress" to "Under Offer" in Notion and the rows keep pointing at the same case, but your live site keeps rendering "In Progress" until the field mapping is rebuilt.

This is a display-only problem, which is what makes it easy to miss. Nothing is wrong in the data; the labels on the site are simply out of date. The fix is the same as for a new option: re-run the field mapping.

Multi-select is a different problem

Everything above concerns Notion's Select and Status types, which map onto a single Framer Option field. Multi-select does not map at all in Framer's own plugin: it is not in the list of property types the plugin accepts, so attempting it produces Property type 'multi_select' is not supported. (api.ts).

The reason is structural rather than an oversight. One row holding three tags needs somewhere to put three values, and a single Option field holds one. Doing it properly means a second CMS collection holding the tags and a multi-reference field pointing into it, which is a different data model rather than a different mapping.

• Practical workaround: sync the multi-select as plain text — a comma-separated list — and render it as a string. You lose filtering and styling per tag, you keep the information. KnotCMS does this today; with Framer's plugin you would add a Notion formula property that joins the values and map that instead.
• If you need real filtering by tag: model it as a separate collection and references. No sync tool turns a multi-select into that for you, ours included.

Checking it in order

Fastest path from symptom to cause:

• The column is missing from Framer entirely. It was never mapped, or it is a multi-select. Re-open the field mapping and look for it there before assuming a sync problem.
• Old rows are right, new rows are wrong. An option was added in Notion after setup. Re-map the field.
• Rows you know are blank are showing a value. The first-case fallback. Fill the blanks in Notion.
• Every row shows the same value. Either the mapped property is empty on every row, or the wrong property was mapped. Check the mapping screen, then check the data.
• The value is right but the wording is old. An option was renamed in Notion. Re-map the field.
• None of the above. Search the framer/plugins issue tracker for the field type — the plugin is developed in the open and several field-level bugs are tracked there.

Where this leaves you

None of this is a bug in the ordinary sense, which is why it survives so well. Option fields are a closed set by design, and matching by id rather than by name is the right call. The cost is that the field has a setup-time snapshot inside it, and every later change to the Notion options quietly drifts away from that snapshot until someone re-maps.

The practical habit that avoids nearly all of it: decide your Select options before you map the field, fill every row rather than leaving blanks, and re-map after any change to the option list. That is true of any Notion to Framer sync, including our own.

Which sync you use does change how often you meet this. Framer's plugin re-reads the option list only when someone re-runs the import from inside the editor, so on a handed-off site the drift can sit for months before anyone looks. The comparison of KnotCMS, Framer's Notion plugin and on-page editing sets out the trade-offs, and is honest about where the free options win.

If a Select column is missing rather than wrong, the field may never have reached Framer at all — how the field mapping works covers what maps to what, and the sync troubleshooting page covers the errors that stop a sync before it writes anything.

Common questions