Identity store schema
You can learn about how to set up customer identification and data collection fields for identity stores.
The identity store schema makes setting up new identity stores quick and effortless. Once you’ve configured the key functionalities of the identity store, you’re provided with a set of default attributes that are most commonly used in customer data collection.
Settings
Identity store settings allow you to configure the key aspects of the store, such as setting the supported identifier(s), applying a password policy, and naming the identity store.
Identity store name
The identity store is referenced by this name in the Admin Console.
Description
A description appears under the identity store’s name in the store listing.
Identifiers
Identifiers are unique credentials that identify customers within an identity store or organization. Identity stores need to support at least one identifier to be created. An identity store can support:
- Username: The user will be asked to enter a string unique to the identity store or organization they're registering for.
- Email address: The user will be asked to enter an email address in the valid format for the identity store or organization they're signing up to.
- Support for both username and email address: You can choose to support both types of identifiers at the same time
Supported identifiers selected at identity store creation are set to mandatory by default, but you can change their required status later on.
Identifier settings
Identifier settings allow you granular control over the required status and visibility of each identifier. You can make one of the identifiers mandatory, the other one optional, you can display or hide one of them from registration, etc.
You can find identifier settings in the Attributes tab for each identifier.
Password quality policy
This policy determines the characteristics of user passwords and enforces security measures.
You can find out more about password quality settings at the link.
Account event TTL
The account event TTL (time-to-live) period determines how long account events are retained. Strivacity retains account events from the last 30 days by default.
You can contact Strivacity’s customer success team to request a longer retention period.
Enable self-service organization registration
This setting allows administrators with adequate access rights to create organizations via the organization management portal. If it’s disabled, organization admins can’t create new organizations.
Lifecycle event hooks
This option allows for updating external systems if a password change occurs in the Strivacity identity store. You can use an ‘After password change’ event hook that triggers after a password update. Once the hook is created, and tested with your external system, it can be assigned to the identity store.
Attributes tab
Identifiers
The type of required identifier affects some self-service capabilities. You can find out of each identifier type's impact at the link.
You can access username and email identifier settings by selecting them in the Account attribute list. You can change which identifier is supported, modify their required status, or fine-tune their visibility in customer experiences.
Enabled/Disabled switch This switch determines if an identifier is supported in the identity store. It also controls the visibility of the identifier in customer login experiences.
- When enabled, that identifier type will be available to use during login.
- If disabled, that identifier type will not be shown at login or registration.
This setting does not determine the required status of the identifier. There’s a separete checkbox for that.
Display options
- Make the attribute mandatory When an identifier is enabled, you can change its required status. If it’s set to mandatory, users will have to register and authenticate with that identifier.
- Show attribute during registration You can also control the visibility of an identifier for registration. If the identifier is set to mandatory, this option is always selected. If mandatory is not selected, then the identifier becomes optional if "Show attribute during registration" is not selected.
Username restrictions
- Can contain up to 104 characters
- Cannot contain: " / \ [ ] : ; | = , + * ? < >
- Can contain any of the remaining special ASCII characters: # $ % & ' ( ) - . @ ^ _ ` { } ~
Use case: Transition from a username-only to email-only support for new users
Granular identifier controls allow you to shift from username-only support to email identifier support without retroactively enforcing email identifiers upon legacy users. Identifiers no longer have to be mandatory to display their field at login. You can keep the username identifier for legacy users by
- enabling username as an identifier type so that it is available to use during login,
- not selecting "Make the attribute mandatory" so new users wont be forced to enter it,
- not selecting "Show attribute during registration"
At the same time, you can set the email identifier as mandatory for new registrations to ensure new users create email address identifiers.
Password attribute
The password attribute allows you to pick the position of the password field on the registration form.
An identifier’s or attribute’s position in the Account attributes list decides the order in which they appear on the registration form. (They need to be made visible at registration to appear.)
You can change the password field’s position by dragging the attribute to a new place in the attribute list. You can place it before or after any identifier or attribute. It will appear in the corresponding order on the registration form.
Default attributes
Default attributes are set with a governing native claim that corresponds to the type of customer data being collected.
Name | Type | Default visibility |
---|---|---|
Given name | String | Appears at registration by default |
Middle name | String | Visible in self-service and administrative experiences except for registration |
Family name | String | Appears at registration by default |
Nickname | String | Not enabled by default |
String | Visible in self-service and administrative experiences except for registration | |
Phone number | Phone number | Visible in self-service and administrative experiences except for registration |
Street address | String | Visible in self-service and administrative experiences except for registration |
City | String | Visible in self-service and administrative experiences except for registration |
Region | String | Visible in self-service and administrative experiences except for registration |
Postal code | String | Visible in self-service and administrative experiences except for registration |
Country | String | Visible in self-service and administrative experiences except for registration |
Gender | Select | Not enabled by default |
Gender (custom) | String | Not enabled by default |
Picture | String | Visible in self-service and administrative experiences except for registration |
Department | String | Not enabled by default |
Company | String | Not enabled by default |
Job title | String | Not enabled by default |
Adaptability
Attributes (not just the default ones) are highly adaptable, meaning they can be used in various ways in the customer journey. You can decide which attribute to include
- at registration
- in customers' self-service portals
- in account management for Admins
- in progressive profiling steps using Lifecycle Event Hooks
You can also change the behavior of each attribute field by applying JavaScript attribute hooks.
Custom attributes
You can leverage the default setup, but you can also customize and scale identity stores to your use cases. You can add custom attributes of 5 different types, override governing native claims, and further extend attribute capabilities:
- Custom attributes can be used in third-party data synchronization.
- You have flexibility in adjusting the attribute’s functionality to your needs with the help of Lifecycle Event Hooks.
- New fields can also be configured for search indexing.
Editing the identity store schema can have adverse effects on your customer experience. By design, new attributes cannot be deleted (they can be disabled and hidden). While this helps avoid accidental data destruction we advise caution when managing account attributes.
For more information on how to configure and extend the list of available attributes and to learn about the various attribute types, go to the following pages:
Updated 8 days ago