Ordlista, härkomst och klassificering
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)
Modul 3 av 6 i kapitlet Datakvalitet och styrning, kapitel 5 i kursen Data Architect. Varje modul står på egna ben. Föregående: Håll dåliga data ute · Nästa: Integritetslagar formar designen
Frågan den här modulen besvarar: Hur fångar du vad data betyder, var de kom ifrån och hur känsliga de är?
Du har ärvt en org. Konto (Account) har 900 fält, bland dem Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c och Account_Status__c. Vilket av dem säger dig om någon faktiskt är kund? Du öppnar beskrivningarna. Tre är tomma. En säger ”Customer Type”. Tack så mycket. En säger att fältet kom från ERP:t; ett annat skapades för sex år sedan av någon som för länge sedan har slutat. Tänk dig nu att du inte är arkitekten utan en integration, ett rapportteam eller en agent. Organisationen har gott om data. Det betyder inte att den vet vad data betyder.
Det är där metadata blir arkitektur, genom tre frågor som hänger ihop men inte är desamma:
- Ordlista: vad betyder de här data?
- Härkomst (lineage): var kom de ifrån?
- Klassificering: hur måste de hanteras?
Två typer av metadata
Section titled “Två typer av metadata ”Metadata finns i två typer, och du behöver båda. Affärsmetadata är vad data betyder för verksamheten: definitionen, ägaren, reglerna för att använda dem, hur känsliga de är. Teknisk metadata är hur data är byggda och rör sig: objektet och fältet, typen och längden, API-namnet, schemat, mappningen från ett system till ett annat, härkomsten från källa till mål. Ett fälts API-namn och typ säger en utvecklare hur fältet ska användas; dess definition och ägare säger alla andra om det ska användas. När de säger emot varandra, eller när en av dem saknas, är det där integrationer och rapporter går fel.
Provkunskap. Skilj på affärsmetadata (betydelse, definitioner, ägare, regler, känslighet: affärsordlistan och klassificeringen) och teknisk metadata (objekt, fält, typer, API-namn, scheman, mappningar och härkomst).
Börja med betydelsen
Section titled “Börja med betydelsen ”Kapitel 3 satte regeln: varje fält får en beskrivning. Inte ”Customer Status” för ett fält som heter Customer Status, utan något i stil med ”Partnerns nuvarande kommersiella relation med Steve Trucking. Sätts från ERP:t efter aktivering. Använd inte för att kvalificera prospekt.” Nu vet jag vad det betyder, var det kommer ifrån och vad det inte ska användas till. Det är början på en affärsordlista: gemensamma definitioner för de data som spelar roll. Vad är en kund? En aktiv kund? Vad betyder Levererad? Vad räknas som i tid? Det låter självklart tills du sätter fem avdelningar i samma rum: Ekonomi har en definition, Försäljning en annan, Drift en tredje, datalagret en fjärde, och någon har byggt en instrumentpanel på en femte. Problemet är inte att ingen talar samma språk. Det är att företaget inte har kommit överens om betydelsen.
En ordlista kan bo i ett kalkylark eller ett dokumentationsverktyg, men dess viktiga definitioner behöver finnas nära där människor använder data. I plattformen är det fältbeskrivningar, hjälptext och klassificeringsmetadata. I analys spelar det ännu större roll: ”intäkter” kan inte betyda en sak på ledningens instrumentpanel och en annan i en analytikers fråga. Det är vad ett semantiskt lager är till för, och de semantiska modellerna i Data 360 håller styrda definitioner som mått, dimensioner och relationer ovanför de fysiska data (Create a Semantic Model in Data 360 (opens in a new tab)). Tekniken ändras; kravet gör det inte: viktiga data behöver en överenskommen betydelse.
Och börja med betydelsen, inte tekniken. En ordlista som börjar med objekt, fält, typ och API-namn dokumenterar implementeringen. En som börjar med affärsbegrepp dokumenterar företaget:
| Affärsbegrepp | Betydelse | Var det representeras |
|---|---|---|
| Detaljhandelspartner (Retail Partner) | En återförsäljare som Steve Trucking levererar åt, enligt avtal | Konto i Salesforce; kund i ekonomins ERP |
| Leverans (Delivery) | En leverans till en mottagare, på en adress, en dag | RouteDesk i dag; en arbetsorder när leveranserna flyttar in i Salesforce |
| Mottagare (Recipient) | Personen som tar emot en leverans | Mottagarens uppgifter på leveransen |
| Levererad | Slutförd enligt den överenskomna operativa definitionen | Leveransstatus |
| Leverans i tid | Slutförd inom det överenskomna leveransfönstret | Härlett mått |
En betydelse, många tekniska representationer.
Fråga sedan var de kom ifrån
Section titled “Fråga sedan var de kom ifrån ”När jag väl vet vad ett värde betyder vill jag veta var det kom ifrån. Det är härkomst. En partners juridiska namn i Salesforce: skrev en säljare in det, skickade ERP:t det, omvandlade en integration det, enhetliggjorde Data 360 det, beräknades det, genererade AI det? Det påverkar hur mycket jag litar på det och vad jag får göra med det. Kom ihåg de provisoriska posterna i modul 2: två konton kan båda säga ”Keystone”, det ena skapat av en säljare i går, det andra från ERP:t med en auktoritativ identifierare. Samma text, olika härkomst, olika hantering.
Härkomst är inte bara en dataingenjörs diagram över tusen tabeller. För viktiga data vill jag kunna svara på praktiska frågor: var började de, vilket system är auktoritativt, vad omvandlade dem, vilka system fick kopior, vad ändrade dem senast, och kan jag spåra ett härlett värde tillbaka till dess källor? Landskapet i kapitel 4 säger att systemen är sammankopplade. Härkomsten säger vad som hände med data på vägen.
En del härkomst får du gratis: ERP-ID:t på kontot, Created By och Last Modified By, integrationsloggar, mappningsdokument. Data 360 lägger till härkomstfält på sina dataobjekt som registrerar datakällan och källobjektet för varje post (Data Lineage Fields (opens in a new tab)). Men anta inte att härkomst uppstår för att system är integrerade. Ibland är den mest användbara härkomsten ett enda fält: Source System = Keystone. Och om källan spelar roll för styrningen, gör den mekaniskt tillförlitlig, satt av integrationen, inte inskriven av en människa.
Härledda data behöver härkomst allra mest. Säg att Steve Trucking beräknar en risk för sen leverans utifrån lastbilens position, leveransfönstret och rutthistoriken, och att trafikledningen använder den för att prioritera. Var kom ”hög” ifrån? Lägg till en agent som säger till en mottagare ”din leverans är försenad”, så behöver du veta vad som låg till grund för det, och hur färskt det var. Ju längre du rör dig från lagrade värden till beräknade, enhetliggjorda, förutsagda och genererade värden, desto mer spelar härkomsten roll.
Klassificering besvarar en annan fråga
Section titled “Klassificering besvarar en annan fråga ”Nu: hur ska de hanteras? Mottagarens namn, leveransadress, telefonnummer, leveransanteckningar, leveransstatus, lastbilsnummer, distributionscentral, detaljhandelspartner, foto: de är inte lika känsliga. ”Ute för leverans” är inte ett telefonnummer, och en DC-kod är inte ett foto från insidan av någons hem. Salesforce låter dig registrera det här på varje fält, standard eller anpassat: Data Owner, Field Usage, Data Sensitivity Level och Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Kapitel 3 kallade dem taxonomifälten och förklarade varför de spelar roll: flagga ett fält som PII eller GDPR så kan processer hitta det, från maskeringsverktyg till AI-förtroendelagret i Salesforce, som kan hindra flaggade värden från att nå en stor språkmodell. En varning från kapitel 3: Salesforce stänger nu av den LLM-maskeringen för agenter, eftersom den kan ta bort kontext som en agent behöver (Klassificera det som spelar roll: taxonomifälten). Så klassificeringen måste fortfarande styra de andra kontrollerna.
Min hållning här är medveten: klassificera de känsliga fälten, inte alla fält. Jag vill inte att tre månader läggs på att klassificera tusentals fält så att någon kan rapportera ”100 % klassificerat” och ingen använder det. Mottagarens telefonnummer: ja. Hemadress: ja. Leveransanteckningar som kan innehålla portkoder och ”hund på gården”: ja. Foton som kan visa människor eller ett hem: absolut. En intern visningsetikett? Inte där styrningens energi ska gå. Det gör inte odokumenterade fält acceptabla. Två olika jobb: dokumentation är bred; klassificering är medveten. Det är det som håller klassificeringen meningsfull.
En taxonomi som människor kan använda
Section titled “En taxonomi som människor kan använda ”Klassificering behöver ett ordförråd, en taxonomi. Salesforce standardvärden är Public, Internal, Confidential, Restricted och MissionCritical; din organisation kanske vill ha egna etiketter. Jag föreskriver dem inte. Håll dem begripliga: om det finns 47 kategorier och ingen utanför dataskyddsteamet kan skilja kategori 31 från 32, hjälper det inte. En bra taxonomi kopplar en etikett till ett beteende. Om ett fält innehåller känsliga personuppgifter, vem får se det, får det gå till en sandbox, lämna regionen, synas i analyser, hur länge sparas det, får en agent använda det? Nu gör klassificeringen nytta.
Klassificering utan genomdrivande är dekoration
Section titled “Klassificering utan genomdrivande är dekoration ”Markera mottagarens telefonnummer som känsligt och ändra inget annat, så har du skrivit dokumentation. Användbart, men styrning går längre: klassificeringen ska styra behörigheter, maskering, kryptering, lagringstid, samtycke, dataflyttar, användning i sandboxar, granskning och AI-åtkomst. En del av det är arkitektens designbeslut; vissa plattformar tillämpar nu taggar och klassificeringar direkt i policyer, som styrningen i Data 360 gör (Data Governance in Data 360 (opens in a new tab)). Och att markera ett fält som Restricted hindrar ingen från att läsa det. Klassificeringen säger hur ett fält ska hanteras; säkerheten gör det så. Ordningen är: identifiera data, förstå dem, klassificera det som spelar roll, och tillämpa sedan de kontroller som klassificeringen kräver.
Tre frågor om dina data, och den tredje måste styra något.
Referensdata behöver också metadata
Section titled “Referensdata behöver också metadata ”Landskoder, leveransstatusar, DC-koder, partneridentifierare, orsaker till avbokning: de ser enkla ut tills två system är oense. Ett säger CANCELLED, ett annat CANCELED, ett tredje CNCL, ett fjärde 9. Referensdata behöver definitioner, en ägare, en källa, en livscykel när värden ändras, och mappningar när system representerar dem olika. Små värden kan styra mycket stora processer. Kapitel 6 går vidare.
Alla tre tillsammans
Section titled “Alla tre tillsammans ”Ta mottagarens telefonnummer. Ordlista: numret som används för att nå personen som tar emot en viss leverans. Härkomst: från detaljhandelspartnerns manifest. Klassificering: personuppgifter. Nu går arkitekturfrågorna att ställa: får teamet se det, och hur länge (briefen säger bara för de egna stoppen, bara under dagen); får det gå till en sandbox; behöver Snowflake det; får en agent använda det; vad händer när leveransen är klar?
Ta nu leveransstatus. Ordlista: leveransens nuvarande operativa tillstånd. Härkomst: sätts av Steve Truckings leveransprocess och skickas tillbaka till varje partner via dess egen integration. Klassificering: operativ, inte känslig. Olika data, olika hantering. Det är poängen.
Jag behandlar inte metadata som dokumentation som tas fram efter att den riktiga arkitekturen är klar. Om jag inte kan säga vad ett fält betyder förstår jag inte datamodellen. Om jag inte vet var ett värde kom ifrån förstår jag inte integrationerna. Om jag inte vet om det är känsligt förstår jag inte säkerheten. Metadata beskriver arkitekturen, och styr den ibland.
Bortom provet: vad AI ändrar. Klassificeringen håller på att bli strömbrytaren för vad en agent får hämta eller upprepa, och härkomsten måste nå ända fram till agentens svar eller handling. Om en agent säger till en mottagare att leveransen är försenad ska arkitekturen kunna säga vad som låg till grund för det, var det kom ifrån och om agenten fick använda det. ”Någonstans i Salesforce” är ingen härkomst, och ”kunddata” är ingen klassificering.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”- Vilka affärsbegrepp som behöver styrda definitioner, så att system och team inte ger ett ord olika betydelser.
- Hur viktiga värden behåller tillräcklig härkomst för att visa sin källa, auktoritet och sina omvandlingar.
- Vilka fält som bär känslighet eller betydelse för regelefterlevnad och därför får en uttrycklig klassificering.
- Vilken taxonomi organisationen använder, och om människor kan tillämpa den konsekvent.
- Hur klassificeringen styr verkliga kontroller i stället för att ligga oanvänd.
Innan du styr data, vet vad du har: vad de betyder, var de kom ifrån, hur de måste hanteras. Dokumentera brett, klassificera medvetet, behåll härkomst där den spelar roll. Annars styr du inte dina data. Du har dem bara.
Utforska vidare
Section titled “Utforska vidare ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
- Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) och Create a Semantic Model in Data 360 (opens in a new tab) (på engelska, kontrollerad 2026-10-14).