Ga naar inhoud
SteveTechArcSteveTechArc Courses

De standaard datamodellen

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Afbeelding gegenereerd met AI

Module 2 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Het Salesforce-dataplatform: meer dan een database · Volgende: Bouw je eigen: aangepaste objecten

De vraag die deze module beantwoordt: Wat heeft Salesforce al voor je gemodelleerd, en hoe zit dat in elkaar?

In module 1 zei ik dat je moet kijken naar het moederschip: voordat je iets verzint, kijk hoe Salesforce het zelf doet. In deze module gaan we echt kijken. Salesforce heeft al veel business voor je gemodelleerd, in zijn standaardobjecten, en twee van die modellen doen het meeste werk in de meeste orgs waar ik binnenstap: het salesmodel en het servicemodel. Voordat je kunt beslissen of iets een aangepast object verdient, moet je weten wat er al is. Daar gaan de volgende twee modules over.

Wat een object standaard maakt

Section titled “Wat een object standaard maakt ”

Een standaardobject zit er standaard in. Salesforce heeft het gebouwd, het heeft een vastgelegd doel, en het komt met zijn eigen velden en relaties. Je kunt er velden aan toevoegen, er automatisering omheen bouwen en de indelingen ervan wijzigen, maar je kunt het niet herontwerpen: de standaardvelden en -relaties zijn van Salesforce.

Kijk naar de namen. Account, Contact, Case. Geen voorvoegsel, geen achtervoegsel. Dat is Salesforce dat die ruimte voor zichzelf houdt. Alles wat wij bouwen eindigt op __c, dus Salesforce kan op elk moment nieuwe standaardobjecten toevoegen zonder ooit te botsen met iets in jouw org. En dat doet het ook, elke release.

Ergens onderweg bouwde iemand een productobject dat niet goed uitpakte en moest worden achtergelaten. Daarom is de API-naam Product2. Het is mijn eerste lakmoesproef als iemand me vertelt dat die Salesforce kent.

Het salesmodel

Section titled “Het salesmodel ”

Begin links, bij de lead (Lead): iemand die misschien klant wordt. Een lead hoort eigenlijk nog niet bij het model. Het is een wachtruimte. Als je hem converteert, maakt Salesforce de echte records aan: een account (Account), een contactpersoon (Contact) en, als er een deal is, een verkoopkans (Opportunity). Daarom teken ik de lead aan de zijkant.

Het account is het bedrijf. De contactpersonen zijn de mensen die er werken. Een verkoopkans is een deal met dat account. Tot nu toe niets wat je niet verwachtte.

Dan wordt het interessant. Wat zit er in de deal? Elke regel is een verkoopkansproduct (Opportunity Product), en een verkoopkansproduct wijst niet rechtstreeks naar een product. Het wijst naar een prijsboekvermelding (Price Book Entry): dit product, tegen deze prijs, in dit prijsboek. De prijsboekvermelding zit tussen het product (Product) en het prijsboek (Price Book), zodat hetzelfde product één prijs kan hebben in het standaardprijsboek en een andere in je partnerprijsboek.

Dat zijn twee relaties die dingen werden, de een na de ander. Weet je nog het leveringsitem uit hoofdstuk 2, tussen de levering en het product, en het hondkunstje tussen de hond en het kunstje? Salesforce deed hier precies hetzelfde, twee keer: het verkoopkansproduct tussen de verkoopkans en de prijsboekvermelding, en de prijsboekvermelding tussen het product en het prijsboek. Als je dat kunt lezen, kun je het grootste deel van het standaard datamodel lezen.

Het salesmodel Het salesmodel. Een lead, links apart, wordt geconverteerd naar een account. Een account heeft contactpersonen en verkoopkansen. Een verkoopkans gebruikt een prijsboek en bevat verkoopkansproducten. Elk verkoopkansproduct wordt geprijsd via één prijsboekvermelding. Een prijsboek bevat prijsboekvermeldingen, en een product staat in prijsboekvermeldingen, dus elke prijsboekvermelding verbindt één product en één prijsboek. wordt geconverteerd naar heeft heeft gebruikt bevat geprijsd via bevat staat in Lead Account Contactpersoon Verkoopkans Prijsboek Verkoopkansproduct Prijsboekvermelding Product precies één nul of één één of veel nul of veel © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Hier is die keten van dichtbij, met de velden die hem bij elkaar houden:

De prijsketen van dichtbij De prijsketen als gedetailleerd datamodel. Een verkoopkansproduct bevat zijn verkoopkans-ID, zijn prijsboekvermelding-ID, een hoeveelheid en een verkoopprijs, en wordt geprijsd via één prijsboekvermelding. De prijsboekvermelding bevat haar prijsboek-ID, haar product-ID, een catalogusprijs en een vlag Standaardprijs gebruiken. Een prijsboek heeft een naam en een vlag Is standaard; een product heeft een naam en een productcode. geprijsd via bevat staat in Prijsboek Prijsboek-ID RECORD-ID Naam Is standaard Verkoopkansproduct Verkoopkansproduct-ID RECORD-ID Verkoopkans-ID Prijsboekvermelding-ID Hoeveelheid Verkoopprijs Prijsboekvermelding Prijsboekvermelding-ID RECORD-ID Prijsboek-ID Product-ID Catalogusprijs Standaardprijs gebruiken Product Product-ID RECORD-ID Naam Productcode precies één nul of één één of veel nul of veel © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Eén regel waar mensen over struikelen: er is een standaardprijsboek, en een prijsboekvermelding in elk ander prijsboek kan gewoon de standaardprijs van het product gebruiken. Weet welk prijsboek een verkoopkans gebruikt voordat je de producten ervan laadt.

Het servicemodel

Section titled “Het servicemodel ”

Nu de andere kant van het huis. Hetzelfde account, dezelfde contactpersonen. Als er iets misgaat, opent de klant een case (Case).

De case gaat meestal over iets wat de klant heeft, en Salesforce heeft daar een object voor: de asset (Asset). In module 5 noem ik het het standaardobject dat mensen over het hoofd zien. Het is iets wat de klant heeft, of hij het nu van jou kocht of niet.

En waar heeft de klant recht op? Dat is het entitlement (Entitlement): de ondersteuning waarvoor een account in aanmerking komt, vaak gekoppeld aan een asset, een product of een servicecontract. Zet een entitlement op een case, en nu weet de case welk niveau van ondersteuning hij hoort te krijgen.

Het servicemodel Het servicemodel. Een account heeft contactpersonen, cases en assets. Een contactpersoon meldt cases. Een case kan over één asset gaan, en een entitlement, dat bij een account hoort, dekt cases. Een lijn van de case terug naar zichzelf, om de hoek, is de parent-case: een case is de parent van nul of veel cases, en elke case heeft nul of één parent. heeft heeft meldt bezit gaat over dekt parent van Account Contactpersoon Asset Case Entitlement precies één nul of één één of veel nul of veel © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Kijk naar de lijn die van de case terugloopt naar zichzelf. Elke case heeft een veld Parent Case (bovenliggende case), en dat wijst naar een andere case. Dat is een self-lookup: een relatie van een object naar zichzelf. Veel mensen raken erdoor in de war als ze het voor het eerst zien, dus hier zijn de twee redenen waarom ik het gebruik.

Eén: een groot probleem dat uiteenvalt in kleinere. De klant meldt dat de hele installatie plat ligt. We openen subcases voor het netwerk, de hardware en de configuratie, die elk apart worden opgepakt, en ze lossen allemaal naar boven op: de bovenliggende case is pas klaar als zij klaar zijn.

Twee: historie. Een case werd vorige maand gesloten, en nu is hetzelfde probleem terug. De nieuwe case wijst terug naar de oorspronkelijke, zodat iedereen die hem opent kan zien dat dit al eerder is gebeurd, en wat eraan gedaan is.

We komen terug op self-lookups als we in module 7 bij relaties komen.

Merk op dat het account en de contactpersoon in beide diagrammen op dezelfde plek staan. Het zijn dezelfde records. Een verkoper en een servicemedewerker kijken naar dezelfde klant, vanaf verschillende kanten van het huis. Dat is een van de sterkste argumenten om standaard te blijven: de modellen zijn gebouwd om elkaar te ontmoeten.

Bestanden en bijlagen

Section titled “Bestanden en bijlagen ”

Niet alles op een record is een veld. Contracten, foto’s, pdf’s en spreadsheets zijn bestanden, en die horen in Salesforce Files, niet in het oude Attachments-model, dat legacy is. Als het document al in SharePoint Online, OneDrive, Google Drive of Box staat, laat Files Connect gebruikers er vanuit Salesforce bij zonder het naar binnen te kopiëren.

Bestanden worden anders geteld dan records. Salesforce splitst opslag in tweeën: bestandsopslag (file storage) bevat bijlagen, Files, Salesforce CRM Content, Chatter-bestanden en dergelijke, en dataopslag (data storage) bevat je records. Bestandsopslag loopt snel op als elk record foto’s of scans krijgt, dus grote hoeveelheden afbeeldingen, zoals de foto’s uit een buitendienstapp, horen vaak helemaal buiten Salesforce, met alleen een link in Salesforce. Module 4 komt daarop terug.

Twee kolommen of tweehonderd

Section titled “Twee kolommen of tweehonderd ”

Dataopslag wordt ook anders geteld dan in een database. In een normale database is een tabel met twee kolommen en een miljoen rijen klein, en een tabel met honderd kolommen en een miljoen rijen een olifant. Salesforce weegt ze hetzelfde: de meeste records tellen als ongeveer 2 KB, hoeveel velden ze ook hebben. Er zijn uitzonderingen. Een campagne telt zwaarder, een e-mailbericht telt op zijn echte grootte, en een persoonsaccount telt als ongeveer 4 KB, omdat het een account én een contactpersoon is.

Een tip. Als ik een nieuwe org binnenstap, is een van de eerste plekken waar ik naartoe ga Setup → Storage Usage (opslaggebruik). Ik vraag een klant zelfs om een screenshot in het eerste gesprek. Dat scherm liegt niet. Het vertelt je welke objecten groeien, en welke al de olifanten zijn.

Persoonsaccounts: als de klant een persoon is

Section titled “Persoonsaccounts: als de klant een persoon is ”

Het model van account en contactpersoon werkt prachtig voor een bedrijf en de mensen die er werken. Maar wat als je klant geen bedrijf is? Wat als het een persoon is?

Dat is het persoonsaccount: een account en een contactpersoon samengevoegd in één record, voor individuele personen. Hun contactvelden komen mee, en de aangepaste verschijnen met een eigen achtervoegsel, __pc. Elk persoonsaccount telt mee voor zowel account- als contactopslag, omdat het eronder allebei is.

Eén waarschuwing voordat je ze aanzet: als persoonsaccounts eenmaal zijn ingeschakeld, kunnen ze niet meer worden uitgeschakeld. Dat is de omkeerbaarheidstest uit hoofdstuk 1 in zijn zuiverste vorm. In module 5 geef ik mijn standpunt over wanneer ze het waard zijn.

Wat een architect hier beslist

Section titled “Wat een architect hier beslist ”
  • Welke delen van de business Salesforce al gemodelleerd heeft, voordat er iets nieuws wordt ontworpen.
  • Of een concept in het salesmodel, het servicemodel of allebei terechtkomt, wetende dat ze het account en de contactpersoon delen.
  • Waar documenten en afbeeldingen staan: Salesforce Files, een gekoppeld bestandssysteem, of buiten het platform met een link.
  • Wat de data aan opslag gaat kosten, geteld zoals Salesforce het telt: records, geen kolommen.
  • Of de klant een bedrijf of een persoon is, voordat je iets aanzet dat niet meer uit kan.

En als Salesforce niet heeft wat je nodig hebt? Dan bouw je het. Dat is de volgende stap.

Verder lezen

Section titled “Verder lezen ”