8cadd00d34
Created by Github action --------- Co-authored-by: Crowdin Bot <support+bot@crowdin.com> Co-authored-by: github-actions <github-actions@twenty.com>
70 lines
8.2 KiB
Plaintext
70 lines
8.2 KiB
Plaintext
---
|
|
title: Налаштуйте свою модель даних
|
|
info: "Дізнайтеся, як розробити та створити модель даних, що відображає вашу діяльність."
|
|
image: /images/user-guide/fields/custom_data_model.png
|
|
sectionInfo: Гнучка модель даних, призначена для підтримки ваших унікальних бізнес-процесів
|
|
---
|
|
|
|
<Frame>
|
|
<img src="/images/user-guide/fields/custom_data_model.png" alt="Header" />
|
|
</Frame>
|
|
|
|
## Що таке модель даних?
|
|
|
|
Модель даних — це структура, яка визначає, як організована інформація в вашій CRM. Вона визначає, які об'єкти існують (наприклад, компанії, люди, або можливості), які властивості вони мають (це поля), і як вони взаємопов'язані одна з одною. Ви можете уявити це як мапу ваших даних клієнтів.
|
|
|
|
## Чому вам слід налаштовувати свою модель даних?
|
|
|
|
Кожен бізнес працює по-різному. Можливість повністю налаштувати модель даних означає, що ви можете адаптувати Twenty до своїх процесів, замість того, щоб змушувати себе використовувати жорстку систему.
|
|
Twenty пропонує необхідну гнучкість для формування моделі даних, яка найкраще підтримуватиме ваші повсякденні справи. Ви можете створити стільки власних об'єктів і полів, скільки вам потрібно, і ціна не зміниться.
|
|
|
|
## Поради щодо розробки вашої моделі даних
|
|
|
|
Рідко є тільки один спосіб створити модель даних. Нижче наведено кілька порад, які допоможуть вам створити свою модель.
|
|
|
|
**1. Почніть з основних об'єктів.**
|
|
Визначте основні концепції, з якими ви працюєте (наприклад, Компанії, Люди, Можливості). Ці три об'єкти вже доступні, оскільки вони використовуються дуже часто. Але подумайте про будь-які інші, які можуть вам знадобитися.
|
|
Приклад: Stripe може знадобитися об'єкт `Підписки`, Airbnb - об'єкт `Поїздки`, стартап-акселератор - об'єкт `Партії`.
|
|
|
|
**2. Використовуйте поля для варіацій, а не нові об'єкти.**
|
|
Якщо щось є просто характеристикою існуючого об'єкта (наприклад, `Галузь` для Компанії або `Статус` для Можливості), зробіть це полем. Поля найкраще підходять для категорій, міток і атрибутів.
|
|
|
|
**3. Створюйте новий об'єкт, коли він існує самостійно.**
|
|
Якщо концепція має свій власний життєвий цикл, властивості або зв'язки, вона зазвичай заслуговує на об'єкт. Наприклад:
|
|
|
|
- **Проекти** з власними термінами, власниками і завданнями
|
|
- **Підписки**, що поєднують компанії, продукти та рахунки
|
|
- **Події** з великою кількістю учасників і подальшими діями
|
|
|
|
Ці об'єкти виходять за рамки одного поля, оскільки вони містять власні дані та відносини.
|
|
|
|
**4. Створюйте об'єкт, коли кількість пов'язаних записів необмежена.**
|
|
Якщо щось може бути пов'язано кілька разів, і ви не знаєте скільки, краще, щоб це було окремим об'єктом. Наприклад, замість створення полів, як-от `Продукт 1`, `Продукт 2` тощо, визначте об'єкт `Продукт` і пов'яжіть його з первинним записом. Таким чином, ви можете підтримувати одну, дві чи сотню продуктів, не змінюючи свою модель.
|
|
|
|
**5. Спочатку дотримуйтесь простоти.**
|
|
Почніть з полів. Переходьте до нових об'єктів лише тоді, коли відчуєте обмеження: занадто багато полів, повторювані записи або відносини, які не підходять добре.
|
|
|
|
### Особлива примітка з приводу Людей, Компаній і Можливостей
|
|
|
|
- **`Люди`, `Компанії` та `Можливості` є єдиними об'єктами, з яких ви можете отримати доступ до електронних листів і зустрічей, синхронізованих з вашої поштової скриньки/календаря.** Ми рекомендуємо максимально використовувати їх. Якщо вам потрібно створити категорії `Людей` або `Компаній`, використовуйте поля, а не нові об'єкти.
|
|
|
|
Приклад: краще використовувати об'єкт `Люди` для обох — потенційних клієнтів і партнерів, додавши поле під назвою `Тип особи`. Уникайте створення об'єкта `Партнер`, оскільки звідти не можна буде отримати доступ до ниток електронних листів. Замість цього створіть різні перегляди в розділі `Люди`: один для показу партнерів, інший — для показу потенційних клієнтів.
|
|
- Враховуючи вищесказане, нормально мати поля, які не застосовуються до кожного запису. Наприклад, у розділі `Люди` ви можете додати поле `Реферальне посилання`, яке є актуальним лише тоді, коли `Тип особи = Партнер`. Це нормально: ви можете приховати це поле в переглядах, де воно не потрібно.
|
|
|
|
### Запитання, які допоможуть визначити ваш вибір
|
|
|
|
Запитайте себе:
|
|
|
|
- Чи це просто властивість чогось, що вже є, чи йому потрібні власні властивості?
|
|
- Чи потрібно буде відстежувати декілька таких записів під ключовим записом, не знаючи, скільки саме?
|
|
- Чи цей концепт пов'язаний з кількома різними об'єктами, а не тільки з одним?
|
|
- Чи буде у нього власний життєвий цикл (наприклад, стадії, дати початку/закінчення)?
|
|
|
|
Якщо ви відповіли "так" на одне або більше з цих питань, ймовірно, настав час для нового об'єкта.
|
|
|
|
## Потрібна допомога?
|
|
|
|
Наша команда може допомогти вам розробити та створити модель даних, яка вам потрібна. Відкрийте наш пакет для входження [тут](https://twenty.com/onboarding-packages).
|
|
|
|
|