Blog · 14 september 2023 · Steve Simpson · Data-architectuur

Datamodellering met Steve: van keuzelijsten tot in de oneindigheid en verder

Inleiding:

Welkom bij weer een inzichtelijke sessie over datamodellering in Steves reeks over datamodellering! In deze blog verkennen we het veelzijdige gebruik van keuzelijsten en bespreken we scenario’s waarin je alternatieven moet overwegen voor geavanceerdere eisen aan datamodellering.

Keuzelijsten begrijpen

Keuzelijsten zijn ideaal als je een veld hebt dat een set vaste waarden vraagt. Ze bieden een nette gebruikerservaring, maar hebben een paar beperkingen:

Je hebt verhoogde beheerdersrechten nodig om waarden toe te voegen.
Nieuwe waarden moeten via sandboxes uitgerold worden.

Er ontstaan datavalidatiefouten als waarden uit integraties met derden niet vooraf in Salesforce toegevoegd zijn.

Opties voor keuzelijsten verkennen

Dit zijn een paar opties voor keuzelijsten om te overwegen:

Optie 1: globale waardesets

Dit is de standaardoptie van Salesforce en kan lijsten over objecten heen gebruiken.

Optie 1, keuzelijsten en globale waardesets. Voordeel: een nette gebruikerservaring. Nadelen: een admin moet waarden toevoegen, wijzigingen moeten naar sandboxes uitgerold worden, externe systemen veroorzaken problemen, en een waarde kan geen gerelateerde velden bevatten

Globale waardesets zijn het best voor waarden die op meerdere plekken gebruikt worden. Je kunt bijvoorbeeld twee globale waardesets hebben voor ‘buisdiameter’ en ‘wanddikte’, met een nette UI waarin gebruikers waarden kiezen.

[caption id="" align=“alignnone” width=“1372”] Voorbeelden van waardesets [/caption] [caption id="" align=“alignnone” width=“1814”] Voorbeeldwaarden [/caption] [caption id="" align=“alignnone” width=“676”] Kiezen uit een lijst [/caption]

Optie 2: tekstvelden

Dit is gewoon een tekstveld zonder validatie.

Optie 2, tekstvelden. Voordeel: ze nemen elke waarde aan. Nadelen: geen datavalidatie en een slechte gebruikerservaring

Als datawaarden via integraties binnengeduwd worden, kun je tekstvelden overwegen. Maar met deze aanpak verlies je validatie, waardoor gebruikers alle data kunnen invoeren, wat tot inconsistentie kan leiden.

Dit kan een optie zijn als de velden in Salesforce alleen-lezen zijn en je de waarden alleen toont.

[caption id="" align=“alignnone” width=“678”] Geen validatie [/caption]

Optie 3: gedeeld referentieobject

Optie 3, een gedeeld referentieobject met recordtypes, met lookups gefilterd op recordtype. Voordelen: data dynamisch toegevoegd en een paar gerelateerde velden. Nadelen: dataloads in sandboxes, en het bronobject bevat een sleutel in plaats van de waarde

Een gedeeld referentieobject met meerdere recordtypes kan gebruikt worden voor dataloads. Deze aanpak maakt twee lookups op het primaire object, die naar het referentieobject verwijzen in plaats van naar echte waarden. Je kunt ook dynamisch nieuwe waarden toevoegen zonder beheerdersrechten, wat de flexibiliteit vergroot.

[caption id="" align=“alignnone” width=“1462”] Recordtypes gebruiken [/caption] [caption id="" align=“alignnone” width=“1700”] Gebruik een gefilterde lookup [/caption] [caption id="" align=“alignnone” width=“1434”] Waarden toevoegen [/caption] [caption id="" align=“alignnone” width=“658”] Zo ziet het kiezen van een waarde eruit. De sortering klopt niet en bij het eerste laden worden niet alle waarden getoond; de gebruiker moet ernaar zoeken. Zorg er ook voor dat je “Create” uit profielen en machtigingensets haalt, zodat gebruikers niet zomaar meer records aanmaken. [/caption]

Deel 3: geavanceerde opties

Overweeg voor geavanceerdere scenario’s deze opties:

Optie 4: aangepaste schermen met een referentieobject

Optie 4, een referentieobject plus een tekstveld, met een Lightning web component die de keuzelijstwaarden uit het referentieobject leest. Voordelen: data dynamisch toegevoegd en het bronobject bewaart de waarden. Nadeel: vraagt LWC-ontwikkeling en aangepaste pagina's

Als je aangepaste Lightning Web Components (LWC’s) gebruikt voor je bewerkschermen, kun je een referentieobject gebruiken om waarden te lezen en weer te geven, en de echte waarden opslaan in plaats van lookups.

Optie 5: losse objecten

Optie 5, losse referentieobjecten, één per lijst. Voordelen: data dynamisch toegevoegd, een schoon datamodel en veel gerelateerde velden. Nadelen: dataloads in sandboxes, sleutels in plaats van waarden, en veel objecten

Als lookupwaarden belangrijker worden, overweeg dan voor elke waarde een los object te maken met aparte lookups. Deze aanpak maakt dynamisch toevoegen van data mogelijk, houdt het datamodel schoon, en ondersteunt extra gerelateerde velden op elk object.

Praktische voorbeelden

Dit zijn praktische voorbeelden bij elke optie:

Standaardkeuzelijsten: Bieden een nette UI met vaste waarden.

Tekstvelden zonder validatie: Bieden flexibiliteit, maar geen datavalidatie.

Lookup naar referentieobjecten: Gebruikt hetzelfde object met gefilterde recordtypes voor flexibiliteit.

Losse objecten: Gebruikt aparte objecten voor elke lookup, met een schoon en flexibel datamodel.

Conclusie

De nuances van keuzelijsten en hun alternatieven begrijpen is cruciaal voor effectieve datamodellering. Van standaardkeuzelijsten tot losse objecten: elke optie biedt eigen voordelen voor specifieke behoeften in datamodellering.

Kom snel terug!

Voor meer inzichten en tips: blijf op de hoogte hier op www.SteveTechArc.com en via het YouTube-kanaal @SteveTechArc (opens in a new tab). Abonneer je en word samen met ons nog beter in datamodellering!

De wereld helpen veranderen door mooie gedachten te delen met collega-architecten en met iedereen die op weg is om architect te worden!

Transcript met hulp van AI

STA 2.2