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
4.7 KiB
Plaintext
70 lines
4.7 KiB
Plaintext
---
|
|
title: Anpassa din datamodell
|
|
info: "Lär dig hur du utformar och skapar en datamodell som speglar hur du arbetar."
|
|
image: /images/user-guide/fields/custom_data_model.png
|
|
sectionInfo: Flexibel datamodell utformad för att stödja dina unika affärsprocesser
|
|
---
|
|
|
|
<Frame>
|
|
<img src="/images/user-guide/fields/custom_data_model.png" alt="Header" />
|
|
</Frame>
|
|
|
|
## Vad är en datamodell?
|
|
|
|
En datamodell är strukturen som definierar hur information organiseras i ditt CRM. Den bestämmer vilka objekt som finns (som företag, personer eller möjligheter), vilka egenskaper de har (dessa är fälten) och hur de förhåller sig till varandra. Du kan tänka på det som kartan över din kunddata.
|
|
|
|
## Varför bör du anpassa din datamodell?
|
|
|
|
Varje företag arbetar på ett unikt sätt. Att kunna helt anpassa din datamodell innebär att du kan forma Twenty runt dina processer istället för att tvinga in dina processer i ett stelbent system.
|
|
Twenty erbjuder den flexibilitet du behöver för att forma datamodellen som bäst stöder din dagliga verksamhet. Du kan skapa så många anpassade objekt och fält du behöver, priset förändras inte.
|
|
|
|
## Tips för att utforma din datamodell
|
|
|
|
Det finns sällan bara ett sätt att bygga en datamodell. Nedan följer några tips för att hjälpa dig bygga din egen.
|
|
|
|
**1. Börja med dina kärnobjekt.**
|
|
Identifiera huvudkoncepten du arbetar med (t.ex. Företag, Personer, Möjligheter). Dessa tre objekt är redan tillgängliga eftersom de används mycket ofta. Men tänk på alla andra du kan behöva.
|
|
Exempel: Stripe kan behöva ett objekt `Prenumerationer`, Airbnb kan behöva ett objekt `Resor`, en start-up-accelerator ett objekt `Partier`.
|
|
|
|
**2. Använd fält för variationer, inte nya objekt.**
|
|
Om något bara är en egenskap hos ett befintligt objekt (t.ex. `Bransch` för ett företag, eller `Status` för en möjlighet), gör det till ett fält. Fält är bäst för kategorier, etiketter och attribut.
|
|
|
|
**3. Skapa ett nytt objekt när det står på egna ben.**
|
|
Om konceptet har sin egen livscykel, egenskaper eller relationer, förtjänar det vanligtvis ett objekt. Till exempel:
|
|
|
|
- **Projekt** som har sina egna deadlines, ägare och uppgifter
|
|
- **Prenumerationer** som kopplar företag, produkter och fakturor
|
|
- **Evenemang** som involverar många deltagare och uppföljningsåtgärder
|
|
|
|
Dessa går bortom ett enda fält eftersom de bär sin egen data och relationer.
|
|
|
|
**4. Skapa ett objekt när antalet relaterade poster är öppet.**
|
|
Om något kan länkas flera gånger och du inte vet hur många, är det bättre som sitt eget objekt. Till exempel, istället för att skapa fält som `Produkt 1`, `Produkt 2`, etc., definiera ett `Produkt`-objekt och koppla det till den ursprungliga posten. På detta sätt kan du stödja en, två eller hundra produkter utan att ändra din modell.
|
|
|
|
**5. Håll det enkelt först.**
|
|
Börja med fält. Flytta till nya objekt endast när du känner gränserna: för många fält, upprepade poster, eller relationer som inte passar in.
|
|
|
|
### Speciell notering om Personer, Företag och Möjligheter
|
|
|
|
- **`Personer`, `Företag` och `Möjligheter` är de enda objekten från vilken du kan komma åt e-postmeddelanden och möten som synkroniseras från din e-postinkorg / kalender.** Vi rekommenderar att du använder dessa så mycket som möjligt. Om du behöver skapa kategorier av `Personer` eller `Företag`, använd fält snarare än nya objekt.
|
|
|
|
Exempel: det är bäst att använda `Personer`-objektet för både prospekter och partners, och lägga till ett fält som heter `Person Typ`. Undvik att skapa ett `Partner`-objekt, eftersom du inte skulle kunna komma åt e-posttrådar från det. Skapa istället olika vyer under `Personer`: en som visar partners, en annan som visar prospekter.
|
|
- Med tanke på ovanstående punkt är det okej att ha fält som inte tillämpas på varje post. Till exempel, under `Personer` kan du lägga till ett fält `Referenslänk` som bara är relevant när `Person Typ = Partner`. Det är okej: du kan dölja detta fält från vyer där det inte behövs.
|
|
|
|
### Frågor för att vägleda ditt val
|
|
|
|
Fråga dig själv:
|
|
|
|
- Är detta bara en egenskap hos något jag redan har, eller behöver det egna egenskaper?
|
|
- Kommer jag någonsin att behöva spåra flera av dessa per post, utan att veta hur många i förväg?
|
|
- Förbinder detta koncept flera olika objekt, inte bara ett?
|
|
- Kommer det ha sin egen livscykel (t.ex. stadier, start/stop datum)?
|
|
|
|
Om svaret är “ja” på en eller flera av dessa, är det förmodligen dags för ett nytt objekt.
|
|
|
|
## Vill du ha hjälp?
|
|
|
|
Vårt team kan hjälpa dig att utforma och skapa den datamodell du behöver. Upptäck vårt Onboarding Pack [här](https://twenty.com/onboarding-packages).
|
|
|
|
|