Making email and phone Field Types Available in Entity Manager – Any Risks?

[IshitaRana]

Hi,

I was recently trying to add email and phone fields via the Entity Manager in EspoCRM, but noticed that they were not appearing in the field type dropdown list.

After some digging, I found that this was because these field types have "notCreatable": true defined in their respective metadata JSON files (email.json and phone.json under application/Espo/Resources/metadata/fields).

To make them available in the UI, I created override files at:

custom/Espo/Custom/Resources/metadata/fields/email.json
custom/Espo/Custom/Resources/metadata/fields/phone.json

With the following content:

{ "notCreatable": false }

After clearing cache and rebuilding, the field types are now showing up as expected in the dropdown when adding fields.

Before I proceed further with using this in production, I wanted to ask:

• Are there any potential issues or side effects this change could cause down the line?
• Why are these fields not creatable by default — is it due to internal limitations, relationships, or design considerations?

Would appreciate any insights or best practices from others who may have explored or overridden this before.

Thanks!

[yuri]

Hi,

Unfortunately, it won't work properly. Phone and Email number fields are designed to be as single fields in an entity.

[IshitaRana]

Thanks for the clarification!

In my case, the requirement is to have multiple phone and email fields (e.g., Work Email, Personal Email, Emergency Phone, etc.) on a single entity.

I understand that the default email and phone fields are designed as single-use and not intended for duplication. But given this business need, could you please advise on the recommended approach for the same.

[yuri]

Storing phone numbers in the default Phone field. It's possible to add custom phone types for a particular Phone field. Entity Manager > {Entity} > Fields > Phone.

For emails, maybe using a varchar field with the view set to "views/fields/email-address" (in entityDefs > fields).