---
title: "Participant identification"
description: "How Signer identifies a person by CPF and e-mail, how it links a participant to an existing user, the uniqueness rules, foreign signers and single sign-on (SSO)."
canonical: "https://docs.lacunasoftware.com/en-us/articles/signer/concepts/participant-identification"
locale: "en"
product: "Signer"
last_updated: "2026-10-22"
---

# Participant identification

Every participant of a document is a Signer **user**. When you create a document, Signer looks for an existing
user for each participant. If it finds none, it creates a new user.

This page explains how that search works. It helps you understand, for example, why a signature came out with
someone else's name, or why the API answered `EmailAlreadyBeingUsed`.

> **Note: Instance settings**
>
> The settings on this page apply to the whole instance, not to one organization. If you use Signer in the cloud
> (SaaS), ask Lacuna support to change them. If you run your own instance, see
> [Signer settings](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/settings#identifier-scope-settings).

## What identifies a person

Signer uses two pieces of data to identify a person:

* The **e-mail address**.
* The **identifier**, an identity document number. By default, the identifier is the CPF.

Sign-in goes through a separate identity service, GrantID. GrantID holds the person's account, with e-mail and
CPF. Signer keeps a copy of that data.

## Identifier modes

The **mode** of an identifier says whether it is required and whether two people can share the same value.

| Mode | Required | Two people with the same value |
|---|---|---|
| `Unique` | Yes | No |
| `NonUnique` | Yes | Yes |
| `Nullable` | No | Yes |
| `NullableUnique` | No | No |

The default mode of the CPF is `Unique`. The `IdentifierModes` setting of the `IdentifierScope` section sets the
mode of each identifier type. For example, `Cpf=NullableUnique` makes the CPF optional but still unique.

## How Signer finds the user

Signer follows these steps for each participant, in this order:

1. If the request carries a user `id`, Signer uses that user.
2. If the `DisableGrantIdIdentifierSync` setting is on, Signer searches by e-mail only.
3. If the participant has an identifier, and the identifier mode is `Unique` or `NullableUnique`, Signer
   searches by identifier.
4. In every other case, Signer searches by e-mail.
5. If the search finds nobody, Signer creates a new user with the name, e-mail, phone and identifier given.

In step 3, Signer does not search by e-mail after a search that found nothing. It creates a new user. The
exception is an instance with [multiple identifiers per user](https://docs.lacunasoftware.com/en-us/articles/signer/concepts/participant-identification#multiple-identifiers): there, if the identifier
search finds nobody, Signer also searches by e-mail.

> **Tip: Example**
>
> The CPF is in `Nullable` mode. You create a document for Ana, with the e-mail `contact@company.com` and her CPF.
> That e-mail already belongs to the user Bruno. Because `Nullable` is not unique, Signer searches by e-mail, finds
> Bruno and uses his account. The signature comes out with Bruno's name and CPF.

### Data of an existing user

If Signer finds a user, it uses that user's stored data, not the data in the request:

* The participant's name becomes the stored name. The screen shows the warning *The name provided was not used
  because the user is already registered with another name.*
* A different identifier becomes the stored identifier.
* The e-mail becomes the stored e-mail, unless the `AllowSetFlowActionEmail` setting is on. It is on by default
  and lets a participant have an e-mail just for that document.

Creating a document never changes the name or e-mail of an existing user.

## E-mail and CPF uniqueness

Signer does not check whether an e-mail is unique. GrantID does. So the uniqueness rules depend on both systems:

| Data | In Signer | In GrantID |
|---|---|---|
| Unique CPF | `Unique` or `NullableUnique` mode | The CPF field marked as unique |
| Required CPF | `Unique` or `NonUnique` mode | The CPF field marked as required |
| Unique e-mail | Not checked | The `RequireUniqueEmail` option, on by default |
| Sign-in | | By e-mail or by CPF (`UsernameType`) |

The settings of both systems must match. If you change only Signer, GrantID can still reject a repeated e-mail or
CPF.

## Multiple identifiers and foreign signers

Starting with version 2.11, an instance can accept identifier types other than the CPF. This lets you register a
foreign signer who has no CPF.

| Type | Country | Since |
|---|---|---|
| `Cpf` | Brazil | |
| `EcuadorBceId` | Ecuador | 2.11 |
| `ParaguayCedulaIdentidad`, `ParaguayRuc`, `ParaguayPassport` | Paraguay | 2.11 |
| `Passport` | Any country | 2.20.0 |
| `Ssn`, `Itin`, `Ein` | United States | 3.0.0 |

These settings of the `IdentifierScope` section control the feature:

* `EnableMultipleIdentifiersPerUser`: turns the feature on. A user can have, for example, a CPF and a passport.
* `AllowedIdentifierTypes`: the types the instance accepts.
* `DefaultIdentifierType`: the type used when the request gives no type.
* `IdentifierModes`: the mode of each type, such as `Cpf=Nullable,Passport=NullableUnique`.

With the feature on, keep these rules in mind:

* GrantID stores one identifier per user. So Signer only searches GrantID by the default type. For the other
  types, it searches by e-mail.
* Signer never uses the SSN to search for a user.
* The instance does not start if GrantID sign-in uses the CPF.

To register a foreigner without turning the feature on, give the CPF a mode that is not required, such as
`Nullable` or `NullableUnique`. The participant then has no identifier.

For the cause and fix of errors such as `EmailAlreadyBeingUsed`, `CpfAlreadyBeingUsed` and `DuplicateUser`, see
[Fixing participant registration errors](https://docs.lacunasoftware.com/en-us/articles/signer/user-guide/erros-de-cadastro).

## Single sign-on (SSO)

Signer has one sign-in service per instance, GrantID. Sign-in with an external account, such as Microsoft
(Microsoft Entra ID), is set up in GrantID, not in each Signer organization.

GrantID accepts one Microsoft provider per instance. So two organizations on the same instance cannot use SSO with
different Microsoft Entra ID tenants.

At each sign-in, Signer updates the user's CPF and phone with the data of the GrantID account.