> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminus.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Letting submitters enter new values

> Use a Text field with Suggest from past entries so submitters can type new values while the form nudges them toward spellings the account has already approved.

<Info>
  **Goal:** let a submitter enter a value that no admin has pre-approved, without losing consistency. A **Text** field with **Suggest from past entries** turned on shows an autocomplete of the values already saved on approved records for that field, so people converge on the same spellings while staying free to type something new.
</Info>

## When to reach for this

A [dropdown field](/reference/fields/dropdown) backed by a picklist is a closed list: submitters pick from what the published model offers, and only an admin can add options. That is the right shape for a vocabulary you want reviewed before it changes.

Some values churn too fast for that loop. Partner names, event titles, one-off placements: by the time a ticket reaches an admin, the campaign has shipped. For those, keep the field as **Text** and turn on **Suggest from past entries**. You trade the hard guarantee of a closed list for suggestions that make the consistent choice the easy one.

<Note>
  Earlier versions of Terminus Hub had an "Allow new values" toggle on static picklists that let submitters propose options from inside the form. That capability was removed: a picklist's option set is now fixed at publish time, and only an admin changes it. This recipe is the replacement. If a dropdown in your model relied on submitter-added values, convert it to a Text field as shown here; nothing converts automatically, because a closed list and free text with suggestions are different shapes.
</Note>

## Prerequisites

* A governance model you can edit and permission to publish it.
* Some approved records, if you want to see suggestions right away. Suggestions come from values already saved on approved records, so a brand-new field starts with none.

## Steps

<Steps>
  <Step title="Create or convert the field">
    In **Fields**, create a new field (or open the one to convert). Name: `partner_name`. Type: **Text**. If you are converting an existing dropdown, change its type to Text; the field keeps its name and placement in taxonomies.
  </Step>

  <Step title="Turn on Suggest from past entries">
    In the field's settings, turn on **Suggest from past entries**. It is off by default. Save the field.
  </Step>

  <Step title="Add guardrails with text validation">
    Suggestions nudge, they do not enforce. Use the Text field's own settings to rule out the messiest variants: set **Transform case** to `lowercase` so `Acme` and `acme` collapse into one value, and **Transform spaces** to `replace_underscore` if the value ends up in URLs. Add allowed character rules if the value feeds a strict downstream system.
  </Step>

  <Step title="Publish the governance model">
    Publish so the change reaches submitters. Field setting changes, like every model edit, take effect when published.
  </Step>

  <Step title="Fill a submission and watch the suggestions">
    Start a submission on a taxonomy that includes the field. As you type in `partner_name`, previously approved values that match appear as suggestions. Pick one to reuse it, or keep typing to enter something new. Either way the form accepts the value.
  </Step>
</Steps>

## How suggestions behave

* **They come from approved records.** A value starts appearing as a suggestion once a record carrying it is approved. Draft submissions do not feed the list, so a typo in an unapproved draft never spreads.
* **They are account-wide.** Suggestions are drawn from the field's values across your whole account, not just the current workspace. Everyone is nudged toward one shared vocabulary, which is the point.
* **They are non-binding.** A submitter can always ignore the suggestions and type a new value. If you need hard enforcement, that is a [dropdown with a picklist](/reference/picklists/static), not this.

## Verify

* With at least one approved record carrying `partner_name: acme`, start a new submission and type `ac` in the field. `acme` appears as a suggestion.
* Type a brand-new value instead and save. The row validates; free text is always accepted.
* Approve that submission, then start another one. The new value now shows up as a suggestion too.

## Gotchas

* **Reviewers are the quality gate.** Nothing stops a submitter from typing a near-duplicate (`Acme Corp` next to `acme`). Transforms and character rules catch the mechanical variants; reviewers should still scan new values before approving. See [review and approve submissions](/guides/review-and-approve-submissions).
* **Suggestions lag approval.** A value entered this morning does not suggest this afternoon unless its submission was approved in between.
* **Converting a dropdown loses the closed-list guarantee.** After conversion, past records keep their values, but new submissions accept any text the validation settings allow. Convert only fields where that trade is deliberate.
* **This is a per-field setting.** Each Text field opts in on its own; there is no account-wide switch.

## Related

* [Text field](/reference/fields/text): all validation and transform settings.
* [Static picklist](/reference/picklists/static): the closed-list alternative.
* [Dropdown field](/reference/fields/dropdown): when picking beats typing.
* [Review and approve submissions](/guides/review-and-approve-submissions): where new values get human eyes.