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.

