Dataarkitektur i Salesforce

🌐 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)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Studieguide for kapittel 3 i kurset Data Architect. Les de ti modulene først; denne siden hjelper deg å sjekke hva som satt seg.

Om denne studieguiden. Den bygger bare på kursets eget innhold og listen over mål i Salesforces publiserte eksamensguide. Den bygger aldri på ekte eksamensspørsmål, og den påstår ikke å vite hva som kommer på eksamen. Hvis du har tatt eksamen, ikke send meg spørsmål fra den: sertifiseringsavtalen forbyr å dele dem, og å pugge svar er uansett feil måte å bli arkitekt på.

Dette er kapitlet der modellen møter plattformen, og det bærer mye av eksamen. Det mater begge de største delene, Data Modeling and Database Design (datamodellering og databasedesign) og Salesforce Data Management (datahåndtering i Salesforce), som er en fjerdedel av eksamen hver. Plattformens tall endrer seg: sjekklisten gir tallene modulene viser til, med datoen de ble kontrollert. Lær hva hver grense er til for, og sjekk gjeldende tall før du stoler på det.

Til eksamen

Kryss av etter hvert. Hvert punkt lenker til der det undervises.

DM-1: å designe datamodellen på plattformen

• Jeg vet at Salesforce er en metadatadrevet plattform med flere leietakere (multitenant): et objekt er metadata, ikke en ny tabell, og hvert objekt får API-ene sine i det øyeblikket det finnes. (Metadata er tegningen, API-et fulgte med objektet)
• Jeg vet at governor limits (plattformens grenser) finnes for at én leietaker ikke skal kunne legge beslag på delte ressurser. (Du kan ikke legge beslag på heisen)
• Jeg kan lese standarddatamodellene: konvertering av kundeemne (Lead) til konto, kontakt og salgsmulighet (Opportunity); et salgsmulighetsprodukt (Opportunity Product) peker på en prislisteoppføring (Price Book Entry), som peker på Product2; og sak (Case), aktivum (Asset) og rettighet (Entitlement) på servicesiden. (Salgsmodellen, Servicemodellen)
• Jeg vet hva skjermen New Custom Object bestemmer: et postnavn av typen Text eller Auto Number; Object Classification (med deling, Bulk API og Streaming API slått på er det et Enterprise Application-objekt, med dem slått av et Light Application-objekt); og Allow Search, som er av som standard. (Skjermen New Custom Object)
• Jeg kan lese et API-navn: standardobjekter og standardfelt har verken prefiks eller suffiks; egendefinerte objekter og felt slutter på __c; en administrert pakke legger til navneromsprefikset sitt (abc__); og et felt du legger til på et objekt fra en pakke, får __c, men aldri leverandørens prefiks. (Prefikser og suffikser)
• Jeg kan bruke testen for ren passform på et standardobjekt, og jeg vet når mening eller tyngde peker mot et egendefinert objekt. (Testen for ren passform)
• Jeg vet hva aktivum og personkontoer er til for, at en personkonto tar omtrent dobbelt så mye lagring som en bedriftskonto, og at personkontoer ikke kan slås av når de først er slått på. (Aktivum er et godt eksempel, Personkontoer, Når er personen kontoen?)
• Jeg velger en felttype for atferden jeg trenger (et flåtenummer er ikke et Number), og jeg vet at dato/tid lagres i GMT og vises i hver lesers tidssone, så det sammenlignes med intervaller, ikke likhet. (Et tall er ikke alltid et tall, Dato, dato/tid og klokkeslett)
• Jeg vet at tekst finnes i to slag: opptil 255 tegn på posten (kan indekseres og brukes som unik eller som External ID), og Long eller Rich text over det, uten indeks, uten filtrering i WHERE og uten formler. (Tekstfamilien)
• Jeg vet når et Name-felt med auto number skal brukes, og at det ikke er postens ID. (Må et menneske kunne kjenne den igjen?)
• Jeg vet hvordan en External ID lar en integrasjon gjøre upsert, og laste inn barn med forelderens External ID. (External ID)
• Jeg vet når en verdi bør avledes med en formel, og når den er et historisk faktum som må lagres. (Lagret eller avledet?)
• Jeg kjenner forskjellen på et logisk koblingsobjekt (modelleringsideen: et objekt som kobler to andre i en mange-til-mange-relasjon, med egne attributter) og et koblingsobjekt i Salesforce (Salesforce Junction Object) (et egendefinert objekt med to master-detail-relasjoner), og at Salesforce mener det siste. (To foreldre bredt)
• Jeg kjenner den hierarkiske relasjonen: en spesiell lookup bare på User-objektet, som standardfeltet Manager, som ikke kan gå i ring tilbake til samme bruker direkte eller indirekte, og som ikke er rollehierarkiet. (Hierarkisk)
• Jeg kjenner forskjellen på en lookup og master-detail: eierskap, deling, obligatorisk forelder, kaskadesletting, sammendragsfelt. (Lookup, Master-detail)
• Jeg vet at master-detail ikke kan opprettes på et objekt som allerede har data (lag en lookup, fyll den, konverter), bare kan gå tilbake til en lookup når det ikke finnes sammendragsfelt på master, og trenger Allow reparenting for å flytte et barn. (Kan barnet bytte forelder?)
• Jeg kjenner plattformens form for master-detail: opptil tre egendefinerte detaljnivåer dypt (en lookup kan bryte kjeden hvor som helst), og to master-detail-foreldre bredt. I et koblingsobjekt i Salesforce er den master-detail-relasjonen som ble opprettet først, den primære (eier, utseende, divisjon), den andre er sekundær, og tilgang krever begge foreldrene: den mest restriktive vinner. (Tre nivåer dypt, To foreldre bredt)
• Jeg kjenner de tre valgene en lookup har når forelderen slettes: tøm feltet (standard), blokker slettingen, eller kaskadesletting, som er av til Salesforce slår den på, og som går forbi delingen. (Lookup)
• Jeg vet at en selvrelasjon må være en lookup, og de to som er innebygd: kontoens Parent Account og sakens Parent Case. (Selvrelasjoner)
• Jeg vet at omberegning av sammendragsfelt kan ta tid, at et sammendragsfelt ikke kan bruke en formel med NOW(), TODAY() eller en referanse på tvers av objekter, og at jeg ikke skal velge master-detail bare for å få et sammendragsfelt: et lagret felt som holdes oppdatert av en flow eller trigger, er alternativet. (Sammendragsfelt er nyttige, men de er ikke gratis)
• Jeg kjenner relasjonsgrensene modulen viser til: to master-detail-relasjoner per objekt; 40 relasjonsfelt som standard (høyst 50); 25 sammendragsfelt som standard (høyst 40). (Relasjoner har også grenser)

DM-2: en modell som respekterer deling og skalerer

• Jeg vet at et barn i en master-detail-relasjon ikke har egen eier og ingen egen delingstabell: tilgangen følger master. (Eierskapet følger med på lasset)
• Jeg kjenner parent-child skew: Salesforces veiledning er ikke mer enn rundt 10 000 barn på én forelder. (Spørsmålet om 10 000 barn)
• Jeg kjenner ownership skew (én bruker som eier mer enn 10 000 poster av et objekt) og veiledningen: spre eierskapet, eller hold den brukeren utenfor rollehierarkiet eller alene på toppen, og utenfor offentlige grupper som brukes av delingsregler. (Eierskap kan bli et skalaproblem)
• Jeg kjenner delingstabellen: delingsobjektet til et egendefinert objekt er Object__Share; et detaljobjekt har ingen, tilgangen kommer fra master; og et eierbytte fjerner manuelle delinger, men beholder Apex-deling med egen begrunnelse. (Delingstabellen)
• Jeg kan bestemme hvem som eier poster som integrasjoner og agenter lager, ut fra om eierskap styrer delingen. (Hvem eier poster som systemer lager?)

DM-4: big objects mot standardobjekter og egendefinerte objekter

• Jeg kjenner de tre hjemmene for data: på core (sObjects, i daglig bruk), referert (et annet system er sannhetskilden: eksterne objekter gjennom Salesforce Connect, __x, eller egendefinerte kall) og arkivert (på core i big objects, __b, eller utenfor core i et datavarehus). (På core og utenfor core)
• Jeg vet at eksterne objekter gjør et kall ut hver gang de berøres, så forsinkelse og kildesystemets tilgjengelighet betyr noe. (Referert)
• Jeg kjenner big objects: enorme volumer, spørres gjennom indeksen med eksakt treff eller intervall, ikke noe standard brukergrensesnitt eller rapportering, bare objekt- og felttillatelser, ingen automatisering. (Arkivert)
• Jeg vet at de fleste poster teller som rundt 2 kB datalagring uansett antall felt, og at filer måles for seg i fillagringen. (To kolonner eller to hundre, Filer og vedlegg)

SDM-1: lisenser og objektene folk kan bruke

• Jeg kjenner de tre interne lisensene, Sales Cloud, Service Cloud og Platform, og hva hver av dem kan bruke. (Tre interne lisenser)
• Jeg vet at lisenser er en del av datamodellen: brukere med Salesforce Platform får ikke kundeemner, kampanjer, salgsmuligheter eller prognoser (Forecasts), og brukere med Customer Community kan ikke bruke salgsmulighet. (Nå skal jeg gjøre alt mer komplisert: lisenser)
• Jeg kjenner nivåene av eksterne lisenser: Customer Community, Customer Community Plus (rapporter, dashbord, standard deling), Partner Community (salgsobjekter); og at Partner Community ikke kan brukes med personkontoer. (Stadionet)
• Jeg kjenner medlemsbaserte og innloggingsbaserte lisenser, og hvilken brukergruppe hver av dem passer for. (Hvordan de betaler, endrer designet)
• Jeg vet at noen plattformlisenser begrenser brukerne til én app med opptil ti egendefinerte objekter, og mønsteret med posttyper for å jobbe innenfor det. (Når lisensen former modellen)
• Jeg vet at lisensen Salesforce Integration er for brukere fra system til system, med bare API-tilgang. (Mennesker er ikke de eneste brukerne lenger)
• Jeg vet at SLA-rapportering trenger rettigheter og milepæler (entitlements and milestones), som krever Service-lisenser. (Nå skal jeg gjøre alt mer komplisert: lisenser)

SDM-2: å holde data konsistente

• Jeg kan plassere en regel på riktig trinn i konsistensstigen: felttype og vokabular, Required og Unique, valideringsregler, duplikatregler, automatisering. (Hold data konsistente)
• Jeg vet at en begrenset plukkliste avviser verdier som ikke står på listen, også gjennom API-et, og at et globalt verdisett deler én liste mellom flere felt (opptil 1 000 verdier). (Trinn én)
• Jeg vet at et krav i sideoppsettet bare beskytter den skjermen, ikke dataene, og at valideringsregler kjører ved hver lagring. (Validering i brukergrensesnittet er ikke datavalidering, Trinn tre)
• Jeg kan avgrense en valideringsregel med ISNEW() og ISCHANGED(), en egendefinert tillatelse eller en dato for go-live, og vet hvilke lagringer (også dem jeg ikke styrer, som et eierbytte i en batch eller et sammendragsfelt) hvert valg fortsatt sjekker. (Problemet med gamle poster)
• Jeg kjenner samsvarsregler og duplikatregler, grensene modulen viser til (fem aktive duplikatregler per objekt, tre samsvarsregler i hver), og at de ikke løser identitet på tvers av systemer. (Trinn fire: duplikatregler)
• Jeg vet at duplikatregler ikke sammenligner poster som lagres i samme øyeblikk, at lagringer fra API og import blokkeres uten varsel, og at en lagring og alt den setter i gang, rulles tilbake som én transaksjon. (Trinn fire, Alt eller ingenting)
• Jeg vet at Workflow Rules og Process Builder ikke lenger har støtte; automatisering betyr Flow eller Apex. (Trinn fem: automatisering)

Utover eksamen

Eksamen er gulvet, ikke taket. Dette er vanene fra dette kapitlet som en arkitekt trenger, enten et spørsmål noen gang spør om dem eller ikke.

• Plattformen har en form. Design for plattformen du står på, ikke for en generisk database.
• Se til moderskipet. Se hvordan Salesforce modellerer et begrep før du finner opp ditt eget.
• Hvert objekt er en forpliktelse: lagring, grenser, en delingsmodell, lisenser og avhengigheter.
• Spør hvor dataene bor før du velger et objekt: på core, referert eller arkivert.
• Les et hvilket som helst API-navn, så vet du hvem som laget det, og hva du kan endre.
• Hvis du ikke arkiverer i dag, kommer du noen gang til å arkivere?
• Lag en prototyp av big objects før du foreslår dem.
• Forskjellige forretningsnavn betyr ikke automatisk forskjellige objekter.
• Spør hvilke identiteter som trenger dataene: mennesker, kunder, partnere, integrasjoner og agenter.
• Hvert felt får en beskrivelse, og klassifisering der det betyr noe.
• Beskriv relasjonens atferd først; konfigurasjonen implementerer den. Ikke forvreng modellen for å få en funksjon.
• Slettespørsmålet: hva skal skje med barna hvis noen sletter forelderen?
• Velg hvilken lenke som bryter kjeden: lag lookup-relasjonen der barnet virkelig har sitt eget liv.
• Eierskap fra den primære, tilgang fra begge: den mest restriktive vinner.
• Skill inaktiv fra borte, og gjør oppbevaring til en forretningsregel.
• Skyv regelen så langt ned som den med rette hører hjemme, og gi legitim historikk et unntak i stedet for å skrive den om.
• Diagrammet er ikke arkitekturen. Du skal kunne spore hver struktur tilbake til en forretningsgrunn.

Ord du bør kunne

Begrep	På én linje
Metadatadrevet	Objekter og felt er definisjoner plattformen leser under kjøring, ikke nye fysiske tabeller
Multitenancy (flere leietakere)	Mange orger deler infrastrukturen, hver isolert, som leiligheter i én bygård
Governor limits	Grenser som hindrer én leietaker i å legge beslag på delte ressurser
Eksternt objekt	Data som vises i Salesforce gjennom Salesforce Connect, hentet fra kilden hver gang de berøres
Big object	Lagring for svært store data som sjelden brukes, spurt gjennom indeksen
Personkonto	En enkeltperson representert som en konto, for modeller fra bedrift til forbruker
Ren passform	Et forretningsbegrep som stemmer med det et standardobjekt er ment for
External ID	Et felt som holder et annet systems identifikator, brukt til upsert og matching
Upsert	Oppdater posten hvis den finnes, opprett den hvis den ikke gjør det
Lookup	En relasjon der barnet beholder sin egen eier og sitt eget liv
Master-detail	En relasjon der barnet tilhører forelderen: arvet eier og deling, kaskadesletting, sammendragsfelt
Logisk koblingsobjekt	Modelleringsideen: et objekt som kobler to andre i en mange-til-mange-relasjon og har egne attributter, uansett hvordan det er bygget
Koblingsobjekt i Salesforce (Salesforce Junction Object)	Det Salesforce mener med «junction object»: et egendefinert objekt med to master-detail-relasjoner
Primær og sekundær master	Den master-detail-relasjonen i et koblingsobjekt i Salesforce som ble opprettet først (eier, utseende, divisjon), og den andre (rapportomfang; blir primær hvis den første fjernes)
Hierarkisk relasjon	En spesiell lookup bare på User-objektet, som Manager, som ikke kan gå i ring tilbake til samme bruker
Navneromsprefiks	Leverandørens prefiks på objektene og feltene i en administrert pakke, som abc__Inspection__c
Delingstabell	Delingsobjektet (AccountShare, Truck__Share) som holder det meste av en posts deling, én rad per bruker eller gruppe, med begrunnelsen
Sammendragsfelt (roll-up summary)	Et felt på master som teller, summerer eller finner minimum eller maksimum av detaljene
Data skew	For mange poster under én forelder eller én eier, som gir låser og lange omberegninger av deling
Medlemsbasert / innloggingsbasert	Betaling per ekstern bruker, eller per innlogging hver måned
Konsistensstigen	Lagene som håndhever dataregler, fra felttype opp til automatisering
Begrenset plukkliste	En plukkliste som avviser enhver verdi som ikke står på listen, fra hvilken som helst kilde
Dataklassifisering	Feltmetadata for eier, bruk, sensitivitet og compliance-kategori

Test deg selv

Korte scenarioer i kursets stil. Bestem deg for svaret før du åpner det.

1. Brukerne må se ordredetaljer som ERP-et eier og oppdaterer hele dagen. De redigerer dem ikke i Salesforce. Kopiere dem inn, eller ikke?

Referer til dem: eksterne objekter gjennom Salesforce Connect holder ERP-et som sannhetskilde, uten noen kopi å synkronisere. Godta at hver visning gjør et kall ut, så forsinkelse og ERP-ets tilgjengelighet betyr noe, og at det passer bedre til lesetilgang enn til tung redigering eller rapportering. Les Referert på nytt.

2. Virksomheten vil holde oversikt over distributører, leverandører og detaljhandelspartnere. Tre egendefinerte objekter?

Nei. Alle er selskaper, så konto (Account) er en ren passform; de forskjellige navnene er roller, båret av en type, en posttype eller en relasjon. Les Testen for ren passform på nytt.

3. Et design bruker salgsmulighet (Opportunity), men de fleste som trenger dataene, har lisensen Salesforce Platform eller Customer Community. Hva nå?

De lisensene kan ikke bruke salgsmulighet, så lisensen er en arkitektonisk begrensning: kjøp andre lisenser, flytt opplevelsen, eller design på nytt, vanligvis mot et egendefinert objekt. Les Nå skal jeg gjøre alt mer komplisert: lisenser på nytt.

4. ERP-et sender nattlige oppdateringer av kontoer. Hvordan skal integrasjonen finne riktig post uten å spørre etter Salesforce-ID-er?

Lagre ERP-ets kundenummer i et External ID-felt og gjør upsert på det: oppdater hvis den finnes, opprett hvis ikke. Barneposter kan også peke på forelderen med forelderens External ID. Les External ID på nytt.

5. En leveringslinje kan ikke finnes uten leveringen sin, flyttes aldri og trenger ingen egen eier. En levering finnes før den får en rute og kan flyttes til en annen rute. Hvilken relasjon for hver?

Leveringslinje til levering: master-detail (den tilhører forelderen hele livet, arver tilgang, slettes i kaskade). Levering til rute: en lookup (eget liv, valgfri til å begynne med, kan flyttes, og å slette en rute må aldri slette leveringer). Les Begynn med forretningsrelasjonen på nytt.

6. En integrasjon lager 3 300 leveringer om dagen, alle eid av integrasjonsbrukeren, som har en rolle midt i hierarkiet. Hva er risikoen, og hva er løsningen?

Ownership skew: forbi 10 000 poster utløser det lange omberegninger av deling å flytte den brukeren eller endre gruppene dens. Spre eierskapet hvis det betyr noe for tilgang; ellers hold integrasjonsbrukeren utenfor rollehierarkiet, eller alene i en rolle på toppen, og utenfor grupper som brukes av delingsregler. Les Eierskap kan bli et skalaproblem på nytt.

7. Du legger til en valideringsregel, og 20 000 gamle poster bryter den. En bruker endrer et telefonnummer på én av dem, og lagringen feiler. Hva burde regelen ha gjort?

Sagt når den skal håndheves, ikke bare hva som må være sant: avgrens den med ISNEW() eller ISCHANGED() på de relevante feltene, og gi poster som er eldre enn regelen, et bevisst unntak i stedet for å skrive om historikken deres. Les Problemet med gamle poster på nytt.

8. Virksomheten vil ha hvert leveringsbilde «i Salesforce»: fire til fem millioner i året, med 30 % vekst. Hva foreslår du?

Skill tilgang fra lagring. Hold filene i lagring bygget for det volumet, utenfor core-orgen, og hold en referanse, et antall eller en indekspost i Salesforce, så brukerne kan finne og se dem. Les Bilder på nytt.

9. En teamtildeling (Crew Assignment) har master-detail-relasjoner til team (Crew, opprettet først) og lastebil (Truck). En koordinator kan se teamet, men ikke lastebilen. Kan koordinatoren se teamtildelingen?

Nei. Team er den primære, så det gir tildelingen eier og utseende, men tilgang krever begge foreldrene: koordinatoren trenger tilgang til teamet og lastebilen, på nivået som Sharing Setting for hvert master-detail-felt krever. Den mest restriktive vinner. Les To foreldre bredt på nytt.

10. En partner sender en manifestfil på nytt, og samme kunde står to ganger i den. Du har en duplikatregel på konto satt til å blokkere. Er du trygg?

Ikke bare med duplikatregelen. Poster som lagres i samme øyeblikk, sammenlignes ikke med hverandre, bare med poster som allerede finnes i Salesforce, så begge radene kan slippe gjennom. Skyv det unike ned til feltet: en unik External ID, som plattformen sjekker ved hver lagring, så bare én vinner. Les Trinn fire: duplikatregler og Alt eller ingenting på nytt.

Les mer

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-09-25): den offisielle listen over mål og vektingen av dem. Sjekk alltid gjeldende versjon før du bestiller eksamen.
• Hver moduls egen Les mer-del lister Salesforce-dokumentasjonen bak plattformfaktaene, med datoen den ble kontrollert.