Skip to main content
Digital Identity Management enables applications to store custom data for an organization’s users. Digital Identity Management’s data model consists of these default data entities:
  • User
  • Runtime
  • Group
  • Account
  • Feature
  • Subscription
Each entity is defined by a set of default properties and attributes (that is, JSON strings, booleans, integers, complex objects, and arrays). These entities represent users and the various services and devices in their orbit. For most of these entities, the properties and attributes made available by Digital Identity Management are enough for most organizations to store the relevant information they desire with each entity, for the purposes of their applications. However, a business may want to store additional information about a user, beyond what Digital Identity Management User entity stores, for a variety of reasons such as:
  • Better understand the user
  • Define a more personal and relevant user experience within a given application
  • Optimize an application to better track or respond to user input
Digital Identity Management provides a flexible storage mechanism called Custom Data to service this need. As information is collected from the user, either directly (that is, applications that allow users to provide more of their own information or change settings) or indirectly (that is, applications that silently observe and record user behavior), your application(s) can call Digital Identity Management Custom Data API endpoints to both persist this data in the cloud and retrieve it on demand (for example, when a user returns to your application).

​
Use Case Examples

An organization may wish to store a “day mode / night mode” setting for a given application. The organization makes this option available within the application. If the user makes an explicit selection, that selection can be stored directly on the Digital Identity Management User entity as custom data, and then retrieved from Digital Identity Management when the user returns to the application. Other common uses of Custom Data include:
  • Provision a date of birth item that allows a user to set their date of birth in their in-app profile.
  • Provision a favorite list array that allows a user to create a list of their favorite shows, music artists, or other application-specific content.
  • Provision genre tags, and use tags on app content that is added to the User entity as they view it, to compile a user’s recent viewing history.
  • Provision time-stamps to track the last known position at which a user watched a show.
  • Allow-list or block-list content to expose to, or hide from, a soft profile user (for example, because they need to pay for a full membership, or if the soft profile user is underage).
With this information at hand, Custom Data can help to drive your organization’s UI. As an example, knowing the age of the user and whether they are a child, teenager, or adult helps your UI deliver an experience that is tailored to them, with content that appeals to them upfront and center whenever they visit the service. Custom Data is built for performance. It is capable of handling millions of requests per day.

​
Lists and Items

Custom Data is a free-form data structure that your organization defines. The only requirement is that your data is formatted to proper JavaScript Object Notation (JSON). It is organized by lists and items. A list is a collection of items, and an item is the small piece of data to be captured in the application, stored in Digital Identity Management, and retrieved from Digital Identity Management as needed. Examples of a list and item include:
  • List - A collection of uniquely identified television shows the user has marked as favorite.
  • Items - An user’s date of birth, a user’s favorite genre, and such.
Lists can be created, modified, or deleted. Items can be added to, modified on, or removed from a list. Items can be scalar item (including text, numeric, boolean and formatted date) or JSON objects. Lists organize scalar items or JSON objects. Note: An individual item can be isolated and updated individually to prevent retrieving an entire list. This helps to improve API response time and size of request.

​
Notable Points

The following points are noteworthy and can be adjusted as per the requirements:
  • Data limit is consistent with the limits on UXDR. Storage limit can be increased as per the requirements.
  • Request size limit is 1 KB per request. Request size limit can be increased as per the requirements.
  • Throughput limit (request per second) is to be determined as per the requirements.
Parent topic:Digital Identity Management Features