Havilo organizes a workspace around entities and the relationships between them. Each workspace can define the entity types it needs, the fields that describe them, and the relationship types that can connect them.
An entity is a record: one person, company, fund, project, or anything else a workspace needs to track. Entities provide the familiar structure of a customizable CRM. A workspace can define new types for the work it does, and every Havilo application can use the resulting model.
Model at a glance
| Concept | Meaning and example |
|---|---|
| Entity Type | The structure for a category of entity, such as People |
| Entity | One record belonging to an entity type, such as Maya Chen |
| Field | A typed property defined on an entity type, such as Email |
| Field Value | The value an entity holds for a field, such as maya@example.com |
| Relationship Type | The rules and labels for a kind of connection, such as Employment |
| Relationship | One connection between two entities, such as Maya Chen works at Northstar Labs |
| Entity List | A named collection of existing entities, such as Portfolio founders |
Entity types and entities
An entity type defines a category of information. It determines which fields its entities can have and how those entities appear in lists, hovercards, and forms.
People and Companies are common entity types. A workspace can also define Funds, Programs, Projects, Properties, Suppliers, or a type specific to its work. Each type has its own fields and display configuration.
An entity is one instance of an entity type. Maya Chen may be an entity of the People type; Northstar Labs may be an entity of the Companies type. Every entity belongs to exactly one entity type, but it can participate in many relationships and entity lists.
Some entity types are marked System because Havilo applications depend on them. Their configuration can evolve, but the type itself cannot be removed while those applications rely on it. Workspace-defined entity types can be created and adapted as the model changes.
Fields and field values
A field defines a piece of information that an entity type can hold. Its definition includes a name, a type, and options such as whether it is required, accepts several values, or may be populated through enrichment.
A field value is the information stored for one entity. Email may be a field on the People entity type; maya@example.com is the field value on Maya Chen's entity.
Field types give values structure beyond their label:
| Field types | Used for |
|---|---|
Text (TEXT, LONG_TEXT) | Names, descriptions, and other written values |
Number (NUMBER) | Quantities and numeric measurements |
Date and time (DATE, TIME, DATETIME) | Dates, times, and scheduled moments |
Boolean (BOOLEAN) | Yes-or-no states |
Contact and web (EMAIL, PHONE, URL) | Contact details and web identifiers in a declared format |
Choice (PICKLIST, MULTI_PICKLIST) | One or several choices from a defined set |
The declared type affects how Havilo validates, displays, filters, and uses the value. An Email field carries a declared format, so Havilo can use it for identity matching and other features that require an email address.
Most fields hold one value. A field configured as a List can hold several values of the same type—for example, a Roles field containing Founder, Mentor, and Advisor. This is different from an entity list, which gathers several entities rather than several values on one entity.
Fields may be workspace-defined or protected system fields. Some can also receive enriched or synchronized values. Those controls determine who or what may write a field; they do not change the underlying relationship between a field definition and its field values.
Relationship types and relationships
A relationship type defines a category of connection in the same way that an entity type defines a category of entity. It specifies the source and target entity types, the labels used to describe the connection, and whether it can be traversed equally in both directions.
For example, an Employment relationship type can connect People to Companies. Its forward label may be works at, while its reverse label is employs:
Maya Chen -- works at --> Northstar Labs
Maya Chen <-- employs ---- Northstar LabsA relationship is one instance of that type: Maya Chen works at Northstar Labs. It points to both entities; their names are not copied into the relationship.
Relationships can carry information about the connection itself:
- Title describes the role within the relationship, such as
FounderorAdvisor. - Start and end dates preserve when the relationship was active.
- Qualifier distinguishes multiple relationships of the same type between the same entities.
A qualifier allows the same fund and company to be connected once for a seed investment and again for a Series A investment without one relationship replacing the other. Dates preserve former employment and other historical connections instead of reducing the network to its current state.
Because relationships point to entities, they survive a rename and can be followed from the connected records. Their roles, dates, and qualifiers also remain structured information that Havilo can search and reason over.
Fields or relationships?
Fields and relationships can sometimes describe similar information, but they behave differently.
| Use a Field when… | Use a Relationship when… |
|---|---|
| The value describes this entity | The value is another entity you track |
| The value does not need its own history | The connection needs a role, dates, or history |
| Filtering the value is sufficient | Havilo should follow the connection from either entity |
A text field called Company can store the characters Northstar Labs. A works at relationship points to the Northstar Labs entity itself. The relationship appears with both entities, remains intact if the company is renamed, and can carry Maya's title and employment dates.
Entity lists
An entity list is a named collection of existing entities. Each list entry points to an entity, so its current field values and relationships remain available wherever the list is used.
The same entity can belong to several lists without being duplicated. Removing it from a list does not delete it, and changing the entity updates what every list sees. Lists, tables, boards, and saved views can organize the same entities for different work. They all read the workspace's data model.
See Entity Lists for membership, visibility, and external sync.
Entities across Havilo
Notes, messages, meetings, source material, and artifacts can link to the same entities and relationships.
A company discovered through a meeting can be the same entity that appears in a list, receives an enriched website, connects to its employees, and supplies context for a later briefing. When one application updates the entity, the others read the updated version, subject to the workspace's access controls.