Dataarkitektur i Salesforce
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)
Studieguide til kapitel 3 i kurset Data Architect. Læs de ti moduler først; denne side hjælper dig med at tjekke, hvad der er blevet hængende.
Om denne studieguide. Den er udelukkende bygget på kursets eget indhold og listen over mål i Salesforces offentliggjorte eksamensguide. Den bygger aldrig på rigtige eksamensspørgsmål, og den påstår ikke at vide, hvad der kommer til eksamen. Hvis du har taget eksamen, så send mig venligst ikke spørgsmål fra den: certificeringsaftalen forbyder at dele dem, og at lære svar udenad er under alle omstændigheder den forkerte måde at blive arkitekt på.
Det her er kapitlet, hvor modellen møder platformen, og det bærer en stor del af eksamen. Det fodrer begge de største sektioner, Data Modeling and Database Design og Salesforce Data Management, som hver udgør en fjerdedel af eksamen. Platformens tal ændrer sig: tjeklisten angiver dem, modulerne citerer, med datoen for kontrollen. Lær, hvad hver grænse er til for, og tjek det aktuelle tal, før du stoler på det.
Til eksamen
Sektion kaldt “Til eksamen ”Sæt flueben, efterhånden som du går frem. Hvert punkt linker til det sted, hvor det bliver undervist.
DM-1: at designe datamodellen på platformen
- Jeg ved, at Salesforce er en metadatadrevet multitenant-platform: et objekt er metadata, ikke en ny tabel, og hvert objekt får sine API’er i samme øjeblik, det findes. (Metadata er tegningen, Dit API fulgte med objektet)
- Jeg ved, at governor limits findes, så én lejer ikke kan lægge beslag på de delte ressourcer. (Du kan ikke lægge beslag på elevatoren)
- Jeg kan læse standarddatamodellerne: konvertering af et kundeemne (Lead) til konto, kontakt og salgsmulighed; et Opportunity Product peger på en Price Book Entry, som peger på Product2; og sag, aktiv og Entitlement på servicesiden. (Salgsmodellen, Servicemodellen)
- Jeg ved, hvad skærmen New Custom Object beslutter: et postnavn af typen Text eller Auto Number; Object Classification (med deling, Bulk API og Streaming API slået til er det et Enterprise Application-objekt, med dem slået fra et Light Application-objekt); og Allow Search, som er slået fra som standard. (Skærmen New Custom Object)
- Jeg kan læse et API-navn: standardobjekter og -felter har hverken præfiks eller suffiks; brugerdefinerede objekter og felter ender på
__c; en administreret pakke tilføjer sit navnerumspræfiks (abc__); og et felt, du tilføjer til en pakkes objekt, får__c, men aldrig leverandørens præfiks. (Præfikser og suffikser) - Jeg kan bruge testen for rent match på et standardobjekt, og jeg ved, hvornår betydning eller vægt peger mod et brugerdefineret objekt. (Testen for rent match)
- Jeg ved, hvad aktiv (Asset) og personkonti er til, at en personkonto fylder omkring dobbelt så meget som en erhvervskonto, og at personkonti ikke kan slås fra igen, når de først er slået til. (Aktiv er et godt eksempel, Personkonti, Hvornår er personen kontoen?)
- Jeg vælger en felttype efter den adfærd, jeg har brug for (et vognnummer er ikke et Number), og jeg ved, at dato/tid gemmes i GMT og vises i hver læsers tidszone, så den sammenlignes med intervaller, ikke lighedstegn. (Et tal er ikke altid et tal, Dato, dato/tid og klokkeslæt)
- Jeg ved, at tekst findes i to slags: op til 255 tegn på posten (kan indekseres og bruges som unik eller som External ID) og Long eller Rich Text derover, uden indeks, uden filtrering i
WHEREog uden formler. (Tekstfamilien) - Jeg ved, hvornår et Auto Number-navn skal bruges, og at det ikke er postens id. (Skal et menneske kunne genkende den?)
- Jeg ved, hvordan et External ID lader en integration lave upsert og indlæse børn via deres forælders External ID. (External IDs)
- Jeg ved, hvornår en værdi skal afledes af en formel, og hvornår den er et historisk faktum, der skal gemmes. (Gemt eller afledt?)
- Jeg kender forskellen på et logisk forbindelsesobjekt (modelleringsideen: et objekt, der forbinder to andre i en mange-til-mange-relation og har sine egne attributter) og et forbindelsesobjekt i Salesforce (Salesforce Junction Object) (et brugerdefineret objekt med to master-detail-relationer), og jeg ved, at Salesforce mener det sidste. (To forældre bredt)
- Jeg kender den hierarkiske relation: et særligt lookup, der kun findes på User-objektet, som standardfeltet Manager, der ikke må pege tilbage på den samme bruger, hverken direkte eller indirekte, og som ikke er rollehierarkiet. (Hierarkisk)
- Jeg kender forskellen på en lookup-relation og en master-detail-relation: ejerskab, deling, påkrævet forælder, kaskadesletning, oversigtsfelter (roll-up summary). (Lookup, Master-detail)
- Jeg ved, at en master-detail-relation ikke kan oprettes på et objekt, der allerede har data (opret et lookup, udfyld det, konvertér), kun kan laves tilbage til et lookup, når der ikke er roll-ups på masteren, og kræver Allow reparenting for at flytte et barn. (Kan barnet skifte forælder?)
- Jeg kender platformens form for master-detail: op til tre brugerdefinerede detail-niveauer i dybden (et lookup kan bryde kæden hvor som helst) og to master-detail-forældre i bredden. I et forbindelsesobjekt i Salesforce er den master-detail, der blev oprettet først, den primære (ejer, udseende, division), den anden er sekundær, og adgang kræver begge forældre: den mest restriktive vinder. (Tre niveauer dybt, To forældre bredt)
- Jeg kender et lookups tre valg, når forælderen slettes: ryd feltet (standard), bloker sletningen eller kaskadeslet, som er slået fra, indtil Salesforce aktiverer det, og som går uden om delingen. (Lookup)
- Jeg ved, at en selvrelation skal være et lookup, og jeg kender de to indbyggede: kontoens Parent Account og sagens Parent Case. (Selvrelationer)
- Jeg ved, at genberegning af roll-ups kan tage tid, at en roll-up ikke kan bruge en formel med
NOW(),TODAY()eller en reference på tværs af objekter, og at man ikke skal vælge master-detail bare for at få en roll-up: et gemt felt, der holdes opdateret af et flow eller en trigger, er alternativet. (Roll-ups er nyttige, men de er ikke gratis) - Jeg kender de relationsgrænser, modulet citerer: to master-details pr. objekt; 40 relationsfelter som standard (højst 50); 25 roll-ups som standard (højst 40). (Relationer har også grænser)
DM-2: en model, der respekterer delingen og skalerer
- Jeg ved, at et master-detail-barn hverken har ejer eller delingstabel for sig selv: adgangen følger masteren. (Ejerskabet kører med)
- Jeg kender parent-child skew: Salesforces anbefaling er højst omkring 10.000 børn på én forælder. (Spørgsmålet om de 10.000 børn)
- Jeg kender ownership skew (én bruger, der ejer mere end 10.000 poster af et objekt) og anbefalingen: spred ejerskabet, eller hold den bruger uden for rollehierarkiet eller alene i toppen, og uden for de offentlige grupper, delingsregler bruger. (Ejerskab kan blive et skalaproblem)
- Jeg kender delingstabellen: et brugerdefineret objekts delingsobjekt er
Object__Share; et detail-objekt har ingen, dets adgang kommer fra masteren; og et ejerskifte fjerner manuelle delinger, men beholder Apex-deling med sin egen årsag. (Delingstabellen) - Jeg kan beslutte, hvem der ejer poster, som integrationer og agenter opretter, ud fra om ejerskab styrer delingen. (Hvem ejer de poster, som systemer opretter?)
DM-4: big objects over for standardobjekter og brugerdefinerede objekter
- Jeg kender de tre hjem for data: på core (sObjects, i daglig brug), refereret (et andet system er sandhedskilden: eksterne objekter via Salesforce Connect,
__x, eller brugerdefinerede kald) og arkiveret (på core i big objects,__b, eller uden for core i et datavarehus). (På core og uden for core) - Jeg ved, at eksterne objekter laver et kald ud, hver gang de bliver rørt, så latens og kildesystemets tilgængelighed betyder noget. (Refereret)
- Jeg kender big objects: enorme mængder, forespurgt via deres indeks med eksakt match eller interval, ingen standard-UI eller rapportering, kun objekt- og felttilladelser, ingen automatisering. (Arkiveret)
- Jeg ved, at de fleste poster tæller som omkring 2 kB datalagerplads uanset antal felter, og at filer måles for sig i fillagerpladsen. (To kolonner eller to hundrede, Filer og vedhæftninger)
SDM-1: licenser og de objekter, folk kan bruge
- Jeg kender de tre interne licenser, Sales Cloud, Service Cloud og Platform, og hvad hver af dem kan bruge. (Tre interne licenser)
- Jeg ved, at licenser er en del af datamodellen: Salesforce Platform-brugere får ikke Leads, Campaigns, Opportunities eller Forecasts, og Customer Community-brugere kan ikke bruge Opportunity. (Lad mig så gøre det hele mere kompliceret: licenser)
- Jeg kender de eksterne licensniveauer: Customer Community, Customer Community Plus (rapporter, dashboards, standarddeling), Partner Community (salgsobjekter); og at Partner Community ikke kan bruges med personkonti. (Stadionet)
- Jeg kender medlemsbaserede over for login-baserede licenser, og hvilken brugergruppe hver af dem passer til. (Hvordan de betaler, ændrer designet)
- Jeg ved, at nogle platformslicenser begrænser brugerne til én app med op til ti brugerdefinerede objekter, og jeg kender mønsteret med posttyper til at arbejde inden for den grænse. (Når licensen former modellen)
- Jeg ved, at licensen Salesforce Integration er til brugere, der kun bruger API’et, fra system til system. (Mennesker er ikke længere de eneste brugere)
- Jeg ved, at SLA-rapportering kræver entitlements og milestones, som kræver Service-licenser. (Lad mig så gøre det hele mere kompliceret: licenser)
SDM-2: at holde data konsistente
- Jeg kan placere en regel på det rigtige trin på konsistensstigen: felttype og ordforråd, påkrævet og unik, valideringsregler, dubletregler, automatisering. (Hold data konsistente)
- Jeg ved, at en begrænset valgliste afviser værdier, der ikke står på listen, også via API’et, og at et globalt værdisæt deler én liste på tværs af felter (op til 1.000 værdier). (Første trin)
- Jeg ved, at et påkrævet felt i sidelayoutet kun beskytter den skærm, ikke dataene, og at valideringsregler kører ved hver gemning. (Validering i brugerfladen er ikke datavalidering, Tredje trin)
- Jeg kan afgrænse en valideringsregel med ISNEW() og ISCHANGED(), en brugerdefineret tilladelse eller en go-live-dato, og jeg ved, hvilke gemninger (også dem, jeg ikke styrer, som et batchvis ejerskifte eller en roll-up) hvert valg stadig tjekker. (Problemet med de gamle poster)
- Jeg kender matchningsregler og dubletregler, de grænser, modulet citerer (fem aktive dubletregler pr. objekt, tre matchningsregler i hver), og at de ikke løser identitet på tværs af systemer. (Fjerde trin: dubletregler)
- Jeg ved, at dubletregler ikke sammenligner poster, der gemmes i samme øjeblik, at gemninger via API og import blokeres uden en advarsel, og at en gemning og alt det, den sætter i gang, rulles tilbage som én transaktion. (Fjerde trin, Alt eller intet)
- Jeg ved, at Workflow Rules og Process Builder ikke længere er understøttet; automatisering betyder Flow eller Apex. (Femte trin: automatisering)
Ud over eksamen
Sektion kaldt “Ud over eksamen ”Eksamen er gulvet, ikke loftet. Det her er de vaner fra dette kapitel, som en arkitekt har brug for, uanset om et spørgsmål nogensinde spørger til dem.
- Platformen har en form. Design til den platform, du står på, ikke til en generisk database.
- Kig på moderskibet. Se, hvordan Salesforce modellerer et begreb, før du opfinder dit eget.
- Hvert objekt er en forpligtelse: lagerplads, grænser, en delingsmodel, licenser og afhængigheder.
- Spørg, hvor dataene bor, før du vælger et objekt: på core, refereret eller arkiveret.
- Læs et hvilket som helst API-navn, og du ved, hvem der har lavet det, og hvad du kan ændre.
- Hvis du ikke arkiverer i dag, kommer du så nogensinde til at arkivere?
- Lav en prototype med big objects, før du foreslår dem.
- Forskellige forretningsnavne betyder ikke automatisk forskellige objekter.
- Spørg, hvilke identiteter der har brug for dataene: mennesker, kunder, partnere, integrationer og agenter.
- Hvert felt får en beskrivelse, og en klassifikation, hvor det betyder noget.
- Beskriv relationens adfærd først; konfigurationen implementerer den. Forvræng ikke modellen for at få en funktion.
- Spørgsmålet om sletning: hvad skal der ske med børnene, hvis nogen sletter forælderen?
- Vælg, hvilket led der bryder kæden: lav lookup’et der, hvor barnet virkelig har sit eget liv.
- Ejerskab fra den primære, adgang fra begge: den mest restriktive vinder.
- Skeln mellem inaktiv og væk, og gør opbevaring til en forretningsregel.
- Skub reglen så langt ned, som den med rette hører hjemme, og giv legitim historik en undtagelse i stedet for at omskrive den.
- Diagrammet er ikke arkitekturen. Du skal kunne spore hver struktur tilbage til en forretningsmæssig grund.
Ord du skal kende
Sektion kaldt “Ord du skal kende ”| Term | På én linje |
|---|---|
| Metadatadrevet | Objekter og felter er definitioner, som platformen læser under kørslen, ikke nye fysiske tabeller |
| Multitenancy | Mange org’er deler infrastrukturen, hver for sig isoleret, som lejligheder i én bygning |
| Governor limits | Grænser, der forhindrer én lejer i at lægge beslag på de delte ressourcer |
| Eksternt objekt | Data, der vises i Salesforce via Salesforce Connect og hentes fra kilden, hver gang de bliver rørt |
| Big object | Lagerplads til meget store, sjældent brugte datamængder, forespurgt via indekset |
| Personkonto | En enkeltperson repræsenteret som en konto, til business-to-consumer-modeller |
| Rent match | Et forretningsbegreb, der passer til det formål, et standardobjekt er tænkt til |
| External ID | Et felt med et andet systems identifikator, brugt til upserts og matchning |
| Upsert | Opdatér posten, hvis den findes, og opret den, hvis den ikke gør |
| Lookup | En relation, hvor barnet beholder sin egen ejer og sit eget liv |
| Master-detail | En relation, hvor barnet tilhører forælderen: nedarvet ejer og deling, kaskadesletning, roll-ups |
| Logisk forbindelsesobjekt | Modelleringsideen: et objekt, der forbinder to andre i en mange-til-mange-relation og har sine egne attributter, uanset hvordan det er bygget |
| Forbindelsesobjekt i Salesforce (Salesforce Junction Object) | Det, Salesforce mener med »junction object«: et brugerdefineret objekt med to master-detail-relationer |
| Primær og sekundær master | Den master-detail, der blev oprettet først i et forbindelsesobjekt i Salesforce (ejer, udseende, division), og den anden (rapportomfang; bliver primær, hvis den første fjernes) |
| Hierarkisk relation | Et særligt lookup, der kun findes på User-objektet, som Manager, og som ikke må pege tilbage på den samme bruger |
| Navnerumspræfiks | Leverandørens præfiks på en administreret pakkes objekter og felter, som abc__Inspection__c |
| Delingstabel | Delingsobjektet (AccountShare, Truck__Share), der rummer det meste af en posts deling, én række pr. bruger eller gruppe, med årsagen |
| Oversigtsfelt (roll-up summary) | Et felt på masteren, der tæller, summerer eller finder minimum eller maksimum af dens detaljer |
| Data skew | For mange poster under én forælder eller én ejer, som giver låse og lange genberegninger af delingen |
| Medlemsbaseret / login-baseret | At betale pr. ekstern bruger eller pr. login hver måned |
| Konsistensstigen | De lag, der håndhæver dataregler, fra felttype op til automatisering |
| Begrænset valgliste | En valgliste, der afviser enhver værdi, der ikke står på listen, uanset kilde |
| Dataklassifikation | Feltmetadata for ejer, brug, følsomhed og compliance-kategori |
Test dig selv
Sektion kaldt “Test dig selv ”Korte scenarier i kursets stil. Beslut dig for dit svar, før du åbner det.
1. Brugerne skal kunne se ordredetaljer, som ERP'et ejer og opdaterer hele dagen. De redigerer dem ikke i Salesforce. Skal de kopieres ind eller ej?
Referér til dem: eksterne objekter via Salesforce Connect holder ERP’et som sandhedskilde, uden en kopi, der skal synkroniseres. Acceptér, at hver visning laver et kald ud, så latens og ERP’ets tilgængelighed betyder noget, og at det passer bedre til læseadgang end til tung redigering eller rapportering. Læs Refereret igen.
2. Forretningen vil holde styr på distributører, leverandører og detailpartnere. Tre brugerdefinerede objekter?
Nej. De er alle virksomheder, så konto er et rent match; de forskellige navne er roller, der bæres af en type, en posttype eller en relation. Læs Testen for rent match igen.
3. Et design bruger salgsmulighed (Opportunity), men de fleste af dem, der skal bruge dataene, har Salesforce Platform- eller Customer Community-licenser. Hvad nu?
De licenser kan ikke bruge Opportunity, så licensen er en arkitektonisk begrænsning: køb andre licenser, flyt oplevelsen, eller redesign, som regel i retning af et brugerdefineret objekt. Læs Lad mig så gøre det hele mere kompliceret: licenser igen.
4. ERP'et sender opdateringer til konti hver nat. Hvordan skal integrationen finde den rigtige post uden at forespørge efter Salesforce-id'er?
Gem ERP’ets kundenummer i et External ID-felt, og lav upsert på det: opdatér, hvis posten findes, og opret, hvis den ikke gør. Underordnede poster kan også pege på deres forælder via dens External ID. Læs External IDs igen.
5. En leveringslinje kan ikke eksistere uden sin levering, flytter sig aldrig og behøver ingen ejer for sig selv. En levering findes, før den bliver lagt på en rute, og kan flytte til en anden rute. Hvilken relation til hver?
Leveringslinje til levering: master-detail (den tilhører forælderen hele livet, nedarver adgang og bliver slettet med den). Levering til rute: et lookup (sit eget liv, valgfri i starten, kan flyttes, og sletning af en rute må aldrig slette leveringer). Læs Start med forretningsrelationen igen.
6. En integration opretter 3.300 leveringer om dagen, som alle ejes af integrationsbrugeren, der har en rolle midt i hierarkiet. Hvad er risikoen, og hvad er løsningen?
Ownership skew: over 10.000 poster udløser det lange genberegninger af delingen at flytte den bruger eller ændre dens grupper. Spred ejerskabet, hvis det betyder noget for adgangen; ellers hold integrationsbrugeren uden for rollehierarkiet, eller alene i en rolle i toppen, og uden for de grupper, delingsregler bruger. Læs Ejerskab kan blive et skalaproblem igen.
7. Du tilføjer en valideringsregel, og 20.000 gamle poster bryder den. En bruger retter et telefonnummer på én af dem, og gemningen fejler. Hvad burde reglen have gjort?
Sagt, hvornår den skal håndhæves, ikke kun hvad der skal være sandt: afgræns den med ISNEW() eller ISCHANGED() på de relevante felter, og giv poster, der er ældre end reglen, en bevidst undtagelse i stedet for at omskrive deres historik. Læs Problemet med de gamle poster igen.
8. Forretningen vil have alle leveringsfotos »i Salesforce«: fire til fem millioner om året, med en vækst på 30 %. Hvad foreslår du?
Adskil adgang fra lagring. Hold filerne i lagerplads, der er bygget til den volumen, uden for core-org’en, og gem en reference, et antal eller en indekspost i Salesforce, så brugerne kan finde og se dem. Læs Fotos igen.
9. En teamtildeling (Crew Assignment) har master-detail-relationer til team (oprettet først) og lastbil. En disponent kan se teamet, men ikke lastbilen. Kan disponenten se teamtildelingen?
Nej. Teamet er den primære, så det giver tildelingen dens ejer og udseende, men adgang kræver begge forældre: disponenten skal have adgang til teamet og lastbilen, på det niveau, hvert master-detail-felts Sharing Setting kræver. Den mest restriktive vinder. Læs To forældre bredt igen.
10. En partner sender en manifestfil igen, og den samme kunde optræder to gange i den. Du har en dubletregel på konto, der er sat til at blokere. Er du sikker?
Ikke med dubletreglen alene. Poster, der gemmes i samme øjeblik, sammenlignes ikke med hinanden, kun med poster, der allerede er i Salesforce, så begge rækker kan slippe igennem. Skub unikheden ned til feltet: et unikt External ID, som platformen tjekker ved hver gemning, så kun én vinder. Læs Fjerde trin: dubletregler og Alt eller intet igen.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-09-25): den officielle liste over mål og deres vægtning. Tjek altid den aktuelle version, før du booker eksamen.
- Hvert moduls eget afsnit Læs mere angiver den Salesforce-dokumentation, der ligger bag dets platformsfakta, med datoen for kontrollen.