Dataarkitektur i Salesforce

🌐 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

Studieguide för kapitel 3 i kursen Data Architect. Läs de tio modulerna först; den här sidan hjälper dig att kontrollera vad som har fastnat.

Om den här studieguiden. Den bygger enbart på kursens eget innehåll och på listan över mål i Salesforce publicerade provguide. Den bygger aldrig på riktiga provfrågor, och den påstår inte att den vet vad som kommer på provet. Om du har skrivit provet, skicka inte frågor från det till mig: certifieringsavtalet förbjuder att de delas, och att plugga in svar är ändå fel sätt att bli arkitekt.

Det här är kapitlet där modellen möter plattformen, och det bär en stor del av provet. Det matar båda de största avsnitten, Data Modeling and Database Design och Salesforce Data Management, en fjärdedel av provet vardera. Plattformens siffror ändras: checklistan anger de siffror som modulerna hänvisar till, med datumet då de kontrollerades. Lär dig vad varje gräns är till för, och kontrollera den aktuella siffran innan du förlitar dig på den.

Inför provet

Bocka av dem allt eftersom. Varje punkt länkar till där den lärs ut.

DM-1: designa datamodellen på plattformen

• Jag vet att Salesforce är en metadatadriven plattform med flera hyresgäster (multitenant): ett objekt är metadata, inte en ny tabell, och varje objekt får sina API:er i samma stund som det finns. (Metadata är ritningen, Ditt API följde med objektet)
• Jag vet att governor limits (plattformens gränser) finns så att en hyresgäst inte kan ta över delade resurser. (Du kan inte ta över hissen)
• Jag kan läsa standarddatamodellerna: konvertering av lead till konto, kontakt och affärsmöjlighet; en affärsmöjlighetsprodukt (Opportunity Product) pekar på en prisbokspost (Price Book Entry), som pekar på Product2; och ärende, tillgång och berättigande (Entitlement) på servicesidan. (Säljmodellen, Servicemodellen)
• Jag vet vad skärmen New Custom Object bestämmer: ett postnamn av typen Text eller Auto Number; Object Classification (med delning, Bulk API och Streaming API påslagna är det ett Enterprise Application-objekt, med dem avslagna ett Light Application-objekt); och Allow Search, avslaget som standard. (Skärmen New Custom Object)
• Jag kan läsa ett API-namn: standardobjekt och standardfält har inget prefix eller suffix; anpassade objekt och fält slutar på __c; ett hanterat paket lägger till sitt namnrymdsprefix (abc__); och ett fält du lägger till på ett pakets objekt får __c men aldrig leverantörens prefix. (Prefix och suffix)
• Jag kan tillämpa testet för ren passform på ett standardobjekt, och jag vet när betydelse eller tyngd pekar mot ett anpassat objekt. (Testet för ren passform)
• Jag vet vad tillgång (Asset) och personkonton är till för, att ett personkonto tar ungefär dubbelt så mycket lagring som ett företagskonto, och att personkonton inte kan stängas av när de väl har slagits på. (Tillgång är ett bra exempel, Personkonton, När är personen kontot?)
• Jag väljer en fälttyp efter det beteende jag behöver (ett fordonsnummer är inget Number), och jag vet att datum/tid lagras i GMT och visas i varje läsares tidszon, så det jämförs med intervall, inte likhet. (Ett nummer är inte alltid ett tal, Date, Date/Time och Time)
• Jag vet att text finns i två sorter: upp till 255 tecken på posten (kan indexeras, kan användas som unik eller som External ID), och Long eller Rich text över det, utan index, utan filtrering med WHERE och utan formler. (Textfamiljen)
• Jag vet när jag ska använda ett auto number-namn, och att det inte är postens ID. (Behöver en människa identifiera den?)
• Jag vet hur ett External ID låter en integration göra upsert, och ladda barn via förälderns External ID. (External ID)
• Jag vet när ett värde ska härledas med en formel, och när det är ett historiskt faktum som måste lagras. (Lagrat eller härlett?)
• Jag vet skillnaden mellan ett logiskt kopplingsobjekt (modelleringsidén: ett objekt som förenar två andra i en många-till-många-relation, med egna attribut) och ett kopplingsobjekt i Salesforce (Salesforce Junction Object) (ett anpassat objekt med två master-detail-relationer), och att Salesforce menar det senare. (Två föräldrar brett)
• Jag känner till den hierarkiska relationen: en särskild lookup som bara finns på User-objektet, som standardfältet Manager, som inte kan peka tillbaka på samma användare direkt eller indirekt, och som inte är rollhierarkin. (Hierarkisk)
• Jag vet skillnaden mellan lookup och master-detail: ägarskap, delning, obligatorisk förälder, kaskadradering, sammanställningsfält. (Lookup, Master-detail)
• Jag vet att master-detail inte kan skapas på ett objekt som redan har data (skapa en lookup, fyll den, konvertera), bara kan göras om till lookup när mastern saknar roll-ups, och behöver Allow reparenting för att ett barn ska kunna flyttas. (Kan barnet byta förälder?)
• Jag känner till plattformens form för master-detail: upp till tre anpassade detaljnivåer djupt (en lookup kan bryta kedjan var som helst), och två master-detail-föräldrar brett. I ett kopplingsobjekt i Salesforce är den master-detail som skapades först den primära (ägare, utseende, division), den andra är sekundär, och åtkomst kräver båda föräldrarna: den mest restriktiva vinner. (Tre nivåer djupt, Två föräldrar brett)
• Jag känner till en lookups tre val när föräldern raderas: töm fältet (standard), blockera raderingen, eller kaskadradera, vilket är avslaget tills Salesforce slår på det och går förbi delningen. (Lookup)
• Jag vet att en självrelation måste vara en lookup, och de två som är inbyggda: kontots Parent Account och ärendets Parent Case. (Självrelationer)
• Jag vet att omräkning av roll-ups kan ta tid, att en roll-up inte kan använda en formel med NOW(), TODAY() eller en referens till ett annat objekt, och att jag inte ska välja master-detail bara för att få en roll-up: ett lagrat fält som hålls aktuellt av ett flöde eller en trigger är alternativet. (Roll-ups är användbara, men de är inte gratis)
• Jag känner till relationsgränserna som modulen hänvisar till: två master-detail per objekt; 40 relationsfält som standard (högst 50); 25 roll-ups som standard (högst 40). (Relationer har också gränser)

DM-2: en modell som respekterar delning och skalar

• Jag vet att ett barn i en master-detail saknar egen ägare och egen delningstabell: åtkomsten följer mastern. (Ägarskapet följer med på köpet)
• Jag känner till parent-child skew: Salesforce riktlinje är högst ungefär 10 000 barn på en förälder. (Frågan om 10 000 barn)
• Jag känner till ownership skew (en användare som äger fler än 10 000 poster av ett objekt) och riktlinjen: sprid ägarskapet, eller håll den användaren utanför rollhierarkin eller ensam högst upp, och utanför publika grupper som delningsregler använder. (Ägarskap kan bli ett skalproblem)
• Jag känner till delningstabellen: ett anpassat objekts delningsobjekt är Object__Share; ett detaljobjekt har inget, dess åtkomst kommer från mastern; och ett ägarbyte tar bort manuella delningar men behåller Apex-delning med en egen orsak. (Delningstabellen)
• Jag kan bestämma vem som äger poster som integrationer och agenter skapar, utifrån om ägarskapet styr delningen. (Vem äger poster som system skapar?)

DM-4: big objects jämfört med standardobjekt och anpassade objekt

• Jag känner till de tre hemmen för data: på core (sObjects, i dagligt arbete), refererade (ett annat system är sanningskällan: externa objekt via Salesforce Connect, __x, eller egna anrop) och arkiverade (på core i big objects, __b, eller utanför core i ett datalager). (På core och utanför core)
• Jag vet att externa objekt gör ett anrop varje gång de används, så latensen och källsystemets tillgänglighet spelar roll. (Refererade)
• Jag känner till big objects: enorma volymer, frågas via sitt index med exakt matchning eller intervall, inget standardgränssnitt eller rapportering, bara objekt- och fältbehörigheter, ingen automatisering. (Arkiverade)
• Jag vet att de flesta poster räknas som ungefär 2 kB datalagring oavsett antal fält, och att filer mäts separat i fillagringen. (Två kolumner eller tvåhundra, Filer och bilagor)

SDM-1: licenser och objekten folk kan använda

• Jag känner till de tre interna licenserna, Sales Cloud, Service Cloud och Platform, och vad var och en kan använda. (Tre interna licenser)
• Jag vet att licenser är en del av datamodellen: användare med Salesforce Platform får inte leads, kampanjer, affärsmöjligheter eller prognoser, och användare med Customer Community kan inte använda affärsmöjligheter. (Nu ska jag krångla till allt: licenser)
• Jag känner till nivåerna för externa licenser: Customer Community, Customer Community Plus (rapporter, instrumentpaneler, standarddelning), Partner Community (säljobjekt); och att Partner Community inte kan användas med personkonton. (Arenan)
• Jag känner till medlemsbaserad och inloggningsbaserad licensiering, och vilken population var och en passar. (Hur de betalar ändrar designen)
• Jag vet att vissa plattformslicenser begränsar användare till en app med upp till tio anpassade objekt, och mönstret med posttyper för att arbeta inom den gränsen. (När licensen formar modellen)
• Jag vet att licensen Salesforce Integration är till för användare som bara arbetar system till system, via API. (Människor är inte de enda användarna längre)
• Jag vet att SLA-rapportering kräver berättiganden och milstolpar (entitlements and milestones), som kräver Service-licenser. (Nu ska jag krångla till allt: licenser)

SDM-2: hålla data konsistenta

• Jag kan placera en regel på rätt steg i konsistensstegen: fälttyp och vokabulär, Required och Unique, valideringsregler, dubblettregler, automatisering. (Håll data konsistenta)
• Jag vet att en begränsad plocklista avvisar värden som inte står på listan, även via API:t, och att en global värdeuppsättning delar en lista mellan flera fält (upp till 1 000 värden). (Steg ett)
• Jag vet att ett krav i sidlayouten bara skyddar den skärmen, inte data, och att valideringsregler körs vid varje sparning. (Validering i gränssnittet är inte datavalidering, Steg tre)
• Jag kan avgränsa en valideringsregel med ISNEW() och ISCHANGED(), en anpassad behörighet eller ett go live-datum, och vet vilka sparningar (även sådana jag inte styr, som ett ägarbyte i batch eller en roll-up) som varje val fortfarande kontrollerar. (Problemet med gamla poster)
• Jag känner till matchningsregler och dubblettregler, gränserna som modulen hänvisar till (fem aktiva dubblettregler per objekt, tre matchningsregler vardera), och att de inte löser identitet mellan system. (Steg fyra: dubblettregler)
• Jag vet att dubblettregler inte jämför poster som sparas i samma ögonblick, att sparningar via API och import blockeras utan avisering, och att en sparning och allt den sätter igång rullas tillbaka som en enda transaktion. (Steg fyra, Allt eller inget)
• Jag vet att Workflow Rules och Process Builder inte längre har support; automatisering betyder Flow eller Apex. (Steg fem: automatisering)

Bortom provet

Provet är golvet, inte taket. Det här är vanorna från kapitlet som en arkitekt behöver, oavsett om en fråga någonsin tar upp dem.

• Plattformen har en form. Designa för plattformen du står på, inte för en generisk databas.
• Titta på moderskeppet. Se hur Salesforce modellerar ett begrepp innan du hittar på ett eget.
• Varje objekt är ett åtagande: lagring, gränser, en delningsmodell, licenser och beroenden.
• Fråga var data bor innan du väljer ett objekt: på core, refererade eller arkiverade.
• Läs ett API-namn så vet du vem som skapade det, och vad du kan ändra.
• Om du inte arkiverar i dag, kommer du någonsin att arkivera?
• Gör en prototyp av big objects innan du föreslår dem.
• Olika affärsnamn betyder inte automatiskt olika objekt.
• Fråga vilka identiteter som behöver data: människor, kunder, partner, integrationer och agenter.
• Varje fält får en beskrivning, och klassificering där det spelar roll.
• Beskriv relationens beteende först; konfigurationen implementerar det. Förvräng inte modellen för att få en funktion.
• Raderingsfrågan: vad ska hända med barnen om någon raderar föräldern?
• Välj vilken länk som bryter kedjan: gör lookupen där barnet verkligen har ett eget liv.
• Ägarskap från den primära, åtkomst från båda: den mest restriktiva vinner.
• Skilj på inaktivt och borta, och gör lagringstiden till en affärsregel.
• Tryck ned regeln så lågt som den korrekt hör hemma, och ge legitim historik ett undantag i stället för att skriva om den.
• Diagrammet är inte arkitekturen. Kunna spåra varje struktur tillbaka till ett affärsskäl.

Ord att kunna

Term	På en rad
Metadatadriven	Objekt och fält är definitioner som plattformen läser vid körning, inte nya fysiska tabeller
Multitenancy (flera hyresgäster)	Många orgar delar infrastrukturen, var och en isolerad, som lägenheter i ett och samma hus
Governor limits	Gränser som hindrar en hyresgäst från att lägga beslag på delade resurser
Externt objekt	Data som visas i Salesforce via Salesforce Connect, hämtade från källan varje gång de används
Big object	Lagring för mycket stora, sällan använda data, som frågas via sitt index
Personkonto	En privatperson representerad som ett konto, för modeller där företaget säljer till konsumenter
Ren passform	Ett affärsbegrepp som stämmer med ett standardobjekts avsedda syfte
External ID	Ett fält som håller ett annat systems identifierare, används för upsert och matchning
Upsert	Uppdatera posten om den finns, skapa den om den inte finns
Lookup	En relation där barnet behåller sin egen ägare och sitt eget liv
Master-detail	En relation där barnet tillhör föräldern: ärvd ägare och delning, kaskadradering, roll-ups
Logiskt kopplingsobjekt	Modelleringsidén: ett objekt som förenar två andra i en många-till-många-relation och har egna attribut, hur det än byggs
Kopplingsobjekt i Salesforce (Salesforce Junction Object)	Det Salesforce menar med ”junction object”: ett anpassat objekt med två master-detail-relationer
Primär och sekundär master	Den master-detail som skapades först i ett kopplingsobjekt i Salesforce (ägare, utseende, division) och den andra (rapportomfång; blir primär om den första tas bort)
Hierarkisk relation	En särskild lookup som bara finns på User-objektet, som Manager, som inte kan peka tillbaka på samma användare
Namnrymdsprefix	Leverantörens prefix på ett hanterat pakets objekt och fält, som abc__Inspection__c
Delningstabell	Delningsobjektet (AccountShare, Truck__Share) som håller det mesta av en posts delning, en rad per användare eller grupp, med sin orsak
Sammanställningsfält (roll-up summary)	Ett fält på mastern som räknar, summerar eller hittar minimum eller maximum bland detaljerna
Data skew	För många poster under en förälder eller en ägare, vilket orsakar lås och långa omräkningar av delningen
Medlemsbaserad / inloggningsbaserad	Betala per extern användare, eller per inloggning varje månad
Konsistensstegen	Lagren som upprätthåller dataregler, från fälttyp upp till automatisering
Begränsad plocklista	En plocklista som avvisar alla värden som inte står på listan, oavsett källa
Dataklassificering	Fältmetadata för ägare, användning, känslighet och efterlevnadskategori

Testa dig själv

Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.

1. Användarna behöver se orderuppgifter som ERP:t äger och uppdaterar hela dagen. De redigerar dem inte i Salesforce. Kopiera in dem eller inte?

Referera dem: externa objekt via Salesforce Connect behåller ERP:t som sanningskälla, utan någon kopia att synkronisera. Acceptera att varje visning gör ett anrop, så latensen och ERP:ts tillgänglighet spelar roll, och att det passar läsåtkomst bättre än tung redigering eller rapportering. Läs om Refererade.

2. Verksamheten vill följa distributörer, leverantörer och detaljhandelspartner. Tre anpassade objekt?

Nej. Alla är företag, så konto (Account) är en ren passform; de olika namnen är roller, som bärs av en typ, en posttyp eller en relation. Läs om Testet för ren passform.

3. En design använder affärsmöjlighet (Opportunity), men de flesta som behöver data har licenser för Salesforce Platform eller Customer Community. Vad nu?

De licenserna kan inte använda affärsmöjligheter, så licensen är en arkitektonisk begränsning: köp andra licenser, flytta upplevelsen eller designa om, oftast mot ett anpassat objekt. Läs om Nu ska jag krångla till allt: licenser.

4. ERP:t skickar uppdateringar av konton varje natt. Hur ska integrationen hitta rätt post utan att fråga efter Salesforce-ID:n?

Spara ERP:ts kundnummer i ett External ID-fält och gör upsert på det: uppdatera om posten finns, skapa den om inte. Barnposter kan också peka på sin förälder via dess External ID. Läs om External ID.

5. En leveransrad kan inte finnas utan sin leverans, flyttas aldrig och behöver ingen egen ägare. En leverans finns innan den får en rutt och kan flyttas till en annan rutt. Vilken relation för var och en?

Leveransrad till leverans: master-detail (den tillhör föräldern hela livet, ärver åtkomsten, kaskadraderas). Leverans till rutt: en lookup (eget liv, valfri i början, flyttbar, och att radera en rutt får aldrig radera leveranser). Läs om Börja med affärsrelationen.

6. En integration skapar 3 300 leveranser om dagen, alla ägda av integrationsanvändaren, som har en roll mitt i hierarkin. Vad är risken, och lösningen?

Ownership skew: förbi 10 000 poster utlöser det långa omräkningar av delningen att flytta den användaren eller ändra dess grupper. Sprid ägarskapet om det spelar roll för åtkomsten; håll annars integrationsanvändaren utanför rollhierarkin, eller ensam i en roll högst upp, och utanför grupper som delningsregler använder. Läs om Ägarskap kan bli ett skalproblem.

7. Du lägger till en valideringsregel, och 20 000 gamla poster bryter mot den. En användare ändrar ett telefonnummer på en av dem och sparningen misslyckas. Vad borde regeln ha gjort?

Sagt när den ska gälla, inte bara vad som måste vara sant: avgränsa den med ISNEW() eller ISCHANGED() på de relevanta fälten, och ge poster som är äldre än regeln ett medvetet undantag i stället för att skriva om deras historia. Läs om Problemet med gamla poster.

8. Verksamheten vill ha varje leveransfoto ”i Salesforce”: fyra till fem miljoner om året, med en tillväxt på 30 procent. Vad föreslår du?

Skilj åtkomst från lagring. Ha filerna i lagring byggd för den volymen, utanför core-orgen, och spara en referens, ett antal eller en indexpost i Salesforce så att användarna kan hitta och se dem. Läs om Foton.

9. En teamtilldelning (Crew Assignment) har master-detail-relationer till team (skapad först) och lastbil. En trafikledare kan se teamet men inte lastbilen. Kan trafikledaren se teamtilldelningen?

Nej. Teamet är den primära, så det ger tilldelningen dess ägare och utseende, men åtkomst kräver båda föräldrarna: trafikledaren behöver åtkomst till teamet och lastbilen, på den nivå som varje master-detail-fälts Sharing Setting kräver. Den mest restriktiva vinner. Läs om Två föräldrar brett.

10. En partner skickar om en manifestfil, och samma kund finns två gånger i den. Du har en dubblettregel på konto som är inställd på att blockera. Är du säker?

Inte bara tack vare dubblettregeln. Poster som sparas i samma ögonblick jämförs inte med varandra, bara med poster som redan finns i Salesforce, så båda raderna kan slinka igenom. Tryck ned unikheten till fältet: ett unikt External ID, som plattformen kontrollerar vid varje sparning, så att bara en vinner. Läs om Steg fyra: dubblettregler och Allt eller inget.

Utforska vidare

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-09-25): den officiella listan över mål och deras vikter. Kontrollera alltid den aktuella versionen innan du bokar provet.
• Varje moduls eget avsnitt Utforska vidare listar Salesforce-dokumentationen bakom dess plattformsfakta, med datumet då den kontrollerades.