67 lines
4.4 KiB
Plaintext
67 lines
4.4 KiB
Plaintext
---
|
||
title: Customize your data model
|
||
info: "Learn how to design and create a data model that reflects how you operate."
|
||
image: /images/user-guide/fields/custom_data_model.png
|
||
sectionInfo: Flexible data model designed to support your unique business processes
|
||
---
|
||
<Frame>
|
||
<img src="/images/user-guide/fields/custom_data_model.png" alt="Header" />
|
||
</Frame>
|
||
|
||
## What is a data model?
|
||
A data model is the structure that defines how information is organized in your CRM. It determines what objects exist (like companies, people, or opportunities), what properties they have (those are the fields), and how they relate to each other. You can think of it as the map of your customer data.
|
||
|
||
## Why should you customize your data model?
|
||
Every business works differently. Being able to fully customize your data model means you can shape Twenty around your processes instead of forcing yours into a rigid system.
|
||
Twenty offers the flexibility you need to shape the data model that will best support your day-to-day. You can create as many custom objects and fields as you need, the price won't change.
|
||
|
||
## Tips to design your data model
|
||
There is rarely only one way to build a data model. Below are a few tips to help you build yours.
|
||
|
||
**1. Start with your core objects.**
|
||
Identify the main concepts you work with (e.g. Companies, People, Opportunities). Those three objects are already available as they are used very often. But think of any other you might need.
|
||
Example: Stripe would need an object ```Subscriptions```, Airbnb would need an object ```Trips```, a start-up accelerator an object ```Batches```.
|
||
|
||
**2. Use fields for variations, not new objects.**
|
||
If something is just a characteristic of an existing object (e.g. ```Industry``` for a Company, or ```Status``` for an Opportunity), make it a field. Fields are best for categories, labels, and attributes.
|
||
|
||
**3. Create a new object when it stands on its own.**
|
||
If the concept has its own lifecycle, properties, or relationships, it usually deserves an object. For example:
|
||
- **Projects** that have their own deadlines, owners, and tasks
|
||
- **Subscriptions** that connect companies, products, and invoices
|
||
- **Events** that involve many attendees and follow-up actions
|
||
|
||
These go beyond a single field because they carry their own data and relationships.
|
||
|
||
**4. Create an object when the number of related records is open-ended.**
|
||
If something can be linked multiple times and you don’t know how many, it’s better as its own object. For instance, instead of creating fields like `Product 1`, `Product 2`, etc., define a `Product` object and relate it to the original record. This way, you can support one, two, or a hundred products without changing your model.
|
||
|
||
**5. Keep it simple first.**
|
||
Start with fields. Move to new objects only when you feel the limits: too many fields, repeated records, or relationships that don’t fit neatly.
|
||
|
||
|
||
### Special note on People, Companies and Opportunities
|
||
|
||
- **`People`, `Companies` and `Opportunities` are the only objects from where you can access the emails and meetings synchronized from your mailbox / calendar.** We recommend using those as much as possible. If you need to create categories of `People` or `Companies`, use fields rather than new objects.
|
||
|
||
Example: it is best to use the `People` object for both prospects and partners, adding a field called `Person Type`. Avoid creating a `Partner` object, since you wouldn’t be able to access email threads from it. Instead, create different views under `People`: one showing partners, another showing prospects.
|
||
- Given the point above, it’s fine to have fields that don’t apply to every record. For example, under `People` you might add a `Referral Link` field that is only relevant when `Person Type = Partner`. That’s okay: you can hide this field from views where it is not needed.
|
||
|
||
|
||
### Questions to guide your choice
|
||
|
||
Ask yourself:
|
||
- Is this just a property of something I already have, or does it need its own properties?
|
||
- Will I ever need to track multiple of these per record, without knowing how many in advance?
|
||
- Does this concept connect to several different objects, not just one?
|
||
- Will it have its own lifecycle (e.g. stages, start/end dates)?
|
||
|
||
If the answer is “yes” to one or more of these, it’s probably time for a new object.
|
||
|
||
|
||
## Want some help?
|
||
Our team can assist you designing and creating the data model you need. Discover our Onboarding Pack [here](https://twenty.com/onboarding-packages).
|
||
|
||
|
||
|