Velden zijn ook 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

Module 6 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Kies het juiste object · Volgende: Relaties hebben gevolgen

De vraag die deze module beantwoordt: Hoe moet Salesforce elk stukje data fysiek weergeven?

Een veld maken kost ongeveer een minuut. New Field, kies een type, geef het een naam, Next, Next, Save. Precies daarom worden velden niet als architectuur behandeld.

Ga een org in die al tien jaar bestaat en open Account. Vijfhonderd velden. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Drie verschillende klantnummers. Een selectievakje dat niemand durft te verwijderen omdat niemand weet welke integratie het nog gebruikt. Het veld maken kostte een minuut. Ermee leven kost jaren. Het idee van deze module is dus simpel: een veld is een architectuurbeslissing. Niet altijd een grote, maar elk veld legt iets vast over de betekenis, het gedrag, de identiteit of de kwaliteit van de data, en net als objecten zijn velden makkelijk toe te voegen en verrassend moeilijk weg te halen.

Wat betekent deze data eigenlijk?

In hoofdstuk 2 gaven we onze entiteiten attributen: een levering heeft een gepland tijdvak, een vrachtwagen heeft een VIN. Nu implementeren we ze, en hier springen mensen meteen naar “tekstveld”. Wacht. Vóór het type wil ik weten wat de data betekent. Is het een getal, of een identificator die toevallig cijfers bevat? Een datum, of een moment in de tijd? Vrije tekst, of een waarde uit een goedgekeurde reeks? Ingevoerd door een persoon, of eigendom van een ander systeem? Kan het veranderen? Moet het uniek zijn? Kan het ontbreken? Moet het überhaupt opgeslagen worden, of berekend? Dat zijn geen Setup-vragen. Het zijn data-architectuurvragen, en het veldtype komt nadat we ze beantwoord hebben.

Een getal is niet altijd een getal

Steve Trucking geeft elke vrachtwagen een vlootnummer, zeg 001247. Getalveld? Waarschijnlijk niet. Tellen we vlootnummers bij elkaar op? Is vrachtwagen 1247 min vrachtwagen 1246 één vrachtwagen? Het is een identificator die toevallig cijfers bevat, en een getalveld zou zelfs de voorloopnullen laten vallen. Hetzelfde geldt voor postcodes, productcodes, rekeningnummers en trackingnummers. Hoe de waarde eruitziet, zegt niet wat ze betekent. Kies het type op het gedrag dat je nodig hebt, niet op hoe de voorbeelddata eruitziet.

Moet een mens het kunnen herkennen?

Elk aangepast object krijgt een veld Name, en de eerste beslissing is tekst of automatisch nummer. Ik vraag: moet een mens dit ding kunnen herkennen? Mensen kennen een retailpartner aan zijn naam en een vrachtwagen aan zijn vlootnummer. Maar een vrachtlijst die het systeem elke nacht genereert? Niemand zou “Vrachtlijst 10-02 nummer 3” moeten typen omdat Salesforce een Name eiste. Geef het een automatisch nummer. Verwar die gegenereerde Name alleen niet met de identiteit van het record: het automatische nummer helpt gebruikers, de Salesforce-ID identificeert het record, en de eigen vrachtlijstreferentie van de retailpartner identificeert misschien hetzelfde ding over systemen heen. Drie verschillende taken.

Het detailscherm

Kies een type, klik op Next, en Setup vraagt om de details. Dit is het scherm waar de meeste beslissingen uit deze module echt genomen worden, meestal in een haast.

New Custom Field, stap 2: de details (screenshot, 12 oktober 2026). Volledige grootte

Twee vakken lijken op elkaar en doen iets anders. Description (omschrijving) is voor de mensen die de org onderhouden, en nu ook voor de AI-tools die hem lezen: wat het veld betekent, wie eigenaar is, waar het vandaan komt. Help Text (helptekst) is voor de gebruiker op het scherm: wat je hier invult. Vul ze allebei in. Dan komen Required, Unique en External ID, en die verdienen elk een eigen sectie. Daaronder kan Default Value (standaardwaarde) een formule zijn, zodat een nieuw record met een zinnige waarde kan beginnen in plaats van leeg.

Verplicht is een grotere beslissing dan het lijkt

Er is een klein vakje in de veldwizard met het label Required (verplicht), en zoals we in hoofdstuk 1 zagen, kan dat een tijdbom zijn. Je hebt een object al vijf jaar en twee miljoen records, en nu besluit iemand dat een nieuw veld altijd een waarde moet hebben. Hoe zit het met de twee miljoen records van daarvoor? De integraties die het niet sturen? De automatisering die het record maakt voordat de waarde bekend is? Het proces waarin de waarde pas drie stappen later opduikt?

“Verplicht” klinkt als een beslissing over datakwaliteit, en soms is het dat ook. Maar wanneer een waarde bekend wordt, is deel van het bedrijfsproces. Vink Verplicht dus niet aan omdat iemand zegt “dat willen we altijd”. Vraag wanneer het bekend is, wie het levert, en wat er gebeurt als het er niet is. In module 7 zetten we dit op de volledige consistentieladder.

Uniek betekent ook iets

Als ik een veld uniek maak, doe ik een uitspraak over de business: niet “het komt meestal niet dubbel voor”, maar “twee records mogen nooit deze waarde hebben”. Dat is sterk. En het scherm laat je nog één ding beslissen: zijn “ABC” en “abc” dezelfde waarde of verschillende? Niet hoofdlettergevoelig is de veiligere standaard voor alles wat een mens typt. De sleutelregel uit hoofdstuk 2, uniek, onveranderlijk, betekenisloos, nooit persoonsgegevens, geldt hier. Als iemand me vertelt dat het e-mailadres van een medewerker uniek is, begin ik te vragen: kan het veranderen, kan iemand vertrekken en terugkomen, kunnen adressen hergebruikt worden, wat gebeurt er na een overname? E-mail kan nuttig zijn, vandaag zelfs uniek. Dat maakt het nog geen goede identiteit.

Externe ID’s: identiteit over de grens heen

Hier bewijzen externe ID’s hun waarde. Het scherm beschrijft het goed: het veld wordt “the unique record identifier from an external system” (de unieke record-ID uit een extern systeem). Het ERP heeft klant 873492; Salesforce heeft zijn eigen record-ID. Als het ERP een update stuurt, hoe weten we dan bij welk record die hoort? Markeer een veld als External ID en een integratie kan erop upserten: het record aanmaken als het niet bestaat, bijwerken als het wel bestaat (Upsert a Record Using an External ID (opens in a new tab), Engels). En als je child-records laadt, kun je naar de parent verwijzen met zijn externe ID in plaats van eerst de Salesforce-ID op te vragen. Ik zeg graag dat je Salesforce het opzoekwerk voor je laat doen. Heel krachtig.

Merk op dat het nummer van het ERP niet de identiteit van het Salesforce-record wordt. Het is een attribuut, en een record kan er meerdere dragen: een klant-ID uit het ERP, een oude ID, de ID van een partner. Dat is prima. Eén bedrijfsentiteit kan door meerdere systemen verschillend gekend worden. De architectuurvraag is welk systeem eigenaar is van elke identificator, en welke belofte die doet: markeer hem alleen als uniek als de business dat echt garandeert.

Veldtype voor veldtype

Nu de types zelf. Open New Field op een willekeurig object en Setup toont je de hele lijst, gegroepeerd zoals ik ze ga doorlopen: de velden die Salesforce voor je berekent, de relatievelden, en dan de datatypes.

Setup, New Custom Field, stap 1: de datatypes (screenshot, 12 oktober 2026). Volledige grootte

Hier is de hele lijst in één oogopslag, met het ene ding dat ik je van elk type wil laten onthouden.

Groep	Type	Onthoud
Berekend	Automatisch nummer (Auto Number)	Tot 30 tekens, waarvan 20 voor voor- of achtervoegsel; een label voor mensen, niet de identiteit van het record
	Formule	Berekend bij het lezen, niet opgeslagen; 3.900 tekens
	Samenvattingsveld (Roll-Up Summary)	Aantal, som, minimum of maximum van de details; alleen bij hoofd-detail
Relaties	Opzoekrelatie, hoofd-detail, externe opzoekrelatie	Module 7
Data	Selectievakje (Checkbox)	Waar of onwaar, met een standaardwaarde die jij kiest; in flows kan toch null opduiken
	Getal, percentage, valuta	Afrondingsregels; voorloopnullen vallen weg; 15 decimalen
	Datum, datum/tijd, tijd	Een dag, een moment of een tijdstip; momenten worden in UTC opgeslagen
	E-mail, telefoon, URL	Opgemaakt en gecontroleerd bij opslaan: 80, 40 en 255 tekens
	Geolocatie, adres	Samengestelde velden die meer dan één veld kosten: 3 en 9
	Keuzelijst, meervoudige keuzelijst	Een gecontroleerd vocabulaire, beheerd door een admin
	Tekst, tekstgebied, lang, opgemaakt, versleuteld	Tot 255 op het record en indexeerbaar; daarboven geen index en geen filtering

De velden die Salesforce berekent

Automatisch nummer (Auto Number) geeft elk nieuw record het volgende nummer in een reeks, in een formaat dat jij bepaalt, zoals T-{000000}. Gebruik het als een mens een handig houvast nodig heeft en niemand er een zou moeten verzinnen. De hele waarde is maximaal 30 tekens, en 20 daarvan zijn gereserveerd voor het voor- of achtervoegsel. Onthoud wel uit hoofdstuk 2: het is een label voor mensen, niet de identiteit van het record, en de nummers lopen niet altijd strikt op.

Formulevelden (Formula) berekenen een waarde uit andere velden. Ze zijn krachtig, en ze worden berekend als het record gelezen wordt, niet als het opgeslagen wordt, dus er is niets opgeslagen dat kan verouderen. Jij kiest wat de formule teruggeeft: een selectievakje, valuta, datum, datum/tijd, getal, percentage, tekst of tijd.

New Custom Field, formule: het retourtype kiezen (screenshot, 12 oktober 2026). Volledige grootte

Dan schrijf je de formule zelf, met velden, operatoren en functies, en controleer je de syntaxis. Let op de knop Use Formula Assistant: de AI van Salesforce helpt je nu de formule te schrijven. Gebruik hem, en lees daarna wat hij schreef. Jij bent eigenaar van de formule, niet de assistent.

De formule-editor, met de Formula Assistant (screenshot, 12 oktober 2026). Volledige grootte Een formule mag maximaal 3.900 tekens lang zijn, en mag bij opslaan of compileren niet groter zijn dan 15.000 bytes; een lange formule kun je opsplitsen over meerdere formulevelden die naar elkaar verwijzen. Lange tekstgebieden, versleutelde velden en omschrijvingsvelden kun je er niet in gebruiken.

Samenvattingsvelden (Roll-Up Summary) staan op de master en tellen, sommeren of nemen het minimum of maximum van de detailrecords. Ze werken alleen over een hoofd-detailrelatie (master-detail), en dat is een van de grootste redenen om überhaupt voor hoofd-detail te kiezen. In module 7 komen we erop terug, en op hun grenzen.

Opgeslagen of afgeleid?

Moeten we deze waarde überhaupt opslaan? Als ik aantal en stukprijs heb, moet iemand, of een automatisering, dan een totaal bijhouden? Misschien moet een formule het afleiden: één bron voor de berekening, opnieuw berekend bij het lezen, dus verander het aantal en het antwoord volgt. Formules hebben hun eigen limieten (opslaggrootte en getoonde lengte; Formula Field Limits and Restrictions (opens in a new tab), Engels), en ingewikkelde formules worden lastig te onderhouden.

Maar soms wil de business niet het antwoord van vandaag. Ze wil het antwoord zoals het was. Als de kortingsregel volgend jaar verandert, moet de factuur van vorig jaar dan ineens een ander bedrag tonen? Natuurlijk niet. De vraag is dus niet “kan Salesforce dit berekenen?” Het is “is dit een actuele berekening of een historisch feit?” Historische feiten worden opgeslagen.

De relatievelden

Lookup-, Master-Detail- en External Lookup-relaties zijn ook velden, en daar worden de lijnen van je model echt. De opzoekrelatie is de losse koppeling; hoofd-detail verbindt het leven, het eigenaarschap en de beveiliging van het child aan de parent; de externe opzoekrelatie bereikt een extern object uit module 4 en matcht op zijn External ID. Kiezen tussen die drie is een beslissing die groot genoeg is voor een eigen module.

Selectievakje

Een selectievakje (checkbox) is het eenvoudigste veld dat er is: waar of onwaar, aangevinkt of niet. Perfect voor een ja/nee-feit over het record: Is Active, Install Required, Signed For. Als je er een maakt, laat Salesforce je de standaardwaarde kiezen, aangevinkt of niet, en dat is een echte beslissing: daarmee begint elk nieuw record, ook records die een integratie maakt zonder het veld mee te sturen. Rapporten en lijstweergaven filteren het als True en False; de importtools en de wekelijkse export tonen het als 1 en 0.

Eén valkuil om te kennen. Het veld op het record heeft twee waarden, maar de automatisering eromheen kan er een derde hebben. In een flow is een checkbox-variabele die nooit gezet is null, niet false, en die opslaan in een record mislukt (Trailblazer Community (opens in a new tab), Engels; zie ook de bekende Salesforce-issue W-11208535 (opens in a new tab)). Kies een zinnige standaardwaarde, en laat je flows en code bewust met null omgaan.

Getal, percentage en valuta

Number (getal) slaat een echt getal op en laat voorloopnullen vallen, en precies daarom is een vlootnummer als 001247 geen getal. Salesforce rondt getalvelden af van nul af bij een half: 12,345 wordt 12,35, en −12,345 wordt −12,35. En in samenvoegvelden rondt het af volgens de landinstelling van de gebruiker, niet op het aantal decimalen dat je op het veld instelde.

Percent (percentage) slaat een decimaal getal op en toont een percentage: voer 0,10 in en je ziet 10%. Na 15 decimalen gaat precisie verloren.

Currency (valuta) is opgemaakt voor geld, en in een org met meerdere valuta’s draagt het zijn valutacode mee en kan het wisselkoersen gebruiken; met advanced currency management (opens in a new tab) (geavanceerd valutabeheer) kunnen verkoopkansen gedateerde wisselkoersen gebruiken, de koers van de periode waarin de deal gesloten werd. Alleen verkoopkansen en wat eromheen hangt (producten, schema’s, splits en hun rapporten) gebruiken gedateerde koersen; valutavelden op andere objecten houden de ene vaste koers. Let op de afronding: zonder decimalen kapt Salesforce gewoon af (23,5 wordt 23); met een of meer decimalen rondt het van nul af bij een half.

Datum, datum/tijd en tijd

Drie types, drie verschillende betekenissen. Een Date (datum) is een dag: een contract verloopt op een datum. Een Date/Time (datum/tijd) is een moment: de levering kwam die ochtend om 9.42 uur aan. Een Time (tijd) is een tijdstip zonder datum: de winkel gaat om 7.00 uur open, elke dag.

De valkuil zit in het moment. Salesforce slaat datum/tijd-waarden op in GMT (UTC). De tijd die een gebruiker typt, wordt gelezen in zijn tijdzone, omgerekend en opgeslagen; als iemand hem leest, wordt hij weer omgerekend naar de tijdzone van de lezer. Meestal is dat precies wat je wilt. Maar dit is het voorbeeld dat ik in de klas geef: een coördinator in Los Angeles registreert een levering laat op zondagavond, om 22.00 uur Pacific-tijd. Onderliggend heeft Salesforce maandagochtend opgeslagen, 05.00 uur GMT. Een rapport gegroepeerd per dag in een andere tijdzone, of een integratie die de ruwe waarde leest, kan die zondaglevering op maandag zetten. “De dag waarop het gebeurde” hangt af van wiens klok je het vraagt. Let op de tijdzones van de gebruikers, en beslis welke de business bedoelt.

En wees voorzichtig als je ze vergelijkt. Onderliggend is een datum/tijd één groot getal: Apex leest het als het aantal milliseconden sinds 1 januari 1970, 00:00:00 GMT (Datetime Class (opens in a new tab), Engels). Het is een precies moment, geen dag. Vragen of twee datum/tijden gelijk zijn (==) doet dus bijna nooit wat je wilt: 9:42:00 en 9:42:01 zijn niet gelijk, en “maandag” en een willekeurig moment op maandag ook niet. Vraag in plaats daarvan om een bereik: op of na het begin (>=) en op of vóór het einde (<=). “Elke levering op maandag” is elke levering >= maandag 00:00 en <= maandag 23:59:59, in de tijdzone waarvan je besloot dat de business die bedoelt.

En een leuke: Salesforce kan niet zomaar elke datum opslaan. Geldige datums lopen van 1 januari 1700 tot en met 31 december 4000, en Salesforce geeft hetzelfde bereik voor datums en datum/tijden (Data Import Dates (opens in a new tab), Engels). Zelfs de randen zijn momenten in GMT, dus voor een gebruiker in Pacific-tijd is de vroegste geldige waarde 16.00 uur op 31 december 1699. De oprichtingsdatum van je historische vereniging past er misschien niet in. En de klassieke truc voor “geen einddatum”, 31 december 9999, wordt geweigerd; heb je een plaatshouder ver in de toekomst nodig, dan moet die in het jaar 4000 of eerder liggen.

E-mail, telefoon en URL

Dit zijn de opgemaakte velden, en ze doen meer dan tekens opslaan. Email bevat tot 80 tekens en wordt gecontroleerd op een correct formaat; bij contactpersonen en leads start een klik erop een e-mail naar dat adres. Phone bevat tot 40 tekens, wordt opgemaakt als telefoonnummer en wordt click-to-dial (klikken om te bellen) als de org een telefoonsysteem gekoppeld heeft. URL bevat tot 255 tekens en opent als link. Dat is het platform dat je gratis gedrag geeft, en daarom zou ik een telefoonnummer nooit in een gewoon tekstveld opslaan.

Ook integraties worden gecontroleerd. Een waarde die niet past bij het formaat van het veld, zoals een slecht gevormd e-mailadres, faalt op de validatie, en het hele record wordt geweigerd, niet alleen dat veld. Dus als de data in het bronsysteem rommelig is, maak die dan schoon voordat ze aankomt, of houd rekening met de records die niet laden.

Geolocatie en adres

Geolocation (geolocatie) bevat een breedte- en een lengtegraad. Onderliggend is een veld met de naam Location__c eigenlijk twee waarden die je los kunt lezen en zetten, Location__Latitude__s en Location__Longitude__s. En je kunt erop zoeken: de SOQL-functies DISTANCE en GEOLOCATION vinden records binnen een straal, of sorteren ze op afstand. “Elke open levering binnen 25 mijl van deze vrachtwagen” is één query: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), Engels). Address (adres) bevat een heel adres, straat, plaats, staat of provincie, postcode en land, en gebruikers kunnen een adres opzoeken en de onderdelen laten invullen.

Beide zijn samengestelde velden (compound fields): één veld op het scherm, meerdere eronder. En ze tellen voor meer dan één veld mee in de limiet van je object: een geolocatie telt als drie aangepaste velden, een adres als negen. Op een object dat al vol zit, maakt dat uit.

Keuzelijst en meervoudige keuzelijst

Een keuzelijst (picklist) bepaalt wat gebruikers kunnen invoeren: één waarde uit een lijst die jij definieert. Status? Keuzelijst, waarschijnlijk. Maar de waarden zijn metadata, en een admin moet ze toevoegen of wijzigen. Dus vraag ik nog steeds wie eigenaar is van de waarden, hoe vaak ze veranderen, of meerdere objecten dezelfde lijst nodig hebben, of de waarden zelf informatie dragen, en of een ander systeem eigenaar is van het vocabulaire.

Waar de waarden staan, is ook een beslissing. Als een lijst één keer gebruikt wordt, op één veld, houd de waarden dan op het veld zelf, op het object; dat doet Salesforce standaard. Maar als dezelfde reeks waarden op meerdere plekken opduikt, een regio op het account, op de levering en op het magazijn, promoveer hem dan tot een globale waardeset voordat de kopieën uit elkaar groeien. Een globale waardeset houdt één lijst voor allemaal bij, tot 1.000 waarden, actief en inactief samen (Picklist Limitations (opens in a new tab), Engels). De eigen omschrijving van Setup zegt waarom dat ertoe doet: de waardeset “is restricted so users can’t add unapproved values through the API” (is beperkt, zodat gebruikers via de API geen niet-goedgekeurde waarden kunnen toevoegen). Eén lijst, één eigenaar, en geen integratie die stiekem een nieuwe spelling binnensmokkelt.

Dat laatste punt is het verschil tussen beperkt (restricted) en onbeperkt (unrestricted). Op een beperkte keuzelijst zijn alleen de waarden toegestaan die een admin heeft gedefinieerd, van waar dan ook: een gebruiker, een import of een integratie die iets anders stuurt, krijgt een foutmelding, “bad value for restricted picklist field”, en het record wordt niet opgeslagen. Op een onbeperkte keuzelijst kiezen gebruikers op het scherm nog steeds uit de lijst, maar de API, imports en automatisering kunnen elke waarde sturen, en Salesforce slaat die op en voegt hem toe als inactieve waarde (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), Engels). Zo eindigt een org met “Delivered”, “delivered” en “Dlvrd”. Globale waardesets zijn altijd beperkt. Mijn standaard is beperkt; onbeperkt is een bewuste keuze voor als een ander systeem echt eigenaar is van de waarden, en dan is iemand eigenaar van het opruimen van de inactieve waarden.

Setup, Picklist Value Sets: een nieuwe globale waardeset (screenshot, 12 oktober 2026). Volledige grootte

Met een meervoudige keuzelijst (multi-select picklist) kan een gebruiker meerdere waarden kiezen, samen opgeslagen en gescheiden door puntkomma’s. Handig op een scherm, onhandig overal elders: moeilijker om op te filteren, te rapporteren en te integreren, en je kunt hem niet gebruiken in het filter van een samenvattingsveld. Meerdere waarden voor één record betekenen meestal de les uit hoofdstuk 2: er probeert een child-object naar buiten te komen.

Een keuzelijst heeft ook één waarde meer dan de waarden die jij definieerde: leeg. Een record kan zonder selectie blijven staan, en daar trappen mensen in. In een formule of validatieregel kun je een keuzelijst niet alleen met ISBLANK testen; je schrijft ISBLANK(TEXT(Field__c)), of ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), Engels). Beslis dus voor elke keuzelijst wat “geen waarde” betekent: is het toegestaan, en wat betekent het als het gebeurt? Laat je formules, validatieregels en filters er dan mee omgaan.

En soms is een attribuut eigenlijk een entiteit. Iemand vraagt om een keuzelijst met distributiecentra. Het zijn er negen. Makkelijk. Dan horen we dat elk een adres heeft, een manager, openingstijden, capaciteit, een regio en vrachtwagens. Dat is geen keuzelijst; dat is een ding. Maak van een entiteit geen keuzelijst alleen omdat er nog niet veel van zijn. In jaar één voelt het geweldig en in jaar vijf verschrikkelijk. (Module 5 van hoofdstuk 2 heeft mijn vuistregels voor wanneer een lijst een eigen object verdient.)

De tekstfamilie

Ik leer tekst als twee soorten, en de grens ertussen ligt bij 255 tekens.

Tot 255: opgeslagen bij het record. Text (tekst) bevat tot 255 tekens, en je kunt het bijna overal gebruiken: in formules, filters, rapporten, lijstweergaven, als uniek veld of externe ID, en het kan geïndexeerd worden. Text Area (tekstgebied) bevat ook 255 tekens, op aparte regels, zoals een korte notitie.

Boven 255: opgeslagen via een verwijzing. Text Area (Long) (lang tekstgebied) bevat tot 131.072 tekens, en Text Area (Rich) (opgemaakt tekstgebied) bevat hetzelfde met opmaak, links en afbeeldingen. Ik zie ze als opgeslagen aan de zijkant, met een verwijzing in het record, en zo gedragen ze zich ook: geen index, dus je kunt ze niet uniek of externe ID maken; je kunt er niet op filteren in een SOQL-WHERE-clausule (SOQL WHERE (opens in a new tab), Engels); formules kunnen ze niet gebruiken (Formula Field Limits and Restrictions (opens in a new tab)); en rapporten tonen alleen de eerste 254 tekens van een aangepast exemplaar, waarbij rapportfilters alleen ongeveer de eerste 255 doorzoeken (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Afbeeldingen die in een opgemaakt tekstveld geüpload worden, mogen elk tot 1 MB zijn, en die tellen mee voor bestandsopslag, terwijl de tekst meetelt voor dataopslag (Rich Text Area Field Considerations (opens in a new tab)). Dus als iemand op de waarde moet zoeken, sorteren, matchen of rapporteren, houd hem dan onder de 255 en houd het een tekstveld.

Text (Encrypted) (versleutelde tekst) slaat tot 175 tekens versleuteld op, met Classic Encryption. Als je org Shield Platform Encryption gebruikt, versleutel je in plaats daarvan een gewoon tekstveld, en veel andere types kunnen ook op die manier versleuteld worden.

Geef elk veld een omschrijving

Mijn standaard: elk veld krijgt een omschrijving. Dat vind ik al heel lang, en in het tijdperk van AI doet het er meer toe dan ooit: elke AI-tool en elke agent die je org leest, leest de omschrijvingen om te begrijpen wat een veld betekent. Een lege omschrijving is een gok die erop wacht te gebeuren. Wat betekent Customer_Status__c? Wie is eigenaar? Waar komt het vandaan? Kunnen gebruikers het bewerken, of overschrijft het ERP het vannacht? Over zes maanden weet ik het niet meer, en over drie jaar weet de admin die de org onderhoudt het niet, tenzij we het vertelden. Het label is geen documentatie, en de API-naam ook niet.

Op veelgedeelde objecten (Account, Contact, Opportunity) gebruik ik ook naamvoorvoegsels voor gespecialiseerde velden, zodat hun herkomst en doel in de naam zelf zichtbaar zijn: alles waarvan het ERP eigenaar is begint met hetzelfde voorvoegsel, bijvoorbeeld. Ik ben niet uit op API-namen van twaalf woorden. Ik wil dat het model zichzelf uitlegt.

Classificeer wat ertoe doet: de taxonomievelden

Salesforce geeft elk veld een reeks classificatiemetadata. Ik noem ze de taxonomievelden. Je kunt de data-eigenaar vastleggen; het veldgebruik (Active, DeprecateCandidate, Hidden); het gevoeligheidsniveau (Public, Internal, Confidential, Restricted, MissionCritical); en de compliancecategorie: PII, HIPAA, GDPR, PCI, CCPA en andere. Ze werken op standaardvelden net zo goed als op aangepaste (Data Classification Metadata Fields (opens in a new tab), Engels).

Waarom de moeite? Omdat processen ze kunnen lezen. Markeer een veld als GDPR en een proces kan elk GDPR-veld op een record vinden en maskeren of verwijderen. En als de trust layer van Salesforce een prompt naar een groot taalmodel stuurt, kan die precies deze classificatie gebruiken om gevoelige velden te maskeren: op de heenweg vervangt hij de naam van een klant, zeg “Maria Lopez”, door een plaatshouder, het model ziet de naam nooit, en op de terugweg wordt de naam weer in het antwoord gezet (Einstein Trust Layer (opens in a new tab), Engels).

Een update. Salesforce documenteert nu dat maskering op basis van patronen en velden voor LLM’s uitgeschakeld is voor agents: maskering kan de context weghalen die een agent nodig heeft om te antwoorden (Data Masking Limitations in Agentforce (opens in a new tab), Engels). Classificatie stuurt nog steeds de maskering voor andere generatieve AI-functies, maar reken er niet op om persoonsgegevens bij een agent weg te houden; dat is een beslissing over toegang en ontwerp (hoofdstuk 12).

Mijn standpunt: classificatie is belangrijk op de sleutelmomenten. Maak er geen drie weken van waarin je elk vakje invult omdat governance dat zei. Gebruik het waar het ertoe doet: persoonsgegevens, financiële gegevens, gereguleerde gegevens, en velden waarvoor de business een benoemde eigenaar nodig heeft. Het punt is dat gevoeligheid ophoudt kennis in iemands hoofd te zijn en deel van het veld wordt.

Voorbij het examen: wat AI verandert. Slechte velddocumentatie strafte vroeger de volgende admin. Nu misleidt ze elke AI-tool en elke agent die het schema leest: is Flag2__c gevoelig, gezaghebbend, nog in gebruik? AI maakt ook sneller velden dan welk team ook, dus namen, omschrijvingen en classificatie zijn deel van de architectuur, geen huishoudelijk werk.

Elk veld is een verplichting

Zodra een veld data aan het verzamelen is, begint alles erop te leunen. Schermen tonen het, flows vertakken erop, validatieregels controleren het, rapporten groeperen erop, integraties sturen en lezen het, en nu redeneren AI-tools erover. Elk van hen maakt aannames over het veld: het type, de lengte, of het ooit leeg is, en wat de waarden betekenen. Verander je het veld later, dan moet je eerst al die aannames vinden. Een keuzelijstwaarde hernoemen, een tekstveld inkorten of een tekstveld omzetten in een keuzelijst klinkt als een kleine wijziging, en het kan een integratie in het systeem van een ander bedrijf breken. Daarom is een veld een verplichting.

Click to enlarge

Ik wil niet dat je deze module verlaat met angst om velden te maken. Salesforce is gebouwd om uitgebreid te worden; gebruik het. Ik wil dat de vraag verandert van “welk veldtype moet ik kiezen?” naar “wat betekent deze data, en tot welk gedrag verplichten we ons?” Type, verplicht, uniek, externe ID, keuzelijst, formule, omschrijving, classificatie: samen zijn ze de fysieke uitdrukking van het logische model uit hoofdstuk 2.

Wat een architect hier beslist

• Wat de waarde betekent voordat het veldtype gekozen wordt, en of het een attribuut is, een identificator, een gecontroleerde woordenlijst of eigenlijk een andere entiteit.
• Of een waarde een actuele berekening is die afgeleid kan worden, of een historisch feit dat opgeslagen moet worden.
• Welk systeem eigenaar is van elke identificator, en of de uniciteit ervan een echte belofte van de business is.
• Wanneer een verplichte waarde eigenlijk bekend is, en wat er gebeurt met records en integraties die haar niet hebben.
• Welke omschrijving, naamgeving en classificatie het veld nodig heeft zodat mensen, processen en AI het veilig kunnen gebruiken.

Verder lezen

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) en Data Masking Limitations in Agentforce (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Help, Picklist Limitations (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)