Gå til indhold
SteveTechArcSteveTechArc Courses

Standarddatamodellerne

Findes også på 28 sprog

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 · Norsk bokmål · 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.
Billedet er lavet med AI

Modul 2 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Salesforce-dataplatformen: mere end en database · Næste: Byg dit eget: brugerdefinerede objekter

Spørgsmålet, dette modul besvarer: Hvad har Salesforce allerede modelleret for dig, og hvordan hænger det sammen?

I modul 1 sagde jeg, at du skal kigge på moderskibet: Før du opfinder noget, så se på, hvordan Salesforce selv gør det. I dette modul kigger vi faktisk efter. Salesforce har allerede modelleret en stor del af forretningen for dig i sine standardobjekter, og to af de modeller klarer det meste af arbejdet i de fleste org’er, jeg kommer ind i: salgsmodellen og servicemodellen. Før du kan beslutte, om noget fortjener et brugerdefineret objekt, skal du vide, hvad der allerede er der. Det handler de næste to moduler om.

Hvad gør et objekt til et standardobjekt

Sektion kaldt “Hvad gør et objekt til et standardobjekt ”

Et standardobjekt følger med fra start. Salesforce har bygget det, det har et defineret formål, og det kommer med sine egne felter og relationer. Du kan tilføje felter til det, bygge automatisering omkring det og ændre dets layouts, men du kan ikke designe det om: Standardfelterne og -relationerne tilhører Salesforce.

Se på navnene. Account, Contact, Case. Intet præfiks, intet suffiks. Det er Salesforce, der holder det område for sig selv. Alt, hvad vi bygger, ender på __c, så Salesforce kan tilføje nye standardobjekter når som helst uden nogensinde at støde sammen med noget i din org. Og det gør den, i hver eneste release.

Undervejs byggede nogen et produktobjekt, der ikke fungerede, og som måtte efterlades. Derfor er API-navnet Product2. Det er min første lakmusprøve, når nogen fortæller mig, at de kender Salesforce.

Salgsmodellen

Sektion kaldt “Salgsmodellen ”

Start til venstre med kundeemnet (Lead): en person, der måske bliver kunde. Et kundeemne er egentlig ikke en del af modellen endnu. Det er et venteområde. Når du konverterer det, opretter Salesforce de rigtige poster: en konto (Account), en kontakt (Contact) og, hvis der er en handel, en salgsmulighed (Opportunity). Derfor tegner jeg kundeemnet ude til siden.

Kontoen er virksomheden. Dens kontakter er personerne i den. En salgsmulighed er en handel med den konto. Indtil videre intet, du ikke havde forventet.

Så bliver det interessant. Hvad er der i handlen? Hver linje er et salgsmulighedsprodukt (Opportunity Product), og et salgsmulighedsprodukt peger ikke direkte på et produkt. Det peger på en prisbogspost (Price Book Entry): dette produkt, til denne pris, i denne prisbog. Prisbogsposten sidder mellem produktet (Product) og prisbogen (Price Book), så det samme produkt kan have én pris i standardprisbogen og en anden i din partnerprisbog.

Det er to relationer, der blev til ting, den ene efter den anden. Kan du huske leveringslinjen (Delivery Item) fra kapitel 2, mellem leveringen og produktet, og hundetricket mellem hunden og tricket? Salesforce gjorde præcis det samme her, to gange: salgsmulighedsproduktet mellem salgsmuligheden og prisbogsposten, og prisbogsposten mellem produktet og prisbogen. Når du kan læse det, kan du læse det meste af standarddatamodellen.

Salgsmodellen Salgsmodellen. Et kundeemne, lidt til venstre, konverteres til en konto. En konto har kontakter og salgsmuligheder. En salgsmulighed bruger en prisbog og indeholder salgsmulighedsprodukter. Hvert salgsmulighedsprodukt prissættes af én prisbogspost. En prisbog oplister prisbogsposter, og et produkt optræder i prisbogsposter, så hver prisbogspost forbinder ét produkt og én prisbog. konverteres til har har bruger indeholder prissættes af oplister optræder i Kundeemne Konto Kontakt Salgsmulighed Prisbog Salgsmulighedsprodukt Prisbogspost Produkt præcis én nul eller én én eller mange nul eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Her er den kæde helt tæt på, med de felter, der holder den sammen:

Priskæden tæt på Priskæden som en detaljeret datamodel. Et salgsmulighedsprodukt bærer sit salgsmuligheds-id, sit prisbogspost-id, et antal og en salgspris og prissættes af én prisbogspost. Prisbogsposten bærer sit prisbogs-id, sit produkt-id, en listepris og et flag Brug standardpris. En prisbog har et navn og et flag Er standard; et produkt har et navn og en produktkode. prissættes af oplister optræder i Prisbog Prisbogs-id POST-ID Navn Er standard Salgsmulighedsprodukt Salgsmulighedsprodukt-id POST-ID Salgsmuligheds-id Prisbogspost-id Antal Salgspris Prisbogspost Prisbogspost-id POST-ID Prisbogs-id Produkt-id Listepris Brug standardpris Produkt Produkt-id POST-ID Navn Produktkode præcis én nul eller én én eller mange nul eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

En regel, folk falder over: Der findes en standardprisbog, og en prisbogspost i enhver anden prisbog kan simpelthen bruge produktets standardpris. Vid, hvilken prisbog en salgsmulighed bruger, før du indlæser dens produkter.

Servicemodellen

Sektion kaldt “Servicemodellen ”

Nu den anden side af huset. Samme konto, samme kontakter. Når noget går galt, opretter kunden en sag (Case).

Sagen handler som regel om noget, kunden har, og det har Salesforce et objekt til: aktivet (Asset). I modul 5 kalder jeg det det standardobjekt, folk overser. Det er en ting, kunden har, uanset om de har købt den af dig eller ej.

Og hvad har kunden ret til? Det er berettigelsen (Entitlement): den support, en konto er berettiget til at få, ofte knyttet til et aktiv, et produkt eller en servicekontrakt. Sæt en berettigelse på en sag, og så ved sagen, hvilket supportniveau den skal have.

Servicemodellen Servicemodellen. En konto har kontakter, sager og aktiver. En kontakt rapporterer sager. En sag kan handle om ét aktiv, og en berettigelse, som hører til en konto, dækker sager. En streg fra sagen tilbage til sig selv, rundt om dens hjørne, er den overordnede sag: en sag er overordnet for nul eller mange sager, og hver sag har nul eller én overordnet. har har rapporterer ejer handler om dækker overordnet for Konto Kontakt Aktiv Sag Berettigelse præcis én nul eller én én eller mange nul eller mange © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Se på linjen, der går fra sagen tilbage til sig selv. Hver sag har et felt Parent Case (overordnet sag), og det peger på en anden sag. Det er et self-lookup: en relation fra et objekt til sig selv. Det forvirrer mange første gang, de ser det, så her er de to grunde til, at jeg bruger det.

Én: et stort problem, der deles op i mindre. Kunden melder, at hele installationen er nede. Vi opretter undersager for netværket, hardwaren og konfigurationen, som hver bliver arbejdet på for sig, og de løses alle opad: Den overordnede sag er ikke færdig, før de er.

To: historik. En sag blev lukket i sidste måned, og nu er det samme problem tilbage. Den nye sag peger tilbage på den oprindelige, så alle, der åbner den, kan se, at det er sket før, og hvad der blev gjort ved det.

Vi vender tilbage til self-lookups, når vi kommer til relationer i modul 7.

Læg mærke til, at kontoen og kontakten står samme sted i begge diagrammer. Det er de samme poster. En sælger og en servicemedarbejder ser på den samme kunde fra hver sin side af huset. Det er et af de stærkeste argumenter for at holde sig til standarden: Modellerne blev bygget til at mødes.

Filer og vedhæftninger

Sektion kaldt “Filer og vedhæftninger ”

Ikke alt på en post er et felt. Kontrakter, fotos, PDF’er og regneark er filer, og de hører hjemme i Salesforce Files, ikke i den gamle Attachments-model, som er forældet. Hvis dokumentet allerede ligger i SharePoint Online, OneDrive, Google Drive eller Box, lader Files Connect brugerne nå det fra Salesforce uden at kopiere det ind.

Filer tælles anderledes end poster. Salesforce deler lagerpladsen i to: fillagring (file storage) rummer vedhæftninger, Files, Salesforce CRM Content, Chatter-filer og lignende, og datalagring (data storage) rummer dine poster. Fillagringen stiger hurtigt, når hver post får fotos eller scanninger, så store mængder billeder, som fotos fra en app i marken, hører ofte helt hjemme uden for Salesforce, mens Salesforce kun gemmer et link. Modul 4 vender tilbage til det.

To kolonner eller to hundrede

Sektion kaldt “To kolonner eller to hundrede ”

Datalagring tælles også anderledes end i en database. I en almindelig database er en tabel med to kolonner og en million rækker lille, og en tabel med hundrede kolonner og en million rækker er en elefant. Salesforce vejer dem ens: De fleste poster tæller som cirka 2 kB, uanset hvor mange felter de har. Der er undtagelser. En kampagne tæller mere, en e-mailbesked tæller med sin faktiske størrelse, og en personkonto tæller som cirka 4 kB, fordi den er både en konto og en kontakt.

Her er et tip. Når jeg kommer ind i en ny org, er et af de første steder, jeg går hen, Setup → Storage Usage. Jeg beder endda en kunde om et skærmbillede på det første opkald. Den skærm lyver ikke. Den fortæller dig, hvilke objekter der vokser, og hvilke der allerede er elefanterne.

Personkonti: når kunden er en person

Sektion kaldt “Personkonti: når kunden er en person ”

Konto- og kontaktmodellen fungerer smukt for en virksomhed og personerne i den. Men hvad hvis din kunde ikke er en virksomhed? Hvad hvis det er en person?

Det er personkontoen (person account): en konto og en kontakt slået sammen i én post, til enkeltpersoner. Deres kontaktfelter følger med, og de brugerdefinerede dukker op med deres eget suffiks, __pc. Hver personkonto tæller med i både konto- og kontaktlagringen, fordi den nedenunder er begge dele.

En advarsel, før du slår dem til: Når personkonti først er aktiveret, kan de ikke deaktiveres. Det er reversibilitetstesten fra kapitel 1 i sin reneste form. Modul 5 giver dig min holdning til, hvornår de er det værd.

Hvad en arkitekt beslutter her

Sektion kaldt “Hvad en arkitekt beslutter her ”
  • Hvilke dele af forretningen Salesforce allerede har modelleret, før noget nyt bliver designet.
  • Om et begreb lander i salgsmodellen, servicemodellen eller begge, velvidende at de deler kontoen og kontakten.
  • Hvor dokumenter og billeder bor: Salesforce Files, et tilkoblet filsystem eller uden for platformen med et link.
  • Hvad dataene vil koste i lagerplads, talt på den måde, Salesforce tæller: poster, ikke kolonner.
  • Om kunden er en virksomhed eller en person, før du slår noget til, som ikke kan slås fra.

Og når Salesforce ikke har det, du har brug for? Så bygger du det. Det kommer næste gang.

Læs mere

Sektion kaldt “Læs mere ”