Tagify Store New Tags

Let Tagify create new tags deliberately and store them cleanly when your data model allows user-generated labels.

Introduction

Demo Projects HQ gives you a disciplined baseline on the task edit form: the existing Tagify field still points at curated data and still submits through tags[]. That makes it the right place to explain how you would safely extend the field for new-tag creation. The key is not just removing one restriction. The key is keeping display, validation, and persistence aligned after you let editors invent new values.

Start from the current working field

The edit form already proves the page can reload existing tags coherently, so it is the right baseline before relaxing the rules.

Creation changes both UI and data rules

Allowing new tags affects suggestion behavior, server validation, and how future edits reload the tag list.

Use the existing task edit field as the baseline before enabling creation.

Identify which property currently keeps the field selection-only.

Preserve the tags[] posting contract even when values are newly created.

Feed accepted new tags back into the available source so later edits stay consistent.

Edit-form Tagify field selected

This is the same kind of Tagify control, now on the edit page where previously saved tags are reloaded. That makes it the right place to think about what happens after a brand-new tag has been accepted and the user later revisits the record.

Properties panel shows the current guardrails

With the edit-form Tagify field selected, use the Properties panel as the control surface for the creation policy. This is where you can read the current selection-only setup first, then reason about which settings would need to change before new tags can be introduced safely.

No Custom is the baseline guardrail

Right now this property is the clear indicator that the field is still selection-only. As long as No Custom stays enabled, the edit form expects every token to come from the known source. If you later allow new tags, this is the property you review first because it changes the author’s editing freedom immediately.

Keep the Name contract stable when creation is allowed

Even after you allow new tokens, the form still needs to submit them through the same predictable name. On Demo Projects HQ that means keeping the tags[] contract stable so the server receives a coherent array of selected or newly created values instead of a widget-specific payload shape.

The Data Source must learn about accepted new tags

Once a new tag is stored, future edits should load it like any other known option. That is why the Data Source matters even more after creation is enabled: the source has to be refreshed or extended so the tag comes back as part of the legitimate whitelist instead of looking like an accidental one-off value.

tip: Creation is not complete until the next edit session can rediscover the accepted tag through the same source.

Value Field still decides what becomes canonical

If editors can create a new tag, you still have to decide what canonical value the application stores. Value Field is where that decision stays explicit. Use it to separate human-readable labels from the token or identifier your backend will normalize and persist.

Limits stay useful after creation is enabled

Once users can invent tags, Max Tags, Min Chars, and the rest of the dropdown limits become even more important. They keep the field from becoming noisy, help editors focus on the strongest matches first, and reduce the chance that the UI turns into an uncontrolled freeform input.

Next steps

The task edit form shows the right way to think about new-tag storage: start with the current selection-only field, relax the right guardrail, keep the tags[] contract stable, and make sure accepted values come back through the same source on the next edit. That is what turns Tagify creation from a UI trick into a durable data workflow.