First-Time EspoCRM User: Tips for Balancing Custom Entities vs. Relationships?

[timocracy]

I’m new to EspoCRM (been exploring it for a couple of weeks now) and I’m impressed with how flexible it is. I'm currently planning a custom CRM setup for a small logistics company and I'm at a bit of a crossroads.

I’m debating whether to create entirely new custom entities for things like “Warehouses,” “Shipment Routes,” and “Fleet Vehicles,” or to handle these more as related fields within a couple of broader entities.

Before I go too deep and make structural choices that are hard to undo later, I’d love to hear how more experienced users approach this. Specifically:

• When do you decide something should be a standalone entity vs. just a related field?
• Any lessons learned from over-complicating (or under-building) your schema?
• Does performance get impacted when you create too many custom entities?

geometry dash

Would really appreciate any insights or “wish-I-knew-sooner” tips from the community!

Thanks in advance.

[shalmaxb]

Hi,
the approach you are taking, is in the right direction. As any database, also espoCRM has to be planned very thoughtfully. Even more, when you want to mirror a non default process.
I recommend in your case to work with custom entities, as to modify pre-configured entities could lead to "bending" those to fit your needs. And that is not recommendable at all, because in the end this will cause more headache as getting custom entities to fulfill your tasks.

When I started with espoCRM I had to learn a lot, fortunately with this community here and the system itself, you will nevertheless get astonishing results very quickly. Have a little patience, be aware, that you will come to points, where you see, that even a thoroughly planned approach to resolve a problem could lead to re-thinking and start over from time to time. This is also kind of learning and in learning, there is investment necessary.

Said that, first step is good planning, use pencil and paper.
Try to acquire some knowledge about databases (MySQL), as there could appear some caveats on the long run, when you do not plan correctly. As example: Inserting more and more Varchar fields could cause the table to large problem in MySQL, which is very difficult to heal, when it once happens. Be aware of the importance of fieldNames, whenever possible use the same as label names. It is a hellride, if you have fieldnames you cannot remember anymore, because the labels are completely different. The same with relationship names (in the end, these will,be field as well).

For special tasks have a look into the meanwhile rich amount of extensions, from espoCRM itself as well as from third party. Lots of extensions ease your life and are often even for free.

Never! Never change anything in the core files. espoCRM has the possibility for overrides by custom files in nearly every part of the app. So there is no need at all to modify core files. Such modifications would be deleted by every update and could disturb the system substantially.

Use this forum, ask your questions and participate in posting solutions as well. One tip regarding the forum: The search function of the forum itself is quite limited. Put your search into a internet search engine, referring to espoCRM, you will get presented all threads about your subject.

As far as I experienced in the last 5 years, the size of your app does not impact the performance. espoCRM is very well coded, very modern and I never had speed issues and as far as I read here, nobody with big apps and hundreds of thousands records as well did not complain about such situation.

If you have any particular question, ask. Here are a lot of members willing to help in a friendly and not arrogant way, as known from other communities. And the best thing is, the chief developer, Yuri, is always present.

[yuri]

Opting to having multiple entities from the start can be beneficial if the functionality is supposed to be extended in the future. The downside is that it may result in a more complex UI for users to work with. May require some additional coding to automate things so that it's available for users in more simple UI.

I'd say that the data design in the most complex part of developing.