<@U04UQ68083H> What is the best practice in terms ...
# ory-copilot
b
@chilly-king-10285 What is the best practice in terms of identity schema when we need to log informations about Terms of Service acceptance (both dates and version). Is it a good practice to keep it in the Ory Schema?
c
A message from kapa.ai
The best practice for storing information such as Terms of Service (ToS) acceptance (including dates and version) in Ory is to keep your identity schema lean and focused on profile data that is used across your system, such as usernames, email addresses, phone numbers, and names. The documentation specifically advises against storing business logic or excessive fields in the identity schema, and recommends keeping the number of fields well below 15. Storing ToS acceptance data (like version and date) is not explicitly forbidden, but you should be cautious not to overload the schema with business logic or data that is not essential for identity management. Instead, such information is often better managed in your application database or a dedicated consent management system, especially if it is not required for authentication or profile purposes. However, if you decide that ToS acceptance is a critical part of the user's profile and must be tracked within Ory, you can add custom fields to your identity schema for this purpose. For example, you could add a field like
accepted_tos
(boolean),
tos_version
(string), and
tos_accepted_at
(timestamp). This approach is technically supported, but you should be mindful of the recommendation to avoid complex schemas and not to store business logic in the identity traits. Sensitive or internal data should be stored in
metadata_admin
, which is not visible or editable by the user, while public profile data can be stored in traits if it must be user-facing and editable [Identity schema best practices](https://www.ory.sh/docs/kratos/manage-identities/best-practices). In summary: - It is possible to store ToS acceptance (date and version) in the Ory identity schema as custom traits. - The best practice is to keep the schema lean and avoid storing business logic or excessive fields. - For more complex or business-critical consent tracking, consider using your own backend system. If you need to store this information in Ory, keep the schema simple and only include what is necessary for your authentication and profile needs [Identity schema best practices](https://www.ory.sh/docs/kratos/manage-identities/best-practices) [Customize identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema).