Implementering og drift

Del af Softwaredrift og overvågning

Dokumentér ændringer i automatiske regler

Skriv ændringer i automatiske regler ned med formål, omfang, godkendelse, kontrol og vej tilbage.

Dokumentér en automatisk regel, så en anden ansvarlig kan se formål, ændring, godkendelse og kontrol. Gem både beslutning og teknisk version, hvor muligt. Versionshistorik forklarer ikke nødvendigvis formål eller forventet virkning og bevares ikke altid længe nok.

Beskriv reglen før den ændres

Tag en regel, der tildeler indkomne kundeopgaver til et team. Beskriv udløser, betingelser, handling og undtagelser i almindeligt sprog. Angiv, hvor en sag ender, hvis ingen betingelse passer. Notér regelens ejer og berørte teams.

Beskriv problemet, ændringen skal løse, fx at en bestemt opgavetype sendes til forkert team. Angiv, hvilke sager der skal ændre vej, og hvilke der skal forblive som før. Så kan den faglige ejer vurdere virkningen, før indstillingen ændres.

Felt i ændringsnotatet / Spørgsmål

Formål
Hvilket problem skal ændringen løse?
Omfang
Hvilke poster og brugere kan blive berørt?
Før og efter
Hvilken betingelse eller handling ændres?
Beslutning
Hvem godkendte, og hvornår?
Kontrol
Hvilke kendte tilfælde skal prøves?
Tilbageførsel
Hvem kan standse eller rulle ændringen tilbage?

Kontrollér mere end normalforløbet

Forventet resultat for en almindelig sag, en sag der netop rammer den ændrede betingelse, og en undtagelse uden match. Brug fiktive poster i en egnet prøveopsætning, hvis løsningen tillader det. Kontrollér også beskeder eller ændringer i andre systemer, hvis reglen kan sende dem.

Aftal, hvornår ændringen sættes i drift, og hvem der ser de første relevante sager bagefter. Registrér den version, der faktisk blev aktiveret, og resultatet af kontrollen. Ved en hastende rettelse kan dokumentationen færdiggøres efter indgrebet, men årsag, ansvar og efterfølgende kontrol bør stadig fremgå.

Kend grænsen for produktets historik

Power Automate tilbyder udkast og versionshistorik for løsningsbaserede cloudflows i designeren. En tidligere version kan gendannes som et nyt udkast.

Microsoft oplyser, at udkast udløber efter seks måneder og publicerede versionsposter efter 12 måneder. Brugere af Power Automate bør derfor gemme begrundelse og godkendelse særskilt og planlægge prøveforløbet i en egnet opsætning.

Microsoft Purview kan under dokumenterede forudsætninger vise hændelser som oprettelse, redigering, sletning og ændring af tilladelser for cloudflows. Loggen viser ikke enkelte kørsler eller handlinger under drift. Kontrollér licens, rettigheder og aktiveret audit for det relevante produktionsmiljø, før I regner med loggen. Brug ændringsnotat, versionshistorik og driftskontrol til hver deres spørgsmål.

Versionshistorik og gemmepolitik i Power Automate (Danmark)

Udkast udløber efter
6 måneder
Publicerede versioner bevarer oplysninger i
12 måneder
Auditlog for cloudflows (Microsoft Purview)
Kræver aktiveret audit og rettigheder

Gør notatet brugbart ved næste fejl

Når en opgave begynder at havne forkert, skal en kollega kunne finde den seneste ændring, den tidligere regel, berørte sager og den ansvarlige. Gennemgå notaterne, når regler ændres eller afvikles, så dokumentationen fortsat svarer til den aktive opsætning.

Mere fra Implementering og drift

Implementering og drift

Test gendannelse af nødvendige data

Planlæg en gendannelsesprøve, der kontrollerer data, bilag, relationer, adgang og tiden frem til brugbart arbejde.

Integrationer

Overvåg integrationer, der kan stoppe arbejdet

Se hvilke integrationer der kræver driftskontrol, hvilke signaler der afslører manglende arbejde, og hvem der skal reagere.