Ticket‑systemer: ændringshistorik i Jira, ServiceNow og lignende

Forside · Gennemgået oktober 2026 · Af John Nielsen

Ticket-systemer gemmer ikke kun den aktuelle tilstand af en sag, men også en historik over ændringer: hvem ændrede status, prioritet, ansvarlig, beskrivelse eller et brugerdefineret felt, hvornår, og fra hvilken værdi til hvilken. Den historik er ofte det stærkeste bevis i IT-tvister om leverancer, fejlretning og svartider. Men den findes i flere lag, og en almindelig eksport fra brugergrænsefladen indeholder sjældent det hele. Et forsvarligt udtræk henter historikken via systemets API eller administrative eksport, kontrollerer fuldstændigheden og dokumenterer metoden.

Hvad historikken kan bruges til juridisk, og hvad advokaten bør bede om, er beskrevet i Jira, Zendesk og ticketsystemer som bevis. Her handler det om de tekniske lag og selve udtrækket.

Tre lag af historik

Sagens ændringslog · Feltændringer pr. sag med tidspunkt, bruger, før- og efterværdi
Kommentarer og arbejdslog · Tekst, redigeringer, synlighed, registreret tid
Systemets auditlog · Administrative ændringer: arbejdsgange, felter, rettigheder, SLA-regler

Det første lag svarer på, hvad der skete med den enkelte sag. Det tredje lag svarer på, om reglerne blev ændret undervejs, fx om en SLA-definition, en arbejdsgang eller et prioritetsfelt fik ny betydning. Uden det tredje lag kan en historik let fejltolkes.

Jira

I Jira har hver sag en ændringslog (changelog), der kan hentes via REST-API’et sammen med sagens felter, kommentarer og arbejdslog. Ændringsloggen indeholder for hver ændring en bruger-id, et tidspunkt og en liste over felter med før- og efterværdi. Systemets auditlog registrerer administrative ændringer som oprettelse af felter, ændring af arbejdsgange og tilladelser. I Jira Cloud er auditloggen ikke tilgængelig, hvis alle sitets produkter kører på gratisabonnementet, og opbevaringstiden indstilles af administratoren. Kontrollér derfor den aktuelle indstilling, før det antages, at loggen rækker tilbage til den relevante periode.

Vær opmærksom på, at brugere i Jira Cloud identificeres med et konto-id, og at visningsnavne kan ændres. Hent derfor også en liste over brugere med konto-id og navn på udtrækstidspunktet.

ServiceNow

ServiceNow gemmer ændringer i audittabellen sys_audit, der registrerer feltændringer for tabeller, hvor auditering er slået til. Historikvisningen bygges ud fra den via tabellerne sys_history_set og sys_history_line, der fungerer som en mellemlagring. Kommentarer og arbejdsnoter ligger i journaltabellen sys_journal_field. Auditering slås til pr. tabel i systemets dictionary, og enkelte felter kan være undtaget. Kontrollér konfigurationen, før det lægges til grund, at historikken er fuldstændig.

Andre systemer

Zendesk, Freshdesk, Azure DevOps, GitLab og tilsvarende systemer har hver deres model, men de fleste skelner på samme måde mellem sagens egen historik og systemets administrative log. Find i dokumentationen for det konkrete system, hvilke API-endepunkter der leverer historikken, og hvilke begrænsninger der er på opbevaring og adgang. Feltlogs i CRM-systemer følger lignende principper, se Feltlog og ændringshistorik i CRM-systemer.

Eksportformater og hvad der går tabt

CSV fra brugergrænsefladen indeholder typisk kun den aktuelle tilstand af valgte felter. Historikken mangler.
PDF eller udskrift af en sag viser historikken, som brugergrænsefladen præsenterer den, ofte forkortet og i brugerens tidszone.
API-udtræk i JSON indeholder de rå data med tidspunkter, typisk i UTC eller med tidszoneangivelse, og med interne id’er. Det er det mest fuldstændige format.
Administrativ backup eller eksport af hele instansen kan indeholde alt, men kræver det samme system for at kunne læses.

Til en sag er API-udtrækket ofte det rigtige valg, suppleret med en læsbar præsentation, der henviser til de rå data. Generelt om hvilke logs der findes i SaaS-systemer, og hvem der har dem, se SaaS-systemer som datakilde.

Fremgangsmåde

Afgræns projekter, sagstyper og periode, og notér afgrænsningen.
Hent sagerne med alle felter, ændringslog, kommentarer, arbejdslog og vedhæftninger via API.
Hent systemets auditlog og konfigurationen af arbejdsgange, felter, SLA-regler og prioriteter.
Hent brugerlisten med id, navn og eventuelt organisation.
Kontrollér fuldstændigheden: Sammenlign antallet af hentede sager med antallet i systemets egen søgning, og kontrollér, at der ikke er huller i sagsnumrene, som ikke kan forklares.
Beregn hashværdier af alle filer og lav et manifest. Se Hashmanifest for filsamlinger.
Dokumentér API-version, script eller værktøj med version, den konto, der blev brugt, og tidspunktet.

Brug en konto med læseadgang, og undgå at åbne sager i brugergrænsefladen undervejs, hvis systemet registrerer visninger. Vær opmærksom på, at API’er leverer data i sider og kan begrænse antallet af kald. Et script, der ikke håndterer sideinddeling eller afvisninger korrekt, kan stille og roligt springe sager eller ændringer over. Det er netop det, fuldstændighedskontrollen skal fange.

Fortolkning og faldgruber

Tidszoner. Brugergrænsefladen viser tidspunkter i den enkelte brugers tidszone, mens API’et typisk leverer UTC. To skærmbilleder fra to brugere kan derfor vise forskellige tider for samme hændelse. Se Server-tid og klient-tid.

Automatiseringer. Mange ændringer foretages af regler, integrationer eller servicekonti, ikke af personer. En statusændring kl. 03.00 kan være en automatisk lukning efter en fastsat periode uden svar. Identificér automatiseringskonti, og hent deres regler.

Ændrede definitioner. Hvis et felt er omdøbt, eller en status har fået ny betydning, kan historikken vise de nye navne for gamle ændringer. Auditloggen kan vise, hvornår definitionerne ændrede sig.

Slettede sager og kommentarer. Afhængigt af system og konfiguration kan slettede elementer være væk uden spor, ligge i en papirkurv i en periode eller være registreret i auditloggen. Kontrollér det for det konkrete system.

SLA-ure. SLA-tid beregnes af systemet ud fra regler for kalender, pauser og statusser. Den beregnede værdi i et felt er resultatet af reglerne, ikke en måling. Hvordan sådanne tal efterregnes, er beskrevet i SLA-målinger.

Når modparten ejer systemet

I mange IT-tvister er det leverandøren, der ejer og administrerer ticket-systemet, mens kunden kun har adgang til en portal med et udsnit af sagerne. Kunden ser da hverken interne kommentarer, arbejdslog eller systemets auditlog. Det udtræk, kunden selv kan lave, er derfor ufuldstændigt, og det skal stå tydeligt i dokumentationen.

Det fulde udtræk kræver, at leverandøren medvirker, frivilligt eller efter krav. Bed i så fald om rådata via API med ændringslog og auditlog, ikke om en sammenfatning, og bed om en beskrivelse af, hvordan udtrækket er lavet, så det kan gentages. Sammenhold de sager, kunden selv kan se, med leverandørens udtræk. Afvigelser mellem de to er i sig selv værd at undersøge. Samme problemstilling gælder for projektværktøjer, se fra virksomhedens side Projektværktøjer: hvem gjorde hvad hvornår.

Hvad historikken kan og ikke kan bevise

Historikken kan vise, hvilke ændringer systemet har registreret, med hvilken konto og hvornår. Den kan ikke vise, hvem der fysisk betjente kontoen, eller hvad der blev aftalt uden for systemet, fx i telefonen. Den viser heller ikke, om en fejl faktisk var rettet, når en sag blev lukket. Det kræver andre kilder som kode, testresultater eller drift.

Dokumentation

Rapporten bør beskrive afgrænsning, udtræksmetode, fuldstændighedskontrol, hashværdier og konfigurationens tilstand i perioden. Når enkelte sager fremhæves, bør de vises med den fulde ændringslog og med tidspunkter i én angiven tidszone, så læseren kan se hele forløbet og ikke kun et udsnit.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Kildekode og Git som bevis · Wiki og kravdokumenter: sidehistorik og kravændringer

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik