Labels¶
Labels are an important concept to grasp in Lime CRM, but can sometimes be confusing.
Below we explain what labels are and why they exist in Lime CRM.
Types of labels¶
There are two kinds of labels:
- Field labels
- Table labels
A field label can be set on a field (a property on a limetype) and a table label can be set on a table (a limetype)
Usage¶
Labels are used to explain the database model to the Lime CRM application (for instance the Desktop Client or the Web Client).
As a database designer in Lime CRM you're free to create whatever user tables you want. A Lime CRM database almost always contains the following tables:
- Coworker
- Company
- Person
- Business
- History
But as a database designer you're free to add, edit, remove or rename whatever tables you want. That means that some databases might not have a company table and a company table in one database might have a totally different set of fields compared to a company table in another database. It's also possible that there exists a "company" table in a database but under a different name (it could for instance be called organization). This means that in order for Lime CRM to be smart and add custom logic on a company table, the table and its appropriate fields must be given the correct labels.
field label != property name¶
It's common that a property has the same name as its label but that's something that you never can take for a fact. The field label that is used to describe the "name field" on a table is name. This is most of the times also the name of that field but sometimes the property describing the name has another name, for instance company_name or title.
table label != relation property name¶
It's common that a relation property has the same name as its label but that's something that you never can take for a fact. The field label used to describe the relation to a "person table" is person but the property name of that relation might be something else - student for instance.
Several relations to the same limetype¶
Sometimes you need to create a table (limetype) with several relations to the same type of limetype. See examples below:
- Multiple responsible co-workers for different parts of the customer, like sales responsible and project responsible. This could also happen on deal.
- Multiple relations to Person on the history limetype. (This is a bad example as it makes it impossible for the desktop client to auto attach persons on a history note)
A good question to ask yourself in these scenarios is where to put the label? Features in Lime is often built on the assumption that there only exists a single field on a table with a specific label, that means that you need to decide which relation that should be treated as the "lime relation" to a co-worker for instance.