Salesforce-data-architectuur

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Studiegids bij hoofdstuk 3 van de cursus Data Architect. Lees eerst de tien modules; deze pagina helpt je na te gaan wat is blijven hangen.

Over deze studiegids. Hij is alleen gebaseerd op de eigen inhoud van deze cursus en op de lijst met doelstellingen in de gepubliceerde examengids van Salesforce. Hij is nooit gebaseerd op echte examenvragen, en hij beweert niet te weten wat er in het examen staat. Als je het examen hebt gedaan, stuur me dan alsjeblieft geen vragen eruit: de certificeringsovereenkomst verbiedt het delen ervan, en antwoorden uit je hoofd leren is sowieso de verkeerde manier om architect te worden.

Dit is het hoofdstuk waarin het model het platform ontmoet, en het draagt een groot deel van het examen. Het voedt beide grootste onderdelen, Data Modeling and Database Design en Salesforce Data Management, elk een kwart van het examen. Platformgetallen veranderen: de checklist geeft de getallen die de modules noemen, met de datum waarop ze gecontroleerd zijn. Leer waar elke limiet voor dient, en controleer het actuele getal voordat je erop vertrouwt.

Voor het examen

Vink ze af terwijl je verdergaat. Elk punt linkt naar de plek waar het behandeld wordt.

DM-1: het datamodel op het platform ontwerpen

• Ik weet dat Salesforce een metadatagestuurd, multitenant platform is: een object is metadata, geen nieuwe tabel, en elk object krijgt zijn API’s op het moment dat het bestaat. (Metadata is de bouwtekening, Je API kwam mee met het object)
• Ik weet dat governor limits bestaan zodat één tenant de gedeelde middelen niet kan overnemen. (Je kunt de lift niet overnemen)
• Ik kan de standaard datamodellen lezen: de conversie van een lead naar account, contactpersoon en verkoopkans; een Opportunity Product verwijst naar een Price Book Entry, die naar Product2 verwijst; en Case, Asset en Entitlement aan de servicekant. (Het salesmodel, Het servicemodel)
• Ik weet wat het scherm New Custom Object beslist: een recordnaam als tekst of automatisch nummer; Object Classification (met sharing, Bulk API en Streaming API aan is het een Enterprise Application-object, met die uit een Light Application-object); en Allow Search, standaard uit. (Het scherm New Custom Object)
• Ik kan een API-naam lezen: standaardobjecten en -velden hebben geen voor- of achtervoegsel; aangepaste objecten en velden eindigen op __c; een managed package voegt zijn namespace-voorvoegsel toe (abc__); en een veld dat je toevoegt aan een object van een package krijgt __c, maar nooit het voorvoegsel van de leverancier. (Voorvoegsels en achtervoegsels: waar je naar kijkt)
• Ik kan de test van de schone fit toepassen voor een standaardobject, en ik weet wanneer betekenis of gewicht naar een aangepast object wijzen. (De test van de schone fit)
• Ik weet waar Asset en persoonsaccounts voor zijn, dat een persoonsaccount ongeveer twee keer zoveel opslag inneemt als een zakelijk account, en dat persoonsaccounts, eenmaal ingeschakeld, niet meer uitgeschakeld kunnen worden. (Asset is een goed voorbeeld, Persoonsaccounts, Wanneer is de persoon het account?)
• Ik kies een veldtype op het gedrag dat ik nodig heb (een vlootnummer is geen Number), en ik weet dat datum/tijd in GMT wordt opgeslagen en in de tijdzone van elke lezer wordt getoond, dus dat je het met bereiken vergelijkt, niet met gelijkheid. (Een getal is niet altijd een getal, Datum, datum/tijd en tijd)
• Ik weet dat tekst in twee soorten komt: tot 255 tekens op het record (indexeerbaar, bruikbaar als uniek veld of externe ID), en lange of opgemaakte tekst daarboven, zonder index, zonder WHERE-filtering en zonder formules. (De tekstfamilie)
• Ik weet wanneer ik een Name met automatisch nummer gebruik, en dat het niet de ID van het record is. (Moet een mens het kunnen herkennen?)
• Ik weet hoe een externe ID een integratie laat upserten, en children laat laden via de externe ID van hun parent. (Externe ID’s)
• Ik weet wanneer een waarde door een formule afgeleid moet worden, en wanneer het een historisch feit is dat opgeslagen moet worden. (Opgeslagen of afgeleid?)
• Ik ken het verschil tussen een logisch koppelobject (het modelleeridee: een object dat twee andere verbindt in een veel-op-veel, met eigen attributen) en een Salesforce-koppelobject (Salesforce Junction Object: een aangepast object met twee master-detailrelaties), en weet dat Salesforce het tweede bedoelt. (Twee parents breed)
• Ik ken de hiërarchische relatie: een speciale lookup alleen op het object User, zoals het standaardveld Manager, die niet direct of indirect naar dezelfde gebruiker kan teruglopen, en die niet de rolhiërarchie is. (Hiërarchisch)
• Ik ken het verschil tussen een lookup en master-detail: eigenaarschap, sharing, verplichte parent, trapsgewijs verwijderen, samenvattingsvelden. (Lookup, Master-detail)
• Ik weet dat master-detail niet gemaakt kan worden op een object dat al data heeft (maak een lookup, vul hem, zet hem om), alleen terug kan naar een lookup zonder samenvattingsvelden op de master, en Allow reparenting nodig heeft om een child te verplaatsen. (Kan het child van parent wisselen?)
• Ik ken de vorm van het platform voor master-detail: tot drie aangepaste detailniveaus diep (een lookup kan de keten overal breken), en twee master-detail-parents breed. Bij een Salesforce-koppelobject is de eerst gemaakte master-detail de primaire (eigenaar, uiterlijk, divisie), de tweede is de secundaire, en toegang vraagt om beide parents: de strengste wint. (Drie niveaus diep, Twee parents breed)
• Ik ken de drie keuzes van een lookup als de parent verwijderd wordt: het veld leegmaken (de standaard), de verwijdering blokkeren, of trapsgewijs verwijderen, wat uit staat tot Salesforce het inschakelt en wat sharing omzeilt. (Lookup)
• Ik weet dat een relatie met zichzelf een lookup moet zijn, en ken de twee ingebouwde: Parent Account op Account en Parent Case op Case. (Relaties met zichzelf)
• Ik weet dat het herberekenen van samenvattingsvelden tijd kan kosten, dat een samenvattingsveld geen formule kan gebruiken met NOW(), TODAY() of een objectoverschrijdende verwijzing, en dat je master-detail niet kiest alleen om een samenvattingsveld te krijgen: een opgeslagen veld dat een flow of trigger actueel houdt, is het alternatief. (Samenvattingsvelden zijn nuttig, maar niet gratis)
• Ik ken de relatielimieten die de module noemt: twee master-details per object; standaard 40 relatievelden (hooguit 50); standaard 25 samenvattingsvelden (hooguit 40). (Relaties hebben ook limieten)

DM-2: een model dat sharing respecteert en schaalt

• Ik weet dat een master-detail-child geen eigenaar en geen sharetabel van zichzelf heeft: toegang volgt de master. (Eigenaarschap reist mee)
• Ik ken parent-child skew: de richtlijn van Salesforce is niet meer dan ongeveer 10.000 children op één parent. (De vraag van de 10.000 children)
• Ik ken ownership skew (één gebruiker die eigenaar is van meer dan 10.000 records van een object) en de richtlijn: verdeel eigenaarschap, of houd die gebruiker buiten de rolhiërarchie of alleen bovenaan, en buiten openbare groepen die deelregels gebruiken. (Eigenaarschap kan een schaalprobleem worden)
• Ik ken de sharetabel: het share-object van een aangepast object is Object__Share; een detailobject heeft er geen, zijn toegang komt van de master; en een eigenaarswissel verwijdert handmatige shares, maar houdt Apex-sharing met een eigen reden. (De sharetabel)
• Ik kan beslissen wie eigenaar is van records die integraties en agents maken, op basis van of eigenaarschap de sharing stuurt. (Wie is eigenaar van records die systemen maken?)

DM-4: big objects tegenover standaard- en aangepaste objecten

• Ik ken de drie plekken voor data: in de core (sObjects, dagelijks mee gewerkt), verwezen (een ander systeem is de bron van waarheid: de externe objecten van Salesforce Connect, __x, of eigen aanroepen), en gearchiveerd (in de core in big objects, __b, of buiten de core in een warehouse). (In de core en buiten de core)
• Ik weet dat externe objecten elke keer dat ze aangeraakt worden een callout doen, dus vertraging en de beschikbaarheid van het bronsysteem doen ertoe. (Verwezen)
• Ik ken big objects: enorme volumes, bevraagd via hun index op exacte match of bereik, geen standaard-UI of rapportage, alleen object- en veldrechten, geen automatisering. (Gearchiveerd)
• Ik weet dat de meeste records voor ongeveer 2 KB dataopslag tellen, ongeacht het aantal velden, en dat bestanden apart in bestandsopslag worden gemeten. (Twee kolommen of tweehonderd, Bestanden en bijlagen)

SDM-1: licenties en de objecten die mensen kunnen gebruiken

• Ik ken de drie interne licenties, Sales Cloud, Service Cloud en Platform, en weet wat elk ervan kan gebruiken. (Drie interne licenties)
• Ik weet dat licenties deel zijn van het datamodel: Salesforce Platform-gebruikers krijgen geen leads, campagnes, verkoopkansen of forecasts, en Customer Community-gebruikers kunnen geen verkoopkansen gebruiken. (Laat me nu alles ingewikkelder maken: licenties)
• Ik ken de niveaus van externe licenties: Customer Community, Customer Community Plus (rapporten, dashboards, standaard-sharing), Partner Community (salesobjecten); en weet dat Partner Community niet met persoonsaccounts gebruikt kan worden. (Het stadion)
• Ik ken licenties op basis van leden (member-based) tegenover op basis van logins (login-based), en weet bij welke populatie elk past. (Hoe ze betalen verandert het ontwerp)
• Ik weet dat sommige platformlicenties gebruikers beperken tot één app van maximaal tien aangepaste objecten, en ken het recordtypepatroon om daarbinnen te werken. (Als de licentie het model vormt)
• Ik weet dat de licentie Salesforce Integration bedoeld is voor gebruikers van systeem tot systeem, alleen API. (Mensen zijn niet meer de enige gebruikers)
• Ik weet dat SLA-rapportage entitlements en milestones nodig heeft, en dat die Service-licenties vragen. (Laat me nu alles ingewikkelder maken: licenties)

SDM-2: data consistent houden

• Ik kan een regel op de juiste sport van de consistentieladder zetten: veldtype en woordenlijst, verplicht en uniek, validatieregels, duplicaatregels, automatisering. (Gegevens consistent houden)
• Ik weet dat een beperkte keuzelijst waarden weigert die niet op de lijst staan, zelfs via de API, en dat een globale waardeset één lijst over velden deelt (tot 1.000 waarden). (Sport één)
• Ik weet dat een eis op een page layout alleen dat scherm beschermt, niet de data, en dat validatieregels bij elke opslagactie draaien. (UI-validatie is geen datavalidatie, Sport drie)
• Ik kan een validatieregel afbakenen met ISNEW() en ISCHANGED(), een aangepaste machtiging of een go-livedatum, en weet welke opslagacties (ook die ik niet in de hand heb, zoals een eigenaarswissel in batch of een samenvattingsveld) elke keuze nog steeds controleert. (Het probleem van de oude records)
• Ik ken overeenkomstregels en duplicaatregels, de limieten die de module noemt (vijf actieve duplicaatregels per object, elk drie overeenkomstregels), en weet dat ze identiteit over systemen heen niet oplossen. (Sport vier: duplicaatregels)
• Ik weet dat duplicaatregels records die op hetzelfde moment worden opgeslagen niet vergelijken, dat opslag via de API en import zonder waarschuwing geblokkeerd wordt, en dat een opslag met alles wat die in gang zet als één transactie teruggedraaid wordt. (Sport vier, Alles of niets)
• Ik weet dat Workflow Rules en Process Builder niet meer ondersteund worden; automatisering betekent Flow of Apex. (Sport vijf: automatisering)

Voorbij het examen

Het examen is de vloer, niet het plafond. Dit zijn de gewoonten uit dit hoofdstuk die een architect nodig heeft, of er nu ooit een vraag over gesteld wordt of niet.

• Het platform heeft een vorm. Ontwerp voor het platform waar je op zit, niet voor een generieke database.
• Kijk naar het moederschip. Kijk hoe Salesforce een concept modelleert voordat je er zelf een verzint.
• Elk object is een verplichting: opslag, limieten, een sharingmodel, licenties en afhankelijkheden.
• Vraag waar de data staat voordat je een object kiest: in de core, verwezen of gearchiveerd.
• Lees een willekeurige API-naam en je weet wie hem maakte, en wat je kunt veranderen.
• Als je vandaag niet archiveert, ga je dan ooit archiveren?
• Maak een prototype van big objects voordat je ze voorstelt.
• Verschillende bedrijfsnamen betekenen niet automatisch verschillende objecten.
• Vraag welke identiteiten de data nodig hebben: mensen, klanten, partners, integraties en agents.
• Elk veld krijgt een omschrijving, en classificatie waar het ertoe doet.
• Beschrijf eerst het gedrag van de relatie; de configuratie implementeert het. Verbuig het model niet om een functie te krijgen.
• De verwijdervraag: wat moet er met de children gebeuren als iemand de parent verwijdert?
• Kies welke schakel de keten breekt: maak de lookup waar het child echt een eigen leven heeft.
• Eigenaarschap van de primaire, toegang van allebei: de strengste wint.
• Scheid inactief van weg, en maak bewaren een bedrijfsregel.
• Duw de regel zo laag als ze correct thuishoort, en geef legitieme historie een uitzondering in plaats van haar te herschrijven.
• Het diagram is niet de architectuur. Kun elke structuur terugvoeren naar een bedrijfsreden.

Begrippen

Begrip	In één zin
Metadatagestuurd	Objecten en velden zijn definities die het platform tijdens runtime leest, geen nieuwe fysieke tabellen
Multitenancy	Veel orgs delen de infrastructuur, elk afgeschermd, zoals appartementen in één gebouw
Governor limits	Limieten die voorkomen dat één tenant gedeelde middelen monopoliseert
Extern object	Data die via Salesforce Connect in Salesforce getoond wordt, bij elke aanraking uit de bron opgehaald
Big object	Opslag voor zeer grote, zelden gebruikte data, bevraagd via de index
Persoonsaccount	Een individu weergegeven als account, voor business-to-consumer-modellen
Schone fit	Een bedrijfsconcept dat overeenkomt met het bedoelde doel van een standaardobject
Externe ID	Een veld met de identificator van een ander systeem, gebruikt voor upserts en matching
Upsert	Het record bijwerken als het bestaat, aanmaken als het niet bestaat
Lookup	Een relatie waarbij het child een eigen eigenaar en leven houdt
Master-detail	Een relatie waarbij het child bij de parent hoort: geërfde eigenaar en sharing, trapsgewijs verwijderen, samenvattingsvelden
Logisch koppelobject	Het modelleeridee: een object dat twee andere verbindt in een veel-op-veel en eigen attributen draagt, hoe het ook gebouwd is
Salesforce-koppelobject (Salesforce Junction Object)	Wat Salesforce bedoelt met “junction object”: een aangepast object met twee master-detailrelaties
Primaire en secundaire master	De eerst gemaakte master-detail van een Salesforce-koppelobject (eigenaar, uiterlijk, divisie) en de tweede (reikwijdte van rapporten; wordt primair als de eerste verwijderd wordt)
Hiërarchische relatie	Een speciale lookup alleen op het object User, zoals Manager, die niet naar dezelfde gebruiker kan teruglopen
Namespace-voorvoegsel	Het voorvoegsel van de leverancier op de objecten en velden van een managed package, zoals abc__Inspection__c
Sharetabel	Het share-object (AccountShare, Truck__Share) met het grootste deel van de sharing van een record, één rij per gebruiker of groep, met de reden erbij
Samenvattingsveld (roll-up summary)	Een veld op de master dat zijn details telt, optelt of het minimum of maximum vindt
Data skew	Te veel records onder één parent of één eigenaar, met vergrendelingen en lange sharingherberekeningen tot gevolg
Member-based / login-based	Betalen per externe gebruiker, of per login per maand
Consistentieladder	De lagen die dataregels afdwingen, van veldtype tot automatisering
Beperkte keuzelijst	Een keuzelijst die elke waarde weigert die niet op de lijst staat, uit welke bron ook
Dataclassificatie	Veldmetadata voor eigenaar, gebruik, gevoeligheid en compliancecategorie

Test jezelf

Korte scenario’s in de stijl van de cursus. Bepaal je antwoord voordat je het openklapt.

1. Gebruikers moeten orderdetails zien waarvan het ERP eigenaar is en die het de hele dag bijwerkt. Ze bewerken ze niet in Salesforce. Kopiëren of niet?

Verwijs ernaar: externe objecten via Salesforce Connect houden het ERP als bron van waarheid, zonder kopie om te synchroniseren. Accepteer dat elke weergave een callout maakt, dus vertraging en de beschikbaarheid van het ERP doen ertoe, en dat het beter past bij lezen dan bij veel bewerken of zware rapportage. Lees opnieuw Verwezen.

2. De business wil distributeurs, leveranciers en retailpartners bijhouden. Drie aangepaste objecten?

Nee. Het zijn allemaal bedrijven, dus account is een schone fit; de verschillende namen zijn rollen, gedragen door een type, een recordtype of een relatie. Lees opnieuw De test van de schone fit.

3. Een ontwerp gebruikt Opportunity, maar de meeste mensen die de data nodig hebben, hebben een licentie Salesforce Platform of Customer Community. Wat nu?

Die licenties kunnen geen verkoopkansen gebruiken, dus de licentie is een architectuurbeperking: andere licenties kopen, de ervaring verplaatsen of herontwerpen, meestal richting een aangepast object. Lees opnieuw Laat me nu alles ingewikkelder maken: licenties.

4. Het ERP stuurt elke nacht updates voor accounts. Hoe moet de integratie het juiste record vinden zonder Salesforce-ID's op te vragen?

Sla het klantnummer van het ERP op in een veld met externe ID en upsert daarop: bijwerken als gevonden, aanmaken als niet. Child-records kunnen ook via de externe ID van hun parent naar die parent verwijzen. Lees opnieuw Externe ID’s.

5. Een leveringsitem kan niet bestaan zonder zijn levering, verhuist nooit en heeft geen eigen eigenaar nodig. Een levering bestaat voordat ze ingepland is en kan naar een andere route verhuizen. Welke relatie voor elk?

Leveringsitem naar levering: master-detail (het hoort zijn hele leven bij de parent, erft toegang, wordt mee verwijderd). Levering naar route: een lookup (een eigen leven, eerst optioneel, verplaatsbaar, en het verwijderen van een route mag nooit leveringen verwijderen). Lees opnieuw Begin bij de bedrijfsrelatie.

6. Een integratie maakt 3.300 leveringen per dag, allemaal van de integratiegebruiker, die een rol midden in de hiërarchie heeft. Wat is het risico, en de oplossing?

Ownership skew: voorbij 10.000 records zorgt het verplaatsen van die gebruiker of het veranderen van zijn groepen voor lange sharingherberekeningen. Verdeel eigenaarschap als het voor toegang ertoe doet; houd anders de integratiegebruiker buiten de rolhiërarchie, of alleen in een rol bovenaan, en buiten groepen die deelregels gebruiken. Lees opnieuw Eigenaarschap kan een schaalprobleem worden.

7. Je voegt een validatieregel toe, en 20.000 oude records overtreden haar. Een gebruiker bewerkt een telefoonnummer in een ervan en het opslaan mislukt. Wat had de regel moeten doen?

Zeggen wanneer ze afgedwongen wordt, niet alleen wat er waar moet zijn: baken haar af met ISNEW() of ISCHANGED() op de relevante velden, en geef records van vóór de regel een bewuste uitzondering in plaats van hun historie te herschrijven. Lees opnieuw Het probleem van de oude records.

8. De business wil elke leveringsfoto "in Salesforce": vier tot vijf miljoen per jaar, met 30 procent groei. Wat stel je voor?

Scheid toegang van opslag. Bewaar de bestanden in opslag die voor dat volume gebouwd is, buiten de core-org, en houd een referentie, een aantal of een indexrecord in Salesforce zodat gebruikers ze kunnen vinden en zien. Lees opnieuw Foto’s.

9. Een ploegtoewijzing heeft master-detailrelaties met Bezorgploeg (als eerste gemaakt) en Vrachtwagen. Een planner kan de ploeg zien, maar niet de vrachtwagen. Kan hij de ploegtoewijzing zien?

Nee. Bezorgploeg is de primaire, dus die geeft de toewijzing haar eigenaar en uiterlijk, maar toegang vraagt om beide parents: de planner heeft toegang nodig tot de ploeg en de vrachtwagen, op het niveau dat de Sharing Setting van elk master-detailveld vraagt. De strengste wint. Lees opnieuw Twee parents breed.

10. Een partner stuurt een vrachtlijstbestand opnieuw, en dezelfde klant staat er twee keer in. Je hebt een duplicaatregel op Account die op blokkeren staat. Ben je veilig?

Niet door de duplicaatregel alleen. Records die op hetzelfde moment worden opgeslagen, worden niet met elkaar vergeleken, alleen met records die al in Salesforce staan, dus beide rijen kunnen erdoor komen. Duw uniciteit omlaag naar het veld: een unieke externe ID, die het platform bij elke opslag controleert, zodat maar één wint. Lees opnieuw Sport vier: duplicaatregels en Alles of niets.

Verder lezen

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-09-25): de officiële lijst met doelstellingen en hun gewicht. Kijk altijd de actuele versie na voordat je het examen boekt.
• Het onderdeel Verder lezen van elke module noemt de Salesforce-documentatie achter de platformfeiten, met de datum waarop ze gecontroleerd is.