Gå till innehållet

Ändra en befintlig modul

Den här guiden beskriver ett rekommenderat arbetssätt när en befintlig modul i DF RESPONS ska ändras.

En modul består ofta av flera delar som är beroende av varandra. Ett nytt eller ändrat fält kan därför påverka:

  • Vyer.
  • NOS-regler.
  • Dokumentmallar och handlingar.
  • E-postmallar.
  • Påminnelser.
  • Sökningar och exporter.
  • Rapporter.
  • Integrationer.
  • Roller och behörigheter.

Det är därför viktigt att planera och testa ändringen som en helhet.

Ändringar kan påverka en modul som redan används

Var särskilt försiktig när ändringar görs i en modul som innehåller befintliga ärenden eller används aktivt i verksamheten.

Testa hela det berörda arbetsflödet innan ändringen tas i bruk.

Förbered ändringen

Börja med att tänka igenom vad som ska ändras och varför.

Dokumentera exempelvis:

  • Vilket behov ändringen ska lösa.
  • Vilka fält som ska läggas till eller ändras.
  • Vilka befintliga ärenden som kan påverkas.
  • I vilka vyer fälten ska visas.
  • Vilka användare och roller som berörs.
  • Om NOS-regler behöver skapas eller ändras.
  • Om dokumentmallar eller e-postmallar påverkas.
  • Om sökningar, exporter eller rapporter påverkas.
  • Hur ändringen ska testas.
  • När ändringen ska börja användas.

Beskriv hela användningsfallet

Beskriv inte bara vilket fält som ska läggas till.

Ange även vem som ska fylla i det, när det ska visas, om det ska vara obligatoriskt och hur informationen ska användas senare i processen.

Kontrollera befintliga data och beroenden

Innan ett befintligt fält eller ett alternativ i ett fält ändras behöver systemförvaltaren kontrollera hur det används.

Ett fält eller fältvärde kan förekomma i:

  • Befintliga ärenden.
  • Vyer.
  • NOS-regler.
  • Dokumentmallar.
  • E-postmallar.
  • Påminnelser.
  • Sökningar.
  • Exportvyer.
  • Rapporter.
  • Integrationer.
  • Relationsfält.
  • Publikationer.

Ta aldrig bort ett fält eller val på fält utan att kontrollera ärendedata

Ett fält eller val på fält (t.ex. alternativ på flervalsfält) ska aldrig tas bort om det inte är helt säkerställt att fältet saknar registrerade värden i samtliga befintliga ärenden.

Om ett fält som innehåller information tas bort kan informationen bli otillgänglig. Fältet kan dessutom användas av andra delar av modulens konfiguration.

Ta endast bort ett fält när det har säkerställts att:

  • Fältet saknar ärendedata.
  • Fältet inte används i någon vy.
  • Fältet inte refereras från någon NOS-regel.
  • Fältet inte används i dokument- eller e-postmallar.
  • Fältet inte används i sökningar, exporter, rapporter eller integrationer.
  • Informationen inte behöver bevaras.

Om det finns osäkerhet bör fältet eller valet på fältet behållas och istället döljas med hjälp av NOS-regler.

Rekommenderad ordning för ändringar

Genomför ändringen i följande ordning:

  1. Skapa eller ändra fält.
  2. Skapa eller uppdatera NOS-regler.
  3. Uppdatera dokumentmallar och e-postmallar.
  4. Lägg till fälten i relevanta vyer.
  5. Kontrollera sökningar, exporter och rapporter.
  6. Testa hela arbetsflödet.
  7. Dokumentera och informera om ändringen.

Ordningen minskar risken för att användarna börjar använda ett nytt fält innan regler, mallar och övrig konfiguration är färdiga.

Skapa eller ändra fält

Börja med att skapa de nya fält som behövs eller uppdatera inställningarna för befintliga fält.

Kontrollera bland annat:

  • Fälttyp.
  • Fältnamn.
  • Beskrivning och hjälptext.
  • Om fältet ska vara obligatoriskt.
  • Om fältet ska vara sökbart.
  • Eventuella standardvärden.
  • Behörighetsinställningar.
  • Fälttypsspecifika inställningar.

Fältet behöver finnas innan det kan användas i NOS-regler, dokumentmallar, e-postmallar och vyer.

Använd tydliga och konsekventa fältnamn

Fältnamnet bör vara begripligt både för användaren och systemförvaltaren.

Undvik flera fält med samma namn då det gör det svårt att veta vilket fält som ska användas i regler och mallar.

Läs mer om fält i avsnittet Fält.

Skapa eller uppdatera NOS-regler

När fälten finns på plats skapas eller uppdateras de NOS-regler som ska styra modulens beteende.

NOS-regler kan exempelvis användas för att:

  • Visa eller dölja fält.
  • Göra fält obligatoriska.
  • Låsa eller låsa upp fält.
  • Sätta eller kopiera värden.
  • Skapa handlingar.
  • Skicka e-post.
  • Ändra ärendets status.
  • Skapa eller koppla andra ärenden.

Kontrollera regelns tre delar:

  • När ska regeln köras?
  • Om vilka villkor ska vara uppfyllda?
  • vad ska systemet göra?

Genom att skapa NOS-reglerna innan fälten läggs till i vyerna finns det avsedda beteendet på plats när fälten blir tillgängliga för användarna.

Testa en avgränsad ändring i taget

Om flera NOS-regler ändras samtidigt kan det bli svårt att avgöra vilken regel som orsakar ett oväntat resultat.

Skapa och testa om möjligt en regel i taget.

Läs mer om NOS-regler i avsnittet Regler.

Hantera tidsstyrda ändringar

Om nya och äldre ärenden ska visa olika information behöver detta hanteras genom NOS-regler som styr fältens synlighet. Om ett fält som inte ska användas längre tas bort i vyn syns det inte heller för redan registrerade ärenden.

Det gäller exempelvis när:

  • Ett äldre fält inte längre ska visas i nya ärenden.
  • Ett nytt fält inte ska visas i äldre ärenden.

NOS-regeln kan exempelvis kontrollera ärendets registreringsdatum eller ett fältvärde och därefter visa eller dölja fältet.

Exempel: nytt fält ska endast visas i nya ärenden

Ett nytt fält för uppföljningsmetod ska endast användas i ärenden som registreras efter att en ny process har införts.

Fältet läggs till i vyn för intern hantering men döljs genom NOS-regler som kontrollerar ärendets registreringsdatum och visar fältet endast för ärenden som registrerats från och med det datum då den nya processen började gälla.

Exempel: äldre fält ska finnas kvar i historiska ärenden

Ett äldre fält ska inte längre användas i nya ärenden men innehåller information i befintliga ärenden.

Fältet tas därför inte bort.

Istället används en NOS-regel som:

  • Visar fältet i äldre ärenden.
  • Döljer fältet i ärenden som registrerats efter att den nya processen infördes.

Använd inte borttagning för att skilja mellan gamla och nya ärenden

Om gamla och nya ärenden ska visa olika information bör detta hanteras genom NOS-regler.

Att ta bort ett fält eller ett alternativ påverkar även historisk information och är därför inte ett lämpligt sätt att ändra formuläret för nya ärenden.

Uppdatera dokumentmallar

Om det nya eller ändrade fältets värde ska visas i en handling behöver berörda dokumentmallar uppdateras.

Kontrollera:

  • Att rätt fält används.
  • Att rätt referenstagg har lagts in.
  • Att lämplig taggvariant används för fälttypen.
  • Att rubriker och förklaringar är aktuella.
  • Att villkorad text fungerar.
  • Att tomma värden hanteras korrekt.
  • Att dokumentets layout och formatering är korrekt.
  • Att rätt NOS-regel skapar handlingen.

Handlingar är ögonblicksbilder

En handling innehåller de uppgifter som ärendet hade när handlingen skapades.

Om ett värde senare ändras i ärendet uppdateras inte den befintliga handlingen. En ny handling behöver skapas för att innehålla det nya värdet.

Läs mer om dokumentmallar i avsnittet Dokumentmallar.

Skapa en provhandling

Skapa en ny handling i ett testärende och kontrollera:

  • Att handlingen skapas vid rätt tillfälle.
  • Att samtliga fältvärden visas.
  • Att tomma värden hanteras korrekt.
  • Att rubriker och formatering är korrekta.
  • Att villkorad text fungerar.
  • Att äldre handlingar inte har förändrats.

Läs mer om handlingar i avsnittet Handlingar.

Uppdatera e-postmallar

Kontrollera om det nya eller ändrade fältet ska användas i en e-postmall.

Kontrollera:

  • Ämnesrad.
  • Meddelandetext.
  • Referenstaggar.
  • Mottagare.
  • Avsändare.
  • Svarsmottagare.
  • Länkar till ärendet eller Mina sidor.
  • Villkor för när meddelandet ska skickas.
  • Vilken NOS-regel som skickar meddelandet.

Skicka ett testmeddelande och kontrollera resultatet i den mottagna e-posten.

Kontrollera mottagarna vid test

Använd testadresser när mallar och NOS-regler som skickar e-post provas.

Säkerställ att testmeddelanden inte skickas till verkliga ärendeparter eller andra mottagare av misstag.

Lägg till fältet i relevanta vyer

När fält, NOS-regler, dokumentmallar och e-postmallar är färdiga läggs fältet till i de vyer där det ska användas.

Kontrollera samtliga relevanta vytyper:

  • Extern registrering.
  • Intern registrering.
  • Intern hantering.
  • Intern ärendeöversikt.
  • Intern utskrift.
  • Intern export.
  • Publikation.
  • Intern gallring.

För varje vy behöver systemförvaltaren kontrollera:

  • Om fältet ska visas.
  • Var fältet ska placeras.
  • Om användaren ska kunna redigera fältet.

Lägg till fältet i vyerna sist

Genom att lägga till fältet i vyerna sist minskar risken för att användarna börjar använda fältet innan tillhörande regler och mallar är färdiga.

Läs mer om vyer i avsnittet Vyer.

Kontrollera sökningar, exporter och rapporter

Ta ställning till om fältet ska användas i:

  • Sökningar.
  • Ärendeöversikter.
  • Excel-exporter.
  • Utskrifter.
  • Rapporter.
  • Power BI eller andra statistiklösningar.

Om fältet ska kunna användas som sökfilter behöver fältet vara konfigurerat som sökbart.

Om fältet ska exporteras behöver det läggas till i relevant vy av typen Intern export.

Befintliga ärenden kan sakna värde

Ett nytt fält saknar normalt värde i ärenden som skapades innan fältet lades till.

Ta hänsyn till detta i NOS-regler, dokumentmallar, sökningar, exporter och rapporter.

Kontrollera roller och behörigheter

Kontrollera om ändringen påverkar roller eller rättighetsregler.

Kontrollera exempelvis:

  • Vilka roller som ska kunna läsa eller ändra informationen.
  • Vilka användare som ska vara valbara i användarfält.
  • Vilka roller som ska få e-post eller påminnelser.
  • Om vyernas rollstyrning fortfarande är korrekt.
  • Om Publik användare behöver rättigheter vid extern registrering.
  • Om testanvändare har rätt behörigheter för kvalitetssäkringen.

Testa ändringen

Testa hela det berörda arbetsflödet med representativa användarkonton och roller.

Använd om möjligt en testenhet och testärenden.

Testa registrering

Kontrollera:

  • Extern registrering.
  • Intern registrering.
  • Obligatoriska fält.
  • Standardvärden.
  • Hjälptexter och informationstexter.
  • Felmeddelanden och validering.

Testa handläggningen

Kontrollera:

  • Att rätt vy visas för respektive roll.
  • Att fält visas vid rätt tillfälle.
  • Att fält döljs i ärenden där de inte ska visas.
  • Att användaren kan ändra rätt fält.
  • Att låsta fält inte kan ändras.
  • Att NOS-regler körs i rätt ordning.
  • Att status och andra fältvärden uppdateras korrekt.

Testa tidsstyrda ändringar

Kontrollera:

  • Ett ärende som registrerades före brytdatumet.
  • Ett ärende som registrerades efter brytdatumet.
  • Att äldre fält visas i rätt historiska ärenden.
  • Att nya fält visas i rätt nya ärenden.
  • Att historiska värden finns kvar.
  • Att nya värden inte krävs i äldre ärenden.

Testa utdata och kommunikation

Kontrollera:

  • Handlingar.
  • E-postmeddelanden.
  • Påminnelser.
  • Utskrifter.
  • Excel-exporter.
  • Rapporter.

Testa olika användare och ärenden

Testa:

  • Ett nytt ärende som skapas efter ändringen.
  • Ett befintligt ärende som skapades före ändringen.
  • Ärenden med olika statusar och fältvärden.
  • Ärenden på olika organisatoriska enheter.
  • Användare med olika roller och behörigheter.

Testa inte bara som systemadministratör

Ett systemadministratörskonto har ofta mer omfattande behörigheter än verksamhetens användare.

Testa därför även med konton som motsvarar de roller som ska använda modulen.

Kontrollera ärendeloggen

Använd ärendeloggen för att kontrollera att systemet har utfört de förväntade aktiviteterna.

Loggen kan exempelvis visa:

  • Att fältvärden har ändrats.
  • Att ett e-postmeddelande har skickats.
  • Att en handling har skapats.
  • Vem som utförde en viss åtgärd.

Informera användarna

Om ändringen påverkar verksamhetens arbetssätt bör berörda användare informeras innan ändringen tas i bruk.

Informationen bör beskriva:

  • Vad som har ändrats.
  • Varför ändringen har gjorts.
  • När ändringen börjar gälla.
  • Vilka användare som berörs.
  • Om användaren behöver arbeta på ett nytt sätt.
  • Var uppdaterad dokumentation finns.