Org-strategi är ett landskapsbeslut

🌐 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 5 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: Rita systemlandskapet · Nästa: Steve Truckings landskap

Frågan den här modulen besvarar: En org eller flera, och var körs den?

När jag undervisar CTA-kandidater säger jag att det största beslutet i ett scenario kommer under de första fem eller tio minuterna: hur många orgar i Salesforce har vi att göra med? En stor org? Regionala orgar för Nordamerika, EMEA och APAC? Separata orgar för separata affärsenheter? En särskild org för ett land med egna regler? Och direkt kopplat till det: var körs de orgarna?

Det här är inga admindetaljer. De ändrar var data bor, integrationerna, rapporteringen, identiteten och hur människor runt om i världen når systemet. Därför behandlar jag org-strategi som ett landskapsbeslut, och därför fattar jag det först.

Börja med en org

Min utgångspunkt är enkel: börja med en org. Inte för att en org alltid är rätt, utan för att jag behöver ett skäl för att lägga till en till. En org ger mig ett ställe för delade kunddata, en säkerhetsmodell, ett ställe att deploya till, en uppsättning integrationer, ett ställe att rapportera från. Och en org kan ändå stödja olika affärsenheter, länder, processer, posttyper, appar, delningsmodeller och upplevelser.

Så jag lägger inte till en org för att Europa gör saker lite annorlunda, eller för att en division har en egen säljprocess, eller för att affärsenheterna inte gillar varandra. Det är krav, inte org-gränser. Frågan är: vilken kraft är stark nog för att motivera en org till?

Flera orgar har en kostnad

Dela upp en org i tre (Nordamerika, Europa, Asien och Stillahavsområdet) så har du inte ritat tre prydliga lådor; du har skapat nya frågor. Var bor en global kund? Vad händer om den verkar i två regioner: två kopior, och vilken äger den? Hur rapporterar någon globalt? Integrerar ERP:t med alla tre, får datalagret tre flöden, kopplas identitetsleverantören till alla tre? Deployar vi samma funktionalitet tre gånger och håller tre datamodeller i linje? Om en agent behöver en global bild av en kund, vilken org frågar den?

Gå tillbaka till landskapet från modul 4. En Salesforce-låda blir tre, och varje pil ritas om. Flera orgar är inte fel. Det är aldrig gratis.

Leta efter verkliga gränser

Vad kan motivera en org till? Gränser som är verkliga nog att forma arkitekturen: datalokalisering, reglering, juridisk separation, verkligt olika verksamhetsmodeller, ett förvärv som inte har konvergerat än, en regional begränsning för driften, mycket olika styrning, ibland skala eller isolering. Listan är inte fullständig. Poängen är att skilja ”de här grupperna är olika” från ”de här grupperna behöver en arkitektonisk gräns”. Den andra ribban ligger mycket högre.

Geografi är inte automatiskt en org-strategi

”Vi verkar i 30 länder, så vi behöver 30 orgar.” Nej. Geografi spelar roll när den för med sig ett arkitektoniskt krav. Ett företag kan ha användare över hela världen på en gemensam arkitektur. Så jag räknar inte länder; jag frågar vad som följer med dem. Var får data lagras? Var får de behandlas? Finns det gränser för att flytta personuppgifter över landsgränser? Avtalslöften om datalokalisering? Behöver en region en annan tjänst eller värd i Salesforce? ”Det finns ett kontor i Tyskland” räcker inte i sig.

Driften är en del av ritningen

Här gör den moderna plattformen landskapet mer intressant. Hyperforce kör Salesforce på infrastruktur i det publika molnet i regioner runt om i världen, vilket ger kunderna större val och kontroll över var deras data finns (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Så när jag märker en låda ”Salesforce, Europa” kan den platsen spela roll.

Men var exakt. Att välja var en org bor är inget löfte om att varje byte i varje tjänst stannar där. Salesforce uppmanar kunderna att gå igenom dokumentationen om förtroende och regelefterlevnad för Hyperforce, inklusive de ytterligare underbiträdena för de tjänster de köper (samma källa). Så säg inte ”vi kör Hyperforce i land X, så allt stannar i land X”. Vet vilka tjänster du faktiskt använder, och vilket krav du uppfyller. Och lägg märke till vad du väljer: regionen, inte molnet under den. Hyperforce körs på AWS, med Google Cloud från slutet av 2026, och Salesforce bestämmer vilken leverantör en org ligger hos; en kund med ett dokumenterat regulatoriskt skäl att undvika en av dem pratar med sitt kontoteam (samma källa).

Lek inte jurist

Det är också här arkitekter behöver känna till sin roll. Om någon säger ”europeisk integritetslagstiftning kräver en separat org” accepterar jag inte det blint. Jag utser inte heller mig själv till företagets jurist och förklarar att den inte gör det. Jag frågar: vilket specifikt krav uppfyller vi? Var data lagras, var de behandlas, överföring över gränser, vem som kan komma åt dem för support, ett avtal, en intern policy? Sedan arbetar jag med dataskydd, säkerhet, compliance och juridik för att göra det kravet till arkitektur. Hitta inte på juridiska krav, och ignorera dem inte. Översätt dem.

När Europa får en egen org

Här är en gräns jag ser i verkliga scenarier. Ett företag har en stor närvaro i USA och en stor närvaro i Europa: två stora kundbaser, två sälj- och serviceverksamheter och ett europeiskt dataskyddsprogram byggt kring GDPR (dataskyddsförordningen). GDPR säger inte ”du behöver en separat org i Salesforce”. Den sätter regler för personuppgifter, bland annat för när de får överföras ut ur EU (GDPR, kapitel V (opens in a new tab)). Men det här företaget bestämmer, tillsammans med sina dataskydds- och juristteam, att dess europeiska kunders personuppgifter ska bo i en org som driftas i Europa, drivs av dess europeiska team och lyder under dess europeiska styrning. Det är ett verkligt krav, och det är deras, inte mitt.

Nu är ”en stor global org” inte längre en preferens. Det finns en gräns på landskapet, Salesforce AMER och Salesforce EMEA, och jag måste rita den. Och den andra orgen är aldrig bara en låda till.

Click to enlarge

Två orgar, AMER och EMEA. Det bärnstensfärgade är vad den andra orgen tillför: inte en låda till, utan varje pil en gång till.

Gå igenom pilarna igen

Med mer än en org, gå igenom landskapet igen. Skickar ERP:t produkter till varje org? Skickar var och en ordrar tillbaka? Var hanteras kunderna som masterdata, och får deras data korsa regioner? Är integrationslagret globalt eller regionalt? Vilken identitetsleverantör loggar in vilka användare? Vart tar analytiska data vägen?

Tre ställen visar kostnaden snabbast:

Rapportering. VD:n vill ha en global pipeline. I en org är det en rapport i Salesforce. I tre är det ett rapportproblem för hela företaget: replikera, skicka till datalagret, federera? Hur aktuellt måste det vara, och definierar orgarna ens ”pipeline” på samma sätt? Var analysen bor följer var data bor, och om du medvetet delar upp de operativa data måste du designa hur insikterna kommer samman igen.

Masterdata. En global kund köper i USA, Tyskland och Japan. Tre orgar, alltså förmodligen tre konton. Hur vet du att de är samma företag? Vilken är den globala identifieraren, och vem äger den? Om en region ändrar adressen, ska ändringen spridas? Vilka attribut är globala och vilka regionala? Org-strategi löser inte identitet; den ändrar identitetsproblemet. Det är kapitel 6.

Integration. En org: Salesforce, integrationslagret, ERP:t. Tre orgar: tre kopplingar in i integrationslagret, kanske en med egen värd och egen uppkoppling, vissa flöden delade, vissa regionala, vissa data som får korsa gränsen och vissa som inte får det. Till och med nätverket kan ändras: om företaget behöver en dedikerad privat uppkoppling till Hyperforce (på AWS rekommenderar Salesforce AWS Direct Connect; samma FAQ om Hyperforce) är varje org och värd på ritningen ännu en koppling att planera. Var en org körs kan ändra hur resten av företaget når den.

En org eller flera är ett beslut du fattar nu, i början, på landskapet. Hur orgarna sedan delar data (Salesforce Connect mellan orgar, integration mellan dem, Data 360) är mekaniken, och kapitel 14, En org eller flera? (coming soon), tar upp den.

Om du designar hela datamodellen och integrationsarkitekturen och först då hör ”förresten, det här måste vara tre orgar” har du inte gjort en liten justering. Du har ändrat arkitekturen. Därför kommer beslutet först.

Dela inte upp bara för att göra lådorna mindre

En stor org känns komplicerad: massor av enheter, objekt, användare, integrationer. Någon säger: ”Vore det inte renare om alla hade sin egen org?” Ritningen blir kanske renare. Företaget blir det kanske inte. Du har bytt intern komplexitet mot distribuerad komplexitet: synkronisering, dubbla data, identitet mellan orgar, global rapportering, flera releaseflöden, dubblerade integrationer och automatiseringar, och styrning över allt det. Ibland är det ändå rätt byte. Men separat är inte samma sak som enkelt.

Och en org är inte heller gratis. Gemensam styrning spelar större roll, team kan påverka varandra, säkerhetsgränser behöver designas noggrant, datamodellen måste tjäna många grupper, releaser behöver samordnas och regionala regler kan begränsa alla. Så det är inte ”Steve säger alltid en org”. Min utgångspunkt är en org; sedan letar jag efter kravet som är starkt nog att flytta mig från den.

Gör beslutet synligt

Om org-strategin spelar roll, rita inte ett generiskt Salesforce-moln. Rita orgarna och märk dem (AMER, EMEA, vad som nu är verkligt), anteckna kravet på drift eller datalokalisering bakom var och en, och gå igenom kopplingarna. En annan arkitekt ska kunna se varför varje gräns finns. Om jag inte kan förklara varför det finns tre Salesforce-lådor har jag inte fattat klart beslutet.

Steve Trucking kör en org, i USA, och inget i uppdragsbeskrivningen kräver en till. Men ha den här modulen i minnet inför slutprojektet: ett förvärv som kommer med en egen org är precis den sortens gräns som sätter de här frågorna på prov.

Bortom provet: vad AI ändrar. En agent kan göra en org-gräns osynlig för användaren. Under ytan måste arkitekturen fortfarande bestämma vilken org eller vilket system agenten får fråga, vilka data som får korsa regioner och vilket svar som är auktoritativt. AI kan dölja komplexiteten i upplevelsen; den tar inte bort styrningen eller gränsen.

Vad en arkitekt bestämmer här

• Om det finns ett verkligt arkitektoniskt skäl för mer än en org, i stället för att lösa skillnaderna inom en.
• Var varje org körs, och vilket krav på datalokalisering, reglering, avtal eller verksamhet som placerar den där.
• Vilka data som får korsa org- och regiongränser, var masterdata är auktoritativa och hur global identitet fungerar.
• Hur integration, identitet, analys och rapportering ändras när en Salesforce-låda blir flera.
• Om nyttan med separationen är värd den distribuerade arkitektur som den skapar.

När jag läser ett scenario letar jag efter det här beslutet först: en org eller flera, driftade var, och framtvingade av vad? Svara på det, så börjar resten av landskapet ta form.

Utforska vidare

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), kapitel V (överföring av personuppgifter till tredjeländer) (på engelska, kontrollerad 2026-10-14).