Gå til innholdet
SteveTechArcSteveTechArc Courses

Standarddatamodellene

Finnes også på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Bildet er laget med KI

Modul 2 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Dataplattformen i Salesforce: mer enn en database · Neste: Bygg ditt eget: egendefinerte objekter

Spørsmålet denne modulen besvarer: Hva har Salesforce allerede modellert for deg, og hvordan henger det sammen?

I modul 1 sa jeg at du skal se til moderskipet: før du finner opp noe, se på hvordan Salesforce selv gjør det. I denne modulen ser vi faktisk etter. Salesforce har allerede modellert mye forretning for deg i standardobjektene sine, og to av de modellene gjør mesteparten av jobben i de fleste orgene jeg kommer inn i: salgsmodellen og servicemodellen. Før du kan avgjøre om noe fortjener et egendefinert objekt, må du vite hva som allerede finnes. Det er de neste to modulene.

Hva som gjør et objekt til et standardobjekt

Section titled “Hva som gjør et objekt til et standardobjekt ”

Et standardobjekt følger med fra start. Salesforce bygde det, det har et definert formål, og det kommer med egne felt og relasjoner. Du kan legge til felt på det, bygge automatisering rundt det og endre oppsettene, men du kan ikke designe det om: standardfeltene og relasjonene tilhører Salesforce.

Se på navnene. Account, Contact, Case. Ingen prefiks, ingen suffiks. Det er Salesforce som holder av det rommet for seg selv. Alt vi bygger, slutter på __c, så Salesforce kan legge til nye standardobjekter når som helst uten noen gang å kollidere med noe i orgen din. Og det gjør den, hver eneste release.

En gang underveis bygde noen et produktobjekt som ikke fungerte og måtte legges bak seg. Derfor er API-navnet Product2. Det er min første lakmustest når noen forteller meg at de kan Salesforce.

Salgsmodellen

Section titled “Salgsmodellen ”

Begynn til venstre, med kundeemnet (Lead): noen som kanskje blir kunde. Et kundeemne er egentlig ikke en del av modellen ennå. Det er et venteområde. Når du konverterer det, lager Salesforce de ekte postene: en konto (Account), en kontakt (Contact) og, hvis det finnes en avtale, en salgsmulighet (Opportunity). Derfor tegner jeg kundeemnet litt på siden.

Kontoen er firmaet. Kontaktene er folkene der. En salgsmulighet er en avtale med den kontoen. Så langt ingenting du ikke ventet.

Så blir det interessant. Hva er i avtalen? Hver linje er et salgsmulighetsprodukt (Opportunity Product), og et salgsmulighetsprodukt peker ikke rett på et produkt (Product). Det peker på en prislisteoppføring (Price Book Entry): dette produktet, til denne prisen, i denne prislisten. Prislisteoppføringen sitter mellom produktet og prislisten (Price Book), så det samme produktet kan ha én pris i standardprislisten og en annen i partnerprislisten din.

Det er to relasjoner som ble til ting, den ene etter den andre. Husker du leveringslinjen (Delivery Item) fra kapittel 2, mellom leveringen og produktet, og hundetrikset mellom hunden og trikset? Salesforce gjorde akkurat det samme her, to ganger: salgsmulighetsproduktet mellom salgsmuligheten og prislisteoppføringen, og prislisteoppføringen mellom produktet og prislisten. Når du kan lese det, kan du lese det meste av standarddatamodellen.

Salgsmodellen Salgsmodellen. Et kundeemne, litt til venstre, konverteres til en konto. En konto har kontakter og salgsmuligheter. En salgsmulighet bruker en prisliste og inneholder salgsmulighetsprodukter. Hvert salgsmulighetsprodukt prises av én prislisteoppføring. En prisliste lister prislisteoppføringer, og et produkt finnes i prislisteoppføringer, så hver prislisteoppføring kobler ett produkt og én prisliste. konverteres til har har bruker inneholder prises av lister finnes i Kundeemne Konto Kontakt Salgsmulighet Prisliste Salgsmulighetsprodukt Prislisteoppføring Produkt nøyaktig én null eller én én eller mange null eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Her er den kjeden på nært hold, med feltene som holder den sammen:

Priskjeden på nært hold Priskjeden som en detaljert datamodell. Et salgsmulighetsprodukt bærer salgsmulighets-ID-en, prislisteoppføring-ID-en, et antall og en salgspris, og prises av én prislisteoppføring. Prislisteoppføringen bærer prisliste-ID-en, produkt-ID-en, en listepris og et flagg Bruk standardpris. En prisliste har et navn og et flagg Er standard; et produkt har et navn og en produktkode. prises av lister finnes i Prisliste Prisliste-ID POST-ID Navn Er standard Salgsmulighetsprodukt Salgsmulighetsprodukt-ID POST-ID Salgsmulighets-ID Prislisteoppføring-ID Antall Salgspris Prislisteoppføring Prislisteoppføring-ID POST-ID Prisliste-ID Produkt-ID Listepris Bruk standardpris Produkt Produkt-ID POST-ID Navn Produktkode nøyaktig én null eller én én eller mange null eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Én regel folk snubler i: det finnes en standardprisliste, og en prislisteoppføring i en hvilken som helst annen prisliste kan ganske enkelt bruke produktets standardpris. Vit hvilken prisliste en salgsmulighet bruker før du laster inn produktene.

Servicemodellen

Section titled “Servicemodellen ”

Nå den andre siden av huset. Samme konto, samme kontakter. Når noe går galt, åpner kunden en sak (Case).

Saken handler som regel om noe kunden har, og Salesforce har et objekt for det: aktivumet (Asset). I modul 5 kommer jeg til å kalle det standardobjektet folk overser. Det er en ting kunden har, enten de kjøpte den av deg eller ikke.

Og hva har kunden krav på? Det er rettigheten (Entitlement): støtten en konto har rett til å få, ofte knyttet til et aktivum, et produkt eller en servicekontrakt. Sett en rettighet på en sak, og nå vet saken hvilket støttenivå den skal få.

Servicemodellen Servicemodellen. En konto har kontakter, saker og aktiva. En kontakt rapporterer saker. En sak kan gjelde ett aktivum, og en rettighet, som hører til en konto, dekker saker. En linje fra saken tilbake til seg selv, rundt hjørnet, er den overordnede saken: en sak er overordnet for null eller mange saker, og hver sak har null eller én overordnet. har har rapporterer eier gjelder dekker overordnet for Konto Kontakt Aktivum Sak Rettighet nøyaktig én null eller én én eller mange null eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Se på linjen som går fra saken tilbake til seg selv. Hver sak har et Parent Case-felt (overordnet sak), og det peker på en annen sak. Det er en selvreferanse (self-lookup): en relasjon fra et objekt til seg selv. Den forvirrer mange første gang de ser den, så her er de to grunnene til at jeg bruker den.

Én: et stort problem som brytes ned i mindre. Kunden melder at hele installasjonen er nede. Vi åpner undersaker for nettverket, maskinvaren og konfigurasjonen, hver jobbet med for seg, og alle løses oppover: den overordnede saken er ikke ferdig før de er det.

To: historikk. En sak ble lukket forrige måned, og nå er det samme problemet tilbake. Den nye saken peker tilbake på den opprinnelige, så alle som åpner den, kan se at dette har skjedd før, og hva som ble gjort med det.

Vi kommer tilbake til selvreferanser når vi kommer til relasjoner i modul 7.

Legg merke til at kontoen og kontakten sitter på samme sted i begge diagrammene. Det er de samme postene. En selger og en servicemedarbeider ser på den samme kunden, fra hver sin side av huset. Det er et av de sterkeste argumentene for å holde seg til standard: modellene ble bygd for å møtes.

Filer og vedlegg

Section titled “Filer og vedlegg ”

Ikke alt på en post er et felt. Kontrakter, bilder, PDF-er og regneark er filer, og de hører hjemme i Salesforce Files, ikke i den gamle Attachments-modellen, som er utdatert. Ligger dokumentet allerede i SharePoint Online, OneDrive, Google Drive eller Box, lar Files Connect brukerne nå det fra Salesforce uten å kopiere det inn.

Filer telles annerledes enn poster. Salesforce deler lagringen i to: fillagring rommer vedlegg, Files, Salesforce CRM Content, Chatter-filer og lignende, og datalagring rommer postene dine. Fillagringen stiger fort når hver post får bilder eller skanninger, så store mengder bilder, som bildene fra en feltapp, hører ofte hjemme helt utenfor Salesforce, mens Salesforce bare beholder en lenke. Modul 4 kommer tilbake til det.

To kolonner eller to hundre

Section titled “To kolonner eller to hundre ”

Datalagring telles også annerledes enn i en database. I en vanlig database er en tabell med to kolonner og en million rader liten, og en tabell med hundre kolonner og en million rader er en elefant. Salesforce veier dem likt: de fleste poster teller som omtrent 2 kB, uansett hvor mange felt de har. Det finnes unntak. En kampanje teller mer, en e-postmelding teller med sin faktiske størrelse, og en personkonto teller som omtrent 4 kB, fordi den er en konto og en kontakt.

Her er et tips. Hver gang jeg kommer inn i en ny org, er et av de første stedene jeg går til Setup → Storage Usage. Jeg ber til og med en kunde om et skjermbilde i den første samtalen. Den skjermen lyver ikke. Den forteller deg hvilke objekter som vokser, og hvilke som allerede er elefantene.

Personkontoer: når kunden er en person

Section titled “Personkontoer: når kunden er en person ”

Konto- og kontaktmodellen fungerer utmerket for et firma og folkene der. Men hva om kunden din ikke er et firma? Hva om det er en person?

Det er personkontoen (Person Account): en konto og en kontakt slått sammen til én post, for enkeltpersoner. Kontaktfeltene følger med, og de egendefinerte dukker opp med sitt eget suffiks, __pc. Hver personkonto teller mot både konto- og kontaktlagring, fordi den under panseret er begge deler.

Én advarsel før du slår dem på: når personkontoer først er aktivert, kan de ikke deaktiveres. Det er reversibilitetstesten fra kapittel 1 i sin reneste form. Modul 5 gir deg mitt standpunkt på når de er verdt det.

Hva en arkitekt bestemmer her

Section titled “Hva en arkitekt bestemmer her ”
  • Hvilke deler av virksomheten Salesforce allerede har modellert, før noe nytt blir designet.
  • Om et begrep havner i salgsmodellen, servicemodellen eller begge, vel vitende om at de deler kontoen og kontakten.
  • Hvor dokumenter og bilder bor: Salesforce Files, et tilkoblet filsystem eller utenfor plattformen med en lenke.
  • Hva dataene kommer til å koste i lagring, telt slik Salesforce teller: poster, ikke kolonner.
  • Om kunden er et firma eller en person, før du slår på noe som ikke kan slås av.

Og når Salesforce ikke har det du trenger? Da bygger du det. Det kommer neste.

Les mer

Section titled “Les mer ”