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.

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.

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: there, if the identifier search finds nobody, Signer also searches by e-mail.

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.

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.