Var bor de här data?

🌐 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 4 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Bygg ditt eget: anpassade objekt · Nästa: Välj rätt objekt

Frågan den här modulen besvarar: innan du skapar ett objekt, var ska de här data egentligen bo: på core i Salesforce, refererade där de redan finns, eller arkiverade?

Låt mig ställa en fråga. Ett nytt krav landar på ditt skrivbord. Vad är det första du gör?

Om du är som de flesta av oss öppnar du Setup och skapar ett anpassat objekt. Jag förstår det. På tio minuter har du en flik, en sidlayout och en listvy. Och det här säger jag till varje klass: i samma ögonblick som du skapar det nya objektet tänker du redan som en arkitekt, vare sig du menade det eller inte. För varje objekt du skapar är ett åtagande. Det tar lagring. Det drar på sig gränser. Det får en delningsmodell, vare sig du designade en eller inte. Det kräver en licens för alla som rör det. Och när människor och integrationer väl är beroende av det: lycka till med att ta bort det.

Så det första arkitekturbeslutet är inte vilket objekt. Det är var ska de här data bo? Gör rätt där, så väljer objekttypen nästan sig själv.

På core och utanför core

Först ett ord jag kommer att använda mycket: core. Core är Salesforce-plattformen som din org körs på: den metadatadrivna multitenant-plattformen från modul 1, där objekten för sälj och service från modul 2 bor, och varje anpassat objekt du bygger i modul 3. När jag säger att data finns på core (on core) menar jag att de lagras i din org, i dess objekt.

Alla data bor inte där. Data 360 har sina data i ett eget lager, utanför din orgs objekt (det är nära core (near-core): hanteras på core, med sina data lagrade utanför core; mer om det i kapitel 4). Och sedan finns allt som ditt företag kör som inte är Salesforce alls: ERP-systemet, lagret, ordersystemet, partnerns plattform. Allt det är utanför core (off core). Salesforce kan nå det, visa det och använda det, men din org lagrar det inte.

På core finns det två sorters objekt som faktiskt rymmer dina poster: sObjects, standard och anpassade (__c), och big objects (__b). Utanför core når du data via externa objekt (__x) och de andra integrationsverktygen. Ha suffixen från modul 3 i huvudet; de talar om var en bit data bor bara genom namnet.

Jag tänker på det som ett kontor. Vissa saker hör hemma på ditt skrivbord, där du använder dem varje dag. Vissa saker behöver du bara slå upp i någon annans arkivskåp. Och vissa saker hamnar i lådor i förrådet på baksidan. Det ger mig tre svar.

1. På core: de bor på ditt skrivbord

Data skapas, ändras och används i Salesforce varje dag: konton, ärenden, affärsmöjligheter, arbetsordrar. Att ha dem i sObjects är som att ha dem längst fram på kontoret. Det är vad standardobjekt och anpassade objekt är till för, och du får allt: sidlayouter, delning, automatisering, rapportering, sökning, och numera AI-funktionerna som bygger på datamodellen.

Ditt skrivbord är dock inte gratis. Data på core kostar lagring, räknat som Salesforce räknar, post för post, inte kolumn för kolumn, och dokument räknas för sig mot fillagringen. Vi gick igenom båda i modul 2. Stora mängder foton och skanningar hör ofta hemma utanför core, där Salesforce bara behåller en länk.

2. Refererade: de bor i någon annans arkivskåp

Data tillhör ett annat system (ERP-systemet, ett datalager, en orderplattform), och det systemet förblir sanningskällan. Användarna behöver se data i Salesforce, kanske relatera dem till en post, men Salesforce behöver ingen egen kopia. Du hör också det här kallas virtuella data: de dyker upp i Salesforce virtuellt, utan att någonsin lagras där.

Det är externa objekt, via Salesforce Connect. Jag brukar säga att det ser ut som en anka och går som en anka, men det är ingen anka. Det dyker upp som ett sObject: du kan lägga det på sidlayouter och relaterade listor och relatera det till dina egna poster med externa och indirekta lookups. Men data lagras inte på core. Varje gång du rör det gör det ett anrop ut (callout). Öppna en post, ladda en relaterad lista, kör en rapport, så går Salesforce och frågar det andra systemet. Det betyder latens, och din sida är bara så tillgänglig som systemet bakom den.

Folk invänder mot licenskostnaden, så räkna som jag gör i klassrummet. Connect licensieras per endpoint, och en endpoint kan ta in många objekt. Fråga dig sedan vad det kostar att bygga och underhålla alternativet: en anpassad komponent, anropskoden bakom den och en utvecklare i beredskap när det går sönder. Ofta är licensen billigare, och dina admins kan konfigurera det utan att skriva en rad kod. Där det inte håller: data som dina användare redigerar hela dagen eller rapporterar mycket på.

Dokument kan också refereras. Om ett avtal redan finns i SharePoint Online, OneDrive, Google Drive eller Box låter Files Connect användarna nå det från Salesforce utan att kopiera in det.

Salesforce Connect är inte det enda sättet att referera data. Ibland är det anpassad logik: kod som anropar det andra systemet i realtid och visar dess data på sidan, utan att någon kopia sparas. Det ger dig full kontroll, och fullt ansvar för anropet, felen och underhållet. Och Data 360 kan också federera utan att kopiera. Det valet har ett eget kapitel (Virtualisering, federering och Zero-Copy). Här handlar det om själva beslutet: referera, kopiera inte.

3. Arkiverade: de hamnar i förrådet på baksidan

Historik, granskningsspår, gamla transaktioner. Du måste spara dem, ibland i åratal, men nästan ingen öppnar dem. Och det här är den del som team skjuter upp. När en klass berättar att de har ett objekt med 50 miljoner poster och frågar varför de skulle arkivera, frågar jag tillbaka: om du inte arkiverar i dag, kommer du någonsin att arkivera? Med 50 miljoner i dag är du på väg mot 100, 150, 200 miljoner.

Det finns två förråd. Det ena finns på core: big objects. Tänk på dem som att lagra data i garaget. Du kan lagra ett enormt antal poster, men du kan inte lägga dem på en sidlayout, det finns inget standardgränssnitt eller standardrapportering, och du frågar via big objectets index, med exakt matchning eller intervall (Big Objects Best Practices (opens in a new tab)). Säkerheten är bara objekt- och fältbehörigheter, utan delning av poster, och automatisering körs inte på dem. Jag har använt Salesforce Connect dussintals gånger och big objects bara en eller två gånger. De fungerar, men de är krångliga, och jag har skrivit min beskärda del av lösningar för att komma åt data. Så mitt råd: gör en prototyp innan du föreslår det, och planera hur folk ska hitta data innan du väljer det.

Det andra förrådet finns utanför core: ett datalager eller en databas någon annanstans (Designa för skala). Ofta är det det bättre förrådet, och det behöver inte vara utom synhåll. Arkiverade data utanför core kan fortfarande synas i rapporter via verktyg som Tableau, och de kan fortfarande nås från Salesforce, via Salesforce Connect eller något annat sätt att virtualisera dem, när någon behöver blicka bakåt.

Låt mig berätta om ett projekt där vi gjorde rätt från början. En detaljhandelskund hade över 1 200 butiker. De sa till mig: ”Vi gör bara hundra bokningar om dagen per butik. Ingen stor grej.” Sedan räknade jag: hundra om dagen, sex dagar i veckan (cirka 305 dagar om året), i 1 200 butiker, blir över 36 miljoner bokningar om året. Sedan nämnde de att varje besök skapade två bokningar, en vid disken och en för verkstaden på baksidan: över 73 miljoner poster om året. Sedan ville de ha fem års historik: mer än 360 miljoner poster, innan någon tillväxt. Vi hade inte gått live, och jag kunde redan se tåget på väg rakt mot stationen för stora datavolymer. Så arkivet byggdes innan vi hade samlat in en enda bokning: äldre bokningar flyttades till big objects, och sökskärmen visade aktuella bokningar med de arkiverade direkt nedanför. Flera år senare rullar det fortfarande på fint.

Click to enlarge

Sätt det i arbete: Steve Trucking

Steve Trucking är vårt genomgående scenario: ett familjeägt företag för sista milen-leveranser som hämtar vitvaror och hemelektronik på stora detaljhandelskedjors distributionscentraler och sedan levererar och installerar dem hemma hos kunderna. Fyra sorters data, tre svar:

Data	Var de bor	Varför
Dagens leveranser, team och bokningar	På core	Trafikledare och team jobbar i dem hela dagen
Detaljhandlarens orderuppgifter	Refererade (eller en tunn kopia på core)	Detaljhandlarens system är sanningskällan
Leveranshistorik från tre år sedan	Arkiverade	Sparas för reklamationer och trender; nästan ingen öppnar dem
Leveransfoton	Utanför core, länkade	Tusentals om dagen; lagras utanför Salesforce med en länk på leveransen

Här är samma sak som en datamodell. Leveransen (Delivery) ligger på core, där folk jobbar i den hela dagen. Efter tre år flyttas den till Delivery History, ett big object: fortfarande på core, men ute i förrådet. Partnerns order dyker upp som ett externt objekt, __x: Salesforce relaterar leveransen till den, men data stannar i detaljhandlarens system. Och fotona bor helt utanför core, med en länk från leveransen. En modell, tre hem.

Click to enlarge

Varje verklig org har alla tre. De som hamnar i trubbel lägger allt på core, eftersom att skapa ett objekt var standardknappen.

Vad en arkitekt bestämmer här

• Hemmet för varje sorts data, innan något objekt designas: på core, refererade eller arkiverade.
• Sanningskällan. Om ett annat system äger data ska Salesforce inte i tysthet bli en andra master.
• Åtkomstvägen för allt utanför core. Refererade data kräver en tillgänglig källa och acceptabel latens; arkiverade data kräver ett sätt för folk att hitta dem.
• Lagringstillväxt. Räkna nu (poster per dag, gånger tillväxt, gånger lagringstid), inte när lagringsvarningen kommer.

Bortom provet: AI höjer insatserna för ”på core”. AI-funktioner och agenter fungerar bäst på data som plattformen förstår: data i standardobjekt och anpassade objekt, med bra namn och bra beskrivningar. Det drar mot att lägga mer på core. Stå emot det för fel data. En agent som är förankrad i en inaktuell kopia av ERP-data ger självsäkra, felaktiga svar. Ofta är det bättre draget att referera den levande källan, eller att hålla en liten, väl beskriven del på core. Var AI läser data är numera en del av beslutet om var data bor.

Utforska vidare

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (på engelska, kontrollerad 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-09-25)
• I den här kursen: Virtualisering, federering och Zero-Copy och Designa för skala