Fält är också arkitektur

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 6 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Välj rätt objekt · Nästa: Relationer får konsekvenser

Frågan den här modulen besvarar: Hur ska Salesforce fysiskt representera varje bit data?

Att skapa ett fält tar ungefär en minut. New Field, välj en typ, ge det ett namn, Next, Next, Save. Det är just därför fält inte behandlas som arkitektur.

Gå in i en org som har funnits i tio år och öppna konto (Account). Femhundra fält. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tre olika kundnummer. En kryssruta som ingen vågar radera eftersom ingen vet vilken integration som fortfarande använder den. Att skapa fältet tog en minut. Att leva med det tar år. Så idén med den här modulen är enkel: ett fält är ett arkitekturbeslut. Inte alltid ett stort, men varje fält kodar in något om betydelsen, beteendet, identifieringen eller kvaliteten hos data, och precis som objekt är fält lätta att lägga till och förvånansvärt svåra att ta bort.

Vad betyder de här data egentligen?

I kapitel 2 gav vi våra entiteter attribut: en leverans har ett planerat tidsfönster, en lastbil har ett chassinummer (VIN). Nu implementerar vi dem, och det är här folk hoppar direkt till ”textfält”. Vänta. Före typen vill jag veta vad data betyder. Är det ett tal, eller en identifierare som råkar innehålla siffror? Ett datum, eller en tidpunkt? Fritext, eller ett av ett godkänt urval? Inmatat av en person, eller ägt av ett annat system? Kan det ändras? Måste det vara unikt? Kan det saknas? Ska det lagras över huvud taget, eller beräknas? Det är inga Setup-frågor. Det är dataarkitekturfrågor, och fälttypen kommer efter att vi har besvarat dem.

Ett nummer är inte alltid ett tal

Steve Trucking ger varje lastbil ett flottnummer, säg 001247. Number-fält? Förmodligen inte. Adderar vi flottnummer? Är lastbil 1247 minus lastbil 1246 en lastbil? Det är en identifierare som råkar innehålla siffror, och ett Number-fält skulle till och med ta bort de inledande nollorna. Samma sak gäller postnummer, produktkoder, kontonummer och spårningsnummer. Hur värdet ser ut säger inte vad det betyder. Välj typen efter beteendet du behöver, inte efter hur exempeldata ser ut.

Behöver en människa identifiera den?

Varje anpassat objekt får ett Name-fält, och det första beslutet är text eller Auto Number. Jag frågar: behöver en människa identifiera den här saken? Folk känner en detaljhandelspartner till namnet och en lastbil till dess flottnummer. Men ett manifest som systemet genererar varje natt? Ingen ska behöva skriva ”Manifest 10-02 nummer 3” för att Salesforce krävde ett Name. Ge det ett Auto Number. Blanda bara inte ihop det genererade namnet med det som identifierar posten: Auto Number hjälper användarna, Salesforce-ID:t identifierar posten, och detaljhandelspartnerns egen manifestreferens kan identifiera samma sak över flera system. Tre olika jobb.

Skärmen med detaljerna

Välj en typ, klicka på Next, så frågar Setup efter detaljerna. Det är på den här skärmen de flesta besluten i modulen faktiskt fattas, oftast i all hast.

New Custom Field, steg 2: detaljerna (skärmdump, 2026-10-12). Full storlek

Två rutor ser likadana ut men gör olika jobb. Description (beskrivning) är för dem som underhåller orgen, och numera för AI-verktygen som läser den: vad fältet betyder, vem som äger det, var det kommer ifrån. Help Text (hjälptext) är för användaren vid skärmen: vad ska skrivas här. Fyll i båda. Sedan kommer Required, Unique och External ID, och var och en förtjänar ett eget avsnitt. Under dem kan Default Value (standardvärde) vara en formel, så att en ny post kan börja med ett rimligt värde i stället för ett tomt.

Required är ett större beslut än det ser ut

Det finns en liten kryssruta i fältguiden som heter Required (obligatoriskt), och som vi såg i kapitel 1 kan den vara en tidsinställd bomb. Du har haft ett objekt i fem år med två miljoner poster, och nu bestämmer någon att ett nytt fält alltid måste ha ett värde. Hur blir det med de två miljoner poster som är äldre än fältet? Integrationerna som inte skickar det? Automatiseringen som skapar posten innan värdet är känt? Processen där värdet dyker upp först tre steg senare?

”Obligatoriskt” låter som ett beslut om datakvalitet, och ibland är det det. Men när ett värde blir känt är en del av affärsprocessen. Så kryssa inte i Required för att någon säger ”det vill vi alltid ha”. Fråga när det blir känt, vem som tillhandahåller det och vad som händer när det inte finns. Vi placerar det här på hela konsistensstegen i modul 7.

Unique betyder också något

Om jag markerar ett fält som unikt gör jag ett påstående om verksamheten: inte ”det upprepas oftast inte”, utan ”två poster får aldrig ha det här värdet”. Det är starkt. Och skärmen tvingar dig att bestämma en sak till: är ”ABC” och ”abc” samma värde eller olika? Skiftlägesokänsligt är det säkrare standardvalet för allt som en person skriver. Nyckelregeln från kapitel 2, unik, oföränderlig, betydelselös, aldrig personuppgifter (PII), gäller här. Om någon säger att de anställdas e-postadress är unik börjar jag fråga: kan den ändras, kan någon sluta och komma tillbaka, kan adresser återanvändas, vad händer efter ett företagsförvärv? E-post kan vara användbart, till och med unikt i dag. Det gör det inte till en bra nyckel.

External ID: identifiering över gränsen

Det är här External ID gör skäl för sig. Skärmen beskriver det bra: fältet blir den unika postidentifieraren från ett externt system. ERP-systemet har kund 873492; Salesforce har sitt eget post-ID. När ERP-systemet skickar en uppdatering, hur vet vi vilken post den hör till? Markera ett fält som External ID så kan en integration göra upsert på det: skapa posten om den inte finns, uppdatera den om den finns (Upsert a Record Using an External ID (opens in a new tab)). Och när du laddar barnposter kan du peka på föräldern via dess External ID i stället för att först fråga efter Salesforce-ID:t. Jag brukar säga att du låter Salesforce göra uppslaget åt dig. Väldigt kraftfullt.

Lägg märke till att ERP-systemets nummer inte blir Salesforce-postens ID. Det är ett attribut, och en post kan bära flera: ett kund-ID från ERP, ett legacy-ID, en partners ID. Det är helt i sin ordning. En affärsentitet kan vara känd på olika sätt i flera system. Arkitekturfrågan är vilket system som äger varje identifierare, och vilket löfte det ger: markera den som unik bara om verksamheten verkligen garanterar det.

Fälttyp för fälttyp

Nu till själva typerna. Öppna New Field på vilket objekt som helst så visar Setup hela listan, grupperad på det sätt jag går igenom den: fälten som Salesforce beräknar åt dig, relationsfälten och sedan datatyperna.

Setup, New Custom Field, steg 1: datatyperna (skärmdump, 2026-10-12). Full storlek

Här är hela listan i en överblick, med det enda jag vill att du kommer ihåg om varje typ.

Grupp	Typ	Kom ihåg
Beräknade	Auto Number	Upp till 30 tecken, varav 20 prefix eller suffix; en etikett för människor, inte postens identifierare
	Formula	Beräknas när det läses, lagras inte; 3 900 tecken
	Roll-Up Summary	Antal, summa, min eller max av detaljposterna; bara master-detail
Relationer	Lookup, Master-Detail, External Lookup	Modul 7
Data	Checkbox	Sant eller falskt, med ett standardvärde du väljer; null kan ändå dyka upp i flöden
	Number, Percent, Currency	Avrundningsregler; inledande nollor försvinner; 15 decimaler
	Date, Date/Time, Time	En dag, en tidpunkt eller en tid på dygnet; tidpunkter lagras i UTC
	Email, Phone, URL	Formateras och kontrolleras när posten sparas: 80, 40 och 255 tecken
	Geolocation, Address	Sammansatta fält som kostar mer än ett fält: 3 och 9
	Picklist, Multi-Select	Ett kontrollerat vokabulär, ägt av en admin
	Text, Text Area, Long, Rich, Encrypted	Upp till 255 på posten och indexerbart; över det inget index och ingen filtrering

Fälten som Salesforce beräknar

Auto Number ger varje ny post nästa nummer i en sekvens, i ett format du definierar, som T-{000000}. Använd det när en människa behöver ett smidigt handtag och ingen ska behöva hitta på ett. Hela värdet är upp till 30 tecken, och 20 av dem är reserverade för prefixet eller suffixet. Kom bara ihåg från kapitel 2: det är en etikett för människor, inte postens identifierare, och numren är inte alltid strikt i följd.

Formula-fält (formelfält) beräknar ett värde från andra fält. De är kraftfulla, och de beräknas när posten läses, inte när den sparas, så det finns inget lagrat som kan bli inaktuellt. Du väljer vad formeln returnerar: checkbox, valuta, datum, datum/tid, tal, procent, text eller tid.

New Custom Field, formel: välja returtyp (skärmdump, 2026-10-12). Full storlek

Sedan skriver du själva formeln, med fält, operatorer och funktioner, och kontrollerar syntaxen. Lägg märke till knappen Use Formula Assistant: Salesforce AI hjälper dig nu att skriva formeln. Använd den, och läs sedan vad den skrev. Det är du som äger formeln, inte assistenten.

Formeleditorn, med Formula Assistant (skärmdump, 2026-10-12). Full storlek En formel kan vara upp till 3 900 tecken, och den får inte överstiga 15 000 byte när den sparas eller kompileras; en lång formel kan delas upp på flera formelfält som refererar till varandra. Långa textområden, krypterade fält och Description-fält kan inte användas i dem.

Roll-Up Summary-fält (sammanställningsfält) sitter på mastern och räknar, summerar eller tar minimum eller maximum av dess detaljposter. De fungerar bara över en master-detail-relation, vilket är en av de största anledningarna att välja master-detail över huvud taget. Vi återkommer till dem, och deras begränsningar, i modul 7.

Lagrat eller härlett?

Behöver vi lagra det här värdet över huvud taget? Om jag har antal och styckpris, behöver någon, eller någon automatisering, underhålla en totalsumma? Kanske ska en formel härleda den: en källa för beräkningen, omräknad när den läses, så ändra antalet och svaret följer med. Formler har egna gränser (sparad storlek och visad längd; Formula Field Limits and Restrictions (opens in a new tab)), och komplexa formler blir svåra att underhålla.

Men ibland vill verksamheten inte ha dagens svar. Den vill ha svaret som det var. Om rabattregeln ändras nästa år, ska förra årets faktura plötsligt visa ett annat belopp? Självklart inte. Så frågan är inte ”kan Salesforce beräkna det här?”. Den är ”är det här en aktuell beräkning eller ett historiskt faktum?” Historiska fakta lagras.

Relationsfälten

Lookup-, Master-Detail- och External Lookup-relationer är också fält, och det är där linjerna i din modell blir verkliga. Lookupen är den lösa länken; master-detail knyter barnets liv, ägarskap och säkerhet till föräldern; den externa lookupen når ett externt objekt från modul 4 och matchar på dess External ID. Att välja mellan dem är ett tillräckligt stort beslut för att få en egen modul.

Checkbox

En checkbox (kryssruta) är det enklaste fält som finns: sant eller falskt, ikryssad eller inte. Den är perfekt för ett ja/nej-faktum om posten: Is Active, Install Required, Signed For. När du skapar en tvingar Salesforce dig att välja dess standardvärde, ikryssad eller inte, och det är ett verkligt beslut: det är vad varje ny post börjar med, inklusive poster som en integration skapar utan att skicka fältet. Rapporter och listvyer filtrerar det som True och False; importverktygen och den veckovisa exporten visar det som 1 och 0.

En fälla att känna till. Fältet på posten har två värden, men automatiseringen runt det kan ha ett tredje. I ett flöde är en checkbox-variabel som aldrig har satts null, inte false, och att spara den till en post misslyckas (Trailblazer Community (opens in a new tab); se även Salesforces kända problem W-11208535 (opens in a new tab)). Välj ett rimligt standardvärde, och låt dina flöden och din kod hantera null med avsikt.

Number, Percent och Currency

Number lagrar ett reellt tal och tar bort eventuella inledande nollor, vilket är just därför ett flottnummer som 001247 inte är ett Number. Salesforce avrundar talfält halvt bort från noll: 12,345 blir 12,35, och −12,345 blir −12,35. Och i sammanslagningsfält (merge fields) avrundas det enligt användarens språkinställning, inte enligt de decimaler du har satt på fältet.

Percent lagrar ett decimaltal och visar en procentsats: skriv 0,10 så ser du 10 %. Värden förlorar precision efter 15 decimaler.

Currency formateras för pengar, och i en org med flera valutor bär det sin valutakod och kan använda växelkurser; med advanced currency management (opens in a new tab) kan affärsmöjligheter använda daterade växelkurser, kursen för perioden då affären stängdes. Bara affärsmöjligheter och det som hör till dem (produkter, scheman, uppdelningar och deras rapporter) använder daterade kurser; valutafält på andra objekt behåller den enda statiska kursen. Se upp med avrundningen: utan decimaler trunkerar Salesforce helt enkelt (23,5 blir 23); med en eller flera avrundar det halvt bort från noll.

Date, Date/Time och Time

Tre typer, tre olika betydelser. Ett Date är en dag: ett avtal löper ut ett visst datum. Ett Date/Time är en tidpunkt: leveransen kom fram 09.42 den morgonen. En Time är en tid på dygnet helt utan datum: butiken öppnar 07.00, varje dag.

Fällan är tidpunkten. Salesforce lagrar datum/tid-värden i GMT (UTC). Tiden en användare skriver läses i användarens tidszon, konverteras och lagras; när någon läser den konverteras den igen till läsarens tidszon. För det mesta är det precis vad du vill. Men här är exemplet jag ger i klassrummet: en samordnare i Los Angeles registrerar en leverans sent på söndagskvällen, kl. 22.00 Pacific-tid. Under ytan lagrade Salesforce måndag morgon, 05.00 GMT. En rapport grupperad per dag i en annan tidszon, eller en integration som läser det råa värdet, kan lägga den där söndagsleveransen på måndagen. ”Dagen det hände” beror på vems klocka du frågar. Håll koll på användarnas tidszoner, och bestäm vilken verksamheten menar.

Och var försiktig när du jämför dem. Under ytan är ett datum/tid-värde ett enda stort tal: Apex läser det som antalet millisekunder sedan 1 januari 1970, 00.00.00 GMT (Datetime Class (opens in a new tab)). Det är en exakt tidpunkt, inte en dag. Så att fråga om två datum/tid-värden är lika (==) gör nästan aldrig det du vill: 09.42.00 och 09.42.01 är inte lika, och det är inte heller ”måndag” och en godtycklig tidpunkt på måndagen. Fråga i stället efter ett intervall: från och med början (>=) och till och med slutet (<=). ”Alla leveranser på måndag” är alla leveranser >= måndag 00.00 och <= måndag 23.59.59, i den tidszon du har bestämt att verksamheten menar.

Och en rolig sak: Salesforce kan inte lagra vilket datum som helst. Giltiga datum går från 1 januari 1700 till och med 31 december 4000, och Salesforce anger samma intervall för datum och datum/tid (Data Import Dates (opens in a new tab)). Även gränserna är tidpunkter i GMT, så för en användare i Pacific-tid är det tidigaste giltiga värdet kl. 16.00 den 31 december 1699. Din hembygdsförenings grundandedatum kanske inte får plats. Och det klassiska tricket för ”inget slutdatum”, 31 december 9999, avvisas; behöver du en platshållare långt fram i tiden måste den ligga år 4000 eller tidigare.

Email, Phone och URL

Det här är de formaterade fälten, och de gör mer än att lagra tecken. Email rymmer upp till 80 tecken och kontrolleras för korrekt format; på kontakter och leads startar ett klick på det ett e-postmeddelande till den adressen. Phone rymmer upp till 40 tecken, formateras som ett telefonnummer och blir klicka-för-att-ringa när orgen har ett telefonsystem anslutet. URL rymmer upp till 255 tecken och öppnas som en länk. Det är plattformen som ger dig beteende gratis, och därför skulle jag aldrig lagra ett telefonnummer i ett vanligt textfält.

Integrationer kontrolleras också. Ett värde som inte matchar fältets format, till exempel en felaktigt formaterad e-postadress, misslyckas i valideringen, och hela posten avvisas, inte bara det fältet. Så när källsystemets data är röriga, städa dem innan de kommer fram, eller planera för posterna som inte går att ladda.

Geolocation och Address

Geolocation rymmer en latitud och en longitud. Under ytan är ett fält som heter Location__c egentligen två värden som du kan läsa och sätta var för sig, Location__Latitude__s och Location__Longitude__s. Och du kan ställa frågor på det: SOQL-funktionerna DISTANCE och GEOLOCATION hittar poster inom en radie, eller sorterar dem efter hur långt bort de är. ”Alla öppna leveranser inom 25 miles (cirka 40 km) från den här lastbilen” är en enda fråga: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address rymmer en hel adress, gata, ort, delstat eller provins, postnummer och land, och användare kan söka efter en adress och få delarna ifyllda.

Båda är sammansatta fält (compound fields): ett fält på skärmen, flera under ytan. Och de kostar mer än ett fält mot objektets gräns: en Geolocation räknas som tre anpassade fält, och en Address räknas som nio. På ett objekt som redan är trångt spelar det roll.

Plocklista och flervalsplocklista

En plocklista (picklist) styr vad användarna kan mata in: ett värde ur en lista som du definierar. Status? Plocklista, förmodligen. Men värdena är metadata, och en admin måste lägga till eller ändra dem. Så jag frågar ändå vem som äger värdena, hur ofta de ändras, om flera objekt behöver samma lista, om värdena bär egen information och om ett annat system äger vokabulären.

Var värdena bor är också ett beslut. När en lista används en gång, på ett fält, behåll värdena på själva fältet, på objektet; det är vad Salesforce gör som standard. Men när samma uppsättning värden börjar dyka upp på flera ställen, en region på kontot, på leveransen och på lagret, lyft upp den till en global värdeuppsättning innan kopiorna glider isär. En global värdeuppsättning (global value set) håller en lista för dem alla, upp till 1 000 värden, aktiva och inaktiva sammanlagt (Picklist Limitations (opens in a new tab)). Setups egen beskrivning säger varför det spelar roll: värdeuppsättningen är begränsad så att användare inte kan lägga till icke godkända värden via API:et. En lista, en ägare, och ingen integration som smyger in en ny stavning.

Den sista punkten är skillnaden mellan begränsad (restricted) och obegränsad (unrestricted). På en begränsad plocklista tillåts bara de värden som en admin har definierat, varifrån de än kommer: en användare, en import eller en integration som skickar något annat får ett fel, ”bad value for restricted picklist field”, och posten sparas inte. På en obegränsad plocklista väljer användarna fortfarande ur listan på skärmen, men API:et, importer och automatisering kan skicka vilket värde som helst, och Salesforce sparar det och lägger till det som ett inaktivt värde (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Det är så en org får både ”Delivered”, ”delivered” och ”Dlvrd”. Globala värdeuppsättningar är alltid begränsade. Mitt standardval är begränsad; obegränsad är ett medvetet val för när ett annat system verkligen äger värdena, och då äger någon städningen av de inaktiva.

Setup, Picklist Value Sets: en ny global värdeuppsättning (skärmdump, 2026-10-12). Full storlek

En flervalsplocklista (multi-select picklist) låter en användare välja flera värden, som lagras tillsammans åtskilda av semikolon. Smidigt på en skärm, krångligt överallt annars: svårare att filtrera, rapportera och integrera på, och den kan inte användas i filtret för ett sammanställningsfält. Flera värden för en post betyder oftast lärdomen från kapitel 2: det finns ett barnobjekt som försöker ta sig ut.

En plocklista har också ett värde till utöver de du definierade: tomt. En post kan stå utan något valt, och det överraskar folk. I en formel eller valideringsregel kan du inte testa en plocklista med bara ISBLANK; du skriver ISBLANK(TEXT(Field__c)) eller ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Så bestäm vad ”inget värde” betyder för varje plocklista: är det tillåtet, och vad betyder det när det händer? Se sedan till att dina formler, valideringsregler och filter hanterar det.

Och ibland är ett attribut egentligen en entitet. Någon ber om en plocklista med distributionscentraler. De är nio. Enkelt. Sedan får vi veta att var och en har en adress, en chef, öppettider, kapacitet, en region och lastbilar. Det är ingen plocklista; det är en sak. Gör inte en entitet till en plocklista bara för att de inte är så många än. Det känns toppen år ett och hemskt år fem. (Modul 5 i kapitel 2 har mina tumregler för när en lista förtjänar ett eget objekt.)

Textfamiljen

Jag undervisar om text som två sorter, och gränsen mellan dem går vid 255 tecken.

Upp till 255: lagras med posten. Text rymmer upp till 255 tecken, och du kan använda det nästan överallt: i formler, filter, rapporter, listvyer, som unikt fält eller External ID, och det kan indexeras. Text Area rymmer också 255, på separata rader, som en kort anteckning.

Över 255: lagras via referens. Text Area (Long) rymmer upp till 131 072 tecken, och Text Area (Rich) rymmer lika mycket med formatering, länkar och bilder. Jag tänker på dem som lagrade vid sidan av, där posten håller en pekare, och de beter sig så: inget index, så du kan inte göra dem unika eller till External ID; du kan inte filtrera på dem i en SOQL-WHERE-sats (SOQL WHERE (opens in a new tab)); formler kan inte använda dem (Formula Field Limits and Restrictions (opens in a new tab)); och rapporter visar bara de första 254 tecknen i ett anpassat sådant fält, där rapportfilter bara söker i ungefär de första 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Bilder som laddas upp i ett rich text-fält kan vara upp till 1 MB styck, och de räknas mot fillagringen, medan texten räknas mot datalagringen (Rich Text Area Field Considerations (opens in a new tab)). Så om någon behöver söka, sortera, matcha eller rapportera på värdet, håll det under 255 och håll det som ett Text-fält.

Text (Encrypted) lagrar upp till 175 tecken i krypterad form, med Classic Encryption. Om din org använder Shield Platform Encryption krypterar du i stället ett vanligt Text-fält, och många andra typer kan också krypteras på det sättet.

Ge varje fält en beskrivning

Min standard: varje fält får en beskrivning. Det har jag trott på länge, och i AI:s tid spelar det större roll än någonsin: varje AI-verktyg och agent som läser din org läser beskrivningarna för att förstå vad ett fält betyder. En tom beskrivning är en gissning som väntar på att hända. Vad betyder Customer_Status__c? Vem äger det? Var kommer det ifrån? Kan användarna redigera det, eller skriver ERP-systemet över det i natt? Om sex månader minns jag inte, och om tre år vet inte den admin som underhåller orgen, om vi inte berättade det. Etiketten är ingen dokumentation, och det är inte API-namnet heller.

På hårt delade objekt (konto, kontakt, affärsmöjlighet) använder jag också namnprefix för specialfält, så att deras ursprung och syfte syns i själva namnet: allt som ERP-systemet äger börjar till exempel med samma prefix. Jag är inte ute efter API-namn på tolv ord. Jag vill att modellen förklarar sig själv.

Klassificera det som spelar roll: taxonomifälten

Salesforce ger varje fält en uppsättning klassificeringsmetadata. Jag kallar dem taxonomifälten. Du kan registrera dataägaren (data owner); fältanvändningen (field usage: Active, DeprecateCandidate, Hidden); datakänslighetsnivån (data sensitivity level: Public, Internal, Confidential, Restricted, MissionCritical); och regelefterlevnadskategoriseringen (compliance categorization): PII, HIPAA, GDPR, PCI, CCPA med flera. De fungerar på standardfält lika väl som på anpassade (Data Classification Metadata Fields (opens in a new tab)).

Varför bry sig? För att processer kan läsa dem. Flagga ett fält som GDPR så kan en process hitta varje GDPR-fält på en post och maskera eller ta bort det. Och när Salesforces trust layer skickar en prompt till en stor språkmodell kan den använda exakt den här klassificeringen för att maskera känsliga fält: den byter ut en kunds namn, säg ”Maria Lopez”, mot en platshållare på vägen ut, modellen ser aldrig namnet, och namnet byts tillbaka i svaret på vägen in (Einstein Trust Layer (opens in a new tab)).

En uppdatering. Salesforce dokumenterar nu att mönsterbaserad och fältbaserad maskering för LLM:er är avstängd för agenter: maskering kan ta bort det sammanhang som en agent behöver för att svara (Data Masking Limitations in Agentforce (opens in a new tab)). Klassificeringen styr fortfarande maskeringen för andra generativa AI-funktioner, men räkna inte med att den håller personuppgifter borta från en agent; det är ett beslut om åtkomst och design (kapitel 12).

Min hållning: klassificering är viktig vid nyckeltillfällen. Gör det inte till tre veckors ifyllande av varje ruta för att styrningen sa det. Använd den där den spelar roll: personuppgifter, finansiella data, reglerade data och fält där verksamheten behöver en namngiven ägare. Poängen är att känsligheten slutar vara kunskap i någons huvud och blir en del av fältet.

Bortom provet: vad AI förändrar. Dålig fältdokumentation brukade straffa nästa admin. Nu vilseleder den varje AI-verktyg och agent som läser schemat: är Flag2__c känsligt, auktoritativt, fortfarande i bruk? AI skapar också fält snabbare än något team, så namn, beskrivningar och klassificering är en del av arkitekturen, inte städning.

Varje fält är ett åtagande

När ett fält väl är ute och samlar data börjar allt luta sig mot det. Skärmar visar det, flöden förgrenar sig på det, valideringsregler kontrollerar det, rapporter grupperar på det, integrationer skickar och läser det, och nu resonerar AI-verktyg om det. Var och en av dem gör antaganden om fältet: dess typ, dess längd, om det någonsin är tomt och vad dess värden betyder. Ändrar du fältet senare måste du först hitta varenda ett av de antagandena. Att byta namn på ett plocklistvärde, korta ett textfält eller göra om ett Text-fält till en plocklista låter som en liten ändring, och det kan knäcka en integration i ett annat företags system. Därför är ett fält ett åtagande.

Click to enlarge

Jag vill inte att du lämnar den här modulen rädd för att skapa fält. Salesforce är byggt för att byggas ut; använd det. Jag vill att frågan ändras från ”vilken fälttyp ska jag välja?” till ”vad betyder de här data, och vilket beteende förbinder vi oss till?” Typ, obligatoriskt, unikt, External ID, plocklista, formel, beskrivning, klassificering: tillsammans är de det fysiska uttrycket för den logiska modellen från kapitel 2.

Vad en arkitekt bestämmer här

• Vad värdet betyder innan fälttypen väljs, och om det är ett attribut, en identifierare, ett kontrollerat vokabulär eller egentligen en annan entitet.
• Om ett värde är en aktuell beräkning som kan härledas eller ett historiskt faktum som måste lagras.
• Vilket system som äger varje identifierare, och om dess unikhet är ett verkligt löfte från verksamheten.
• När ett obligatoriskt värde faktiskt blir känt, och vad som händer med poster och integrationer som inte har det.
• Vilken beskrivning, namngivning och klassificering fältet behöver för att människor, processer och AI ska kunna använda det säkert.

Utforska vidare

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