Felter er også arkitektur

🌐 Findes også på 28 sprog

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 6 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Vælg det rigtige objekt · Næste: Relationer har konsekvenser

Spørgsmålet, dette modul besvarer: Hvordan skal Salesforce fysisk repræsentere hvert stykke data?

Det tager cirka et minut at oprette et felt. New Field, vælg en type, giv det et navn, Next, Next, Save. Det er præcis derfor, felter ikke bliver behandlet som arkitektur.

Gå ind i en org, der har eksisteret i ti år, og åbn Account. Fem hundrede felter. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tre forskellige kundenumre. Et afkrydsningsfelt, som ingen tør slette, fordi ingen ved, hvilken integration der stadig bruger det. Det tog et minut at oprette feltet. At leve med det tager år. Så idéen i dette modul er enkel: Et felt er en arkitektonisk beslutning. Ikke altid en stor, men hvert felt koder noget om dataenes betydning, adfærd, identifikation eller kvalitet, og ligesom objekter er felter nemme at tilføje og overraskende svære at fjerne.

Hvad betyder disse data egentlig?

I kapitel 2 gav vi vores entiteter attributter: En levering har et planlagt tidsvindue, en lastbil har et stelnummer (VIN). Nu implementerer vi dem, og det er her, folk springer direkte til »tekstfelt«. Vent. Før typen vil jeg vide, hvad dataene betyder. Er det et tal eller en identifikator, der tilfældigvis består af cifre? En dato eller et tidspunkt? Fri tekst eller én værdi fra et godkendt sæt? Indtastet af et menneske eller ejet af et andet system? Kan det ændre sig? Skal det være unikt? Kan det mangle? Skal det overhovedet gemmes, eller beregnes? Det er ikke Setup-spørgsmål. Det er dataarkitekturspørgsmål, og felttypen kommer, efter vi har besvaret dem.

Et tal er ikke altid et tal

Steve Trucking giver hver lastbil et flådenummer, lad os sige 001247. Talfelt? Sandsynligvis ikke. Lægger vi flådenumre sammen? Er lastbil 1247 minus lastbil 1246 én lastbil? Det er en identifikator, der tilfældigvis indeholder cifre, og et Number-felt ville endda fjerne de foranstillede nuller. Det samme gælder postnumre, produktkoder, kontonumre og sporingsnumre. Hvordan værdien ser ud, fortæller dig ikke, hvad den betyder. Vælg typen efter den adfærd, du har brug for, ikke efter hvordan eksempeldataene ser ud.

Skal et menneske kunne genkende den?

Hvert brugerdefineret objekt får et Name-felt, og den første beslutning er tekst eller autonummer. Jeg spørger: Skal et menneske kunne genkende denne ting? Folk kender en detailpartner på navnet og en lastbil på flådenummeret. Men et manifest, som systemet genererer hver nat? Ingen skal sidde og skrive »Manifest 10-02 nummer 3«, fordi Salesforce krævede et Name. Giv det et autonummer. Bare forveksl ikke det genererede Name med det, der identificerer posten: Autonummeret hjælper brugerne, Salesforce-id’et identificerer posten, og detailpartnerens egen manifestreference kan identificere den samme ting på tværs af systemer. Tre forskellige opgaver.

Detaljeskærmen

Vælg en type, klik på Next, og Setup beder om detaljerne. Det er på denne skærm, de fleste beslutninger i dette modul faktisk bliver truffet, som regel i en fart.

New Custom Field, trin 2: detaljerne (skærmbillede, 12. oktober 2026). Fuld størrelse

To felter ligner hinanden og gør forskellige ting. Description er til de folk, der vedligeholder org’en, og nu også til de AI-værktøjer, der læser den: hvad feltet betyder, hvem der ejer det, hvor det kommer fra. Help Text er til brugeren på skærmen: hvad der skal skrives her. Udfyld begge. Så kommer Required, Unique og External ID, og hver af dem fortjener sit eget afsnit. Under dem kan Default Value være en formel, så en ny post kan starte med en fornuftig værdi i stedet for et tomt felt.

Required er en større beslutning, end det ser ud til

Der er et lille afkrydsningsfelt i feltguiden med teksten Required (påkrævet), og som vi så i kapitel 1, kan det være en tidsindstillet bombe. Du har haft et objekt i fem år med to millioner poster, og nu beslutter nogen, at et nyt felt altid skal have en værdi. Hvad med de to millioner poster, der er ældre end feltet? Integrationerne, der ikke sender det? Automatiseringen, der opretter posten, før værdien kendes? Processen, hvor værdien først dukker op tre trin senere?

»Påkrævet« lyder som en beslutning om datakvalitet, og nogle gange er det det. Men hvornår en værdi bliver kendt, er en del af forretningsprocessen. Så sæt ikke flueben i Required, fordi nogen siger »det vil vi altid have«. Spørg, hvornår den kendes, hvem der leverer den, og hvad der sker, når den ikke gør. Vi sætter det her på den fulde konsistensstige i modul 7.

Unique betyder også noget

Hvis jeg markerer et felt som unikt, udtaler jeg mig om forretningen: ikke »det gentager sig som regel ikke«, men »to poster må aldrig have denne værdi«. Det er stærkt. Og skærmen tvinger dig til at beslutte én ting mere: Er »ABC« og »abc« den samme værdi eller forskellige? Uden forskel på store og små bogstaver er den sikreste standard for alt, et menneske skriver. Nøglereglen fra kapitel 2, unik, uforanderlig, uden betydning, aldrig personoplysninger, gælder her. Hvis nogen fortæller mig, at medarbejderes e-mail er unik, begynder jeg at spørge: Kan den ændre sig, kan nogen rejse og komme tilbage, kan adresser genbruges, hvad sker der efter et opkøb? E-mail kan være nyttig, endda unik i dag. Det gør den ikke til en god nøgle.

External IDs: identifikation på tværs af grænsen

Det er her, External IDs gør sig fortjent til deres plads. Skærmen beskriver det godt: Feltet bliver »the unique record identifier from an external system«, postens unikke id fra et eksternt system. ERP-systemet har kunde 873492; Salesforce har sit eget post-id. Når ERP-systemet sender en opdatering, hvordan ved vi så, hvilken post den hører til? Markér et felt som External ID, og en integration kan lave upsert på det: oprette posten, hvis den ikke findes, og opdatere den, hvis den gør (Upsert a Record Using an External ID (opens in a new tab)). Og når du indlæser underordnede poster, kan du pege på forælderen via dens External ID i stedet for først at forespørge efter Salesforce-id’et. Jeg plejer at sige, at du lader Salesforce lave opslaget for dig. Meget kraftfuldt.

Læg mærke til, at ERP-systemets nummer ikke bliver Salesforce-postens id. Det er en attribut, og en post kan bære flere: et kunde-id fra ERP, et id fra det gamle system, en partners id. Det er fint. Én forretningsenhed kan være kendt på forskellige måder af flere systemer. Det arkitektoniske spørgsmål er, hvilket system der ejer hver identifikator, og hvilket løfte det giver: Markér den kun som unik, hvis forretningen virkelig garanterer det.

Felttype for felttype

Nu selve typerne. Åbn New Field på et hvilket som helst objekt, og Setup viser dig hele listen, grupperet på den måde, jeg gennemgår den: de felter, Salesforce beregner for dig, relationsfelterne og derefter datatyperne.

Setup, New Custom Field, trin 1: datatyperne (skærmbillede, 12. oktober 2026). Fuld størrelse

Her er hele listen i overblik med den ene ting, jeg gerne vil have, at du husker om hver.

Gruppe	Type	Husk
Beregnet	Auto Number	Op til 30 tegn, heraf 20 til præfiks eller suffiks; en etiket til mennesker, ikke postens id
	Formula	Beregnes, når den læses, gemmes ikke; 3.900 tegn
	Roll-Up Summary	Antal, sum, minimum eller maksimum af detaljeposterne; kun master-detail
Relationer	Lookup, Master-Detail, External Lookup	Modul 7
Data	Checkbox	Sand eller falsk, med en standardværdi, du vælger; null kan stadig optræde i flows
	Number, Percent, Currency	Afrundingsregler; foranstillede nuller fjernes; 15 decimaler
	Date, Date/Time, Time	En dag, et tidspunkt eller et klokkeslæt; tidspunkter gemmes i UTC
	Email, Phone, URL	Formateres og kontrolleres ved gem: 80, 40 og 255 tegn
	Geolocation, Address	Sammensatte felter, der koster mere end ét felt: 3 og 9
	Picklist, Multi-Select	Et kontrolleret ordforråd, ejet af en admin
	Text, Text Area, Long, Rich, Encrypted	Op til 255 på posten og kan indekseres; derover intet indeks eller filtrering

Felterne, Salesforce beregner

Auto Number tildeler det næste nummer i en sekvens til hver ny post i et format, du definerer, som T-{000000}. Brug det, når et menneske har brug for et venligt håndtag, og ingen burde skulle finde på et. Hele værdien er op til 30 tegn, og 20 af dem er forbeholdt præfikset eller suffikset. Husk bare fra kapitel 2: Det er en etiket til mennesker, ikke postens id, og numrene er ikke altid strengt fortløbende.

Formula-felter beregner en værdi ud fra andre felter. De er kraftfulde, og de beregnes, når posten læses, ikke når den gemmes, så der er intet gemt, der kan blive forældet. Du vælger, hvad formlen returnerer: et afkrydsningsfelt, valuta, dato, dato/tid, tal, procent, tekst eller klokkeslæt.

New Custom Field, formel: valg af returtype (skærmbillede, 12. oktober 2026). Fuld størrelse

Så skriver du selve formlen med felter, operatorer og funktioner og tjekker dens syntaks. Læg mærke til knappen Use Formula Assistant: Salesforces AI hjælper dig nu med at skrive formlen. Brug den, og læs så, hvad den skrev. Det er dig, der ejer formlen, ikke assistenten.

Formeleditoren med Formula Assistant (skærmbillede, 12. oktober 2026). Fuld størrelse En formel kan være op til 3.900 tegn, og den må ikke overstige 15.000 bytes, når den gemmes eller kompileres; en lang formel kan deles op i flere formelfelter, der henviser til hinanden. Lange tekstområder, krypterede felter og Description-felter kan ikke bruges i dem.

Roll-Up Summary-felter sidder på masteren og tæller, summerer eller tager minimum eller maksimum af dens detaljeposter. De virker kun på tværs af en master-detail-relation, og det er en af de største grunde til overhovedet at vælge master-detail. Vi vender tilbage til dem og deres begrænsninger i modul 7.

Gemt eller afledt?

Skal vi overhovedet gemme denne værdi? Hvis jeg har antal og enhedspris, skal nogen, eller en automatisering, så vedligeholde en total? Måske bør en formel aflede den: én kilde til beregningen, genberegnet når den læses, så ændrer du antallet, følger svaret med. Formler har deres egne grænser (størrelse ved gem og vist længde; Formula Field Limits and Restrictions (opens in a new tab)), og komplekse formler bliver svære at vedligeholde.

Men nogle gange vil forretningen ikke have dagens svar. Den vil have svaret, som det var. Hvis rabatreglen ændres næste år, skal sidste års faktura så pludselig vise et andet beløb? Selvfølgelig ikke. Så spørgsmålet er ikke »kan Salesforce beregne det her?« Det er »er det en aktuel beregning eller et historisk faktum?« Historiske fakta bliver gemt.

Relationsfelterne

Lookup-, Master-Detail- og External Lookup-relationer er også felter, og det er dem, der gør linjerne i din model virkelige. Lookup-relationen er det løse link; master-detail binder barnets liv, ejerskab og sikkerhed til forælderen; external lookup når et eksternt objekt fra modul 4 og matcher på dets External ID. At vælge mellem dem er en stor nok beslutning til at få sit eget modul.

Afkrydsningsfelt (Checkbox)

Et afkrydsningsfelt (checkbox) er det enkleste felt, der findes: sand eller falsk, markeret eller ikke markeret. Det er perfekt til et ja/nej-faktum om posten: Is Active, Install Required, Signed For. Når du opretter et, tvinger Salesforce dig til at vælge dets standardværdi, markeret eller ikke markeret, og det er en rigtig beslutning: Det er det, hver ny post starter med, også poster, som en integration opretter uden at sende feltet. Rapporter og listevisninger filtrerer det som True og False; importværktøjerne og den ugentlige eksport viser det som 1 og 0.

En fælde, du skal kende. Feltet på posten har to værdier, men automatiseringen omkring det kan have en tredje. I et flow er en checkbox-variabel, der aldrig er blevet sat, null, ikke false, og at gemme den på en post fejler (Trailblazer Community (opens in a new tab); se også Salesforces kendte fejl W-11208535 (opens in a new tab)). Vælg en fornuftig standardværdi, og få dine flows og din kode til at håndtere null med vilje.

Tal, procent og valuta

Number gemmer et reelt tal og fjerner eventuelle foranstillede nuller, og det er præcis derfor, et flådenummer som 001247 ikke er et Number. Salesforce afrunder talfelter halvt væk fra nul: 12,345 bliver til 12,35, og −12,345 bliver til −12,35. Og i flettefelter afrunder den efter brugerens landestandard, ikke efter de decimaler, du har sat på feltet.

Percent gemmer et decimaltal og viser en procentsats: Skriv 0,10, og du ser 10 %. Værdier mister præcision efter 15 decimaler.

Currency er formateret til penge, og i en org med flere valutaer bærer den sin valutakode og kan bruge valutakurser; med advanced currency management (opens in a new tab) kan salgsmuligheder bruge daterede valutakurser, kursen for den periode, handlen blev lukket i. Kun salgsmuligheder og tingene omkring dem (produkter, planer, opdelinger og deres rapporter) bruger daterede kurser; valutafelter på andre objekter beholder den ene statiske kurs. Hold øje med afrundingen: Uden decimaler afskærer Salesforce simpelthen (23,5 bliver til 23); med én eller flere afrunder den halvt væk fra nul.

Dato, dato/tid og klokkeslæt

Tre typer, tre forskellige betydninger. En Date er en dag: En kontrakt udløber på en dato. En Date/Time er et tidspunkt: Leveringen ankom kl. 9.42 den morgen. En Time er et klokkeslæt helt uden dato: Butikken åbner kl. 7.00, hver dag.

Fælden er tidspunktet. Salesforce gemmer dato/tid-værdier i GMT (UTC). Det klokkeslæt, en bruger skriver, læses i brugerens tidszone, konverteres og gemmes; når nogen læser det, konverteres det igen til læserens tidszone. Det meste af tiden er det præcis det, du vil have. Men her er det eksempel, jeg giver i klassen: En koordinator i Los Angeles registrerer en levering sent søndag aften, kl. 22.00 Pacific-tid. Nedenunder har Salesforce gemt mandag morgen, kl. 05.00 GMT. En rapport grupperet pr. dag i en anden tidszone, eller en integration, der læser den rå værdi, kan placere den søndagslevering om mandagen. »Den dag, det skete« afhænger af, hvis ur du spørger. Hold øje med brugernes tidszoner, og beslut, hvilken forretningen mener.

Og vær forsigtig, når du sammenligner dem. Nedenunder er en dato/tid ét stort tal: Apex læser det som antallet af millisekunder siden 1. januar 1970 kl. 00.00.00 GMT (Datetime Class (opens in a new tab)). Det er et præcist tidspunkt, ikke en dag. Så at spørge, om to dato/tider er lig med hinanden (==), gør næsten aldrig det, du vil: 9.42.00 og 9.42.01 er ikke ens, og det er »mandag« og et vilkårligt tidspunkt om mandagen heller ikke. Spørg i stedet efter et interval: på eller efter starten (>=) og på eller før slutningen (<=). »Alle leveringer om mandagen« er alle leveringer >= mandag kl. 00.00 og <= mandag kl. 23.59.59, i den tidszone, du har besluttet, at forretningen mener.

Og en sjov én: Salesforce kan ikke gemme en hvilken som helst dato. Gyldige datoer går fra 1. januar 1700 til 31. december 4000, og Salesforce angiver det samme interval for datoer og dato/tider (Data Import Dates (opens in a new tab)). Selv yderpunkterne er tidspunkter i GMT, så for en bruger i Pacific-tid er den tidligste gyldige værdi kl. 16.00 den 31. december 1699. Din lokalhistoriske forenings stiftelsesdato kommer måske ikke med. Og det klassiske trick med »ingen slutdato«, 31. december 9999, bliver afvist; har du brug for en pladsholder langt ude i fremtiden, skal den ligge i år 4000 eller før.

E-mail, telefon og URL

Det er de formaterede felter, og de gør mere end at gemme tegn. Email rummer op til 80 tegn og kontrolleres for korrekt format; på kontakter og kundeemner starter et klik en e-mail til den adresse. Phone rummer op til 40 tegn, formateres som et telefonnummer og bliver til klik-for-at-ringe, når org’en har et telefonsystem tilkoblet. URL rummer op til 255 tegn og åbnes som et link. Det er platformen, der giver dig adfærd gratis, og derfor ville jeg aldrig gemme et telefonnummer i et almindeligt tekstfelt.

Integrationer bliver også kontrolleret. En værdi, der ikke passer til feltets format, som en forkert formateret e-mailadresse, fejler valideringen, og hele posten bliver afvist, ikke bare det felt. Så når kildesystemets data er rodede, så ryd op, før de ankommer, eller planlæg for de poster, der ikke kan indlæses.

Geolokation og adresse

Geolocation rummer en breddegrad og en længdegrad. Nedenunder er et felt ved navn Location__c i virkeligheden to værdier, du kan læse og sætte hver for sig, Location__Latitude__s og Location__Longitude__s. Og du kan forespørge på det: SOQL-funktionerne DISTANCE og GEOLOCATION finder poster inden for en radius eller sorterer dem efter, hvor langt væk de er. »Alle åbne leveringer inden for 25 miles af denne lastbil« er én forespørgsel: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address rummer en hel adresse, gade, by, stat eller provins, postnummer og land, og brugerne kan søge efter en adresse og få delene udfyldt.

Begge er sammensatte felter: ét felt på skærmen, flere nedenunder. Og de koster mere end ét felt i forhold til dit objekts grænse: En Geolocation tæller som tre brugerdefinerede felter, og en Address tæller som ni. På et objekt, der allerede er fyldt op, betyder det noget.

Valgliste og flervalgsliste

En valgliste (picklist) styrer, hvad brugerne kan indtaste: én værdi fra en liste, du definerer. Status? Valgliste, sandsynligvis. Men værdierne er metadata, og en admin skal tilføje eller ændre dem. Så jeg spørger stadig, hvem der ejer værdierne, hvor tit de ændrer sig, om flere objekter har brug for den samme liste, om værdierne bærer deres egen information, og om et andet system ejer ordforrådet.

Hvor værdierne bor, er også en beslutning. Når en liste bruges én gang, på ét felt, så hold værdierne på selve feltet, på objektet; det gør Salesforce som standard. Men når det samme sæt værdier begynder at dukke op flere steder, en region på kontoen, på leveringen og på lageret, så ophøj det til et globalt værdisæt, før kopierne glider fra hinanden. Et globalt værdisæt (global value set) holder én liste for dem alle, op til 1.000 værdier, aktive og inaktive tilsammen (Picklist Limitations (opens in a new tab)). Setups egen beskrivelse siger, hvorfor det betyder noget: Værdisættet »is restricted so users can’t add unapproved values through the API«, det er begrænset, så brugere ikke kan tilføje ikke-godkendte værdier via API’et. Én liste, én ejer og ingen integration, der sniger en ny stavemåde ind.

Det sidste punkt er forskellen mellem begrænset (restricted) og ubegrænset (unrestricted). På en begrænset valgliste er kun de værdier tilladt, som en admin har defineret, uanset hvorfra: En bruger, en import eller en integration, der sender noget andet, får en fejl, »bad value for restricted picklist field«, og posten bliver ikke gemt. På en ubegrænset valgliste vælger brugerne stadig fra listen på skærmen, men API’et, importer og automatisering kan sende en hvilken som helst værdi, og Salesforce gemmer den og tilføjer den som en inaktiv værdi (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Sådan ender en org med »Delivered«, »delivered« og »Dlvrd«. Globale værdisæt er altid begrænsede. Min standard er begrænset; ubegrænset er et bevidst valg til når et andet system virkelig ejer værdierne, og så ejer nogen oprydningen af de inaktive.

Setup, Picklist Value Sets: et nyt globalt værdisæt (skærmbillede, 12. oktober 2026). Fuld størrelse

En flervalgsliste (multi-select picklist) lader en bruger vælge flere værdier, gemt sammen og adskilt af semikolon. Praktisk på en skærm, besværlig alle andre steder: sværere at filtrere, rapportere og integrere på, og den kan ikke bruges i filteret på et oversigtsfelt (roll-up summary). Flere værdier for én post betyder som regel lektien fra kapitel 2: Der er et underordnet objekt, der prøver at komme ud.

En valgliste har også én værdi mere end dem, du har defineret: tom. En post kan stå uden noget valgt, og det fanger folk. I en formel eller valideringsregel kan du ikke teste en valgliste med ISBLANK alene; du skriver ISBLANK(TEXT(Field__c)) eller ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Så beslut, hvad »ingen værdi« betyder for hver valgliste: Er det tilladt, og hvad betyder det, når det sker? Og få så dine formler, valideringsregler og filtre til at håndtere det.

Og nogle gange er en attribut i virkeligheden en entitet. Nogen beder om en valgliste med distributionscentre. Der er ni. Nemt. Så finder vi ud af, at hvert af dem har en adresse, en leder, åbningstider, kapacitet, en region og lastbiler. Det er ikke en valgliste; det er en ting. Gør ikke en entitet til en valgliste, bare fordi der ikke er mange af dem endnu. Det føles fantastisk i år ét og forfærdeligt i år fem. (Kapitel 2, modul 5, har mine tommelfingerregler for, hvornår en liste fortjener sit eget objekt.)

Tekstfamilien

Jeg underviser i tekst som to slags, og grænsen mellem dem er 255 tegn.

Op til 255: gemt med posten. Text rummer op til 255 tegn, og du kan bruge det næsten overalt: i formler, filtre, rapporter, listevisninger, som unikt felt eller External ID, og det kan indekseres. Text Area rummer også 255, på separate linjer, som en kort note.

Over 255: gemt via reference. Text Area (Long) rummer op til 131.072 tegn, og Text Area (Rich) rummer det samme med formatering, links og billeder. Jeg tænker på dem som gemt ude ved siden af, mens posten har en pegepind, og de opfører sig sådan: intet indeks, så du kan ikke gøre dem unikke eller til External ID; du kan ikke filtrere på dem i en SOQL-WHERE-betingelse (SOQL WHERE (opens in a new tab)); formler kan ikke bruge dem (Formula Field Limits and Restrictions (opens in a new tab)); og rapporter viser kun de første 254 tegn af et brugerdefineret felt, mens rapportfiltre kun søger i cirka de første 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Billeder, der uploades i et rich text-felt, kan være op til 1 MB hver, og de tæller med i fillagringen, mens teksten tæller med i datalagringen (Rich Text Area Field Considerations (opens in a new tab)). Så hvis nogen har brug for at søge, sortere, matche eller rapportere på værdien, så hold den under 255 og hold den som et Text-felt.

Text (Encrypted) gemmer op til 175 tegn i krypteret form med Classic Encryption. Hvis din org bruger Shield Platform Encryption, krypterer du i stedet et almindeligt Text-felt, og mange andre typer kan også krypteres på den måde.

Giv hvert felt en beskrivelse

Min standard: Hvert felt får en beskrivelse. Det har jeg ment længe, og i AI’s tid betyder det mere end nogensinde: Hvert AI-værktøj og hver agent, der læser din org, læser beskrivelserne for at forstå, hvad et felt betyder. En tom beskrivelse er et gæt, der venter på at ske. Hvad betyder Customer_Status__c? Hvem ejer det? Hvor kommer det fra? Kan brugerne redigere det, eller overskriver ERP-systemet det i nat? Om seks måneder husker jeg det ikke, og om tre år ved den admin, der vedligeholder org’en, det ikke, medmindre vi har fortalt det. Etiketten er ikke dokumentation, og det er API-navnet heller ikke.

På meget delte objekter (Account, Contact, Opportunity) bruger jeg også navnepræfikser til specialfelter, så deres oprindelse og formål fremgår af selve navnet: Alt, hvad ERP-systemet ejer, starter for eksempel med det samme præfiks. Jeg er ikke ude efter API-navne på tolv ord. Jeg vil have, at modellen forklarer sig selv.

Klassificér det, der betyder noget: taksonomifelterne

Salesforce giver hvert felt et sæt klassifikationsmetadata. Jeg kalder dem taksonomifelterne. Du kan registrere dataejeren (data owner); feltbrugen (field usage: Active, DeprecateCandidate, Hidden); følsomhedsniveauet (data sensitivity level: Public, Internal, Confidential, Restricted, MissionCritical); og compliance-kategoriseringen: PII, HIPAA, GDPR, PCI, CCPA og andre. De virker på standardfelter såvel som brugerdefinerede (Data Classification Metadata Fields (opens in a new tab)).

Hvorfor gøre sig umaget? Fordi processer kan læse dem. Markér et felt som GDPR, og en proces kan finde hvert GDPR-felt på en post og maskere eller fjerne det. Og når Salesforces trust layer sender en prompt til en stor sprogmodel, kan den bruge præcis denne klassifikation til at maskere følsomme felter: Den bytter en kundes navn, lad os sige »Maria Lopez«, ud med en pladsholder på vej ud, modellen ser aldrig navnet, og navnet sættes tilbage i svaret på vej ind (Einstein Trust Layer (opens in a new tab)).

En opdatering. Salesforce dokumenterer nu, at mønsterbaseret og feltbaseret maskering til LLM’er er slået fra for agenter: Maskering kan fjerne den kontekst, en agent har brug for til at svare (Data Masking Limitations in Agentforce (opens in a new tab)). Klassifikation styrer stadig maskering for andre generative AI-funktioner, men regn ikke med, at den holder personoplysninger væk fra en agent; det er en beslutning om adgang og design (kapitel 12).

Min holdning: Klassifikation er vigtig på de rigtige tidspunkter. Gør det ikke til tre ugers udfyldning af hvert eneste felt, fordi styringen sagde det. Brug det, hvor det betyder noget: personoplysninger, finansielle data, regulerede data og felter, hvor forretningen har brug for en navngiven ejer. Pointen er, at følsomhed holder op med at være viden i nogens hoved og bliver en del af feltet.

Ud over eksamen: hvad AI ændrer. Dårlig feltdokumentation plejede at straffe den næste admin. Nu vildleder den hvert AI-værktøj og hver agent, der læser skemaet: Er Flag2__c følsomt, autoritativt, stadig i brug? AI opretter også felter hurtigere end noget team, så navne, beskrivelser og klassifikation er en del af arkitekturen, ikke husholdning.

Hvert felt er en forpligtelse

Når et felt først er derude og samler data, begynder alt at læne sig op ad det. Skærme viser det, flows forgrener sig på det, valideringsregler tjekker det, rapporter grupperer efter det, integrationer sender og læser det, og nu ræsonnerer AI-værktøjer om det. Hver eneste af dem gør antagelser om feltet: dets type, dets længde, om det nogensinde er tomt, og hvad dets værdier betyder. Ændrer du feltet senere, skal du først finde hver eneste af de antagelser. At omdøbe en værdi i en valgliste, forkorte et tekstfelt eller gøre et Text-felt til en valgliste lyder som en lille ændring, og det kan få en integration i en anden virksomheds system til at gå i stykker. Derfor er et felt en forpligtelse.

Click to enlarge

Jeg vil ikke have, at du forlader dette modul bange for at oprette felter. Salesforce er bygget til at blive udvidet; brug det. Jeg vil have, at spørgsmålet ændrer sig fra »hvilken felttype skal jeg vælge?« til »hvad betyder disse data, og hvilken adfærd forpligter vi os til?« Type, påkrævet, unik, External ID, valgliste, formel, beskrivelse, klassifikation: Tilsammen er de det fysiske udtryk for den logiske model fra kapitel 2.

Hvad en arkitekt beslutter her

• Hvad værdien betyder, før felttypen vælges, og om den er en attribut, en identifikator, et kontrolleret ordforråd eller i virkeligheden en anden entitet.
• Om en værdi er en aktuel beregning, der kan afledes, eller et historisk faktum, der skal gemmes.
• Hvilket system der ejer hver identifikator, og om dens unikhed er et reelt forretningsløfte.
• Hvornår en påkrævet værdi faktisk er kendt, og hvad der sker med poster og integrationer, der ikke har den.
• Hvilken beskrivelse, navngivning og klassifikation feltet har brug for, så mennesker, processer og AI kan bruge det sikkert.

Læs mere

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