Salesforce-delingsmodellen er et viktig element i organisasjonens mulighet til å gi sikker programdatatilgang. Det er derfor avgjørende å arkitektere delingsmodellen riktig for å oppfylle gjeldende og fremtidige datatilgangskrav. I dette dokumentet ser vi gjennom datatilgjengelighetskomponenter, brukstilfeller med delingsmodeller og reelle kundedelingsløsninger, og vi gir deg noen feilsøkingsretningslinjer.

Dette dokumentet er beregnet for avanserte systemadministratorer og arkitekter. For å forstå konseptene må du ha en kompetent Knowledge i Salesforce-modellen for sikkerhet og deling. Forutsetninger for denne veiledningen er følgende:

• Salesforce Hjelp: Innstillinger for deling
• Trailhead-modul: Datasikkerhet
• Utforme posttilgang i bedriftsskala
• Salesforce velbygd - sikker

Denne veiledningen fokuserer på hovedfunksjonene som brukes til å kontrollere tilgang på postnivå til standardobjekter og tilpassede objekter. Emner som ikke dekkes i denne veiledningen, inkluderer følgende:

• Mappetilgang
• Innholdstilgang
• Chatter
• Tilgang til Knowledge Base
• Tilgang til Ideer, Spørsmål/svar
• Mobildatatilgjengelighet

Med postnivåsikkerhet kan du gi brukere tilgang til enkelte objektposter, men ikke andre. Som med de fleste programmer begynner datatilgang med en bruker. Programmet må vite hvem brukeren er før det gir tilgang. For Salesforce er det forskjellige typer brukere, og noen ganger er tilgangsnivået forskjellig etter type. I stedet for å se gjennom alle attributtene i hver lisenstype, fokuserer vi her på de interessante attributtene som har betydelig innvirkning på datatilgangen. Posteierskap og full tilgang er synonyme og kan byttes ut og gir brukeren det høyeste tilgangsnivået til en post.

High-Volume-brukere

Brukere av nettsteder med stor trafikk (inkludert brukere med lisenstypene Customer Community, High Volume Customer Portal og Authenticated Website) bruker ikke delingsmodellen fordi lisenstypene deres ikke støtter roller. Disse lisensene har sin egen delingsmodell som fungerer etter fremmednøkkel-samsvar mellom brukeren (som holder lisensen) og dataene i Konto- og Kontakt-oppslag. Administratorer kan opprette delingssett eller delingsgrupper for å gi brukere av nettsteder med stor trafikk tilgang til poster.

Chatter Free og Chatter External-lisenser

Lisensene Chatter Free og Chatter External følger ikke standard delingsmodell. Disse lisensene har ikke tilgang til CRM-poster (standardobjekter eller tilpassede objekter) og innholdsfunksjonalitet, og støtter ikke roller, så det er ingen deling.

For resten av dette dokumentet forutsetter vi en Salesforce-brukertype som bruker en full delingsmodell. Se Brukerlisenser for å få mer informasjon om hver tilgjengelig lisenstype.

Profile og tillatelsessett

Profiler og tillatelsessett sørger for sikkerhet på objektnivå ved å bestemme hvilke datatyper brukere kan se og om de kan redigere, opprette eller slette poster. For hvert objekt ignorerer tillatelsene Vise alle og Endre alle delingsregler og innstillinger, slik at administratorer raskt kan gi tilgang til poster knyttet til et gitt objekt på tvers av organisasjonen. Disse tillatelsene er ofte foretrukne alternativer til de administrative tillatelsene Vise alle data og Endre alle data, som gir brukere mulighet til å vise eller endre alle apper og data.

Profiler og tillatelsessett styrer også feltnivåsikkerhet, som bestemmer feltene i hvert objekt som brukere har tilgang til. Et objekt kan for eksempel ha 20 felt, men feltnivåsikkerhet kan konfigureres for å hindre at brukerne ser fem av de 20 feltene.

Vi anbefaler sterkt at du bruker tillatelsessett og tillatelsessettgrupper i stedet for profiler til å behandle brukernes objekttillatelser. Fordi du kan gjenbruke byggeblokker for mindre tillatelsessett, kan du unngå å opprette dusinvis eller til og med hundrevis av profiler for hver bruker- og jobbfunksjon.

Posteierskap og køer

Hver post må eies av én enkelt bruker eller en kø. Eieren har tilgang til posten basert på Objektinnstillinger for eierens profil. Hvis for eksempel eierens profil har Opprette- og Lese-tillatelse for et objekt, men ikke Redigere- eller Slette-tillatelse, kan eieren opprette en post for objektet og se den nye posten. Eieren kan imidlertid ikke redigere eller slette posten. Brukere høyere i et hierarki (rolle eller område) arver samme datatilgang som sine underordnede for standardobjekter. Hvis den underordnede har skrivebeskyttet tilgang, vil brukerne over dem i rollehierarkiet også ha det. Denne tilgangen gjelder for poster som eies av brukere, i tillegg til poster som deles med dem.

Køer hjelper deg å prioritere, distribuere og tildele poster til team som deler arbeidsbelastninger. Kømedlemmer og brukere høyere i rollehierarkiet kan få tilgang til køer fra listevisninger og ta eierskap til poster i en kø.

En god fremgangsmåte hvis en enkelt bruker eier mer enn 10 000 poster:

• Brukerposten til eieren skal ikke inneholde en rolle i rollehierarkiet.

• Hvis eierens brukerpost må inneholde en rolle, plasserer du rollen øverst i hierarkiet i sin egen gren av rollehierarkiet.

Se Salesforce velbygd – pålitelig for å få mer informasjon.

Organisasjonsomfattende standardinnstillinger

Organisasjonsomfattende delingsinnstillinger angir standardtilgangsnivået som brukere har til hverandres poster. Du bruker organisasjonsomfattende delingsinnstillinger til å låse dataene på det mest restriktive nivået. Bruk de andre sikkerhets- og delingsverktøyene på postnivå til å selektivt gi tilgang til andre brukere. Brukere har for eksempel tillatelser på objektnivå for å lese og redigere salgsmuligheter, og den organisasjonsomfattende delingsinnstillingen er Skrivebeskyttet. Disse brukerne kan som standard lese alle salgsmulighetsposter, men kan ikke redigere noen med mindre de eier posten eller har fått andre tillatelser.

Organisasjonsomfattende standardinnstillinger kan endres fra én innstilling til en annen (Privat til Kontrollert av overordnet og deretter tilbake til Privat). Disse endringene krever imidlertid ny beregning av deling, og avhengig av volum kan det føre til lange behandlingstider.

Bare for tilpassede objekter kan du konfigurere innstillingen Gi tilgang ved bruk av hierarkier. Hvis det ikke er merket av for (standard er merket av), hindres brukere høyere i rollehierarkiet i å arve tilgang. Denne innstillingen finnes i de organisasjonsomfattende standardinnstillingene.

Rollehierarki

Et rollehierarki representerer et datatilgangsnivå som en bruker eller gruppe av brukere trenger. Rollehierarkiet sikrer at ledere alltid har tilgang til de samme dataene som sine ansatte, uavhengig av de organisasjonsomfattende standardinnstillingene. Rollehierarkier trenger ikke å samsvare nøyaktig med organisasjonsdiagrammet. I stedet bør hver rolle i hierarkiet representere et datatilgangsnivå som en bruker eller gruppe av brukere trenger.

I Salesforce-organisasjoner som er opprettet i Spring ’21-utgivelsen eller nyere, kan du opprette opptil 5000 roller. I organisasjoner som er opprettet før Spring ’21-utgivelsen, kan du opprette opptil 500 roller og kan kontakte Salesforces kundestøtte for å øke denne grensen. En god fremgangsmåte er å holde antall interne roller til 25 000 og antall eksterne roller til 100 000.

En god fremgangsmåte er å holde rollehierarkiet på ikke mer enn 10 nivåer med grener i hierarkiet.

Når en brukers rolle endres, evalueres eventuelle relevante delingsregler for å korrigere tilgang etter behov. Medarbeidere i samme rolle garanterer ikke at de får tilgang til hverandres data.

Modellering av rollehierarkiet begynner med å forstå hvordan organisasjonen er strukturert. Dette bygger vanligvis på å forstå en leders omfang, og starter fra øverst. Administrerende direktør overvåker hele firmaet. Administrerende direktøren har vanligvis direkte underordnede som deretter kan segmenteres etter forretningsenhet (salg eller kundestøtte) eller geografisk område (EMEA, APAC). Denne personen har deretter direkte underordnede som kan segmenteres ytterligere, og så videre. Selv om dette høres veldig ut som et HR-organisasjonsdiagram, bør du fokusere på datatilgjengelighet med hensyn til HR-rapportering når du modellerer datatilgang.

Overlegg er alltid den vanskelige delen av hierarkiet. Hvis de er i sin egen avdeling, krever de enten delingsregler, team eller områdebehandling for å få nødvendig tilgang. Hvis de brettes inn i hierarkiet, kan det være rapporteringspåvirkninger.

Det er viktig å bruke tiden på å konfigurere rollehierarkiet fordi det er en av de grunnleggende aspektene ved delingsmodellen.

Felles grupper

En felles gruppe er en samling enkeltbrukere, roller, områder og så videre som alle har en felles funksjon. Felles grupper kan bestå av:

• Brukere
• Kundeportalbrukere
• Partnerbrukere
• Roller
• Roller og interne underordnede
• Roller, interne underordnede og underordnede til portal
• Portalroller
• Portalroller og underordnede
• Områder
• Områder og underordnede
• Andre felles grupper (nesting)

Grupper kan nestes (gruppe A nestet til gruppe B), men ikke neste flere enn fem nivåer. Nesting har en innvirkning på gruppevedlikehold og ytelse på grunn av beregning av gruppemedlemskap. En god fremgangsmåte er å holde totalt antall felles grupper for en organisasjon på 100 000.

Eierbaserte delingsregler

Eierbaserte delingsregler tillater unntak for organisasjonsomfattende standardinnstillinger og rollehierarkiet som gir flere brukere tilgang til poster de ikke eier. Eierbaserte delingsregler er basert bare på posteieren.

Eierbaserte delingsregler for kontakter gjelder ikke for private kontakter eller kontakter som ikke er tilknyttet en konto.

Grensen for totalt antall delingsregler per objekt er 300.

Kriteriebaserte delingsregler

Kriteriebaserte delingsregler gir tilgang til poster basert på postens feltverdier (kriterier). Hvis kriteriene oppfylles (én eller mange feltverdier), opprettes det en delingspost for regelen. Posteierskap er ikke en vurdering.

Grensen for kriteriebaserte delingsregler og delingsregler for gjestebrukere per objekt er 50.

Delingsregler for gjestebrukere

En delingsregel for gjestebrukere er en spesiell type kriteriebasert delingsregel som brukes til å gi posttilgang til ikke-godkjente gjestebrukere. Grensen for kriteriebaserte delingsregler og delingsregler for gjestebrukere per objekt er 50.

Advarsel: Delingsregeltypen for gjestebrukere gir tilgang til gjestebrukere uten påloggingslegitimasjon. Ved å opprette en delingsregel for gjestebrukere gir du umiddelbar og ubegrenset tilgang til alle poster som samsvarer med delingsregelens kriterier, til hvem som helst. For å sikre Salesforce-dataene og gi gjestebrukerne tilgang til det de trenger, bør du vurdere alle bruksområder og konsekvenser ved opprettelse av denne typen delingsregel. Implementer sikkerhetskontroller som du mener er riktige for datasensitiviteten. Salesforce er ikke ansvarlig for eventuell eksponering av dataene dine for ikke-godkjente brukere basert på denne endringen fra standardinnstillinger.

Handlig deling

Noen ganger er det umulig å definere en konsistent gruppe brukere som trenger tilgang til et bestemt sett med poster. Posteiere eller andre brukere med tilstrekkelige rettigheter, som systemadministratorer, kan bruke manuell deling til å gi lese- og redigeringstillatelser til brukere som ikke har tilgang på noen annen måte. Manuell deling er ikke automatisert som organisasjonsomfattende delingsinnstillinger, rollehierarkier eller delingsregler. Men det gir posteiere fleksibilitet til å dele poster med brukere som må se dem.

Manuell deling fjernes når posteieren endres eller når den gitte delingstilgangen ikke gir ytterligere tilgang ut over objektets organisasjonsomfattende standard tilgangsnivå for deling. Dette gjelder også manuelle delinger som er opprettet programmatisk.

Manuelle delingsposter defineres som delingsposter med radårsaken angitt til manuell deling.

Alle delingsposter (standardobjekter og tilpassede objekter) med en radårsak satt til manuell deling kan redigeres og slettes med Del-knappen i objektets sideoppsett, selv om delingsposten ble opprettet programmatisk.

Team

Et team er en gruppe brukere som arbeider sammen om en konto, en salgsmulighet eller en sak. Posteiere kan bygge et team for hver post de eier. Posteieren legger til teammedlemmer og angir tilgangsnivået hvert teammedlem har til posten. Enkelte teammedlemmer kan ha skrivebeskyttet tilgang, mens andre har lese/skrive-tilgang.

Bare eiere, personer høyere i hierarkiet og administratorer kan legge til teammedlemmer og gi mer tilgang til medlemmet. Et teammedlem med lese/skrive-tilgang kan legge til et annet medlem som allerede har tilgang til posten som teamet er tilknyttet. Teammedlemmet kan ikke gi dem ekstra tilgang.

Når du oppretter et teammedlem i appen, opprettes det to poster: en teampost og en tilknyttet delingspost. Hvis du oppretter teammedlemmer programmatisk, må du behandle både teamposten og den tilknyttede delingsposten. Det er bare ett team per post (Konto, Salgsmulighet eller Sak). Hvis flere team er nødvendige, kan du vurdere områdebehandling eller programmatisk deling avhengig av dine spesifikke behov.

Områdehierarki

Når du bruker Foretaksområdebehandling, konfigurerer du et områdehierarki som viser en modells områdestruktur og fungerer som hovedinteraksjonspunkt. Hvis Foretaksområdebehandling er aktivert, må du behandle både rollehierarkiet og områdehierarkiet. Hvis du vil ha mer informasjon, kan du se Foretaksområdebehandling i Salesforce Hjelp.

Apex-administrert deling

Med Apex deling (også kalt programmatisk deling) kan du bruke kode til å bygge avanserte og dynamiske delingsinnstillinger når et datatilgangskrav ikke kan oppfylles på noen annen måte.

Hvis du oppretter en delingspost programmatisk, og den forhåndsdefinerte radårsaken (manuell deling) brukes, kan du vedlikeholde denne delingsposten med knappen Del i appen. Delingsposten er underlagt alle regler med den manuelle delingsradårsaken, som sletting ved eieroverføring.

Du kan også opprette dine egne Apex for tilpassede objekter for å spore hvorfor en post med en bruker eller gruppe av brukere, og forenkle kodingen som kreves for å gjøre oppdateringer og slettinger av delingsposter.

Hvis du vil ha mer informasjon, kan du lese Deling av en post med Apex før du vurderer å bruke programmatisk deling.

Begrensningsregler

I datatilgangskonfigurasjonen kan du hindre at brukere ser poster som kan inneholde sensitive data eller bare ikke er viktige for arbeidet deres. Du kan bruke begrensningsregler til å gi brukere tilgang bare til poster som oppfyller kriteriene du angir. Når en begrensningsregel brukes på en bruker, filtreres postene som brukeren får tilgang til via organisasjonsomfattende standardinnstillinger, delingsregler og andre delingsmekanismer, etter kriterier du angir. Begrensningsregler fungerer på den motsatte måten som delingskomponentene som er diskutert i dette emnet. I stedet for å åpne opp tilgang til brukere, begrenser de den ytterligere.

Begrensningsregler er tilgjengelig for tilpassede objekter, eksterne objekter, kontrakter, hendelser, oppgaver, timelister og timelisteoppføringer. Du kan opprette opptil to aktive begrensningsregler per objekt i Enterprise og Developer Edition og opptil fem aktive begrensningsregler per objekt i Performance og Unlimited Edition. Begrensningsregler brukes på følgende Salesforce-funksjoner:

• Listevisninger
• Oppslag
• Relaterte lister
• Rapporter
• Søk
• SOQL
• SOSL

Implisitt deling

Implisitt deling er automatisk. Du kan verken slå den av eller slå den på – den er innebygd for programmet. Med andre ord er ikke implisitt deling en konfigurerbar innstilling, men det er viktig for enhver arkitekt å forstå den. Overordnet implisitt deling gir tilgang til overordnede poster (bare konto) når en bruker har tilgang til underordnede salgsmuligheter, saker eller kontakter for den kontoen. Salesforce har en datatilgangspolicy som angir at hvis en bruker kan se en kontakt (eller salgsmulighet, sak eller bestilling), ser brukeren implisitt den tilknyttede kontoen. Underordnet implisitt deling gir tilgang til en kontos underordnede poster til kontoeieren. Denne tilgangen defineres ved eierens rolle i rollehierarkiet. Underordnet implisitt deling gjelder bare for kontakt-, salgsmulighets- og saksobjekter (underordnede til kontoen). Tilgangsnivåene som kan gis, er Vise-, Redigere- og Ingen-tilgang for hvert av de underordnede objektene når rollen opprettes. Ved å angi Vis kan kontoeieren implisitt se de tilknyttede objektpostene (kontakt, salgsmulighet eller sak). Ved å angi Rediger kan kontoeieren implisitt endre det tilknyttede objektet (kontakt, salgsmulighet eller sak).

Implisitt deling gjelder ikke for tilpassede objekter.

Det er ikke en delingsmodell som passer alle Salesforce-organisasjoner. Alle organisasjoner har forskjellige krav og utfordringer når de prøver å bygge opp den beste delingsmodellen. Det er avgjørende å bruke de mest aktuelle datatilgangskomponentene for å tilpasse dem til organisasjonens delingskrav. Følgende scenarier er vanlige utfordringer når du prøver å bygge opp en delingsmodell.

• Hva skjer med rollehierarkiet?

  • Det skjer ikke noe med rollehierarkiet hvis du også bruker et områdehierarki. Men hvis du bruker både områdebaserte prognoser og rollebaserte prognoser sammen, må du behandle to hierarkier. I dette tilfellet anbefaler vi at du bruker rollehierarkiet til å modellere HR-rapporteringsstrukturen, og deretter bruker du områdehierarkiet til å modellere det faktiske salgshierarkiet. Områdehierarkiet er best for modellering av en matriserapportstruktur der noen kan rapportere til flere ledere.

    Hvis du ikke bruker områdebaserte prognoser og rollebaserte prognoser sammen, er det mulig å bruke bare områdehierarkiet som salgshierarki. I dette scenariet er det best å forenkle eller flate ut hierarkiet så mye som mulig.

    Vi anbefaler at du ikke gjør rollehierarkiet og områdehierarkiet identiske fordi det fører til unødvendig delingsaktivitet.

• Kan du fremdeles bruke team?

  • Ja. Men hvis du kan tilfredsstille tilgangskravene dine innenfor områdehierarkiet (som overlegg), er det bedre å gjøre det der enn å bruke team. Du vedlikeholder allerede flere hierarkier (rolle og område), så hvis du prøver å gjøre ting så enkle som mulig, implementerer du bare team hvis ingen annen eksisterende delingskomponent oppfyller kravet.

• Omjustering og ny tildeling

  • Det er to typer endringer som skjer – medlemskapet i roller, team eller områder og strukturen i hierarkiet. Medlemsendringer kan vanligvis skje daglig, også hver time. Endringer i hierarkistruktur (omjusteringer) skjer vanligvis sjeldnere (kvartalsvis, halvårlig eller årlig) og kan være ressurskrevende. Det som må vurderes, er volumet av endringer og antall gjennomgripende endringer som hver endring vil forårsake. Som en regel må ikke strukturelle endringer skje mer enn kvartalsvis, og alle endringer med stor trafikk (masseendringer eller masseendringer) må være godt planlagt, testet og koordinert.

• Store datavolumer

  • Enten du modellerer for den første utrullingen eller planlegger en endring av omjusteringen, må du ta noen alvorlige hensyn til datavolumet. Det er terskler der ytelse kan bli en faktor, så det anbefales sterkt å teste ut endringene i en Sandbox-organisasjon før produksjon. Denne testen gir deg også en grunnleggende informasjon om hvor lang tid endringen vil ta.

    Hvis du har flere enn to millioner kontoer og har implementert team eller Foretaksområdebehandling, må du spesielt være oppmerksom på ytelsen. Dette er komplekse delingsmodellkomponenter som kan utgjøre et stort antall delingsposter og dermed langvarige transaksjoner.

• Utsette beregninger av deling

  • Hvis du har et objekt som bruker deling og har et stort antall poster (som flere enn to millioner kontoer), og du må utføre en masseendring (som en kvartalsvis omjustering som krever en hierarkiendring), er det en funksjon som Salesforces kundestøtte kan aktivere for å utsette beregninger av automatisk deling. Innebygd kan hver enkeltendring i rollehierarkiet, områdehierarkiet, grupper, delingsregler, brukerroller, teammedlemskap eller eierskap for poster starte automatiske beregninger av deling. Når en masseendring utføres, starter det en rekke automatiske nye beregninger av deling. Ved å suspendere disse nye beregningene midlertidig kan du gjøre endringen og deretter få delingsberegninger til å skje alt på en gang. Denne metoden er vanligvis mer effektiv og gjør det bedre for masseendringer.

• Dataskift og eierskap

  • Dataskift defineres som noen få overordnede poster med mange underordnede poster. Disse skjevhetene kan virkelig skade deg når noen få kontoer har mange kontakter, salgsmuligheter eller saker. Forholdet der vi begynner å se ytelsesforringelse er 1:10 000. En god fremgangsmåte er å holde forholdet så nært det som mulig (lavere er foretrukket).

    Eierskapsskjevheter ligner dataskjevheter bortsett fra at vi refererer til en enkelt bruker, rolle eller gruppe som eier mange poster for et objekt. Som med dataskift kan disse også føre til langvarige transaksjoner som fører til en nedgang i ytelsen når endring skjer. Det anbefalte forholdet mellom eier og antall poster er også 1:10 000.

    En god fremgangsmåte hvis en enkelt bruker eier mer enn 10 000 poster:

    • Brukerposten til eieren skal ikke inneholde en rolle i rollehierarkiet.

    • Hvis eierens brukerpost må inneholde en rolle, plasserer du rollen øverst i hierarkiet i sin egen gren av rollehierarkiet.

• Kontohierarkis innvirkning på datatilgang

  • Mange gjør en dårlig antagelse når de implementerer et kontohierarki. De forutsetter at brukerne som har tilgang til en overordnet konto, også har tilgang til de underordnede kontoene. Det enkle faktum at du bare har en overordnet/underordnet-relasjon mellom to poster, fører ikke til tilgang. Selv om rollehierarkiet og områdehierarkiet fungerer på denne måten, gjør ikke kontohierarkiet det.

Når du har fullført delingsmodellarkitekturen, vil du sannsynligvis bli utfordret over hvorfor en bruker kan eller ikke kan se en post. Vanligvis vil du ikke høre når brukere kan se noe de ikke burde, men om nødvendig er det en måte å se alle brukere som har tilgang til en post, og hvorfor.

Den vanskeligste utfordringen, og sannsynligvis mer vanlig, er hvorfor en bruker ikke kan se en post. Sikkerhetslagene du har arkitektert, bestemmer hvor du starter. Hvis du kjenner delingsmodellen godt, vet du sannsynligvis hvilken komponent som burde ha gitt tilgangen, og kan starte der. Men hvis du er mindre kjent med delingsmodellen, starter du med rollehierarkiet og går tilbake hvert lag for å finne ut hvilket som skal gi tilgang. Her er en feilsøkingsflyt.

1. Kontroller at brukeren har tilgangstillatelser til objektet.
2. Identifiser brukerens rolle som ikke kan se posten, og noter den.
3. Identifiser eieren av postens rolle, og noter den.
4. Se gjennom rollehierarkiet, og kontroller at disse to rollene er i to forskjellige grener (de skal være det).
5. Nå må du se gjennom delingsreglene for objektet og forsikre deg om at det ikke er noen regel som gir brukeren tilgang. Se om nødvendig også i felles grupper. Kanskje brukeren ble utelatt fra en gruppe der det finnes en delingsregel, eller er det fornuftig å opprette en ny delingsregel for å gi brukeren tilgang? Dette valget avhenger av arkitekturen du prøver å vedlikeholde, og gjelder både eierbaserte delingsregler og kriteriebaserte delingsregler.
6. Hvis du bruker team, skal denne brukeren være i teamet for denne posten? Hvordan vedlikeholdes team, og hvordan oppstod tapet?
7. Hvis manuell deling brukes, kan brukeren ha mistet tilgang fordi posteieren ble endret. Manuelle delinger utelates når eierskap endres. Den manuelle delingen kunne også ha blitt fjernet ved hjelp av Del-knappen.
8. Hvis du bruker Foretaksområdebehandling, mangler brukeren fra ett av områdene? Hvor beholdes områdemedlemskapet, og hvordan oppstod mangelen? Eller posten ble kanskje ikke tildelt til området der brukeren er medlem.
9. Hvis du oppretter programmatiske delinger og det er kriterier for å opprette delingen i kode, ser du gjennom koden for å forstå hvorfor denne brukeren ble utelatt.