Hvor bor disse data?
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)
Modul 4 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Byg dit eget: brugerdefinerede objekter · Næste: Vælg det rigtige objekt
Spørgsmålet, dette modul besvarer: Før du opretter et objekt, hvor skal disse data så egentlig bo: på core i Salesforce, refereret der, hvor de allerede ligger, eller arkiveret?
Lad mig stille dig et spørgsmål. Et nyt krav lander på dit bord. Hvad er det første, du gør?
Hvis du er som de fleste af os, åbner du Setup og opretter et brugerdefineret objekt. Det forstår jeg godt. På ti minutter har du en fane, et sidelayout og en listevisning. Og her er det, jeg siger til hver eneste klasse: I det øjeblik du opretter det nye objekt, tænker du allerede som en arkitekt, uanset om det var meningen eller ej. For hvert objekt, du opretter, er en forpligtelse. Det tager lagerplads. Det samler grænser op. Det får en delingsmodel, uanset om du har designet en eller ej. Det kræver en licens for alle, der rører det. Og når mennesker og integrationer først afhænger af det, så held og lykke med at fjerne det igen.
Så den første arkitekturbeslutning er ikke hvilket objekt. Den er hvor skal disse data bo? Får du det rigtigt, vælger objekttypen nærmest sig selv.
På core og uden for core
Sektion kaldt “På core og uden for core ”Først et ord, jeg kommer til at bruge meget: core. Core er den Salesforce-platform, din org kører på: den metadatadrevne multitenant-platform fra modul 1, hvor salgs- og serviceobjekterne fra modul 2 bor, og hvert brugerdefineret objekt, du bygger i modul 3. Når jeg siger, at data er på core (on core), mener jeg, at de er gemt i din org, i dens objekter.
Ikke alle data bor der. Data 360 gemmer sine data i sit eget lager uden for din orgs objekter (det er tæt på core, near-core: styret på core, med dataene hostet uden for core; mere i kapitel 4). Og så er der alt det, din virksomhed kører, som slet ikke er Salesforce: ERP-systemet, lageret, ordresystemet, partnerens platform. Alt det er uden for core (off core). Salesforce kan nå det, vise det og bruge det, men din org gemmer det ikke.
På core er der to slags objekter, der faktisk rummer dine poster: sObjects, standard og brugerdefinerede (__c), og big objects (__b). Uden for core når du data gennem eksterne objekter (__x) og de andre integrationsværktøjer. Hav suffikserne fra modul 3 i baghovedet; de fortæller dig, hvor et stykke data bor, bare ud fra navnet.
Jeg tænker på det som et kontor. Nogle ting hører hjemme på dit skrivebord, hvor du bruger dem hver dag. Nogle ting skal du bare slå op i en andens arkivskab. Og nogle ting ryger i kasser i skuret bag huset. Det giver mig tre svar.
1. På core: det bor på dit skrivebord
Sektion kaldt “1. På core: det bor på dit skrivebord ”Dataene oprettes, ændres og bruges i Salesforce hver dag: konti, sager, salgsmuligheder, arbejdsordrer. At have dem i sObjects er som at have dem forrest på kontoret. Det er det, standardobjekter og brugerdefinerede objekter er til, og du får det hele: sidelayouts, deling, automatisering, rapportering, søgning og nu de AI-funktioner, der er bygget på datamodellen.
Dit skrivebord er dog ikke gratis. Data på core koster lagerplads, talt på den måde, Salesforce tæller, post for post, ikke kolonne for kolonne, og dokumenter tæller for sig mod fillagringen. Vi gennemgik begge dele i modul 2. Store mængder fotos og scanninger hører ofte hjemme uden for core, mens Salesforce kun gemmer et link.
2. Refereret: det bor i en andens arkivskab
Sektion kaldt “2. Refereret: det bor i en andens arkivskab ”Dataene tilhører et andet system (ERP-systemet, et datavarehus, en ordreplatform), og det system forbliver sandhedskilden. Brugerne skal kunne se dem i Salesforce, måske relatere dem til en post, men Salesforce behøver ikke sin egen kopi. Du hører det også kaldt virtuelle data: De dukker op i Salesforce virtuelt uden nogensinde at være gemt der.
Det er eksterne objekter gennem Salesforce Connect. Jeg plejer at sige, at det ligner en and og går som en and, men det er ikke en and. Det dukker op som et sObject: Du kan sætte det på sidelayouts og relaterede lister og relatere det til dine egne poster med eksterne og indirekte lookups. Men dataene er ikke gemt på core. Hver gang du rører det, laver det et kald ud (callout). Åbn en post, indlæs en relateret liste, kør en rapport, og Salesforce går ud og spørger det andet system. Det betyder ventetid, og din side er kun så tilgængelig som systemet bagved.
Folk protesterer over licensprisen, så regn på det, som jeg gør i klassen. Connect licenseres pr. endpoint, og ét endpoint kan bringe mange objekter ind. Spørg så, hvad det koster at bygge og vedligeholde alternativet: en brugerdefineret komponent, koden til kaldene bag den og en udvikler på vagt, når den går i stykker. Ofte er licensen billigere, og dine admins kan konfigurere det uden at skrive en linje kode. Hvor det kommer til kort: data, dine brugere redigerer hele dagen eller rapporterer meget på.
Dokumenter kan også refereres. Hvis en kontrakt allerede ligger i SharePoint Online, OneDrive, Google Drive eller Box, lader Files Connect brugerne nå den fra Salesforce uden at kopiere den ind.
Salesforce Connect er ikke den eneste måde at referere data på. Nogle gange er det brugerdefineret logik: kode, der kalder det andet system i realtid og viser dets data på siden, uden at gemme en kopi. Det giver dig fuld kontrol og fuldt ansvar for kaldet, fejlene og vedligeholdelsen. Og Data 360 kan også føderere uden at kopiere. Det valg har sit eget kapitel (Virtualisering, føderering og Zero-Copy). Her er pointen selve beslutningen: referér, kopiér ikke.
3. Arkiveret: det ryger i skuret bag huset
Sektion kaldt “3. Arkiveret: det ryger i skuret bag huset ”Historik, revisionsspor, gamle transaktioner. Du skal gemme dem, nogle gange i årevis, men næsten ingen åbner dem. Og det er den, teams udskyder. Når en klasse fortæller mig, at de har et objekt med 50 millioner poster, og spørger, hvorfor de skulle arkivere, spørger jeg tilbage: Hvis du ikke arkiverer i dag, kommer du så nogensinde til at arkivere? Med 50 millioner i dag er du på vej mod 100, 150, 200 millioner.
Der er to skure. Det ene er på core: big objects. Tænk på dem som at gemme data i garagen. Du kan gemme et enormt antal poster, men du kan ikke sætte dem på et sidelayout, der er ingen standardbrugerflade eller rapportering, og du forespørger gennem big objectets indeks, med præcist match eller interval (Big Objects Best Practices (opens in a new tab)). Sikkerheden er kun objekt- og felttilladelser, uden deling af poster, og automatisering kører ikke på dem. Jeg har brugt Salesforce Connect snesevis af gange og big objects kun en eller to gange. De virker, men de er besværlige, og jeg har skrevet min del af workarounds for at komme til dataene. Så mit råd: Lav en prototype, før du foreslår det, og planlæg, hvordan folk skal finde dataene, før du vælger det.
Det andet skur er uden for core: et datavarehus eller en database et andet sted (Design til skala). Ofte er det det bedre skur, og det behøver ikke at være ude af syne. Arkiverede data uden for core kan stadig dukke op i rapporter gennem værktøjer som Tableau, og de kan stadig nås fra Salesforce, gennem Salesforce Connect eller en anden måde at virtualisere dem på, når nogen har brug for at se tilbage.
Lad mig fortælle om et projekt, hvor vi fik det rigtigt fra starten. En detailkunde havde over 1.200 butikker. De sagde til mig: »Vi har kun hundrede aftaler om dagen i en butik. Ikke noget at tale om.« Så regnede jeg på det: hundrede om dagen, seks dage om ugen (cirka 305 dage om året), på tværs af 1.200 butikker, er over 36 millioner aftaler om året. Så nævnte de, at hvert besøg skabte to aftaler, én ved skranken og én i værkstedet bagved: over 73 millioner poster om året. Så ville de have fem års historik: mere end 360 millioner poster, før nogen vækst. Vi var ikke gået live, og jeg kunne allerede se toget køre direkte mod stationen for store datamængder. Så arkivet blev bygget, før vi havde indsamlet en eneste aftale: Ældre aftaler blev flyttet til big objects, og søgeskærmen viste de aktuelle aftaler med de arkiverede lige nedenunder. Mange år senere kører det stadig fint.
Sæt det i arbejde: Steve Trucking
Sektion kaldt “Sæt det i arbejde: Steve Trucking ”Steve Trucking er vores gennemgående scenarie: et familieejet last-mile-leveringsfirma, der henter hvidevarer og elektronik på store detailkæders distributionscentre og derefter leverer og installerer dem hjemme hos kunderne. Fire slags data, tre svar:
| Data | Hvor de bor | Hvorfor |
|---|---|---|
| Dagens leveringer, teams og aftaler | På core | Disponenter og teams arbejder i dem hele dagen |
| Detailkædens ordredetaljer | Refereret (eller en tynd kopi på core) | Detailkædens system er sandhedskilden |
| Leveringshistorik fra for tre år siden | Arkiveret | Gemt til reklamationer og tendenser; næsten ingen åbner den |
| Leveringsfotos | Uden for core, med link | Tusindvis om dagen; gemt uden for Salesforce med et link på leveringen |
Her er det samme som en datamodel. Leveringen (Delivery) sidder på core, hvor folk arbejder i den hele dagen. Tre år senere flytter den ind i Delivery History, et big object: stadig på core, men ude i skuret. Partnerens ordre dukker op som et eksternt objekt, __x: Salesforce relaterer leveringen til den, men dataene bliver i detailkædens system. Og fotoene bor helt uden for core med et link fra leveringen. Én model, tre hjem.
Enhver rigtig org har alle tre. Dem, der kommer i problemer, lægger alt på core, fordi det at oprette et objekt var standardknappen.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hjemmet for hver slags data, før noget objekt designes: på core, refereret eller arkiveret.
- Sandhedskilden. Hvis et andet system ejer dataene, skal Salesforce ikke i al stilhed blive en ekstra master.
- Adgangsvejen til alt uden for core. Refererede data kræver en tilgængelig kilde og acceptabel ventetid; arkiverede data kræver en måde, folk kan finde dem på.
- Vækst i lagerpladsen. Regn på det nu (poster pr. dag gange vækst gange opbevaringstid), ikke når advarslen om lagerplads kommer.
Ud over eksamen: AI hæver indsatsen for »på core«. AI-funktioner og agenter fungerer bedst på data, platformen forstår: data i standardobjekter og brugerdefinerede objekter, godt navngivet og godt beskrevet. Det trækker i retning af at lægge mere på core. Modstå det for de forkerte data. En agent, der er forankret i en forældet kopi af ERP-data, giver selvsikre, forkerte svar. Ofte er det bedre træk at referere den levende kilde eller at holde en lille, godt beskrevet skive på core. Hvor AI læser dataene, er nu en del af beslutningen om, hvor dataene bor.
Læs mere
Sektion kaldt “Læs mere ”- Big Objects Best Practices (opens in a new tab), Salesforce Developers (på engelsk, kontrolleret 2026-09-25)
- Files Connect FAQ (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-09-25)
- I dette kursus: Virtualisering, føderering og Zero-Copy og Design til skala