Zet het model om naar Salesforce

🌐 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

Module 6 van 6 in het hoofdstuk Data modelleren naar betekenis, hoofdstuk 2 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Ontwerp tot de derde normaalvorm en doe dan een stap terug · Volgende: de studiegids bij dit hoofdstuk, daarna het volgende hoofdstuk: Salesforce-data-architectuur

De vraag die deze module beantwoordt: Hoe wordt een logisch datamodel een fysiek Salesforce-datamodel?

Eindelijk gaan we het over Salesforce hebben. Als je de neiging hebt weerstaan om van elk blok een object te maken, mag het nu. Maar let op de volgorde waarin we hier kwamen: we begrepen de business, beschreven de data, zetten elk feit waar het hoort, en besloten waar we daar bewust van afwijken. Pas nu vraag ik hoe Salesforce het moet implementeren. Dat is de volgorde die ik wil dat je onthoudt: conceptueel → logisch → fysiek. Het conceptuele model beschrijft de business. Het logische model beschrijft de data. Het fysieke model beschrijft hoe we het echt gaan bouwen.

Zit, Blijf, Modelleer

De fysieke stap is het makkelijkst te zien bij iets kleins, dus de huisdieren gaan eerst.

Wie zijn de bedrijven en de mensen? De fokker is een bedrijf, dus die wordt een account (Account) met het recordtype Fokker. De eigenaar is ook een account, of een persoonsaccount, met het recordtype Eigenaar. Twee soorten van hetzelfde standaardobject, naast elkaar bovenaan het diagram, precies waar ze sinds module 1 staan.

Wat heeft geen standaardplek? Huisdier, Ras, Kunstje, Huisdierkunstje en Kunstjebeoordeling worden aangepaste objecten. En weet je nog de soort die we in module 5 naar het huisdier kopieerden? Hier krijgt die zijn taak: het wordt het recordtype van het huisdier, Hond of Kat. Eén object met twee recordtypes, elk met een eigen pagina-indeling en eigen keuzelijstwaarden, in plaats van een object Hond en een object Kat.

Welke relaties zijn hoofd-detail? Ik gebruik hoofd-detail alleen waar het child nooit een andere parent krijgt. Een huisdierkunstje hoort zijn hele leven bij zijn huisdier, en elke kunstjebeoordeling hoort bij haar huisdierkunstje, dus beide zijn hoofd-detail. Dat betaalt zich meteen uit: hoofd-detail is wat het huisdier een samenvattingsveld (roll-up summary) van zijn huisdierkunstjes laat bijhouden, zodat de telling Aantal kunstjes uit module 5 vanzelf klopt. Huisdieren verhuizen wel eens naar een ander thuis, dus de eigenaar is een lookup.

Welke zijn lookups? Salesforce raadt niet meer dan 10.000 children op één parent aan. Een populair kunstje als Zit, een veelvoorkomend ras of een grote fokker kan daar makkelijk overheen gaan, dus Huisdierkunstje verwijst met een lookup naar zijn Kunstje, en het huisdier verwijst op dezelfde manier naar zijn Ras en Fokker. En vermijd polymorfe relaties waar je kunt, het soort waarbij één veld naar meerdere objecttypes kan verwijzen. Ze zijn handig op dag één en lastiger voor alles wat ze later moet lezen: rapporten, integraties, en nu ook agents.

Wat blijft buiten het platform? Als het huisdier een gps-halsband draagt die doorgeeft waar het is, hoeft die locatie helemaal niet naar binnen gekopieerd te worden. Het kan een extern object zijn, live gelezen uit het volgsysteem van de halsband.

Click to enlarge

Elke beslissing in dat diagram is terug te voeren op iets wat we eerder besloten, en daar gaat het om. Nu dezelfde stap voor Steve Trucking.

Begin bij het logische model

Ons logische model van Steve Trucking bevat nu Retailpartner, Distributiecentrum, Vrachtlijst, Levering, Leveringsitem, Ontvanger, Route, Stop, Bezorgploeg, Vrachtwagen en Ploegtoewijzing. Dat zijn bedrijfsconcepten, en nu kan ik ze aan Salesforce gaan koppelen.

Een retailpartner zou een account kunnen zijn. Een levering zou kunnen passen op iets wat Salesforce al heeft voor ingepland werk in het veld, of een aangepast object kunnen worden. Voor een vrachtlijst past niets standaards, dus die wordt waarschijnlijk aangepast. En de ontvanger is een echt lastige vraag: een persoonsaccount, een contactpersoon, of gewoon informatie op de levering? Die beantwoorden we goed in het volgende hoofdstuk.

Het belangrijke woord is nog steeds zou. Neem de implementatie niet aan alleen omdat een bedrijfsconcept klinkt als een Salesforce-object. Daarom bouwden we eerst het logische model: het geeft ons iets om het Salesforce-ontwerp tegen te toetsen.

Een bedrijfsentiteit betekent niet automatisch een aangepast object

Hier is een valkuil die ik admins wil laten vermijden: “We hebben elf entiteiten gevonden, dus we hebben elf aangepaste objecten nodig.” Nee. Een logische entiteit vertelt ons dat het bedrijfsconcept ertoe doet. Ze schrijft niet voor hoe Salesforce het moet opslaan. Een concept kan een standaardobject worden, een aangepast object, een relatie tussen objecten, een veld of een paar velden, een waarde die in configuratie wordt beheerd, of data die helemaal buiten Salesforce staat (de leveringsfoto’s van Steve Trucking zijn daar een goede kandidaat voor). Het fysieke model is waar die keuzes gemaakt worden, en precies daarom maakten we ze niet in het eerste gesprek.

Attributen worden fysieke velden

Dezelfde overgang gebeurt met attributen. Onze logische Vrachtwagen heeft een eenheidsnummer, VIN, merk, model, bouwjaar, kenteken en status. Nu beslissen we hoe ze fysiek bestaan: welk object er eigenaar van is, welke veldtypen ze gebruiken, welke verplicht zijn, welke uniek moeten zijn, welke externe identificatoren zijn, welke validatie nodig hebben, welke afgeleid worden in plaats van opgeslagen, en welke gevoelig zijn. Op logisch niveau vroegen we wat Vrachtwagen betekent. Op fysiek niveau vragen we hoe Salesforce Vrachtwagen gaat weergeven. Verschillende vragen.

Click to enlarge

Relaties worden platformbeslissingen

Alle tijd die we aan relaties besteedden, betaalt zich hier uit. We weten al of elke relatie een-op-een, een-op-veel of veel-op-veel is, verplicht of optioneel, en of haar historie ertoe doet. Nu beslissen we hoe Salesforce haar implementeert: een lookup, een master-detail of een Salesforce-koppelobject, en misschien een koppelobject met eigen attributen, omdat, zoals we ontdekten, de relatie zelf betekenis voor de business kan hebben.

Denk terug aan de ploegtoewijzing. We hadden dit hoofdstuk kunnen beginnen met: “Laten we een Salesforce-koppelobject maken tussen ploeg en vrachtwagen.” Kijk wat we dan hadden overgeslagen: waarom de relatie bestaat, of ze een datum en een route nodig heeft, of ze een status heeft, en of een schadeclaim weken later haar historie nodig heeft. Die bedrijfsvragen vertellen ons wat een ploegtoewijzing is. Pas daarna moeten we beslissen hoe Salesforce haar bouwt, en of Salesforce al iets heeft dat het werk doet.

Teken nu het fysieke model

Het diagram verandert weer. Het conceptuele model toonde bedrijfsconcepten en eenvoudige lijnen. Het logische model voegde attributen, sleutels, kardinaliteit en de entiteiten in relaties toe. Nu begint het fysieke model op Salesforce te lijken: standaardobjecten, aangepaste objecten, velden, relatietypen, en wat buiten het platform staat.

Click to enlarge

Ik wil dat je die drie diagrammen naast elkaar kunt leggen en de voortgang ziet: geen drie losse diagrammen, maar hetzelfde bedrijf op drie niveaus.

Een woord over hoe ik deze teken, want de indeling is deel van de boodschap. Ik zet het primaire object in het midden, iets naar beneden. Als het parent-objecten heeft, zet ik die iets erboven, zodat je het model van boven naar beneden en van links naar rechts leest, zoals de business erover denkt. Referentiedata gaat opzij. Kleur betekent ook iets: Salesforce maak ik altijd blauw, en voor de eigen systemen van het bedrijf kies ik een kleur, meestal groen, omdat groen een fijne, vriendelijke kleur is. Rood gebruik ik niet, en geel is een beetje fel. Als een model zo is ingedeeld, zingt het voor me. Veel diagrammen die je tegenkomt zijn eigenlijk ruimtebeheer: hoe parkeer ik al mijn auto’s in mijn volle garage? Ik schilder liever een logisch beeld dat het verstand kan vatten.

Het fysieke model moet het platform respecteren

Salesforce is geen generieke relationele database. Het heeft opvattingen over relaties, eigenaarschap, beveiliging en rapportage. Het heeft limieten, querygedrag en automatisering, en een architectuur die bepaalt hoe een model zich op schaal gedraagt. Dus een logisch model dat er op een whiteboard perfect uitziet, moet misschien veranderen als het fysiek wordt. Dat is niet Salesforce dat in de weg zit. Het betekent dat het platform een vorm heeft, en goede architecten begrijpen die vorm. Het volgende hoofdstuk gaat precies daarover.

Soms wijkt het fysieke model ook bewust af van het schone logische model, vanwege de denormalisatiebeslissingen die we in module 5 namen. Dat is prima, zolang we kunnen uitleggen waarom.

Ontwerp niet vanuit Setup

Er is een gewoonte die ik je wil laten afleren als je haar hebt: je data-architectuur beginnen bij Setup → Object Manager → New Custom Object en het model gaandeweg uitvogelen. Salesforce maakt het ongelooflijk makkelijk om dingen te maken; dat is een van zijn sterke punten, en een van de redenen waarom zwakke datamodellen zo snel ontstaan. Een paar klikken en je hebt een object, nog een paar en je hebt velden en een relatie. Dan komt er data binnen, worden er flows gebouwd, rapporten gemaakt, gaan integraties ervan afhangen, en is het object dat je in vijf minuten maakte heel duur om te veranderen. Het is de omkeerbaarheidstest uit hoofdstuk 1. Dus voordat je op New Custom Object klikt, teken het model.

Fysiek betekent niet permanent

Er is nog een reden waarom ik de drie modellen gescheiden houd: technologie verandert. Vandaag staat een deel van de data van Steve Trucking op Salesforce core. Morgen staat een deel misschien in Data 360, een warehouse of een systeem dat we nog niet gekozen hebben, en heeft de AI-assistent een eigen weergave nodig. De fysieke architectuur kan veranderen, terwijl de bedrijfsconcepten opmerkelijk stabiel blijven: retailpartners, leveringen en ontvangers bestaan nog steeds. Dat maakt het logische model waardevol. Het is een duurzame beschrijving van de business die niet vastzit aan de implementatie van vandaag.

Wat een architect hier beslist

Als ik een logisch model omzet in een fysiek Salesforce-model, beslis ik:

• Welke bedrijfsentiteiten passen op standaardmogelijkheden van Salesforce, en welke aangepaste objecten of een andere weergave nodig hebben.
• Hoe logische attributen fysieke velden worden, en hoe relaties op het platform geïmplementeerd worden.
• Waar bewuste denormalisatie in het fysieke ontwerp hoort.
• Welke data in Salesforce hoort, en welke ergens anders.
• Welke eigenschappen van het platform vragen dat het fysieke model afwijkt van het logische.

En vooral wil ik elke beslissing terug kunnen volgen. Als je naar iets in mijn fysieke model wijst en vraagt “Waarom staat dat daar?”, moet ik je kunnen terugleiden via het logische model en het conceptuele model naar iets wat de business echt nodig heeft: business → conceptueel → logisch → fysiek.

Voorbij het examen: wat AI verandert. AI kan nu een eisendocument in één sprong omzetten naar Salesforce-objecten en -velden. Dat maakt de volgorde belangrijker, niet minder belangrijk: als het van eisen naar configuratie springt, vraag het dan te laten zien wat er tussenin gebeurde: wat het als entiteit zag, welke sleutels het koos, welke relaties het aannam en waar het denormaliseerde. Dat zijn architectuurbeslissingen, en de architect moet ze nog steeds zien.

We begonnen dit hoofdstuk in een eerste gesprek, luisterend naar zelfstandige naamwoorden, en we eindigen met een fysiek model dat we kunnen terugvoeren naar de business. Nu we ervoor gekozen hebben op Salesforce te bouwen, gaat de volgende vraag dieper: op wat voor dataplatform bouwen we eigenlijk?

Verder lezen

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab) (Engels), Salesforce Developers, Winter ‘27 (gecontroleerd op 2026-10-02): “configure parent-child relationships with no more than 10,000 children to one parent record.” Een richtlijn over data skew, geen harde limiet; hoofdstuk 7 gaat dieper.
• Roll-Up Summary Field (opens in a new tab) (Engels), Salesforce Help (gecontroleerd op 2026-10-12): een samenvattingsveld (roll-up summary) telt of totaliseert detailrecords via een hoofd-detailrelatie.