> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/roles-rights-and-permissions.md). # Roller, rettigheter og tillatelser CERRIX bruker en rollebasert tilgangsmodell for å styre hvem som kan se, redigere og godkjenne informasjon på tvers av plattformen. Dette sikrer at hver bruker bare har tilgang til funksjonene og dataene de trenger for sitt ansvar, noe som støtter både datasikkerhet og effektivt samarbeid. ## Roller og tillatelser i CERRIX Hver bruker tildeles én eller flere roller, som definerer tilgangsnivået deres. Rollene er tilpasset vanlige ansvarsområder innen styring, risiko, etterlevelse, revisjon og avvikshåndtering. Tillatelser angir hva en rolle kan gjøre i en modul. ## Rollegrupper og hvordan roller tildeles Roller kan tildeles brukere én og én, eller samlet via rollegrupper. En rollegruppe pakker et sett med roller og et sett med brukere: hver bruker i gruppen får alle rollene som er tildelt gruppen. ### Tildele roller til en enkelt bruker For et lite antall brukere, gå til **Brukeradministrasjon**, velg brukeren og åpne **Roller**. Merk av rollene du vil gi, og klikk **Lagre bruker** for å ta i bruk endringen. ### Tildele roller via en rollegruppe For å administrere roller for en gruppe brukere samtidig: 1. Gå til **Brukeradministrasjon** og åpne **Workspace-verktøy** i øverste høyre hjørne av skjermen. 2. Velg **Rollegrupper** og åpne rollegruppen du vil redigere. En veiviser vises. 3. I **Tildelte roller** trinnet, velg rollene gruppen skal gi. 4. Gå gjennom de gjenværende trinnene ett og ett — velg brukerne som tilhører gruppen og dashbordene de trenger — og lagre endringene dine i det siste **Oppsummering** trinnet.
Adding a role group: name and description
### Automatisk rolletildeling for provisjonerte brukere Når brukere provisjoneres via SCIM, synkroniseres grupper fra identitetsleverandøren din til CERRIX som rollegrupper. Alle roller du tildeler en slik rollegruppe i CERRIX gis automatisk til de provisjonerte medlemmene av den tilkoblede gruppen — nye brukere får dem så snart provisjoneringen plasserer dem i gruppen. Rollene håndteres alltid i CERRIX: finn rollegruppen som er koblet til identitetsleverandørgruppen din (under **Brukeradministrasjon** > **Workspace-innstillinger**) og tildel de ønskede rollene til den. Merk at gruppenavnene må samsvare: hvis en synkronisert gruppe ikke samsvarer med en eksisterende rollegruppe med samme navn ved første synkronisering, opprettes en ny rollegruppe i CERRIX. ### Brukere opprettet manuelt For brukere som opprettes manuelt, finnes det ingen automatisk rolletildeling: en ny bruker kobles ikke automatisk til en rollegruppe. For å gi en rolle til mange eksisterende brukere samtidig, åpne veiviseren for rollegrupper som beskrevet over og bruk **velg alle** -knappen i trinn 3 for å legge alle brukerne til gruppen i én handling. Alternativt kan roller tildeles samlet via en brukerimportfil — kontakt CERRIX support hvis du vil bruke en import. {% hint style="info" %} For automatisk å opprette brukere og koble dem til rollegrupper, se [Brukerprovisjonering med SCIM](/cerrix-documentation-no/cerrix-funksjoner/admin-settings/authentication-and-user-provisioning/user-provisioning-with-scim.md). {% endhint %} ## Tillatelsesmatriser per modul CERRIX tilbyr en tillatelsesmatrise for hver nøkkelmodul. Disse matrisene er den autoritative referansen for å konfigurere og validere brukerrettigheter. I matrisearket: * Hver rad viser en spesifikk handling (f.eks. *Kan rapportere nye avvik*, *Kan slette risikoer*). * Hver kolonne representerer en rolle (f.eks. Risiko Ubegrenset administrator, Avvik vurderer). * Cellene viser om rollen har tillatelse, og hva omfanget av tillatelsen er (*Ubegrenset*, *Begrenset*, eller *Tildelt*). * Ubegrenset betyr at en bruker har rettigheter på tvers av alle organisasjoner * Begrenset betyr at en bruker har rettigheter for en bestemt organisasjon ## Tillatelsesmatrise for avvik | Rolle | Beskrivelse | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Hendelse Ubegrenset administrator | Full tilgang til all hendelsesrelatert funksjonalitet og synlighet på tvers av alle organisasjoner. | | Hendelse Begrenset administrator | Tilsvarende den ubegrensede administratoren, men begrenset til egen organisasjon (og datterorganisasjoner) og uten tilgang til grunndata. | | Hendelse vurderer | Full redigeringsrett (i statusene: Venter på aksept og Klar for gjennomgang) for hendelser som er tildelt dem | | Hendelse Ansvarlig | Redigeringsrett (i status Venter på forbedringer) for tildelte hendelser, unntatt brukerallokeringer. | | Hendelse rapportør | Kan rapportere nye hendelser for enhver organisasjon i CERRIX. | | Hendelse informert | Kun visningstilgang til hendelser der brukeren er tildelt. | | Hendelse Ubegrenset viser | Kun visningstilgang til alle hendelser, på tvers av alle organisasjoner. | | Hendelse Begrenset viser | Kun visningstilgang til hendelser innenfor brukerens egen organisasjon (og datterorganisasjoner) | Du kan se hvilke tillatelser disse rollene har i denne tillatelsesmatrisen: {% file src="/files/923b119f198b07e9a5f3b18a51265fec4e1a4273" %} ### Avvik bruker Hendelse-rollene Avvik-modulen har ikke sitt eget sett med roller: den gjenbruker rollene fra Hendelser-modulen. Derfor er rollene nedenfor navngitt «Hendelse …», og derfor finner du ikke en egen Avvik-fane i Brukeradministrasjon — avvikstillatelser håndteres under **Hendelser**. For å opprette (rapportere) et nytt avvik trenger du spesielt **Hendelse rapportør** rollen. Uten den blir ikke **Legg til nytt avvik** -knappen vist i Avvik-modulen. Administratorrettigheter alene er ikke nok — selv brukere med en Hendelse-administratorrolle eller plattformadministratorrolle må også ha Hendelse rapportør for å rapportere avvik. En bruker må også ha Hendelse rapportør-rollen for å kunne velges som rapportør for et avvik. For å tildele rollen, gå til **Brukeradministrasjon**, velg brukeren, åpne **Roller**, og under **Hendelser** merk av **Hendelse rapportør** (du kan også gi den via en rollegruppe). Be brukeren oppdatere CERRIX, eller logge ut og inn igjen, for at endringen skal tre i kraft. ### Rettighetene som trengs for å koble risikoer, kontroller og MoI-er til et avvik Å koble et eksisterende objekt til et avvik — en risiko, en kontroll eller en MoI — avhenger samtidig av to ting: 1. **Redigeringsrett på selve avviket.** Brukeren trenger en rolle som tillater redigering av avviket i den gjeldende statusen: **Hendelse vurderer** (statusene Venter på aksept og Klar for gjennomgang), **Hendelse Ansvarlig** (status Venter på forbedringer), eller en av **Hendelse-administrator** -rollene. 2. **Rettigheter i modulen objektet kommer fra.** For å kunne velge en risiko eller en kontroll, trenger brukeren også en rolle i den modulen. En visningsrolle er nok: **Risiko Begrenset viser** og **Kontroll Begrenset viser** gjør objektene i brukerens egen organisasjon (og datterorganisasjoner) valgbare, og de ubegrensede variantene gjør det mulig å koble objekter på tvers av organisasjoner. Uten en rolle i den modulen forblir valglisten tom, selv om brukeren kan redigere avviket. Administratorrettigheter i Avvik-modulen er ikke nødvendig for dette. En andrelinjerolle som beriker avvik med eksisterende risikoer, kontroller og MoI-er beholder vanligvis avvik-Workflow-rollene sine som de er og legger til **Risiko Begrenset viser**, **Kontroll Begrenset viser** og MoI-rollen som passer til oppgaven — se *MoI-er og BIM tillatelsesmatrise* nedenfor for hva hver MoI-rolle tillater. ### Hvilke avvik en bruker kan se Avvikssynlighet styres av brukerens roller og tildelinger. Workflow-rollene ser avvikene de jobber med; administrator- og visningsrollene ser avvik innenfor sitt organisasjonsomfang: | Roller | Avvik synlige | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | Hendelse vurderer, Hendelse Ansvarlig, Hendelse rapportør, Hendelse informert, Beskyttelsesansvarlig | Bare avvikene de selv opprettet eller er tildelt | | Hendelse Begrenset administrator, Hendelse Begrenset viser | Alle avvik i egen organisasjon (og datterorganisasjoner) | | Hendelse Ubegrenset administrator, Hendelse Ubegrenset viser | Alle avvik, på tvers av alle organisasjoner | Ved å kombinere disse rollene kan du finjustere tilgangen: brukere som er involvert i håndteringen av et bestemt avvik ser bare det avviket, mens koordinerende roller beholder oversikten. #### Organisasjonsomfattende lesetilgang uten rettigheter til grunndata Når et team trenger å overvåke hvert avvik på tvers av organisasjonen — for eksempel et team som overvåker datainnbrudd — tildel **Hendelse Ubegrenset viser** rollen. Den gir lesetilgang til alle avvik, mens grunndata fortsatt administreres av administratorene dine. Kombiner den med Workflow-roller for avvikene teamet håndterer aktivt. #### En rapportørrollegruppe med full tilgang til egne avvik For å la avvikskoordinatorer registrere avvik og beholde full skrivetilgang til dem — og til de underliggende MoI-ene — uten å gi administratorrettigheter, opprett en rollegruppe med disse tre rollene: * **Hendelse rapportør** * **Hendelse vurderer** * **Hendelse Ansvarlig** Når et avvik rapporteres, tildeler brukeren seg selv både som vurderer og ansvarlig. De kan da følge sitt eget avvik gjennom hvert Workflow-trinn, redigere alle felter og administrere de koblede MoI-ene, mens kollegenes avvik forblir utenfor omfanget. ## Tillatelsesmatrise for risiko
RollerBeskrivelse
Risiko Ubegrenset administratorDen ubegrensede administratoren har ubegrensede lese- og skriverettigheter, og kan legge til oppføringer i kataloger.
Risiko Begrenset administratorDen begrensede administratoren har begrensede lese- og skriverettigheter for egen organisasjon.
Risiko Ubegrenset skriverDen ubegrensede skriveren har skriverettigheter for hele organisasjonen.
Risiko Begrenset skriverDen begrensede skriveren har skriverettigheter for egen organisasjon.
Risiko Ubegrenset viserDen ubegrensede viseren har visningsrettigheter for hele organisasjonen.
Risiko Begrenset viserDen begrensede viseren har leserettigheter for egen organisasjon.
Du kan se hvilke tillatelser disse rollene har i denne tillatelsesmatrisen: {% file src="/files/06ad674a98496d13b37307d893f120a0fd24bcc2" %} ## Tillatelsesmatrise for kontroller
RollerBeskrivelse
Kontroll Ubegrenset administratorDen ubegrensede administratoren har ansvar for å sette opp og vedlikeholde en komplett oversikt over Kontroll-modulen på tvers av alle organisasjoner. Denne rollen gir full synlighet og redigeringsrett på alle kontroller, samt tilgang til alle grunndata i modulen. Brukeren kan også tildeles enhver rolle innen testaktiviteter.
Kontroll Begrenset administratorDen begrensede administratoren kan også sette opp og holde oversikten over kontrollene. Den begrensede administratoren er imidlertid begrenset til kontroller i egen organisasjon. I tillegg kan den begrensede administratoren velges i alle roller innen testing i egen organisasjon.
Kontroll Ubegrenset skriverDen ubegrensede skriveren har full skriverett for Kontroll-modulen på tvers av alle organisasjoner. De kan opprette, redigere og slette kontroller, men har ingen testrelaterte rettigheter.
Kontroll Begrenset skriverDen begrensede skriveren kan opprette, redigere og slette kontroller innenfor egen organisasjon. I likhet med den ubegrensede skriveren inkluderer denne rollen ingen testrettigheter.
Kontroll Ubegrenset viserDen ubegrensede viseren kan åpne og se alle kontroller på tvers av alle organisasjoner i skrivebeskyttet modus. Denne rollen har ingen redigerings- eller testrettigheter.
Kontroll Begrenset viserDen begrensede viseren kan åpne og se kontroller bare innenfor egen organisasjon i skrivebeskyttet modus. Denne rollen har ingen redigerings- eller testrettigheter.
Kontroll Evidence UploaderEvidence Uploader kan tildeles i testplaner for både Design & Implementation og Effektivitetstesting. Denne rollen er ansvarlig for å laste opp og vedlikeholde støttende bevis som brukes under kontrolltesting.
Kontroll TesterTester er ansvarlig for å utføre både Design & Implementation og Effektivitetstesting. Denne rollen gjennomfører kontrolltester og dokumenterer testresultatene.
Kontroll ReviewerReviewer evaluerer og godkjenner resultatene av Effektivitetstesting. Denne rollen er ansvarlig for å gjennomgå testerens arbeid og sikre at kontrollvurderingene er fullstendige og korrekte.
Kontroll Testplan CreatorTestplanoppretteren er ansvarlig for å utforme og vedlikeholde testplaner for både Design & Implementation og Effektivitetstesting. Denne rollen kan også administrere de tilhørende testkatalogene.
Kontroll UtførerKontrollutføreren er ansvarlig for å utføre den operative gjennomføringen av kontroller slik de er definert i systemet. Denne rollen registrerer utførelsesresultatene og kan laste opp relevant dokumentasjon som viser at kontrollen er utført i henhold til planen.
Du kan se hvilke tillatelser disse rollene har i denne tillatelsesmatrisen: {% file src="/files/bccdb1dfaf5aa89523d64cb3895004d4ae9eec2a" %} ### Tilgang til kontroller og testdokumenter To spørsmål dukker ofte opp om Kontroll-rollene: * **Hvem kan åpne dokumentene som er vedlagt en testscore?** En bruker med en Kontroll Viewer- eller Kontroll Writer-rolle — begrenset eller ubegrenset — som har tilgang til selve kontrollen, kan åpne Design & Implementation-testen for den kontrollen, åpne linjeelementet og se og laste ned dokumentene som er vedlagt testscoren. Tilgang til disse dokumentene følger tilgangen til kontrollen, så det trenger ikke gis noen separat dokumentrettighet. * **Hvorfor ser deltakerne i testplanen fortsatt kontroller fra en arkivert organisasjon?** En bruker som er tildelt en rolle i en testplan beholder tilgang til kontrollene som er koblet til den testplanen, også når organisasjonslaget til disse kontrollene er arkivert og brukeren ikke har noen rettigheter i arkivet. Rollen i testplanen er det som gir tilgangen, og den forblir på plass til rollen fjernes. ## Tillatelsesmatrise for kontroll-effektivitetstesting Rollebeskrivelsene for Kontroll Effektivitetstesting er de samme som for [Kontroll](#controls-permission-matrix). Du kan se hvilke tillatelser disse rollene har i denne tillatelsesmatrisen: {% file src="/files/c8e60356cfd889ede58ee7f24e8f976dabde8341" %} ## MoI-er og BIM tillatelsesmatrise Forbedringstiltak (MoI-er) er alltid koblet til et overordnet objekt som en risiko, en kontroll, et avvik eller en funnrapport. Rettighetene en bruker trenger avhenger derfor av to ting: MoI-rollene selv, og brukerens rettigheter i modulen MoI-en tilhører. {% hint style="warning" %} **MoI-rettigheter alene er ikke tilstrekkelige.** Siden MoI-er tilhører en overordnet modul, trenger en bruker også de riktige rettighetene i den modulen (for eksempel skriverettigheter for Risiko eller Kontroll) for å opprette MoI-er eller opptre som reviewer. En bruker som bare har fått tildelt MoI-roller, vil ikke kunne opprette MoI-er. {% endhint %} ### MoI-workflow-roller MoI-rollene i Brukeradministrasjon bestemmer hvilke workflow-roller en bruker kan tildeles: | Rolle | Beskrivelse | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | MoI Ansvarlig | Gir retten til å bli valgt som Ansvarlig for alle typer MoI. Retten til å justere eller gi et ledelsesvar er spesielt for MoI Ansvarlig. | | MoI Stedfortreder | Gir retten til å bli valgt som Stedfortreder. Stedfortrederen har ikke de samme rettighetene som Ansvarlig og kan ikke redigere ledelsesvaret. | ### Rettigheter som trengs for å opprette en MoI Hvilke rettigheter som trengs for å opprette en MoI, avhenger av typen MoI (dvs. overordnet modul): | MoI-type | Rettigheter som trengs for å opprette | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Risiko MoI | Risiko Begrenset skriver eller Risiko Ubegrenset skriver | | Kontroll MoI | Skriverettigheter for Kontroll; rollen Kontroll Tester tillater også opprettelse av Kontroll-MoI-er | | Avvik MoI | Rollen Hendelse Ansvarlig tillater opprettelse av Avvik-MoI-er | | Funnrapport MoI | BIM funnrapport redigeringsrettigheter; visningsroller som BIM Funnrapport Rapporttype Begrenset viser gir lesetilgang til funnrapporter, men tillater ikke opprettelse av MoI-er | {% hint style="info" %} Vil du at brukere skal kunne registrere funnrapport-MoI-er uten å gi dem bredere BIM-redigeringsrettigheter? Den underliggende retten **Business IM | Forbedringstiltak | Creator** kan aktiveres innenfor en visningsrolle (for eksempel BIM Funnrapport Begrenset viser). Dette er en egendefinert justering av miljøet ditt — kontakt CERRIX support for å få det satt opp. På samme måte kan retten til å opprette Risiko-MoI-er legges til rollen Risiko Begrenset viser som en egendefinert endring. Merk at alle med risikovisningsrettigheter da også vil kunne opprette Risiko-MoI-er for risikoene de har tillatelse til å se. {% endhint %} ### Rettigheter som trengs for å være MoI-reviewer For å være reviewer på en MoI må en bruker ha skriverettigheter for modulen MoI-en tilhører. For eksempel kreves rollen Kontroll Begrenset skriver for en Kontroll-MoI. Uten skriverettigheter i den overordnede modulen: * Brukeren **kan ikke velges** som reviewer på MoI-en. * En bruker som allerede er tildelt som reviewer **ser ikke workflow-knappene** (Godta, Avvis og Lukk MoI), selv når MoI-en har statusen «Klar for aksept».
The Accept, Reject and Close MoI workflow buttons, visible to reviewers with write rights in the parent module
{% hint style="info" %} Hvis en reviewer rapporterer at knappene Godta, Avvis og Lukk MoI mangler, sjekk om de har skriverettigheter i modulen MoI-en tilhører. {% endhint %} ### Bekreftelse av MoI-er og BIM Administrator-rollen Etter at en MoI er opprettet, må den bekreftes før den når stadiet «Under arbeid». Med **BIM Administrator** -rollen kan brukerne: * Bekrefte eller avvise funnrapport-MoI-er * Se og redigere alle funnrapporter, samt alle koblede MoI-er * Endre grunndata, opprette BIM-perioder, justere MoI-e-postmeldinger og gjenopprette slettede funnrapporter * Juster forhåndsinnstillinger i både Workspace for Funnrapport og MoI-Workspace {% hint style="warning" %} BIM Administrator **kan ikke** bekrefte eller avvise Risiko- eller Kontroll-MoI-er. Bekreftelse av disse MoI-ene kan bare utføres av Ansvarlig eller Applikasjonsadministrator. {% endhint %} Visse underrettigheter i BIM Administrator-rollen kan justeres, for eksempel for å begrense tilgang til grunndata. Dette er en tilpasset rollekonfigurasjon — kontakt CERRIX support for å utforske alternativene. Vær oppmerksom på at enhver tilpasning av rollen gjelder generelt for alle brukere som er tildelt den. ### Hvem kan endre forfallsdatoer for MOI-er Muligheten til å endre en MOI-forfallsdato styres av en egen **Due Date Changer** -rettighet. Som standard er denne rettigheten knyttet til følgende roller: * BIM Administrator * MoI Ansvarlig * MoI Stedfortreder MoI Ansvarlig kan bare endre forfallsdatoen mens MOI har statusen **Under arbeid**. Det finnes to separate underliggende rettigheter, avhengig av typen MOI: | Rettighet | Gjelder for | | ---------------------- | ------------------------------------------------------------------------ | | `ImMoiDueDateChanger` | MoI-er koblet til risikoer, kontroller og andre Forbedringstiltak-MoI-er | | `BimMoIDueDateChanger` | MoI-er koblet til funnrapporter | **Begrense endringer i forfallsdato** Hvis du vil hindre Ansvarlig og/eller Stedfortreder i å flytte forfallsdatoer, kan Due Date Changer-retten fjernes fra disse rollene, slik at bare andre roller (for eksempel Applikasjonsadministrator eller BIM Reviewer) kan endre forfallsdatoer. Når du begrenser denne retten, anbefales det å la den være tilgjengelig for Applikasjonsadministrator. Vær oppmerksom på følgende: * Dette er en **endring på rollenivå**: å fjerne retten fra en rolle påvirker **alle brukere med den rollen**, uavhengig av rollegrupper. Den kan ikke begrenses per rollegruppe eller per bruker. * Å endre hvilke roller som har disse rettighetene er en **tilpasset tjenesteforespørsel utført av CERRIX** — kontakt CERRIX support for å få det satt opp. * Det anbefales å bruke endringen i **akseptansemiljøet først** og validere den i ulike scenarier (ulike MOI-typer, ulike roller og ulike MOI-statuser) før du bruker den i produksjon.
The Improvement management roles in User Management
### Hvilke MoI-er en bruker kan se MoI-synlighet styres av dedikerte visningsroller, i tillegg til Workflow-rollene beskrevet over: | Rolle | MoI-er synlige for brukeren | | --------------------- | -------------------------------------------- | | MoI Stedfortreder | Bare MoI-ene som er delegert til dem | | MoI Viewer Begrenset | Alle MoI-er i brukerens egen organisasjon | | MoI Viewer Ubegrenset | Alle MoI-er, på tvers av alle organisasjoner | I tillegg vil visningsrettigheter i overordnet modul vise MoI-ene til objekter innenfor det omfanget. En bruker med visningsrettigheter for Kontroll eller Risiko i en organisasjon, ser for eksempel også MoI-ene som er koblet til kontrollene og risikoene i den organisasjonen. Å eie eller administrere det overordnede objektet utvider ikke i seg selv MoI-synligheten på tvers av organisasjoner. En kontrolleier som må følge opp MoI-er tildelt en annen organisasjon, kan få tildelt **MoI Viewer Ubegrenset** rollen. Tilsvarende er kontrollskriver- og begrensede administratorroller fokusert på å administrere kontroller innenfor sitt omfang og garanterer ikke synlighet for hver koblede MoI — når brukere trenger en fullstendig MoI-oversikt, tildel en av MoI-visningsrollene over i stedet for å utvide kontrollrettighetene deres. {% hint style="info" %} Hvis en bruker rapporterer at de ser færre MoI-er enn forventet, sjekk hvilke av rollene over de har: MoI-oversikten viser nøyaktig hva kombinasjonen av MoI-visningsroller og modulens visningsrettigheter dekker. {% endhint %} ### Avvik MoI-er Avvik MoI-er følger samme tillatelsesmodell som de andre MoI-typene. MoI-Ansvarlig ser bare avvik-MoI-ene som er tildelt dem og kan åpne detaljene for det koblede avviket; MoI-Stedfortreder ser avvik-MoI-ene som er delegert til dem; MoI Viewer Begrenset ser avvik-MoI-ene i egen organisasjon og dens datterorganisasjoner, og MoI Viewer Ubegrenset ser dem alle. Å opprette avvik-MoI-er krever rollen Hendelse Ansvarlig (se *Rettigheter som trengs for å opprette en MoI* ovenfor). ### Hvorfor en MoI-ansvarlig også kan fullføre gjennomgangstrinnene Når ansvarlig for en MoI er i stand til å gå gjennom hele Workflow-en på egen hånd — inkludert trinnene som er ment for reviewer, samtidig som reviewer faktisk mottar varslene — er dette effekten av **BIM Rapporttype Begrenset admin** -rollen. Den rollen gir administratorrettigheter på funnrapporttyper i to situasjoner: * Alle funnrapporttyper som er koblet til brukerens egen organisasjon. * Alle funnrapporttyper som har **ingen organisasjon koblet til i det hele tatt**. Administratorrettigheter på en funnrapporttype dekker Workflow-trinnene til MoI-ene under den, så en bruker som har denne rollen og som også er ansvarlig for en slik MoI, kan bekrefte og godta sitt eget forbedringstiltak. {% hint style="info" %} For å beholde gjennomgangstrinnet hos reviewer, koble hver funnrapporttype til organisasjonen den tilhører — en rapporttype uten organisasjonstilknytning er åpen for hver BIM Rapporttype Begrenset admin i miljøet. Rapporttyper vedlikeholdes i [BIM Grunndata](https://docs.cerrix.com/cerrix-functionalities/module-overview/business-improvement-management/bim-standing-data). {% endhint %} ## Rettigheter som kreves for å koble elementer på tvers av moduler Å koble to elementer starter alltid fra ett av dem, og rettighetene du trenger er rettighetene til elementet du kobler **fra**. To regler gjelder i hele CERRIX: * Du trenger **skriverettigheter** på elementet du kobler fra. Administrator- og skriveroller i den modulen kan opprette koblinger; visningsroller kan se eksisterende koblinger, men ikke legge dem til eller fjerne dem. * Kobling er avgrenset til **organisasjonen til elementet**. En begrenset rolle kan koble elementer i egen organisasjon; en ubegrenset rolle kan koble elementer på tvers av organisasjoner. For elementet du kobler **til**, er visningsrettigheter nok: for eksempel kan en kontrollskriver koble en risiko til en kontroll uten å ha en risiko-skriverrolle, så lenge organisasjonen til kontrollen tillater det. | Kobling fra | Roller som kan opprette koblinger | Koblinger de kan opprette | | ------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Risiko | Risiko Ubegrenset/Begrenset administrator, Risiko Ubegrenset/Begrenset skriver | Kontroller, MoI-er og databehandlingsposter i risikoens organisasjon | | Kontroll | Kontroll Ubegrenset/Begrenset administrator, Kontroll Ubegrenset/Begrenset skriver | Risikoer, MoI-er og databehandlingsposter i kontrollens organisasjon | | Kontroll | Kontroll Tester, Kontroll Reviewer | MoI-er for kontrollen; risikoer og databehandlingsposter er bare til visning | | Avvik | Hendelse Ubegrenset/Begrenset administrator, Hendelse vurderer, Hendelse Ansvarlig | Risikoer, kontroller og MoI-er i avvikets organisasjon (Ansvarlig mens avviket er i vurderings-, forbedrings- eller gjennomgangsfasen) | | MoI | BIM Administrator | Kontroller og databehandlingsposter i MoI-ens organisasjon | | MoI | Revisor | Risikoer, kontroller og databehandlingsposter i MoI-ens organisasjon | | MoI | MoI Ansvarlig, MoI Stedfortreder | Kun visning | | Databehandlingspost | Databehandling Ubegrenset/Begrenset administrator, Databehandling Ubegrenset/Begrenset skriver | Risikoer, kontroller og MoI-er i postens organisasjon | Visningsrollene i hver modul (Ubegrenset viser og Begrenset viser) kan åpne koblede elementer innenfor sitt omfang, men kan ikke endre koblingene. For rettighetene rundt avvik spesielt, se [Rettighetene som trengs for å koble risikoer, kontroller og MoI-er til et avvik](https://docs.cerrix.com/cerrix-functionalities/roles-rights-and-permissions#rights-needed-to-link-risks-controls-and-mois-to-an-incident). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/roles-rights-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.