Standarddatamodellerna

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 2 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Dataplattformen i Salesforce: mer än en databas · Nästa: Bygg ditt eget: anpassade objekt

Frågan den här modulen besvarar: Vad har Salesforce redan modellerat åt dig, och hur hänger det ihop?

I modul 1 sa jag åt dig att titta på moderskeppet: innan du hittar på något, titta på hur Salesforce själv gör det. I den här modulen tittar vi på riktigt. Salesforce har redan modellerat en stor del av verksamheten åt dig, i sina standardobjekt, och två av de modellerna gör det mesta av jobbet i de flesta orgar jag kliver in i: Säljmodellen och Servicemodellen. Innan du kan avgöra om något förtjänar ett anpassat objekt behöver du veta vad som redan finns. Det handlar de två kommande modulerna om.

Vad som gör ett objekt till standard

Ett standardobjekt följer med från start. Salesforce byggde det, det har ett definierat syfte och det kommer med egna fält och relationer. Du kan lägga till fält på det, bygga automatisering runt det och ändra dess layouter, men du kan inte designa om det: standardfälten och relationerna är Salesforces.

Titta på namnen. Account, Contact, Case. Inget prefix, inget suffix. Det är Salesforce som håller det utrymmet för sig själv. Allt vi bygger slutar på __c, så Salesforce kan lägga till nya standardobjekt när som helst utan att någonsin krocka med något i din org. Och det gör Salesforce, i varje release.

Någon gång på vägen byggde någon ett produktobjekt som inte fungerade och som fick lämnas kvar. Därför är API-namnet Product2. Det är mitt första lackmustest när någon säger att de kan Salesforce.

Säljmodellen

Börja till vänster, med lead (Lead): någon som kanske blir kund. En lead är egentligen inte en del av modellen än. Det är ett väntrum. När du konverterar den skapar Salesforce de riktiga posterna: ett konto (Account), en kontakt (Contact) och, om det finns en affär, en affärsmöjlighet (Opportunity). Därför ritar jag leaden vid sidan av.

Kontot är företaget. Dess kontakter är personerna där. En affärsmöjlighet är en affär med det kontot. Hittills inget du inte väntade dig.

Sedan blir det intressant. Vad ingår i affären? Varje rad är en affärsmöjlighetsprodukt (Opportunity Product), och en affärsmöjlighetsprodukt pekar inte direkt på en produkt. Den pekar på en prisbokspost (Price Book Entry): den här produkten, till det här priset, i den här prisboken. Prisboksposten sitter mellan produkten (Product) och prisboken (Price Book), så samma produkt kan ha ett pris i standardprisboken och ett annat i din partnerprisbok.

Det är två relationer som blev saker, den ena efter den andra. Minns du leveransraden (Delivery Item) från kapitel 2, mellan leveransen och produkten, och Hundtrick mellan Hund och Trick? Salesforce gjorde exakt samma sak här, två gånger: affärsmöjlighetsprodukten mellan affärsmöjligheten och prisboksposten, och prisboksposten mellan produkten och prisboken. När du kan läsa det kan du läsa det mesta av standarddatamodellen.

Click to enlarge

Här är den kedjan på nära håll, med fälten som håller ihop den:

Click to enlarge

En regel som folk snubblar på: det finns en standardprisbok, och en prisbokspost i vilken annan prisbok som helst kan helt enkelt använda produktens standardpris. Ta reda på vilken prisbok en affärsmöjlighet använder innan du laddar in dess produkter.

Servicemodellen

Nu andra sidan av huset. Samma konto, samma kontakter. När något går fel öppnar kunden ett ärende (Case).

Ärendet handlar oftast om något som kunden har, och Salesforce har ett objekt för det: tillgång (Asset). I modul 5 kallar jag det standardobjektet som folk förbiser. Det är något kunden har, oavsett om de köpte det av dig eller inte.

Och vad har kunden rätt till? Det är berättigandet (Entitlement): den support ett konto har rätt att få, ofta kopplad till en tillgång, en produkt eller ett serviceavtal. Sätt ett berättigande på ett ärende, så vet ärendet vilken supportnivå det ska få.

Click to enlarge

Titta på linjen som går från ärendet tillbaka till sig själv. Varje ärende har fältet Parent Case (överordnat ärende), och det pekar på ett annat ärende. Det är en självrelation (self-lookup): en relation från ett objekt till sig självt. Den förvirrar många första gången de ser den, så här är de två anledningarna till att jag använder den.

Ett: ett stort problem som bryts ned i mindre. Kunden rapporterar att hela installationen ligger nere. Vi öppnar delärenden för nätverket, hårdvaran och konfigurationen, som var och ett hanteras för sig, och alla löses uppåt: det överordnade ärendet är inte klart förrän de är det.

Två: historik. Ett ärende stängdes förra månaden, och nu är samma problem tillbaka. Det nya ärendet pekar tillbaka på det ursprungliga, så den som öppnar det ser att det här har hänt förut, och vad som gjordes åt det.

Vi återkommer till självrelationer när vi kommer till relationer i modul 7.

Lägg märke till att kontot och kontakten sitter på samma ställe i båda diagrammen. Det är samma poster. En säljare och en servicehandläggare tittar på samma kund, från olika sidor av huset. Det är ett av de starkaste argumenten för att hålla sig till standard: modellerna byggdes för att mötas.

Filer och bilagor

Allt på en post är inte fält. Avtal, foton, PDF:er och kalkylblad är filer, och de hör hemma i Salesforce Files, inte i den gamla Attachments-modellen, som är legacy. Om dokumentet redan finns i SharePoint Online, OneDrive, Google Drive eller Box låter Files Connect användarna nå det från Salesforce utan att kopiera in det.

Filer räknas annorlunda än poster. Salesforce delar lagringen i två: fillagring (file storage) rymmer bilagor, Files, Salesforce CRM Content, Chatter-filer och liknande, och datalagring (data storage) rymmer dina poster. Fillagringen växer snabbt när varje post får foton eller skanningar, så stora mängder bilder, som fotona från en fältapp, hör ofta hemma helt utanför Salesforce, där Salesforce bara behåller en länk. Modul 4 återkommer till det.

Två kolumner eller tvåhundra

Datalagring räknas också annorlunda än i en databas. I en vanlig databas är en tabell med två kolumner och en miljon rader liten, och en tabell med hundra kolumner och en miljon rader är en elefant. Salesforce väger dem lika: de flesta poster räknas som cirka 2 kB, oavsett hur många fält de har. Det finns undantag. En kampanj räknas tyngre, ett e-postmeddelande räknas efter sin verkliga storlek, och ett personkonto räknas som cirka 4 kB, eftersom det är ett konto och en kontakt.

Här är ett tips. Varje gång jag kliver in i en ny org är ett av de första ställena jag går till Setup → Storage Usage (lagringsanvändning). Jag ber till och med en kund om en skärmdump vid första samtalet. Den skärmen ljuger inte. Den talar om vilka objekt som växer, och vilka som redan är elefanterna.

Personkonton: när kunden är en person

Modellen med konto och kontakt fungerar fint för ett företag och personerna där. Men om din kund inte är ett företag? Om det är en person?

Det är personkontot (Person Account): ett konto och en kontakt kombinerade i en enda post, för enskilda personer. Kontaktfälten följer med, och de anpassade dyker upp med ett eget suffix, __pc. Varje personkonto räknas mot både konto- och kontaktlagringen, eftersom det under ytan är båda.

En varning innan du slår på dem: när personkonton väl är aktiverade kan de inte inaktiveras. Det är reversibilitetstestet från kapitel 1 i sin renaste form. Modul 5 ger dig min hållning om när de är värda det.

Vad en arkitekt bestämmer här

• Vilka delar av verksamheten Salesforce redan har modellerat, innan något nytt designas.
• Om ett begrepp hamnar i Säljmodellen, Servicemodellen eller båda, med vetskapen att de delar konto och kontakt.
• Var dokument och bilder bor: Salesforce Files, ett anslutet filsystem eller utanför plattformen med en länk.
• Vad data kommer att kosta i lagring, räknat som Salesforce räknar: poster, inte kolumner.
• Om kunden är ett företag eller en person, innan du slår på något som inte går att stänga av.

Och när Salesforce inte har det du behöver? Då bygger du det. Det kommer härnäst.

Utforska vidare

• OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (på engelska, kontrollerad 2026-10-12): en av produkterna (Product2) i listan som hör till en affärsmöjlighet; prisboksposten är obligatorisk.
• PricebookEntry (opens in a new tab), Object Reference (på engelska, kontrollerad 2026-10-12): en koppling mellan en Pricebook2 och en Product2; en post kan använda standardpriset.
• Case (opens in a new tab), Object Reference (på engelska, kontrollerad 2026-10-12): ParentId, ID:t för det överordnade ärendet i hierarkin, med etiketten Parent Case; en lookup till Case.
• Entitlement (opens in a new tab), Object Reference (på engelska, kontrollerad 2026-10-12): den kundsupport ett konto eller en kontakt har rätt att få, eventuellt baserad på en tillgång, en produkt eller ett serviceavtal.
• Data and Storage Resources (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): vad fillagring och datalagring omfattar.
• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): de flesta poster i Salesforce tar cirka 2 kB datalagring; personkonton cirka 4 kB.
• Enable Person Accounts (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): när Person Accounts väl är aktiverat kan det inte inaktiveras.
• Files Connect FAQ (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-09-25).