Frequently Asked Questions
Can you add a new User field for my application?
Usually, no. For application-specific data, the recommended approach is to use Custom Fields instead of requesting changes to the built-in User document.
Custom Fields are designed for storing small pieces of application-specific user data without changing the core product data model. This gives you a solution you can use immediately, while keeping your application data separate from fields that are part of Trivore ID itself.
Why use Custom Fields?
Custom Fields are the best fit when you need to store data such as:
- external system identifiers
- customer-specific profile attributes
- application feature flags or licence information
- small structured JSON data related to a user
Using Custom Fields also helps avoid side effects in other parts of the product. Built-in User fields may appear in APIs, the Management UI, and OIDC claims, so adding a new core field affects more than a single application.
When is a built-in User field added?
New built-in User fields are only added when they serve a broader product-level purpose in Trivore ID.
Because the platform is shared across many organisations and use cases, a customer-specific field is usually not suitable as a permanent part of the core User model.
Can Custom Fields be protected or exposed selectively?
Yes. Depending on your environment and configuration, you can:
- restrict access to Custom Fields using Custom Field definitions and access controls
- expose selected Custom Field values through APIs
- map selected Custom Field values into OIDC tokens and other responses when needed
If your use case requires search by Custom Field values at scale, indexing may also be needed for good performance.
Custom Fields are a good fit for small JSON-based values. If you need to store larger application data sets or more generic non-user-specific data, consider other storage options provided by Trivore ID.