Ontwerp het fysieke Salesforce-model

🌐 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 10 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Gegevens consistent houden · Volgende: de studiegids bij het hoofdstuk, dan het volgende hoofdstuk, Enterprisegegevens begrijpen

De vraag die deze module beantwoordt: Hoe zetten we ons logische model om in een Salesforce-architectuur?

Dit hoofdstuk is één lang betoog geweest dat het platform een vorm heeft: standaard- en aangepaste objecten, plekken waar data kan staan, veldtypen, relaties, eigenaarschap, licenties, consistentieregels, opslag en schaal. Elk ervan kan veranderen hoe het logische model uit hoofdstuk 2 gebouwd wordt. Laten we het nu samenvoegen op één uitsnede van Steve Trucking.

Eén uitsnede, niet het hele bedrijf. Een fout die ik architecten zie maken, is proberen de hele organisatie in één diagram op te lossen. Ik wil iets waarover we kunnen redeneren: een retailpartner stuurt een vrachtlijst, Steve Trucking levert wat erop staat, en we bewaren wat we over elke levering nodig hebben. Dan nemen we de fysieke beslissingen een voor een. Het volledige ontwerp is het checkpoint van deel 1.

Begin bij wat we al weten

Hoofdstuk 2 deed het conceptuele werk: retailpartner, ontvanger, vrachtlijst, levering, leveringsitem, het soort stop, bezorgploeg, vrachtwagen, distributiecentrum, foto’s. We gaven de relaties namen en vroegen wat ze betekenen. Dat herhaal ik niet. De vraag is nu hoe die concepten op Salesforce leven. Eén feit uit de briefing doet er meteen toe: Steve Trucking gebruikt al Field Service voor afspraken, ploegen en de mobiele app.

Retailpartner: verzin geen account

Een retailpartner is een bedrijf waarvoor Steve Trucking werkt. Salesforce heeft al een object dat voor bedrijven ontworpen is: Account. Schone fit. Dus geen Retail_Partner__c alleen omdat de business “partner” zegt. Het is een account, met een recordtype Retail Partner om het te onderscheiden van andere organisaties, en daarmee komen contracten, cases, contactpersonen voor de DC-managers, en portaaltoegang voor die contactpersonen. Makkelijke beslissing. Niet alle beslissingen zijn dat.

Het ordernummer van de partner is niet onze identiteit

Elke retailpartner stuurt zijn eigen referenties. De order van de ene partner ziet eruit als 8843119, die van een andere als A-984732. Die nummers doen ertoe, maar van wie zijn ze? Van de partner. Salesforce heeft een eigen record-ID, en de partner heeft de referentie die hij gebruikt als hij met ons praat. Beide kunnen bestaan; dat is “één ding, meerdere identificatoren” uit hoofdstuk 2.

De referentie van de partner wordt dus een externe ID die de integratie gebruikt om updates te koppelen. En omdat twee partners hetzelfde nummer kunnen gebruiken, is de identiteit de partner plus de referentie, niet de referentie alleen. Maak het nummer van een partner niet de universele identiteit van de levering omdat het als eerste binnenkwam, en laat een integratie niet elke keer een tekstveld doorzoeken als die een record moet vinden.

Levering: kijk naar het moederschip

Hier is het verleidelijk om Delivery__c te maken. De business zei “levering”, dus hebben we een object Delivery nodig. Dat is precies wat ik niet wil dat je als eerste doet. Kijk naar het moederschip, zoals we in module 2 deden. Wat heeft Salesforce al voor werk dat op een locatie wordt uitgevoerd, met een levenscyclus, items, planning en een ploeg in het veld? De Work Order (werkorder) van Field Service: Salesforce beschrijft die als field-servicewerk dat voor een klant moet worden uitgevoerd (WorkOrder (opens in a new tab), Engels). Het geplande bezoek met zijn tijdvak is de Service Appointment (serviceafspraak), en dat is wat de planning inplant en wat de app van de ploeg toont.

Dus Levering → werkorder. Niet omdat de woorden overeenkomen; dat doen ze niet. Maar omdat het gedrag overeenkomt met de platformmogelijkheid waarvoor we al betalen en die we willen gebruiken. Een standaardobject hoeft niet dezelfde woorden te gebruiken als de business. Het moet het concept correct weergeven.

Click to enlarge

Stap 1 van 4: het moederschip. Elke kaart is het bedrijfsconcept, met het Salesforce-object eronder.

Maar standaardobjecten hebben bagage

De andere helft: een werkorder is niet gratis. Ze brengt Field Service-licenties mee, eigen relaties, beveiligingsgedrag, verplichte velden, automatisering en een levenscyclus, en andere delen van het platform verwachten dat ze zich op een bepaalde manier gedraagt. We kiezen haar omdat de fit schoon is en we gebruiken wat eromheen gebouwd is. Als Steve Trucking niets van Field Service wilde en het model het proces bij elke stap tegenwerkte, zou ik het heroverwegen. De architectuur is de fit, niet het label.

Leveringsitems: volg het model

Zodra een levering een werkorder is, kijk dan naar de rest van dat model voordat je iets verzint. Een Work Order Line Item (werkorderregel) is een deeltaak op een werkorder (WorkOrderLineItem (opens in a new tab), Engels): de koelkast, de installatie, de afvoer. Dus Leveringsitem → werkorderregel. Merk op dat de eerste beslissing de tweede vormde. We kiezen niet voor elke entiteit los een object. Neem een model over, en begrijp de rest ervan voordat je er aangepaste structuren omheen bouwt.

Wat voor stop is dit?

Bij Steve Trucking is een stop alleen levering, levering met installatie, of levering met afvoer, en elk soort heeft zijn eigen duur, ploegvaardigheden en installatiechecklist. In hoofdstuk 2 besloten we dat dat een entiteit is, geen label. Field Service heeft er al een: Work Type (werktype), een sjabloon voor een soort werk dat op werkorders en regels kan worden toegepast (WorkType (opens in a new tab), Engels). Dus Soort stop → werktype. Ook weer niet omdat er iets bestaat dat Work Type heet, maar omdat het concept en het gedrag overeenkomen.

Click to enlarge

Stap 2 van 4: volg het model. Regels en Work Type komen mee met de Work Order.

Vrachtlijst: nu wil ik een aangepast object

Is er een standaardobject voor “de lijst van de partner voor dinsdag bij het DC Phoenix”? Niet echt, en ik ga het niet in een niet-verwant object proppen alleen om te kunnen zeggen dat we standaard bleven. Vrachtlijst → Manifest__c. Het is de eenheid van ontvangst: waar het vandaan kwam (een bestand, een API-batch), wanneer, de status en totalen, en, als een partner het op de dag zelf opnieuw stuurt, wat er vergeleken wordt. Elke regel op de vrachtlijst wordt een werkorder die ernaar terugverwijst.

Aangepast is geen falen. Het is wat het platform ons geeft als een concept geen schone standaardplek heeft. De fout is niet een aangepast object maken; het is er een maken zonder te controleren of het platform het concept al heeft.

Click to enlarge

Stap 3 van 4: het ene aangepaste object, waar geen standaardobject past.

Foto’s: dat Salesforce het kan opslaan, betekent niet dat het moet

“We willen de leveringsfoto’s in Salesforce.” Wat betekent “in Salesforce”? Gebruikers moeten ze vanuit Salesforce kunnen zien, ja. Betekent dat dat de beeldbestanden in de core-opslag moeten staan? Niet per se. Tel de nullen: ongeveer vier foto’s per levering, meer bij installaties, bij een miljoen leveringen per jaar, is vier tot vijf miljoen foto’s per jaar, en leveringen groeien 30% per jaar.

Mijn uitgangspunt dus: maak van de core-org geen gigantische fotobibliotheek omdat gebruikers toegang tot foto’s nodig hebben. De bestanden horen in opslag die voor dat volume gebouwd is, buiten de core, waarbij Salesforce bewaart wat het nodig heeft om ze te vinden en te tonen: een referentie, een aantal of een klein indexrecord per foto, en een vlag dat de verplichte installatiefoto’s compleet zijn. Toegang tot data en waar de data fysiek staat zijn twee verschillende vragen. Dat is module 4 die terugkomt.

Velden: maak de betekenis zichtbaar

De werkorder heeft velden nodig: de referentie van de partner, het bezorgtijdvak, het werkelijke bezorgtijdstip, de status, notities als “poortcode” of “hond in de tuin”. Ik maak er geen veldcatalogus van; dat deed module 6. Stel de vragen bij elk veld: wat het betekent, wie eigenaar is, of het verandert, of het een identificator is, een gecontroleerde woordenlijst, opgeslagen of afgeleid, gevoelig. De referentie van de partner is de externe ID, dus haar uniciteit is deel van het integratiecontract, niet alleen een vinkje. Het werkelijke bezorgtijdstip is een moment, dus Date/Time. De status stuurt gedrag, dus een gecontroleerde lijst, nooit vrije tekst. En leveringsnotities over iemands huis zijn persoonsgegevens, dus die worden geclassificeerd. Elk veld is terug te voeren op betekenis.

Relaties: verbind niet zomaar de blokken

Account naar werkorder, werkorder naar haar regels, vrachtlijst naar werkorder, werktype dat de stop beschrijft. Dan de vragen uit module 7 bij elke lijn: kan het child alleen bestaan, wie is eigenaar, erft de toegang, kan het verhuizen, wat gebeurt er bij verwijderen, hoeveel children kunnen zich opstapelen? Elke werkorder onder een handvol accounts van retailpartners betekent honderdduizenden children per parent: een skewvraag die we in deel 2 beantwoorden. En kijk bij de standaardrelaties van Field Service hoe Salesforce ze al gebouwd heeft in plaats van aan te nemen dat ze overeenkomen met wat wij zouden hebben ontworpen. Als je een standaardmodel overneemt, neem je de beslissingen over die Salesforce erin nam. Begrijp ze voordat je erop bouwt.

Eigenaarschap en de ontvanger: laat de standaard niet beslissen

Twee beslissingen die een standaardinstelling graag voor ons zou nemen.

Wie is eigenaar van een levering? Dat beantwoordden we in module 8, en het gaat rechtstreeks over naar de werkorder: eigenaarschap stuurt hier niemands toegang, dus de integratiegebruiker is eigenaar van de werkorders die hij aanmaakt. Planners zien die van hun distributiecentrum, ploegen die van hun routes, en elke retailpartner ziet de zijne via het portaal, allemaal via sharing, niet via eigenaarschap. De integratiegebruiker heeft geen rol en blijft buiten de openbare groepen die onze deelregels gebruiken, omdat hij bij 3.300 per dag binnen drie dagen over de 10.000 records gaat. En we schrijven op wat er gebeurt als die gebruiker ooit vervangen wordt.

Wat is de ontvanger? Een contactpersoon? Een persoonsaccount? Iets wat alleen op de levering bewaard wordt? Dat hangt ervan af of Steve Trucking überhaupt een relatie heeft met deze mensen (het zijn de klanten van de retailpartners), of de ene partner ooit die van een andere mag zien, hoe lang hun persoonsgegevens bewaard mogen worden, en de schaal: zo’n miljoen nieuwe ontvangers per jaar. Dat hebben we nog niet allemaal, en dat is prima. Soms is het juiste antwoord we weten nog niet genoeg. Schrijf de vraag op en ga de informatie halen; begraaf de onzekerheid niet in een aangepast object. We beantwoorden het bij het checkpoint van Deel 1, nadat hoofdstuk 4 tot en met 6 ons het beeld van de enterprise en de stamgegevens geven.

Consistentie: bescherm het model op de juiste laag

De ladder uit module 9 is van toepassing: de referentie van de partner is een externe ID, uniek, dus een opnieuw verstuurde vrachtlijst upsert in plaats van te dupliceren; de status is een beperkte lijst; het werkelijke bezorgtijdstip is pas verplicht als de status Delivered zegt; een installatiestop kan niet worden afgesloten zonder checklist en foto’s. Niet één gigantische flow. Elke regel op zijn eigen sport.

Waar elk stuk staat

Nog één ronde over de uitsnede, met de vraag uit module 4: waar staat elk stuk data? In mijn lesdeck is het één slide, logisch tegenover fysiek: de logische entiteiten uit hoofdstuk 2, en waar elk ervan fysiek terechtkomt: in de core, als sObject (__c als het aangepast is) of big object (__b), of buiten de core, als extern object (__x) of data die nooit in Salesforce komt.

• In de core, dagelijks mee gewerkt: het account, de werkorders en hun regels, de serviceafspraken, de werktypes, Manifest__c.
• In de core, gearchiveerd: leveringen ouder dan drie jaar verhuizen naar Delivery History, een big object, nog steeds beschikbaar voor claims, in de schuur.
• Verwezen: de eigen ordergegevens van de retailpartner blijven in het systeem van de partner; wij bewaren de referentie van de partner als externe ID, en bereiken de rest via een extern object of de integratie als iemand het nodig heeft.
• Buiten de core: de foto’s, in opslag die gebouwd is voor miljoenen afbeeldingen, met een link vanaf de werkorder.

Dat is het fysieke model: niet alleen welk object, maar welk thuis.

Kijk nu naar de hele uitsnede

• Retailpartner → account, met een recordtype Retail Partner; DC-managers als contactpersonen.
• Levering → werkorder van Field Service, ingepland via een serviceafspraak.
• Leveringsitem → werkorderregel.
• Soort stop → werktype.
• Vrachtlijst → aangepast Manifest__c.
• Referentie van de partner → externe ID op de werkorder, uniek per partner.
• Foto’s → buiten de core opgeslagen; Salesforce bewaart de referentie en de vlag voor compleetheid.
• Leveringshistorie → na drie jaar gearchiveerd naar een big object.
• Eigenaarschap → de integratiegebruiker, met toegang via sharing (module 8).
• Ontvanger → open, voor het checkpoint van Deel 1.

Click to enlarge

Stap 4 van 4: de hele uitsnede, in de core, gearchiveerd en buiten de core. Elke lijn is een lookup: Salesforce bouwde Field Service op lookups, en met het model nemen we die beslissingen over.

Het diagram is niet de architectuur

Ik kan je dat diagram geven, en het is niet genoeg. De architectuur is de redenering erachter. Waarom een account? Een bedrijf met een schone fit. Waarom een werkorder en niet Delivery__c? De levering gedraagt zich als veldwerk, en Field Service is er al. Waarom een aangepaste vrachtlijst? Geen schone standaardplek. Waarom zijn foto’s niet gewoon Files? Volume en de economie van opslag. Waarom een externe ID? Een ander systeem heeft over de grens heen een stabiele identiteit nodig. Waarom is de integratiegebruiker eigenaar van de werkorders? Eigenaarschap stuurt hier geen toegang, en zo blijft het audittrail eerlijk. Waarom staat de ontvanger nog open? We hebben nog niet genoeg vragen beantwoord. De lijnen zijn het resultaat; de beslissingen hebben ze voortgebracht.

Dit is dus de gewoonte die ik wil dat je uit hoofdstuk 3 meeneemt. Wijs naar iets in een fysiek model en vraag waarom? Waarom dit object, dit type, deze relatie, deze eigenaar, deze plek, deze regel? Je moet het antwoord kunnen terugvoeren: van configuratie, naar het fysieke model, naar het logische model, naar de bedrijfseis. Als je dat niet kunt, heeft iemand vanuit Setup ontworpen.

En je hebt vast gemerkt welke getallen we nog niet helemaal hebben uitgewerkt: leveringen per partner, regels, foto’s, bewaren, archiveren. Goed zo. Vraag naar het aantal nullen voordat je een ontwerp vastlegt: een model dat prachtig werkt bij vijftigduizend records kan zich bij vijfhonderd miljoen heel anders gedragen. Dat is deel 2.

Voorbij het examen: wat AI verandert. Geef een AI de briefing van Steve Trucking en het produceert in seconden een schema: account, werkorder, aangepaste objecten, velden, zelfs deploymentmetadata. Dat is een fantastische versneller, en het is niet de review. De taak van de architect verschuift naar het controleren van de vertalingen en hun gevolgen: fit, licenties, eigenaarschap, levenscyclus, schaal, identiteit, beveiliging en wat buiten het platform blijft. AI is de raketaanjager; het vertelt je niet of je de goede kant op wijst.

Wat een architect hier beslist

• Hoe elk bedrijfsconcept op Salesforce terechtkomt: een standaardobject, een aangepast object, of iets buiten de kern.
• Welke identificatoren, velden en relaties de bedrijfsbetekenis implementeren zonder haar stilletjes te veranderen.
• Welk platformgedrag en welke licenties meekomen met een standaardmodel dat je overneemt.
• Welke beslissingen over eigenaarschap, levenscyclus, consistentie, opslag en schaal genomen moeten worden voordat het ontwerp compleet is.
• Welke vragen expliciet open blijven, in plaats van verstopt achter een willekeurige implementatiekeuze.

Aan het begin van dit hoofdstuk vroegen we hoe het model op Salesforce moet leven. Dat is Salesforce-data-architectuur: niet objecten maken, niet Setup uit je hoofd leren, niet mooiere blokken tekenen, maar het bedrijfsmodel bewust laten passen bij de vorm van het platform. Elke structuur is een verplichting. Maak de verplichtingen die je kunt uitleggen.

Verder lezen

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) en WorkType (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• De briefing van Steve Trucking.