Kan flera bolag dela ett system? Multitenant förklarat

Olle Krantz

Ett multitenant-system är ett system där flera organisationer delar installation men bara ser sin egen data. Det är värt att bygga när ni driver en tjänst åt flera bolag eller har flera bolag i en koncern. Då måste data, användare, roller, inbjudningar, AI-anslutningar och filer separeras per organisation, helst med en regel i databasen och inte bara i koden.

Kort förklaring

Ett multitenant-system är ett system där flera organisationer använder samma installation, men var och en bara ser sin egen data. Engelskans ”tenant” betyder hyresgäst, och bilden stämmer: många bor i samma hus, men varje lägenhet har en egen dörr.

Det är så de flesta molntjänster fungerar. Frågan för er är när det är värt att bygga så själva, och vad som krävs för att det ska vara säkert.

Varför bygga det så

Tre skäl återkommer:

  • Ni driver en tjänst åt flera bolag. Till exempel en kundportal, ett branschverktyg eller en plattform för franchisetagare, där varje organisation ska vara avskild.
  • Ni har flera bolag i en koncern. Gemensam kod och drift, men separat data och egna användare.
  • Ni vill kunna låta fler använda er lösning senare, utan att behöva bygga om grunden.

Annars behövs det inte. Ett internt verktyg för ett bolag är enklare att bygga som ett system för en organisation.

Vad som måste skiljas åt

I vårt eget system, Altu Central Command, blev systemet fleranvändarbolag under hösten 2026. Organisationer, roller, inbjudningar och OAuth-anslutningar separeras per organisation, så att samma installation kan köra för flera bolag med vattentäta skott emellan. Det visar vad som behöver ingå:

  1. Data. Varje rad hör till en organisation, och ingen fråga får returnera rader från en annan.
  2. Användare och roller. En person tillhör en eller flera organisationer och har en roll i varje.
  3. Inbjudningar. Hur nya användare kommer in i rätt organisation, utan att kunna välja en annan.
  4. Anslutningar och nycklar. En AI-agents koppling gäller en organisation, inte alla. Se OAuth och AI-agenter.
  5. Filer, loggar och index. Det som lagras vid sidan om databasen, till exempel dokument och sökindex, ska också skiljas åt.

Tre vanliga sätt att separera data

  • Samma tabeller, en organisationskolumn. Enklast och billigast. Kräver att varje fråga filtrerar på organisation, och det är lätt att glömma på ett ställe. Därför är det klokt att låta databasen själv upprätthålla regeln.
  • Ett eget schema per organisation. Starkare avskiljning, mer att underhålla.
  • En egen databas per organisation. Starkast, och dyrast i drift.

Vilket som passar beror på hur känsligt datat är och hur många organisationer det blir. För många mindre bolag räcker första sättet, om regeln sitter i databasen och inte bara i appen.

Frågor att ställa

  • Var upprätthålls separationen: i databasen eller bara i koden?
  • Vad händer om en utvecklare glömmer ett filter?
  • Hur testar ni att en organisation inte når en annans data?
  • Kan en användare tillhöra två organisationer, och hur byter hen?
  • Vad händer med data när en organisation lämnar?

Vad det kostar att lägga till i efterhand

Att göra ett system för en organisation till ett för flera är ofta svårt, eftersom antagandet ”allt hör ihop” sitter i varje fråga och varje fil. Bygger ni för flera är det billigare att göra det från början. Det är också skälet till att det är bra att veta vad ni vill innan ni skriver offertförfrågan.

Funderar ni på att erbjuda en lösning åt flera bolag? Läs om skräddarsydda system eller hör av er.