Felt er også arkitektur

🌐 Finnes også på 28 språk

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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 6 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Velg riktig objekt · Neste: Relasjoner har konsekvenser

Spørsmålet denne modulen besvarer: Hvordan skal Salesforce fysisk representere hver enkelt databit?

Å lage et felt tar omtrent ett minutt. New Field, velg en type, gi det et navn, Next, Next, Save. Det er nettopp derfor felt ikke blir behandlet som arkitektur.

Gå inn i en org som har eksistert i ti år, og åpne Account. Fem hundre felt. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tre forskjellige kundenumre. En avkrysningsboks ingen vil slette fordi ingen vet hvilken integrasjon som fortsatt bruker den. Å lage feltet tok ett minutt. Å leve med det tar år. Så tanken i denne modulen er enkel: et felt er en arkitekturbeslutning. Ikke alltid en stor en, men hvert felt koder noe om meningen, oppførselen, identifiseringen eller kvaliteten til dataene, og i likhet med objekter er felt lette å legge til og overraskende vanskelige å fjerne.

Hva betyr disse dataene egentlig?

I kapittel 2 ga vi entitetene våre attributter: en levering har et planlagt tidsvindu, en lastebil har et VIN (understellsnummer). Nå implementerer vi dem, og det er her folk hopper rett til «tekstfelt». Vent. Før typen vil jeg vite hva dataene betyr. Er det et tall, eller en identifikator som tilfeldigvis har sifre? En dato, eller et tidspunkt? Fritekst, eller én av et godkjent sett? Lagt inn av en person, eller eid av et annet system? Kan det endre seg? Må det være unikt? Kan det mangle? Skal det i det hele tatt lagres, eller beregnes? Det er ikke Setup-spørsmål. Det er dataarkitekturspørsmål, og felttypen kommer etter at vi har svart på dem.

Et tall er ikke alltid et tall

Steve Trucking gir hver lastebil et flåtenummer, si 001247. Number-felt? Sannsynligvis ikke. Legger vi sammen flåtenumre? Er lastebil 1247 minus lastebil 1246 én lastebil? Det er en identifikator som tilfeldigvis inneholder sifre, og et Number-felt ville til og med kutte de innledende nullene. Det samme gjelder postnumre, produktkoder, kontonumre og sporingsnumre. Hvordan verdien ser ut, forteller deg ikke hva den betyr. Velg typen ut fra oppførselen du trenger, ikke ut fra hvordan eksempeldataene ser ut.

Må et menneske kunne kjenne den igjen?

Hvert egendefinert objekt får et Name-felt, og den første beslutningen er tekst eller automatisk nummer. Jeg spør: må et menneske kunne kjenne igjen denne tingen? Folk kjenner en detaljhandelspartner på navnet og en lastebil på flåtenummeret. Men et manifest systemet genererer hver natt? Ingen burde måtte skrive «Manifest 10-02 nummer 3» fordi Salesforce krevde et navn. Gi det et Auto Number. Bare ikke bland det genererte navnet sammen med postens identifisering: det automatiske nummeret hjelper brukerne, Salesforce-ID-en identifiserer posten, og detaljhandelspartnerens egen manifestreferanse kan identifisere den samme tingen på tvers av systemer. Tre forskjellige jobber.

Detaljskjermen

Velg en type, klikk Next, og Setup spør etter detaljene. Det er på denne skjermen de fleste beslutningene i denne modulen faktisk tas, som regel i en fart.

New Custom Field, steg 2: detaljene (skjermbilde, 2026-10-12). Full størrelse

To bokser ser like ut og gjør forskjellige jobber. Description er for folkene som vedlikeholder orgen, og nå for KI-verktøyene som leser den: hva feltet betyr, hvem som eier det, hvor det kommer fra. Help Text er for brukeren på skjermen: hva som skal skrives her. Fyll ut begge. Så kommer Required, Unique og External ID, og hver av dem fortjener sitt eget avsnitt. Under dem kan Default Value være en formel, så en ny post kan starte med en fornuftig verdi i stedet for et tomt felt.

Required er en større beslutning enn det ser ut som

Det finnes en liten avkrysningsboks i feltveiviseren merket Required (obligatorisk), og som vi så i kapittel 1, kan den være en tidsinnstilt bombe. Du har hatt et objekt i fem år og to millioner poster, og nå bestemmer noen at et nytt felt alltid må ha en verdi. Hva med de to millioner postene som er eldre enn feltet? Integrasjonene som ikke sender det? Automatiseringen som oppretter posten før verdien er kjent? Prosessen der verdien først dukker opp tre steg senere?

«Required» høres ut som en datakvalitetsbeslutning, og noen ganger er det det. Men når en verdi blir kjent, er en del av forretningsprosessen. Så ikke kryss av for Required fordi noen sier «vi vil alltid ha det». Spør når det er kjent, hvem som leverer det, og hva som skjer når det ikke er det. Vi setter dette på hele konsistensstigen i modul 7.

Unique betyr også noe

Markerer jeg et felt som unikt, kommer jeg med en påstand om forretningen: ikke «det gjentar seg som regel ikke», men «to poster kan aldri ha denne verdien». Det er sterkt. Og skjermen tvinger deg til å bestemme én ting til: er «ABC» og «abc» samme verdi eller forskjellige? Uten skille mellom store og små bokstaver er det tryggeste standardvalget for alt en person skriver inn. Nøkkelregelen fra kapittel 2, unik, uforanderlig, meningsløs, aldri personopplysninger (PII), gjelder her. Sier noen til meg at ansattes e-post er unik, begynner jeg å spørre: kan den endre seg, kan noen slutte og komme tilbake, kan adresser gjenbrukes, hva skjer etter et oppkjøp? E-post kan være nyttig, til og med unik i dag. Det gjør den ikke til en god identifikator.

External ID: identifisering på tvers av grensen

Det er her External ID gjør seg fortjent. Skjermen beskriver det godt: feltet blir «the unique record identifier from an external system» (den unike postidentifikatoren fra et eksternt system). ERP-systemet har kunde 873492; Salesforce har sin egen post-ID. Når ERP-systemet sender en oppdatering, hvordan vet vi hvilken post den hører til? Marker et felt som External ID, så kan en integrasjon gjøre upsert på det: opprette posten hvis den ikke finnes, oppdatere den hvis den gjør det (Upsert a Record Using an External ID (opens in a new tab)). Og når du laster inn barneposter, kan du peke på forelderen med dens External ID i stedet for å spørre etter Salesforce-ID-en først. Jeg pleier å si at du lar Salesforce gjøre oppslaget for deg. Svært kraftig.

Legg merke til at ERP-nummeret ikke blir Salesforce-postens ID. Det er et attributt, og en post kan ha flere: en kunde-ID fra ERP, en eldre ID, en partners ID. Det er greit. Én forretningsentitet kan være kjent på forskjellige måter i flere systemer. Det arkitektoniske spørsmålet er hvilket system som eier hver identifikator, og hvilket løfte den gir: marker den som unik bare hvis forretningen virkelig garanterer det.

Felttype for felttype

Så selve typene. Åpne New Field på et hvilket som helst objekt, og Setup viser deg hele listen, gruppert slik jeg kommer til å gå gjennom den: feltene Salesforce beregner for deg, relasjonsfeltene og så datatypene.

Setup, New Custom Field, steg 1: datatypene (skjermbilde, 2026-10-12). Full størrelse

Her er hele listen på ett blikk, med den ene tingen jeg vil at du skal huske om hver.

Gruppe	Type	Husk
Beregnet	Auto Number	Opptil 30 tegn, 20 av dem prefiks eller suffiks; en etikett for mennesker, ikke postens ID
	Formula	Beregnes når det leses, lagres ikke; 3 900 tegn
	Roll-Up Summary	Antall, sum, min eller maks av detaljpostene; bare master-detail
Relasjoner	Lookup, Master-Detail, External Lookup	Modul 7
Data	Checkbox	Sann eller usann, med en standardverdi du velger; null kan likevel dukke opp i flows
	Number, Percent, Currency	Avrundingsregler; innledende nuller forsvinner; 15 desimaler
	Date, Date/Time, Time	En dag, et tidspunkt eller et klokkeslett; tidspunkter lagres i UTC
	Email, Phone, URL	Formatert og kontrollert ved lagring: 80, 40 og 255 tegn
	Geolocation, Address	Sammensatte felt som koster mer enn ett felt: 3 og 9
	Picklist, Multi-Select	Et kontrollert vokabular, eid av en admin
	Text, Text Area, Long, Rich, Encrypted	Opptil 255 på posten og kan indekseres; over det ingen indeks eller filtrering

Feltene Salesforce beregner

Auto Number gir hver nye post det neste nummeret i en sekvens, i et format du definerer, som T-{000000}. Bruk det når et menneske trenger et vennlig håndtak og ingen burde måtte finne på et. Hele verdien er på opptil 30 tegn, og 20 av dem er satt av til prefikset eller suffikset. Bare husk fra kapittel 2: det er en etikett for mennesker, ikke postens ID, og numrene er ikke alltid strengt fortløpende.

Formula-felt beregner en verdi fra andre felt. De er kraftige, og de beregnes når posten leses, ikke når den lagres, så det finnes ikke noe lagret som kan bli utdatert. Du velger hva formelen returnerer: en avkrysningsboks, valuta, dato, dato/tid, tall, prosent, tekst eller klokkeslett.

New Custom Field, formel: valg av returtype (skjermbilde, 2026-10-12). Full størrelse

Så skriver du selve formelen, med felt, operatorer og funksjoner, og kontrollerer syntaksen. Legg merke til knappen Use Formula Assistant: Salesforces KI hjelper deg nå med å skrive formelen. Bruk den, og les så det den skrev. Det er du som eier formelen, ikke assistenten.

Formeleditoren, med Formula Assistant (skjermbilde, 2026-10-12). Full størrelse En formel kan være på opptil 3 900 tegn, og den kan ikke overstige 15 000 byte når den lagres eller kompileres; en lang formel kan deles over flere formelfelt som viser til hverandre. Lange tekstområder, krypterte felt og Description-felt kan ikke brukes i dem.

Roll-Up Summary-felt (sammendragsfelt) sitter på masteren og teller, summerer eller tar minimum eller maksimum av detaljpostene. De fungerer bare over en master-detail-relasjon, og det er en av de største grunnene til i det hele tatt å velge master-detail. Vi kommer tilbake til dem, og grensene deres, i modul 7.

Lagret eller avledet?

Trenger vi i det hele tatt å lagre denne verdien? Har jeg antall og enhetspris, må noen, eller noe automatisering, vedlikeholde en total? Kanskje en formel bør avlede den: én kilde for beregningen, beregnet på nytt når den leses, så endrer du antallet, følger svaret etter. Formler har egne grenser (lagringsstørrelse og vist lengde; Formula Field Limits and Restrictions (opens in a new tab)), og komplekse formler blir vanskelige å vedlikeholde.

Men noen ganger vil ikke forretningen ha dagens svar. Den vil ha svaret slik det var. Endrer rabattregelen seg neste år, skal fjorårets faktura plutselig vise et annet beløp? Selvfølgelig ikke. Så spørsmålet er ikke «kan Salesforce beregne dette?» Det er «er dette en nåværende beregning eller et historisk faktum?» Historiske fakta lagres.

Relasjonsfeltene

Lookup-, Master-Detail- og External Lookup-relasjoner er også felt, og det er der linjene i modellen din blir virkelige. Lookup-relasjonen er den løse koblingen; master-detail binder barnets liv, eierskap og sikkerhet til forelderen; den eksterne lookup-relasjonen når et eksternt objekt fra modul 4 og matcher på dets External ID. Valget mellom dem er en stor nok beslutning til å få sin egen modul.

Avkrysningsboks (Checkbox)

En avkrysningsboks er det enkleste feltet som finnes: sann eller usann, avkrysset eller ikke. Den er perfekt for et ja/nei-faktum om posten: Is Active, Install Required, Signed For. Når du lager en, tvinger Salesforce deg til å velge standardverdien, avkrysset eller ikke, og det er en ekte beslutning: det er det hver ny post starter med, også poster en integrasjon oppretter uten å sende feltet. Rapporter og listevisninger filtrerer den som True og False; importverktøyene og den ukentlige eksporten viser den som 1 og 0.

Én felle du bør kjenne. Feltet på posten har to verdier, men automatiseringen rundt det kan ha en tredje. I en flow er en avkrysningsboks-variabel som aldri ble satt, null, ikke false, og å lagre den til en post feiler (Trailblazer Community (opens in a new tab); se også Salesforces kjente feil W-11208535 (opens in a new tab)). Velg en fornuftig standardverdi, og få flowene og koden din til å håndtere null med vilje.

Tall, prosent og valuta

Number lagrer et reelt tall og kutter eventuelle innledende nuller, og det er nettopp derfor et flåtenummer som 001247 ikke er et Number. Salesforce runder tallfelt halvt bort fra null: 12,345 blir 12,35, og −12,345 blir −12,35. Og i flettefelt runder den etter brukerens lokale innstillinger, ikke etter antall desimaler du har satt på feltet.

Percent lagrer et desimaltall og viser en prosent: skriv inn 0,10, og du ser 10 %. Verdier mister presisjon etter 15 desimaler.

Currency er formatert for penger, og i en org med flere valutaer har det valutakoden sin og kan bruke valutakurser; med avansert valutastyring (opens in a new tab) kan salgsmuligheter bruke daterte valutakurser, kursen for perioden avtalen ble lukket i. Bare salgsmuligheter og det som henger rundt dem (produkter, planer, fordelinger og rapportene deres) bruker daterte kurser; valutafelt på andre objekter beholder den ene faste kursen. Pass på avrundingen: uten desimaler kutter Salesforce bare av (23,5 blir 23); med én eller flere runder den halvt bort fra null.

Dato, dato/tid og klokkeslett

Tre typer, tre forskjellige betydninger. En Date er en dag: en kontrakt utløper på en dato. En Date/Time er et tidspunkt: leveringen kom kl. 09.42 den morgenen. En Time er et klokkeslett helt uten dato: butikken åpner kl. 07.00, hver dag.

Fella er tidspunktet. Salesforce lagrer dato/tid-verdier i GMT (UTC). Klokkeslettet en bruker skriver inn, leses i brukerens tidssone, konverteres og lagres; når noen leser det, konverteres det igjen til leserens tidssone. Som oftest er det akkurat det du vil. Men her er eksemplet jeg gir på kurs: en koordinator i Los Angeles registrerer en levering sent søndag kveld, kl. 22.00 Pacific-tid. Under panseret lagret Salesforce mandag morgen, kl. 05.00 GMT. En rapport gruppert per dag i en annen tidssone, eller en integrasjon som leser den rå verdien, kan legge den søndagsleveringen på mandag. «Dagen det skjedde» avhenger av hvem sin klokke du spør. Følg med på brukernes tidssoner, og bestem hvilken forretningen mener.

Og vær forsiktig når du sammenligner dem. Under panseret er en dato/tid ett stort tall: Apex leser det som antall millisekunder siden 1. januar 1970, kl. 00.00.00 GMT (Datetime Class (opens in a new tab)). Det er et presist tidspunkt, ikke en dag. Så å spørre om to dato/tid-verdier er like (==) gjør nesten aldri det du vil: 09.42.00 og 09.42.01 er ikke like, og det er heller ikke «mandag» og et hvilket som helst tidspunkt på mandag. Spør i stedet etter et intervall: på eller etter starten (>=) og på eller før slutten (<=). «Alle leveringer på mandag» er alle leveringer >= mandag kl. 00.00 og <= mandag kl. 23.59.59, i tidssonen du bestemte at forretningen mener.

Og en morsom en: Salesforce kan ikke lagre hvilken som helst dato. Gyldige datoer går fra 1. januar 1700 til og med 31. desember 4000, og Salesforce oppgir det samme intervallet for datoer og dato/tid-verdier (Data Import Dates (opens in a new tab)). Selv yttergrensene er tidspunkter i GMT, så for en bruker i Pacific-tid er den tidligste gyldige verdien kl. 16.00 den 31. desember 1699. Stiftelsesdatoen til historielaget ditt kommer kanskje ikke inn. Og det klassiske «ingen sluttdato»-trikset, 31. desember 9999, blir avvist; trenger du en plassholder langt frem i tid, må den være i år 4000 eller før.

E-post, telefon og URL

Dette er de formaterte feltene, og de gjør mer enn å lagre tegn. Email rommer opptil 80 tegn og kontrolleres for riktig format; på kontakter og kundeemner starter et klikk på den en e-post til den adressen. Phone rommer opptil 40 tegn, formateres som et telefonnummer og blir klikk-for-å-ringe når orgen har et telefonsystem tilkoblet. URL rommer opptil 255 tegn og åpnes som en lenke. Det er plattformen som gir deg oppførsel gratis, og det er derfor jeg aldri ville lagret et telefonnummer i et vanlig tekstfelt.

Integrasjoner blir også kontrollert. En verdi som ikke passer feltets format, for eksempel en feilformet e-postadresse, feiler valideringen, og hele posten avvises, ikke bare det feltet. Så når dataene i kildesystemet er rotete, rydd dem før de kommer, eller planlegg for postene som ikke lar seg laste inn.

Geolokasjon og adresse

Geolocation rommer en breddegrad og en lengdegrad. Under panseret er et felt kalt Location__c egentlig to verdier du kan lese og sette hver for seg, Location__Latitude__s og Location__Longitude__s. Og du kan spørre på det: SOQL-funksjonene DISTANCE og GEOLOCATION finner poster innenfor en radius, eller sorterer dem etter hvor langt unna de er. «Alle åpne leveringer innenfor 25 miles (omtrent 40 km) fra denne lastebilen» er én spørring: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address rommer en hel adresse, gate, by, delstat eller provins, postnummer og land, og brukerne kan søke etter en adresse og få delene fylt inn.

Begge er sammensatte felt (compound fields): ett felt på skjermen, flere under panseret. Og de koster mer enn ett felt mot objektets grense: en Geolocation teller som tre egendefinerte felt, og en Address teller som ni. På et objekt som allerede er fullt, betyr det noe.

Plukkliste og flervalg

En plukkliste styrer hva brukerne kan legge inn: én verdi fra en liste du definerer. Status? Plukkliste, sannsynligvis. Men verdiene er metadata, og en admin må legge dem til eller endre dem. Så jeg spør likevel hvem som eier verdiene, hvor ofte de endres, om flere objekter trenger den samme listen, om verdiene bærer egen informasjon, og om et annet system eier vokabularet.

Hvor verdiene bor, er også en beslutning. Når en liste brukes én gang, på ett felt, behold verdiene på selve feltet, på objektet; det er det Salesforce gjør som standard. Men når det samme settet med verdier begynner å dukke opp flere steder, en region på kontoen, på leveringen og på lageret, forfrem det til et globalt verdisett før kopiene glir fra hverandre. Et globalt verdisett holder én liste for alle sammen, opptil 1 000 verdier, aktive og inaktive til sammen (Picklist Limitations (opens in a new tab)). Setups egen beskrivelse sier hvorfor det betyr noe: verdisettet «is restricted so users can’t add unapproved values through the API» (er begrenset, så brukerne ikke kan legge til ikke-godkjente verdier gjennom API-et). Én liste, én eier, og ingen integrasjon som sniker inn en ny stavemåte.

Det siste punktet er forskjellen mellom begrenset (restricted) og ubegrenset (unrestricted). På en begrenset plukkliste er bare verdiene en admin har definert, tillatt, uansett hvor de kommer fra: en bruker, en import eller en integrasjon som sender noe annet, får en feilmelding, «bad value for restricted picklist field», og posten lagres ikke. På en ubegrenset plukkliste velger brukerne fortsatt fra listen på skjermen, men API-et, importer og automatisering kan sende hvilken som helst verdi, og Salesforce lagrer den og legger den til som en inaktiv verdi (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Slik ender en org opp med «Delivered», «delivered» og «Dlvrd». Globale verdisett er alltid begrenset. Mitt standardvalg er begrenset; ubegrenset er et bevisst valg for når et annet system virkelig eier verdiene, og da er det noen som eier oppryddingen av de inaktive.

Setup, Picklist Value Sets: et nytt globalt verdisett (skjermbilde, 2026-10-12). Full størrelse

En flervalgsplukkliste (multi-select picklist) lar en bruker velge flere verdier, lagret sammen og skilt med semikolon. Praktisk på en skjerm, klønete alle andre steder: vanskeligere å filtrere, rapportere og integrere på, og den kan ikke brukes i filteret til et sammendragsfelt. Flere verdier for én post betyr som regel lærdommen fra kapittel 2: det er et barneobjekt som prøver å komme ut.

En plukkliste har også én verdi mer enn dem du definerte: tom. En post kan stå uten at noe er valgt, og det tar folk. I en formel eller valideringsregel kan du ikke teste en plukkliste med ISBLANK alene; du skriver ISBLANK(TEXT(Field__c)), eller ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Så bestem hva «ingen verdi» betyr for hver plukkliste: er det tillatt, og hva betyr det når det skjer? Sørg så for at formlene, valideringsreglene og filtrene dine håndterer det.

Og noen ganger er et attributt egentlig en entitet. Noen ber om en plukkliste med distribusjonssentre. Det er ni. Enkelt. Så finner vi ut at hvert av dem har en adresse, en leder, åpningstider, kapasitet, en region og lastebiler. Det er ikke en plukkliste; det er en ting. Ikke gjør en entitet om til en plukkliste bare fordi det ikke er mange av dem ennå. Det føles fantastisk det første året og forferdelig det femte. (Modul 5 i kapittel 2 har tommelfingerreglene mine for når en liste fortjener sitt eget objekt.)

Tekstfamilien

Jeg underviser tekst som to typer, og grensen mellom dem går ved 255 tegn.

Opptil 255: lagret med posten. Text rommer opptil 255 tegn, og du kan bruke det nesten overalt: i formler, filtre, rapporter, listevisninger, som unikt felt eller External ID, og det kan indekseres. Text Area rommer også 255, på separate linjer, som et kort notat.

Over 255: lagret via referanse. Text Area (Long) rommer opptil 131 072 tegn, og Text Area (Rich) rommer det samme med formatering, lenker og bilder. Jeg tenker på dem som lagret litt på siden, med en peker i posten, og de oppfører seg slik: ingen indeks, så du kan ikke gjøre dem unike eller til en External ID; du kan ikke filtrere på dem i en SOQL WHERE-klausul (SOQL WHERE (opens in a new tab)); formler kan ikke bruke dem (Formula Field Limits and Restrictions (opens in a new tab)); og rapporter viser bare de første 254 tegnene i et egendefinert felt av denne typen, mens rapportfiltre bare søker i omtrent de første 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Bilder lastet opp i et rik tekst-felt kan være på opptil 1 MB hver, og de teller mot fillagringen, mens teksten teller mot datalagringen (Rich Text Area Field Considerations (opens in a new tab)). Så hvis noen trenger å søke, sortere, matche eller rapportere på verdien, hold den under 255 og la den være et Text-felt.

Text (Encrypted) lagrer opptil 175 tegn i kryptert form, med Classic Encryption. Bruker orgen din Shield Platform Encryption, krypterer du heller et vanlig Text-felt, og mange andre typer kan også krypteres på den måten.

Gi hvert felt en beskrivelse

Min standard: hvert felt får en beskrivelse. Det har jeg ment lenge, og i KI-ens tid betyr det mer enn noen gang: hvert KI-verktøy og hver agent som leser orgen din, leser beskrivelsene for å forstå hva et felt betyr. En tom beskrivelse er en gjetning som venter på å skje. Hva betyr Customer_Status__c? Hvem eier det? Hvor kommer det fra? Kan brukerne redigere det, eller overskriver ERP-systemet det i natt? Om seks måneder husker ikke jeg det, og om tre år vet ikke adminen som vedlikeholder orgen det, med mindre vi fortalte det. Etiketten er ikke dokumentasjon, og det er ikke API-navnet heller.

På objekter som deles mye (Account, Contact, Opportunity) bruker jeg også navneprefikser for spesialfelt, så opphavet og formålet synes i selve navnet: alt ERP-systemet eier, begynner med det samme prefikset, for eksempel. Jeg er ikke ute etter API-navn på tolv ord. Jeg vil at modellen skal forklare seg selv.

Klassifiser det som betyr noe: taksonomifeltene

Salesforce gir hvert felt et sett med klassifiseringsmetadata. Jeg kaller dem taksonomifeltene. Du kan registrere dataeieren (data owner); feltbruken (field usage: Active, DeprecateCandidate, Hidden); datasensitivitetsnivået (data sensitivity level: Public, Internal, Confidential, Restricted, MissionCritical); og samsvarskategoriseringen (compliance categorization): PII, HIPAA, GDPR, PCI, CCPA og andre. De fungerer på standardfelt så vel som egendefinerte (Data Classification Metadata Fields (opens in a new tab)).

Hvorfor bry seg? Fordi prosesser kan lese dem. Merk et felt GDPR, så kan en prosess finne hvert GDPR-felt på en post og maskere eller fjerne det. Og når Salesforces tillitslag (trust layer) sender en ledetekst til en stor språkmodell, kan det bruke nettopp denne klassifiseringen til å maskere sensitive felt: det bytter ut en kundes navn, si «Maria Lopez», med en plassholder på vei ut, modellen ser aldri navnet, og navnet byttes tilbake inn i svaret på vei inn (Einstein Trust Layer (opens in a new tab)).

En oppdatering. Salesforce dokumenterer nå at mønsterbasert og feltbasert maskering for språkmodeller er deaktivert for agenter: maskering kan fjerne konteksten en agent trenger for å svare (Data Masking Limitations in Agentforce (opens in a new tab)). Klassifisering styrer fortsatt maskering for andre generative KI-funksjoner, men ikke regn med at den holder personopplysninger unna en agent; det er en tilgangs- og designbeslutning (kapittel 12).

Mitt standpunkt: klassifisering er viktig på nøkkeltidspunkter. Ikke gjør det om til tre uker med utfylling av hver eneste boks fordi styringen sa det. Bruk det der det betyr noe: personopplysninger, finansielle data, regulerte data og felt der forretningen trenger en navngitt eier. Poenget er at sensitivitet slutter å være kunnskap i hodet til noen og blir en del av feltet.

Utover eksamen: hva KI endrer. Dårlig feltdokumentasjon pleide å straffe neste admin. Nå villeder den hvert KI-verktøy og hver agent som leser skjemaet: er Flag2__c sensitivt, autoritativt, fortsatt i bruk? KI lager også felt raskere enn noe team, så navn, beskrivelser og klassifisering er en del av arkitekturen, ikke husarbeid.

Hvert felt er en forpliktelse

Når et felt først er ute og samler inn data, begynner alt å lene seg på det. Skjermer viser det, flows forgrener seg på det, valideringsregler sjekker det, rapporter grupperer etter det, integrasjoner sender og leser det, og nå resonnerer KI-verktøy om det. Hver av dem gjør antakelser om feltet: typen, lengden, om det noen gang er tomt, og hva verdiene betyr. Endrer du feltet senere, må du finne hver av de antakelsene først. Å gi nytt navn til en plukklisteverdi, korte ned et tekstfelt eller gjøre et Text-felt om til en plukkliste høres ut som en liten endring, og det kan ødelegge en integrasjon i et annet selskaps system. Det er derfor et felt er en forpliktelse.

Click to enlarge

Jeg vil ikke at du forlater denne modulen redd for å lage felt. Salesforce er bygd for å utvides; bruk det. Jeg vil at spørsmålet skal endre seg fra «hvilken felttype skal jeg velge?» til «hva betyr disse dataene, og hvilken oppførsel forplikter vi oss til?» Type, obligatorisk, unik, External ID, plukkliste, formel, beskrivelse, klassifisering: sammen er de det fysiske uttrykket for den logiske modellen fra kapittel 2.

Hva en arkitekt bestemmer her

• Hva verdien betyr før felttypen velges, og om den er et attributt, en identifikator, et kontrollert vokabular eller egentlig en annen entitet.
• Om en verdi er en nåværende beregning som kan avledes, eller et historisk faktum som må lagres.
• Hvilket system som eier hver identifikator, og om unikheten er et ekte forretningsløfte.
• Når en obligatorisk verdi faktisk er kjent, og hva som skjer med poster og integrasjoner som ikke har den.
• Hvilken beskrivelse, navngivning og klassifisering feltet trenger, så mennesker, prosesser og KI kan bruke det trygt.

Les mer

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab), på engelsk, kontrollert 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, kontrollert 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Help, Picklist Limitations (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab), på engelsk, kontrollert 2026-10-02.