Gå til innholdet
SteveTechArcSteveTechArc Courses

Eierskap og livssyklus

Finnes også 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 · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

The cut end of a large log in a forest, every year's growth ring visible from the center to the bark.
Bildet er laget med KI

Modul 8 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Relasjoner har konsekvenser · Neste: Hold data konsistente

Spørsmålet denne modulen besvarer: Hvem eier posten, og hva skjer med den gjennom hele livet?

Når jeg ser på en datamodell, vil jeg ikke bare vite hva objektene er og hvordan de henger sammen. Jeg vil vite hva som skjer med postene over tid. Hvem oppretter dem? Hvem eier dem? Hvem kan tildele dem på nytt? Hva skjer når forretningsrelasjonen endres, når de ikke lenger er aktive? Skal de noen gang slettes, og hvor lenge tar vi vare på dem? Ingenting av det vises på et ER-diagram (entity relationship diagram): boksene og linjene i datamodellen fra kapittel 2. Alt sammen er dataarkitektur. Og i Salesforce er eierskap stedet der datamodellen og sikkerhetsmodellen kolliderer.

Eierskap er mer enn et navn i et felt

Section titled “Eierskap er mer enn et navn i et felt ”

Admins ser Owner på en post og leser det som en etikett: Bart eier denne kontoen, Lisa eier den saken. Det kan bety det. Men i Salesforce er eierskap også en plattformmekanisme. På objekter som har en eier, styrer eieren hvem som kan se posten, gjennom rollehierarkiet, delingsregler, køer og ny tildeling. Så når jeg spør «hvem eier denne posten?», spør jeg ikke hvem sitt navn som står på siden. Jeg spør hvilken sikkerhets- og livssyklusoppførsel vi knytter til den. Eieren kan være en bruker, eller for noen objekter, blant dem egendefinerte objekter, saker og kundeemner, en kø, og uansett får eieren full tilgang til posten (Understanding Sharing (opens in a new tab)).

Det er derfor jeg skiller forretningsansvar fra posteierskap. Noen ganger er det samme person. Noen ganger ikke. Sier forretningen at en disponent er ansvarlig for en levering, gjør ikke det automatisk disponenten til eier. Ansvaret kan bo i et eget felt, mens eierskapet settes for å støtte sikkerhet og skala. Ikke la de to bli blandet sammen bare fordi begge bruker ordet «eier».

Delingstabellen: der eierskap blir tilgang

Section titled “Delingstabellen: der eierskap blir tilgang ”

Noen vet ikke engang hva delingstabellen er. Hver dataarkitekt bør vite det.

Det meste av delingen for en post ligger i et relatert delingsobjekt (share object), Salesforces versjon av en tilgangskontrolliste (Understanding Sharing (opens in a new tab)). Account har AccountShare, Contact har ContactShare, og et egendefinert objekt får sitt eget: Truck__c har Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Hver rad i det sier fire ting:

  • Hvilken post: forelderens ID.
  • Hvem: en bruker eller en gruppe (en offentlig gruppe, en rolles gruppe, et område).
  • Hvor mye: Read, Edit eller All (full tilgang).
  • Hvorfor: radårsaken (row cause). Owner for eieren, Rule for en delingsregel, Manual for en manuell deling, Team, de implisitte årsakene Salesforce legger til mellom en konto og barna dens, og årsaker en utvikler definerer for Apex-deling.

På kurs åpner jeg Workbench og spør mot delingstabellen mens jeg deler en post, og du ser radene dukke opp og forsvinne. Når noen spør «hvorfor kan denne personen se det?», ligger svaret ofte i en rad, med årsaken sin.

Men ikke alt ligger der. Den organisasjonsomfattende standarden (organization-wide default) er ikke en rad. Rollehierarkiet lagres heller ikke der: tilgangen for dem over eieren regnes ut når den trengs. Og View All, Modify All, View All Data og Modify All Data hopper helt over delingstabellen (Sharing a Record Using Apex (opens in a new tab)). Som jeg sier på kurs: kryss av for View All, og du har gått forbi delingstabellen.

Salesforce deler også noen poster for deg, på grunn av hvordan de er relatert. Dette er implisitt deling, og det virker mellom en konto og barna dens. Kan du se en kontakt, en sak eller en salgsmulighet, kan du også lese kontoen den hører til. Og kontoeieren får tilgang til kontoens kontakter, saker og salgsmuligheter, på et nivå som settes av eierens rolle (Implicit Sharing (opens in a new tab)). I nyere releaser regner Salesforce ut noe av den barnetilgangen når den trengs, i stedet for å lagre den som rader, så ikke bli overrasket når en spørring mot delingstabellen ikke viser den. Jeg gir deg bare et hint her; detaljene står i Relasjoner og innebygd deling.

Ett unntak til, for når du har mange eksterne brukere. Høyvolumbrukere i communities (high-volume community users), Customer Community-lisensene laget for tusenvis til millioner av kunder, har ingen rolle, kan ikke være i offentlige grupper og kan ikke få poster gjennom delingsregler eller manuell deling (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). For dem er ikke delingstabellen svaret: de kommer til poster gjennom delingssett (sharing sets), som matcher en posts konto eller kontakt mot brukerens egen. Det er en av grunnene til at de lisensene skalerer. Kurset Sharing and Visibility dekker det i Deling med eksterne brukere.

Og husk modul 7: et detaljobjekt har ikke noe delingsobjekt i det hele tatt. Tilgangen kommer fra masterens delingsobjekt og Sharing Setting på master-detail-feltet.

Hvorfor bryr en dataarkitekt seg? Fordi eierskapet skrives inn i denne tabellen. Hvert eierbytte, hver nye delingsregel, hver bruker som bytter rolle eller gruppe, betyr at Salesforce legger til og fjerner rader. Med noen få tusen poster merker ingen noe. Med ti millioner, og én bruker som eier de fleste, er det omberegningen vi skal møte om et øyeblikk.

Eksamenskunnskap. Et egendefinert objekts delingsobjekt heter Object__Share, som Truck__Share. Et detaljobjekt har ikke noe delingsobjekt: tilgangen kommer fra masteren. Og når en posts eier endres, fjernes de manuelle delingene, mens Apex-deling med en utviklers egen årsak blir stående.

Det er her datamodellen gir stafettpinnen videre til sikkerhetsmodellen, og resten underviser jeg i kurset Sharing and Visibility Architect: Steves 22 måter å dele en post på, Org-Wide Defaults, eierskap, køer og rollehierarkiet, Relasjoner og innebygd deling for de implisitte delingene, og Programmatisk deling og sikker kode for årsaker til Apex-deling. I dette kurset samler kapittel 12 det for mennesker, applikasjoner og agenter.

Noen ganger arves eierskapet

Section titled “Noen ganger arves eierskapet ”

I forrige modul så vi at et master-detail-barn ikke har sin egen eier; det følger forelderen. Det er ofte helt riktig. Trenger forretningen en annen eier for hver linje på en levering? Nei. Leveringen eier livssyklusen, og linjen tilhører den. Det er derfor relasjonsdesign og eierskapsdesign skjer sammen: da du valgte master-detail, hadde du allerede tatt en del av eierskapsbeslutningen.

Hvem eier poster som systemer lager?

Section titled “Hvem eier poster som systemer lager? ”

Nå blir det interessant. En person oppretter en konto, og kanskje blir de eieren. Men et ERP-system sender 100 000 transaksjoner i løpet av natta. Hvem eier dem? Integrasjonsbrukeren? En kø? En regional eier utledet fra dataene? En systemkonto ingen har tenkt på på fem år? Og nå oppretter agenter poster også.

Mitt standpunkt: det avhenger av om eierskapet betyr noe for delingen. Integrasjonsbrukeren, eller agentbrukeren, er en gyldig bruker, og den kan eie postene. Styrer eierskap tilgangen i det objektet (gjennom rollehierarkiet eller delingsregler), tildel postene til riktig eier: en ekte bruker, en kø eller en dedikert eierbruker. Gjør det ikke det, kan det være bedre å la systembrukeren være eier, for da fører revisjonssporet rett tilbake til det som opprettet posten.

Uansett: bestem det med vilje. En integrasjonskonto som eier alt, har i det stille blitt en del av sikkerhetsarkitekturen din, og noen må vite hva som skjer hvis den noen gang blir deaktivert.

Eierskap kan bli et skalaproblem

Section titled “Eierskap kan bli et skalaproblem ”

Fordelingen betyr også noe. Ti millioner poster spredt på tusenvis av eiere er én form. Ti millioner poster eid av én bruker er en helt annen. Salesforce kaller det ownership data skew (eierskapsskjevhet) når én enkelt bruker eier mer enn 10 000 poster av et objekt (Ownership Data Skew (opens in a new tab)). Det skjer som regel når noen parkerer alt på én bruker eller kø: alle de ufordelte kundeemnene på en plassholderbruker, hver integrasjonspost på integrasjonsbrukeren. Det er harmløst helt til den brukeren flytter i rollehierarkiet, eller inn i eller ut av en gruppe en delingsregel avhenger av. Da må Salesforce justere et enormt antall delingsoppføringer, og du får langvarige omberegninger.

Veiledningen er praktisk. Spre eierskapet på flere brukere der du kan. Må én bruker eie mye, hold dem utenfor rollehierarkiet; trenger de en rolle, gi dem en egen rolle på toppen og ikke flytt dem, og hold dem utenfor offentlige grupper som delingsregler bruker (Ownership Data Skew (opens in a new tab)). Den samme tenkningen gjelder forelderen med for mange barn fra forrige modul, parent-child skew (forelder-barn-skjevhet).

Så fordelingen er en del av den fysiske modellen. Ikke bare spør hvor mange poster; spør hvordan de er fordelt. Det er enda en versjon av Steves «antall nuller»: ikke bare hvor mange nuller, men hvor nullene er samlet. Del 2 går i dybden på skew; her vil jeg at du skal se det komme. Kurset Sharing and Visibility tar det opp igjen i Deling i stor skala.

«Standardeieren» blir arkitektur

Section titled “«Standardeieren» blir arkitektur ”

Her er et mønster jeg ser hele tiden. Ingen vet hvem som skal eie noe, så noen sier: «Bare tildel alle til integrasjonsbrukeren», eller «lag en generell bruker som heter System». Kanskje er det riktig. Men ikke gjør det ved et uhell. En midlertidig standard har en tendens til å bli permanent: to år senere tilhører hver post integration@company.com, ingen husker hvorfor, og å endre det er et prosjekt. Det er reversibilitetstesten fra kapittel 1: før du gir en million poster til én eier, spør hva det krever å endre det senere.

Ny tildeling er en livssyklushendelse

Section titled “Ny tildeling er en livssyklushendelse ”

Eiere endres. Selgere slutter, områder flyttes, team omorganiseres, regioner balanseres på nytt. Hva avhenger av eieren: deling, automatisering, rapporter, køer, eskaleringer, integrasjoner? Endrer et eierbytte hvem som kan se posten, er ny tildeling ikke admin-opprydding. Det er en sikkerhetshendelse, og med en million poster er det en driftshendelse også. Følg med på delingstabellen når det skjer: manuelle delinger fjernes når eieren endres, mens Apex-deling med en utviklers egen årsak overlever endringen (Understanding Sharing (opens in a new tab)). På kurs deler jeg en post med noen, bytter eier, og personen mister tilgangen. Rommet blir alltid overrasket.

Og husk at eierskap ikke er det samme som tilgang. Eieren er ikke den eneste som trenger å se en post, og Salesforce har mange måter å gi tilgang på: rollehierarkiet, delingsregler, team, områder, manuell og programmatisk deling. Kurset Sharing and Visibility går i dybden på dem, og begynner med Steves 22 måter å dele en post på. Arkitektens poeng er enklere: ikke bruk eierskap til å løse hvert tilgangsproblem. Flytter du eiere rundt bare så noen kan se en post, løser du sannsynligvis feil problem.

Opprettelsen er bare begynnelsen

Section titled “Opprettelsen er bare begynnelsen ”

Mye datamodellering stopper ved opprettelsen: feltene, objektet, relasjonen, ferdig. Men posten kan leve i ti år. Den oppdateres, bytter eier, endrer status og relasjoner, blir inaktiv, blir historikk, må kanskje arkiveres og en dag kanskje slettes. Arkitektur er ikke bare hvordan posten blir født. Det er hva som skjer fra fødsel til død.

En posts liv En posts liv i seks trinn, koblet med piler. Opprettet: hvem eier den, og hvem ser den? Aktiv: hvilken automatisering kjører? Tildelt på nytt: hvem får eller mister tilgang? Inaktiv: trengs den fortsatt for historikken? Arkivert: hvor havner den, og kan den fortsatt finnes? Slettet eller beholdt: hva sier oppbevaringsregelen? Under: arkitektur handler ikke bare om hvordan posten blir født; den handler om hva som skjer fra fødsel til død. Opprettet Hvem eier den? Hvem ser den? Aktiv Hvilken automatisering kjører? Tildelt på nytt Hvem får eller mister tilgang? Inaktiv Trengs den fortsatt for historikken? Arkivert Hvor, og kan den fortsatt finnes? Slettet eller beholdt Hva sier oppbevaringsregelen? Arkitektur handler ikke bare om hvordan posten blir født. Den handler om hva som skjer fra fødsel til død. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Ikke slett bare fordi noe er gammelt

Section titled “Ikke slett bare fordi noe er gammelt ”

En detaljhandelspartner slutter å sende oppdrag. Slette kontoen? Ikke automatisk: leveringene, reklamasjonene og faktureringshistorikken betyr fortsatt noe. En lastebil tas ut av drift. Slette den, sammen med leveringshistorikken og skadesakene? Tingen er kanskje ikke lenger aktiv, men dataene er det fortsatt. Så jeg skiller inaktiv fra borte. En utrangert lastebil kan bli værende i modellen; en tidligere ansatt kan fortsatt dukke opp i revisjonshistorikken. Arkitekturen må ta vare på faktaene som betyr noe etter at den operative relasjonen er over.

Oppbevaring er et forretningskrav

Section titled “Oppbevaring er et forretningskrav ”

Den andre siden: å ta vare på alt for alltid er heller ikke arkitektur. Lagringen vokser, rapporter blir tregere, søk blir mer støyete, og personvernlovgivningen kan si at noen data må bort. Så jeg vil ha et eksplisitt svar på hvor lenge tar vi vare på dette? «Salesforce tar vare på det» er ikke en oppbevaringspolicy.

Og for det meste er dette et spørsmål om transaksjonsdata. Referansedata, produktene, tjenestetypene, distribusjonssentrene, blir ikke enorme, og andre poster peker på dem, så de blir som regel værende. Kundedata ligger midt imellom: det kan komme en dag da du avslutter livet til en kunde, særlig når du holder personopplysninger og grunnen til å beholde dem tar slutt. Men volumet ligger i transaksjonene: leveringene, ordrene, sakene, avtalene, opprettet hver dag, for alltid. Det er det som vokser til hundrevis av millioner rader, og det er der oppbevaringen må være eksplisitt: kanskje to år med driftsdata i orgen, sju år med regnskapsdata et sted, nitti dager for noen bilder. Det er forretningsregler, og har ingen spurt, bør arkitekten gjøre det.

Jeg har sagt det på kurs i årevis: hvis du ikke arkiverer i dag, kommer du noen gang til å arkivere? «Vi tar det senere» har en tendens til å bli et nødprosjekt ved tre hundre millioner poster. Del 2 har en hel modul om arkivering og sletting, bygd på det samme spørsmålet.

Steve Trucking: hvem eier en levering?

Section titled “Steve Trucking: hvem eier en levering? ”

En levering opprettes fra detaljhandelspartnerens manifest, av en integrasjon, omtrent 3 300 ganger om dagen. Hvem eier den? Ikke detaljhandelspartneren; det er en forretningsrelasjon. Ikke mottakeren. Teamet utfører den, men skal posten bytte eier hver gang team bytter lastebil? Disponenten? Distribusjonssenteret? En kø? Integrasjonsbrukeren som opprettet den?

Bruk nå denne modulen, og begynn med spørsmålet som avgjør det: styrer eierskapet noens tilgang til leveringer? Hos Steve Trucking gjør det ikke det. Disponentene ser leveringene for distribusjonssenteret sitt, teamene ser dem på rutene sine, og hver detaljhandelskjede ser sine egne i partnerportalen. Ingenting av det avhenger av hvem som eier posten; det kommer fra distribusjonssenteret, ruten og partneren.

Så svaret mitt: integrasjonsbrukeren eier leveringene. Det er et godt eksempel på en systembruker som eier poster med vilje:

  • Revisjonssporet er ærlig. Eieren av hver levering sier hvor den kom fra: manifestintegrasjonen.
  • Tilgangen kommer fra deling, ikke eierskap. Kriteriebaserte delingsregler på distribusjonssenteret gir teamet på hvert DC leveringene sine; partnerne når sine gjennom portalen.
  • Skew er designet bort. Med 3 300 om dagen passerer integrasjonsbrukeren 10 000 leveringer på tre dager, så det er eierskapsskjevhet fra dag én, og det er greit hvis vi planlegger for det. Integrasjonsbrukeren har ingen rolle, så ingenting over den i et hierarki må beregnes på nytt, og den holdes utenfor de offentlige gruppene delingsreglene våre bruker.
  • Ingen tildeler leveringer på nytt. Team bytter lastebil og disponenter bytter skift, og eieren flytter seg aldri, så det blir ingen storm av nye tildelinger og ingen manuelle delinger å miste.

Og skriv ned hva som skjer hvis den brukeren noen gang blir deaktivert eller erstattet, for den eier nå millioner av poster. Det er beslutningen neste team kommer til å trenge å finne.

Utover eksamen: hva KI endrer. Agenter oppretter og endrer poster i maskinfart. Oppretter en agent 100 000 poster under sin egen bruker, blir «vi fikser eieren senere» til skew, en omberegning av delingen og et oppryddingsprosjekt. Bestem agentens eierskapsregel før den går live, med det samme spørsmålet: betyr eierskapet noe for delingen her?

Hva en arkitekt bestemmer her

Section titled “Hva en arkitekt bestemmer her ”
  • Om eierskap representerer forretningsansvar, en sikkerhetsmekanisme eller begge deler, og hvor ansvaret bor hvis ikke i Owner.
  • Om poster trenger sin egen eier eller skal arve den fra en forelder.
  • Hvem som eier poster integrasjoner og agenter oppretter, avhengig av om eierskap styrer deling.
  • Hvordan eierskapet er fordelt, og hvordan du unngår eierskapsskjevhet når én bruker må eie mye.
  • Når poster blir inaktive, når de arkiveres, hvor lenge de oppbevares, og når sletting er riktig.

Når du ser på en fysisk modell, ikke bare spør hvor dataene er lagret. Spør hvem som eier dem i dag, hvem som kan eie dem i morgen, og hva som skjer når vi ikke lenger trenger dem. Neste: selv med riktig objekt, felt, relasjoner og eier må dataene fortsatt forbli pålitelige.

Les mer

Section titled “Les mer ”