| Skriv ut Åpne PDF-versjon av elektronisk hjelp

#### Eksempel 1: Bruke tilgangsnivået Vise Dette emnet inneholder et eksempel på hvordan tilgangsrettigheter for brukere beregnes i Oracle CRM On Demand. I dette eksemplet har Amanda Jacobsen rollen Selger. Amanda kan opprette nye firmaer og se alle andre firmaposter. Hun kan opprette salgsmuligheter, men hun kan bare se salgsmuligheter som hun eier, eller som hun er autorisert til å se. Tabellen nedenfor viser posttypeinnstillingene for rollen Selger.
Primær posttype | Har tilgang | Kan opprette | Kan lese alle poster
--- | --- | --- | ---
Firma | Ja | Ja | Ja
Salgsmulighet | Ja | Ja | Nei
Rollen Selger gir Amanda full kontroll over firmaene og salgsmulighetene som hun oppretter, og begrensede rettigheter for poster som hun ikke eier. Rollen Selger krever to tilgangsprofiler: en eiertilgangsprofil og en standard tilgangsprofil. Tabellen nedenfor viser innstillingene for selgers eiertilgangsprofil.
Primær posttype | Tilgangsnivå | Relatert posttype | Tilgangsnivå
--- | --- | --- | ---
Firma | Lese/redigere/slette | Salgsmuligheter | Vis
Salgsmulighet | Lese/redigere/slette | Ikke tilgjengelig | Ikke tilgjengelig
Tabellen nedenfor viser innstillingene for selgers standard tilgangsprofil.
Primær posttype | Tilgangsnivå | Relatert posttype | Tilgangsnivå
--- | --- | --- | ---
Firma | Skrivebeskyttet | Salgsmuligheter | Vis
Salgsmulighet | Skrivebeskyttet | Ikke tilgjengelig | Ikke tilgjengelig
I dette eksemplet, der tilgangsrettigheter blir beregnet, antas det at overtagelse av team ikke er aktivert for posttypen Salgsmulighet. Det vil si at det ikke er merket av for valget Aktiver overtagelse av overordnet team for Salgsmulighet på siden Selskapsprofil. Hvis du vil ha flere opplysninger om virkemåten til funksjonen for overtagelse av overordnet team, Om tilgangsoverføring via overtagelse av team. David Blom har også en selgerrolle i det samme selskapet. David har de samme tilgangsrettighetene som Amanda. Amanda er eier av Salgsmulighet X, som er koblet til Firma 1. David oppretter en salgsmulighet, Salgsmulighet Y, og kobler også den til Firma 1. Amanda er ikke med i salgsmulighetsteamet. Når Amanda viser listen over firmaer i selskapet, kan hun se alle firmaene fordi rollen tillater synlighet for alle firmaer, inkludert firmaer hun ikke eier. Tabellen nedenfor viser postene som Amanda ser når hun klikker på firmanavnet Firma 1 for å drille ned til posten. I dette eksemplet vises bare de relevante feltene og kolonnene.
Firmadetaljer: Firma 1
Firmadetaljer
Firmanavn: | Firma 1
Eier: | John Hop
Salgsmuligheter
Navn på salgsmulighet | Eier
Salgsmulighet X | Amanda Jacobsen
Salgsmulighet Y | David Blom
Firmateam
Etternavn | Fornavn | Firmatilgang
Hop | John | Eier
#### Synlighet for relaterte poster i eksempel 1 Når det skal fastslås hvilke relaterte salgsmulighetsposter Amanda kan se for firmaet i dette eksemplet, undersøkes Amandas tilgangsrettigheter i Oracle CRM On Demand som vist nedenfor: Alle aktuelle tilgangsnivåer for den relaterte salgsmulighetsposttypen for denne overordnede firmaposten undersøkes i Oracle CRM On Demand som vist nedenfor: MERKNAD: Hvis flere tilgangsnivåer oppdages fra de forskjellige tilgangskontrollkomponentene, tas alle i betraktning under beregning av tilgangsrettigheter. Det fastslås om Amanda eier det overordnede firmaet. I dette eksemplet er svaret nei. Det fastslås om Amandas rolle tillater henne å lese alle firmaposter. I dette eksemplet er svaret ja. Amandas rolle tillater henne å lese alle firmaposter, og derfor kan Amanda se firmaet. Siden Amanda ikke er eieren av det overordnede firmaet, brukes Amandas standard tilgangsprofil. Tilgangsnivået for den relaterte salgsmulighetsposttypen i Amandas standard tilgangsprofil er Vise. Det fastslås om den overordnede posten er i en bok der Amanda er medlem. I dette eksemplet er svaret nei. Det fastslås om Amanda er medlem av firmateamet. I dette eksemplet er svaret nei. Det fastslås om noen av Amandas underordnede (direkte eller indirekte) er medlem av firmateamet. I dette eksemplet er svaret nei. Hvis svaret på dette spørsmålet er ja (det vil si at én eller flere av Amandas underordnede er medlem av firmateamet), trekkes tilgangsnivået for den relaterte salgsmulighetsposttypen ut for hver av disse underordnede fra den aktuelle tilgangsprofilen, i Oracle CRM On Demand. Tilgangsprofilen som er tilordnet i feltet Firmatilgang i den underordnedes teammedlemskap i firmaet, brukes i slike tilfeller (ikke tilgangsprofilen som er tilordnet i feltet Tilgang til salgsmulighet). Det fastslås om Amanda har tilgang til firmaposten via delegering. I dette eksemplet er svaret nei. Deretter skjer følgende i Oracle CRM On Demand: Det fastslås om Amandas rolle tillater grunnleggende tilgang til salgsmulighetsposter. I dette eksemplet er svaret ja fordi Har tilgang er valgt for posttypen Salgsmulighet i brukerrollen. Det fastslås om Amandas rolle gir henne rettighet for posttypen Salgsmulighet. Salgsmuligheter kontrolleres ikke via rettigheter, og derfor virker ikke rettighetene inn på beregningen av Amandas tilgangsrettigheter i dette eksemplet. Det fastslås om tilgangsnivået for noen av tilgangsprofilene i beregningen er angitt til Overta primær eller en av kombinasjonene av dette nivået. I dette eksemplet er svaret nei. I Oracle CRM On Demand undersøkes deretter alle tilgangsnivåene som er funnet, og det mest tolerante nivået fastslås. I dette tilfellet er Vise det mest tolerante tilgangsnivået. Tilgangsnivået Overta primær finnes ikke, og derfor vises alle underordnede salgsmulighetsposter, inkludert postene som brukeren ikke er autorisert til å se. #### Handlinger for relaterte poster i eksempel 1 Når en bruker prøver å utføre en handling for en relatert post, må det fastslås i Oracle CRM On Demand om brukeren har riktige tilgangsrettigheter for denne handlingen. I dette eksemplet kan Amanda prøve å lese postdetaljene, redigere posten eller slette posten. To tilfeller tas i betraktning: I tilfelle 1 prøver Amanda å utføre en handling for Salgsmulighet X. I tilfelle 2 prøver Amanda å utføre en handling for Salgsmulighet Y. Tilfelle 1: Amanda prøver å utføre en handling for Salgsmulighet X, som hun eier. Amandas tilgangsrettigheter undersøkes i Oracle CRM On Demand, som vist nedenfor: Alle aktuelle tilgangsnivåer for den relaterte salgsmulighetsposttypen for denne overordnede firmaposten undersøkes i Oracle CRM On Demand som vist nedenfor: MERKNAD: Hvis flere tilgangsnivåer oppdages fra de forskjellige tilgangskontrollkomponentene, tas alle i betraktning under beregning av tilgangsrettigheter. Det fastslås om Amanda eier det overordnede firmaet. I dette eksemplet er svaret nei. Det fastslås om Amandas rolle tillater henne å lese alle salgsmulighetsposter. I dette eksemplet er svaret nei. Selv om Amanda kan se den overordnede firmaposten fordi hun bruker standard tilgangsprofil, brukes ikke denne profilen for salgsmulighetsposten. Det fastslås om salgsmulighetsposten er i en bok der Amanda er medlem. I dette eksemplet er svaret nei. Det fastslås om Amanda er medlem av salgsmulighetsteamet. I dette eksemplet er svaret ja. Amanda eier salgsmuligheten og er derfor i salgsmulighetsteamet. Tilgangsnivået for den primære salgsmulighetsposttypen fra Amandas standard tilgangsprofil (selgers standard tilgangsprofil) er Lese/redigere/slette. Det fastslås om noen av Amandas underordnede (direkte eller indirekte) er medlem av salgsmulighetsteamet. I dette eksemplet er svaret nei. Det fastslås om Amanda har tilgang til firmaposten via delegering. I dette eksemplet er svaret nei. Deretter skjer følgende i Oracle CRM On Demand: Det fastslås om Amandas rolle tillater grunnleggende tilgang til salgsmulighetsposter. I dette eksemplet er svaret ja fordi Har tilgang er valgt for posttypen Salgsmulighet i Amandas rolle. Det fastslås om Amandas rolle gir henne rettighet for posttypen Salgsmulighet. Posttypen Salgsmulighet kontrolleres ikke via rettigheter. Derfor virker ikke rettighetene inn på beregningen av Amandas tilgangsrettigheter i dette eksemplet. Det fastslås om tilgangsnivået for noen av tilgangsprofilene i beregningen er angitt til Overta primær eller en av kombinasjonene av dette nivået. I dette eksemplet er svaret nei. I Oracle CRM On Demand undersøkes deretter alle tilgangsnivåene som er funnet, og det mest tolerante nivået fastslås. I dette tilfellet er Lese/redigere/slette det mest tolerante tilgangsnivået. Tilfelle 2: Amanda prøver å utføre en handling for Salgsmulighet Y, som eies av David Blom. Amandas tilgangsrettigheter undersøkes i Oracle CRM On Demand, som vist nedenfor: Alle aktuelle tilgangsnivåer for den relaterte salgsmulighetsposttypen for denne overordnede firmaposten undersøkes i Oracle CRM On Demand som vist nedenfor: MERKNAD: Hvis flere tilgangsnivåer oppdages fra de forskjellige tilgangskontrollkomponentene, tas alle i betraktning under beregning av tilgangsrettigheter. Det fastslås om Amanda eier det overordnede firmaet. I dette eksemplet er svaret nei. Det fastslås om Amandas rolle tillater henne å lese alle salgsmulighetsposter. I dette eksemplet er svaret nei. Selv om Amanda kan se den overordnede firmaposten fordi hun bruker standard tilgangsprofil, brukes ikke denne profilen for salgsmulighetsposten. Det fastslås om salgsmulighetsposten er i en bok der Amanda er medlem. I dette eksemplet er svaret nei. Det fastslås om Amanda er medlem av salgsmulighetsteamet. I dette eksemplet er svaret nei. Det fastslås om noen av Amandas underordnede (direkte eller indirekte) er medlem av salgsmulighetsteamet. I dette eksemplet er svaret nei. Det fastslås om Amanda har tilgang til firmaposten via delegering. I dette eksemplet er svaret nei. Deretter skjer følgende i Oracle CRM On Demand: Det fastslås om Amandas rolle tillater grunnleggende tilgang til salgsmulighetsposter. I dette eksemplet er svaret ja fordi Har tilgang er valgt for posttypen Salgsmulighet i Amandas rolle. Det fastslås om Amandas rolle gir henne rettighet for posttypen Salgsmulighet. Posttypen Salgsmulighet kontrolleres ikke via rettigheter, og derfor virker ikke rettighetene inn på beregningen av Amandas tilgangsrettigheter i dette eksemplet. Det fastslås om tilgangsnivået for noen av tilgangsprofilene i beregningen er angitt til Overta primær eller en av kombinasjonene av dette nivået. I dette eksemplet er svaret nei. I Oracle CRM On Demand undersøkes deretter alle tilgangsnivåene som er funnet, og det mest tolerante nivået fastslås. I dette tilfellet er Ingen tilgang det endelige tilgangsnivået. #### Beslektede emner Du finner flere eksempler i følgende emner: Eksempel 2: Bruke tilgangsnivået Overta primær Eksempel 3: Sikre data via bøker

Publisert August 2022 | Copyright © 2005, 2022, Oracle og/eller tilknyttede selskaper. Legal Notices.