Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

Nedenstående links er interne (indhold i links ikke relevant for eksterne)

https://starwiki.atlassian.net/browse/VIRK-8198

https://starwiki.atlassian.net/browse/VIRK-8882

https://starwiki.atlassian.net/browse/VIRK-5179

https://starwiki.atlassian.net/browse/VIRK-5181

https://starwiki.atlassian.net/browse/VIRK-8732

Indholdsfortegnelse

Afgrænsning af epic

Acceptkriterier

Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader

Oversigt over berørte webservices 

Ingen berørte webservices

Manuel oversigt som er synlig for eksterne

Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår i tabellen.

(kopiér og indsæt manuelt i tabellen)

Automatisk oversigt

Beskrivelse af epic

Baggrund

Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Driften af VITAS skal fra 2025-3 flyttes fra Kyndryl servere (Windows) til STARLight (Docker / Linux i SIT driftsmiljø). Det kræver væsentlige ændringer i det tekniske fundament for VITAS.

Indholdet i denne epic idriftsættes først i Release 2025-3, når alt arbejde med at klargøre VITAS til drift på STARLight er afsluttet. Indholdet i denne epic kan indtil da testes i en container på STARs testmiljø.

Den primære målsætning for denne epic er, at VITAS skal omlægges til drift på STARLight uden unødige risici, herunder i forhold til de ressourcer, som STAR kan stille til rådighed for opgaven i udviklingsperioden. Det betyder at yderligere tiltag til at modernisere VITAS ikke er en målsætning. Fx vil dele af VITAS fortsat blive driftsafviklet med AngularJS, ligesom datamodeller og VITAS' interne arkitektur i al væsentlighed er uændret.

STAR forventer at VITAS skal moderniseres mht. arkitektur og teknologier efter at VITAS er sat i drift på STARLight, i takt med at STAR kan stille ressourcer til rådighed. STAR ønsker mest mulig modernisering i år 2025, hvor der fortsat er bevilling til Moderniseringsprojektet. Modernisering og videreudvikling af VITAS efter idriftsættelse på STARLight er ikke en del af denne epic.

Henviser derudover læser til at gennemgå https://starwiki.atlassian.net/wiki/spaces/ISB/pages/4751982612, da man her kan se planen for, at få VITAS på STARLight opsat i hovedpunkter, der også var udslagsgivende for man fik en igangsættelses accept.

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

Alle forretningsregler og brugerfunktionalitet er uændrede.

Da der er sket væsentlige ændringer i den tekniske implementering, skal der gennemføres en omfattende regressionstest, som omfatter alle brugerrettede / serviceaftagerrettede flows.

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Her beskriver PO overordnet, hvordan epic'en forventes at påvirke aftagerne. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Der vil være både tilsagn og varsling mod aftagere af hhv. WSRM og de endpoints som VITAS udstiller til eksterne aftagere, da disse i forbindelse med idriftsættelse af 2025-3 skal over på tynde WSBer og kalde Getmetoder for at få yderligere data på samtlige ordninger, hvor det As Is ‘kun' er enkelte der er udstillet 'Getmetoder’ for.

Fremfor As Is hvor det ‘kun' er nedenstående ordninger der er på ‘tynde’ WSRMer vil det fra Release 2025-3 være samtlige ordninger der vil være udstillet som 'tynde’ WSBer

Nuværende ordninger der er omfattet af 'tynde' WSRMer

• Fleksjob

• Personlig Assistance

• Mentor

• Jobrotation

• Hjælpemidler

Der er ingen forventede påvirkninger af applikationsbrugerne af VITAS, da der kun er tale om opgradering og delvis udskiftning af det tekniske fundament for VITAS.

1005.31.3.1.1 VITAS applikationen, batchjobs og WebAPI er omlagt til .Net 8 for at klargøre driftafvikles i containers

Internt highlevel acc.kr.

1005.31.3.1.2 VITAS applikationen og webservices driftsafvikles i containers på STARLight

Internt highlevel acc.kr.

1005.31.3.1.3 VITAS kodebase er flyttet til Azure frem for GitHub og pipelines er tilrettet for at tage kode herfra i stedet

Internt highlevel acc.kr.

1005.31.3.1.4 VITAS applikationen gør brug af ny sikkerhedsmodel i form af Login Providers udstillet af IAM - Nemlog-in login (inkluderet FBRS privilegier) omdannet til JWT og adgangsroller

Mangler beskrivelse

1005.31.3.1.5 VITAS applikationen gør brug af ny sikkerhedsmodel i form af Login Providers udstillet af IAM - KOMBIT STS login

Mangler beskrivelse

1005.31.3.1.6 VITAS eksisterende signerings flows med Pen, Upload og MitID er omlagt og kan driftafvikles i container på STARLight

Internt highlevel acc.kr.

1005.31.3.1.7 VITAS webservices er omlagt til REST services og kan driftsafvikles i container med ny sikkerhedsmodel på STARLight

Mangler beskrivelse

1005.31.3.1.8 Eksisterende VITAS webservices der af ovenstående high level acc.kr implementeres, undergår et serviceløft, hvor match på længder, placeringer i snitfladen for de enkelte værdier mv. gennemgås til brugscases herunder ActivityService

Mangler beskrivelse

1005.31.3.1.9 Nye VITAS webservice endpoint udstilles via REST, for at aftagere kan få den data de tidligere fik via 'tyk' WSRM - Dette i tråd med at overgå til 'tynde' WSBer, i forbindelse med omlægningen fra WSRM til WSB

I forlængelse af: 942.1 Overgang til dataudstilling via tynde WSRM beskeder og webservices udstillet direkte i Vitas tilbage fra Release 2019-1, hvor tynde WSRMer blev introduceret, er det i forbindelse med skiftet til SIT / STARLight samt overgangen fra WSRM til WSBer tiltænkt, at omlægge disse resterende tykke WSRMer til tynde WSBer.

For at aftagere stadig kan få den nødvendige data til sagsbehandlingen, vil der blive udstillet tre nye webservices med i alt fire nye webservicemetoder.

1005.31.3.1.10 VITAS WSRM omlægning til tynde WSBer

Mangler beskrivelse

1005.31.3.1.11 VITAS PDF-generering fra hhv. VITAS brugergrænseflade og webserviceudstilling understøttes via containers

Mangler beskrivelse

1005.31.3.1.12 VITAS Ved driftafvikling af VITAS i containers ønskes eksekvering af batchjob blive udført fra containers frem for StoneBranch

Internt highlevel acc.kr.

1005.31.3.1.13 VITAS Ved driftafvikling i containers ønskes eksisterende log, at blive udstillet via Kibana

Internt highlevel acc.kr.

1005.31.3.1.14 VITAS Ved driftafvikling i containers ønskes applikation og webservice tests der blev fjernet / sat til at være ignored i forbindelse med opgraderingen til .Net 8, at blive begrænset kontrolleret genintroduceret (ikke nødvendigvis 1 til 1)

Internt highlevel acc.kr.

1005.31.3.1.15 VITAS Ved driftafvikling i containers ønsker jeg en verifikation i form af en fuld regression test af applikationen, for at være sikker på at .Net 8 'moderniseringen' og skiftet til STARLight er gået godt

Internt highlevel acc.kr.

1005.31.3.1.16 VITAS i forbindelse med ‘moderniseringen' af VITAS gennemgås ‘gamle’ TopDesk/FogBugz sager der er markeret med 'modernisering’

Der vil primært blive fokuseret på Topdesk/FogBugz sager der vedr. snitfladeændringer

STAR har opsamlet en række Fogbugz og TopDesk sager, som vedrører snitfladeændringer på henholdsvis Webservices og WSRMer der fremtidigt skal udstilles som WSBer, og som er blevet skubbet til moderniseringen

PO har været inde og give kommentar og 'gæt' i T-Shirt sizing, i forhold til vurdering af størrelsen af hver enkelt rettelse.

S2312-960 (221074) EAN-nummer mangler i WRSM-besked for hjælpemiddeltillægsbevilling

• Kommentar fra PO: EAN nummer indgår i bevilling og hjælpemidler, men er åbenbart blevet glemt i WSRM

• PO Vurdering: S

• Udvidelse af felt i den overførsel der sker via WSRM ‘As-Is' til at indeholde dette felt, når denne i stedet udstilles som WSB 'To-Be’ når denne epic er idriftsat’, det er en forventning, at vi har dataen, da den fremgår af brugergrænsefladen.

• Open

  

S2403-665 Ophørsdato for fleksjob fra Vitas [snitfladeændring]

• Kommentar fra PO: Ophørsdato skal medtages i WSRM

• PO Vurdering: S

• Open

  

• Det lyder ikke til at der behøver at være snitflade ændringer i denne, men at vi fejlagtigt sender slutdato som enddate, fremfor ophørsdato når den ophører.

  • Schultz skriver: At der virker fint på Virksomhedspraktik men, at der virker anderledes på FleksJob

  • Flere løsninger i spil

  • Uagtet hvilken løsning, er det en forventning at vi har dataen, da man kan gøre det på Virksomhedspraktik, samt at der nedenstående er screenshots fra brugergrænsefladen.

S2408-778 Der er modtaget en del WSRM beskeder i går d. 15/8

• Kommentar fra PO: STAR havde en periode, hvor der blev sendt en bunke af WSRM – (batchjob kører hvert 2. minut). Det skal sikres i moderniseret VITAS, at batchjob kører optimalt. Måske allerede løst.

• PO Vurdering: M

• Denne bør timebokses, eller en foranalyse igangsættes, da man ikke er bekendt med, hvad ‘optimalt’ er, der kan gemme sig alt muligt under denne meget lille, hvis den allerede er løst, til ?, hvis batchjobbet skal laves fundamentalt om, grundet at eksekveringsmønster er forkert så vi ikke kan gøre det optimalt uden at lave helt om på batchjobbet.

S2312-828 (337720) Ønske om fjernelse af feltet 'Evt. særligt CVR nummer som refusionen skal udbetales til [snitfladeændring]

• Kommentar fra PO: Det er ikke logisk, idet at refusion altid skal betales til virksomheden, som ansøger. Derfor skal feltet fjernes.

• PO Vurdering: S

• Har man hørt fagkontoret, evt. jurist om der kunne gemme sig noget, hvorfor dette er muligt i dag? Det er en undring, at det er blevet implementeret, hvis der ikke er noget lovgivning/andet til grund.

• Hvis feltet skal fjernes fra brugergrænsefladen bør dette også fjernes fra eventuelle eksternt udstillede snitflader Webservices / WSRMer ->WSBer

S2312-847 (272031) Ønske om felt/-er til beskrivelse af det bevilgede hjælpemiddel [snitfladeændring] hvor stor er ændring, når vi nu er i gang med at åbne patienten

• Kommentar fra PO: Der indsættes et ekstra felt i Bevilling af Hjælpemidler (ustøttet beskæftigelse) på faneblad 7. Samlet tilskud, og feltindhold skal selvfølgelig med i WSRM. Der skal være begrænsning på feltlængde (samme validering front/backend).

• PO Vurdering: M

• Som det læses ønskes der en tilføjelse af ny tekstboks til brugergrænsefladen, samt tilføjelse af dette til eksternt udstillede snitflader Webservices / WSRMer ->WSBer

• Feltlænger / valideringer mv. bør være de samme.

  • Opgaver:

    • Udvidelse med database felt (feltlængder mv.)

      • Skal den være mandatory?

      • Er det samme tabel for flere ordninger?

      • Skal den kun gælde denne ene ordning?

    • Udvidelse med tekstboks i brugergrænseflade

      • Samme som ovenstående, er det kun på ordningen bevilgede hjælpemidler?

    • Valideringer

    • Tilføjelse af dette til eksternt udstillede snitflader Webservices / WSRMer ->WSBer

S2312-229 (321734) ÆØ VITAS - Personlig assistance. 'Besked til virksomhed' er ikke med i allocation [Snitfladeændring]

• Kommentar fra PO: Det lader til, at man i GetPersonalAssistanceAllocation ikke får feltet ”Besked til virksomhed” med i den tynde WSRM.
  Gælder også Hjælpemidler (ustøttet beskæftiglse) – dvs. ikke tillægsbevillinger.

• PO Vurdering: S x 2

• Man kan argumentere med, at dette ikke bør udstilles i WSRMerne → WSBerne, da der er ønske om at disse forbliver tynde, det er også samme tynde WSB der tiltænktes at sendes på samtlige ordninger, så ved at udvide, grundet to af ordningerne har dette behov, hvor det ikke vil blive udfyldt for de andre ordninger, vil være uhensigtsmæssigt.

S2312-353 (127289) Vitas ÆØ: P-nummer søgning ved Ekstern mentor [Snitfladeændring]

• Kommentar fra PO: Tillægsbevilling (støttet beskæftigelse) @Tanvir: Det skal undersøges, om det kræver meget, at overgå fra CVR til p-nr.

• PO Vurdering: M?

• Har man hørt fagkontoret, evt. jurist om der kunne gemme sig noget, hvorfor dette er muligt i dag? Det er en undring, at det er blevet implementeret, hvis der ikke er noget lovgivning/andet til grund og det i stedet burde have været pNummer.

• Det bør vel være CVR + pNummer, hvis det bør implementeres, så pNummer ikke står alene, at søge på et pNummer kan man potentielt få flere ud på tværs af virksomheder, hvis det er en fritekstsøgning der ønskes.

 S2312-826 (269101) Træffetid i mentorbevilling ønskes ændret til ikke-obligatorisk felt [Snitfladeændring]

• Kommentar fra PO: Ændring af felt fra mandatory til Voluntry for ”Træffetid”.

• PO Vurdering: S

• Er der tale om tabel, der også bruges på andre ordninger, hvor det her ønskes at være optional, hvor det andre steder stadig ønskes at være påkrævet?

• Dette kan potentielt også skabe modstand i Tilsagnet, da aftagere der benytter denne data også skal tilrette deres datagrundlag, til at dette i stedet skal være optional + eventuelle rettelser til deres brugergrænseflader også.

• Opgaver:

  • Ændring af tabel for kolonne

  • Lempelse af valideringsreglerne i brugergrænsefladen

  • NULLable for felt i objektstrukturen

  • Tilrettelse af eksternt udstillede snitflader Webservices / WSRMer ->WSBer

 S2312-355 (130668) ÆØ - Tilskudssats i VITAS tilføjes tykke WSRM beskeder JobOrderNotification [Snitfladeændring]

• Kommentar fra PO: Er det relevant, når vi laver tynde WSRM=WSB?
  KMD har behov for at få tilskudssatsen på løntilskud ifm. CreateActivity, der skal benytte JobOrderPriceHourTypeIdentifyer, såfremt DFDG er opdateret.

• PO Vurdering: M

• JobOrderPriceHourTypeIdentifyer eksistere ikke længere det er i stedet: Borgerindsats.TimetilskudsatsTypeCodeList

• Denne kodeliste bliver brugt i: Borgerindsats.AktivitetService (Version 1 [UDV], 2025-1)

• Er ikke sikker på, at dette er 'rigtigt' lavet. Giver det mening, at vi udstiller kodelisten fra BorgerIndsats, når det er i Vitas at vi ændre på disse tilskudssatser?

• Bliver beskrivelserne i kodelisterne fra Borgerindsats brugt til noget?

  • Som minimum bør man, have en process for, at ved tilrettelse af tilskudssatser, at der skal laves en ændringsanmodning til BorgerIndsats på ændringen af tilskuddet, dette bør også varsles ud til de eksterne, hver gang det gøres, samttidigt med at man ikke bør tilrette satser med ikrafttrædelse, før kodelisten i Borgerindsats er opdateret.

• En mere 'rigtig' løsning, lyder til, at det bør være VITAS der udstiller kodelisten, at kodelisten bliver en DB First kodeliste, samt, at der ligesom ovenstående laves procesændring der tager højde for varslings tider, ved tilrettelse af tilskudssatser, så vi varsler de eksterne aftagere af disse når der sker ændringer

 S2312-841 (269075) VITAS ÆØ- Fleksjobvurdering: Ønske om registrering af decimaltal i 'Jobcenter [Snitfladeændring]

• Kommentar fra PO: Feltet er pt. et heltals felt som skal ændres til decimaltal.

• PO Vurdering: S

• Er der tale om tabel, der også bruges på andre ordninger, hvor det her ønskes at være decimal og at der skal forblive heltal i andre?

• Opgaver:

  • Ændring af tabel for kolonne

  • Ændring af valideringsreglerne i brugergrænsefladen

  • Decimal frem for Int32 for felt i objektstrukturen

  • Tilrettelse af eksternt udstillede snitflader Webservices / WSRMer ->WSBer

 S2312-853 (170798) Ønske om mulighed for at vedhæfte refusionsvejledning i bevilling af personlig assistance

• Kommentar fra PO: Det skal overvejes, om det billigste ikke er at udvide feltet på faneblad 6 under tilskud alternativt genbruge vedhæft dokument (men som dog skal læses af virksomhed og ikke kun af sagsbehandler). CHT skal undersøge nærmere!
  Denne har vel ikke noget med snitflade at gøre men udsendelse af mails (batchjobs?):

• PO Vurdering: M?

 Denne har vel ikke noget med snitflade at gøre men udsendelse af mails:

S2312-907 (301868) Ønske om e-mailadvisering af virksomhed om udløb af bevilling af voksen

• Kommentar fra PO: Der sendes en række mails til virksomheden. Der ønskes suppleret med adviseringsmail ifm. udløb af bevilling af voksenlærling (ligesom ved løntilskud), se også https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2273902830 – se mail nr. 121 løntilskud

• PO Vurdering: S

• Som det læses af ovenstående udsendes der allerede adviseringsmails på løntilskud ifm. udløb, ønsket at at disse også bliver sendt i forbindelse med udløb af voksenlærling.

• Er der tale om den samme email der ønskes sendes?

• Er det den samme database tabel men blot forskellige typer?

 Jeg har en gammel Fogbugzsag, som jeg ikke længere kan finde i Topdesk:

 ??? Hvad ønskes der udføres i ovenstående, så vidt kan udlæses er det at JobAllocationTypeIdentifier mangler i en eller anden WSRM?

S2404-140266 Vitas kontaktperson er ikke rettet med FB 303834 [MUST HAVE]

WSRM tilpasses, således at begge datasæt omkring “Kontaktperson hos Arbejdsgiver” og “Kontaktperson på Arbejdssted” medtages i WSRM på ansøgning og bevilling

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

• DFDG

  • Services

  • WSRMer

  • Kodelister

  • PersonStatusService (PSS) / domænespecifikke statusservices

  • PersonHistoryService (PHS) / domænespecifikke historik services

  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)

• Jobnet

• VITAS

  • Idriftsættes på STARLight i Release 2025-3

  • ErrorCode range for VirksomhedOrdninger vil have det samme ErrorCode range som VITAS (webservices) tidligere havde.

  • Databaser for hhv. Virksomhedsordning (tidligere Vitas webservices), Vitas applikation og Virksomhedsordning.batchjobs (tidligere Vitas.batchjobs) vil være uændrede og disse skal i forbindelse med idriftsættelsen være på STARLight.

  • Webservices vil blive udstillet fra et nyt forretningsdomæne

• JobKon

• JobAG

• JobSearch

• Ydelsesudstilling

• Taxonomy

• BI integrationsplatform

• Alle områder

  • Nye batchjobs

    • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon)

    • Der vil i alt være 21 'nye' batchjobs der vil skulle eksekveres fra STARLight ved idriftsættelsen af Release 2025-3 til forskel for i dag, hvor det er 23 batchjobs på eksisterende platform.

      • De batchjobs der ikke længere vil blive eksekvereter:

        • SendVitasNotificationErrorMessage (allerede 'slukket' med Release 2025-1)

        • BenchmarkUpload (allerede 'slukket' med Release 2025-1)

      • SendVitasNotification vil fremadrettet sende WSBer frem for WSRMer og tanken er at omnavngive dette til SendVirksomhedsordningWsb

  • Dataløft

    • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.

• Kommunalt sagsbehandlingssystem

• A-kasse sagsbehandlingssystem

• Kommunalt bookingsystem

  • WorkForcePlanner (WFP)

  • M4 Booking

  • Schultz Booking

• Kommunalt ydelsessystem (KY)

• Kommunalt sygedagpengesystem (KSD)

Særlige krav til test

• Batchjobs

• bør testes både med delta og fuldt load,

• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden

• bør testes i samarbejde med teams som har afhængigheder

• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres:  

• Skal der køres konvertering:  

• Skal der køres databasescripts for opdatering af tabeller i databasen:  

Efter idriftsættelse:

Her beskriver PO/FA konsekvenser for løsninger efter idriftsættelse, hvis noget afviger fra normale setup.  

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder:  

• Nye snitflader:  

• Nye komponenter:  

• Nye miljøer:  

• Nye teknologier:  

• Nye aftagertyper:  

• Eller afvigelser fra principperne:  

• Eventuelle behov for reduktion af teknisk gæld skal afdækkes:  

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

•  Ja, det er tjekket, at epic ikke indeholder dette.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin