> 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/module-overview/incidents/creating-a-new-incident.md).
# Opprette et nytt avvik
Denne veiledningen forklarer Workflow for å opprette og rapportere Avvik i **Avviksmodulen** av **CERRIX**. Følg disse trinnene for effektivt å registrere, spore og håndtere Avvik i organisasjonen din.
{% hint style="info" %}
**Videoopplæring**
Foretrekker du å se i stedet for å lese? Ta en titt på vår [Videoveiledninger](/cerrix-documentation-no/beste-praksiser-og-guider/video-tutorials.md#incidents) Videoveiledninger
{% endhint %}
***
### Før du begynner: påkrevd rolle
For å opprette et Avvik trenger du **Hendelse rapportør** rolle. Avviksmodulen har ikke egne roller — den bruker rollene i Hendelsesmodulen, så denne rettigheten administreres under **Hendelser** i brukeradministrasjonen. Administratorrettigheter alene er ikke tilstrekkelige: uten Hendelsesrapportør er **Legg til nytt avvik** knappen ikke synlig.
En administrator kan tildele rollen via **Brukeradministrasjon** → velg brukeren → **Roller** → **Hendelser** → huk av **Hendelse rapportør** (enkeltvis eller via en rollegruppe). Etter at rollen er tildelt, oppdater CERRIX eller logg ut og inn igjen.
Brukere som skal tildeles som **Rapportør** i et Avvik trenger også rollen Hendelsesrapportør — ellers vises de ikke i valglisten for rapportør.
Avvik sendt inn via **CERRIX Forms** er et unntak: enhver bruker kan rapportere et Avvik via et skjema, uten spesielle brukertilganger.
#### Jeg ser ikke alternativet for å rapportere et Avvik
Hvis **Legg til nytt avvik** knappen mangler:
1. Sjekk i brukeradministrasjonen **Brukeradministrasjon** → **Roller** → **Hendelser** om du har **Hendelse rapportør** rollen. Hendelsesadministrator- eller administratorrettigheter inkluderer den ikke.
2. Hvis rollen nettopp ble tildelt, oppdater CERRIX eller logg ut og inn igjen — det kan ta litt tid før knappen vises.
### Slik begynner du å opprette et nytt Avvik
Du kan opprette et nytt Avvik på én av to måter:
* **Fra Avvik Dashboard-siden:**
* Gå til **Avvik**.
* Klikk på knappen merket **"Legg til nytt Avvik"**.
* **Fra et skjema:**
* Konfigurer et skjema for å opprette nye Avvik
* **Gjennom en API-integrasjon**
> **Merk:** Uansett hvilken metode du velger, vil Avviket bli logget og koblet riktig i systemet.
***
### Fylle ut Avvik-skjemaet
Når du åpner et nytt Avvik-skjema, er flere felt tilgjengelige for å registrere detaljert informasjon. For å gjøre det enkelt å registrere et Avvik raskt, selv når detaljene ennå ikke er kjent, er bare feltene som identifiserer Avviket **påkrevd** når du lagrer det for første gang: **Navn på Avvik** og **Rapporterende Organisasjon**. Alle andre felt som administratoren din har konfigurert som påkrevde — for eksempel vurderer og Ansvarlig, beskrivelsen eller påkrevde egendefinerte felt for en Avvikstype — blir påkrevde når Avviket har status **Venter på aksept**, og må fylles ut på det tidspunktet. Den samme regelen gjelder for Avvik opprettet via et skjema eller gjennom API-et.
#### Avvik-felt:
* **Navn på Avvik**: Oppgi en kortfattet, beskrivende tittel for enkel referanse. (Påkrevd)
*
*
*
* **Informert:** Brukeren som skal informeres om hendelsene, men som ikke har noe ansvar i.
*
* **Dato for Hendelse:** Datoen Hendelsen inntraff.
* **Fristdato:** Bruk denne datoen til å angi når du foretrekker at Workflow for undersøkelse og løsning av Avvik skal være fullført. Overvåking av Avviksfremdrift mot fristdatoen bidrar til å opprettholde rettidig administrasjon og løsning.
*
* **Rapporterende Organisasjon**: Velg Ansvarlig organisasjon for rapportering av dette Avviket. (Påkrevd)
* **Avvikstype:** Typen Avvik som inntraff.
* **Forårsaket av Organisasjon:** Organisasjonen som forårsaket Hendelsen.
* **Berørt Organisasjon:** Organisasjonen som ble berørt av Hendelsen.
* **Rotårsakskategori:** Kategorien for rotårsaken.
* **Rotårsak:** En beskrivelse av rotårsaken til Hendelsen.
* **Beskrivelse av påvirkning:** En kort beskrivelse av påvirkningen Hendelsen har.
* **Intern Identifier:** En valgfri ID for Hendelsen, som kan redigeres av brukere. Dette kan brukes for Hendelser som allerede var registrert med en ID før de ble dokumentert i CERRIX.
### Skrive en nyttig Avviksrapport
Tydelige Avviksrapporter gjør Vurdering og undersøkelse raskere.
#### Bruk en spesifikk tittel
Velg en tittel som tydelig beskriver problemet.
Gode eksempler:
* `Kundens betalingsdata eksponert på grunn av e-postfeil`
* `Uautorisert tilgang til HRs delte disk`
* `Brannslukking aktivert i serverrom A`
Unngå vage titler som `Avvik 001` eller `Problem i dag`.
#### Beskriv faktaene
Ta med kjernefaktaene i beskrivelsen:
* Hva som skjedde
* Når det skjedde
* Hvor det skjedde
* Hvem som var involvert eller berørt
* Hvordan det skjedde
* Hvorfor det skjedde, hvis det allerede er kjent
***
### Tildele Avviksroller
Avviksroller tydeliggjør ansvar i teamet ditt:
* **Rapportør**: Tildeles automatisk brukeren som oppretter Avviket.
* **Assessor**: Velg en bruker som skal vurdere og evaluere Avviket.
* **Ansvarlig**: Velg personen som er ansvarlig for å håndtere Avviket.
* **Informert**: Angi andre brukere som skal holdes informert om Avvikets fremdrift.
Bruk disse rollene konsekvent:
* **Rapportør** registrerer de innledende faktaene.
* **Assessor** validerer og videresender Avviket.
* **Ansvarlig** leder undersøkelse og oppfølging.
* **Informert** holder interessenter oppdatert.
> Du kan velge flere brukere for rollene Vurderer, Ansvarlig og Informert hvis nødvendig. Når de er valgt, kan brukere enkelt legges til eller fjernes når som helst.
{% hint style="info" %}
Du kan lese mer om Avviksroller og -rettigheter her: [Roller, rettigheter og tillatelser](/cerrix-documentation-no/cerrix-funksjoner/roles-rights-and-permissions.md#incidents-permission-matrix)
{% endhint %}
***
### Avvikstype og egendefinerte felt
Når du velger en **Avvikstype** kan det aktivere flere egendefinerte felt som er spesifikke for organisasjonens konfigurasjon.
* Velg avvikstypen din **Avvikstype** fra nedtrekksmenyen (f.eks. "Demo").
* Når du har valgt Avvikstypen, kan ekstra faner med egendefinerte felt vises ved siden av standard **"Detaljer"** fanen.
*
***
### Tredjepartsfeltene «Forårsaket av» og «Berørt»
Ved siden av *Forårsaket av Organisasjon* og *Berørt Organisasjon* feltene tilbyr Avvik-skjemaet søkefelt for å registrere **tredjepart** som forårsaket Avviket og den **tredjepart** som er berørt av det. Bruk disse når et Avvik er forårsaket av, eller påvirker, en ekstern tredjepart i stedet for en av de interne organisasjonene dine.
Valglisten i disse feltene hentes fra tredjepartene som er registrert i **Tredjepartsmodulen** i CERRIX. For å gjøre en ekstern part valgbar i Avvik, registrer den i [Tredjepartshåndtering](/cerrix-documentation-no/cerrix-funksjoner/module-overview/third-party-management.md) — det er der listen vedlikeholdes, i stedet for i Grunndata.
### Lagre og validere Avviket ditt
* Fyll ut minst **Navn på Avvik** og **Rapporterende Organisasjon**, og klikk deretter på **Lagre**. **Rapportør** fylles ut automatisk med brukerkontoen din, og **Dato oppdaget** settes til dagens dato med mindre du angir en annen dato.
* Hvis et påkrevd felt fortsatt er tomt, viser systemet valideringsmeldinger som fremhever den manglende informasjonen.
* Fullfør de gjenværende påkrevde feltene — tildelte brukere, beskrivelse og påkrevde egendefinerte felt — mens Avviket er **Venter på aksept**; Avviket kan ikke fortsette i Workflow før de er fylt ut.
Når valideringen og innsendingen er vellykket, vil du se en bekreftelsesmelding.
---
# 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/module-overview/incidents/creating-a-new-incident.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.
