Verksamhetens restlista och den tekniska backloggen samkörda — utanför prototypens omfång, interna fixar inom scope och utredningsfrågor som behöver klarläggas innan bygge.
Stommen följer verksamhetens officiella restlista — punkter som identifierats under sprinten men ligger utanför prototypens omfång. Den kompletteras här av den tekniska backloggen: interna fixar inom prototypens scope och utredningsfrågor som behöver klarläggas innan bygge. Storlek: S / M / L. "Utredning" = klarläggande krävs innan bygge.
Sex punkter som ligger utanför prototypen och tas omhand i fortsatt utveckling.
Strukturerad kommunikation mellan handläggare och medborgare. Omfattar bl.a. handläggarens "kräver komplettering"-meddelande som visas i medborgarens ärende, samt notis via mejl.
Teknisk not BFF:en skickar inga mejl idag — rtj-management/Messaging äger notifieringar. Utred om en notifikation/process-message kan trigga mejl, annars behövs integration mot Messaging-API:et.
Statistikvy för att följa arbetsflödet: antal ärenden per status, handläggningstid, ärenden per handläggare, kö/genomströmning m.m. Beror delvis på R5 (tidsregistrering) och på om alla ärendetyper ligger i samma lista (se Ö2).
Låt AI verifiera att uppladdade dokument verkligen är ett utbildningsintyg resp. en brandskyddskontroll (BSK), integrerat mot ärendehanteringssystemet (Eneo).
Teknisk not Öppen fråga: ska granskningen ske vid uppladdning (synkront, blockerande) eller i processmotorn (asynkront)? Kräver PoC kring modellval, prompt och placering i flödet.
Rutiner och flöde för när sökanden inte är folkbokförd/ägare på fastigheten (t.ex. sommarstuga). I formuläret: "Gäller ansökan annan fastighet?" → ange fastighetsbeteckning → följdfråga "Äger du fastigheten? (ja/nej)" → vid nej, kräv motivering. Ge handläggaren detta som underlag vid manuell granskning.
Registrera nedlagd handläggningstid per ärende, med möjlighet att pausa när ärendet ligger hos sökande för komplettering. Underlag till statistik (R2).
Dra automatiskt tillbaka ett beslut vid adressändring (sökanden flyttar / ändrad folkbokföring) eller vid underkänd brandskyddskontroll (BSK). Mallens villkorstext anger redan att medgivandet upphör vid ägarbyte och kan återkallas vid brister.
Teknisk not Kräver: trigger/övervakning av ändringar + återkallelseflöde + notifiering till medborgaren.
Punkter från den interna sprint-checklistan som ligger inom prototypen men ändå bör åtgärdas.
Admin-chippen ska visa "Ny" för ärenden utan tilldelad handläggare i stället för "Behandlas"/manuell granskning. Statusbaserad + tilldelnings-medveten etikett.
Hela motiveringen ska kunna redigeras (förifylld standardtext, en enda "Motivering"-rubrik, obligatorisk, ingen separat "Beslutstext"). Kräver att mallen renderar motiveringen från en parameter.
Teknisk not Arkitektonisk gaffel: mallen i repot via render/direct vs uppdatera den delade Templating-servern — beslut krävs innan bygge.
Sökfält + filter, bl.a. per "modul"/ärendetyp. Knyter an till R2 och Ö2.
Kontrollera att fastigheten ligger i rätt distrikt (Ånge/Timrå/Sundsvall); annars felmeddelande "fastigheten ligger i fel område". Utred om Lantmäteri-API finns via WSO2.
Läs giltighetsdatum (egensotning-details.validFrom/validUntil) och notifiera medborgaren när beslutet närmar sig utgång. Klargör regel (tillsvidare eller X år). Överlappar delvis R6.
UI-hint i formuläret: användaren kan/ska ändra fastighetsbeteckningen om ansökan inte gäller den som hämtas från Citizen (folkbokföringsadressen). Knyter an till R4.
Skilj tydligt på inskickat vs pågående — vad får medborgaren ändra efter inskick (t.ex. lägga till/uppdatera bilaga vs ändra allt)?