Ejerskab og livscyklus

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 8 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Relationer har konsekvenser · Næste: Hold data konsistente

Spørgsmålet, dette modul besvarer: Hvem ejer posten, og hvad sker der med den gennem hele dens liv?

Når jeg ser på en datamodel, vil jeg ikke bare vide, hvad objekterne er, og hvordan de hænger sammen. Jeg vil vide, hvad der sker med posterne over tid. Hvem opretter dem? Hvem ejer dem? Hvem kan tildele dem til en anden? Hvad sker der, når forretningsrelationen ændrer sig, når de ikke længere er aktive? Skal de nogensinde slettes, og hvor længe gemmer vi dem? Intet af det fremgår af et ERD, entity relationship-diagrammet: kasserne og linjerne i datamodellen fra kapitel 2. Alt det er dataarkitektur. Og i Salesforce er ejerskab stedet, hvor datamodellen og sikkerhedsmodellen støder ind i hinanden.

Ejerskab er mere end et navn i et felt

Admins ser Owner på en post og læser det som en etiket: Bart ejer denne konto, Lisa ejer den sag. Det kan det godt betyde. Men i Salesforce er ejerskab også en platformsmekanisme. På objekter, der har en ejer, styrer ejeren, hvem der kan se posten, gennem rollehierarkiet, delingsregler, køer og omfordeling. Så når jeg spørger »hvem ejer denne post?«, spørger jeg ikke, hvis navn der står på siden. Jeg spørger, hvilken sikkerheds- og livscyklusadfærd vi knytter til den. Ejeren kan være en bruger eller for nogle objekter, blandt andet brugerdefinerede objekter, sager og kundeemner, en kø, og uanset hvad får ejeren fuld adgang til posten (Understanding Sharing (opens in a new tab)).

Derfor skelner jeg mellem forretningsansvar og ejerskab af posten. Nogle gange er det den samme person. Nogle gange ikke. Hvis forretningen siger, at en disponent er ansvarlig for en levering, gør det ikke automatisk disponenten til ejer. Ansvaret kan bo i sit eget felt, mens ejerskabet sættes, så det understøtter sikkerhed og skala. Lad ikke de to blive blandet sammen, bare fordi begge bruger ordet »ejer«.

Delingstabellen: hvor ejerskab bliver til adgang

Nogle ved ikke engang, hvad delingstabellen er. Det bør enhver dataarkitekt vide.

Det meste af delingen for en post gemmes i et relateret delingsobjekt (share object), Salesforces udgave af en adgangskontrolliste (Understanding Sharing (opens in a new tab)). Account har AccountShare, Contact har ContactShare, og et brugerdefineret objekt får sit eget: Truck__c har Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Hver række i det siger fire ting:

• Hvilken post: forælderens id.
• Hvem: en bruger eller en gruppe (en offentlig gruppe, en rolles gruppe, et område).
• Hvor meget: Read, Edit eller All (fuld adgang).
• Hvorfor: årsagen til rækken (row cause). Owner for ejeren, Rule for en delingsregel, Manual for en manuel deling, Team, de implicitte årsager, som Salesforce tilføjer mellem en konto og dens børn, og årsager, som en udvikler definerer til Apex-deling.

I klassen åbner jeg Workbench og forespørger delingstabellen, mens jeg deler en post, og så ser du rækkerne dukke op og forsvinde. Når nogen spørger »hvorfor kan denne person se det?«, står svaret ofte i en række, med sin årsag.

Men ikke alt står i den. Den organisationsdækkende standard (organization-wide default) er ikke en række. Rollehierarkiet gemmes heller ikke der: Adgangen for folk over ejeren beregnes, når der er brug for den. Og View All, Modify All, View All Data og Modify All Data springer helt uden om delingstabellen (Sharing a Record Using Apex (opens in a new tab)). Som jeg siger i klassen: Sæt flueben i View All, og du er gået uden om delingstabellen.

Salesforce deler også nogle poster for dig på grund af, hvordan de er relateret. Det er implicit deling, og den virker mellem en konto og dens børn. Hvis du kan se en kontakt, en sag eller en salgsmulighed, kan du også læse den konto, den hører til. Og kontoens ejer får adgang til kontoens kontakter, sager og salgsmuligheder på et niveau, som ejerens rolle bestemmer (Implicit Sharing (opens in a new tab)). I nyere releases beregner Salesforce noget af den adgang til børn, når der er brug for den, i stedet for at gemme den som rækker, så bliv ikke overrasket, når en forespørgsel på delingstabellen ikke viser den. Jeg giver dig kun et hint her; detaljerne står i Relationer og indbygget deling.

Én undtagelse mere, til når du har mange eksterne brugere. Højvolumen-community-brugere (high-volume community users), de Customer Community-licenser, der er bygget til tusinder eller millioner af kunder, har ingen rolle, kan ikke være i offentlige grupper og kan ikke få poster gennem delingsregler eller manuel deling (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). For dem er delingstabellen ikke svaret: De når poster gennem sharing sets, som matcher en posts konto eller kontakt med brugerens egen. Det er en af grundene til, at de licenser kan skaleres. Kurset Sharing and Visibility gennemgår det i Deling med eksterne brugere.

Og husk modul 7: Et detaljeobjekt har slet intet delingsobjekt. Dets adgang kommer fra masterens delingsobjekt og Sharing Setting på master-detail-feltet.

Hvorfor interesserer en dataarkitekt sig for det? Fordi ejerskab skrives ind i denne tabel. Hver ændring af ejer, hver ny delingsregel, hver bruger, der skifter rolle eller gruppe, betyder, at Salesforce tilføjer og fjerner rækker. Ved et par tusinde poster lægger ingen mærke til det. Ved ti millioner, hvor én bruger ejer de fleste af dem, er det den genberegning, vi møder om lidt.

Eksamensviden. Et brugerdefineret objekts delingsobjekt hedder Object__Share, som Truck__Share. Et detaljeobjekt har intet delingsobjekt: Dets adgang kommer fra masteren. Og når en posts ejer ændres, fjernes dens manuelle delinger, mens Apex-deling med en udviklers egen årsag bliver.

Det er her, datamodellen giver stafetten videre til sikkerhedsmodellen, og resten underviser jeg i i kurset Sharing and Visibility Architect: Steves 22 måder at dele en post på, Org-Wide Defaults, ejerskab, køer og rollehierarkiet, Relationer og indbygget deling om de implicitte delinger og Programmatisk deling og sikker kode om årsager til Apex-deling. I dette kursus samler kapitel 12 det hele for mennesker, applikationer og agenter.

Nogle gange er ejerskabet nedarvet

I sidste modul så vi, at et master-detail-barn ikke har sin egen ejer; det følger sin forælder. Det er ofte helt rigtigt. Har forretningen brug for en forskellig ejer for hver linje på en levering? Nej. Leveringen ejer livscyklussen, og linjen tilhører den. Det er derfor, relationsdesign og ejerskabsdesign sker samtidig: Da du valgte master-detail, havde du allerede truffet en del af ejerskabsbeslutningen.

Hvem ejer de poster, som systemer opretter?

Nu bliver det interessant. En person opretter en konto, og måske bliver vedkommende ejer. Men et ERP-system sender 100.000 transaktioner i løbet af natten. Hvem ejer dem? Integrationsbrugeren? En kø? En regional ejer, der udledes af dataene? En systemkonto, som ingen har tænkt på i fem år? Og nu opretter agenter også poster.

Min holdning: Det afhænger af, om ejerskab betyder noget for delingen. Integrationsbrugeren, eller agentbrugeren, er en gyldig bruger, og den kan eje posterne. Hvis ejerskab styrer adgangen i det objekt (gennem rollehierarkiet eller delingsregler), så tildel posterne til den rigtige ejer: en rigtig bruger, en kø eller en dedikeret ejerbruger. Hvis ikke, kan det være det bedre valg at lade systembrugeren være ejer, for så fører revisionssporet direkte tilbage til det, der oprettede posten.

Uanset hvad, så beslut det med vilje. En integrationskonto, der ejer alt, er i al stilhed blevet en del af din sikkerhedsarkitektur, og nogen skal vide, hvad der sker, hvis den nogensinde bliver deaktiveret.

Ejerskab kan blive et skalaproblem

Fordelingen betyder også noget. Ti millioner poster fordelt på tusindvis af ejere er én form. Ti millioner poster ejet af én bruger er en helt anden. Salesforce kalder det ownership data skew, når én bruger ejer mere end 10.000 poster af et objekt (Ownership Data Skew (opens in a new tab)). Det sker som regel, når nogen parkerer alt på én bruger eller kø: alle de ikke-tildelte kundeemner på en pladsholderbruger, hver integrationspost på integrationsbrugeren. Det er harmløst, indtil den bruger flytter i rollehierarkiet eller ind i eller ud af en gruppe, som en delingsregel afhænger af. Så skal Salesforce justere et enormt antal delingsposter, og du får langvarige genberegninger.

Vejledningen er praktisk. Fordel ejerskabet på flere brugere, hvor du kan. Hvis én bruger skal eje meget, så hold vedkommende uden for rollehierarkiet; har brugeren brug for en rolle, så giv den sin egen rolle øverst, og flyt den ikke, og hold den ude af offentlige grupper, som delingsregler bruger (Ownership Data Skew (opens in a new tab)). Den samme tankegang gælder forælderen med for mange børn fra sidste modul, parent-child skew.

Så fordelingen er en del af den fysiske model. Spørg ikke bare, hvor mange poster der er; spørg, hvordan de er fordelt. Det er endnu en udgave af Steves »antal nuller« (Steve’s Number of Zeros): ikke kun hvor mange nuller, men hvor nullerne er samlet. Del 2 går i dybden med skew; her vil jeg have, at du ser det komme. Kurset Sharing and Visibility tager det op igen i Deling i stor skala.

»Standardejeren« bliver arkitektur

Her er et mønster, jeg ser hele tiden. Ingen ved, hvem der skal eje noget, så nogen siger: »Tildel dem bare alle til integrationsbrugeren« eller »opret en generisk bruger, der hedder System«. Måske er det rigtigt. Men gør det ikke ved et tilfælde. En midlertidig standard har en tendens til at blive permanent: To år senere tilhører hver post integration@company.com, ingen husker hvorfor, og at ændre det er et projekt. Det er reversibilitetstesten fra kapitel 1: Før du giver en million poster til én ejer, så spørg, hvad det kræver at ændre det senere.

Omfordeling er en livscyklushændelse

Ejere skifter. Sælgere stopper, områder flytter, teams omorganiseres, regioner balanceres om. Hvad afhænger af ejeren: deling, automatisering, rapporter, køer, eskaleringer, integrationer? Hvis en ny ejer ændrer, hvem der kan se posten, er omfordeling ikke admin-oprydning. Det er en sikkerhedshændelse, og ved en million poster er det også en driftshændelse. Hold øje med delingstabellen, når det sker: Manuelle delinger fjernes, når ejeren ændres, mens Apex-deling med en udviklers egen årsag overlever ændringen (Understanding Sharing (opens in a new tab)). I klassen deler jeg en post med nogen, ændrer ejeren, og personen mister adgangen. Lokalet bliver altid overrasket.

Og husk, at ejerskab ikke er det samme som adgang. Ejeren er ikke den eneste, der har brug for at se en post, og Salesforce har mange måder at give adgang på: rollehierarkiet, delingsregler, teams, områder, manuel og programmatisk deling. Kurset Sharing and Visibility går i dybden med dem, begyndende med Steves 22 måder at dele en post på. Arkitektens pointe er enklere: Brug ikke ejerskab til at løse ethvert adgangsproblem. Hvis du flytter ejere rundt bare for at nogen kan se en post, løser du sandsynligvis det forkerte problem.

Oprettelsen er kun begyndelsen

Meget datamodellering stopper ved oprettelsen: felterne, objektet, relationen, færdig. Men posten lever måske i ti år. Den bliver opdateret, skifter ejer, skifter status og relationer, bliver inaktiv, bliver historik, skal måske arkiveres og en dag måske slettes. Arkitektur er ikke bare, hvordan posten bliver født. Det er, hvad der sker fra fødsel til død.

Click to enlarge

Slet ikke bare, fordi noget er gammelt

En detailpartner holder op med at sende opgaver. Slet kontoen? Ikke automatisk: Dens leveringer, reklamationer og faktureringshistorik betyder stadig noget. En lastbil bliver taget ud af drift. Slet den sammen med dens leveringshistorik og skadesanmeldelser? Tingen er måske ikke længere aktiv, men dens data er. Så jeg skelner mellem inaktiv og væk. En udfaset lastbil kan blive i modellen; en tidligere medarbejder kan stadig optræde i revisionshistorikken. Arkitekturen skal bevare de fakta, der betyder noget, efter at den operationelle relation er slut.

Opbevaring er et forretningskrav

Den anden side: At gemme alt for evigt er heller ikke arkitektur. Lagerpladsen vokser, rapporter bliver langsommere, søgning får mere støj, og privatlivslovgivningen kan sige, at nogle data skal væk. Så jeg vil have et eksplicit svar på, hvor længe vi gemmer det her? »Salesforce gemmer det« er ikke en opbevaringspolitik.

Og for det meste er det et spørgsmål om transaktionsdata. Referencedata, produkterne, servicetyperne, distributionscentrene, bliver ikke enorme, og andre poster peger på dem, så de bliver som regel. Kundedata ligger midt imellem: Der kan komme en dag, hvor du udfaser en kunde, især når du har personoplysninger, og grunden til at gemme dem udløber. Men volumen ligger i transaktionerne: leveringerne, ordrerne, sagerne, aftalerne, der oprettes hver dag, for evigt. Det er dem, der vokser til hundredvis af millioner rækker, og det er dér, opbevaringen skal være eksplicit: måske to års driftsdata i org’en, syv års regnskabsposter et sted, halvfems dage for nogle fotos. Det er forretningsregler, og hvis ingen har spurgt, bør arkitekten gøre det.

Jeg har sagt det i klassen i årevis: Hvis du ikke arkiverer i dag, kommer du så nogensinde til at arkivere? »Det tager vi os af senere« har en tendens til at blive et nødprojekt ved tre hundrede millioner poster. Del 2 har et helt modul om arkivering og sletning, bygget på det samme spørgsmål.

Steve Trucking: hvem ejer en levering?

En levering oprettes ud fra detailpartnerens manifest af en integration, cirka 3.300 gange om dagen. Hvem ejer den? Ikke detailpartneren; det er en forretningsrelation. Ikke modtageren. Teamet udfører den, men skal posten skifte ejer, hver gang teams bytter lastbiler? Disponenten? Distributionscentret? En kø? Integrationsbrugeren, der oprettede den?

Anvend nu dette modul, begyndende med det spørgsmål, der afgør det: Styrer ejerskab nogens adgang til leveringer? Hos Steve Trucking gør det ikke. Disponenter ser leveringerne for deres distributionscenter, teams ser dem på deres ruter, og hver detailkæde ser sine egne i partnerportalen. Intet af det afhænger af, hvem der ejer posten; det kommer fra distributionscentret, ruten og partneren.

Så mit svar: Integrationsbrugeren ejer leveringerne. Det er et godt eksempel på en systembruger, der ejer poster med vilje:

• Revisionssporet er ærligt. Hver leverings ejer siger, hvor den kom fra: manifestintegrationen.
• Adgang kommer fra deling, ikke fra ejerskab. Kriteriebaserede delingsregler på distributionscentret giver hvert DC’s team dets leveringer; partnere når deres gennem portalen.
• Skew er designet væk. Med 3.300 om dagen passerer integrationsbrugeren 10.000 leveringer på tre dage, så det er ownership skew fra dag ét, og det er fint, hvis vi planlægger for det. Integrationsbrugeren har ingen rolle, så intet over den i et hierarki skal genberegnes, og den holdes ude af de offentlige grupper, som vores delingsregler bruger.
• Ingen omfordeler leveringer. Teams bytter lastbiler, og disponenter skifter vagt, og ejeren flytter sig aldrig, så der er ingen omfordelingsstorm og ingen manuelle delinger at miste.

Og skriv ned, hvad der sker, hvis den bruger nogensinde bliver deaktiveret eller udskiftet, for den ejer nu millioner af poster. Det er den beslutning, det næste team får brug for at finde.

Ud over eksamen: hvad AI ændrer. Agenter opretter og ændrer poster med maskinhastighed. Hvis en agent opretter 100.000 poster under sin egen bruger, bliver »vi retter ejeren senere« til skew, en genberegning af delingen og et oprydningsprojekt. Beslut agentens ejerskabsregel, før den går live, med det samme spørgsmål: Betyder ejerskab noget for delingen her?

Hvad en arkitekt beslutter her

• Om ejerskab repræsenterer forretningsansvar, en sikkerhedsmekanisme eller begge dele, og hvor ansvaret bor, hvis ikke i Owner.
• Om poster har brug for deres egen ejer eller skal arve den fra en forælder.
• Hvem der ejer de poster, som integrationer og agenter opretter, afhængigt af om ejerskab styrer delingen.
• Hvordan ejerskabet er fordelt, og hvordan man undgår ownership skew, når én bruger skal eje meget.
• Hvornår poster bliver inaktive, hvornår de arkiveres, hvor længe de gemmes, og hvornår sletning er det rigtige.

Når du ser på en fysisk model, så spørg ikke bare, hvor dataene er gemt. Spørg, hvem der ejer dem i dag, hvem der måske ejer dem i morgen, og hvad der sker, når vi ikke længere har brug for dem. Næste gang: Selv med det rigtige objekt, de rigtige felter, relationer og den rigtige ejer skal dataene stadig forblive troværdige.

Læs mere

• Apex Developer Guide, Understanding Sharing (opens in a new tab), på engelsk, kontrolleret 2026-10-13: Ejere (en bruger eller en kø for brugerdefinerede objekter, sager og kundeemner) får fuld adgang; det meste af delingen bor i et relateret delingsobjekt; rollehierarkiet udledes under kørsel; manuelle delinger fjernes, når ejeren ændres, Apex managed sharing bevares; værdierne for row cause.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab), på engelsk, kontrolleret 2026-10-13: AccountShare, MyCustomObject__Share; detaljeobjekter har intet delingsobjekt; hvad delingsobjektet ikke registrerer (OWD, rollehierarki, View All og Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab), på engelsk, kontrolleret 2026-10-13: adgang mellem en konto og dens kontakter, sager og salgsmuligheder.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) og Sharing Rule Considerations (opens in a new tab), på engelsk, kontrolleret 2026-10-13: ingen roller, ingen delingsregler eller manuelle delinger; sharing sets i stedet.
• Kurset Sharing and Visibility Architect: Steves 22 måder at dele en post på, Org-Wide Defaults, ejerskab, køer og rollehierarkiet, Relationer og indbygget deling, Programmatisk deling og sikker kode, Deling med eksterne brugere, Deling i stor skala.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) og Parent-Child Data Skew (opens in a new tab), på engelsk, kontrolleret 2026-10-02.