Het Salesforce-model voor delen is een essentieel element in het vermogen van uw organisatie om veilige toegang tot toepassingsgegevens te bieden. Daarom is het van cruciaal belang om uw sharemodel correct te ontwerpen om te voldoen aan uw huidige en toekomstige vereisten voor gegevenstoegang. In dit document bekijken we componenten voor gegevenstoegankelijkheid, gebruikscases van het model voor delen en oplossingen voor delen met echte klanten, en geven we enkele richtlijnen voor probleemoplossing.

Dit document is bedoeld voor geavanceerde systeembeheerders en architecten. Als u de concepten wilt begrijpen, moet u Knowledge hebben van het beveiligings- en deelmodel van Salesforce. Randvoorwaarden voor deze handleiding zijn:

• Salesforce Help: Instellingen voor delen
• Trailhead Module: Gegevensbeveiliging
• Recordtoegang ontwerpen voor Enterprise Scale
• Goed ontworpen Salesforce - veilig

Deze handleiding richt zich op de belangrijkste voorzieningen die worden gebruikt om toegang op recordniveau tot standaard- en aangepaste objecten te bepalen. Onderwerpen die niet in deze handleiding worden behandeld, zijn:

• Maptoegang
• Inhoudstoegang
• Chatter toegang
• Knowledge Base-toegang
• Ideeën, toegang tot Vragen/antwoorden
• Mobiele gegevenstoegankelijkheid

Met beveiliging op recordniveau kunt u gebruikers wel toegang geven tot bepaalde objectrecords, maar niet tot andere. Zoals bij de meeste toepassingen begint gegevenstoegang bij een gebruiker. De toepassing moet weten wie de gebruiker is voordat deze toegang verleent. Voor Salesforce zijn er verschillende typen gebruikers en soms verschilt het toegangsniveau per type. In plaats van elk kenmerk van elk licentietype te beoordelen, richten we ons hier op de interessante kenmerken die een aanzienlijke invloed hebben op gegevenstoegang. Recordeigendom en volledige toegang zijn synoniem en uitwisselbaar en bieden de gebruiker het hoogste niveau van toegang tot een record.

Gebruikers met groot volume

Gebruikers met groot volume (inclusief gebruikers met de licentietypen Customer Community, Klantportal met groot volume en Geauthenticeerde website) gebruiken het sharemodel niet, omdat hun licentietypen geen rollen ondersteunen. Deze licenties hebben hun eigen sharemodel dat werkt op basis van overeenkomsten met externe sleutels tussen de gebruiker (die de licentie vasthoudt) en de gegevens in opzoekopdrachten voor Account en Contactpersoon. Beheerders kunnen sets voor delen of groepen voor delen maken om gebruikers met groot volume toegang tot records te verlenen.

Chatter Free- en Chatter External-licenties

De Chatter Free- en Chatter External-licenties volgen niet het standaardmodel voor delen. Deze licenties hebben geen toegang tot CRM-records (standaard- of aangepaste objecten) en Content-functionaliteit, en ondersteunen geen rollen. Daarom is er geen sprake van delen.

Voor de rest van dit document gaan we uit van een Salesforce-gebruikerstype dat een volledig sharemodel gebruikt. Zie Gebruikerslicenties voor meer informatie over elk beschikbaar licentietype.

Profielen en machtigingensets

Profielen en machtigingensets bieden beveiliging op objectniveau door te bepalen welke typen gegevens gebruikers zien en of ze records kunnen bewerken, maken of verwijderen. Voor elk object negeren de machtigingen "Alles weergeven" en "Alles wijzigen" regels en instellingen voor delen, waardoor beheerders snel toegang kunnen verlenen tot records die zijn gekoppeld aan een bepaald object in de hele organisatie. Deze machtigingen zijn vaak een beter alternatief voor de beheermachtigingen "Alle gegevens weergeven" en "Alle gegevens wijzigen", waarmee gebruikers alle apps en gegevens kunnen weergeven of wijzigen.

Profielen en machtigingensets bepalen ook beveiliging op veldniveau, die bepaalt tot welke velden binnen elk object gebruikers toegang hebben. Een object kan bijvoorbeeld 20 velden hebben, maar beveiliging op veldniveau kan worden ingesteld om te voorkomen dat gebruikers vijf van de 20 velden zien.

U wordt dringend aangeraden om machtigingensets en groepen machtigingensets te gebruiken in plaats van profielen om de objectmachtigingen van uw gebruikers te beheren. Omdat u kleinere bouwstenen voor machtigingensets opnieuw kunt gebruiken, kunt u voorkomen dat u tientallen of zelfs honderden profielen maakt voor elke gebruiker en functie.

Recordeigendom en wachtrijen

Elke record moet eigendom zijn van één gebruiker of een wachtrij. De eigenaar heeft toegang tot de record op basis van de objectinstellingen voor het profiel van de eigenaar. Als het profiel van de eigenaar bijvoorbeeld de machtiging Maken en Lezen voor een object heeft, maar niet de machtiging Bewerken of Verwijderen, kan de eigenaar een record voor het object maken en de nieuwe record zien. De eigenaar kan de record echter niet bewerken of verwijderen. Gebruikers hoger in een hiërarchie (rol of territorium) nemen dezelfde gegevenstoegang over als hun ondergeschikten voor standaardobjecten. Als de ondergeschikte alleen-lezen toegang heeft, hebben de gebruikers boven hen in de rollenhiërarchie dat ook. Deze toegang geldt zowel voor records die eigendom zijn van gebruikers als voor records die met hen worden gedeeld.

Wachtrijen helpen bij het prioriteren, distribueren en toewijzen van records aan teams die werk delen. Wachtrijleden en gebruikers hoger in de rollenhiërarchie hebben toegang tot wachtrijen vanuit lijstweergaven en kunnen eigendom krijgen van records in een wachtrij.

Als één gebruiker eigenaar is van meer dan 10.000 records, kunt u het volgende doen:

• De gebruikersrecord van de eigenaar mag geen rol in de rollenhiërarchie hebben.

• Als de gebruikersrecord van de eigenaar een rol moet bevatten, plaatst u de rol boven aan de hiërarchie in een eigen vertakking van de rollenhiërarchie.

Zie Salesforce goed ontworpen - betrouwbaar voor meer informatie.

Standaardinstellingen voor de hele organisatie

Instellingen voor delen voor de hele organisatie bepalen het standaardtoegangsniveau dat gebruikers hebben tot elkaars records. U gebruikt instellingen voor delen voor de hele organisatie om uw gegevens te vergrendelen tot het meest beperkende niveau. Gebruik de andere tools voor beveiliging en delen op recordniveau om selectief toegang te verlenen aan andere gebruikers. Gebruikers hebben bijvoorbeeld machtigingen op objectniveau voor het lezen en bewerken van opportunities en de instelling voor delen voor de hele organisatie is Alleen-lezen. Standaard kunnen die gebruikers alle opportunityrecords lezen, maar kunnen ze er geen bewerken, tenzij ze eigenaar zijn van de record of andere machtigingen hebben.

Standaardinstellingen voor de hele organisatie kunnen worden gewijzigd van de ene instelling in de andere (Privé in Beheerd door bovenliggend niveau en vervolgens terug naar Privé). Deze wijzigingen vereisen echter een nieuwe berekening voor delen en kunnen, afhankelijk van het volume, leiden tot lange verwerkingstijden.

Alleen voor aangepaste objecten kunt u de instelling Toegang verlenen met behulp van hiërarchieën configureren. Indien uitgeschakeld (standaard is ingeschakeld), wordt voorkomen dat gebruikers hoger in de rollenhiërarchie toegang overnemen. Deze instelling vindt u in de standaardinstellingen voor de hele organisatie.

Rollenhiërarchie

Een rollenhiërarchie vertegenwoordigt een niveau van gegevenstoegang dat een gebruiker of groep gebruikers nodig heeft. De rollenhiërarchie zorgt ervoor dat managers altijd toegang hebben tot dezelfde gegevens als hun werknemers, ongeacht de standaardinstellingen voor de hele organisatie. Rollenhiërarchieën hoeven niet exact overeen te komen met uw organisatiediagram. In plaats daarvan moet elke rol in de hiërarchie een niveau van gegevenstoegang vertegenwoordigen dat een gebruiker of groep gebruikers nodig heeft.

In Salesforce-organisaties die zijn gemaakt in Spring '21 of later, kunt u maximaal 5000 rollen maken. In organisaties die zijn gemaakt vóór Spring '21, kunt u maximaal 500 rollen maken en kunt u contact opnemen met de klantenondersteuning van Salesforce om deze limiet te verhogen. Als best practice geldt dat u het aantal interne rollen beperkt tot 25.000 en het aantal externe rollen beperkt tot 100.000.

Als best practice geldt dat u de rollenhiërarchie beperkt tot niet meer dan 10 niveaus van vertakkingen in de hiërarchie.

Wanneer de rol van een gebruiker verandert, worden alle relevante regels voor delen geëvalueerd om indien nodig toegang te corrigeren. Peers met dezelfde rol garanderen niet dat ze toegang hebben tot elkaars gegevens.

Het modelleren van de rollenhiërarchie begint met inzicht in de manier waarop de organisatie is gestructureerd. Dit wordt meestal samengesteld vanuit inzicht in het bereik van een manager, beginnend bij de top. De CEO houdt toezicht op het gehele bedrijf. De CEO heeft doorgaans directe rapporten die vervolgens kunnen worden gesegmenteerd op bedrijfseenheid (Verkoop of Ondersteuning) of geografische regio (EMEA, APAC). Die persoon heeft dan directe rapporten die verder kunnen worden gesegmenteerd, enzovoort. Hoewel dit veel op een HR-organisatiediagram lijkt, moet u bij het modelleren van gegevenstoegang aandacht besteden aan gegevenstoegankelijkheid met inachtneming van HR-rapportage.

Overlays vormen altijd het lastige deel van de hiërarchie. Als ze in hun eigen filiaal werken, hebben ze regels voor delen, teams of territoriumbeheer nodig om de benodigde toegang te krijgen. Als ze zijn samengevouwen in de hiërarchie, kunnen er gevolgen zijn voor de rapportage.

Het is belangrijk om de tijd te besteden aan het instellen van de rollenhiërarchie, omdat dit een van de basisaspecten van het model voor delen is.

Openbare groepen

Een openbare groep is een verzameling afzonderlijke gebruikers, rollen, territoria, enzovoort, die allemaal een functie gemeen hebben. Openbare groepen kunnen bestaan uit:

• Gebruikers
• Klantportalgebruikers
• Partnergebruikers
• Rollen
• Rollen en interne ondergeschikten
• Rollen, interne en portalondergeschikten
• Portalrollen
• Portalrollen en ondergeschikten
• Territoria
• Territoria en ondergeschikten
• Andere openbare groepen (nesten)

Groepen kunnen worden genest (Groep A genest in Groep B), maar nest niet meer dan vijf niveaus. Nesten heeft invloed op het onderhoud en de prestaties van groepen vanwege de berekening van groepslidmaatschappen. Houd als best practice het totale aantal openbare groepen voor een organisatie op 100.000.

Op eigenaar gebaseerde regels voor delen

Regels voor delen op basis van eigenaar staan uitzonderingen toe op standaardinstellingen voor de hele organisatie en de rollenhiërarchie die extra gebruikers toegang geven tot records waarvan ze geen eigenaar zijn. Op eigenaar gebaseerde regels voor delen zijn alleen gebaseerd op de recordeigenaar.

Op eigenaar gebaseerde regels voor delen van contactpersonen zijn niet van toepassing op privécontactpersonen of contactpersonen die niet aan een account zijn gekoppeld.

De limiet van het totale aantal regels voor delen per object is 300.

Op criteria gebaseerde regels voor delen

Op criteria gebaseerde regels voor delen bieden toegang tot records op basis van de veldwaarden (criteria) van de record. Als aan de criteria wordt voldaan (een of meer veldwaarden), wordt er een record voor delen voor de regel gemaakt. Recordeigendom is geen overweging.

De limiet van op criteria gebaseerde regels voor delen en regels voor delen voor gastgebruikers per object is 50.

Regels voor delen voor gastgebruikers

Een regel voor delen voor gastgebruikers is een speciaal type op criteria gebaseerde regel voor delen die wordt gebruikt om recordtoegang te verlenen aan niet-geauthenticeerde gastgebruikers. De limiet van op criteria gebaseerde regels voor delen en regels voor delen voor gastgebruikers per object is 50.

Waarschuwing: Het type regel voor delen voor gastgebruikers verleent toegang aan gastgebruikers zonder inloggegevens. Door een regel voor delen voor gastgebruikers te maken, verleent u iedereen onmiddellijke en onbeperkte toegang tot alle records die voldoen aan de criteria van de regel voor delen. Als u uw Salesforce-gegevens wilt beveiligen en uw gastgebruikers toegang wilt geven tot wat ze nodig hebben, denkt u na over alle gebruikscases en gevolgen van het maken van dit type regel voor delen. Implementeer beveiligingsmaatregelen die u geschikt acht voor de gevoeligheid van uw gegevens. Salesforce is niet verantwoordelijk voor de blootstelling van uw gegevens aan niet-geauthenticeerde gebruikers op basis van deze wijziging van de standaardinstellingen.

Handmatig delen

Soms is het onmogelijk om een consistente groep gebruikers te definiëren die toegang nodig hebben tot een bepaalde set records. Recordeigenaars of andere gebruikers met voldoende machtigingen, zoals systeembeheerders, kunnen handmatig delen gebruiken om machtigingen voor lezen en bewerken te verlenen aan gebruikers die op geen enkele andere manier toegang hebben. Handmatig delen is niet geautomatiseerd, zoals instellingen voor delen voor de hele organisatie, rollenhiërarchieën of regels voor delen. Maar het biedt recordeigenaars de flexibiliteit om records te delen met gebruikers die ze moeten zien.

Handmatig delen wordt verwijderd wanneer de recordeigenaar verandert of wanneer de verleende toegang voor delen geen extra toegang verleent boven het standaardtoegangsniveau voor delen voor de hele organisatie van het object. Dit geldt ook voor handmatige shares die programmatisch worden gemaakt.

Handmatige records voor delen worden gedefinieerd als records voor delen met de rijoorzaak ingesteld op handmatig delen.

Alle records voor delen (standaard- en aangepaste objecten) met een rijoorzaak die is ingesteld op handmatig delen, kunnen worden bewerkt en verwijderd door de knop Delen in de paginalay-out van het object, zelfs als de record voor delen programmatisch is gemaakt.

Teams

Een team is een groep gebruikers die samenwerken aan een account, verkoopopportunity of case. Recordeigenaars kunnen een team samenstellen voor elke record waarvan ze eigenaar zijn. De recordeigenaar voegt teamleden toe en geeft het toegangsniveau op dat elk teamlid heeft voor de record. Sommige teamleden kunnen alleen-lezen toegang hebben, terwijl anderen lezen/schrijven hebben.

Alleen eigenaars, mensen hoger in de hiërarchie en beheerders kunnen teamleden toevoegen en meer toegang tot het lid verlenen. Een teamlid met lees-/schrijftoegang kan een ander lid toevoegen dat al toegang heeft tot de record waaraan het team is gekoppeld. Het teamlid kan hen geen extra toegang verlenen.

Als u een teamlid in de app maakt, worden twee records gemaakt: een teamrecord en een gekoppelde record voor delen. Als u teamleden programmatisch maakt, moet u zowel de teamrecord als de gekoppelde record voor delen beheren. Er is slechts één team per record (Account, Opportunity of Case). Als er meerdere teams nodig zijn, kunt u, afhankelijk van uw specifieke behoeften, territoriumbeheer of programmatisch delen overwegen

Territoriumhiërarchie

Wanneer u Territoriumbeheer voor de onderneming gebruikt, stelt u een territoriumhiërarchie in die de territoriumstructuur van een model toont en als het belangrijkste interactiepunt ervan dient. Als Territoriumbeheer voor de onderneming is ingeschakeld, moet u zowel de rollenhiërarchie als de territoriumhiërarchie beheren. Zie Enterprise Territorium Management in de Salesforce Help voor meer informatie.

Apex beheerd delen

Met door Apex beheerd delen (ook wel programmatisch delen genoemd) kunt u code gebruiken om geavanceerde en dynamische instellingen voor delen samen te stellen wanneer op geen enkele andere manier aan een vereiste voor gegevenstoegang kan worden voldaan.

Als u programmatisch een record voor delen maakt en de kant-en-klare rijoorzaak (handmatig delen) wordt gebruikt, kunt u deze record voor delen onderhouden met de knop Delen in de app. De record voor delen is onderworpen aan alle regels met de handmatige oorzaak van rij voor delen, zoals verwijdering bij overdracht van eigenaar.

U kunt ook uw eigen Apex redenen voor delen maken voor aangepaste objecten om bij te houden waarom een record met een gebruiker of groep gebruikers is en om de codering te vereenvoudigen die vereist is voor het bijwerken en verwijderen van records voor delen.

Raadpleeg voor meer informatie Een record delen met behulp van Apex voordat u programmatisch delen overweegt.

Beperkingsregels

In uw configuratie voor gegevenstoegang wilt u mogelijk voorkomen dat gebruikers records zien die gevoelige gegevens kunnen bevatten of gewoon niet essentieel zijn voor hun werk. U kunt beperkingsregels gebruiken om gebruikers alleen toegang te geven tot records die voldoen aan de criteria die u opgeeft. Wanneer een beperkingsregel wordt toegepast op een gebruiker, worden de records waartoe de gebruiker toegang krijgt via standaardinstellingen voor de hele organisatie, regels voor delen en andere mechanismen voor delen gefilterd op criteria die u opgeeft. Beperkingsregels werken op de tegenovergestelde manier als de componenten voor delen die in dit onderwerp worden besproken; in plaats van de toegang voor gebruikers open te stellen, beperken ze deze verder.

Beperkingsregels zijn beschikbaar voor aangepaste objecten, externe objecten, contracten, events, taken, tijdenregistratiebladen en tijdenregistratiebladen. U kunt maximaal twee actieve beperkingsregels per object maken in de Enterprise en Developer Edition en maximaal vijf actieve beperkingsregels per object in de Performance en Unlimited Edition. Beperkingsregels worden toegepast op de volgende Salesforce-voorzieningen:

• Lijstweergaven
• Opzoekopdrachten
• Gerelateerde lijsten
• Rapporten
• Zoeken
• SOQL
• SOSL

Impliciet delen

Impliciet delen gebeurt automatisch. U kunt het niet uitschakelen of inschakelen—het is eigen aan de toepassing. Met andere woorden, impliciet delen is geen configureerbare instelling; het is echter belangrijk dat elke architect het begrijpt. Impliciet delen via bovenliggend niveau is toegang verlenen tot bovenliggende records (alleen account) wanneer een gebruiker toegang heeft tot onderliggende opportunities, cases of contactpersonen voor die account. Salesforce heeft een gegevenstoegangsbeleid dat bepaalt of een gebruiker een contactpersoon (of opportunity, case of order) kan zien, waarna de gebruiker impliciet de gekoppelde account ziet. Onderliggend impliciet delen is toegang verlenen tot onderliggende records van een account aan de accounteigenaar. Deze toegang wordt gedefinieerd op de rol van de eigenaar in de rollenhiërarchie. Onderliggend impliciet delen is alleen van toepassing op contactpersoons-, opportunity- en caseobjecten (onderliggende objecten van de account). De toegangsniveaus die kunnen worden geboden, zijn Weergeven, Bewerken en Geen toegang voor elk van de onderliggende objecten wanneer de rol wordt gemaakt. Door de instelling Weergeven kan de accounteigenaar impliciet de gekoppelde objectrecords (contactpersoon, opportunity of case) zien. Door de instelling Bewerken kan de accounteigenaar het gekoppelde object (contactpersoon, opportunity of case) impliciet wijzigen.

Impliciet delen is niet van toepassing op aangepaste objecten.

Er is geen model voor delen dat geschikt is voor alle Salesforce-organisaties. Elke organisatie heeft andere vereisten en uitdagingen bij het samenstellen van het beste model voor delen. Het is van cruciaal belang om de meest geschikte componenten voor gegevenstoegang te gebruiken die passen bij de vereisten voor delen van de organisatie. De volgende scenario's zijn veelvoorkomende uitdagingen bij het samenstellen van een model voor delen.

• Wat gebeurt er met de rollenhiërarchie?

  • Er gebeurt niets met de rollenhiërarchie als u ook een territoriumhiërarchie gebruikt. Als u echter zowel op territorium gebaseerde prognoses als op rollen gebaseerde prognoses samen gebruikt, moet u twee hiërarchieën beheren. In dit geval wordt aangeraden om de rollenhiërarchie te gebruiken voor het modelleren van de HR-rapportagestructuur en vervolgens de territoriumhiërarchie te gebruiken voor het modelleren van de feitelijke verkoophiërarchie. De territoriumhiërarchie is het meest geschikt voor het modelleren van een matrixrapportagestructuur, waarin iemand kan rapporteren aan meerdere managers.

    Als u op territorium gebaseerde prognoses en op rollen gebaseerde prognoses niet samen gebruikt, is het mogelijk om alleen de territoriumhiërarchie als verkoophiërarchie te gebruiken. In dit scenario kunt u de hiërarchie het best zo veel mogelijk vereenvoudigen of afvlakken.

    Het wordt afgeraden om de rollenhiërarchie en territoriumhiërarchie identiek te maken, omdat dit onnodige activiteiten voor delen veroorzaakt.

• Kunt u nog steeds teams gebruiken?

  • Ja. Als u echter kunt voldoen aan uw toegangsvereisten binnen de territoriumhiërarchie (zoals overlays), is het beter om dit daar te doen dan teams te gebruiken. U onderhoudt al meerdere hiërarchieën (rol en territorium), dus implementeer alleen teams als geen enkele andere bestaande component voor delen aan de vereiste voldoet.

• Opnieuw uitlijnen en opnieuw toewijzen

  • Er zijn twee typen wijzigingen: het lidmaatschap van rollen, teams of territoria, en de structuur van de hiërarchie. Lidmaatschapswijzigingen kunnen doorgaans dagelijks of zelfs elk uur plaatsvinden. Structurele hiërarchiewijzigingen (heruitlijningen) komen over het algemeen minder vaak voor (kwartaal, halfjaarlijks of jaarlijks) en kunnen duur zijn voor resources. Waar rekening mee moet worden gehouden, is het aantal wijzigingen en het aantal trapsgewijze wijzigingen dat elke wijziging zal veroorzaken. Als vuistregel geldt dat structurele veranderingen niet meer dan driemaandelijks plaatsvinden en dat alle wijzigingen van groot volume (bulk- of bulkwijzigingen) goed worden gepland, getest en gecoördineerd.

• Grote gegevensvolumes

  • Of u nu model staat voor de initiële implementatie of een wijziging van uitlijning plant, u moet goed nadenken over het volume aan gegevens. Er zijn drempelwaarden waarbij prestaties een factor kunnen worden, dus het wordt sterk aanbevolen om uw wijzigingen in een sandbox te testen voordat u gaat produceren. Dit testen geeft u ook een baseline voor hoe lang de wijziging gaat duren.

    Als u meer dan twee miljoen accounts hebt en teams of Territoriumbeheer voor de onderneming hebt geïmplementeerd, moet u vooral op prestaties letten. Dit zijn complexe componenten van het sharemodel die kunnen zorgen voor een enorm volume aan sharerecords en dus langlopende transacties.

• Berekeningen voor delen uitstellen

  • Als u een object hebt dat gebruikmaakt van delen en een groot volume records (zoals meer dan twee miljoen accounts) heeft en u een bulkwijziging moet aanbrengen (zoals een driemaandelijkse uitlijning die een hiërarchiewijziging vereist), is er een voorziening die de klantenondersteuning van Salesforce kan inschakelen om automatische berekeningen voor delen uit te stellen. Elke afzonderlijke wijziging in de rollenhiërarchie, territoriumhiërarchie, groepen, regels voor delen, gebruikersrollen, teamlidmaatschap of eigendom van records kan automatisch berekeningen voor delen starten. Wanneer er een bulkwijziging wordt aangebracht, leidt dit ertoe dat een aantal automatische herberekeningen voor delen worden gestart. Door deze herberekeningen tijdelijk op te schorten, kunt u de wijziging aanbrengen en de berekeningen voor delen vervolgens allemaal tegelijk laten plaatsvinden. Deze methode is doorgaans efficiënter en presteert beter voor bulkwijzigingen.

• Vertekening van gegevens en eigendom

  • Vertekende gegevens worden gedefinieerd als enkele bovenliggende records met veel onderliggende records. Deze scheeftrekkingen kunnen u echt pijn doen wanneer een paar accounts veel contactpersonen, opportunities of cases hebben. De verhouding waar we prestatievermindering zien is 1:10.000. Als best practice geldt dat u de verhouding zo dicht mogelijk bij die verhouding moet houden (lager heeft de voorkeur).

    Vertekeningen in eigendom lijken op vertekeningen in gegevens, met dit verschil dat het gaat om één gebruiker, rol of groep die eigenaar is van vele records voor een object. Net als bij scheefgetrokken gegevens kunnen deze ook langdurige transacties veroorzaken, waardoor de prestaties achteruitgaan wanneer er wijzigingen optreden. De aanbevolen verhouding tussen eigenaar en aantal records is ook 1:10.000.

    Als één gebruiker eigenaar is van meer dan 10.000 records, kunt u het volgende doen:

    • De gebruikersrecord van de eigenaar mag geen rol in de rollenhiërarchie hebben.

    • Als de gebruikersrecord van de eigenaar een rol moet bevatten, plaatst u de rol boven aan de hiërarchie in een eigen vertakking van de rollenhiërarchie.

• Impact van accounthiërarchieën op gegevenstoegang

  • Veel mensen maken een slechte aanname wanneer ze een accounthiërarchie implementeren. Ze gaan ervan uit dat de gebruikers die toegang hebben tot een bovenliggende account, ook toegang hebben tot de onderliggende accounts. Het simpele feit dat er alleen een bovenliggende/onderliggende relatie tussen twee records is, leidt niet tot toegang. Hoewel de rollenhiërarchie en de territoriumhiërarchie op deze manier werken, werkt de accounthiërarchie dat niet.

Zodra u de architectuur van uw model voor delen hebt voltooid, krijgt u waarschijnlijk de vraag waarom een gebruiker een record wel of niet kan zien. Doorgaans hoort u niet wanneer gebruikers iets kunnen zien dat ze niet zouden moeten zien, maar indien nodig is er een manier om elke gebruiker te zien die toegang heeft tot een record en waarom.

De moeilijkere uitdaging, en waarschijnlijk vaker, is waarom een gebruiker een record niet kan zien. De beveiligingslagen die u hebt ontworpen, bepalen waar u begint. Als u het sharemodel goed kent, weet u waarschijnlijk welke component de toegang had moeten bieden en kunt u daar beginnen. Maar als u minder vertrouwd bent met het model voor delen, begint u met de rollenhiërarchie en verwijdert u elke laag om te bepalen welke de toegang moet bieden. Hier is een stroom voor probleemoplossing.

1. Controleer of de gebruiker machtigingen heeft voor toegang tot het object.
2. Identificeer de rol van de gebruiker die de record niet kan zien, en maak er een notitie van.
3. Identificeer de eigenaar van de rol van de record en noteer deze.
4. Controleer de rollenhiërarchie en controleer of deze twee rollen zich in twee verschillende vertakkingen bevinden (dat zouden ze moeten zijn).
5. U moet nu de regels voor delen voor het object controleren en ervoor zorgen dat er geen regel is die de gebruiker toegang verleent. Kijk indien nodig ook in openbare groepen. Misschien is de gebruiker uitgesloten van een groep waarin een regel voor delen bestaat, of is het logisch om een nieuwe regel voor delen te maken om de gebruiker toegang te verlenen? Deze keuze is afhankelijk van de architectuur die u probeert te onderhouden en is van toepassing op zowel op eigenaar gebaseerde regels voor delen als op criteria gebaseerde regels voor delen.
6. Als u teams gebruikt, moet deze gebruiker dan in het team voor die record zitten? Hoe worden teams onderhouden en hoe is de misser ontstaan?
7. Als handmatig delen wordt gebruikt, heeft de gebruiker mogelijk geen toegang meer omdat de recordeigenaar is gewijzigd. Handmatige shares vervallen wanneer eigendom verandert. Het handmatig delen kan ook zijn verwijderd met behulp van de knop Delen.
8. Als u Territoriumbeheer voor de onderneming gebruikt, ontbreekt de gebruiker dan in een van de territoria? Waar wordt het lidmaatschap van territoria gehandhaafd en hoe heeft de misser plaatsgevonden? Of misschien is de record niet toegewezen aan het territorium waarvan de gebruiker lid is.
9. Als u programmatische shares maakt en er criteria zijn voor het maken van de share in code, controleert u de code om te begrijpen waarom deze gebruiker is weggelaten.