Feltlog og ændringshistorik i CRM‑systemer

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Et CRM-system kan vise, hvem der ændrede en kundes ejer, slettede en salgsmulighed eller rettede et telefonnummer, men kun hvis feltsporingen var slået til for netop det felt, før ændringen skete. Feltsporing er i de fleste CRM-systemer noget, en administrator aktiverer pr. objekt og pr. felt, ofte med et loft over antal felter og en begrænset opbevaringstid. Det betyder, at den vigtigste tekniske afklaring i en CRM-sag er opsætningen, ikke indholdet. Uden den kan du ikke sige, om fravær af en ændring betyder, at intet skete.

Den grundlæggende sikring af CRM-data er beskrevet i Bevissikring af CRM-systemer. Sporene efter eksport af kundelister er behandlet særskilt i Kundelisten fra CRM: eksportlogs i SaaS-systemer. Her handler det om ændringshistorikken.

De typiske kilder i et CRM

Feltsporing · Gammel og ny værdi, bruger og tidspunkt for de felter, der er slået til
Postens systemfelter · Oprettet af, oprettet dato, senest ændret af, senest ændret dato
Aktivitetstidslinje · Mails, opkald, møder og noter knyttet til posten
Opsætningslog · Ændringer i konfigurationen, fx felter, rettigheder og sporingsindstillinger
Loginhistorik · Tidspunkt, IP-adresse, klient og resultat
Papirkurv · Slettede poster i en periode
Hændelsesovervågning · Detaljerede hændelser som rapportkørsel og eksport, ofte som tilkøb

Navnene varierer mellem systemer som Salesforce, HubSpot, Dynamics 365 og Pipedrive, men lagene går igen. Loft og opbevaring varierer også: I Salesforce kan feltsporing som standard omfatte op til 20 felter pr. objekt, og historikken vises i 18 måneder i brugerfladen og kan hentes via API i op til 24 måneder, medmindre der er købt udvidet sporing. I Dynamics 365 slås revision til pr. tabel og kolonne, og opbevaringen kan indstilles. For de øvrige systemer slås loft og periode op for den konkrete plan.

Postens systemfelter er ikke historik

Felterne “senest ændret af” og “senest ændret dato” overskrives ved hver ændring. De viser kun den seneste. Er en kundepost ændret af en medarbejder og derefter af en integration, står integrationen som senest ændret, og medarbejderens ændring er kun synlig, hvis feltsporing var slået til. Det er en hyppig fejl at læse systemfelterne som en historik.

Det samme gælder “oprettet af”. En post, der er importeret fra en fil eller oprettet af en formular på hjemmesiden, står med den bruger eller den integration, der kørte importen.

Feltsporing i praksis

Feltsporing gemmer typisk en række pr. ændret felt med postens id, feltnavn, gammel værdi, ny værdi, bruger og tidspunkt. Der er nogle almindelige begrænsninger:

Loft over felter. Mange systemer tillader kun et begrænset antal sporede felter pr. objekt. Administratoren har valgt, hvilke.
Lange tekstfelter gemmes ofte kun som “ændret” uden værdier.
Opbevaring. Historikken kan blive slettet efter en periode, eller kun være tilgængelig via API efter en vis alder.
Masseopdateringer via import eller integration kan være sporet eller ej, afhængigt af systemet.
Ændring af sporing registreres i opsætningsloggen. Hent den, så du kan se, hvornår et felt blev sporet, og om sporingen blev slået fra i perioden.

Ejerskifte, sammenlægning og sletning

Tre handlinger går igen i sager om kunder og medarbejdere, og de efterlader forskellige spor:

Ejerskifte: Hvis ejerfeltet er sporet, viser historikken, hvem der flyttede kunden til hvem. Masseoverførsler kan stå som én handling med mange poster.
Sammenlægning af dubletter: Den ene post slettes, og dens data flyttes til den anden. Historikken på den slettede post kan følge med eller gå tabt.
Sletning: Slettede poster ligger i papirkurven i en periode, ofte med oplysning om, hvem der slettede. Efter tømning er de normalt kun mulige at finde via leverandørens backup.

Integrationer og automatisering

Mange ændringer i et CRM sker uden en person ved tastaturet: synkronisering med mail og kalender, marketingautomatisering, webformularer, ERP-integration og arbejdsgange, der opdaterer felter ud fra regler. De står ofte med en integrationsbruger eller med den bruger, der byggede automatiseringen. Kortlæg derfor integrationer og automatiseringer, og find ud af, hvilke felter de skriver til, før en ændring tilskrives en person.

Sikring

Gem opsætningen først: sporede felter pr. objekt, opsætningslog, brugere og roller, integrationer og automatiseringer.
Eksportér feltsporingen for de relevante objekter og perioder via API eller rapport med alle kolonner. Kontrollér antal rækker.
Eksportér de berørte poster i deres nuværende form, inkl. papirkurven.
Hent loginhistorik og evt. hændelsesovervågning for de relevante brugere.
Deaktivér frem for at slette brugere, der er relevante for sagen. Sletning kan gøre historikken sværere at koble til personen.
Beregn hashværdier for eksporterne, og notér værktøj og tidspunkt.

Er opbevaringen kort, så tag sikringen nu og ikke efter et møde. Mange CRM-systemer viser kun historik for en begrænset periode, og efter den er data typisk kun mulige hos leverandøren, hvis overhovedet. Den generelle afklaring med leverandøren er beskrevet i SaaS-systemer som datakilde.

Rekonstruktion af en kundeportefølje

Et typisk spørgsmål er, hvilke kunder en bestemt sælger havde på et bestemt tidspunkt, fx dagen før en opsigelse. Det kan rekonstrueres, hvis ejerfeltet var sporet i hele perioden:

Tag udgangspunkt i den nuværende ejer for alle relevante kundeposter.
Gå baglæns gennem historikken for ejerfeltet, og tilbagefør hver ændring efter skæringstidspunktet.
Tilføj poster, der er slettet efter skæringstidspunktet, fra papirkurven eller fra en ældre eksport.
Kontrollér resultatet mod en uafhængig kilde, fx en rapport, der blev sendt rundt på tidspunktet, en ældre backup eller provisionsopgørelser.

Rekonstruktionen er kun så god som historikken. Mangler sporing i en del af perioden, skal det fremgå, og konklusionen skal begrænses til den del, der er dækket.

Sammenhold med andre kilder

CRM-historikken bliver stærkere, når den sammenholdes med spor uden for systemet. En ændring af kundens ejer kort før en fratræden kan kobles til loginhistorikken, til identitetsudbyderens log og til mails, der blev sendt til kunden samme dag. En eksporteret liste kan findes igen på computeren eller i mailen. Hvad virksomheden praktisk gør, når mistanken opstår, er beskrevet i CRM: medarbejderen har eksporteret kundelisten.

Fejlkilder i fortolkningen

En post uden historik kan være uændret, eller feltet kan have været usporet.
“Senest ændret af” er ikke den person, der lavede den relevante ændring.
Tidspunkter vises i brugerens tidszone i brugerfladen, men eksporteres ofte i UTC.
Ændringer fra mobilapps kan blive synkroniseret senere end handlingen.
En ny værdi, der ligner en sletning, kan være en sammenlægning.

Hvad historikken kan og ikke kan bevise

En korrekt sikret feltlog kan vise, hvilken konto der ændrede hvilket felt fra hvad til hvad, og hvornår. Kombineret med opsætningsloggen kan den vise, om sporingen var aktiv. Den kan ikke vise ændringer i usporede felter, og den kan ikke alene vise, hvem der brugte en konto. I sager om provision og kunder ved ophør af et samarbejde kan historikken være central; den juridiske side er beskrevet i Agentur og provisionskrav ved ophør.

Dokumentation

Angiv system, version eller plan, de sporede felter i perioden, eksportmetode, antal rækker, tidszone, hashværdier og de felter, der ikke var sporet. Beskriv også integrationer og automatiseringer, der kunne skrive i de relevante felter, så læseren kan vurdere alternative forklaringer.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: ERP-systemers audit trail teknisk · Containere og Kubernetes: flygtige spor, der skal sikres hurtigt

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · 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