User fields
This document provides extended information about commonly used fields in User objects.
addresses
The User's physical addresses. Each address has a type — PERMANENT, TEMPORARY,
POSTAL, or CONTACT — and can be marked verified. A User can have at most 50 addresses.
customerGroupInfo field
Customer-service-entered data about special customer statuses, such as being identified as a
student, a senior, or having a disability. This field is read-only through the User API — it's
populated by dedicated APIs and integrations (for example, student status can be set via the
/api/rest/v1/user/{userId}/customergroupinfo/student endpoint) rather than by writing to the
User document directly.
customFields field
In addition to the built in fields, you can add custom fields to the User document to fit your use cases.
See Custom fields for more information.
dateOfBirth field
The User's date of birth. If you only need to know whether a User is a minor rather than their
exact birth date, consider using the minor field instead.
emails field
The emails field contains an array of email address objects. Each such object holds information about a single email address of the User.
The first address in the array is the primary email address of the User.
Note that unverified addresses may also be listed. You can check the verified status from the verified subfield.
Email addresses can be added with the /api/rest/v1/user/{userId}/change-contact/begin and /api/rest/v1/user/{userId}/change-contact/finish APIs.
Alternatively, the whole array can be replaced with the PUT /api/rest/v1/user/{userId} API.
id field
This field is autogenerated by the service. It is a globally unique identifier for the User. It is called the "User ID". The value is a 24 character lowercase hexadecimal string. The ID values are sortable by creation time.
In most APIs, when a user is referenced, this value is used.
In the User's ID Tokens, this value is used as the sub claim value.
lastActivity and lastLicenseActivity fields
Both fields are read-only, and hold the same kind of information: a timestamp, a human-readable
description (for example "Sign In"), and the ID and type of whoever caused the recorded
activity. lastActivity tracks the User's most recent activity in general, while
lastLicenseActivity tracks activity that's relevant for license usage tracking specifically.
locale and preferredLanguage fields
Both fields have the same value. This field controls which language is used in Trivore ID user interfaces. If this field value is specified, Trivore ID user interfaces and related communications (emails, SMS messages) should use the same language. If there is no value, the locale may be selected based on browser preference, group policy setting, or a default locale.
lockInfos field
A read-only list of the User's active locks, populated only while the User is locked (that is,
while its locked field is true). Each entry has a lockedReason — for example
LOCKED_BY_ADMINISTRATOR or LOCKED_DUE_TO_TOO_MANY_INCORRECT_PASSWORDS — and a lockedTime.
See Locking Accounts for how and why accounts
get locked.
memberOf field
The memberOf field is used to manage membership in Groups. It is an array of group IDs.
minor field
A boolean flag for whether the User is a legal minor, as an alternative to specifying an exact
dateOfBirth — what age counts as a minor is up to the client setting this
field, since Trivore ID doesn't enforce a specific age threshold itself.
mobiles field
The mobiles field contains an array of mobile number objects. Each such object holds information about a single mobile number of the User.
The first number in the array is the primary mobile number of the User.
Note that unverified numbers may also be listed. You can check the verified status from the verified subfield.
Mobile numbers can be added with the /api/rest/v1/user/{userId}/change-contact/begin and /api/rest/v1/user/{userId}/change-contact/finish APIs.
Alternatively, the whole array can be replaced with the PUT /api/rest/v1/user/{userId} API.
name field
An object holding the User's givenName, middleName, and familyName. There's no uniqueness
requirement on names — username (see below) is what's required to be unique within a
namespace.
nickName field
The User's nickname or preferred name, as opposed to their legal name. There's
no namespace configuration specific to this field, unlike screenName below.
nsCode field
This field shows the current code of the user's Namespace. Note that the namespace code may change over time.
personalIdentityCodes field
A read-only list of Personal Identity Codes (such as a social security code) known for the
User, together with their source (for example SUOMI_FI or IN_PERSON) and when that
knowledge was last updated. A User may have more than one, for example if they've been strongly
identified through more than one method. Viewing this field requires the
ACCOUNT_VIEW_PERSONAL_ID permission.
screenName field
A name that's unique within the User's namespace, intended for use as an alias on discussion
forums rather than as the User's real or sign-in name. Restrictions on the allowed format are
configurable in namespace settings, the same way they are for username.
strongIdentification field
A read-only summary of the User's most recent strong identification event: the method used
(for example SUOMI_FI or IN_PERSON), a timestamp, and whether the identification is still
identified (valid) or has since expired. For the full history of a User's strong
identification events, rather than just the most recent one, use the
/api/rest/v1/user/{userId}/strongidentification/history API instead of this field.
tags field
This list of tags can be used as another way to group certain users. Users can be searched with a filter like tags eq "influencer". Tags can be updated by replacing the whole list with the PUT /api/rest/v1/user/{userId} API.
timeZone field
The User's preferred time zone, as an IANA time zone name such as Europe/Helsinki.
username field
This is the username of the User. It is unique within the Namespace the User belongs to. The user can use it during sign in to identify themself.
Restrictions:
- Minimum length: 1 character
- Maximum length: 100 characters
The username format can be restricted in Namespace configuration.
The username may be automatically generated, based on Namespace configuration. When a User is created with the Create User API, and no username is provided, it is generated automatically if possible.
The username is changeable, so it should not be used as a permanent identifier for a User.