@UVUNIQUE

@UVUNIQUE is a REDCap action tag that checks a value against every other record as it is typed, with project, DAG or event scope and optional composite keys. REDCap has no native field-level uniqueness.

REDCap has no native field-level uniqueness. @UVUNIQUE checks the value against every other record as it is typed — a CSRF-protected module AJAX call, no page reload — with the usual message / confirm / block enforcement.

Syntax

@UVUNIQUE                       unique across the project

@UVUNIQUE=event                 scope: project | dag | event

@UVUNIQUE={"with":["site"],
           "message":"Specimen already registered",
           "blockSave":"hard"}

Scopes and composite keys

project (the default) — unique across the whole project.
dag — unique within each Data Access Group.
event — unique within the same event of a longitudinal project.
with makes the key composite: the value plus those fields together must be unique, such as a specimen ID within its site.

Under dag scope, records in no group form one group of their own. They are compared against each other, not exempted. "No DAG" is a scope like any other, and the alternative reading — that an ungrouped record has nothing to be compared with — would let the rule lapse exactly where records are hardest to attribute. Use project scope if you want them compared against everything.

Privacy posture

The endpoint answers only for fields that carry a unique rule, so it cannot be used to probe arbitrary fields for the existence of a value. Staff see the colliding record id only when it is inside their own Data Access Group. Comparison is exact, after trimming, against stored values.

Surveys: opt-in, and never on an identifier

Survey respondents are not logged in, so an "already used" answer tells anyone holding the survey link that a specific value is in the study — one value at a time. {"surveys":true} is therefore:

Off by default.
Answered as a bare yes/no, never a record id.
Rate-limited.
Refused outright on any field REDCap flags as an Identifier — there it would let a stranger test whether a named person is enrolled, so the module makes that a configuration error rather than trusting a warning to be read.

A reasonable use is a non-identifying response token, to stop the same person submitting twice. Leaving it off costs no data quality: survey submissions are still covered by the post-save audit and the Validation scan.

The race is audited, not denied

Two near-simultaneous saves can both pass the live check. The post-save audit re-checks the saved value against every other record and logs a collision as type: unique, reason: duplicate-value — review the module log for races. Any transport failure fails open: a network error never traps a save.

Field types

Text, Notes, dropdown, radio, yes/no, true/false and slider. Composes with the other modes on the same field.