Tell people when a value is already in use
Finding out that a chosen name is unavailable after completing a whole form is frustrating. Wildo can check a unique field when the person leaves it, so the problem appears while the value is still in focus.
The check follows the field’s declared uniqueness scope. A name that must be unique inside one organization can still be used by another. When editing a record, the check can exclude that record itself, so keeping its existing value does not create a false conflict.
This is early guidance backed by the server. The database constraint remains the final authority when the record is saved, including when two people choose the same value at nearly the same time.
Example — Choose a shareable list name
A team creates a task list with the short name launch-plan. If another list in that organization already uses it, the form can ask for a different name immediately. Another organization can use its own launch-plan because the uniqueness rule is scoped to the organization.
For engineers
Declare what makes the value unique
Wonder Todos’ todo-lists.schemas.ts defines an optional URL-safe slug with organization-scoped uniqueness. This excerpt includes neighboring list fields to show the rule in its resource context; source comments are omitted:
status: z.enum(TodoLists_Status).default(TodoLists_Status.ACTIVE).isSummaryField(),
name: z.string().min(1).max(100).isSummaryField(),
description: z.string().max(500).optional(),
attachments: z_file({
multiple: true,
nature: FileNature.ALL,
}).optional(),
isPublic: z.boolean().isDBIndexed().default(false),
color: ZodTypeForColors.optional(),
slug: z.string().min(1).max(60).regex(/^[a-z0-9-]+$/).isUnique({ scope: 'organization', sparse: true }).optional(),
createdAt: z.date().isDBIndexed().excludeFromCreate().excludeFromUpdate(),
updatedAt: z.date().isDBIndexed().excludeFromCreate().excludeFromUpdate()
The slug combines ordinary string validation with isUnique({ scope: 'organization', sparse: true }). The regular expression describes the accepted value, the scope determines which records compete for it, and sparse uniqueness allows lists without a slug.
Make the validation route available
The resource must have exactly one default, non-bulk, URL-bearing CREATE operation. The route initializer uses that operation’s URL and authorization context to mount the field-validation endpoint. A repository-only CREATE does not provide that HTTP route.
| CREATE configuration | Live validation route |
|---|---|
| One eligible default CREATE | Mounted using that operation’s routing context. |
| No eligible default CREATE | Not mounted for this resource. |
| More than one eligible default CREATE | Rejected as ambiguous instead of choosing one. |
This matters for an edit form too: the preflight uses CREATE authorization even when excludeId tells the uniqueness query to ignore the record being edited. Permission to UPDATE alone is not a promise that this feedback route is available.
Let the field ask the backend
FormField connects unique fields to useFieldUniquenessValidation. On blur, the hook sends the field name, value and, for an edit, the current record identifier to the resource’s POST /validate-field route. Starting another nonempty uniqueness check aborts the previous request.
The endpoint validates the request and uses the resource’s CREATE authorization context. Its uniqueness strategy reads the actual field declaration, adds organization or user scope where required, and excludes the current record for an update check. A conflict becomes a field validation result that the form can display next to the input.
Keep feedback and persistence distinct
Network failure leaves this optional feedback nonblocking; it is not evidence that the value is unique. If required organization or user context is missing, the uniqueness strategy skips the lookup rather than broadening it into a global query.
A successful check says that the value was available when checked. It does not reserve it. The unique index still decides whether the later write succeeds, and the normal API error path handles a competing write.
Use this mechanism for declared uniqueness, such as a slug, external reference or account code. More involved business checks belong to their own validation or operation logic; the live endpoint’s current strategy is uniqueness rather than a general execution surface for arbitrary rules.