Ägarskap och livscykel

🌐 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 8 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Relationer får konsekvenser · Nästa: Håll data konsistenta

Frågan den här modulen besvarar: Vem äger posten, och vad händer med den under hela dess liv?

När jag tittar på en datamodell vill jag inte bara veta vilka objekten är och hur de hänger ihop. Jag vill veta vad som händer med posterna över tid. Vem skapar dem? Vem äger dem? Vem kan tilldela om dem? Vad händer när affärsrelationen ändras, när de inte längre är aktiva? Ska de någonsin raderas, och hur länge sparar vi dem? Inget av det syns i ett ER-diagram (entity relationship diagram): lådorna och linjerna i datamodellen från kapitel 2. Allt det är dataarkitektur. Och i Salesforce är ägarskapet där datamodellen och säkerhetsmodellen krockar med varandra.

Ägarskap är mer än ett namn i ett fält

Admins ser Owner på en post och läser det som en etikett: Bart äger det här kontot, Lisa äger det där ärendet. Det kan betyda det. Men i Salesforce är ägarskap också en plattformsmekanism. På objekt som har en ägare styr ägaren vem som kan se posten via rollhierarkin, delningsregler, köer och omtilldelning. Så när jag frågar ”vem äger den här posten?” frågar jag inte vems namn som står på sidan. Jag frågar vilket säkerhets- och livscykelbeteende vi kopplar till den. Ägaren kan vara en användare, eller för vissa objekt, bland dem anpassade objekt, ärenden och leads, en kö, och i båda fallen får ägaren full åtkomst till posten (Understanding Sharing (opens in a new tab)).

Därför skiljer jag på affärsansvar och postägarskap. Ibland är det samma person. Ibland inte. Om verksamheten säger att en trafikledare ansvarar för en leverans gör det inte automatiskt trafikledaren till ägare. Ansvaret kan bo i ett eget fält medan ägarskapet sätts för att stödja säkerhet och skala. Låt inte de två blandas ihop bara för att båda använder ordet ”ägare”.

Delningstabellen: där ägarskap blir åtkomst

Vissa vet inte ens vad delningstabellen (share table) är. Varje dataarkitekt borde veta det.

Det mesta av delningen för en post hålls i ett relaterat delningsobjekt (share object), Salesforces version av en åtkomstkontrollista (Understanding Sharing (opens in a new tab)). Account har AccountShare, Contact har ContactShare, och ett anpassat objekt får ett eget: Truck__c har Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Varje rad i det säger fyra saker:

• Vilken post: förälderns ID.
• Vem: en användare, eller en grupp (en publik grupp, en rolls grupp, ett territorium).
• Hur mycket: Read, Edit eller All (full åtkomst).
• Varför: radorsaken (row cause). Owner för ägaren, Rule för en delningsregel, Manual för en manuell delning, Team, de implicita orsakerna som Salesforce lägger till mellan ett konto och dess barn, och orsaker som en utvecklare definierar för Apex-delning.

I klassrummet öppnar jag Workbench och frågar mot delningstabellen medan jag delar en post, och du ser raderna dyka upp och försvinna. När någon frågar ”varför kan den här personen se det där?” finns svaret ofta i en rad, med sin orsak.

Men allt finns inte där. Den organisationsövergripande standarden (organization-wide default) är ingen rad. Rollhierarkin lagras inte där heller: åtkomsten för dem ovanför ägaren räknas fram när den behövs. Och View All, Modify All, View All Data och Modify All Data hoppar helt över delningstabellen (Sharing a Record Using Apex (opens in a new tab)). Som jag säger i klassrummet: kryssa i View All så har du gått förbi delningstabellen.

Salesforce delar också vissa poster åt dig, på grund av hur de är relaterade. Det här är implicit delning, och den fungerar mellan ett konto och dess barn. Om du kan se en kontakt, ett ärende eller en affärsmöjlighet kan du också läsa kontot som den hör till. Och kontots ägare får åtkomst till kontots kontakter, ärenden och affärsmöjligheter, på en nivå som styrs av ägarens roll (Implicit Sharing (opens in a new tab)). I senare releaser räknar Salesforce fram en del av den barnåtkomsten när den behövs i stället för att lagra den som rader, så bli inte förvånad när en fråga mot delningstabellen inte visar den. Jag ger dig bara en vink här; detaljerna finns i Relationer och inbyggd delning.

Ett undantag till, för när du har många externa användare. Community-användare med hög volym (high-volume community users), Customer Community-licenserna som är byggda för tusentals till miljontals kunder, har ingen roll, kan inte vara med i publika grupper och kan inte få poster via delningsregler eller manuell delning (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). För dem är delningstabellen inte svaret: de når poster via sharing sets, som matchar en posts konto eller kontakt mot användarens eget. Det är en av anledningarna till att de licenserna skalar. Kursen om delning och synlighet tar upp det i Delning med externa användare.

Och kom ihåg modul 7: ett detaljobjekt har inget delningsobjekt alls. Dess åtkomst kommer från masterns delningsobjekt och Sharing Setting på master-detail-fältet.

Varför bryr sig en dataarkitekt? För att ägarskapet skrivs in i den här tabellen. Varje ägarbyte, varje ny delningsregel, varje användare som byter roll eller grupp innebär att Salesforce lägger till och tar bort rader. Vid några tusen poster märker ingen något. Vid tio miljoner, med en användare som äger de flesta, blir det den omräkning vi snart ska möta.

Provkunskap. Ett anpassat objekts delningsobjekt heter Object__Share, som Truck__Share. Ett detaljobjekt har inget delningsobjekt: dess åtkomst kommer från mastern. Och när en posts ägare byts tas dess manuella delningar bort, medan Apex-delning med en utvecklares egen orsak blir kvar.

Det är här datamodellen lämnar över till säkerhetsmodellen, och resten undervisar jag om i kursen Sharing & Visibility Architect: Steves 22 sätt att dela en post, Org-Wide Defaults, ägarskap, köer och rollhierarkin, Relationer och inbyggd delning för de implicita delningarna, och Programmatisk delning och säker kod för orsaker till Apex-delning. I den här kursen samlar kapitel 12 ihop det för människor, applikationer och agenter.

Ibland ärvs ägarskapet

I förra modulen såg vi att ett master-detail-barn inte har någon egen ägare; det följer sin förälder. Det är ofta helt rätt. Behöver verksamheten en annan ägare för varje rad på en leverans? Nej. Leveransen äger livscykeln och raden tillhör den. Därför sker relationsdesign och ägarskapsdesign samtidigt: när du valde master-detail hade du redan fattat en del av ägarskapsbeslutet.

Vem äger poster som system skapar?

Nu blir det intressant. En person skapar ett konto, och kanske blir den personen ägare. Men ett ERP-system skickar 100 000 transaktioner över natten. Vem äger dem? Integrationsanvändaren? En kö? En regional ägare som räknas fram ur data? Ett systemkonto som ingen har tänkt på på fem år? Och nu skapar agenter också poster.

Min hållning: det beror på om ägarskapet spelar roll för delningen. Integrationsanvändaren, eller agentanvändaren, är en giltig användare, och den kan äga posterna. Om ägarskap styr åtkomsten i det objektet (via rollhierarkin eller delningsregler), tilldela posterna till rätt ägare: en verklig användare, en kö eller en särskild ägaranvändare. Om det inte gör det kan det vara bättre att låta systemanvändaren vara ägare, eftersom granskningsspåret då leder rakt tillbaka till det som skapade posten.

Hur du än gör, bestäm det med avsikt. Ett integrationskonto som äger allt har i tysthet blivit en del av din säkerhetsarkitektur, och någon behöver veta vad som händer om det någonsin inaktiveras.

Ägarskap kan bli ett skalproblem

Fördelningen spelar också roll. Tio miljoner poster utspridda på tusentals ägare är en form. Tio miljoner poster som ägs av en användare är en helt annan. Salesforce kallar det ownership data skew när en enda användare äger fler än 10 000 poster av ett objekt (Ownership Data Skew (opens in a new tab)). Det händer oftast när någon parkerar allt på en användare eller kö: alla otilldelade leads på en platshållaranvändare, varje integrationspost på integrationsanvändaren. Det är ofarligt tills den användaren flyttas i rollhierarkin, eller in i eller ut ur en grupp som en delningsregel är beroende av. Då måste Salesforce justera ett enormt antal delningsposter, och du får långa omräkningar.

Vägledningen är praktisk. Sprid ägarskapet på fler användare där du kan. Om en användare måste äga mycket, håll den utanför rollhierarkin; om den behöver en roll, ge den en egen roll högst upp och flytta den inte, och håll den utanför publika grupper som delningsregler använder (Ownership Data Skew (opens in a new tab)). Samma tänkande gäller för föräldern med för många barn från förra modulen, parent-child skew.

Så fördelningen är en del av den fysiska modellen. Fråga inte bara hur många poster; fråga hur de är fördelade. Det är ännu en version av Steves ”antal nollor”: inte bara hur många nollor, utan var nollorna är koncentrerade. Del 2 går på djupet med skew; här vill jag att du ser det komma. Kursen om delning och synlighet tar upp det igen i Delning i stor skala.

”Standardägaren” blir arkitektur

Här är ett mönster jag ser hela tiden. Ingen vet vem som ska äga något, så någon säger: ”Tilldela bara alla till integrationsanvändaren”, eller ”skapa en generisk användare som heter System”. Kanske är det rätt. Men gör det inte av misstag. En tillfällig standard har en tendens att bli permanent: två år senare tillhör varje post integration@company.com, ingen minns varför, och att ändra det är ett projekt. Det är reversibilitetstestet från kapitel 1: innan du ger en miljon poster till en ägare, fråga vad det krävs för att ändra det senare.

Omtilldelning är en livscykelhändelse

Ägare byts. Säljare slutar, territorier flyttas, team omorganiseras, regioner balanseras om. Vad är beroende av ägaren: delning, automatisering, rapporter, köer, eskaleringar, integrationer? Om ett ägarbyte ändrar vem som kan se posten är omtilldelning inte admin-städning. Det är en säkerhetshändelse, och vid en miljon poster är det en driftshändelse också. Håll koll på delningstabellen när det händer: manuella delningar tas bort när ägaren byts, medan Apex-delning med en utvecklares egen orsak överlever bytet (Understanding Sharing (opens in a new tab)). I klassrummet delar jag en post med någon, byter ägare, och personen förlorar åtkomsten. Rummet blir alltid förvånat.

Och kom ihåg att ägarskap inte är samma sak som åtkomst. Ägaren är inte den enda som behöver se en post, och Salesforce har många sätt att ge åtkomst: rollhierarkin, delningsregler, team, territorier, manuell och programmatisk delning. Kursen om delning och synlighet går på djupet med dem, med start i Steves 22 sätt att dela en post. Arkitektens poäng är enklare: använd inte ägarskap för att lösa varje åtkomstproblem. Om du flyttar runt ägare bara för att någon ska kunna se en post löser du förmodligen fel problem.

Skapandet är bara början

Mycket datamodellering stannar vid skapandet: fälten, objektet, relationen, klart. Men posten kan leva i tio år. Den uppdateras, byter ägare, byter status och relationer, blir inaktiv, blir historik, kan behöva arkiveras och kanske en dag raderas. Arkitektur handlar inte bara om hur posten föds. Den handlar om vad som händer från födsel till död.

Click to enlarge

Radera inte bara för att något är gammalt

En detaljhandelspartner slutar skicka uppdrag. Radera kontot? Inte automatiskt: dess leveranser, reklamationer och faktureringshistorik spelar fortfarande roll. En lastbil tas ur drift. Radera den, tillsammans med dess leveranshistorik och skadeanmälningar? Saken kanske inte är aktiv längre, men dess data är det. Så jag skiljer på inaktiv och borta. En lastbil som tagits ur drift kan stanna i modellen; en före detta anställd kan fortfarande synas i granskningshistoriken. Arkitekturen måste behålla de fakta som spelar roll efter att den operativa relationen har tagit slut.

Lagringstid är ett affärskrav

Den andra sidan: att spara allt för alltid är inte heller arkitektur. Lagringen växer, rapporter blir långsammare, sökningen blir brusigare och integritetslagstiftningen kan säga att vissa data måste bort. Så jag vill ha ett uttryckligt svar på hur länge sparar vi det här? ”Salesforce sparar det” är ingen lagringspolicy.

Och för det mesta är det här en fråga om transaktionsdata. Referensdata, produkterna, servicetyperna, distributionscentralerna, blir inte enorma, och andra poster pekar på dem, så de stannar oftast kvar. Kunddata ligger mittemellan: det kan komma en dag när du avslutar en kunds livscykel, särskilt när du har personuppgifter och skälet att spara dem tar slut. Men volymen finns i transaktionerna: leveranserna, ordrarna, ärendena, bokningarna, som skapas varje dag, för alltid. Det är de som växer till hundratals miljoner rader, och det är där lagringstiden måste vara uttrycklig: kanske två års driftdata i orgen, sju år av finansiella poster någonstans, nittio dagar för vissa foton. Det är affärsregler, och om ingen har frågat ska arkitekten göra det.

Jag har sagt det i klassrummet i åratal: om du inte arkiverar i dag, kommer du någonsin att arkivera? ”Vi tar det sen” har en tendens att bli ett akutprojekt vid trehundra miljoner poster. Del 2 har en hel modul om arkivering och rensning, byggd på samma fråga.

Steve Trucking: vem äger en leverans?

En leverans skapas från detaljhandelspartnerns manifest, av en integration, ungefär 3 300 gånger om dagen. Vem äger den? Inte detaljhandelspartnern; det är en affärsrelation. Inte mottagaren. Teamet utför den, men ska posten byta ägare varje gång team byter lastbil? Trafikledaren? Distributionscentralen? En kö? Integrationsanvändaren som skapade den?

Tillämpa nu den här modulen, med början i frågan som avgör det: styr ägarskapet någons åtkomst till leveranser? Hos Steve Trucking gör det inte det. Trafikledare ser leveranserna för sin distributionscentral, team ser dem på sina rutter, och varje detaljhandlare ser sina egna i partnerportalen. Inget av det beror på vem som äger posten; det kommer från distributionscentralen, rutten och partnern.

Så mitt svar: integrationsanvändaren äger leveranserna. Det är ett bra exempel på en systemanvändare som äger poster med avsikt:

• Granskningsspåret är ärligt. Varje leverans ägare säger var den kom ifrån: manifestintegrationen.
• Åtkomsten kommer från delning, inte ägarskap. Kriteriebaserade delningsregler på distributionscentralen ger varje DC:s team dess leveranser; partner når sina via portalen.
• Skew är bortdesignat. Med 3 300 om dagen passerar integrationsanvändaren 10 000 leveranser på tre dagar, så det är ownership skew från dag ett, och det är okej om vi planerar för det. Integrationsanvändaren har ingen roll, så inget ovanför den i en hierarki behöver räknas om, och den hålls utanför de publika grupper som våra delningsregler använder.
• Ingen tilldelar om leveranser. Team byter lastbil och trafikledare byter skift, och ägaren flyttas aldrig, så det blir ingen omtilldelningsstorm och inga manuella delningar att förlora.

Och skriv ned vad som händer om den användaren någonsin inaktiveras eller ersätts, för den äger nu miljontals poster. Det är beslutet som nästa team kommer att behöva hitta.

Bortom provet: vad AI förändrar. Agenter skapar och ändrar poster i maskinfart. Om en agent skapar 100 000 poster under sin egen användare blir ”vi fixar ägaren sen” till skew, en omräkning av delningen och ett städprojekt. Bestäm agentens ägarregel innan den går live, med samma fråga: spelar ägarskap roll för delningen här?

Vad en arkitekt bestämmer här

• Om ägarskap representerar affärsansvar, en säkerhetsmekanism eller båda, och var ansvaret bor om inte i Owner.
• Om poster behöver en egen ägare eller ska ärva den från en förälder.
• Vem som äger poster som integrationer och agenter skapar, beroende på om ägarskap styr delningen.
• Hur ägarskapet är fördelat, och hur du undviker ownership skew när en användare måste äga mycket.
• När poster blir inaktiva, när de arkiveras, hur länge de sparas och när radering är rätt.

När du tittar på en fysisk modell, fråga inte bara var data lagras. Fråga vem som äger dem i dag, vem som kan äga dem i morgon och vad som händer när vi inte längre behöver dem. Härnäst: även med rätt objekt, fält, relationer och ägare måste data fortfarande förbli pålitliga.

Utforska vidare

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (på engelska, kontrollerad 2026-10-13): ägare (en användare, eller en kö för anpassade objekt, ärenden och leads) får full åtkomst; det mesta av delningen bor i ett relaterat delningsobjekt; rollhierarkin härleds vid körning; manuella delningar tas bort när ägaren byts, Apex managed sharing behålls; värdena för radorsak.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (på engelska, kontrollerad 2026-10-13): AccountShare, MyCustomObject__Share; detaljobjekt har inget delningsobjekt; vad delningsobjektet inte håller reda på (OWD, rollhierarki, View All och Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (på engelska, kontrollerad 2026-10-13): åtkomst mellan ett konto och dess kontakter, ärenden och affärsmöjligheter.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) och Sharing Rule Considerations (opens in a new tab) (på engelska, kontrollerad 2026-10-13): inga roller, inga delningsregler eller manuella delningar; sharing sets i stället.
• Kursen Sharing & Visibility Architect: Steves 22 sätt att dela en post, Org-Wide Defaults, ägarskap, köer och rollhierarkin, Relationer och inbyggd delning, Programmatisk delning och säker kod, Delning med externa användare, Delning i stor skala.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) och Parent-Child Data Skew (opens in a new tab) (på engelska, kontrollerad 2026-10-02).