Salesforce-delingsmodellen er et vigtigt element i din organisations mulighed for at give sikker applikationsdataadgang. Derfor er det vigtigt at arkitektere din delingsmodel korrekt for at opfylde dine aktuelle og fremtidige dataadgangskrav. I dette dokument gennemser vi datatilgængelighedskomponenter, delingsmodelanvendelsessituationer og virkelige kundedelingsløsninger, og vi leverer nogle fejlfindingsretningslinjer.

Dette dokument er beregnet til avancerede systemadministratorer og arkitekter. For at forstå begreberne skal du have en praktisk Knowledge af Salesforce-sikkerheds- og delingsmodellen. Forudsætninger for denne vejledning er:

• Hjælp til Salesforce: Delingsindstillinger
• Trailhead Module: Datasikkerhed
• Design af registreringsadgang til virksomhedsskala
• Salesforce veludviklet - sikkert

Denne vejledning fokuserer på de vigtigste funktioner, der bruges til at kontrollere adgang på registreringsniveau til standardobjekter og tilpassede objekter. Emner, der ikke er dækket i denne vejledning, omfatter:

• Mappeadgang
• Indholdsadgang
• Chatter adgang
• Adgang til Knowledge Base
• Adgangen Ideer, Spørgsmål/svar
• Tilgængelighed af mobildata

Sikkerhed på registreringsniveau giver dig mulighed for at give brugere adgang til nogle objektregistreringer, men ikke andre. Som med de fleste applikationer begynder dataadgang med en bruger. Applikationen skal vide, hvem brugeren er, før den giver adgang. For Salesforce er der forskellige typer af brugere, og nogle gange er adgangsniveauet forskelligt efter type. I stedet for at gennemse hver attribut for hver licenstype, vil vi fokusere her på de interessante attributter, der har væsentlig indflydelse på dataadgang. Registreringsejerskab og fuld adgang er synonymer og kan udskiftes og giver brugeren det højeste niveau af adgang til en registrering.

Højvolumen brugere

Højvolumen brugere (herunder brugere med licenstyperne Customer Community, High Volume Customer Portal og Authenticated Website) bruger ikke delingsmodellen, da deres licenstyper ikke understøtter roller. Disse licenser har deres egen delingsmodel, der fungerer efter fremmed nøgle-match mellem brugeren (der har licensen) og dataene på opslagene Konto og Kontakt. Administratorer kan oprette delingssæt eller delingsgrupper for at tildele højvolumen brugere adgang til registreringer.

Chatter Free og Chatter External-licenser

Licenserne Chatter Free og Chatter External følger ikke standarddelingsmodellen. Disse licenser har ikke adgang til CRM-registreringer (standardobjekter eller tilpassede objekter) og indholdsfunktionalitet og understøtter ikke roller, derfor er der ingen deling.

For resten af dette dokument antager vi, at en Salesforce-brugertype bruger en fuld delingsmodel. Se brugerlicenser for at få flere oplysninger om hver tilgængelig licenstype.

Profile og tilladelsessæt

Profiler og tilladelsessæt giver sikkerhed på objektniveau ved at bestemme, hvilke typer af data brugere ser, og om de kan redigere, oprette eller slette registreringer. For hvert objekt ignorerer tilladelserne "Vis alle" og "Rediger alle" delingsregler og indstillinger, så administratorer hurtigt kan tildele adgang til registreringer, der er tilknyttet et givent objekt i hele organisationen. Disse tilladelser er ofte foretrukne alternativer til de administrative tilladelser "Vis alle data" og "Rediger alle data", der tillader brugere at se eller redigere alle apps og data.

Profiler og tilladelsessæt styrer også sikkerhed på feltniveau, hvilket bestemmer felterne i hvert objekt, som brugere kan få adgang til. Et objekt kan f.eks. have 20 felter, men sikkerhed på feltniveau kan opsættes til at forhindre brugerne i at se fem af de 20 felter.

Vi anbefaler på det kraftigste, at du bruger tilladelsessæt og tilladelsessætgrupper i stedet for profiler til at administrere dine brugeres objekttilladelser. Da du kan genbruge mindre tilladelsessætbygningsblokke, kan du undgå at oprette dusinvis eller endda hundredvis af profiler for hver bruger og jobfunktion.

Registreringsejerskab og køer

Hver registrering skal ejes af en enkelt bruger eller en kø. Ejeren har adgang til registreringen baseret på objektindstillingerne for ejerens profil. Hvis f.eks. ejerens profil har tilladelserne Opret og Læs på et objekt, men ikke tilladelsen Rediger eller Slet, kan ejeren oprette en registrering for objektet og se den nye registrering. Men ejeren vil ikke kunne redigere eller slette registreringen. Brugere, der er højere i et hierarki (rolle eller område), overtager den samme dataadgang som deres underordnede for standardobjekter. Hvis den underordnede har skrivebeskyttet adgang, vil brugerne over dem også have det samme i rollehierarkiet. Denne adgang gælder for registreringer, der ejes af brugere, samt registreringer, der deles med dem.

Køer hjælper dig med at prioritere, distribuere og tildele registreringer til teams, der deler arbejdsbelastninger. Kømedlemmer og brugere, der er højere i rollehierarkiet, kan få adgang til køer fra listevisninger og tage ejerskab over registreringer i en kø.

Hvis en enkelt bruger ejer mere end 10.000 registreringer, som en bedste fremgangsmåde:

• Brugerregistreringen for ejeren bør ikke indeholde en rolle i rollehierarkiet.

• Hvis ejerens brugerregistrering skal indeholde en rolle, skal du placere rollen øverst i hierarkiet i sin egen forgrening af rollehierarkiet.

Se Se Salesforce Well-Architected - Reliable for at få flere oplysninger.

Standarder for hele organisationen

Delingsindstillinger for hele organisationen angiver det standardadgangsniveau, som brugere har til hinandens registreringer. Du bruger delingsindstillinger for hele organisationen til at låse dine data på det mest restriktive niveau. Brug de andre sikkerheds- og delingsværktøjer på registreringsniveau til selektivt at give adgang til andre brugere. F.eks. har brugere tilladelser på objektniveau til at læse og redigere salgsmuligheder, og delingsindstillingen for hele organisationen er Skrivebeskyttet. Disse brugere kan som standard læse alle salgsmulighedsregistreringer, men kan ikke redigere nogen, medmindre de ejer registreringen eller har fået tildelt andre tilladelser.

Standardindstillinger for hele organisationen kan ændres fra en indstilling til en anden (Privat til Kontrolleret af overordnet og derefter tilbage til Privat). Men disse ændringer kræver genberegning af deling, og afhængigt af mængden kan det resultere i lange behandlingstider.

Kun for tilpassede objekter kan du konfigurere indstillingen Tildel adgang vha. hierarkier. Hvis det ikke markeres (standard er markeret), forhindres brugere, der er højere i rollehierarkiet, i at overtage adgang. Denne indstilling findes i standardindstillingerne for hele organisationen.

Rollehierarki

Et rollehierarki repræsenterer et niveau af dataadgang, som en bruger eller en gruppe af brugere har brug for. Rollehierarkiet sikrer, at managers altid har adgang til de samme data som deres medarbejdere, uanset standardindstillingerne for hele organisationen. Rollehierarkier behøver ikke matche dit organisationsdiagram nøjagtigt. I stedet skal hver rolle i hierarkiet repræsentere et niveau af dataadgang, som en bruger eller en gruppe af brugere har brug for.

I Salesforce-organisationer, der er oprettet i Spring '21 eller senere, kan du oprette op til 5.000 roller. I organisationer, der er oprettet før Spring ’21, kan du oprette op til 500 roller og kan kontakte Salesforce Kundesupport for at øge denne grænse. Som en bedste fremgangsmåde skal du holde antallet af interne roller til 25.000 og antallet af eksterne roller til 100.000.

Som en bedste fremgangsmåde skal du holde rollehierarkiet på højst 10 niveauer af forgreninger i hierarkiet.

Når en brugers rolle ændres, evalueres eventuelle relevante delingsregler for at rette adgang efter behov. Ligestillede i samme rolle garanterer ikke dem adgang til hinandens data.

Modelering af rollehierarkiet begynder med at forstå, hvordan organisationen er struktureret. Dette opbygges sædvanligvis fra forståelse af en managers omfang, startende fra toppen. Direktøren overvåger hele firmaet. CEO'en har sædvanligvis direkte rapporter, der derefter kan segmenteres efter forretningsenhed (salg eller support) eller geografisk område (EMEA, APAC). Denne person har derefter direkte rapporter, der kan segmenteres yderligere osv. Selvom dette lyder meget som et HR-organisationsdiagram, skal du, når du modellerer dataadgang, fokusere på datatilgængelighed med hensyn til HR-rapportering.

Overlejringer er altid den tricky del af hierarkiet. Hvis de er i deres egen afdeling, kræver de enten delingsregler, teams eller områdestyring for at få den nødvendige adgang. Hvis de foldes ind i hierarkiet, kan der være rapporteringsimplikationer.

Det er vigtigt at bruge tid på at opsætte rollehierarkiet, da det er et af de grundlæggende aspekter af delingsmodellen.

Offentlige grupper

En offentlig gruppe er en samling af individuelle brugere, roller, områder osv., som alle har en fælles funktion. Offentlige grupper kan bestå af:

• Brugere
• Kundeportalbrugere
• Partnerbrugere
• Roller
• Roller og interne underordnede
• Roller, interne og portalunderordnede
• Portalroller
• Portalroller og underordnede
• Områder
• Områder og underordnede
• Andre offentlige grupper (inddeling)

Grupper kan indlejres (gruppe A indlejret i gruppe B), men indlejrer ikke mere end fem niveauer. Indlejring har en indflydelse på gruppevedligeholdelse og ydeevne på grund af gruppemedlemskabsberegning. Som en bedste fremgangsmåde skal du holde det samlede antal offentlige grupper for en organisation på 100.000.

Ejerbaserede delingsregler

Ejerbaserede delingsregler tillader undtagelser til standardindstillinger for hele organisationen og det rollehierarki, der giver yderligere brugere adgang til registreringer, de ikke ejer. Ejerbaserede delingsregler er kun baseret på registreringsejeren.

Kontaktejerbaserede delingsregler gælder ikke for private kontakter eller kontakter, der ikke er tilknyttet en konto.

Grænsen for samlede delingsregler pr. objekt er 300.

Kriteriebaserede delingsregler

Kriteriebaserede delingsregler giver adgang til registreringer baseret på registreringens feltværdier (kriterier). Hvis kriterierne opfyldes (en eller flere feltværdier), oprettes der en delingsregistrering for reglen. Registreringsejerskab er ikke en overvejelse.

Grænsen for kriteriebaserede delingsregler og delingsregler for gæstebrugere pr. objekt er 50.

Delingsregler for gæstebrugere

En delingsregel for gæstebrugere er en særlig type kriteriebaseret delingsregel, der bruges til at tildele registreringsadgang til ikke-godkendte gæstebrugere. Grænsen for kriteriebaserede delingsregler og delingsregler for gæstebrugere pr. objekt er 50.

Advarsel: Delingsregeltypen Gæstebruger giver adgang til gæstebrugere uden loginlegitimationsoplysninger. Ved at oprette en delingsregel for gæstebrugere tillader du øjeblikkelig og ubegrænset adgang til alle registreringer, der matcher delingsreglens kriterier for enhver. Hvis du vil sikre dine Salesforce-data og give dine gæstebrugere adgang til det, de har brug for, skal du overveje alle anvendelsessituationer og implikationer ved oprettelse af denne type delingsregel. Implementer sikkerhedskontroller, som du mener er relevante for følsomheden af dine data. Salesforce er ikke ansvarlig for visning af dine data til ikke-godkendte brugere baseret på denne ændring fra standardindstillingerne.

Manuel deling

Nogle gange er det umuligt at definere en ensartet gruppe af brugere, der har brug for adgang til et bestemt sæt af registreringer. Registreringsejere eller andre brugere med tilstrækkelige rettigheder, f.eks. systemadministratorer, kan bruge manuel deling til at give læse- og redigeringstilladelser til brugere, der ikke har adgang på nogen anden måde. Manuel deling automatiseres ikke som delingsindstillinger for hele organisationen, rollehierarkier eller delingsregler. Men det giver registreringsejere fleksibilitet til at dele registreringer med brugere, der skal se dem.

Manuel deling fjernes, når registreringsejeren ændres, eller når den tildelte delingsadgang ikke tildeler yderligere adgang ud over objektets standarddelingsadgangsniveau for hele organisationen. Dette gælder også for manuelle delinger, der er oprettet programmeringsmæssigt.

Manuel delingsregistreringer defineres som delingsregistreringer med rækkeårsagen indstillet til manuel deling.

Alle aktieregistreringer (standard og tilpassede objekter) med en rækkeårsag indstillet til manuel deling kan redigeres og slettes med knappen Del på objektets sidelayout, selv hvis aktieregistreringen blev oprettet programmeringsmæssigt.

Teams

Et team er en gruppe af brugere, der arbejder sammen om en konto, en salgsmulighed eller en sag. Registreringsejere kan opbygge et team for hver registrering, de ejer. Registreringsejeren tilføjer teammedlemmer og angiver det adgangsniveau, hvert teammedlem har til registreringen. Nogle teammedlemmer kan have skrivebeskyttet adgang, mens andre har læse-/skriveadgang.

Det er kun ejere, personer, der er højere i hierarkiet, og administratorer, der kan tilføje teammedlemmer og give mere adgang til medlemmet. Et teammedlem med læse-/skriveadgang kan tilføje et andet medlem, der allerede har adgang til den registrering, som teamet er tilknyttet. Teammedlemmet kan ikke give dem yderligere adgang.

Oprettelse af et teammedlem i appen opretter to registreringer: en teamregistrering og en tilknyttet delingsregistrering. Hvis du opretter teammedlemmer programmeringsmæssigt, skal du administrere både teamregistreringen og den tilknyttede delingsregistrering. Der er kun et team pr. registrering (konto, salgsmulighed eller sag). Hvis der er brug for flere teams, kan du afhængigt af dine specifikke behov overveje områdestyring eller programmeringsmæssig deling

Områdehierarki

Når du bruger Virksomhedsområdestyring, opsætter du et områdehierarki, der viser en models områdestruktur og fungerer som dens hovedinteraktionspunkt. Hvis Virksomhedsområdestyring er aktiveret, skal du administrere både rollehierarkiet og områdehierarkiet. Hvis du ønsker yderligere oplysninger, kan du se Virksomhedsområdestyring i Hjælp til Salesforce.

Apex-styret deling

Apex deling (også kendt som programmeringsmæssig deling) giver dig mulighed for at bruge kode til at opbygge sofistikerede og dynamiske delingsindstillinger, når et dataadgangskrav ikke kan opfyldes med andre midler.

Hvis du opretter en delingsregistrering programmeringsmæssigt, og der bruges den køreklare rækkeårsag (manuel deling), kan du vedligeholde denne delingsregistrering med knappen Del i appen. Delingsregistreringen er underlagt alle regler med den manuelle delingsrækkeårsag, f.eks. sletning ved ejeroverførsel.

Du kan også oprette dine egne Apex for tilpassede objekter for at spore, hvorfor en registrering med en bruger eller en gruppe af brugere og forenkle den kodning, der kræves for at foretage opdateringer og sletninger af delingsregistreringer.

Hvis du ønsker yderligere oplysninger, kan du gennemse deling af en registrering ved brug af Apex, før du overvejer at bruge programmeringsmæssig deling.

Begrænsningsregler

I din konfiguration af dataadgang ønsker du måske at forhindre brugere i at se registreringer, der kan indeholde følsomme data eller blot ikke er vigtige for deres arbejde. Du kan bruge begrænsningsregler til kun at tillade brugere at få adgang til registreringer, der opfylder de kriterier, du angiver. Når der anvendes en begrænsningsregel på en bruger, filtreres de registreringer, som brugeren er tildelt adgang til via standarder for hele organisationen, delingsregler og andre delingsmekanismer, efter kriterier, som du angiver. Begrænsningsregler fungerer på den modsatte måde, som de delingskomponenter, der er diskuteret i dette emne. I stedet for at åbne adgang til brugere, begrænser de det yderligere.

Begrænsningsregler er tilgængelige for tilpassede objekter, eksterne objekter, kontrakter, begivenheder, opgaver, timesedler og timeseddelangivelser. Du kan oprette op til to aktive begrænsningsregler pr. objekt i Enterprise og Developer Edition og op til fem aktive begrænsningsregler pr. objekt i Performance og Unlimited Edition. Begrænsningsregler anvendes på følgende Salesforce-funktioner:

• Listevisninger
• Opslag
• Relaterede lister
• Rapporter
• Søg
• SOQL
• SOSL

Implicit deling

Implicit deling er automatisk. Du kan hverken inaktivere eller aktivere det – det er oprindeligt for applikationen. Med andre ord er implicit deling ikke en indstilling, der kan konfigureres. Det er dog vigtigt for enhver arkitekt at forstå. Overordnet implicit deling giver adgang til overordnede registreringer (kun konto), når en bruger har adgang til underordnede salgsmuligheder, sager eller kontakter for den pågældende konto. Salesforce har en dataadgangspolitik, der angiver, at hvis en bruger kan se en kontakt (eller en salgsmulighed, sag eller bestilling), så ser brugeren implicit den tilknyttede konto. Underordnet implicit deling giver adgang til en kontos underordnede registreringer til kontoejeren. Denne adgang er defineret ved ejerens rolle i rollehierarkiet. Underordnet implicit deling gælder kun for kontakt-, salgsmuligheds- og sagsobjekter (underordnede af kontoen). Adgangsniveauerne, der kan angives, er Vis, Rediger og Ingen adgang for hvert af de underordnede objekter, når rollen oprettes. Ved at indstille til Vis kan kontoejeren implicit se de tilknyttede objektregistreringer (kontakt, salgsmulighed eller sag). Ved at indstille til Rediger kan kontoejeren implicit redigere det tilknyttede objekt (kontakt, salgsmulighed eller sag).

Implicit deling gælder ikke for tilpassede objekter.

Der er ikke en delingsmodel, der passer til alle Salesforce-organisationer. Hver organisation har forskellige krav og udfordringer, når den forsøger at arkitektere den bedste delingsmodel. Det er vigtigt at bruge de mest relevante dataadgangskomponenter, så de passer til organisationens delingskrav. Følgende scenarier er almindelige udfordringer, når du forsøger at arkitektere en delingsmodel.

• Hvad sker der med rollehierarkiet?

  • Der sker intet med rollehierarkiet, hvis du også bruger et områdehierarki. Men hvis du bruger både områdebaserede prognoser og rollebaserede prognoser sammen, skal du administrere to hierarkier. I denne situation anbefaler vi, at du bruger rollehierarkiet til at modellere HR-rapporteringsstrukturen og derefter bruger områdehierarkiet til at modellere det faktiske salgshierarki. Områdehierarkiet er bedst til modellering af en matrixrapporteringsstruktur, hvor nogen kan rapportere til flere managers.

    Hvis du ikke bruger områdebaserede prognoser og rollebaserede prognoser sammen, er det kun muligt at bruge områdehierarkiet som salgshierarkiet. I dette scenarie er det bedst at forenkle eller fladgøre hierarkiet så meget som muligt.

    Vi anbefaler ikke, at du gør rollehierarkiet og områdehierarkiet identisk, da det medfører unødvendig delingsaktivitet.

• Kan du stadig bruge teams?

  • Ja. Men hvis du kan opfylde dine adgangskrav i områdehierarkiet (f.eks. overlejringer), er det bedre at gøre det der, end at bruge teams. Du vedligeholder allerede flere hierarkier (rolle og område), så når du forsøger at holde tingene så enkle som muligt, skal du kun implementere teams, hvis ingen anden eksisterende delingskomponent vil opfylde kravet.

• Genjustering og gentildeling

  • Der forekommer to typer ændringer – medlemskabet af roller, teams eller områder og strukturen af hierarkiet. Medlemskabsændringer kan typisk forekomme dagligt, selv pr. time. Hierarkisk strukturelle ændringer (omjusteringer) forekommer generelt mindre ofte (kvartalsvis, halvårligt eller årligt) og kan være ressourceprægede. Det, der skal tages med i betragtning, er mængden af ændringer og antallet af overlappende ændringer, som hver ændring vil forårsage. Som tommelfingerregel skal der ikke forekomme mere end kvartalsvis strukturelle ændringer, og alle ændringer af høj mængde (masseændringer eller masseændringer) skal planlægges, testes og koordineres korrekt.

• Store datamængder

  • Uanset om du opretter modeller til den indledende udrulning eller planlægger en omjusteringsændring, skal du tage alvorlige hensyn til mængden af data. Der er tærskler, hvor ydeevne kan blive en faktor, så det anbefales på det kraftigste at teste dine ændringer i en sandbox før produktion. Denne test giver dig også en basislinje for, hvor lang tid ændringen tager.

    Hvis du har mere end to millioner konti og har implementerede teams eller Virksomhedsområdestyring, skal du især være opmærksom på ydeevnen. Disse er komplekse delingsmodelkomponenter, der kan oprette en stor mængde af delingsregistreringer og dermed langsigtede transaktioner.

• Udsæt delingsberegninger

  • Hvis du har et objekt, der bruger deling og har en stor mængde registreringer (f.eks. mere end to millioner konti), og du skal foretage en masseændring (f.eks. en kvartalsvis omjustering, der kræver en hierarkiændring), så er der en funktion, som Salesforce Kundesupport kan aktivere til at udsætte automatiske delingsberegninger. Som standard kan hver enkelt ændring af rollehierarkiet, områdehierarkiet, grupper, delingsregler, brugerroller, teammedlemskab eller ejerskab af registreringer starte automatiske delingsberegninger. Når der foretages en masseændring, medfører det, at der starter en række automatiske delingsgenberegninger. Ved midlertidigt at suspendere disse genberegninger kan du foretage ændringen og derefter få delingsberegninger til at ske på en gang. Denne metode er typisk mere effektiv og klarer sig bedre for masseændringer.

• Data- og ejerskabsskær

  • Dataskydninger defineres som nogle få overordnede registreringer med mange underordnede registreringer. Disse skævheder kan virkelig skade dig, når nogle få konti har mange kontakter, salgsmuligheder eller sager. Forholdet, hvor vi begynder at se nedgang i ydeevne, er 1:10.000. Som en bedste fremgangsmåde skal du holde forholdet så tæt på som muligt (lavere foretrækkes).

    Ejerskabsforskydninger minder om dataskydninger, bortset fra at vi refererer til en enkelt bruger, rolle eller gruppe, der ejer mange registreringer for et objekt. Som med dataskærme kan disse også forårsage lange kørende transaktioner, hvilket forårsager en nedgang i ydeevnen, når der forekommer ændring. Det anbefalede forhold mellem ejer og antal registreringer er også 1:10.000.

    Hvis en enkelt bruger ejer mere end 10.000 registreringer, som en bedste fremgangsmåde:

    • Brugerregistreringen for ejeren bør ikke indeholde en rolle i rollehierarkiet.

    • Hvis ejerens brugerregistrering skal indeholde en rolle, skal du placere rollen øverst i hierarkiet i sin egen forgrening af rollehierarkiet.

• Kontohierarkiernes påvirkning af dataadgang

  • Mange mennesker gør et dårligt antagelse, når de implementerer et kontohierarki. De antager, at de brugere, der kan få adgang til en overordnet konto, også kan få adgang til de underordnede konti. Den enkle kendsgerning om kun at have en overordnet/underordnet relation mellem to registreringer styrer ikke adgang. Selvom rollehierarkiet og områdehierarkiet fungerer på denne måde, fungerer kontohierarkiet ikke.

Når du har fuldført din delingsmodelarkitektur, bliver du sandsynligvis spurgt, hvorfor en bruger kan eller ikke kan se en registrering. Du vil typisk ikke høre, når brugere kan se noget, de ikke bør, men hvis det er nødvendigt, er der en måde at se alle brugere, der har adgang til en registrering, og hvorfor.

Den mere vanskelige og sandsynligvis mere almindelige udfordring er, hvorfor en bruger ikke kan se en registrering. De sikkerhedslag, som du har bygget, bestemmer, hvor du starter. Hvis du kender delingsmodellen godt, så vil du sandsynligvis vide, hvilken komponent der skulle have givet adgangen og kan starte der. Men hvis du er mindre bekendt med delingsmodellen, skal du starte med rollehierarkiet og skrubbe hvert lag tilbage for at bestemme, hvilket lag der skal give adgang. Her er et fejlfindingsforløb.

1. Bekræft, at brugeren har tilladelser til at få adgang til objektet.
2. Identificer den brugers rolle, der ikke kan se registreringen, og noter den.
3. Identificer ejeren af registreringens rolle, og noter den.
4. Gennemse rollehierarkiet, og bekræft, at disse to roller er i to forskellige forgreninger (de skal være).
5. Nu skal du gennemse delingsreglerne for objektet og sørge for, at der ikke er nogen regel, der giver brugeren adgang. Hvis der er behov for det, kan du også se i offentlige grupper. Måske blev brugeren efterladt ude af en gruppe, hvor der er en delingsregel, eller er det fornuftigt at oprette en ny delingsregel for at tildele brugeren adgang? Dette valg afhænger af den arkitektur, du forsøger at vedligeholde, og gælder for både ejerbaserede delingsregler og kriteriebaserede delingsregler.
6. Hvis du bruger teams, skal denne bruger være i teamet for den pågældende registrering? Hvordan vedligeholdes teams, og hvordan forekom fejlen?
7. Hvis manuel deling bruges, kan brugeren have mistet adgang, fordi registreringsejeren er ændret. Manuel deling droppes, når ejerskabet ændres. Den manuelle deling kunne også være fjernet ved hjælp af knappen Del.
8. Hvis du bruger Virksomhedsområdestyring, mangler brugeren et af områderne? Hvor bevares medlemskabet af områder, og hvordan forekom fejlen? Eller måske blev registreringen ikke tildelt til det område, hvor brugeren er medlem.
9. Hvis du opretter programmeringsmæssige shares, og der er kriterier for oprettelse af deling i kode, skal du gennemse koden for at forstå, hvorfor denne bruger blev udeladt.