Systemen runt Salesforce

🌐 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 3 av 6 i kapitlet Förstå företagets data, kapitel 4 i kursen Data Architect. Varje modul står på egna ben. Föregående: Typerna av företagsdata · Nästa: Rita systemlandskapet

Frågan den här modulen besvarar: Vad omger Salesforce, och vilken roll spelar varje system?

Förra modulen sorterade data. Nu vill jag placera dem någonstans, och det är här Salesforce-arkitekter hamnar i trubbel. Vi kan Salesforce, så kunddata betyder konto, orderdata betyder Order, dokument betyder Files, analys betyder Reports. Men företaget köpte inte Salesforce för att ersätta allt annat det äger. Det kan finnas ett ERP som sköter ekonomi och leverans, ett datalager med många års historik, en integrationsplattform, en identitetsleverantör, partnersystem, en händelseplattform, en MDM-plattform och Data 360 som kopplar ihop flera av dem. Jobbet är inte att plugga in teknologier. Det är att förstå vilket jobb varje system har.

Börja inte med produktnamnet

”Vi har SAP” säger mig inte tillräckligt. Inte heller Snowflake, MuleSoft, Tableau eller Data 360. Jag vill veta vad det systemet gör i den här arkitekturen: vilka data det äger, vad det läser, vad det ändrar, vem som använder det, vad som är beroende av det, vad som händer när det ligger nere. Två företag kan äga exakt samma produkter och ha helt olika arkitekturer.

Så jag märker system efter roll. Fyra roller täcker det mesta:

• System of record (källsystem): där den auktoritativa versionen av något underhålls.
• Engagemangssystem (system of engagement): där människor utför arbetet.
• Referenssystem (system of reference): där ett system hämtar information som det behöver men inte äger.
• Insiktssystem (system of insight): där data kommer samman för att mäta, analysera och förutsäga.

En plattform kan spela flera roller, och rollerna skiljer sig åt beroende på data. Salesforce kan vara system of record för ärenden, engagemangssystem för servicehandläggare och konsument av produktdata som ERP:t äger. Så när någon säger ”Salesforce är vårt system of record”, avsluta meningen: system of record för vad?

ERP:t: back office har gravitation

ERP:t är det system du oftast hittar bredvid Salesforce, och det sköter ekonomi, lager, inköp, leverans och fakturering. Mönstret från modul 1 (kunder och produkter in, ordrar ut) betyder att ERP:t äger produkterna, men säljarna behöver dem ändå i Salesforce. Okej: ta in dem. Men att kopiera data överför inte ägarskapet. En kopia är inte auktoritet.

Min hållning: data som ERP:t äger läses lokalt och skrivs under kontroll. Användarna i Salesforce får data där de arbetar, men Salesforce får inte ändra det som ERP:t äger. Och jag gör det synligt i schemat: ERP:ts fält har prefixet erp_, som erp_Product_Number__c, så att alla som läser objektet vet vem som äger varje fält och att de ska vara försiktiga med att ändra det. Prefixet genomdriver ingenting; det gör behörigheter, validering och integrationsmönstret. Det kommunicerar avsikten, och det är auktoritetskartan gjord synlig.

Datalagret, datasjön och lakehouse

Operativa system driver verksamheten; analytiska system hjälper till att förstå den. ”Visa mina öppna affärsmöjligheter” är en rapport i Salesforce. ”Visa fem år av försäljning, leveranser, returer, ärenden, lager och ekonomi i alla kanaler” är ett annat problem.

Du kommer att möta tre sorters analytiska lager. Ett datalager (data warehouse) håller strukturerade data förberedda för analys. En datasjö (data lake) håller mycket mer data i fler former, ofta råa. Ett lakehouse kombinerar de två: lagring som i en datasjö med analys som i ett datalager. Känn till dem, för de dyker upp på landskap. Men min erfarenhet är att lakehouses och data mesh fortfarande är en nisch i Salesforce-projekt. Det typiska landskapet är CRM, ERP, ett datalager och ett integrationslager, med andra plattformar där verksamheten verkligen behöver dem. Lär dig arkitekturen; jaga inte ordförrådet.

Analysen bor där data bor

Det här är en av mina fastaste hållningar: var analysen bor följer var data bor. Om rapporten bara behöver konton, affärsmöjligheter och säljare ligger allt på core: standardrapporter och instrumentpaneler. Sedan ber verksamheten om att lägga till fakturor från ERP:t. Sedan produktkostnad. Sedan fem års ordrar från datalagret. Sedan aktivitet på webbplatsen. Vid någon punkt slutar det vara rimligt att dra in allt det i det operativa CRM-systemet bara för att rapportera på det. När andra datalager är inblandade blir en analysplattform nödvändig: Tableau (inklusive Tableau Next, byggt på Data 360), eller CRM Analytics där det redan används. Den är nödvändig när data från Salesforce slås ihop med ett datalager. Kravet blev inte bara mer komplicerat; landskapet ändrade var frågan ska besvaras. Så jag börjar aldrig med ”vilket analysverktyg?”. Jag börjar med var finns data?

Jag frågar CTA-kandidater samma sak: ”Vilket av mina diagram löser det här snyggt? Landskapet.” Om allt ligger på core, använd rapporter. Om du har data i andra lager vill jag se en analysplattform. Landskapet besvarar rapportfrågan innan någon öppnar en rapportbyggare. (Produktnamnen ändras; kapitlet om Data 360 tar upp var analysen i Salesforce står i dag.)

MDM: vem är den här kunden egentligen?

Anta nu att kundinformationen finns i Salesforce, ERP:t, e-handeln, en lojalitetsplattform och ett partnersystem, och att vart och ett tror att det vet vem kunden är. Det är där masterdatahantering (master data management, MDM) kommer in: att fastställa och styra den auktoritativa identiteten för viktiga data mellan system. Men MDM är inte ”en masterdatabas för kunder”. De svåra frågorna är vilket system som får skapa kunden, vilka attribut varje system äger, hur dubbletter hittas, vilken identifierare som överlever och vad som händer när systemen inte är överens. Kapitel 6 handlar helt om det. Här räcker det att känna igen rollen: om det finns en MDM-plattform kan den vara en kritisk auktoritet mellan Salesforce och resten av företaget.

Integrationslagret och händelserna

Koppla varje system direkt till alla andra, så blir landskapet snabbt spagetti. Därför har företag ett integrationslager: en ESB (enterprise service bus) eller iPaaS (integration platform as a service). MuleSoft är den du oftast möter i landskap med Salesforce. Den förmedlar, så att varje applikation inte behöver förstå alla andra.

Men en MuleSoft-låda i mitten gör inte integrationen bra. Jag vill fortfarande veta vad som går genom den och vad som inte gör det, vem som transformerar data, vem som äger kontraktet, vad som händer när mottagaren ligger nere, om det är synkront eller asynkront, och hur vi vet att ett meddelande gick fram. Kursen Integration Architect går på djupet; här räcker det att känna igen det som en egen roll.

Och alla integrationer är inte system A som anropar system B. Ibland händer något (en order skapas, en leverans byter status, en lastbil kör in i en region), en händelse publiceras, och den som är intresserad reagerar. Händelser i rörelse har också infrastruktur: de egna händelsefunktionerna i Salesforce, en händelsebuss för hela företaget, andra meddelandesystem. Rita mekanismerna som bär data, inte bara databaserna.

Systemet utvecklare glömmer: identitet

Det finns en låda jag alltid vill ha på landskapet som utvecklare sällan tänker på: identitetsleverantören. Utvecklare loggar in direkt i sina sandboxar med användarnamn och lösenord, så identitet är osynlig under bygget. Sedan kommer UAT eller produktion, och plötsligt finns företagets single sign-on för anställda, kanske en andra leverantör för partner, social inloggning för kunder. Identitet var alltid en del av arkitekturen. Utvecklaren såg den bara inte än.

En identitetsleverantör (IdP) är systemet som autentiserar en användare och fastställer den identitet som Salesforce litar på. Den hör hemma på landskapet från dag ett, även om den konfigureras senare i releaseflödet, eftersom den som kan komma in bestämmer vem som kan komma åt data.

Det finns en praktisk hake också: identitetskonfigurationen kan deployas, men inte helt. Konfiguration för SAML single sign-on och autentiseringsleverantörer är typer i Metadata API, så de följer med genom releaseflödet (SamlSsoConfig (opens in a new tab)). Men autentiseringsleverantörers consumer secrets returneras inte längre i svar från Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), och certifikat skiljer sig oftast mellan miljöer. Planera för delarna som följer med och delarna som inte gör det.

Click to enlarge

Läs landskapet som roller, inte logotyper: vad varje system äger, läser eller bestämmer.

Var hör Data 360 hemma?

Data 360 väcker en trevlig ritfråga. Jag sätter det till höger, under ESB:n eller MuleSoft. Skälet är dess kopplingar: användarna ansluter aldrig direkt till det, medan det ansluter direkt till många system i bakänden. Så det hör hemma bland datarören, där de linjerna förblir korta, inte ute bland användarna. Rita det som ännu en skärm som folk loggar in på, så berättar du fel historia.

Admins och datateam öppnar visserligen skärmarna i Data 360, men de skärmarna finns i orgen, på core. Tenanten som gör jobbet, dess data och dess bearbetning, körs utanför core. Därför kallar jag det nära core (near-core): hanteras på core, driftas utanför core (modul 1 förklarar termerna). Ritningen följer tenanten: den hör hemma bland rören, med en linje tillbaka till orgen som hanterar den.

Det som den gör omfattar, med Salesforce egna ord, zero copy: en teknik för datafederering som låter ett företag komma åt och fråga data utan att kopiera dem (Zero Copy (opens in a new tab)). Förmågorna och kopplingarna ändras snabbt, så kapitlet om Data 360 tar upp dem ordentligt i stället för att göra den här modulen till en produktvisning.

Läs landskapet som ansvar

När du tittar på ett landskap, läs inte logotyperna; läs ansvaret. ERP:t: vad äger det? Datalagret: vilka frågor besvarar det? Integrationsplattformen: vad flyttar den? IdP:n: vem autentiserar den? MDM: vilken identitet styr den? Data 360: vad kopplar det ihop, och till vad? Salesforce: vad ansvarar det faktiskt för? När du kan svara på de frågorna betyder lådorna något, och pilarna mellan dem blir mycket mer intressanta. Härnäst ritar vi dem medvetet.

Vad en arkitekt bestämmer här

• Vilken roll varje system spelar, bortom sitt produktnamn.
• Vilket system som är auktoritativt för varje viktig datamängd, och var Salesforce bara har en lokal kopia.
• Om data som ERP:t äger finns tillgängliga i Salesforce med kontrollerade skrivningar, och hur det ägarskapet syns i schemat.
• Var analysen hör hemma, utifrån var data bor.
• Var identitet, integration, händelser och auktoriteten över masterdata hamnar på landskapet.

Ett landskap med tio rektanglar är inte arkitektur; det är en inventering. Arkitekturen börjar när du kan peka på varje rektangel och säga varför den finns där, vad den äger, vem som använder den, vad Salesforce behöver från den och vad som går sönder om du missförstår dess roll.

Utforska vidare

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (produktsida, på engelska, kontrollerad 2026-10-14).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (på engelska).