Best practices for organizing custom fields in EspoCRM

[Fahadijutt]

Hello everyone,

I’m currently working with EspoCRM and exploring ways to keep custom fields well organized as the system grows. After adding fields for different entities, I want to make sure the setup remains easy to manage for both administrators and end users.

I’d appreciate guidance on:

• Recommended naming conventions for custom fields
• When to group fields into panels versus keeping them simple
• How to avoid clutter in forms while still capturing all required information

If anyone has experience managing larger EspoCRM setups, I’d be interested in learning what approaches have worked best over time.

Thanks in advance for your suggestions.

[shalmaxb]

It mostly depends on your individual configuration. I always try to hide fields, which
- certain users do not need (conditional in field manager)
- need values in other fields first (conditional in field manager)
- groupd of field in a layout panel of its own (condition in layout manager)

I quite always have a panel, which is only visible for me (I call it Admin Fields), where I put fields, which I need for conditions and formulas and which all are filled automatically. No user has the need to se these fields.

Naming should avoid use the same names like default system fields already have. Some time ago Yuri introduced the leading C für each custom field, which will be prefixed to any new custom field or relationship (what is in fact an custom link field), so ther will not be any collision, if you use a reserved name.

Even though I am from Germany, I now use only english names, as it fits better for the translation system.

Think thoroughly, what and how you will need regarding your entities, relationships and fields. Be sure of names you give. It can get a nightmare, if you change names of fields in the long run.
The names you cannot change, you would have to delete that field, if it should get another name. In deeply developed entities, that may cause multipüle side effects, as relationships might not work anymore, conditions have to be changed as well an formulas will need the new field names.
I had a customer, who changed the names several times in about one year`s period and as he did not want to create all dependencies again, he labeled the field as he wanted. This way, the label has another term than the field itself. Followed up by complex formulas it is a nightmare now to maintain this installation. Review everything and put it straight, would need so much effort, that he decided to leave it as it is, hoping there will never be a fundamental change in how the system works.