> For the complete documentation index, see [llms.txt](https://help.tahua.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tahua.io/product-news/2026/readme/primary-verifier-select-field-designation.md).

# Applicant Verifier Select field designation

## Problem

A Formnflow form template can contain multiple Verifier Select fields — for example, one where the applicant chooses their verifier and a separate one where staff record a verifier for an individual team member. Previously, every Verifier Select field triggered `assign_verifier!` when its value changed, so any field could silently overwrite the funding application's verifier.

## How it works

A new boolean column, `primary_verifier_select`, is added to each Verifier Select field. Only the field flagged as the primary verifier select drives `assign_verifier!`; all others store their value normally without side effects.

**Default behaviour on creation:**

* The first Verifier Select field added to a template is automatically designated as the primary one (`primary_verifier_select: true`).
* Every subsequent Verifier Select field defaults to `false`.

**Mutual exclusion:**

* Enabling `primary_verifier_select` on one field automatically disables it on all other Verifier Select fields in the same template, ensuring exactly one field controls verifier assignment at any time.

## UI changes

In the form builder, a checkbox labelled **"Applicant verifier select"** appears in the field context bar whenever a Verifier Select field is focused. Checking it designates that field as the primary verifier select; unchecking designates it as a secondary field.

## Data migration

Existing templates require a one-off data migration (see `DATA_MIGRATIONS.md`) to mark the earliest Verifier Select field per template as the primary one.