Eigenaarschap en levenscyclus

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 8 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Relaties hebben gevolgen · Volgende: Gegevens consistent houden

De vraag die deze module beantwoordt: Wie is eigenaar van een record, en wat gebeurt er in zijn leven mee?

Als ik naar een datamodel kijk, wil ik niet alleen weten wat de objecten zijn en hoe ze verbonden zijn. Ik wil weten wat er in de loop van de tijd met de records gebeurt. Wie maakt ze aan? Wie is eigenaar? Wie kan ze opnieuw toewijzen? Wat gebeurt er als de zakelijke relatie verandert, als ze niet meer actief zijn? Moeten ze ooit verwijderd worden, en hoe lang bewaren we ze? Niets daarvan staat op een ERD, het entiteit-relatiediagram: de vakken en lijnen van het datamodel uit hoofdstuk 2. Het is allemaal data-architectuur. En op Salesforce is eigenaarschap waar het datamodel en het beveiligingsmodel elkaar tegenkomen.

Eigenaarschap is meer dan een naam in een veld

Admins zien Owner op een record en lezen het als een naamplaatje: Bart is eigenaar van deze account, Lisa van die case. Zo kan het bedoeld zijn. Maar op Salesforce is eigenaarschap ook een platformmechanisme. Op objecten met een eigenaar bepaalt de eigenaar wie het record kan zien, via de rolhiërarchie, deelregels, wachtrijen en opnieuw toewijzen. Dus als ik vraag “wie is eigenaar van dit record?”, vraag ik niet wiens naam op de pagina staat. Ik vraag welk beveiligings- en levenscyclusgedrag we eraan vastmaken. De eigenaar kan een gebruiker zijn, of voor sommige objecten, waaronder aangepaste objecten, cases en leads, een wachtrij (queue), en hoe dan ook krijgt de eigenaar volledige toegang tot het record (Understanding Sharing (opens in a new tab), Engels).

Daarom scheid ik zakelijke verantwoordelijkheid van recordeigenaarschap. Soms is het dezelfde persoon, soms niet. Als de business zegt dat een planner verantwoordelijk is voor een levering, maakt dat de planner niet automatisch eigenaar. Verantwoordelijkheid kan in een eigen veld staan, terwijl eigenaarschap is ingericht om beveiliging en schaal te ondersteunen. Laat die twee niet door elkaar lopen alleen omdat ze allebei het woord “eigenaar” gebruiken.

De sharetabel: waar eigenaarschap toegang wordt

Sommige mensen weten niet eens wat de sharetabel is. Elke data-architect zou het moeten weten.

Het grootste deel van de sharing van een record staat in een gerelateerd share-object, de Salesforce-versie van een access control list (Understanding Sharing (opens in a new tab), Engels). Account heeft AccountShare, Contact heeft ContactShare, en een aangepast object krijgt zijn eigen: Truck__c heeft Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Elke rij erin zegt vier dingen:

• Welk record: de parent-ID.
• Wie: een gebruiker, of een groep (een openbare groep, de groep van een rol, een gebied).
• Hoeveel: Read, Edit of All (volledige toegang).
• Waarom: de row cause (rijoorzaak). Owner voor de eigenaar, Rule voor een deelregel, Manual voor handmatig delen, Team, de impliciete oorzaken die Salesforce toevoegt tussen een account en zijn children, en redenen die een developer definieert voor Apex-sharing.

In de klas open ik Workbench en bevraag ik de sharetabel terwijl ik een record deel, en je ziet de rijen verschijnen en verdwijnen. Als iemand vraagt “waarom kan deze persoon dat zien?”, staat het antwoord vaak in een rij, met de reden erbij.

Maar niet alles staat erin. De organisatiebrede standaard is geen rij. De rolhiërarchie staat er ook niet in: toegang voor de mensen boven de eigenaar wordt uitgerekend wanneer die nodig is. En View All, Modify All, View All Data en Modify All Data slaan de sharetabel helemaal over (Sharing a Record Using Apex (opens in a new tab), Engels). Zoals ik het in de klas zeg: vink View All aan en je hebt de sharetabel omzeild.

Salesforce deelt ook sommige records voor je, vanwege hoe ze gerelateerd zijn. Dat is impliciete sharing (implicit sharing), en die werkt tussen een account en zijn children. Als je een contactpersoon, case of verkoopkans kunt zien, kun je ook het account lezen waar die bij hoort. En de accounteigenaar krijgt toegang tot de contactpersonen, cases en verkoopkansen van het account, op een niveau dat de rol van de eigenaar bepaalt (Implicit Sharing (opens in a new tab), Engels). In recente releases rekent Salesforce een deel van die childtoegang uit wanneer die nodig is, in plaats van hem als rijen op te slaan, dus wees niet verbaasd als een query op de sharetabel hem niet toont. Ik geef je hier alleen een hint; de details staan in Relaties en ingebouwde sharing.

Nog één uitzondering, voor als je veel externe gebruikers hebt. High-volume community users, de Customer Community-licenties die gebouwd zijn voor duizenden tot miljoenen klanten, hebben geen rol, kunnen niet in openbare groepen zitten, en kunnen geen records krijgen via deelregels of handmatig delen (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), Engels). Voor hen is de sharetabel niet het antwoord: zij komen bij records via sharing sets, die het account of de contactpersoon van een record matchen met die van de gebruiker zelf. Het is een van de redenen dat die licenties schalen. De cursus Sharing and Visibility behandelt het in Delen met externe gebruikers.

En onthoud module 7: een detailobject heeft helemaal geen share-object. Zijn toegang komt van het share-object van de master en de Sharing Setting op het master-detailveld.

Waarom maakt een data-architect zich hier druk om? Omdat eigenaarschap in deze tabel geschreven wordt. Elke eigenaarswissel, elke nieuwe deelregel, elke gebruiker die van rol of groep wisselt, betekent dat Salesforce rijen toevoegt en verwijdert. Bij een paar duizend records merkt niemand het. Bij tien miljoen, met één gebruiker die de meeste ervan bezit, is dat de herberekening die we zo meteen tegenkomen.

Examenkennis. Het share-object van een aangepast object heet Object__Share, zoals Truck__Share. Een detailobject heeft geen share-object: zijn toegang komt van de master. En als de eigenaar van een record verandert, worden de handmatige shares verwijderd, terwijl Apex-sharing met een eigen reden van een developer blijft.

Hier geeft het datamodel het stokje door aan het beveiligingsmodel, en de rest leer ik in de cursus Sharing and Visibility Architect: Steves 22 manieren om een record te delen, Standaardinstellingen voor de hele org, eigenaarschap, wachtrijen en de rolhiërarchie, Relaties en ingebouwde sharing voor de impliciete shares, en Programmatisch delen en veilige code voor de redenen van Apex-sharing. In deze cursus brengt hoofdstuk 12 het samen voor mensen, applicaties en agents.

Soms wordt eigenaarschap geërfd

In de vorige module zagen we dat een master-detail-child geen eigen eigenaar heeft; het volgt de parent. Dat is vaak precies goed. Wil de business een andere eigenaar voor elk item op een levering? Nee. De levering is eigenaar van de levenscyclus, en de items horen erbij. Daarom gebeuren relatieontwerp en eigenaarschapsontwerp samen: als je master-detail kiest, heb je al een deel van de eigenaarschapsbeslissing genomen.

Wie is eigenaar van records die systemen maken?

Nu wordt het interessant. Een persoon maakt een account aan, en wordt misschien de eigenaar. Maar het ERP stuurt ‘s nachts 100.000 transacties. Wie is daar eigenaar van? De integratiegebruiker? Een wachtrij? Een regionale eigenaar die uit de data wordt berekend? Een systeemaccount waar al vijf jaar niemand aan gedacht heeft? En nu maken agents ook records aan.

Mijn standpunt: het hangt ervan af of eigenaarschap de sharing beïnvloedt. Een integratiegebruiker, of een agentgebruiker, is een geldige gebruiker en kan records bezitten. Als eigenaarschap in dat object de toegang stuurt (via de rolhiërarchie of deelregels), wijs de records dan toe aan de juiste eigenaar: een echte gebruiker, een wachtrij of een speciale eigenaargebruiker. Zo niet, dan kan de systeemgebruiker als eigenaar laten staan de betere keuze zijn, omdat de audittrail dan rechtstreeks terugwijst naar wat het record maakte.

Hoe dan ook: beslis het bewust. Een integratieaccount dat eigenaar is van alles, is stilletjes deel geworden van je beveiligingsarchitectuur, en iemand moet weten wat er gebeurt als het gedeactiveerd wordt.

Eigenaarschap kan een schaalprobleem worden

De verdeling doet er ook toe. Tien miljoen records verdeeld over duizenden eigenaren is één vorm. Tien miljoen records van één gebruiker is een heel andere. Salesforce noemt dit ownership data skew: als één gebruiker eigenaar is van meer dan 10.000 records van een object (Ownership Data Skew (opens in a new tab), Engels). Het gebeurt meestal als iemand alles bij één gebruiker of wachtrij parkeert: alle niet-toegewezen leads bij een plaatshoudergebruiker, elk integratierecord bij de integratiegebruiker. Het is onschuldig tot die gebruiker in de rolhiërarchie verschuift, of een groep in- of uitgaat waar deelregels van afhangen. Dan moet Salesforce enorme aantallen sharingregels bijwerken, en krijg je lange herberekeningen.

De richtlijn is praktisch. Verdeel eigenaarschap waar mogelijk over meer gebruikers. Als één gebruiker eigenaar van veel records moet zijn, houd die dan buiten de rolhiërarchie. Moet die een rol hebben, zet die dan in een eigen rol bovenaan en verplaats die niet. En houd die buiten de openbare groepen die deelregels gebruiken (Ownership Data Skew (opens in a new tab), Engels). Hetzelfde denken geldt voor de parent met te veel children uit de vorige module, parent-child skew.

De verdeling is dus deel van het fysieke model. Vraag niet alleen hoeveel records er zijn; vraag hoe ze verdeeld zijn. Het is een andere kant van het aantal nullen: niet alleen hoeveel nullen, maar waar de nullen zich opstapelen. Deel 2 gaat diep in op skew; hier wil ik dat je het ziet aankomen. De cursus Sharing and Visibility pakt het weer op in Sharing op schaal.

De “standaardeigenaar” wordt architectuur

Dit patroon zie ik steeds. Niemand weet wie eigenaar van iets moet zijn, dus zegt iemand: “Wijs het allemaal maar toe aan de integratiegebruiker” of “Maak een algemene gebruiker System aan.” Misschien klopt dat. Maar doe het niet per ongeluk. Tijdelijke standaarden hebben de gewoonte permanent te worden: twee jaar later is elk record van integration@company.com, weet niemand meer waarom, en is het veranderen een project. Dat is de omkeerbaarheidstest uit hoofdstuk 1: voordat je een miljoen records aan één eigenaar geeft, vraag wat het kost om dat later te veranderen.

Opnieuw toewijzen is een gebeurtenis in de levenscyclus

Eigenaren veranderen. Verkopers vertrekken, gebieden verschuiven, teams worden gereorganiseerd, regio’s opnieuw verdeeld. Wat hangt er van de eigenaar af: sharing, automatisering, rapporten, wachtrijen, escalaties, integraties? Als een eigenaarswissel verandert wie een record kan zien, is opnieuw toewijzen geen opruimklusje voor de admin. Het is een beveiligingsgebeurtenis, en bij een miljoen records ook een operationele. Let op de sharetabel als het gebeurt: handmatige shares worden verwijderd als de eigenaar verandert, terwijl Apex-sharing met een eigen reden van een developer de wissel overleeft (Understanding Sharing (opens in a new tab), Engels). In de klas deel ik een record met iemand, verander ik de eigenaar, en verliest die persoon de toegang. De zaal is altijd verrast.

En onthoud dat eigenaarschap niet hetzelfde is als toegang. De eigenaar is niet de enige die een record moet zien, en Salesforce heeft veel manieren om toegang te geven: de rolhiërarchie, deelregels, teams, gebieden, handmatige en programmatische sharing. De cursus Sharing and Visibility gaat daar diep op in, te beginnen met Steves 22 manieren om een record te delen. Het punt voor de architect is eenvoudiger: los niet elk toegangsprobleem op met eigenaarschap. Als je eigenaren heen en weer schuift alleen zodat iemand een record kan zien, los je waarschijnlijk het verkeerde probleem op.

Aanmaken is pas het begin

Veel datamodellering stopt bij het aanmaken: velden, objecten, relaties, klaar. Maar een record kan tien jaar leven. Het wordt bijgewerkt, wisselt van eigenaar, verandert van status en relaties, wordt inactief, wordt historie, moet misschien gearchiveerd worden en wordt ooit misschien verwijderd. Architectuur gaat niet alleen over hoe een record geboren wordt, maar over wat er gebeurt van geboorte tot dood.

Click to enlarge

Verwijder niet alleen omdat iets oud is

Een retailpartner stopt met het sturen van werk. De account verwijderen? Niet automatisch: zijn leveringen, claims en factuurhistorie doen er nog toe. Een vrachtwagen wordt buiten dienst gesteld. Hem verwijderen, samen met zijn leveringshistorie en schadeclaims? Het ding is misschien niet meer actief, maar zijn data wel. Daarom scheid ik inactief van weg. Een buiten dienst gestelde vrachtwagen kan in het model blijven. Een oud-medewerker kan in de audithistorie blijven verschijnen. De architectuur moet de feiten die ertoe doen bewaren nadat de operationele relatie is geëindigd.

Bewaren is een bedrijfseis

Aan de andere kant: alles voor altijd bewaren is ook geen architectuur. De opslag groeit, rapporten worden trager, zoeken wordt rommeliger, en privacywetten kunnen zeggen dat sommige data weg moet. Dus wil ik een duidelijk antwoord op hoe lang bewaren we dit? “Salesforce bewaart het wel” is geen bewaarbeleid.

En meestal is dit een vraag over transactiegegevens. Referentiegegevens, de producten, de servicetypes, de distributiecentra, worden niet enorm, en andere records verwijzen ernaar, dus die blijven meestal. Klantgegevens zitten ertussenin: er kan een dag komen dat je een klant uitfaseert, vooral als je persoonsgegevens bewaart en de reden om ze te bewaren vervalt. Maar het volume zit in de transacties: de leveringen, de orders, de cases, de afspraken, elke dag aangemaakt, voor altijd. Dat groeit uit tot honderden miljoenen rijen, en daar moet het bewaren expliciet zijn: misschien twee jaar operationele data in de org, zeven jaar financiële documenten ergens anders, negentig dagen voor sommige foto’s. Dat zijn bedrijfsregels, en als nog niemand ernaar vroeg, moet de architect het doen.

Ik zeg het al jaren in de klas: als je vandaag niet archiveert, ga je dan ooit archiveren? “Dat regelen we later wel” heeft de gewoonte een spoedproject te worden bij driehonderd miljoen records. Deel 2 heeft een hele module over archiveren en opschonen, gebouwd op dezelfde vraag.

Steve Trucking: wie is eigenaar van een levering?

Leveringen worden aangemaakt uit de vrachtlijsten van retailpartners, door de integratie, ongeveer 3.300 per dag. Wie is eigenaar? Niet de retailpartner; dat is een zakelijke relatie. Niet de ontvanger. De ploeg voert ze uit, maar moet het record van eigenaar wisselen elke keer dat ploegen van vrachtwagen wisselen? De planner? Het distributiecentrum? Een wachtrij? De integratiegebruiker die het aanmaakte?

Pas deze module nu toe, te beginnen met de vraag die het beslist: stuurt eigenaarschap iemands toegang tot leveringen? Bij Steve Trucking niet. Planners zien de leveringen van hun distributiecentrum, ploegen zien die op hun routes, en elke retailer ziet de zijne in het partnerportaal. Niets daarvan hangt af van wie eigenaar is van het record; het komt van het distributiecentrum, de route en de partner.

Dus mijn antwoord: de integratiegebruiker is eigenaar van de leveringen. Het is een goed voorbeeld van een systeemgebruiker die bewust records bezit:

• Het audittrail is eerlijk. De eigenaar van elke levering zegt waar die vandaan kwam: de vrachtlijstintegratie.
• Toegang komt van sharing, niet van eigenaarschap. Deelregels op basis van criteria op het distributiecentrum geven het team van elk DC zijn leveringen; partners bereiken de hunne via het portaal.
• Skew is weg-ontworpen. Bij 3.300 per dag gaat de integratiegebruiker binnen drie dagen over de 10.000 leveringen, dus het is eigenaarschapsskew vanaf dag één, en dat is prima als we erop plannen. De integratiegebruiker heeft geen rol, dus niets boven hem in een hiërarchie hoeft opnieuw berekend te worden, en hij blijft buiten de openbare groepen die onze deelregels gebruiken.
• Niemand wijst leveringen opnieuw toe. Ploegen wisselen van vrachtwagen en planners wisselen van dienst, en de eigenaar verandert nooit, dus er is geen storm van hertoewijzingen en er zijn geen handmatige shares om te verliezen.

En schrijf op wat er gebeurt als die gebruiker ooit gedeactiveerd of vervangen wordt, want hij is nu eigenaar van miljoenen records. Dat is de beslissing die het volgende team zal moeten vinden.

Voorbij het examen: wat AI verandert. Agents maken en wijzigen records op machinesnelheid. Als een agent 100.000 records onder zijn eigen gebruiker maakt, wordt “het eigenaarschap regelen we later wel” skew, sharingherberekeningen en een opruimproject. Beslis de eigenaarschapsregels van een agent voordat die live gaat, met dezelfde vraag: beïnvloedt eigenaarschap hier de sharing?

Wat een architect hier beslist

• Of eigenaarschap zakelijke verantwoordelijkheid vertegenwoordigt, een beveiligingsmechanisme, of beide, en waar verantwoordelijkheid staat als het niet in Owner staat.
• Of een record een eigen eigenaar nodig heeft, of het van een parent moet erven.
• Wie eigenaar is van records die integraties en agents maken, afhankelijk van of eigenaarschap de sharing stuurt.
• Hoe eigenaarschap verdeeld is, en hoe ownership skew vermeden wordt als één gebruiker eigenaar van veel records moet zijn.
• Wanneer records inactief worden, wanneer ze gearchiveerd worden, hoe lang ze bewaard worden, en wanneer verwijderen juist is.

Als je naar een fysiek model kijkt, vraag dan niet alleen waar de data staat. Vraag wie er vandaag eigenaar van is, wie er morgen eigenaar van kan zijn, en wat er gebeurt als we het niet meer nodig hebben. Hierna: zelfs met de juiste objecten, velden, relaties en eigenaren moet de data nog steeds betrouwbaar blijven.

Verder lezen

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): eigenaren (een gebruiker, of een wachtrij voor aangepaste objecten, cases en leads) krijgen volledige toegang; de meeste sharing staat in een gerelateerd sharingobject; de rolhiërarchie wordt tijdens runtime afgeleid; handmatige shares worden verwijderd als de eigenaar verandert, Apex managed sharing blijft; de waarden van row cause.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): AccountShare, MyCustomObject__Share; detailobjecten hebben geen sharingobject; wat het share-object niet bijhoudt (OWD, rolhiërarchie, View All en Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): toegang tussen een account en zijn contactpersonen, cases en verkoopkansen.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) en Sharing Rule Considerations (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): geen rollen, geen deelregels of handmatige shares; in plaats daarvan sharing sets.
• Cursus Sharing and Visibility Architect: Steves 22 manieren om een record te delen, Standaardinstellingen voor de hele org, eigenaarschap, wachtrijen en de rolhiërarchie, Relaties en ingebouwde sharing, Programmatisch delen en veilige code, Delen met externe gebruikers, Sharing op schaal.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) en Parent-Child Data Skew (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)