Identity store schema

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 regsitration" is not selected.

📘

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.

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:

• Create new attributes
• Edit attributes
• Checkbox
• String
• Select
• Phone
• Date