Specifikation

Bakgrund och syfte

Vklass används som gemensam lär‑ och kommunikationsplattform för flera skolformer, enheter och roller inom en kommun eller organisation. Användarkonton skapas och uppdateras i huvudsak genom synkronisering mot bakomliggande verksamhetssystem (t.ex. elev-, personal- och vårdnadshavarregister), men kompletteras ofta med manuellt skapade konton (t.ex. praktikanter, konsulter, tillfälliga vikarier eller elever med TF‑nummer). Detta leder till en komplex livscykel för användarkonton där flera källor, roller och identitetstyper behöver hanteras konsekvent och säkert.

Samtidigt skärps kraven på informationssäkerhet och dataskydd. Vklass hanterar känsliga och integritetskänsliga uppgifter, såsom frånvaro, bedömningar, åtgärdsprogram, kommunikation mellan hem och skola samt uppgifter om skyddade personuppgifter. Organisationerna har att följa både GDPR (bland annat principer om dataminimering, riktighet och gallring), nationell lagstiftning och lokala gallringsplaner, liksom Integritetsmyndighetens vägledning kring hantering av skyddade personuppgifter i skolan. Därutöver ställs ökade krav på stark autentisering och begränsning av åtkomst, särskilt för användare med högre behörigheter, såsom organisations‑ och skoladministratörer.

Mot denna bakgrund finns ett behov av mer avancerade, men ändå kontrollerade, verktyg för organisationsadministratörer att själva kunna hantera användarkonton i Vklass på organisationsnivå, utan beroende av manuella specialrutiner eller återkommande supportärenden till Vklass. I dag är möjligheterna begränsade att på ett konsekvent sätt:

• ta bort eller inaktivera konton så att de inte oavsiktligt återaktiveras av synkronisering,
• slå ihop dubbla konton som uppstått genom ändrade personuppgifter (t.ex. nytt personnummer) eller olika registreringssätt (synkroniserat konto + manuellt konto),
• tillfälligt blockera eller bryta specifika relationer (t.ex. vårdnadshavare–barn) när verksamheten fattat beslut som ännu inte, eller aldrig, återspeglas i källsystemet,
• hantera manuellt skapade konton, TF‑nummer, fiktiva personuppgifter och andra avvikande identiteter på ett enhetligt sätt över tid.

Detta skapar konkreta problem i verksamheten, till exempel:

• dubbla konton för samma person med olika inloggningssätt, där personal och elev inte ser samma information,
• felaktiga eller kvarhängande behörigheter som ger användare åtkomst de inte längre ska ha,
• svårigheter att följa beslut om att begränsa en vårdnadshavares åtkomst till ett barn, trots att folkbokföringen är oförändrad,
• osäkerhet kring vilken data som faktiskt finns kvar i Vklass efter att en användare ”tagits bort” i verksamhetssystemet,
• manuell hantering av särskilda fall (t.ex. skyddad identitet eller fingerade uppgifter) där systemet inte självt kan avgöra situationens karaktär.

En särskild utmaning gäller konton där personuppgifterna avviker från normal struktur, t.ex. TF‑nummer, personer utan svenskt personnummer eller konton med fingerade uppgifter. För dessa fall kan Vklass inte avgöra om det rör sig om skyddad identitet, tillfällig registrering eller andra särskilda omständigheter. Funktionaliteten behöver därför vara generell och kunna användas för samtliga användartyper (elev/barn, personal, vårdnadshavare) oavsett hur kontot har skapats eller vilket identitetsunderlag som används.

Syftet med den utökade användarhanteringen är att etablera ett sammanhållet, säkert och spårbart ramverk för livscykelhantering av användarkonton i Vklass. Funktionen ska:

• ge organisationsadministratörer möjlighet att radera, sammanslå och spärra konton på ett kontrollerat sätt, med tydlig koppling till bakomliggande verksamhetssystem,
• säkerställa att radering och inaktivering inte oavsiktligt motverkas av synkroniseringen, t.ex. genom att införa karenstider, spärrlistor och kontroller mot källsystemet innan radering genomförs,
• möjliggöra både standardiserad radering med karenstid och omedelbar radering när det är verifierat att personen inte längre ska förekomma i Vklass och/eller i källsystemet,
• stödja blockering av inläsning för en hel person eller specifika relationer (t.ex. vårdnadshavare–barn), så att verksamhetens beslut om åtkomst kan upprätthållas även när källsystemets struktur är oförändrad,
• hantera både synkroniserade och manuellt skapade konton på ett enhetligt sätt, inklusive konton med TF‑nummer, fingerade personuppgifter eller andra alternativa identiteter.

För att samtidigt minska risken för felaktiga åtgärder krävs ett kontrollerat flöde med tydlig återkoppling till administratören. Detta innefattar bland annat:

• karenshantering där ett konto först markeras för radering och endast raderas permanent om användaren inte återkommer i synkroniseringsunderlaget under en definierad period,
• möjlighet att ångra planerad radering inom karenstiden,
• tydlig information om att en användare har återkommit i synkroniseringen under karensperioden, vilket förhindrar att raderingen genomförs,
• mekanismer för att säkerställa att konton som fortfarande är aktiva i källsystemet inte oavsiktligt tas bort.

Därutöver behöver alla avancerade åtgärder kring konton – radering, sammanslagning, spärr av inläsning och ändring av relationer – vara spårbara utan att lagra mer personuppgifter än nödvändigt. Det innebär att systemet ska logga:

• vilken åtgärd som vidtagits,
• när den genomfördes,
• av vilken administratör,
• vilka konton eller relationer som berörts,

samtidigt som loggarna begränsas i innehåll (t.ex. endast delar av personnummer, grundläggande identitetsuppgifter och organisatorisk tillhörighet) och lagras under en tidsbegränsad period i linje med dataminimering och lokala gallringsregler.

Sammanfattningsvis är syftet med den utökade användarhanteringen att:

• ge organisationsadministratörer ändamålsenliga och enhetliga verktyg för avancerad hantering av användarkonton i hela organisationen, utan beroende av Vklass support,
• minska risken för obehörig åtkomst genom att felaktiga, dubbla eller inaktuella konton och relationer kan identifieras, justeras och avslutas på ett kontrollerat sätt,
• stärka efterlevnaden av GDPR och lokala gallringsplaner genom tydliga funktioner för radering, karens, spärrlistor och loggning,
• säkerställa att både synkroniserade och manuellt skapade konton, inklusive konton med TF‑nummer eller andra avvikande identiteter, hanteras på ett konsekvent sätt under hela sin livscykel,
• skapa en stabil grund för fortsatt utveckling av gallrings‑, inaktiverings‑ och livscykelfunktioner kopplade till användare i Vklass.

Mål och icke-mål

Funktionen för utökad användarhantering ska ge organisationsadministratörer ett samlat, säkert och kontrollerat stöd för avancerad livscykelhantering av användarkonton i Vklass på organisationsnivå. Tyngdpunkten ligger på särskilda eller avvikande situationer där standardflödena via synkronisering från elev‑, personal‑ eller vårdnadshavarregister inte är tillräckliga. Funktionen är ett komplement till ordinarie användaradministration, inte en ersättning för den.

De övergripande målen är att organisationsadministratören på ett spårbart och dataskyddsanpassat sätt ska kunna:

• Radera användarkonton kontrollerat

  • Markera ett konto för radering med en standardiserad karenstid (t.ex. 48 timmar), där kontot tydligt får en särskild status (t.ex. ”Markerad för radering”).
  • I samband med att kontot markeras för radering få en översikt på hög nivå över vilken typ av data i Vklass som berörs (t.ex. kurs‑ och klasskopplingar, roller, meddelanden, närvaro‑ och resultatdata), utan att visa mer innehåll än nödvändigt.
  • Efter avslutad karenstid låta systemet permanent radera kontot och dess kopplingar automatiskt, under förutsättning att användaren inte förekommit i synkroniseringsunderlaget under hela karensperioden.
    • Exempel: en elev som slutat och tagits bort ur elevregistret, men där kontot behöver raderas i Vklass i enlighet med kommunens gallringsregler.
  • Genomföra omedelbar radering (utan karens) när organisationsadministratören uttryckligen bekräftat att personen inte längre finns i relevanta verksamhetssystem och inte ska kunna återkomma i Vklass.
    • Exempel: ett manuellt skapat testkonto eller ett felregistrerat konto med felaktigt personnummer.
  • I samtliga raderingsfall göra en systematisk kontroll mot verksamhetssystemet/synkroniseringen innan raderingen slutförs, så att aktiva personer inte oavsiktligt tas bort.
  • Kunna ångra en planerad radering under pågående karenstid (d.v.s. innan den permanenta raderingen har genomförts).

• Hantera dubbletter genom sammanslagning av konton

  • Sammanslå två konton som tillhör samma fysiska person, oavsett om det rör sig om elev/barn, personal eller vårdnadshavare.
    • Exempel: ett synkroniserat lärarkonto och ett äldre manuellt konto som läraren tidigare använt.
  • Säkerställa att relevant historik och kopplingar i Vklass (t.ex. undervisningsgrupper, resultat, bedömningar, meddelanden och vårdnadshavarkopplingar) så långt som möjligt följer med till det kvarvarande kontot.
  • Genomföra sammanslagningen på ett sätt som minimerar risken för:
    • felaktiga eller dubbla behörigheter,
    • oavsiktlig förlust av data eller relationskopplingar,
    • oklarhet kring vilket konto som ska användas framåt (det ska finnas ett tydligt ”huvudkonto”).

• Spärra inläsning via synkronisering

  • Lägga upp en person på en spärrlista så att synkroniseringen inte längre kan ny‑skapa eller återaktivera kontot i Vklass, även om personen fortsatt finns i elev‑ eller personalsystemet.
    • Exempel: ett tillfälligt manuellt konto som inte längre ska förekomma, oavsett framtida synkronisering.
  • Spärra inläsning för samtliga roller (elev/barn, personal, vårdnadshavare) på ett enhetligt sätt.
  • För vårdnadshavare kunna:
    • spärra hela vårdnadshavarkontot (ingen åtkomst till något barn i Vklass), eller
    • endast spärra en specifik relation mellan en vårdnadshavare och ett visst barn (vårdnadshavare–barn‑koppling), samtidigt som övriga relationer för samma vårdnadshavare fortsätter fungera som vanligt.
      • Exempel: en vårdnadshavare som enligt beslut inte ska ha digital åtkomst till ett visst barn, men fortsatt ska ha åtkomst till ett syskon.
  • Integrera spärrhanteringen med raderings‑ och sammanslagningsflödena, så att spärrade användare eller relationer inte oavsiktligt återkommer via framtida synkronisering.

• Arbeta konsekvent oavsett kontotyp och identitetstyp

  • Tillämpa samma principer och flöden för både:
    • synkroniserade konton (från elev‑, personal‑ och vårdnadshavarregister), och
    • manuellt skapade konton (t.ex. praktikanter, konsulter, tillfälliga vikarier, TF‑nummer eller fiktiva konton).
  • Stödja hantering av konton med TF‑personnummer, saknat svenskt personnummer eller andra alternativa identiteter – utan att systemet försöker tolka om det rör sig om skyddad identitet eller annan särskild status.
  • Erbjuda en enhetlig sök‑ och urvalsbild för att hitta användare, exempelvis:
    • personnummer (eller motsvarande identitetsnyckel),
    • namn, enhet, skolform, klass/avdelning,
    • vårdnadshavare via koppling till elev/barn.

• Säkerställa spårbarhet med dataminimering

  • Logga alla centrala åtgärder kopplade till radering, sammanslagning och spärrning av konton och relationer, inklusive:
    • åtgärdstyp (t.ex. ”konto markerat för radering”, ”konto sammanslaget”, ”relation vårdnadshavare–barn spärrad”),
    • tidpunkt för åtgärden,
    • ansvarig organisationsadministratör,
    • vilka konton eller relationer som berörts (på ett identifierbart men dataminimerat sätt).
  • Begränsa mängden personuppgifter i loggarna till det som är nödvändigt för spårbarhet och uppföljning, t.ex.:
    • endast de sex första siffrorna i personnumret eller annan pseudonymiserad identitet,
    • förnamn/initialer och organisatorisk tillhörighet (skola/enhet) efter genomförd radering.
  • Gallra loggarna automatiskt efter en fastställd, relativt kort period (t.ex. 30 dagar eller enligt överenskommen standard), i linje med principen om dataminimering och gällande gallringsregler.

Genom ovanstående ska funktionen:

• förhindra att felaktiga, dubbla eller inaktuella konton och relationer lever vidare eller återskapas via synkronisering,
• ge stöd för att hantera komplexa undantagsfall på ett likartat, dokumenterat och reviderbart sätt över hela organisationen,
• bidra till att uppfylla krav på dataminimering, gallring och behörighetsstyrning utan att verksamheten behöver involvera Vklass support i varje enskilt ärende,
• skapa en stabil grund för vidare utveckling av mer generella gallrings‑ och inaktiveringsfunktioner kring personuppgifter i Vklass.

---

Följande ligger uttryckligen utanför scope för denna funktionalitet:

• Automatisk identifiering eller särskild hantering av skyddad identitet
  Systemet kommer inte att försöka avgöra, flagga eller särskilt klassificera om en person har skyddad identitet, sekretessmarkering eller fingerade personuppgifter. TF‑personnummer, alternativa identiteter och manuellt skapade konton behandlas tekniskt som vanliga konton och omfattas av samma funktioner och regler.

• Direkt påverkan på bakomliggande verksamhetssystem
  Funktionen kommer inte att:

  • uppdatera, radera eller på annat sätt påverka data i elev‑, personal‑ eller vårdnadshavarregister eller andra källsystem,
  • styra hur användare skapas, avslutas eller hanteras i dessa system.
    All påverkan är begränsad till Vklass interna datamodell och hur Vklass tolkar och synkroniserar in data från verksamhetssystemen.

• Generell, regelbaserad massgallring av all personrelaterad data
  Funktionen inför inte en fullständig gallringsmotor för automatiska, tidsstyrda gallringar av alla typer av personuppgifter i Vklass (t.ex. central konfiguration av gallringsregler per skolform/enhet och schemalagd körning för hela databeståndet). Fokus är på:

  • hantering av enskilda konton och relationer,
  • riktade åtgärder i specifika fall där standardflöden inte räcker.

• Övergripande förändringar i behörighets‑ och rollsystemet
  Funktionen:

  • förändrar inte vilka roller som i övrigt kan se fullständiga personnummer eller annan känslig information i Vklass,
  • inför inga nya generella behörighetsnivåer eller rolltyper utöver att själva funktionen för utökad användarhantering begränsas till organisationsadministratörer (och eventuellt andra särskilt utsedda roller enligt separat beslut).

• Hantering eller registrering av verksamhetens beslut
  Funktionen:

  • registrerar inte juridiska eller verksamhetsmässiga beslut (t.ex. från socialtjänst, domstol eller nämnd),
  • tolkar inte gall

Definitioner och begrepp

Följande begrepp används konsekvent i denna specifikation och utgör grund för beskrivningen av flöden, datamodeller och behörighetslogik.

Organisationsadministratör / Org‑admin
Avser den behörighetsroll i Vklass som har övergripande administratörsrättigheter på organisationsnivå (t.ex. kommun, huvudman eller motsvarande). En org‑admin kan se och hantera användare över flera enheter/skolor inom samma organisation.

Inom ramen för denna specifikation är det endast org‑admin (och eventuellt andra uttryckligen utsedda systemnära roller enligt separat beslut) som har åtkomst till den utökade användarhanteringen, det vill säga funktioner för:

• radering av användarkonton,
• sammanslagning av konton,
• spärrning av inläsning (på kontonivå eller relationsnivå).

Verksamhetssystem / Källsystem
Gemensam benämning för de system utanför Vklass som är ”ägare” av grunddata om personer och deras organisatoriska kopplingar, t.ex.:

• elevregister/elevadministrativa system,
• personaladministrativa system,
• vårdnadshavarregister eller motsvarande.

Vklass hämtar normalt användare, roller (elev/barn, personal, vårdnadshavare) och relationer (t.ex. elev–klass, vårdnadshavare–barn) från dessa system genom synkronisering. Den utökade användarhanteringen påverkar aldrig dessa system eller deras data, utan styr enbart:

• hur Vklass tolkar inläst data,
• om och hur inläst data ska resultera i konton och relationer i Vklass.

Synkronisering / Synkroniseringsunderlag
Med synkronisering avses den automatiska, återkommande inläsningen av data från verksamhetssystemen till Vklass.

Med synkroniseringsunderlag avses den datafil eller ström av uppgifter som vid varje körning anger:

• vilka personer som ska finnas i Vklass,
• vilka roller dessa personer ska ha (elev/barn, personal, vårdnadshavare),
• vilka relationer som ska finnas (t.ex. till skola, klass, barn).

Synkroniseringsunderlaget utgör referens vid kontroller i samband med:

• radering (för att undvika att aktiva personer tas bort),
• karenshantering (för att avgöra om en markerad användare återkommer under karenstiden),
• spärrhantering (för att blockera ny‑ eller återupprättande av konton eller relationer).

Användarkonto
En unik, inloggningsbar identitet i Vklass kopplad till en fysisk person. Ett användarkonto kännetecknas typiskt av:

• en primär identitetsnyckel (t.ex. personnummer, TF‑nummer eller annan identifierare),
• ett eller flera inloggningssätt (t.ex. Vklass‑inloggning, SSO, BankID),
• en eller flera roller i Vklass (elev/barn, personal, vårdnadshavare),
• kopplingar till organisatoriska enheter och relationer (t.ex. skola, klass, barn).

När specifikationen talar om att ”radera ett konto” avses hela denna användaridentitet i Vklass, inklusive dess kopplingar och den historik som tekniskt och juridiskt kan knytas till kontot.

Roller (elev/barn, personal, vårdnadshavare)
De huvudsakliga användarkategorierna i Vklass:

• Elev/Barn: Personer som deltar i verksamheten som elev, barn eller studerande i någon skolform eller förskoleverksamhet.
• Personal: Medarbetare i skola, förskola eller annan enhet (t.ex. lärare, rektor, administratör, elevhälsopersonal).
• Vårdnadshavare: Personer som har vårdnad eller motsvarande ansvar för ett eller flera barn i verksamheten.

Ett och samma användarkonto kan, i vissa fall, inneha flera roller (t.ex. personal som även är vårdnadshavare i samma kommun). Den utökade användarhanteringen ska fungera likvärdigt oavsett vilken eller vilka av dessa roller kontot har.

Relation vårdnadshavare–barn
En explicit koppling i Vklass mellan ett vårdnadshavarkonto och ett elev/barn‑konto. En vårdnadshavare kan ha en eller flera relationer, t.ex.:

• vårdnadshavare – barn A,
• vårdnadshavare – barn B (syskonrelation), osv.

Denna specifikation beskriver funktionalitet där:

• en hel vårdnadshavare kan spärras (ingen åtkomst till något barn), eller
• en specifik relation vårdnadshavare–barn kan spärras eller tas bort, medan andra relationer för samma vårdnadshavare fortsätter fungera.

Exempel: En vårdnadshavare som enligt beslut inte ska ha digital åtkomst till barn A, men fortsatt ska ha åtkomst till barn B.

Manuellt skapat konto
Användarkonto som har skapats direkt i Vklass av en administratör, utan underlag från synkronisering. Detta används exempelvis för:

• praktikanter, konsulter och tillfälliga vikarier,
• personer utan svenskt personnummer,
• elever med TF‑nummer eller annan tillfällig/fiktiv identitet,
• särskilda undantagsfall där källsystemet inte innehåller personen.

Manuella konton kan i denna specifikation:

• raderas,
• sammanslås med andra konton,
• omfattas av spärrning på samma sätt som synkroniserade konton.

Synkroniserat konto
Användarkonto som har skapats och/eller uppdateras med data från ett eller flera verksamhetssystem via synkronisering. För ett synkroniserat konto gäller att:

• källsystemet i praktiken är ”master” för grunddata (t.ex. namn, personnummer, organisatorisk tillhörighet),
• kontot riskerar att återaktiveras eller återskapas om personen fortsatt förekommer i synkroniseringsunderlaget.

Därför krävs särskilda kontroller och spärrmekanismer innan radering eller borttagning av relationer genomförs.

TF‑nummer / TF‑personnummer
Ett tillfälligt eller fiktivt personnummer som ofta följer strukturen ååmmdd‑TFnn, t.ex. 120813‑TF21. I denna specifikation behandlas TF‑nummer som en teknisk identitetsnyckel i personnummerfältet, utan att Vklass:

• drar slutsatser om skyddad identitet,
• försöker avgöra vilken typ av särskild sekretess eller registreringssituation som föreligger.

Ett konto med TF‑nummer kan representera t.ex.:

• en elev utan svenskt personnummer,
• en elev med fingerade uppgifter,
• ett fall där verkliga personuppgifter inte ska användas i Vklass.

Avvikande identitet
Samlande term för identitetskonfigurationer som avviker från ”standardfallet” (svenskt personnummer + synkroniserat konto), t.ex.:

• TF‑nummer eller andra fiktiva personnummer,
• personer helt utan svenskt personnummer,
• aliasuppgifter eller fingerade personuppgifter,
• rent manuellt skapade identiteter som inte finns i källsystemen.

Systemet gör ingen egen tolkning av om en avvikande identitet är kopplad till t.ex. skyddad folkbokföring, sekretessmarkering eller fingerade personuppgifter. Funktionen för utökad användarhantering ska tekniskt kunna hantera dessa konton på samma sätt som andra konton.

Markera för radering
En administrativ åtgärd där ett konto:

• inte raderas omedelbart,
• utan läggs in i ett planerat raderingsflöde med en definierad karenstid.

Under perioden då kontot är markerat för radering:

• får kontot en tydlig status (t.ex. ”Markerad för radering”),
• gäller särskilda regler för hur kontot visas och kan användas,
• kan org‑admin ångra åtgärden och ta bort kontot från raderingslistan,
• kontrolleras löpande om användaren förekommer i synkroniseringsunderlaget.

Exempel: En elev som avslutats i elevregistret markeras för radering i Vklass. Om eleven åter skulle dyka upp i synkroniseringsunderlaget under karenstiden stoppas den planerade raderingen.

Karenstid / Karenstidsfönster
En tidsperiod (t.ex. 48 timmar eller enligt konfigurerad standard) mellan:

• tidpunkten då ett konto markeras för radering, och
• tidpunkten då permanent radering faktiskt genomförs.

Under karenstiden gäller att:

• kontot endast får raderas permanent om det inte förekommer i synkroniseringsunderlaget under hela perioden,
• org‑admin kan ångra och avbryta den planerade raderingen,
• upptäckt förekomst i synkroniseringen ska förhindra eller skjuta upp raderingen.

Karenstiden fungerar därmed som ett skydd mot felaktig radering av konton som fortfarande är aktiva eller som tillfälligt felaktigt bedömts som avslutade.

Direkt radering
En omedelbar och permanent borttagning av ett användarkonto utan föregående karenstid. Direkt radering får endast:

• genomföras efter uttrycklig bekräftelse från org‑admin,
• ske när det är verifierat att personen inte längre förekommer i relevanta verksamhetssystem och inte ska kunna återkomma i Vklass.

Exempel på lämpliga fall för direkt radering:

• ett felaktigt skapat testkonto,
• ett konto med uppenbart felaktigt personnummer,
• ett rent manuellt konto för en tillfällig konsult där organisationen säkerställt att personen aldrig ska finnas i källsystemen.

Direkt radering ska betraktas som ett undantag och ska alltid föregås av kontroll mot synkroniseringsunderlaget.

Spärra inläsning
En åtgärd som innebär att Vklass instrueras att ignorera eller blockera viss data från synkroniseringsunderlaget. Spärren kan avse:

• en hel person (hela användarkontot, oavsett roll), eller
• en specifik relation (t.ex. vårdnadshavare–barn).

Effekten av att spärra inläsning är att:

• nya konton inte skapas för den spärrade personen,
• befintliga konton inte återaktiveras,
• spärrade relationer inte återupprättas – även om de fortfarande finns i källsystemet.

Spärren ändrar aldrig källdata, utan endast hur Vklass tolkar och omsätter synkroniseringsunderlaget.

Spärrlista
En särskild struktur i Vklass där poster som är spärrade från inläsning registreras. Spärrlistan kan innehålla:

• personbaserade spärrar (gäller hela kontot oavsett roll eller enhet),
• relationsbaserade spärrar (gäller specifika kopplingar, t.ex. vårdnadshavare–barn).

Vid varje synkroniseringskörning:

• kontrolleras om inkommande poster finns i spärrlistan,
• blockeras i så fall skapande eller återaktivering av kontot eller relationen.

Exempel: En vårdnadshavare–barn‑relation som enligt beslut inte ska finnas i Vklass läggs in i spärrlistan. När synkroniseringen senare försöker återskapa relationen (eftersom den finns kvar i folkbokföringsunderlaget) ignoreras den.

Sammanslagning av konton / Slå ihop konton
En kontrollerad åtgärd där två användarkonton som avser samma fysiska person förs samman till ett kvarvarande ”huvudkonto”. Processen omfattar typiskt:

• val av vilket konto som ska vara målkonto (primärt konto),
• flytt eller konsolidering av relevanta kopplingar och historik till målkontot,
• avslut/radering av det andra kontot efter genomförd sammanslagning.

Exempel:

• Ett äldre, manuellt skapat lärarkonto slås samman med det nya, synkroniserade lärarkontot för samma person. Undervisningsgrupper, bedömningar och meddelanden samlas så långt möjligt på det synkroniserade kontot.

Målet är att:

• minska antalet dubbla konton,
• säkerställa att verksamheten använder ett enhetligt konto framåt,
• undvika onödiga eller felaktiga behörighetskombinationer.

Historik (kontohistorik)
Samlad benämning på data i Vklass som kan knytas till en användare, t.ex.:

• inlägg, kommentarer och meddelanden,
• närvaro- och frånvarodata,
• resultat, omdömen och bedömningar,
• uppladdade filer och inlämningar,
• loggar över vissa händelser och interaktioner.

Vid sammanslagning av konton är utgångspunkten att relevant historik:

• så långt tekniskt möjligt kopplas om till målkontot,
• hanteras i enlighet med gällande juridiska krav (t.ex. arkiv‑ och gallringsregler).

Vid radering av konton avses i denna specifikation primärt borttagning av historik som tekniskt är knuten till användarkontot i Vklass, med de undantag som kan krävas av andra regelverk.

Gallring
Kontrollerad borttagning av personuppgifter i syfte att uppfylla:

• dataskyddsförordningen (GDPR),
• nationell lagstiftning (t.ex. arkivlagstiftning),
• lokala gallringsplaner och beslut.

I denna specifikation avses med gallring framför allt:

• radering av användarkonton och tillhörande data,
• borttagning eller spärrning av relationer (t.ex. vårdnadshavare–barn),
• tidsbegränsad lagring och borttagning av åtgärdsloggar.

Generell, schemalagd massgallring på systemnivå (t.ex. per skolform eller enhet) omfattas inte av denna funktionalitet, utan kan hanteras i separata gallringsfunktioner.

Åtgärdslogg / Loggning av åtgärder
En teknisk logg i Vklass som registrerar att en administrativ åtgärd kopplad till denna funktionalitet har genomförts, t.ex.:

• markering för radering,
• genomförd permanent radering,
• sammanslagning av konton,
• införande eller borttag av spärrar.

Åtgärdsloggen ska innehålla:

• tidpunkt för åtgärden,
• identifiering av ansvarig org‑admin,
• identifiering av berörda konton/relationer på en dataminimerad nivå (t.ex

Omfattning och avgränsningar

Funktionen omfattar användarkonton för samtliga huvudsakliga roller i Vklass – elev/barn, personal och vårdnadshavare – oavsett om kontot är synkroniserat från verksamhetssystem (elev‑, personal‑ och vårdnadshavarregister) eller manuellt skapat direkt i Vklass. Konton med TF‑personnummer, andra tillfälliga eller fiktiva identiteter samt konton utan svenskt personnummer hanteras tekniskt på samma sätt som övriga konton; den utökade användarhanteringen gör ingen särskild klassning eller tolkning av dessa identitetstyper.

Åtgärderna kan utföras på alla användarkonton som har koppling till den organisation (huvudman/kommun) där rollen org‑admin är giltig, oavsett skolform, enhet eller kombination av roller på kontot. Det innebär att konton kopplade till t.ex. förskola, grundskola, fritidshem, gymnasieskola, vuxenutbildning och eventuella andra skolformer inom samma Vklass‑organisation kan hanteras, inklusive konton som är knutna till flera skolor eller innehar flera roller samtidigt (t.ex. personal som även är vårdnadshavare). Funktionen är inte tillgänglig för skoladministratörer på enskilda enheter eller för andra roller än de som uttryckligen ges åtkomst till den utökade användarhanteringen (primärt org‑admin).

På datanivå omfattar funktionen i första hand själva användarkontot som identitet i Vklass (inklusive roller, inloggningsuppgifter och organisatoriska kopplingar) och i andra hand den historik som tekniskt är direkt knuten till kontot i Vklass. Vid radering av ett användarkonto kan detta, inom ramen för vad som är tekniskt och juridiskt möjligt, innebära att:

• personposten i Vklass tas bort,
• kontots kopplingar till skolor, klasser, grupper, barn och andra relationer avlägsnas,
• kontorelaterad data i Vklass (t.ex. resultat, bedömningar, inlägg, kommentarer, meddelanden, uppladdade filer, inlämningar samt närvaro‑ och frånvarodata) gallras enligt de regler som definierats för radering av konto.

Exempel: En gymnasieelev som avslutats i elevregistret och enligt kommunens gallringsplan ska tas bort ur Vklass kan markeras för radering, varpå kontot och dess kopplingar raderas efter avslutad karenstid under förutsättning att eleven inte längre förekommer i synkroniseringsunderlaget.

Vid sammanslagning av konton omfattar funktionen överföring och/eller sammanläggning av relevanta kopplingar och historik från ett konto till ett annat, så att ett tydligt ”målkonto” (huvudkonto) återstår. Systemet försöker, inom givna tekniska och juridiska ramar, att:

• flytta eller konsolidera grupp‑, klass‑ och enhetskopplingar,
• så långt möjligt koppla om historik (t.ex. bedömningar, närvaro, meddelanden) till målkontot,
• undvika dubbla eller motsägelsefulla behörigheter på det sammanslagna kontot.

Exempel: Ett äldre, manuellt skapat TF‑konto för en elev kan slås samman med ett nytt, synkroniserat konto med korrekt personnummer när eleven fått permanent identitet, så att lärarnas historiska bedömningar och elevens tidigare inlämningar följer med till det synkroniserade kontot.

Spärrfunktionen omfattar både hela användarkonton och specifika relationer. För samtliga roller (elev/barn, personal, vårdnadshavare) kan ett konto läggas på spärrlista, vilket innebär att synkroniseringen därefter:

• inte skapar nya konton för personen, och
• inte återaktiverar eller återskapar ett tidigare borttaget konto.

För vårdnadshavare omfattar funktionen dessutom möjligheten att enbart spärra en specifik relation vårdnadshavare–barn, så att just den kopplingen inte återupprättas via framtida synkronisering, medan andra relationer för samma vårdnadshavare fortsätter att fungera.

Exempel: En vårdnadshavare som enligt beslut inte ska ha digital åtkomst till barn A kan få relationen vårdnadshavare–barn A spärrad, medan relationen till barn B i samma familj lämnas orörd. Spärrlistan påverkar endast hur Vklass tolkar inkommande synkroniseringsdata; den ändrar aldrig innehållet i bakomliggande verksamhetssystem.

Samtliga åtgärder som omfattas av funktionen – markering för radering (med karenstid), genomförd permanent radering, direkt radering, sammanslagning av konton samt införande och borttag av spärrar (på konto‑ och relationsnivå) – loggas i en särskild åtgärdslogg. Loggningen är begränsad till vad som krävs för spårbarhet och revision och innehåller i huvudsak:

• tidpunkt för åtgärden,
• identifiering av ansvarig org‑admin (eller motsvarande behörig roll),
• typ av åtgärd,
• identifiering av berört konto eller relation på en dataminimerad nivå (t.ex. de sex första siffrorna i personnumret eller motsvarande identitet, förnamn och organisatorisk tillhörighet efter radering).

Åtgärdsloggarna lagras endast under en tidsbegränsad, relativt kort period och gallras därefter automatiskt i enlighet med fastställda regler, i linje med principen om dataminimering.

Funktionen är uttryckligen avgränsad till riktade åtgärder på enskilda användarkonton och specifika relationer i Vklass. Den:

• inför inte generell, regelbaserad massgallring eller schemalagd gallring av alla personrelaterade uppgifter på systemnivå (t.ex. per skolform eller enhet),
• förändrar inte den övergripande behörighets‑ och rollmodellen i Vklass utöver att tillföra rättigheter för att använda just denna funktionalitet,
• uppdaterar, raderar eller styr inte data i bakomliggande verksamhetssystem (elev‑, personal‑ eller vårdnadshavarregister) utan verkar enbart på Vklass interna datamodell och hur synkroniserad data tolkas,
• hanterar inte själva beslutsprocessen i verksamheten (t.ex. tolkning av beslut från socialtjänst eller domstol) utan utgår från att sådana beslut redan fattats och översatts till konkreta åtgärder som org‑admin genomför i Vklass,
• skickar inte notifieringar eller meddelanden till berörda användare utan är uteslutande en administrativ funktion i administrationsgränssnittet för behöriga organisationsadministratörer.

Berörda användarroller

Funktionen för utökad användarhantering riktar sig i första hand till organisationsadministratörer och är endast tillgänglig i administrationsgränssnittet för användare som uttryckligen har tilldelats behörighet att använda dessa avancerade åtgärder. Övriga roller i Vklass kan inte själva initiera radering, sammanslagning eller spärrning, men påverkas indirekt genom förändringar i konton, relationer och åtkomster.

Nedan beskrivs hur respektive roll berörs och vilka ansvarsförhållanden som gäller.

Organisationsadministratör (Org‑admin)
Org‑admin är den primära och i normalfallet enda aktiva användaren av den utökade användarhanteringen. Rollen verkar på organisationsnivå (t.ex. kommun/huvudman) och har rätt att arbeta över samtliga skolformer och enheter inom organisationen.

En org‑admin kan inom ramen för denna funktionalitet:

• söka fram och överblicka användarkonton för elever/barn, personal och vårdnadshavare i hela organisationen, oavsett enhet eller skolform,
• markera konton för radering med karenstid, ångra planerade raderingar samt – i undantagsfall – genomföra direkt radering utan karens när förutsättningarna är uppfyllda,
• initiera och genomföra sammanslagning av två konton som avser samma fysiska person (t.ex. ett äldre manuellt konto och ett nytt synkroniserat konto),
• lägga upp, ändra och ta bort spärrar för inläsning från verksamhetssystemen, både på kontonivå (hela personen) och relationsnivå (t.ex. en specifik vårdnadshavare–barn‑relation),
• ta del av åtgärdsloggar kopplade till dessa funktioner, i den omfattning som krävs för spårbarhet och revision, med beaktande av dataminimering.

Exempel:
En org‑admin får kännedom om att en lärare har två konton – ett manuellt skapat konto med Vklass‑inloggning och ett nytt synkroniserat konto kopplat till personalregistret. Org‑admin söker fram båda kontona, väljer det synkroniserade kontot som målkonto, slår samman kontona så att historik och grupper följer med, och avslutar därefter det manuella kontot. Läraren använder därefter enbart sitt ordinarie, synkroniserade konto.

Org‑admin ansvarar för att:

• funktionen används i enlighet med gällande lagstiftning (t.ex. GDPR, arkivregler) och organisationens interna riktlinjer och gallringsplaner,
• känsliga åtgärder (t.ex. radering av större mängder historik eller spärrning av vårdnadshavare–barn‑relationer) föregås av nödvändiga verksamhetsbeslut,
• nödvändig samverkan sker med dataskyddsombud, systemförvaltare och arkivansvariga när det är relevant.

Organisationen kan därutöver besluta att endast ett begränsat antal särskilt utsedda org‑admins får tillgång till just den utökade användarhanteringen, även om fler personer har generell organisationsadministratörsbehörighet i Vklass.

Särskilt utsedda systemnära administratörer (valfritt)
I vissa organisationer kan det finnas behov av att en eller ett fåtal tekniskt ansvariga (t.ex. systemförvaltare, integrationsansvariga) får tillgång till delar av den utökade användarhanteringen, exempelvis för att:

• hantera komplexa dubblettfall som beror på synkronisering,
• utreda konsekvenser av spärrar i förhållande till verksamhetssystemen.

I dessa fall kan organisationen – genom sin behörighetsmodell – låta en särskild systemnära administratörsroll få samma åtkomst som org‑admin till just denna funktionalitet. Ansvaret för hur åtgärderna används är då detsamma som för org‑admin och ska regleras i lokala rutiner. Denna möjliggörande roll förändrar inte att huvudansvaret för beslut om radering, spärrning och sammanslagning alltid ligger på huvudmannen/verksamheten.

Skoladministratörer och andra lokala administratörer
Skoladministratörer och motsvarande lokala administratörer på enhetsnivå (t.ex. skol‑ eller enhetsadministratörer) har ingen direkt åtkomst till funktionerna för:

• radering med karenstid eller direkt radering,
• sammanslagning av konton,
• spärrning av konton eller specifika relationer.

De fortsätter att använda befintliga administrationsfunktioner i Vklass, såsom:

• hantering av roller och rättigheter på skolnivå,
• sökning och översikt av användare på den egna enheten,
• funktioner för t.ex. ”Tidigare elever på skolan” eller motsvarande.

Skoladministratörer påverkas indirekt genom att:

• konton kan försvinna ur deras listor när de raderas eller spärras av org‑admin,
• dubbletter kan försvinna efter en sammanslagning, vilket förändrar hur personal och elever visas,
• vissa relationer (t.ex. en vårdnadshavare–barn‑koppling) kan upphöra att visas lokalt trots att underlaget i verksamhetssystemet fortfarande finns kvar.

Exempel:
En skoladministratör upptäcker att en vårdnadshavare följer med i synkroniseringen men enligt beslut inte ska ha åtkomst till ett visst barn i Vklass. Skoladministratören kan själv inte bryta relationen permanent, utan vänder sig till org‑admin med ett underlag. Org‑admin spärrar därefter den specifika vårdnadshavare–barn‑relationen, vilket gör att relationen inte längre skapas eller återupprättas via framtida synkronisering.

Elever/Barn
Elever/barn har ingen direkt interaktion med den utökade användarhanteringen. De kan dock påverkas på följande sätt:

• deras konton kan raderas (med tillhörande data i Vklass) när org‑admin genomför en godkänd radering, t.ex. i enlighet med kommunens gallringsplan efter avslutad skolgång,
• dubbla elevkonton kan slås ihop så att resultat, inlämningar och närvarodata sammanförs till ett huvudkonto (t.ex. när ett TF‑konto ersätts av ett konto med korrekt personnummer),
• ett elevkonto kan spärras från inläsning om verksamheten bedömer att eleven inte längre ska förekomma i Vklass, trots att eleven tillfälligt finns kvar i elevregistret.

Elever får inte några automatiska notifieringar från systemet kopplat till dessa åtgärder. Deras praktiska upplevelse blir att inloggning, vyer och tillgång till information kan förändras, t.ex. genom:

• att de inte längre kan logga in,
• att tidigare dubbletter ”försvinner” och endast ett konto återstår,
• att deras historik inte längre är synlig i Vklass efter gallring.

Personal
Personal (lärare, elevhälsa, skolledare, administrativ personal m.fl.) använder inte funktionen direkt, men deras konton och arbetsmiljö i Vklass kan påverkas av åtgärderna:

• personalkonton kan raderas eller spärras när en anställning avslutats och verksamheten bedömer att kontot inte längre ska finnas kvar i Vklass utöver eventuella arkiveringskrav,
• dubbla konton kan slås ihop, t.ex. när en lärare gått från manuellt konto till ett synkroniserat konto kopplat till personalregistret; undervisningsgrupper, bedömningar och meddelanden samlas då så långt som möjligt på ett huvudkonto,
• personalens vyer över elever, kollegor och vårdnadshavare kan förändras när org‑admin rättar till konton, relationer eller spärrar vissa åtkomster.

Ingen automatisk notifiering skickas till personal kopplat till dessa åtgärder, men de kan i praktiken märka:

• att vissa användare inte längre är sökbara eller syns i listor,
• att ett tidigare extra konto de haft upphör att fungera,
• att vyerna över en klass eller grupp uppdateras när dubbletter försvinner.

Vårdnadshavare
Vårdnadshavare har inte åtkomst till funktionen, men är en central målgrupp för vissa av åtgärderna, särskilt spärrar på relationsnivå.

En org‑admin kan, utifrån verksamhetens beslut:

• radera eller spärra ett helt vårdnadshavarkonto, vilket innebär att vårdnadshavaren inte längre kan logga in i Vklass eller ta emot information via plattformen,
• spärra eller ta bort en specifik relation mellan en vårdnadshavare och ett visst barn, samtidigt som andra relationer för samma vårdnadshavare fortsätter att fungera normalt.

Exempel:
En vårdnadshavare A har två barn, B och C, i kommunen. Genom beslut har det fastställts att vårdnadshavare A inte ska ha digital åtkomst till barn B, men fortsatt till barn C. Org‑admin lägger då en spärr på relationen A–B i Vklass. Efter detta kan A fortsatt logga in och se information om C, men kommer inte att se eller kunna interagera med information om B, även om relationen A–B formellt finns kvar i folkbokförings- eller elevregistret.

Vårdnadshavare får inte automatiska systemmeddelanden om sådana åtgärder. Information om förändrad åtkomst hanteras inom ramen för verksamhetens egna kommunikationsrutiner.

Administratörer av verksamhetssystem (källsystem)
Administratörer och systemförvaltare för elev‑, personal‑ och vårdnadshavarregister eller andra verksamhetssystem använder inte funktionen inne i Vklass, men deras system utgör underlag för många av kontrollerna och effekterna:

• synkroniseringsunderlaget från verksamhetssystemen används för att avgöra om ett konto kan raderas efter karens, eller om det fortfarande är aktivt och därför inte ska tas bort,
• spärrlistan i Vklass kan innebära att vissa personer eller relationer inte längre skapas eller uppdateras i Vklass, trots att de finns kvar i verksamhetssystemet,
• systemförvaltare kan behöva justera eller komplettera data i verksamhetssystemen för att långsiktigt harmonisera med de åtgärder som org‑admin har gjort i Vklass (t.ex. vid ändrat personnummer eller avslutade placeringar).

Exempel:
En elev har först registrerats med ett TF‑nummer i elevregistret och därefter fått ett korrekt personnummer. Detta leder till två separata konton i Vklass. Efter samråd uppdaterar administratören i elevregistret personnumret, varefter org‑admin i Vklass slår samman TF‑kontot med det nya kontot och ser till att det gamla identitetsvärdet inte längre används. På så sätt hålls kopplingen mellan Vklass och källsystemet konsekvent över tid.

Samspelet mellan org‑admin och verksamhetssystemens administratörer är centralt för att:

• undvika att felaktiga eller dubbletta konton återskapas av synkroniseringen,
• säkerställa att raderingar och spärrar i Vklass är förenliga med hur personen hanteras i källsystemen,
• upprätthålla en tydlig ansvarsfördelning där källsystemen fortsatt är ”master” för grunddata, medan Vklass hanterar åtkomst, historik och särskilda undantagsfall.

Sammanfattning av rollfördelning
Sammanfattningsvis är organisationsadministratören (och eventuellt särskilt utsedda systemnära administratörer) de enda aktiva användarna av den utökade användarhanteringen. Övriga roller – skoladministratörer, elever/barn, personal, vårdnadshavare samt administratörer av verksamhetssystem – påverkas indirekt genom:

• att konton raderas, slås ihop eller spärras,
• att relationer (särskilt vårdnadshavare–barn) kan upphöra att gälla i Vklass oavsett källdata,
• att vyer, listor och åtkomster i Vklass förändras i enlighet med genomförda åtgärder.

Funktionen är därmed ett kraftfullt, men medvetet koncentrerat, verktyg för ett fåtal behöriga roller, med tydliga konsekvenser för hela organisationens användare.

Åtkomst och behörighetsregler

Funktionen för utökad användarhantering är en systemnära administrativ funktion som endast får användas av ett mycket begränsat antal behöriga roller. Åtkomst styrs av Vklass ordinarie behörighetsmodell och befintliga mekanismer för stark autentisering; funktionen förändrar inte vilka övriga roller som kan se personuppgifter i Vklass och utökar inte någon annan användares åtkomst.

Behöriga roller och organisationsgränser

• Organisationsadministratör (Org‑admin) är den primära behörighetsrollen för funktionen. Endast användare med denna roll på den aktuella organisationen kan:

  • se menyalternativet/funktionsområdet för utökad användarhantering,
  • söka fram och öppna användare i denna funktion,
  • initiera och genomföra radering, sammanslagning av konton samt hantera spärrar (spärrlista),
  • ta del av åtgärdsloggar kopplade till just dessa åtgärder.

• Organisationen kan, om man så beslutar, låta en särskild systemnära administratörsroll (t.ex. systemförvaltare/IT‑förvaltare) få åtkomst till samma funktionsområde. I sådant fall:

  • ska denna roll tekniskt ha samma begränsningar som Org‑admin inom funktionen (ingen åtkomst utanför den egna organisationen, ingen utökad insyn i andras data),
  • regleras ansvar och mandat lokalt (t.ex. i förvaltningsplan eller behörighetsrutin),
  • påverkas inte övriga roller i Vklass.

• Skol‑ och enhetsadministratörer (t.ex. SchoolAdmin, Principal, andra lokala adminroller) har:

  • ingen åtkomst till funktionsområdet för utökad användarhantering,
  • ingen möjlighet att se eller påverka spärrlistor, raderingskön eller åtgärdsloggar kopplade till denna funktion.

• Åtgärder kan bara utföras på användarkonton som tillhör samma organisation (huvudman/kommun) som org‑admin är kopplad till. Vklass befintliga avgränsningar mellan organisationer gäller fullt ut:

  • en org‑admin i Kommun A kan aldrig se eller hantera konton för användare som endast tillhör Kommun B,
  • konton som har historiska kopplingar till flera organisationer visas endast i den mån de i dag är kopplade till org‑admins egen organisation, och åtgärder får inte påverka andra organisationers data.

Exempel:
En org‑admin i Kommun X kan slå ihop två konton för en lärare som endast är anställd i Kommun X. Däremot kan samma org‑admin inte se eller hantera ett konto för en lärare som endast är aktiv i en fristående skola som ligger i en annan Vklass‑organisation.

Autentisering och krav på säker inloggning

Funktionen följer Vklass befintliga mekanismer för autentisering, inklusive stöd för starkare inloggningsnivåer (t.ex. BankID, Freja eID, organisations‑SSO).

• Om organisationen har aktiverat inställningen för ”Säkrare inloggning” för användare med högre behörighet:

  • måste org‑admin (och eventuella systemnära administratörer) använda stark autentisering (t.ex. BankID, Freja eID eller SSO med tillräcklig LOA‑nivå) för att kunna komma åt och använda funktionen,
  • kan funktionen inte nås via enbart användarnamn/lösenord.

• Om org‑admin försöker öppna funktionsområdet utan att kraven på säker inloggning är uppfyllda:

  • ska åtkomst nekas, eller
  • ska användaren omdirigeras till ett flöde för uppgradering av inloggningsnivå (t.ex. ”logga in igen med BankID”).

Funktionen inför inga egna inloggningsmetoder, utan använder enbart de autentiseringslösningar som redan är konfigurerade för organisationen.

Läsbehörighet inom funktionen

En behörig org‑admin (eller systemnära administratör, där sådan roll används) som öppnar funktionen för utökad användarhantering ska kunna:

• Söka fram användare inom den egna organisationen oavsett roll:

  • elev/barn,
  • personal,
  • vårdnadshavare.

• Användaren ska kunna hittas via flera typer av urval, t.ex.:

  • personnummer eller TF‑nummer (inklusive specialfall som 120813‑TF21),
  • namn (för‑/efternamn),
  • skola/enhet,
  • klass/avdelning/grupp,
  • för vårdnadshavare: via koppling till ett specifikt barn.

• Vid visning av uppgifter i funktionen ska org‑admin:

  • se samma uppsättning grundläggande person‑ och kontouppgifter som org‑admin redan har tillgång till i övriga delar av Vklass (t.ex. fullständigt personnummer där detta redan är tillåtet i dag),
  • inte få åtkomst till några ytterligare kategorier av känsliga uppgifter än vad org‑admin kan se i andra administrationsvyer.

Funktionen får inte:

• utöka andra rollers (t.ex. lärare, elevhälsa, skoladministratörer) insyn i personuppgifter eller kontohistorik utöver dagens nivå,
• exponera spärrlistor, raderingsköer eller åtgärdsloggar för någon annan än de behöriga rollerna för denna funktion (primärt org‑admin).

Efter genomförd radering ska endast en begränsad mängd identifierande information om det raderade kontot kvarstå i åtgärdsloggen (t.ex. de sex första siffrorna i personnumret, förnamn och skola/enhet), i enlighet med principen om dataminimering.

Ändringsbehörighet: radering, inaktivering och sammanslagning

Endast org‑admin (och eventuellt särskilt utsedda systemnära administratörer) får initiera och genomföra följande åtgärder i den utökade användarhanteringen:

Markera konto för radering (med karenstid)

Behörig användare kan:

• markera ett konto för radering och därmed lägga det i en raderingskö med karenstid (t.ex. 48 timmar),
• se och hantera listan över alla konton som:
  • är markerade för radering,
  • har pågående karens,
  • har stoppats från radering på grund av att personen återkommit i synkroniseringsunderlaget,
• avbryta en planerad radering under karenstiden genom att ta bort kontot från raderingslistan.

Kontot får under karenstiden en tydlig status (t.ex. ”Markerad för radering”), så att org‑admin ser att en åtgärd är planerad men ännu inte genomförd.

Exempel:
En vuxenstudiestuderande har avslutats i elevregistret och ska enligt kommunens gallringsrutiner tas bort ur Vklass efter viss tid. Org‑admin markerar kontot för radering. Om studenten inte återkommer i elevregistret under karenstiden utför systemet därefter den permanenta raderingen.

Direkt radering

Direkt radering är en medvetet restriktiv undantagsåtgärd och får endast genomföras av behörig org‑admin när:

• systemet först har kontrollerat mot synkroniseringsunderlaget att personen inte längre förekommer i relevanta verksamhetssystem, och
• org‑admin explicit har bekräftat att kontot inte ska kunna återskapas via framtida synkronisering.

Vid direkt radering:

• tas kontot bort omedelbart (ingen karenstid tillämpas),
• skapas en åtgärdsloggpost som anger att direkt radering utförts, av vem och när.

Exempel:
Ett testkonto har av misstag skapats med ett påhittat personnummer. Org‑admin verifierar att kontot inte kommer från något källsystem och använder därefter direkt radering för att omedelbart ta bort kontot och dess historik.

Automatisk radering efter karens

När ett konto är markerat för radering ansvarar systemet för att:

• löpande kontrollera om personen förekommer i synkroniseringsunderlaget under hela karensperioden,
• genomföra den permanenta raderingen automatiskt när villkoren är uppfyllda (t.ex. 48 timmar utan att personen synts i någon synkroniseringskörning),
• avbryta eller skjuta upp raderingen om personen återkommer i synkroniseringsunderlaget under karenstiden.

Org‑admin ska i gränssnittet kunna se:

• aktuell status per konto i raderingskön (t.ex. ”I karens – 24 h kvar”, ”Radering stoppad – användaren är åter aktiv i synkronisering”),
• om och när den slutliga raderingen har genomförts.

Sammanslagning av användarkonton

Behörig org‑admin kan initiera en kontrollerad sammanslagning av två konton som avser samma fysiska person:

• Org‑admin väljer:
  • vilka två konton som ska slås samman, och
  • vilket konto som ska vara målkonto (huvudkonto) respektive vilket konto som ska slås in i målkontot.
• Systemet visar en översikt av:
  • roller, skolor och klasser kopplade till respektive konto,
  • huvudsakliga skillnader (t.ex. olika personnummer, olika inloggningsmetoder),
  • eventuell kritisk historik som berörs (t.ex. undervisningsgrupper, bedömningar, inlämningar).

Efter att org‑admin explicit bekräftat åtgärden:

• förs relevanta kopplingar och historik över till målkontot enligt definierade regler,
• avslutas eller raderas det sekundära kontot,
• skapas en åtgärdsloggpost som tydligt anger att en sammanslagning har skett och vilket konto som är kvarvarande huvudkonto.

Sammanslagning är irreversibel: när åtgärden väl är genomförd kan den inte ångras via gränssnittet.

Exempel:
En lärare har tidigare haft ett manuellt konto med Vklass‑inloggning och får nu ett nytt, synkroniserat konto från personalregistret. Org‑admin använder funktionen för sammanslagning, väljer det synkroniserade kontot som målkonto, och ser till att grupper, tidigare meddelanden och bedömningar kopplas om så långt som möjligt.

Rolloberoende och ansvar

• Samtliga ovanstående åtgärder kan utföras av vilken behörig org‑admin som helst inom organisationen; de är inte bundna till den person som först markerade kontot för radering eller initierade ett ärende.
• Funktionen inför inga möjligheter för andra roller (t.ex. Principal, SchoolAdmin, lärare) att radera, slå ihop eller på annat sätt tekniskt manipulera användarkonton på denna nivå.

Behörighet att hantera spärrar (spärrlista)

Hantera spärrlistan är en central del av den utökade användarhanteringen. Endast org‑admin (och eventuella systemnära administratörer) får:

• se vilka personer och relationer som är spärrade,
• lägga till nya spärrar,
• ändra eller ta bort befintliga spärrar.

Följande typer av spärrar hanteras:

Spärr av hela konton (personbaserad spärr)

Behörig användare kan:

• lägga en person (oavsett roll: elev/barn, personal, vårdnadshavare) på spärrlista, vilket innebär att:
  • nya konton för personen inte skapas i Vklass via synkronisering,
  • tidigare konton inte återaktiveras eller återskapas efter radering eller inaktivering,
• ange orsakstyp eller kommentar (enligt lokala rutiner) för att underlätta uppföljning.

Exempel:
En konsult har haft ett manuellt konto i V

Skolformer och organisationsnivåer

Funktionen för utökad användarhantering är uttryckligen utformad för att verka på organisationsnivå (huvudman/kommun) och är gemensam för samtliga skolformer och enheter som ingår i organisationen. Det innebär att en org‑admin, inom ramen för sin organisation, kan hantera användarkonton för alla typer av verksamheter som finns konfigurerade i Vklass, t.ex.:

• förskola och pedagogisk omsorg,
• grundskola, grundsärskola och fritidshem,
• gymnasieskola och gymnasiesärskola,
• vuxenutbildning och andra eventuella skolformer eller verksamheter som huvudmannen har i Vklass.

Alla åtgärder som omfattas av funktionen – radering (med karenstid eller direkt), sammanslagning av konton samt spärrning av inläsning på konto‑ eller relationsnivå – utförs alltid i kontexten av den organisation där org‑admin har behörighet. Org‑admin kan endast se och påverka konton som tillhör den egna organisationen. Konton och data som tillhör andra organisationer (andra huvudmän i Vklass) är tekniskt separerade och kan inte hanteras via funktionen. Detta följer Vklass befintliga principer för dataseparering mellan huvudmän och förhindrar att en org‑admin oavsiktligt påverkar en annan organisations användare eller historik.

På enhetsnivå (skola, förskola, fritidshem, vuxenutbildningsenhet m.fl.) finns ingen egen åtkomst till den utökade användarhanteringen. Lokala roller såsom skoladministratörer, rektorer (Principal) eller andra enhetsnära administratörer:

• ser inte funktionsområdet för utökad användarhantering i gränssnittet,
• kan inte själva initiera radering, sammanslagning eller spärrning av konton/relationer via denna funktion,
• har ingen insyn i raderingsköer, spärrlistor eller åtgärdsloggar kopplade till funktionen.

Dessa roller påverkas i stället indirekt av de åtgärder som org‑admin genomför på organisationsnivå. Konsekvenserna kan exempelvis vara att:

• en tidigare elev inte längre visas under ”Tidigare elever på skolan” efter att kontot raderats enligt gallringsbeslut,
• ett dubbelt lärarkonto försvinner ur lokala listor när två konton slagits ihop till ett gemensamt huvudkonto,
• en vårdnadshavare inte längre syns som kontaktperson för ett visst barn i skolans vyer, eftersom relationen vårdnadshavare–barn har spärrats eller tagits bort i Vklass trots att den formellt finns kvar i folkbokförings- eller elevregistret.

Funktionen tillämpas likadant oavsett skolform. Samma grundprinciper och tekniska regler gäller för:

• karenstid och hantering av konton markerade för radering,
• kontroll mot synkroniseringsunderlaget innan radering slutförs,
• loggning av vidtagna åtgärder och efterföljande gallring av loggar,
• spärrning av inläsning på konto‑ och relationsnivå.

Eventuella skillnader i hur och när funktionen används mellan olika skolformer (t.ex. olika gallringsfrister för gymnasiet respektive vuxenutbildningen) beror på huvudmannens egna gallringsplaner och rutiner, inte på att systemet beter sig olika per skolform. Org‑admin ansvarar för att tillämpa samma tekniska funktioner på ett sätt som följer respektive verksamhets regelverk.

Eftersom många användare har kopplingar till flera enheter eller skolformer hanteras användarkontot alltid som en gemensam identitet på organisationsnivå. Några typiska exempel:

• en lärare som arbetar både på en grundskola och ett fritidshem i samma kommun,
• en specialpedagog som är knuten till flera skolor och skolformer,
• en elev som byter från grundskola till gymnasieskola inom samma huvudman,
• en vårdnadshavare med barn i både förskola och grundskola.

När ett konto raderas, spärras eller slås ihop gäller åtgärden därför konsekvent för alla enheter och skolformer som kontot är kopplat till inom den aktuella organisationen. Ett raderat eller spärrat lärarkonto upphör t.ex. att gälla i både förskola och grundskola där läraren varit verksam; ett sammanslaget elevkonto blir huvudkonto för elevens historik oavsett om eleven tidigare varit registrerad i flera skolformer.

För vårdnadshavare gäller dock att spärrning även kan ske på relationsnivå. Det innebär att org‑admin, utifrån verksamhetens beslut, kan:

• spärra hela vårdnadshavarkontot (ingen åtkomst till något barn i någon skolform), eller
• endast spärra en specifik relation vårdnadshavare–barn, oberoende av i vilken skolform barnet befinner sig (t.ex. endast relationen till ett barn i grundskolan, medan relationen till ett syskon i förskolan lämnas intakt).

På så sätt kan funktionen användas för att konsekvent tillämpa beslut om åtkomst över alla skolformer inom en organisation, samtidigt som den finmaskighet som ofta krävs för vårdnadshavarrelationer bibehålls.

Översikt av funktionalitet

Den utökade användarhanteringen samlar all avancerad livscykelhantering av användarkonton i ett gemensamt funktionsområde för behöriga Org‑admins. Från samma gränssnitt kan administratören på ett kontrollerat, säkert och spårbart sätt:

• söka fram användare och/eller specifika relationer,
• få en översikt på hög nivå över kontots kopplingar i Vklass,
• initiera radering (med karenstid eller direkt),
• slå ihop dubbla konton som avser samma fysiska person,
• spärra inläsning av hela konton eller enskilda relationer (främst vårdnadshavare–barn) från verksamhetssystemen.

Funktionaliteten är generell och gäller alla användartyper (elev/barn, personal, vårdnadshavare), oavsett om kontot är synkroniserat från källsystem eller skapat manuellt i Vklass (t.ex. TF‑nummer, tillfälliga konton eller andra avvikande identiteter).

Org‑admin inleder alltid med att söka fram relevanta konton eller relationer, t.ex. via:

• personnummer eller TF‑nummer (inkl. format som 120813‑TF21),
• namn och/eller skola/enhet,
• klass/avdelning/grupp,
• för vårdnadshavare: via koppling till ett specifikt barn.

Därefter väljer Org‑admin vilken åtgärd som ska utföras på det valda kontot eller relationen.

---

Radering av användarkonto

Radering av användarkonto kan genomföras enligt två huvudflöden:

1. standardflöde med karenstid,
2. direkt radering i särskilda, verifierade undantagsfall.

Vid båda flödena är utgångspunkten att:

• kontot endast får raderas permanent om det inte längre förekommer i synkroniseringsunderlaget från verksamhetssystemen,
• åtgärden loggas med tidpunkt, ansvarig Org‑admin och berört konto på en dataminimerad nivå.

Standardradering med karenstid

Standardflödet ”markera för radering” används för huvuddelen av alla raderingsärenden (t.ex. avslutade elever enligt gallringsplan):

• Org‑admin väljer ”Markera för radering” på ett konto.
• Systemet visar en sammanfattande översikt över kontots huvudsakliga kopplingar i Vklass (t.ex. roller, skolor/enheter, klasser/grupper, om kontot har vårdnadshavarrelationer), utan att exponera mer detaljerat innehåll än nödvändigt.
• Efter bekräftelse:
  • skapas en karenspost för kontot med en definierad karenstid (t.ex. 48 timmar – exakt längd kan vara konfigurerbar),
  • kontot får status ”Markerad för radering” och visas som sådant i relevanta listor i administrationsgränssnittet.

Under karenstiden gäller:

• Vklass kontrollerar löpande mot synkroniseringsunderlaget om personen fortfarande förekommer i något verksamhetssystem.
• Org‑admin kan se kontots aktuella karensstatus, t.ex.:
  • ”I karens – 36 timmar kvar”,
  • ”Radering stoppad – användaren åter aktiv i synkronisering”.
• Om personen inte förekommer i synkroniseringsunderlaget under hela karensperioden:
  • genomför systemet den permanenta raderingen automatiskt när karenstiden löpt ut.
• Om personen återkommer i synkroniseringsunderlaget under pågående karens:
  • stoppas eller skjuts raderingen upp,
  • detta framgår tydligt i raderingslistan,
  • Org‑admin behöver då ta ställning till om kontot ska kvarstå, markeras på nytt eller hanteras på annat sätt.

Org‑admin kan när som helst under karenstiden:

• ångra den planerade raderingen genom att ta bort kontot från raderingslistan,
• därefter fortsätter kontot att fungera som vanligt i Vklass.

Exempel
En gymnasieelev har slutat och tagits bort ur elevregistret. Enligt kommunens gallringsplan ska kontot raderas ur Vklass efter viss tid. När Org‑admin markerar kontot för radering läggs det i karens. Om eleven inte återkommer i elevregistret under karensperioden raderas kontot och dess kopplingar automatiskt efter karenstidens slut.

Direkt radering

Direkt radering används i undantagsfall där det är verifierat att kontot inte ska kunna återkomma och där en karensperiod inte bedöms nödvändig, t.ex.:

• uppenbart felaktiga testkonton,
• konton med felaktigt personnummer som aldrig funnits i källsystem,
• rent manuella konton där organisationen säkerställt att personen aldrig ska ligga i verksamhetssystemen.

Flödet för direkt radering:

• Org‑admin väljer ”Direkt radering” på ett konto.
• Vklass utför alltid en kontroll mot synkroniseringsunderlaget:
  • om personen förekommer i ett verksamhetssystem stoppas åtgärden och Org‑admin informeras om att direkt radering inte kan genomföras,
  • om personen inte förekommer i synkroniseringsunderlaget kan radering fortsätta.
• Org‑admin måste därefter explicit bekräfta åtgärden (t.ex. via dubbel bekräftelse med tydlig varning om att åtgärden inte kan ångras).
• Kontot och dess kopplingar raderas omedelbart när bekräftelsen genomförts.

Resultat av radering

När ett konto raderas (oavsett flöde) innebär det att:

• användarkontot som identitet i Vklass tas bort,
• kontots kopplingar till skolor, enheter, klasser, grupper, barn och andra relationer tas bort,
• kontorelaterad data i Vklass gallras i den omfattning som definierats för kontoradering (t.ex. resultat, inlämningar, meddelanden, närvaro), med beaktande av juridiska krav.

I åtgärdsloggen kvarstår endast:

• en dataminimerad identifiering av kontot (t.ex. de sex första siffrorna i personnumret eller motsvarande, förnamn och skola/enhet),
• typ av åtgärd (standardradering/direkt radering),
• tidpunkt och ansvarig Org‑admin.

Denna logginformation lagras bara under en begränsad, fastställd period innan den gallras automatiskt.

---

Sammanslagning av användarkonton

Funktionen för sammanslagning gör det möjligt att hantera dubbla konton som avser samma fysiska person, oavsett:

• roll (elev/barn, personal, vårdnadshavare),
• kontotyp (synkroniserat konto, manuellt konto eller kombination),
• identitetstyp (t.ex. övergång från TF‑nummer till korrekt personnummer).

Flödet för sammanslagning:

• Org‑admin söker fram och väljer två användarkonton som bedöms tillhöra samma person.
• Systemet presenterar en jämförande översikt, t.ex.:
  • personuppgifter (namn, personnummer/TF‑nummer),
  • roller och skol-/enhetskopplingar,
  • klass-/grupptillhörigheter,
  • eventuella vårdnadshavare‑ eller barnrelationer,
  • information om kontots ursprung (synkroniserat/manuellt).
• Org‑admin anger vilket konto som ska vara målkonto (huvudkonto framåt) och vilket som ska upphöra.
• Systemet redovisar, på en övergripande nivå, vilken typ av data som kommer att påverkas (t.ex. undervisningsgrupper, bedömningar, närvaro, meddelanden), utan att visa detaljerat innehåll.
• Efter explicit bekräftelse från Org‑admin:
  • förs relevanta kopplingar och kontohistorik så långt som tekniskt och juridiskt möjligt över till målkontot,
  • det sekundära kontot avslutas/raderas,
  • målkontot fortsätter att användas som den enda aktiva identiteten i Vklass.

Sammanslagning är en irreversibel åtgärd och kan inte ångras via gränssnittet när den väl är genomförd.

Exempel
En elev har först haft ett manuellt skapat konto med TF‑nummer (120813‑TF21) och får senare ett synkroniserat konto med sitt riktiga personnummer. Båda kontona finns samtidigt i Vklass. Org‑admin väljer det synkroniserade kontot som målkonto, slår ihop kontona och säkerställer därmed att så mycket som möjligt av elevens historik (t.ex. inlämningar och resultat) följer med till det korrekta, synkroniserade kontot.

Även sammanslagningar loggas i åtgärdsloggen med:

• tidpunkt,
• ansvarig Org‑admin,
• identifiering av målkontot och det avslutade kontot på en dataminimerad nivå.

---

Spärrning av inläsning (spärrlista)

Spärrfunktionen kompletterar radering och sammanslagning genom att styra hur Vklass får tolka framtida synkroniseringar från verksamhetssystemen. Syftet är att kunna förhindra att vissa konton eller relationer:

• ny‑skapas,
• återaktiveras, eller
• återskapas efter att ha raderats eller tagits bort i Vklass,

även om personen eller relationen finns kvar i källsystemet.

Spärrar registreras i en särskild spärrlista och kan avse:

• hela användarkonton (personbaserad spärr), eller
• specifika relationer (främst vårdnadshavare–barn).

Spärr av hela konton

Org‑admin kan lägga en person på spärrlista oavsett roll (elev/barn, personal, vårdnadshavare). Effekten blir att:

• nya konton för personen inte skapas i Vklass via synkronisering,
• tidigare konton för personen inte återaktiveras eller återskapas,
• Vklass konsekvent ignorerar inkommande poster för den spärrade identiteten från synkroniseringsunderlaget.

Det är möjligt att, enligt lokala rutiner, ange orsakstyp eller en kort administrativ kommentar till spärren (t.ex. ”felaktigt registrerad person”, ”särskilt beslut om åtkomst”).

Spärr av specifik relation vårdnadshavare–barn

För vårdnadshavare finns ett särskilt behov av att kunna styra åtkomst på relationsnivå. Org‑admin kan därför:

• spärra hela vårdnadshavarkontot (ingen åtkomst till något barn i Vklass), eller
• enbart spärra en enskild relation mellan en specifik vårdnadshavare och ett visst barn.

Vid spärr av en specifik relation gäller att:

• relationen vårdnadshavare–barn inte skapas eller återupprättas i Vklass vid framtida synkronisering,
• övriga relationer för samma vårdnadshavare (t.ex. till syskon) fortsätter att fungera som vanligt, om de inte också spärras.

Exempel
En vårdnadshavare har två barn i kommunen. Genom beslut har det fastställts att vårdnadshavaren inte ska ha digital åtkomst till barn A, men fortsatt till barn B. Org‑admin lägger då en spärr på relationen vårdnadshavare–barn A i spärrlistan. När nästa synkronisering körs ignorerar Vklass alla försök att återskapa relationen till barn A, samtidigt som relationen till barn B ligger kvar.

Koppling mellan spärr och radering

Spärrar kan kombineras med raderingsflöden

Hantering av användarkonton generellt

Användarkonton i Vklass hanteras enligt en gemensam, rolloberoende modell oavsett om personen är elev/barn, personal eller vårdnadshavare. Utgångspunkten är principen ”en fysisk person – ett användarkonto per organisation”. Det kontot kan därefter bära en eller flera roller, ha kopplingar till flera enheter och skolformer samt olika relationer (t.ex. vårdnadshavare–barn).

Ett användarkonto utgör i grunden:

• en unik identitetsnyckel
  • t.ex. svenskt personnummer, TF‑nummer eller annat unikt ID som används konsekvent i Vklass och synkroniseringen,
• ett eller flera inloggningssätt
  • t.ex. Vklass‑inloggning, BankID/Freja eID, organisations‑SSO,
• en eller flera roller
  • elev/barn, personal, vårdnadshavare (eventuellt i kombination på samma konto),
• organisatoriska kopplingar
  • skolor/enheter, klasser/grupper, barn (för vårdnadshavare) samt särskilda behörigheter och rättigheter,
• kontohistorik
  • t.ex. närvaro- och frånvarodata, resultat och bedömningar, meddelanden, inlägg, uppgifter, inlämningar och andra händelser som tekniskt knyts till kontot.

Denna kontomodell är gemensam för alla funktioner i specifikationen och utgör den tekniska grund som den utökade användarhanteringen verkar mot.

Gemensam struktur för alla roller

Skillnaden mellan elev/barn, personal och vårdnadshavare ligger främst i roller och relationer, inte i hur kontot är uppbyggt tekniskt. Det innebär bl.a. att:

• samma fysiska person kan ha flera roller på samma konto, t.ex.
  • en lärare som samtidigt är vårdnadshavare till ett barn i kommunen,
  • en medarbetare som både är personal på en gymnasieskola och handledare i vuxenutbildningen,
• ett konto kan vara kopplat till flera skolor, enheter och skolformer inom samma organisation,
• kontots identitetsnyckel (personnummer, TF‑nummer eller annat ID) är gemensam över tid och används för att hålla ihop all data som avser personen, oavsett vilken roll personen har eller har haft.

Den utökade användarhanteringen utgår därför alltid från användarkontot som helhet. När ett konto raderas, slås ihop eller spärras är grundregeln att åtgärden omfattar alla roller och kopplingar som är knutna till den identiteten, om inte funktionen uttryckligen riktar sig mot en specifik relation (t.ex. en viss vårdnadshavare–barn‑koppling).

Exempel:

• En elev som samtidigt är timanställd på fritidshemmet inom samma kommun har båda rollerna (elev och personal) på ett konto. Om kontot spärras eller raderas påverkas båda rollerna.
• En specialpedagog som arbetar på flera skolor i samma organisation har ett konto med kopplingar till samtliga berörda skolor. Vid sammanslagning av konton överförs dessa kopplingar till det valda huvudkontot.

Synkroniserade och manuellt skapade konton

Majoriteten av användarkonton i Vklass skapas och uppdateras via synkronisering från bakomliggande verksamhetssystem (elev‑, personal‑ och vårdnadshavarregister). I dessa fall gäller att:

• verksamhetssystemet är ”ägare” av grunddatan
  • t.ex. namn, personnummer/ID, skolplacering, anställning, vårdnadshavarrelationer,
• Vklass ansvarar för att tolka synkroniseringsunderlaget och
  • skapa eller uppdatera användarkonton,
  • tilldela rätt roller, skol- och klasskopplingar,
  • uppdatera eller avsluta relationer i enlighet med källdata.

Utöver synkroniserade konton förekommer manuellt skapade konton i Vklass, exempelvis för:

• praktikanter, konsulter eller tillfälliga vikarier som inte finns i personalregistret,
• personer utan svenskt personnummer,
• elever med TF‑nummer eller annan tillfällig/fiktiv identitet,
• särskilda undantagsfall där källsystemet av olika skäl inte innehåller personen.

Ur teknisk synvinkel hanteras manuella konton enligt samma kontomodell som synkroniserade konton:

• de har en identitetsnyckel (t.ex. TF‑nummer eller annat ID),
• de kan ha roller, skol-/enhetskopplingar, klasser/grupper och relationer,
• de bygger upp historik på samma sätt som andra konton.

Skillnaden är att manuella konton inte styrs av källdata på samma sätt som synkroniserade konton; uppdateringar och avslut sker primärt genom administrativa åtgärder i Vklass.

Om en person först registrerats manuellt och senare börjar förekomma i ett verksamhetssystem (t.ex. när ett TF‑nummer ersätts av ett riktigt personnummer i elevregistret) kan det resultera i dubbla konton i Vklass:

• ett äldre manuellt konto (t.ex. med TF‑nummer), och
• ett nytt synkroniserat konto med korrekt personnummer.

I dessa situationer används funktionen för sammanslagning av konton för att undvika att personens historik splittras, t.ex. genom att:

• välja det synkroniserade kontot som huvudkonto,
• föra över relevanta kopplingar och historik från det manuella kontot,
• avsluta/radera det manuella kontot efter genomförd sammanslagning.

Konton med TF‑nummer, andra tillfälliga eller fiktiva identiteter samt konton utan svenskt personnummer behandlas i denna funktionalitet som vanliga användarkonton. Systemet gör ingen automatisk bedömning av om dessa avser skyddad identitet eller andra sekretesskategorier; de omfattas av samma regler och flöden som övriga konton.

Exempel:

• En elev registreras initialt med TF‑nummer i Vklass eftersom eleven ännu inte har ett svenskt personnummer. När eleven senare får ett personnummer och detta registreras i elevregistret skapas ett nytt, synkroniserat konto. Org‑admin använder därefter sammanslagning för att föra över elevens historik från TF‑kontot till det nya kontot.

Livscykel för användarkonton

På en övergripande nivå kan livscykeln för ett användarkonto i Vklass beskrivas i följande steg:

1. Skapande av konto

   • Via synkronisering:
     • Personen registreras i ett verksamhetssystem (t.ex. elev antas till skola, personal anställs, vårdnadshavare kopplas till barn).
     • Vid nästa synkroniseringskörning skapar Vklass ett nytt konto eller uppdaterar ett befintligt konto utifrån synkroniseringsunderlaget.
   • Manuellt i Vklass:
     • En administratör skapar ett konto direkt i Vklass för fall där ingen adekvat källdatakälla finns eller där en snabb lösning krävs (t.ex. konsult, TF‑elev).

2. Aktiv användning och löpande uppdatering

   • Kontot används i vardagen: inloggning, undervisning, kommunikation, frånvarorapportering, inlämningar m.m.
   • Roller, skol‑ och klasskopplingar, vårdnadshavarrelationer och andra grunddata uppdateras huvudsakligen via synkronisering, i vissa fall kompletterat med administrativt arbete i Vklass (t.ex. tilldelning av särskilda behörigheter eller supportroller).

3. Förändrade förutsättningar i verksamhetssystemen

   • Personen byter skola/enhet, får ändrat personnummer, avslutar studier eller anställning, eller får ändrad vårdnadshavarrelation i folkbokföringen.
   • För synkroniserade konton återspeglas dessa förändringar vid kommande synkroniseringar genom uppdaterade eller borttagna kopplingar.
   • I vissa fall kan detta leda till särskilda situationer, t.ex. dubbla konton eller kvarstående relationer som inte ska gälla i Vklass, trots att källdata formellt finns kvar.

4. Avslut och gallring/inaktivering

   • När en person inte längre ska vara aktiv i Vklass (t.ex. avslutad skolgång, upphörd anställning) uppdateras verksamhetssystemen i första hand.
   • Vklass uppdaterar då kontots kopplingar (t.ex. tar bort skol- och klasskopplingar) enligt synkroniseringslogiken.
   • Själva kontot och dess historik kvarstår normalt tills ytterligare åtgärder vidtas i enlighet med organisationens gallringsplan och rättsliga krav. Detta kan omfatta:
     • radering av kontot med karenstid,
     • direkt radering i särskilda, verifierade fall,
     • inaktivering eller spärrning av kontot eller specifika relationer.

5. Vid behov: avancerad hantering i den utökade funktionen
   När standardflödena via verksamhetssystem och synkronisering inte räcker för att uppnå önskat resultat, används den utökade användarhanteringen för att:

   • radera ett konto på ett kontrollerat sätt (med karenstid eller direkt),
   • slå ihop två konton som avser samma fysiska person,
   • spärra inläsning av ett konto eller en specifik relation (t.ex. vårdnadshavare–barn) så att synkroniseringen inte längre kan ny‑skapa eller återaktivera dessa i Vklass.

Den utökade användarhanteringen ersätter inte ordinarie livscykel via verksamhetssystemen, utan fungerar som ett kompletterande verktyg för undantagsfall, korrigeringar och avancerade scenarier där automatiken inte räcker eller ger felaktigt resultat.

Gemensam hantering i den utökade funktionen

När Org‑admin arbetar i den utökade användarhanteringen sker all hantering av konton på ett enhetligt och rolloberoende sätt, med stöd för samtliga användartyper och kontotyper.

• Sökning och urval
  • Sker i ett gemensamt gränssnitt där Org‑admin kan hitta:
    • elever/barn, personal och vårdnadshavare,
    • synkroniserade såväl som manuella konton,
  • med stöd för flera sökvägar, t.ex.:
    • personnummer/TF‑nummer eller annat unikt ID,
    • namn (för‑/efternamn),
    • skola/enhet, klass/grupp/avdelning,

Radering av användarkonto med karenstid

Standardflödet för radering av ett användarkonto bygger på en karensbaserad process där kontot först markeras för radering och därefter endast raderas permanent om definierade villkor är uppfyllda. Utgångspunkten i systemet är att all radering av användarkonton sker via denna karensmodell; direkt radering utan karens är ett separat, mer restriktivt undantagsflöde.

När en Org‑admin har identifierat ett konto som ska tas bort (oavsett om kontot avser elev/barn, personal eller vårdnadshavare) initieras flödet genom åtgärden ”Markera för radering” på kontots detaljvy i den utökade användarhanteringen. Innan åtgärden kan genomföras visar systemet en bekräftelsedialog med:

• grundläggande identitets‑ och kontouppgifter enligt Org‑admins ordinarie behörighet, t.ex.
  • namn,
  • personnummer/ID (inkl. TF‑nummer eller annat alternativt ID),
  • roll/roller (elev/barn, personal, vårdnadshavare),
  • skol‑ och enhetskopplingar,
  • klass-/grupptillhörigheter,
  • eventuella vårdnadshavare–barn‑relationer,
• en kortfattad men tydlig beskrivning av konsekvenserna av raderingen, t.ex. att
  • användarkontot som identitet kommer att tas bort,
  • kopplingar till skolor, klasser, grupper och barn kommer att raderas,
  • kontorelaterad historik i Vklass (t.ex. resultat, inlämningar, närvaro, meddelanden) kan komma att gallras enligt systemets regler för kontoradering.

Org‑admin måste därefter aktivt bekräfta åtgärden (t.ex. genom att skriva ”RADERA” eller liknande bekräftelsetext) för att kontot ska läggas in i raderingsflödet. Ingen radering påbörjas utan en sådan explicit bekräftelse.

Efter bekräftelse får kontot den tekniska statusen ”Markerat för radering” och registreras i en särskild raderingslista (karenslista) med:

• tidpunkt då kontot markerades för radering (starttid för karensfönstret),
• aktuell organisations‑ och enhetstillhörighet,
• information om vem som initierat åtgärden.

Karenstiden är som utgångspunkt 48 timmar sammanhängande från starttidpunkten. Exakt längd kan fastställas som en systeminställning (t.ex. globalt värde eller konfigurerbar per organisation). Under karensperioden görs inga permanenta borttagningar av kontot eller dess historik; kontot betraktas som planerat för radering men är ännu inte tekniskt raderat. Karenstiden fungerar därmed som en säkerhetszon där:

• Vklass kan verifiera att personen inte längre förekommer i synkroniseringsunderlaget från verksamhetssystemen,
• Org‑admin har möjlighet att upptäcka och korrigera felaktiga beslut,
• temporära avvikelser eller fördröjningar i verksamhetssystemen inte omedelbart leder till oönskad radering.

Hur kontot visas och kan användas under karenstiden (t.ex. möjligheten att logga in, hur kontot visas i listor) beskrivs mer i avsnittet Statushantering under karenstid; i denna del fokuseras enbart villkoren för själva raderingsprocessen.

Kontinuerlig kontroll mot synkroniseringsunderlaget

Så länge ett konto finns i raderingslistan kontrollerar Vklass vid varje synkroniseringskörning om personen förekommer i synkroniseringsunderlaget från något verksamhetssystem. För varje karenspost lagras och uppdateras åtminstone:

• tidpunkt för senast kända förekomst i synkroniseringen,
• om personen vid senaste körning bedöms som ”aktiv” i källsystemet (d.v.s. förekommer i underlaget med någon roll eller koppling).

Raderingsvillkoret definieras som:

Användaren får inte ha förekommit i synkroniseringsunderlaget under en sammanhängande tidsperiod som motsvarar den konfigurerade karenstiden (t.ex. minst 48 timmar).

Praktiskt innebär detta att:

• När kontot först markeras för radering sätts starttid för karens, och systemet börjar mäta tiden sedan senaste kända förekomst i synkroniseringen.
• Om användaren inte dyker upp i någon synkroniseringskörning under hela karensperioden uppfylls villkoret för radering.
• Om användaren återkommer i synkroniseringsunderlaget under pågående karens:
  • karensräkningen nollställs,
  • kontot ligger kvar i raderingslistan, men markeras tydligt som ”fortsatt aktiv i källsystem”,
  • en ny sammanhängande karensperiod måste därefter löpa utan förekomst i synkroniseringen innan radering åter blir möjlig.

Detta säkerställer att konton som fortfarande styrs av verksamhetssystemen (t.ex. elev som tillfälligt felaktigt avslutats, personal som återanställts) inte oavsiktligt tas bort och återskapas på nytt vid senare synkronisering.

Administrativ översikt under karenstid

Org‑admin har via en dedikerad vy åtkomst till hela raderingslistan. För varje konto som är markerat för radering bör åtminstone följande uppgifter visas:

• identifierande uppgifter enligt Org‑admins ordinarie behörighet (så länge kontot inte är raderat), t.ex.
  • namn,
  • personnummer/ID,
  • roll/roller,
  • primär skola/enhet,
• tidpunkt då kontot markerades för radering,
• tidpunkt för senast kända förekomst i synkroniseringsunderlaget,
• aktuell status i förhållande till synkroniseringen, t.ex.
  • ”Ingen förekomst i synkronisering sedan <tidpunkt> – karens pågår”,
  • ”Har förekommit i senaste synkronisering – raderas inte”,
  • ”Villkor uppfyllda – väntar på slutlig radering”,
• beräknad tidigaste tidpunkt då permanent radering kan genomföras om villkoren för karens uppfylls.

I samma vy ska det finnas en tydlig och alltid tillgänglig funktion för ”Ångra radering” per konto. När Org‑admin väljer att ångra:

• tas kontot omedelbart bort ur raderingslistan,
• karensstatusen avlägsnas,
• kontot återgår till att hanteras som ett vanligt aktivt konto i Vklass (utan pågående raderingsflöde).

Det krävs ingen ytterligare bekräftelse för att avbryta en planerad radering; åtgärden kan genomföras när som helst under karenstiden fram till dess att den slutliga raderingen har påbörjats.

Exempel:
En rektor meddelar efter några timmar att en elev felaktigt markerats för radering – eleven ska fortsätta vara aktiv. Org‑admin öppnar raderingslistan, hittar eleven via namn eller personnummer och väljer ”Ångra radering”. Kontot tas då omedelbart bort från karenskön och påverkas inte av raderingsflödet.

Genomförande av slutlig radering

När systemet konstaterar att raderingsvillkoret är uppfyllt – d.v.s. att användaren inte har förekommit i synkroniseringsunderlaget under en sammanhängande period om minst den konfigurerade karenstiden (t.ex. 48 timmar) – flaggas karensposten som ”redo för radering”. Innan den permanenta raderingen faktiskt genomförs gör Vklass en sista kontroll mot den senast genomförda synkroniseringen:

• Om användaren fortfarande inte förekommer i synkroniseringsunderlaget:
  • påbörjas den definitiva raderingen som en systemstyrd bakgrundsprocess.
• Om användaren återigen förekommer i synkroniseringsunderlaget vid denna sista kontroll:
  • skjuts raderingen upp,
  • karensräkningen nollställs,
  • kontot kvarstår i raderingslistan med uppdaterad status ”Har förekommit i senaste synkronisering – raderas inte”.

Vid genomförd radering:

• tas användarkontot bort ur Vklass som inloggningsbar identitet,
• kopplingar till skolor, enheter, klasser, grupper och barn (för vårdnadshavare) avlägsnas,
• kontorelaterad data gallras i enlighet med de regler som definierats för kontoradering i Vklass, med beaktande av gällande juridiska krav (t.ex. arkivlagstiftning och lokala gallringsplaner).

Efter att raderingen slutförts:

• är ingen persondata om kontot längre sökbar eller åtkomlig via användargränssnittet,
• kontot visas inte längre i några listor eller sökresultat för skol‑ eller organisationsadministratörer,
• kontot kan inte återaktiveras internt; om personen återkommer i verksamhetssystemen skapas i så fall ett nytt konto enligt ordinarie synkroniseringslogik (om inte en spärrpost samtidigt införts, se avsnitt om spärrlista).

Loggning och gallring av raderingshändelser

Varje genomförd kontoradering via karensflödet loggas i den särskilda åtgärdsloggen. Loggposten innehåller:

• tidpunkt då den slutliga raderingen genomfördes,
• identifiering av ansvarig Org‑admin som initierat åtgärden,
• åtgärdstyp (t.ex. ”Radering av användarkonto efter karens”),
• en dataminimerad identifiering av det raderade kontot, t.ex.
  • de sex första siffrorna i personnumret eller motsvarande tekniskt ID,
  • förnamn,
  • skola/enhet vid tidpunkten för markering.

Ingen detaljerad kontohistorik eller övriga personuppgifter bevaras i loggen efter genomförd radering. Åtgärdsloggarna lagras endast under en begränsad, fastställd period (t.ex. 30 dagar eller enligt överenskomna regler) för att möjliggöra spårbarhet och revision. Därefter gallras logginformationen automatiskt, i linje med principen om dataminimering och organisationens gallringsregler.

Sammanfattningsvis säkerställer karensbaserad radering att:

• konton som inte längre ska finnas i Vklass verkligen försvinner på ett kontrollerat sätt,
• konton som fortfarande betraktas som aktiva i verksamhetssystemen inte oavsiktligt tas bort och därefter återskapas av synkronisering,
• Org‑admin har en tydlig och tidsmässigt avgränsad möjlighet att ångra felaktiga eller förhastade raderingsbeslut innan åtgärden blir irreversibel.

Direkt radering av användarkonto

Direkt radering är ett alternativt, mer ingripande flöde jämfört med standardflödet med karenstid. Det är avsett för tydligt avgränsade undantagsfall där ett användarkonto behöver tas bort omedelbart, och där Org‑admin redan har säkerställt att personen inte längre ska förekomma i relevanta verksamhetssystem. Åtgärden ska därför ses som ett komplement till, inte en ersättning för, radering med karenstid.

Förutsättningar och typiska användningsfall

Direkt radering får endast användas när följande förutsättningar är uppfyllda:

• Org‑admin har verifierat att personen inte längre ska finnas i de verksamhetssystem som försörjer Vklass med data (elev‑, personal‑ och/eller vårdnadshavarregister), och
• det finns ingen rimlig risk att personen återkommer i synkroniseringsunderlaget efter raderingen.

Typiska exempel där direkt radering är lämplig:

• Rent manuellt skapade konton som aldrig har funnits i något verksamhetssystem, t.ex.
  • testkonton som skapats för utbildning eller felsökning,
  • tillfälliga konton för externa konsulter eller praktikanter där organisationen säkerställt att personen inte kommer att registreras i källsystemen.
• Uppenbart felaktiga konton, t.ex.
  • konton skapade med felaktigt eller påhittat personnummer,
  • dubbletter som uppstått genom felregistrering, där källdata redan är rättad och personen inte längre förekommer i synkroniseringsunderlaget.
• Avslutade manuella specialfall, t.ex.
  • ett tillfälligt alias‑konto för en elev där organisationen har gått över till att använda elevens ordinarie synkroniserade konto och säkerställt att aliaset aldrig kommer att synkas in.

I osäkra fall, eller när personen fortfarande finns i något verksamhetssystem, ska radering med karenstid eller en kombination av karens och spärrlista användas i stället.

Initiering och bekräftelseflöde

Flödet inleds med att Org‑admin söker fram det aktuella kontot i den utökade användarhanteringen (oavsett om kontot avser elev/barn, personal eller vårdnadshavare, och oavsett om det är synkroniserat eller manuellt skapat).

På kontots detaljvy för radering:

• presenteras först standardalternativet ”Markera för radering (med karenstid)”,
• därutöver finns ett särskilt, inaktivt val för ”Direkt radering (ingen karenstid)”.

När Org‑admin aktiverar alternativet för direkt radering ska systemet:

1. Visa en tydlig varningstext som beskriver:
   • att kontot kommer att raderas omedelbart utan karensperiod,
   • att åtgärden inte kan ångras,
   • att kontot inte längre kommer att kunna användas varken för inloggning eller åtkomst till tidigare data.
2. Kräva en aktiv dubbel bekräftelse, t.ex.:
   • kryssruta ”Jag förstår att kontot raderas omedelbart och att åtgärden inte kan ångras”, och
   • separat knapp ”Bekräfta direkt radering”.

Ingen direkt radering får påbörjas utan att båda dessa steg har slutförts.

Teknisk kontroll mot synkroniseringsunderlaget

Innan Vklass genomför en direkt radering görs alltid en teknisk kontroll mot det aktuella synkroniseringsunderlaget. Syftet är att säkerställa att personen inte längre förekommer i de källor som styr skapande och uppdatering av konton i Vklass.

Kontrollen baseras på samma identitetsnyckel som används vid inläsning, t.ex.:

• personnummer,
• TF‑nummer (t.ex. 120813‑TF21), eller
• annat unikt ID som används i integrationen.

Systemet kontrollerar om:

• personen förekommer som elev/barn, personal eller vårdnadshavare i synkroniseringsunderlaget, och/eller
• det finns kvarvarande relationer (t.ex. vårdnadshavare–barn) som fortsatt rapporteras in för personen.

Resultatet hanteras enligt följande:

• Om personen fortfarande förekommer i synkroniseringsunderlaget:

  • den direkta raderingen avbryts,
  • inget konto tas bort,
  • Org‑admin får ett tydligt felmeddelande, t.ex.:

    ”Kontot kan inte raderas direkt eftersom personen fortfarande förekommer i synkroniseringsunderlaget. Uppdatera eller ta bort personen i verksamhetssystemet, eller använd spärrfunktionen om åtkomst ändå ska stoppas i Vklass.”

  • Org‑admin kan därefter välja att:
    • återgå till radering med karenstid, eller
    • lägga upp en spärrpost (t.ex. för en specifik vårdnadshavare–barn‑relation).

• Om personen inte förekommer i synkroniseringsunderlaget:

  • den direkta raderingen kan gå vidare efter bekräftelse,
  • systemet markerar i logikflödet att det inte finns någon aktuell källdata som riskerar att återskapa kontot automatiskt.

För konton som är rent manuellt skapade eller sedan tidigare helt borttagna ur källsystemet kommer kontrollen typiskt att visa att ingen motsvarande post finns i synkroniseringsunderlaget, vilket möjliggör omedelbar radering.

Genomförande och omedelbar effekt

När alla kontroller har passerat utan anmärkning och Org‑admin har genomfört sin dubbelbekräftelse utför Vklass den direkta raderingen som en omedelbar, atomär transaktion. Detta innebär bl.a. att:

• användarkontot som identitet tas bort från Vklass,
• kopplingar till skolor, enheter, klasser, grupper, barn och övriga relationer tas bort enligt gällande regler för kontoradering,
• kontorelaterad data i Vklass gallras i den omfattning som definierats för radering av konto (t.ex. resultat, inlämningar, närvaro och meddelanden), med beaktande av juridiska krav.

Direkta effekter i systemet:

• kontot slutar omedelbart att vara sökbart eller synligt i administrationsvyer,
• kontot visas inte längre i användarlistor, klasslistor eller vårdnadshavare‑vyer,
• användaren kan inte längre logga in, oavsett inloggningssätt (Vklass‑inloggning, BankID, SSO m.m.),
• eventuella pågående sessioner för kontot ska avslutas eller ogiltigförklaras så fort det är tekniskt möjligt.

Exempel:
En administratör har skapat ett rent testkonto med ett påhittat personnummer för att demonstrera funktioner i Vklass. När testet är klart söker Org‑admin upp kontot, väljer ”Direkt radering”, bekräftar åtgärden och får igenom teknisk kontroll (ingen förekomst i synkroniseringsunderlaget). Kontot försvinner omedelbart ur alla listor och kan inte längre användas.

Kombination med spärrlista

För att ytterligare minimera risken att en borttagen identitet oavsiktligt återskapas kan direkt radering kombineras med spärrfunktionen.

I raderingsdialogen för direkt radering ska det finnas möjlighet för Org‑admin att:

• markera att personen som helhet ska spärras från inläsning efter raderingen, och/eller
• för vårdnadshavare: markera att en specifik vårdnadshavare–barn‑relation ska spärras från att återskapas.

Om Org‑admin väljer ett av dessa alternativ:

• genomför Vklass först den direkta raderingen av kontot, och
• skapar därefter automatiskt en motsvarande spärrpost i spärrlistan.

Effekten blir att:

• ett tidigare raderat konto inte ny‑skapas vid en senare synkronisering, även om personen tillfälligt skulle återkomma i källdata,
• en spärrad vårdnadshavare–barn‑relation inte återupprättas i Vklass, även om relationen fortfarande finns kvar i folkbokföring eller elevregister under en övergångsperiod.

Exempel:
En vårdnadshavare har tillfälligt fått ett manuellt konto skapat utanför ordinarie källdata. När ärendet är avslutat beslutar huvudmannen att kontot ska tas bort och att relationen till ett visst barn inte ska kunna återskapas digitalt. Org‑admin väljer då direkt radering av kontot och att spärra relationen till barnet. Systemet raderar kontot och lägger samtidigt in relationen i spärrlistan.

Kombination med pågående karens

Ett konto kan redan vara markerat för radering med karenstid när Org‑admin beslutar att en omedelbar radering är nödvändig. I dessa fall hanteras direkt radering som en kontrollerad ”uppgradering” av den pågående åtgärden:

• När Org‑admin initierar direkt radering på ett konto som finns i karenslistan:
  • tas kontot först bort från raderingslistan (karensstatusen upphör),
  • därefter genomförs hela flödet för direkt radering, inklusive fullständig kontroll mot synkroniseringsunderlaget.
• Om kontrollen mot synkroniseringsunderlaget misslyckas (personen finns fortfarande i källdata) gäller:
  • den direkta raderingen stoppas,
  • kontot återgår antingen till:
    • pågående karensflöde (om Org‑admin inte uttryckligen har avbrutit detta innan), eller
    • vanligt aktivt konto om karensen dessförinnan avbrutits,
  • Org‑admin informeras om att direkt radering inte är möjlig och får vägledning om att i stället:
    • avvakta karenstiden,
    • uppdatera källdata, eller
    • använda spärrfunktionen vid behov.

På så sätt säkerställs att direkt radering aldrig kringgår de skydd som finns mot radering av personer som fortfarande är aktiva i verksamhetssystemen.

Loggning och gallring vid direkt radering

Varje genomförd direkt radering loggas i åtgärdsloggen på motsvarande sätt som radering efter karenstid, men med tydlig markering av åtgärdstyp.

För varje direkt radering registreras minst:

• tidpunkt då raderingen genomfördes,
• identifiering av ansvarig Org‑admin,
• åtgärdstyp (t.ex. ”Direkt radering av användarkonto”),
• eventuell koppling till spärrpost som skapats i samma flöde,
• en dataminimerad identifiering av det raderade kontot, t.ex.:
  • de sex första siffrorna i personnumret eller motsvarande tekniska ID‑del,
  • förnamn,
  • primär skola/enhet vid tidpunkten för raderingen.

Ingen detaljerad kontohistorik eller fullständiga personuppgifter bevaras i loggen efter genomförd radering. Åtgärdsloggar för direkt radering lagras endast under den fastställda, begränsade perioden (t.ex. 30 dagar) och gallras därefter automatiskt. Detta ger nödvändig spårbarhet och revisionsmöjlighet samtidigt som kraven på dataminimering och integritetsskydd upprätthålls.

Kontroll mot verksamhetssystem vid radering

All radering av användarkonton inom den utökade användarhanteringen ska föregås av en obligatorisk, teknisk kontroll mot verksamhetssystemen/synkroniseringsunderlaget. Syftet är att säkerställa att kontot inte längre betraktas som aktivt i något av de källsystem som försörjer Vklass med användar‑ och relationsdata, och därmed inte riskerar att återskapas automatiskt. Funktionen får aldrig genomföra en slutlig radering av ett konto som fortfarande förekommer i synkroniseringsunderlaget för den aktuella organisationen.

Kontrollen gäller både vid radering med karenstid och vid direkt radering och baseras alltid på samma identitetsnyckel som används i integrationerna, t.ex. personnummer, TF‑nummer (t.ex. 120813‑TF21) eller annat unikt ID.

Övergripande kontrollprinciper

• Kontroll ska ske mot samtliga aktiva synkroniseringsflöden för organisationen (elev/barn, personal, vårdnadshavare m.fl.), inte enbart mot ett enskilt system.
• En person betraktas som ”förekommande i synkroniseringsunderlaget” om identiteten finns med i någon roll (elev/barn, personal, vårdnadshavare) i det underlag som Vklass använder för den organisationen.
• Radering av ett användarkonto i Vklass är endast tillåten om:
  • personen inte längre förekommer i något verksamhetssystem/synkroniseringsunderlag, och
  • (vid karensflöde) personen inte har förekommit i synkroniseringsunderlaget under minst den konfigurerade karenstiden i en sammanhängande period (t.ex. 48 timmar).

Kontroll vid radering med karenstid

Vid radering med karenstid sker kontrollen både löpande under karensperioden och direkt innan den slutliga raderingen genomförs.

När ett konto markeras för radering:

• skapas en karenspost med starttid (tidpunkt då markeringen gjordes),
• systemet börjar spåra tiden sedan senaste kända förekomst av personen i synkroniseringsunderlaget, baserat på den identitetsnyckel som används i integrationen.

Under hela karensperioden (t.ex. 48 timmar):

• vid varje synkroniseringskörning kontrollerar Vklass om personen förekommer i synkroniseringsunderlaget,
• tidpunkt för ”senast sedd i synkronisering” uppdateras för kontot när en träff hittas,
• raderingsvillkoret definieras som:

  ”Nuvarande tidpunkt minus tidpunkten för senast kända förekomst i synkroniseringsunderlaget ska vara minst lika lång som den konfigurerade karenstiden.”

Konsekvenser:

• Om personen inte förekommer i någon synkroniseringskörning under hela karensperioden uppfylls villkoret för radering när karenstiden löpt ut.
• Om personen återkommer i synkroniseringsunderlaget under pågående karens:
  • uppdateras tidpunkten för senast kända förekomst till den aktuella synkroniseringstidpunkten,
  • den effektiva karenstiden börjar räknas om från denna tidpunkt,
  • kontot kvarstår i status ”Markerat för radering”, men kan inte raderas förrän en ny, sammanhängande period om minst karenstiden har passerat utan förekomst.

Innan den slutliga raderingen faktiskt påbörjas ska systemet göra en sista kontroll:

• antingen genom att verifiera mot det senaste kompletta synkroniseringsunderlaget att personen inte längre förekommer, och/eller
• genom ett riktat uppslag mot integrerade verksamhetssystem (där sådan funktionalitet finns) med frågan ”finns denna identitet fortfarande i något källsystem?”.

Om den sista kontrollen visar att personen fortfarande förekommer i synkroniseringsunderlaget:

• får raderingen inte genomföras,
• kontot ligger kvar i karenslistan,
• karenstidens uppmätta period justeras i enlighet med den senaste kända förekomsten,
• i raderingsvyn ska det tydligt framgå att kontot inte kan raderas eftersom användaren fortfarande är aktiv i synkroniseringen.

Exempel:
En elev avslutas i elevregistret och markeras därefter för radering i Vklass. Under karenstiden ångrar skolan avslutet och eleven återaktiveras i elevregistret. Vid nästa synkronisering återkommer eleven i synkroniseringsunderlaget. Vklass uppdaterar då ”senast sedd”‑tidpunkten och raderingen stoppas. Kontot ligger kvar i status ”Markerat för radering, användare åter aktiv i källsystem” tills Org‑admin antingen ångrar raderingen eller eleven senare återigen avslutas och karensvillkoren uppfylls.

Kontroll vid direkt radering

Vid direkt radering sker kontrollen omedelbart innan någon raderingsåtgärd utförs.

När Org‑admin initierar direkt radering av ett konto:

• gör Vklass en direkt kontroll mot synkroniseringsunderlaget (och vid behov mot verksamhetssystemen) baserat på kontots aktuella identitetsnyckel,
• kontrollen ska verifiera att det inte finns någon aktiv post i något av källsystemen som motsvarar denna identitet, oavsett roll (elev/barn, personal, vårdnadshavare).

Om kontrollen visar att personen fortfarande finns i synkroniseringsunderlaget:

• avbryts den direkta raderingen innan några data ändras,
• systemet visar ett tydligt fel-/informationsmeddelande till Org‑admin, t.ex.:

  ”Kontot kan inte raderas direkt eftersom personen fortfarande förekommer i synkroniseringsunderlaget. Avsluta eller ändra personen i verksamhetssystemet, eller använd spärrfunktionen om åtkomst ska hindras i Vklass trots att källdata ännu inte är uppdaterad.”

• Org‑admin hänvisas därmed till:
  • att först säkerställa att personen avslutas eller ändras korrekt i källsystemet, och/eller
  • att använda spärrlistan om åtkomsten i Vklass omedelbart behöver stoppas trots att källdata under en övergångsperiod visar något annat.

Endast om kontrollen bekräftar att personen inte längre förekommer i synkroniseringsunderlaget kan direkt radering gå vidare efter Org‑admins uttryckliga dubbelbekräftelse.

Exempel:
Ett manuellt skapat testkonto ska tas bort. Vid direkt radering gör Vklass en kontroll mot elev‑, personal‑ och vårdnadshavarunderlagen. Ingen motsvarighet hittas

Hantering av användare i karenslista

Karenslistan (raderingskön) är den centrala vy där behöriga användare av den utökade användarhanteringen (primärt Org‑admin) kan se och hantera alla användarkonton som har status ”Markerat för radering” men där den slutliga raderingen ännu inte har genomförts. Listan fungerar som ett operativt arbetsverktyg för pågående raderingsärenden och ger en samlad överblick över:

• vilka konton som omfattas,
• var i processen respektive konto befinner sig,
• hur kontots situation ser ut i förhållande till synkroniseringsunderlaget.

Endast behöriga administratörer (Org‑admin och eventuella särskilt utsedda systemnära administratörer) har åtkomst till karenslistan. Varken skoladministratörer eller andra lokala roller ser denna kö.

För varje konto i karenslistan ska åtminstone följande information vara synlig fram till dess att raderingen har slutförts:

• Identifierande uppgifter enligt Org‑admins ordinarie behörighet, t.ex.
  • namn,
  • personnummer/ID (inkl. TF‑nummer eller annan alternativ identitet),
  • roll/roller (elev/barn, personal, vårdnadshavare).
• Organisatoriska kopplingar, t.ex.
  • primär skola/enhet,
  • relevanta klass‑, grupp‑ eller avdelningskopplingar,
  • för vårdnadshavare: barnkopplingar som fortfarande finns definierade i Vklass.
• Tidpunkt för markering
  • när kontot markerades för radering (starttid för karensfönstret).
• Senaste kända förekomst i synkroniseringen
  • tidpunkt då användaren senast förekom i synkroniseringsunderlaget från något verksamhetssystem, baserat på kontots identitetsnyckel.
• Beräknad tidigaste raderingstid
  • den tidigaste möjliga tidpunkt då den slutliga raderingen kan genomföras, under förutsättning att användaren inte återkommer i synkroniseringsunderlaget,
  • beräknad som ”senast kända förekomst i synkronisering + konfigurerad karenstid” (t.ex. 48 timmar).
• Aktuell status i raderingsflödet, exempelvis:
  • ”I karens – ingen förekomst i synkronisering sedan <tidpunkt> (kvarvarande karenstid: <xx timmar>)”
  • ”I karens – förekommer fortfarande i synkronisering (raderas ej, karenstid räknas om från senaste förekomst)”
  • ”Villkor uppfyllda – väntar på slutlig kontroll mot verksamhetssystem”
  • ”Radering stoppad – användaren åter aktiv i synkroniseringen”.

Karenslistan uppdateras automatiskt i samband med varje genomförd synkronisering. När en användare som finns i karenslistan återkommer i synkroniseringsunderlaget:

• uppdateras fältet ”senast kända förekomst i synkronisering” till tidpunkten för den senaste körningen,
• räkningen av karenstid nollställs och börjar löpa från denna nya tidpunkt,
• statusen för kontot ändras så att det tydligt framgår att kontot för närvarande inte kan raderas, eftersom användaren fortfarande är aktiv i källsystemet.

Exempel:
En elev markeras för radering måndag kl. 10.00. Eleven finns inte längre i elevregistret och syns därför inte i synkroniseringen på måndag kväll eller tisdag morgon. Tisdag kl. 15.00 ångrar skolan avslutet och eleven återaktiveras i elevregistret. Vid tisdagens kvällssynkronisering dyker eleven upp igen i underlaget. Karenslistan uppdateras då så att ”senast kända förekomst i synkronisering” sätts till tisdag kl. 22.00 och status ändras till ”I karens – förekommer fortfarande i synkronisering (raderas ej)”. Den tidigare karenstiden från måndag räknas inte längre; en ny sammanhängande period måste löpa innan radering åter blir möjlig.

Från karenslistan ska Org‑admin kunna utföra följande åtgärder per konto:

• Ångra radering

  • Tar bort kontot ur karenslistan och avbryter därmed den planerade raderingen.
  • Kontot tappar statusen ”Markerat för radering” och återgår till att hanteras som ett vanligt aktivt konto i Vklass.
  • Åtgärden är omedelbar och kräver inte någon ytterligare systemprocess; ingen radering kommer att initieras för kontot efter att åtgärden genomförts.

• Visa detaljer

  • Öppnar en detaljerad vy för det aktuella kontot, där Org‑admin ges en översikt på hög nivå över:
    • roller och samtliga skol-/enhetskopplingar,
    • klass‑, grupp‑ och avdelningstillhörigheter,
    • vårdnadshavare–barn‑relationer (där det är relevant),
    • en sammanfattning av huvudsakliga datatyper som är kopplade till kontot (t.ex. förekomst av närvarodata, resultat, inlämningar, meddelanden).
  • Syftet är att underlätta en välgrundad bedömning av om raderingen ska ligga kvar, ångras eller kompletteras med exempelvis en spärr av inläsning.

• Initiera direkt radering (endast där regelverket medger detta)

  • Om Org‑admin, utifrån verksamhetens beslut, bedömer att karensflödet inte längre är nödvändigt för ett visst konto kan kontot behandlas som kandidat för direkt radering.
  • När denna åtgärd väljs:
    • tas kontot först bort ur karenslistan (karensstatusen upphör),
    • därefter initieras det separata flödet för direkt radering, inklusive en ny obligatorisk kontroll mot synkroniseringsunderlaget.
  • Om kontrollen visar att användaren fortfarande förekommer i synkroniseringsunderlaget:
    • avbryts direkt radering,
    • kontot får inte raderas,
    • Org‑admin informeras om att aktiv källdata förhindrar direkt radering och kan välja att:
      • låta kontot ligga kvar i karens (om detta inte redan avbrutits), eller
      • avbryta raderingsprocessen helt och hållet.

Exempel:
Ett rent manuellt testkonto har av misstag markerats för radering med karenstid. Org‑admin ser i karenslistan att kontot är manuellt och aldrig förekommit i synkroniseringen. I stället för att vänta ut karenstiden väljer Org‑admin ”Initiera direkt radering”, genomför bekräftelseflödet och kontot raderas omedelbart efter godkänd kontroll.

För att stödja hantering i större organisationer ska karenslistan erbjuda kraftfulla möjligheter till sökning, filtrering och sortering. Minst följande funktioner ska finnas:

• Sökning
  • fritextsökning på personnummer/ID (inkl. TF‑nummer) och namn.
• Filtrering
  • på roll (elev/barn, personal, vårdnadshavare),
  • på skola/enhet,
  • på status i raderingsflödet, t.ex.:
    • ”Ingen förekomst i synkronisering (karenstid löper)”,
    • ”Förekommer i synkronisering (raderas ej)”,
    • ”Väntar på slutlig kontroll”.
• Sortering
  • på tidpunkt då kontot markerades för radering,
  • på beräknad tidigaste raderingstid,
  • vid behov även på namn eller personnummer/ID för att underlätta manuell genomgång.

När alla villkor för radering är uppfyllda – d.v.s.:

• användaren har inte förekommit i synkroniseringsunderlaget under minst den konfigurerade karenstiden (t.ex. 48 sammanhängande timmar), och
• den avslutande kontrollen mot verksamhetssystem/synkroniseringsunderlag bekräftar att personen fortfarande är frånvarande,

ska Vklass automatiskt påbörja och genomföra den slutliga raderingen utan att Org‑admin behöver göra något ytterligare. I samband med detta:

• utförs själva raderingsprocessen (borttag av konto, kopplingar och kontorelaterad data enligt definierade regler),
• kontot tas bort ur karenslistan,
• en åtgärdsloggpost skapas med dataminimerad information (t.ex. sex första siffrorna i personnummer/ID, förnamn och skola/enhet), som lagras endast under den tidsbegränsade period som definierats för åtgärdsloggen.

Karenslistan ska enbart innehålla konton med pågående, ännu inte slutförd radering. När:

• ett konto har raderats slutligt, eller
• raderingen har ångrats av Org‑admin,

får kontot inte längre visas i karenslistan. Uppföljning av genomförda raderingar sker i stället via åtgärdsloggen. Detta säkerställer att karenslistan förblir en renodlad arbetskö för aktuella ärenden, inte en historikvy.

Om tekniska fel uppstår i samband med synkroniseringen eller vid kontroll mot verksamhetssystemen (t.ex. om den senaste synkroniseringskörningen misslyckats eller inte har fullständigt underlag):

• ska detta tydligt indikeras i anslutning till karenslistan, t.ex. genom en statusrad eller varningsikon,
• karenslistans statusuppgifter ska markeras som ”ej uppdaterade sedan <tidpunkt>” eller motsvarande,
• ingen automatisk övergång till slutlig radering får genomföras förrän:
  • en lyckad synkronisering har slutförts, och
  • en ny, godkänd kontroll mot synkroniseringsunderlaget bekräftar att användaren inte förekommer.

Exempel:
Om en nattlig synkronisering misslyckas helt ska inga konton gå vidare från status ”Villkor uppfyllda – väntar på slutlig kontroll” till faktisk radering förrän nästa lyckade synkronisering genomförts. På så sätt minimeras risken att konton raderas baserat på ofullständig eller utebliven källdata.

Statushantering under karenstid

Status för konton som ligger i karens styrs uteslutande av systemet och uppdateras automatiskt utifrån:

• resultatet av varje synkroniseringskörning (förekommer/inte förekommer i synkroniseringsunderlaget),
• tekniska förutsättningar (t.ex. lyckad/misslyckad synkronisering),
• explicita åtgärder från behörig Org‑admin (t.ex. ”Ångra radering” eller initiering av ”Direkt radering”).

Syftet med statusmodellen är att ge Org‑admin en tydlig, konsekvent och reviderbar bild av:

• var i raderingsflödet ett konto befinner sig,
• varför ett konto ännu inte är raderat,
• när ett konto tidigast kan raderas, givet både karenstid och aktuell förekomst i synkroniseringsunderlaget.

Statusfältet är läsbart men inte manuellt redigerbart; samtliga statusövergångar styrs av systemlogik och dokumenteras indirekt via åtgärdsloggen.

Systemstyrda statuslägen för konton i karenslista

Följande grundläggande statuslägen används för konton som befinner sig i karenslistan.

---

Väntar på första kontroll mot synkronisering

Detta statusläge tilldelas omedelbart när ett konto markeras för radering och Org‑admin har bekräftat åtgärden. Kontot har då:

• fått en karenspost med starttid = tidpunkten för markeringen,
• lagts in i karenslistan,
• ännu inte genomgått någon kontroll mot den synkronisering som körs efter markeringen.

Egenskaper:

• Karenstiden (t.ex. 48 timmar) börjar räknas från markeringstidpunkten.
• Kontot kvarstår i detta läge fram till dess att nästa lyckade synkroniseringskörning har genomförts för organisationen.
• Efter första lyckade synkronisering uppdateras status automatiskt till något av de två karenslägena nedan, beroende på om användaren förekommer i synkroniseringsunderlaget eller inte.

Exempel:
En elev markeras för radering måndag kl. 10.15. Nästa ordinarie nattlig synkronisering körs måndag kl. 23.00. Under perioden 10.15–23.00 visas kontot i karenslistan som ”Väntar på första kontroll mot synkronisering”.

---

I karens – förekommer i synkronisering

Detta läge innebär att kontot är markerat för radering, men att användaren fortfarande finns med i det senaste synkroniseringsunderlaget från något verksamhetssystem (oavsett roll: elev/barn, personal, vårdnadshavare).

Egenskaper:

• Systemet registrerar tidpunkt för senast kända förekomst i synkroniseringsunderlaget.
• Karenstiden anses inte uppfylld så länge användaren förekommer i underlaget; det krävs en sammanhängande period om minst karenstiden (t.ex. 48 timmar) utan förekomst.
• Varje ny synkroniseringskörning som fortfarande innehåller användaren:
  • uppdaterar ”senast förekom i synkronisering” till den nya tidpunkten,
  • skjuter därmed effektivt karensfönstret framåt i tiden.
• I karenslistan ska det tydligt framgå att:
  • kontot inte kommer att raderas så länge användaren förekommer i synkroniseringsunderlaget (t.ex. genom text i stil med ”Förekommer fortfarande i synkronisering – raderas inte”).

Exempel:
En lärare avslutas av misstag i ett personalsystem och markeras därför för radering i Vklass. Innan ändringen hinner slå igenom fullt ut rättas felet i personalsystemet, och läraren finns fortsatt med i varje synkroniseringskörning. Kontot ligger då kvar i status ”I karens – förekommer i synkronisering”, och karenstiden startar aldrig i praktiken.

---

I karens – ingen förekomst i synkronisering (karenstid pågår)

Detta läge innebär att:

• kontot är markerat för radering, och
• användaren inte har förekommit i synkroniseringsunderlaget sedan en viss tidpunkt,
• men att den konfigurerade karenstiden (t.ex. 48 timmar) ännu inte löpt ut.

Egenskaper:

• Systemet beräknar fortlöpande tiden sedan:
  • senast kända förekomst i synkroniseringen, eller
  • markeringstidpunkten, om användaren aldrig har synts i någon synkronisering efter markeringen.
• I karenslistan ska minst följande framgå:
  • när användaren senast förekom i synkroniseringsunderlaget (eller att användaren inte har förekommit sedan markeringstidpunkten),
  • hur lång kvarvarande karenstid som återstår (t.ex. ”12 timmar kvar”),
  • beräknad tidigaste möjliga raderingstidpunkt, givet att användaren fortsatt är frånvarande.
• Om användaren under detta läge återkommer i synkroniseringsunderlaget:
  • byter kontot automatiskt status till ”I karens – förekommer i synkronisering”,
  • ”senast kända förekomst” uppdateras,
  • karensräkningen nollställs och måste börja om från den nya förekomsttiden.

Exempel:
En vuxenstuderande avslutas i elevregistret fredag kl. 09.00 och markeras för radering. Studenten finns inte med i nattliga synkroniseringar fredag och lördag, vilket innebär att kontot under lördagen ligger i status ”I karens – ingen förekomst i synkronisering (karenstid pågår)” med ett fåtal timmar kvar tills 48‑timmarsgränsen nås.

---

Redo för radering – väntar på slutlig kontroll/genomförande

Detta läge inträffar när systemet beräknat att användaren inte har förekommit i synkroniseringsunderlaget under en sammanhängande period som är minst lika lång som den konfigurerade karenstiden. Det tidsmässiga villkoret för radering är därmed uppfyllt.

Egenskaper:

• Kontot markeras som ”Redo för radering” i karenslistan.
• Innan den definitiva raderingen inleds gör systemet en sista obligatorisk kontroll mot:
  • senaste kompletta synkroniseringsunderlag, och/eller
  • eventuella riktade uppslag mot verksamhetssystem (där sådant stöd finns).
• Om kontrollen bekräftar fortsatt frånvaro:
  • initieras den permanenta raderingen som en bakgrundsprocess,
  • kontot tas bort ur karenslistan när raderingen slutförts,
  • åtgärden loggas i åtgärdsloggen.
• Om kontrollen visar att användaren trots allt förekommer i synkroniseringsunderlaget:
  • ändras status tillbaka till ”I karens – förekommer i synkronisering”,
  • ingen radering genomförs,
  • karenstiden måste börja löpa om från den senaste förekomsttidpunkten.

Exempel:
En elev har inte funnits med i någon synkronisering under 48 timmar och hamnar i status ”Redo för radering”. Strax före raderingen visar en ny synkronisering att eleven återaktiverats i elevregistret (t.ex. efter ändrad skolplacering). Systemet returnerar då kontot till status ”I karens – förekommer i synkronisering” och ingen radering sker.

---

Tillfälligt stoppad – avvaktar lyckad synkronisering

Detta läge används när Vklass tillfälligt inte kan genomföra tillförlitliga kontroller mot synkroniseringsunderlaget, t.ex. på grund av:

• misslyckade eller avbrutna synkroniseringskörningar,
• kända integrationsfel,
• tekniskt underhåll som innebär att aktuellt synkroniseringsunderlag saknas eller är ofullständigt.

Egenskaper:

• Konton i detta läge kan inte:
  • gå vidare till status ”Redo för radering”, eller
  • raderas slutligt,
    även om den tidsmässiga karenstiden (t.ex. 48 timmar) formellt är uppfylld.
• I karenslistan ska det tydligt framgå att:
  • raderingsprocessen är pausad av tekniska skäl,
  • ingen automatisk radering kommer att ske förrän en lyckad synkronisering har genomförts och en ny kontroll har bekräftat läget.
• När synkroniseringen åter fungerar:
  • uppdateras status automatiskt till något av de ordinarie karenslägena:
    • ”I karens – förekommer i synkronisering”,
    • ”I karens – ingen förekomst i synkronisering (karenstid pågår)”, eller
    • ”Redo för radering – väntar på slutlig kontroll/genomförande”,
  • exakt läge beror på resultatet av den första lyckade synkroniseringskörningen efter avbrottet.

Exempel:
En nattlig synkronisering misslyckas helt på grund av ett integrationsfel. Flera konton som tidsmässigt skulle kunna gå vidare till radering flaggas då som ”Tillfälligt stoppad – avvaktar lyckad synkronisering”. Först när nästa synkronisering har slutförts utan fel kan dessa konton åter utvärderas och eventuellt övergå till ”Redo för radering”.

---

Statuspåverkan av manuella åtgärder

Utöver de systemstyrda statuslägena påverkas ett kontos status av två typer av explicita åtgärder från Org‑admin: ”Ångra radering” och ”Övergår till direkt radering”.

---

Ångrad radering

När Org‑admin väljer ”Ångra radering” för ett konto i karenslistan:

• tas kontot omedelbart bort ur karenslistan,
• samtliga karensrelaterade statusar upphör att gälla,
• kontot återgår till att vara ett vanligt aktivt konto i Vklass (under fortsatt kontroll av ordinarie synkronisering).

Det finns inget separat statusläge ”Ångrad radering” i karenslistan, eftersom kontot inte längre omfattas av raderingsflödet. I stället:

• registreras åtgärden i åtgärdsloggen med uppgift om:
  • tidpunkt,
  • ansvarig Org‑admin,
  • vilken karenspost som avbrutits (på en dataminimerad identifieringsnivå).

Exempel:
En elev har felaktigt markerats för radering. När Org‑admin uppmärksammas på felet öppnar hen karenslistan, söker fram eleven och väljer ”Ångra radering”. Eleven försvinner då från karenslistan och fortsätter visas som vanligt i elevlistor och klassvyer.

---

Övergår till direkt radering

För vissa konton i karens (t.ex. manuella testkonton) kan Org‑admin bedöma att karensflödet inte längre behövs och i stället vilja genomföra en omedelbar, direkt radering.

När åtgärden ”Initiera direkt radering” väljs på ett konto som befinner sig i karenslista:

1. Tas kontot först ur karensflödet:

   • kontot tas bort från karenslistan,
   • karensstatusen upphör att gälla.

2. Därefter påbörjas det separata flödet för direkt radering, vilket alltid innefattar:

   • ny obligatorisk kontroll mot synkroniseringsunderlaget,
   • dubbel bekräftelse från Org‑admin,
   • eventuell kombination med spärrlista (om så väljs).

3. Resultatet kan bli något av följande:

   • Direkt radering genomförs

Ångra planerad radering

Att ångra en planerad radering innebär att Org‑admin avbryter ett redan initierat raderingsflöde för ett specifikt användarkonto, innan den slutliga, permanenta raderingen har påbörjats. Åtgärden är endast möjlig för konton som fortfarande:

• finns kvar i karenslistan, och
• har någon av de karensrelaterade statusarna (t.ex. ”I karens – förekommer i synkronisering”, ”I karens – ingen förekomst i synkronisering (karenstid pågår)”, ”Redo för radering – väntar på slutlig kontroll”).

När ett konto väl har raderats slutligt tas det bort ur karenslistan och kan därefter inte återställas eller ångras via denna funktion. Eventuell uppföljning av raderingen kan då endast ske via åtgärdsloggen.

Org‑admin initierar åtgärden genom att:

1. öppna karenslistan i den utökade användarhanteringen,
2. söka fram eller filtrera fram det aktuella kontot (t.ex. via namn, personnummer/ID, skola/enhet eller roll),
3. välja åtgärden Ångra radering på den rad som avser det aktuella kontot.

När Ångra radering väljs ska systemet alltid visa en kort, men tydlig, bekräftelsedialog som minst klargör att:

• kontot kommer att tas bort från karenslistan,
• inga automatiska raderingsåtgärder längre kommer att utföras för kontot inom ramen för detta raderingsärende,
• kontot fortsätter att fungera som ett vanligt aktivt användarkonto i Vklass tills en ny, separat åtgärd initieras.

Org‑admin måste aktivt bekräfta åtgärden (t.ex. genom att klicka på ”Bekräfta” eller motsvarande). Om bekräftelsen avbryts (t.ex. genom att stänga dialogen eller välja ”Avbryt”) genomförs ingen förändring och kontot ligger kvar i karensflödet med oförändrad status.

När bekräftelsen genomförts:

• tas kontot omedelbart bort ur karenslistan,
• samtliga karensrelaterade statusar upphör att gälla,
• kontot betraktas åter som ett normalt aktivt användarkonto i Vklass med oförändrade roller, kopplingar och historik.

Konsekvenserna av en ångrad planerad radering är bland annat att:

• ingen automatisk radering längre kommer att ske för det aktuella kontot baserat på det tidigare initierade ärendet,
• all framtida hantering av kontot (t.ex. ny radering, sammanslagning med ett annat konto eller spärrning av inläsning) kräver att Org‑admin uttryckligen startar ett nytt ärende via den utökade användarhanteringen.

Ångra planerad radering påverkar endast själva raderingsflödet. Om samma konto parallellt omfattas av andra åtgärder – till exempel:

• en personbaserad spärrpost i spärrlistan, eller
• en spärrad vårdnadshavare–barn‑relation kopplad till kontot

– ska dessa spärrar inte automatiskt hävas när raderingen ångras. De fortsätter att gälla tills Org‑admin aktivt ändrar eller tar bort dem via spärrfunktionen. På så sätt hålls beslut om radering åtskilda från beslut om blockering av inläsning och åtkomst.

Exempel:
En elev har avslutats i elevregistret och markerats för radering i Vklass. Innan karenstiden löpt ut får Org‑admin besked från skolan om att eleven ska återuppta sina studier och därför inte ska gallras. Org‑admin öppnar karenslistan, söker fram eleven via personnummer, väljer Ångra radering och bekräftar. Elevkontot tas bort från karenslistan, fortsätter vara aktivt och kommer inte att raderas automatiskt. Skulle eleven senare ändå behöva tas bort måste Org‑admin initiera en ny radering.

Själva åtgärden ”Ångra planerad radering” loggas i åtgärdsloggen på samma sätt som övriga centrala åtgärder i funktionen. Loggposten ska minst innehålla:

• tidpunkt då åtgärden genomfördes,
• identifiering av ansvarig Org‑admin,
• åtgärdstyp (t.ex. ”Ångrad planerad radering”),
• en dataminimerad identifiering av det berörda kontot (t.ex. de sex första siffrorna i personnumret eller motsvarande tekniskt ID, förnamn och organisatorisk tillhörighet vid tidpunkten för åtgärden).

Åtgärdsloggen för denna typ av händelser lagras endast under den begränsade tidsperiod som definierats för funktionen och gallras därefter automatiskt, i linje med principen om dataminimering och organisationens gallringsregler.

Återkomst via synkronisering under karens

När en användare som är markerad för radering återkommer i synkroniseringsunderlaget under pågående karenstid ska detta alltid tolkas som att personen fortfarande betraktas som aktiv i minst ett av verksamhetssystemen. I ett sådant läge får raderingsflödet aldrig gå vidare till slutlig radering förrän en ny sammanhängande karensperiod om minst den konfigurerade karenstiden (t.ex. 48 timmar) har passerat utan att personen förekommer i någon synkronisering.

Vid varje genomförd synkroniseringskörning:

• jämför Vklass identitetsnyckeln för alla konton i karenslistan (t.ex. personnummer, TF‑nummer eller annat unikt ID) mot det aktuella synkroniseringsunderlaget för samtliga relevanta flöden (elev/barn, personal, vårdnadshavare),
• uppdateras respektive karenspost automatiskt utifrån om identiteten återfunnits eller inte.

Om en användare som ligger i karenslistan återfinns i synkroniseringsunderlaget ska följande ske utan manuell inblandning:

• Kontots status sätts eller återgår till ”I karens – förekommer i synkronisering”.
• Fältet senast kända förekomst i synkronisering uppdateras till tidpunkten för den aktuella synkroniseringskörningen.
• Den pågående karenstiden nollställs: den sammanhängande period som krävs för radering börjar räknas om från denna nya tidpunkt.

Detta innebär att raderingsvillkoret tidsmässigt definieras som:

Nuvarande tidpunkt minus ”senast kända förekomst i synkronisering” ska vara minst lika lång som den konfigurerade karenstiden (t.ex. 48 timmar) utan att någon ytterligare förekomst har noterats under perioden.

I karenslistans vy ska denna återkomst framgå tydligt för Org‑admin. För varje berört konto ska det bland annat framgå:

• att användaren har förekommit i en nylig synkronisering (med angiven datum- och tidsstämpel),
• att kontot, givet den senaste förekomsten, inte kan raderas förrän en ny full karensperiod har förflutit utan ytterligare förekomst i synkroniseringsunderlaget,
• hur lång uppskattad tid som återstår innan radering åter kan bli möjlig om inga nya förekomster sker.

Denna logik gäller oavsett hur användarens innehåll i synkroniseringsunderlaget ser ut vid återkomsten:

• samma eller ändrad roll (elev/barn, personal, vårdnadshavare),
• samma eller förändrad skol-/enhetstillhörighet,
• uppdaterade klasser, grupper eller vårdnadshavarrelationer.

Så länge identitetsnyckeln (t.ex. personnummer eller TF‑nummer) förekommer i något av de aktiva synkroniseringsflödena betraktas personen som ”förekommande” och radering är inte tillåten.

Exempel 1 – elev återinskriven under karens
En elev avslutas i elevregistret och markeras för radering i Vklass. Efter 30 timmar beslutar skolan att eleven ska återinskrivas. Eleven läggs in på nytt i elevregistret och dyker upp i nästa natts synkronisering. Vklass uppdaterar då karensposten:

• status ändras till ”I karens – förekommer i synkronisering”,
• senast kända förekomst i synkronisering sätts till tidpunkten för den nya synkroniseringen,
• den tidigare 30‑timmarsperioden faller bort och en ny fullständig karenstid måste förflyta innan radering åter kan övervägas.

Exempel 2 – personal byter enhet men ligger kvar i karens
En lärare som tidigare avslutats i ett personalsystem och markerats för radering i Vklass dyker åter upp i synkroniseringsunderlaget, nu kopplad till en annan skola inom samma organisation. Trots att skol-/enhetskopplingen är förändrad behandlas detta som en klar indikation på fortsatt aktivitet:

• kontot ligger kvar i karenslistan med uppdaterad status ”I karens – förekommer i synkronisering”,
• radering kan inte genomföras,
• Org‑admin kan, utifrån verksamhetens beslut, antingen:
  • låta kontot ligga kvar i karens (varvid radering endast kan ske efter en ny full karensperiod utan förekomst), eller
  • ångra den planerade raderingen om kontot ska finnas kvar permanent.

Om en användare återkommer i synkroniseringsunderlaget precis vid eller strax före den tidpunkt då systemet annars skulle initiera slutlig radering (status ”Redo för radering – väntar på slutlig kontroll/genomförande”), ska den avslutande kontrollen mot verksamhetssystemen förhindra att raderingen påbörjas:

• återkomsten registreras,
• status ändras tillbaka till ”I karens – förekommer i synkronisering”,
• raderingsprocessen stoppas helt för detta ärende,
• en ny karensperiod måste därefter löpa ut utan förekomst innan kontot på nytt kan klassas som redo för radering.

Org‑admin kan i ett sådant läge:

• välja att låta kontot ligga kvar i karens (som ett tydligt tecken på att radering är önskad först när källdata faktiskt visar att personen upphört), eller
• aktivt avbryta raderingen genom att använda funktionen Ångra radering, om det står klart att personen inte längre ska gallras.

Själva återkomsten i synkroniseringsunderlaget genererar ingen separat åtgärdspost i åtgärdsloggen, men den påverkar:

• tidstämplarna och statusen i karensposten för det aktuella kontot,
• om och när villkoren för slutlig radering kan uppfyllas.

Detta säkerställer att:

• inga användarkonton raderas så länge verksamhetssystemen signalerar att personen ska finnas kvar i organisationen,
• Org‑admin alltid kan se i karenslistan varför en radering ännu inte har genomförts (t.ex. på grund av återkommande förekomster i synkroniseringen),
• raderingsbeslut och faktisk gallring i Vklass hålls strikt beroende av aktuell källdata, i linje med principerna om riktighet och spårbarhet.

Loggning vid radering av användarkonto

All hantering av radering av användarkonton – inklusive markering för radering, ångring, genomförd radering och avbrutna försök – loggas i en särskild åtgärdslogg för kontoradering. Loggen är en del av den generella åtgärdsloggen i Vklass, men är endast åtkomlig för behöriga Org‑admins (och eventuella särskilt utsedda systemnära administratörer) inom den aktuella organisationen. Syftet är att säkerställa spårbarhet (vem gjorde vad, när och på vilket konto) samtidigt som mängden lagrade personuppgifter minimeras.

Vad som loggas

Följande händelser kopplade till radering av användarkonton ska alltid generera en loggpost:

• Markering för radering
  När ett konto läggs in i karensflödet (”Markerad för radering”).

• Ångrad planerad radering
  När ett konto tas bort ur karenslistan genom åtgärden Ångra radering.

• Genomförd radering efter karens
  När ett konto raderas permanent efter att villkoren för karenstid och kontroll mot synkroniseringsunderlaget har uppfyllts.

• Genomförd direkt radering
  När ett konto raderas omedelbart utan karens, efter godkänd kontroll av att personen inte längre förekommer i något verksamhetssystem.

• Misslyckade eller avbrutna raderingsförsök
  När ett raderingsförsök stoppas, t.ex. därför att:

  • användaren fortfarande förekommer i synkroniseringsunderlaget, eller
  • teknisk kontroll mot verksamhetssystemen inte kan genomföras (t.ex. på grund av integrationsfel eller utebliven synkronisering).

Exempel:
Om en Org‑admin försöker direkt radera ett konto som fortfarande finns i elevregistret kommer åtgärden att avbrytas. Detta registreras som en logghändelse av typen ”Radering avbruten – användare finns kvar i synkronisering” med tidpunkt och ansvarig administratör.

Innehåll i loggposter

För varje loggad händelse kopplad till kontoradering lagras minst följande uppgifter:

• Tidpunkt för åtgärden
  Datum och klockslag då åtgärden initierades eller slutfördes.

• Typ av åtgärd
  En standardiserad åtgärdstyp, t.ex.:

  • ”Markerad för radering (start av karens)”
  • ”Radering ångrad”
  • ”Raderad efter karens”
  • ”Direkt radering genomförd”
  • ”Radering avbruten – användare finns kvar i synkronisering”
  • ”Radering avbruten – teknisk kontroll mot verksamhetssystem misslyckades”

• Ansvarig administratör
  Referens till det administratörskonto (Org‑admin/systemnära administratör) som utförde åtgärden, t.ex. internt användar‑ID och visningsnamn.

• Identifiering av berört konto enligt dataminimeringsprincipen
  Identifieringen anpassas efter om kontot fortfarande finns kvar eller om det redan har raderats:

  • Så länge kontot finns kvar i Vklass (innan slutlig radering):

    • Loggposten kan tekniskt knytas till kontots fullständiga interna identitet (t.ex. fullständigt personnummer/ID och internt kontonyckel‑ID) för att säkerställa korrekt koppling mellan åtgärd och konto.
    • I användargränssnittet för åtgärdsloggen visas dock endast de uppgifter som Org‑admin redan har behörighet att se i övriga administrationsvyer.

  • Efter att kontot har raderats permanent:

    • Loggposten ska endast innehålla pseudonymiserad identifiering i gränssnittet, t.ex.:
      • högst de sex första siffrorna i personnumret/ID:t (ååmmdd), eller motsvarande trunkerad identitet vid andra ID‑format,
      • förnamn,
      • tidigare skola/enhet vid tidpunkten för radering.
    • De fyra sista siffrorna i personnummer eller andra onödigt precisa identitetsattribut får inte lagras i läsbar form i åtgärdsloggen efter radering.
    • Det ska inte vara möjligt för en Org‑admin att via åtgärdsloggen återställa ett komplett personnummer eller återskapa en fullständig personprofil för ett konto som har raderats.

• Teknisk referens till kontot i Vklass
  Ett internt tekniskt ID (t.ex. GUID eller intern kontonyckel) kan lagras i loggposten i syfte att:

  • möjliggöra teknisk felsökning, och
  • säkerställa att rätt åtgärd kan spåras i interna systemloggar.

  Detta tekniska ID är inte avsett att exponeras i klartext för Org‑admin, utan används huvudsakligen av Vklass tekniska drift och support under personuppgiftsbiträdesansvaret. Kopplingen mellan tekniskt ID och fullständig persondata omfattas av separata åtkomstkontroller i Vklass driftmiljö.

Exempel:
En loggrad efter genomförd radering kan i gränssnittet för Org‑admin presenteras i stil med:

2025‑03‑12 14:23 – Raderad efter karens – Elev – 120813‑****** Anna, Gymnasieskola A – Utförd av: Orgadmin Kommun X

Här framgår tidpunkt, åtgärdstyp, roll, pseudonymiserad identitet (sex första siffror + förnamn) och enhet, men inte fullständigt personnummer.

Åtkomst, visning och export

Åtgärdsloggen för kontoradering omfattas av samma organisatoriska avgränsningar som övrig data i Vklass:

• Endast Org‑admins (och ev. särskilt utsedda systemnära administratörer) inom den egna organisationen kan:

  • se loggposter kopplade till organisationens konton,
  • söka och filtrera i loggen (t.ex. på åtgärdstyp, tidspann eller ansvarig administratör).

• Andra roller (t.ex. SchoolAdmin, Principal, lärare, elevhälsopersonal, skolledare utan Org‑admin‑behörighet) har ingen åtkomst till denna loggvy.

• Loggen får inte exponeras eller exporteras på ett sätt som ökar mängden personuppgifter jämfört med vad som visas i Vklass administrationsgränssnitt:

  • eventuella exportfunktioner (t.ex. CSV/PDF) måste använda samma pseudonymiserade visning som i gränssnittet,
  • det är inte tillåtet att via export ta del av fullständiga personnummer eller annan mer detaljerad identitetsinformation än den som presenteras på skärmen.

• Loggdata är strikt organisationstillhörig:

  • en Org‑admin i Kommun A kan aldrig se loggar som avser konton i Kommun B,
  • detta gäller även om samma fysiska person historiskt haft kopplingar till flera organisationer.

Lagringstid och gallring av loggposter

Loggar som rör radering av användarkonton är i sig personuppgiftsbehandling och omfattas därför av tydliga, tidsbegränsade gallringsregler:

• Varje loggpost kopplad till kontoradering får lagras under högst 30 dagar från åtgärdstidpunkten.
• Efter 30 dagar ska loggposten automatiskt gallras (raderas) utan manuell handpåläggning. Detta gäller:
  • både för händelser där radering faktiskt genomförts (efter karens eller direkt), och
  • för händelser där radering ångrats eller avbrutits.

Efter att gallringen har genomförts ska:

• varken detaljerad information om åtgärden,
• eller pseudonymiserade identifierare (t.ex. sex första siffror i personnummer/ID, förnamn, skola/enhet),

längre finnas kvar i åtgärdsloggen för kontoradering.

På så sätt uppfyller funktionen:

• kraven på spårbarhet och revision under en begränsad period (t.ex. vid intern kontroll av vem som beslutat om radering av ett visst konto), samtidigt som
• principen om dataminimering och tidsbegränsad lagring tillämpas konsekvent även på loggarna, i linje med GDPR och organisationens gallringsregler.

Gallring av raderingsloggar

Raderingsloggar utgör en avgränsad delmängd av Vklass åtgärdslogg och omfattar samtliga loggposter som skapas i samband med hantering av radering av användarkonton, inklusive men inte begränsat till:

• markering av konto för radering (start av karens),
• åtgärden Ångra radering (avbruten karens),
• genomförd radering efter avslutad karens,
• genomförd direkt radering (utan karens),
• avbrutna raderingsförsök (t.ex. på grund av fortsatt förekomst i synkroniseringsunderlaget eller tekniskt fel i kontrollen mot verksamhetssystem).

Loggarna används för spårbarhet, intern uppföljning och teknisk felsökning under en begränsad tidsperiod. De är inte avsedda att utgöra ett långsiktigt personregister och omfattas därför av en specifik gallringsprocess med kort lagringstid.

Varje raderingsloggpost får lagras i högst 30 dagar räknat från den tidpunkt då den aktuella åtgärden genomfördes. Detta gäller oavsett åtgärdstyp; loggposter för ”Markerad för radering”, ”Radering ångrad”, ”Raderad efter karens”, ”Direkt radering genomförd” och ”Radering avbruten – användare finns kvar i synkronisering” behandlas likvärdigt.

• Exempel: En direkt radering genomförs den 1 mars kl. 10:00. Den motsvarande loggposten får då finnas kvar som mest till den 31 mars kl. 10:00. Efter den tidpunkten ska loggposten inte längre vara åtkomlig för någon användare och inte heller finnas kvar i databasen i identifierbar form.

När 30‑dagarsgränsen har passerats ska loggposten:

• inte vara åtkomlig i något användargränssnitt (inklusive särskilda administrations‑ och rapportvyer),
• inte kunna hämtas via några externa eller interna API:er,
• inte finnas kvar i den primära databasen i en form där enskilda personer kan identifieras, vare sig direkt eller indirekt.

Gallringen av raderingsloggar utförs av en schemalagd, automatisk process i Vklass och kräver ingen manuell hantering från organisationens sida eller från Vklass support. Denna process ska:

• minst med daglig frekvens identifiera alla loggposter vars åtgärdstidpunkt är äldre än 30 dagar,
• radera dessa poster permanent från den primära logglagringen (inklusive index och eventuella cache‑strukturer),
• säkerställa att raderade loggar inte kan återskapas genom ordinarie drift‑ eller administrationsfunktioner.

Om Vklass använder databassäkerhetskopior (backup) ska dessa hanteras enligt Vklass generella backup‑ och återläsningsrutiner. Säkerhetskopior får:

• endast användas för att återställa systemet vid driftstörningar, fel eller katastrofsituationer,
• inte användas som ett parallellt långtidsarkiv för raderingsloggar eller annan persondata.

Vid återställning från backup gäller följande principer:

• Efter återläsning ska samma schemalagda gallringsprocess för raderingsloggar köras som en del av den ordinarie driften.
• Loggposter som vid återställningstillfället är äldre än 30 dagar (baserat på åtgärdstidpunkt), ska gallras bort på nytt vid första lyckade gallringskörning efter återställningen.
• Därmed säkerställs att en temporär återläsning från backup inte leder till att raderingsloggar i praktiken lagras längre än den fastställda maximala lagringstiden.

Raderingsloggar får inte:

• arkiveras till separata system eller filer på ett sätt som förlänger den faktiska lagringstiden av personuppgifter utöver 30 dagar,
• exporteras, speglas eller kopieras till externa rapport‑ eller BI‑lösningar i identifierbar form, om detta innebär att samma personuppgifter lagras längre tid än vad som gäller i den primära logglagringen.

Organisationsnivå statistik och uppföljning får tas fram, men endast i former där enskilda personer inte kan identifieras, vare sig direkt eller indirekt. Exempel på tillåten aggregerad statistik är:

• ”Antal kontoraderingar per månad och skolform i kommunen”,
• ”Antal direkt raderade konton under ett kvartal”.

Sådan statistik ska tas fram antingen:

• genom aggregering av loggposter innan 30‑dagarsgränsen passeras, eller
• genom separata räknare/metadataposter som inte innehåller personuppgifter (t.ex. enbart antal och typ av åtgärd per organisation och tidsperiod).

Gallringsprocessen ska vara robust och självläkande vid tekniska fel. Om en schemalagd gallringskörning misslyckas (t.ex. på grund av databastillgänglighet eller annan driftsstörning) gäller:

• inga loggposter ska ”fastna” permanent enbart på grund av ett tillfälligt fel,
• nästa lyckade gallringskörning ska omfatta samtliga raderingsloggar som vid det laget är äldre än 30 dagar, oavsett när den föregående körningen genomfördes.

Vklass ska internt kunna visa att gallring av raderingsloggar sker i enlighet med dessa principer, t.ex. genom:

• teknisk dokumentation av gallringsjobbet (körschema, logik för urval och radering),
• övervaknings‑ eller systemloggar som visar att gallringskörningarna genomförts, hur många loggposter som raderats per körning och eventuella fel.

Dessa interna underlag får dock inte exponera ytterligare personuppgifter för organisationens användare jämfört med vad som framgår av den ordinarie åtgärdsloggen under den tillåtna lagringsperioden.

Begränsning av personuppgifter i loggar

Personuppgifter som lagras och exponeras i åtgärdsloggarna ska begränsas strikt till det som är absolut nödvändigt för spårbarhet och revision. Loggarna får aldrig användas som ett parallellt personregister eller som en alternativ informationskälla om enskilda användare, utan har enbart till syfte att visa:

• vilken typ av åtgärd som har genomförts (t.ex. radering, sammanslagning, spärrning),
• när åtgärden genomfördes,
• vilken org‑admin (eller motsvarande behörig administratör) som utförde åtgärden,
• vilken person eller relation åtgärden avsåg – identifierad på en dataminimerad nivå.

Begränsning av personuppgifter efter radering

När ett användarkonto väl har raderats permanent får åtgärdsloggar som avser radering, sammanslagning eller spärrning av kontot aldrig innehålla:

• fullständigt personnummer eller fullständigt TF‑nummer,
• kompletta alternativa identiteter (t.ex. hela fiktiva personnummer eller andra fullständiga ID‑värden),
• kontaktuppgifter (e‑post, telefonnummer),
• adressuppgifter,
• klass‑, grupp‑, avdelnings‑ eller kursinformation,
• vårdnadshavare, barn, anhöriga eller andra relationsuppgifter som kan förstärka möjligheten att identifiera individen,
• annan känslig eller onödigt detaljerad information (t.ex. elevhälsorelaterade anteckningar, särskilda stödformer, skyddad identitet).

Efter radering får loggposten som mest innehålla följande personuppgifter för att identifiera vilken individ åtgärden avsåg:

• de sex första siffrorna i personnumret (ååmmdd) eller motsvarande trunkerad identitet vid andra ID‑format,
• förnamn,
• skola/enhet där användaren senast var kopplad.

De fyra sista siffrorna i personnumret (eller motsvarande del av annat ID) får inte lagras i läsbar form i åtgärdsloggarna efter genomförd radering. Det ska inte heller finnas någon annan kombination av uppgifter i loggen som gör det möjligt att rekonstruera ett komplett personnummer eller skapa en fullständig personprofil.

Exempel (visning i logggränssnitt efter radering):
2025‑03‑12 14:23 – Raderad efter karens – Elev – 120813‑****** Anna, Gymnasieskola A – Utförd av: Orgadmin Kommun X

Här framgår endast datumdelen av personnumret, förnamn och enhet, tillsammans med åtgärdstyp och ansvarig administratör.

Begränsning av personuppgifter vid sammanslagning och spärrning

Samma principer för dataminimering gäller för loggning av:

• sammanslagning av konton (t.ex. TF‑konto → konto med korrekt personnummer),
• spärr av hela konton (personbaserad spärr),
• spärr av specifika relationer (t.ex. vårdnadshavare–barn),
• tillfällig avstängning eller återaktivering där sådana åtgärder stödjs.

För dessa åtgärder gäller:

• Så länge de berörda kontona fortfarande finns kvar i Vklass kan loggposten tekniskt knytas till respektive konto via interna nycklar. I användargränssnittet ska dock endast den information visas som org‑admin redan har behörighet att se i övriga administrationsvyer.
• När ett konto därefter raderas (t.ex. efter avslutad karens eller genom direkt radering) ska samma begränsning gälla som ovan: endast sex första siffror av personnummer/ID, förnamn och skola/enhet får exponeras i åtgärdsloggarna, oavsett om loggposten ursprungligen avsåg radering, sammanslagning eller spärr.

Exempel (sammanslagning, efter att det ena kontot raderats):
2025‑04‑05 09:11 – Sammanslagning av konton – TF‑konto sammanslaget in i huvudkonto – Elev – 120813‑****** Anna, Gymnasieskola A – Utförd av: Orgadmin Kommun X

Tekniska nycklar och interna identifierare

Interna tekniska nycklar som används av systemet, t.ex.:

• interna användar‑ID:n,
• interna GUID/nycklar för karensposter eller spärrposter,

får användas i den underliggande datamodellen och i interna systemloggar för att:

• säkerställa korrekt koppling mellan åtgärd och berörd entitet,
• möjliggöra teknisk felsökning och revision inom ramen för Vklass personuppgiftsbiträdesansvar.

Dessa tekniska nycklar:

• får inte presenteras som personuppgifter i användargränssnittet eller i externa API:er,
• får inte kombineras med ytterligare information i loggvyer eller exporter på ett sätt som i praktiken gör det möjligt för org‑admin att återskapa en fullständig personprofil för ett raderat konto.

Tillämpning i gränssnitt, export och API:er

Begränsningen av personuppgifter i loggar gäller konsekvent i alla kanaler där åtgärdsloggar kan nås:

• administrationsgränssnitt i Vklass,
• eventuella exportfunktioner (t.ex. CSV, Excel, PDF),
• eventuella API:er eller integrationsendpoints som tillhandahåller loggdata.

Det ska inte finnas något tekniskt sätt för en org‑admin eller annan användare att:

• återskapa ett fullständigt personnummer från loggdata,
• kombinera loggdata med annan lättillgänglig information i Vklass för att bygga upp en mer detaljerad personprofil än vad som är nödvändigt för spårbarhet av åtgärden.

Om loggdata görs tillgänglig för export eller för teknisk vidarebearbetning (t.ex. felsökning, intern revision) ska samma begränsningar gälla som i användargränssnittet; export får inte innehålla mer persondata än vad som visas på skärmen.

Ändamålsbegränsning

Åtgärdsloggarna får endast användas för:

• att verifiera att en viss administrativ åtgärd (radering, sammanslagning, spärrning m.m.) har genomförts,
• att se när åtgärden genomfördes och av vilken behörig administratör,
• att i efterhand kunna bedöma vilken individ eller relation åtgärden avsåg – på en pseudonymiserad nivå, när kontot väl är raderat.

Loggarna får inte användas för:

• löpande uppföljning eller kartläggning av enskilda elevers, vårdnadshavares eller personals historik i Vklass,
• att återidentifiera raderade personer genom hopkoppling med andra källor,
• andra syften än spårbarhet, felsökning och revision av de specifika administrativa åtgärderna.

Utöver dessa begränsningar omfattas åtgärdsloggarna av den tidsbegränsade lagring och automatiska gallring som beskrivs i avsnittet om gallring av raderingsloggar. Detta säkerställer att personuppgifter i loggarna inte lagras längre än vad som är nödvändigt för ovanstående ändamål.

Sammanslagning av användarkonton

Sammanslagning av användarkonton gör det möjligt för behörig Org‑admin att konsolidera två separata konton som avser samma fysiska person till ett gemensamt, kvarvarande konto. Funktionen är roll‑ och kontotypoberoende och kan användas för:

• elever/barn,
• personal,
• vårdnadshavare,

oavsett om kontona är synkroniserade från verksamhetssystem eller skapade manuellt i Vklass (t.ex. TF‑konton, tillfälliga konton, alias).

Utgångspunkten är principen ”en fysisk person – ett aktivt användarkonto per organisation”. Sammanslagning används när denna princip har brutits, t.ex. genom:

• ändrat personnummer eller byte från TF‑nummer till svenskt personnummer,
• ändrad identitet eller nytt ID i källsystemet,
• övergång från manuellt konto till synkroniserat konto,
• dubbletter som uppstått vid felregistrering eller felaktig hantering av manuella konton.

Syftet är att samla roller, kopplingar och relevant historik på ett tydligt målkonto (huvudkonto framåt) och avsluta det andra kontot (källkontot) som separat identitet, utan att förlora data i onödan och utan att störa kopplingen till verksamhetssystemen.

Förutsättningar och ansvar

Sammanslagning får endast genomföras av behörig Org‑admin (eller särskilt utsedd systemnära administratör) och endast för konton som:

• tillhör samma Vklass‑organisation (huvudman/kommun), och
• med hög grad av säkerhet bedöms avse samma fysiska person.

Systemet ger stöd för att jämföra konton, men tar inte själv ställning till om de representerar samma individ eller t.ex. skyddad identitet. Bedömningen och ansvaret ligger alltid på Org‑admin.

Funktionen ändrar aldrig data i bakomliggande verksamhetssystem. Efter sammanslagning ligger ansvaret kvar på källsystemen att:

• tilldela korrekt identitet, och
• inte fortsätta producera dubbletter eller motstridiga identiteter i synkroniseringsunderlaget.

Val av konton och jämförelsevy

Processen inleds med att Org‑admin söker fram de berörda kontona i den utökade användarhanteringen. Sökning kan göras med samma sökbegrepp som i övriga delar av funktionen, t.ex.:

• personnummer eller TF‑nummer (inkl. format som 120813‑TF21),
• annat unikt ID,
• namn,
• skola/enhet, klass/grupp/avdelning,
• för vårdnadshavare: via koppling till ett specifikt barn.

När två konton har identifierats som kandidater för sammanslagning öppnas en jämförelsevy där centrala attribut visas sida vid sida, t.ex.:

• namn och identitetsuppgifter (personnummer/ID),
• roller (elev/barn, personal, vårdnadshavare – inklusive kombinationer),
• skol‑ och enhetskopplingar,
• klass‑, grupp‑ och undervisningskopplingar,
• vårdnadshavare–barn‑relationer (för vårdnadshavare),
• kontots ursprung (t.ex. ”synkroniserat från elevregister X” respektive ”manuellt skapat i Vklass”),
• huvudsakliga inloggningssätt (Vklass‑inloggning, SSO, BankID m.m.).

Systemet kan markera uppenbara skillnader (t.ex. olika personnummer, olika e‑postadresser), men fattar inget eget beslut om kontona ska slås ihop eller inte.

Val av målkonto och källkonto

Org‑admin måste alltid uttryckligen välja:

• vilket konto som ska vara målkonto (huvudkonto framåt), och
• vilket som ska vara källkonto (det konto vars data och kopplingar förs över och som därefter upphör som separat konto).

Valet av målkonto ska i normalfallet följa dessa principer:

• Om ett av kontona är synkroniserat från verksamhetssystem och det andra är manuellt skapat bör det synkroniserade kontot väljas som målkonto.
• Om en person har gått från TF‑nummer till korrekt svenskt personnummer bör kontot med det korrekta personnumret vara målkonto.
• Om källsystemen har infört ett nytt ID och markerat det gamla som inaktuellt bör kontot med gällande ID i källsystemet vara målkonto.

I gränssnittet ska det tydligt framgå vilket konto som är valt som målkonto (t.ex. genom markerad rubrik, position överst i jämförelsevyn eller särskild ikon) och vilket som är källkonto.

Innan sammanslagningen kan genomföras ska Org‑admin:

• få en sammanfattande beskrivning av konsekvenserna (att källkontot upphör som separat konto, att dess kopplingar och historik – i den mån det är tekniskt och juridiskt möjligt – förs över till målkontot),
• aktivt bekräfta att:
  • kontona avser samma fysiska person, och
  • valet av målkonto är korrekt.

Sammanslagning är en irreversibel åtgärd; systemet erbjuder ingen ”ångra”‑funktion när sammanslagningen väl har genomförts.

Genomförande – överföring av kopplingar och historik

När sammanslagningen bekräftats genomför Vklass en kontrollerad konsolidering där systemet, så långt det är tekniskt och juridiskt möjligt, ska:

• Samla roller på målkontot

  • Alla roller (elev/barn, personal, vårdnadshavare) från källkontot läggs till på målkontot om de inte redan finns.
  • Dubblerade roller för samma skola/enhet hanteras enligt reglerna för konflikthantering (se separat avsnitt), vanligtvis genom att behålla en roll per skola/enhet.

• Föra över skol‑, klass‑ och gruppkopplingar

  • Skolor/enheter, klasser, undervisningsgrupper och andra gruppkopplingar från källkontot kopplas om till målkontot, i den mån detta är tekniskt möjligt.
  • Vid överlapp (t.ex. båda kontona är kopplade till samma klass) ska dubbletter inte skapa problem i användargränssnittet, utan hanteras enligt definierade regler.

• Föra över relationer

  • För vårdnadshavare: vårdnadshavare–barn‑relationer från källkontot kopplas om till målkontot, så att vårdnadshavaren fortsatt ser rätt barn via målkontot.
  • För barn/elevkonton: relationer till vårdnadshavare och andra relevanta relationer överförs på motsvarande sätt.

• Föra över historik

  • Så långt som tekniskt och juridiskt möjligt kopplas historik från källkontot om till målkontot, t.ex.:
    • resultat och bedömningar,
    • närvaro‑ och frånvaroregistreringar,
    • inlämningar och uppgifter,
    • inlägg, kommentarer och meddelanden,
    • uppladdade filer och annan elev-/personrelaterad dokumentation,
    • andra logiska datapunkter som är knutna till användarkontot.
  • Där det krävs för att uppfylla arkiv‑ eller gallringsregler kan viss data i stället kvarstå som anonymiserad/postrelaterad information utan direkt koppling till personkontot (hanteras vidare i avsnittet Hantering av data vid sammanslagning).

• Säkerställa fortsatt funktionalitet

  • Pågående uppgifter, grupper, undervisningsrelationer och andra aktiva funktioner ska vara tillgängliga via målkontot efter sammanslagningen.
  • En lärare som haft uppgifter och bedömningar kopplade till ett manuellt konto ska t.ex. efter sammanslagning kunna hantera dessa via sitt synkroniserade målkonto utan avbrott.

Efter sammanslagning:

• upphör källkontot att existera som separat, inloggningsbar identitet,
• kan källkontot inte längre sökas fram eller tilldelas nya roller,
• sker all vidare hantering (radering, spärrning, ytterligare sammanslagning) via det kvarvarande målkontot.

Konflikter och begränsningar

Vid sammanslagning kan det uppstå konflikter eller specialfall, t.ex.:

• motstridiga grundidentiteter (olika personnummer/ID där båda förekommer i källsystemen),
• överlappande eller oförenliga skol‑ och klasskopplingar för samma tidsperiod,
• dubbla roller med olika behörighetsnivåer på samma enhet,
• vårdnadshavare som har olika uppsättningar barn kopplade till respektive konto.

Systemet ska ha definierade regler för hur sådana konflikter hanteras (se vidare i avsnittet Konflikthantering vid sammanslagning). Övergripande gäller:

• Om det är möjligt att behålla båda uppsättningarna kopplingar utan att skapa tekniskt felaktiga eller otillåtna tillstånd, ska dessa läggas på målkontot (dvs. hellre bevara än förlora information).
• Om vissa konflikter inte kan lösas automatiskt (t.ex. två helt olika personnummer som båda fortfarande används i synkroniseringen) ska systemet:
  • tydligt varna Org‑admin innan sammanslagning bekräftas,
  • där det är lämpligt kräva att Org‑admin först åtgärdar underliggande problem i verksamhetssystemen eller genom spärr

Hantering av data vid sammanslagning

Vid sammanslagning av två användarkonton (källkonto → målkonto) ska all hantering av data utgå från följande grundprinciper:

• den fysiska personen ska efter sammanslagning endast ha ett (1) aktivt, konsoliderat konto i Vklass inom organisationen,
• relevant historik och kopplingar ska i största möjliga utsträckning bevaras,
• onödiga dubbletter och motsägelsefulla kopplingar ska undvikas,
• kopplingen mot verksamhetssystem och synkronisering ska efter åtgärden vara entydigt knuten till målkontot.

Sammanslagningen är en teknisk konsolideringsåtgärd i Vklass och påverkar aldrig data i bakomliggande verksamhetssystem.

Grundprinciper för dataövertag

• Målkonto

  • behåller sina befintliga grunduppgifter (identitet/ID, personnummer/TF‑nummer, inloggningskonfiguration, primära roller och behörigheter),
  • blir den enda aktiva identiteten för personen efter genomförd sammanslagning,
  • används fortsatt vid all synkronisering och autentisering.

• Källkonto

  • upphör som aktivt användarkonto efter lyckad sammanslagning,
  • kan inte längre användas för inloggning eller administrativ hantering,
  • kan i vissa fall finnas kvar enbart som intern teknisk referens för data som inte kan ommappas, tills ordinarie gallringsregler tar bort dessa rester.

• Dataövertag

  • all data som tekniskt kan kopplas om från källkonto till målkonto, och som inte bryter mot juridiska eller arkivmässiga krav, ska försöka övertas till målkontot,
  • om tekniska eller juridiska begränsningar gör att vissa dataposter inte kan flyttas, ska de i första hand lämnas orörda (kopplade till källkontots interna ID) tills de gallras enligt ordinarie regler – funktionen ska inte radera sådan data utan uttryckligt beslut.

Exempel:
En elev har först ett manuellt TF‑konto (120813‑TF21) och får senare ett synkroniserat konto med korrekt personnummer. Det synkroniserade kontot väljs som målkonto. Klassen, grupperna, vårdnadshavare‑relationerna och elevens inlämningar från TF‑kontot förs över till målkontot. TF‑kontot upphör som aktivt konto.

Kopplingar och relationer

Vid sammanslagning ska alla relevanta kopplingar konsolideras till målkontot, med strikt deduplicering där det är möjligt.

Skolor/enheter

• Samtliga skol‑ och enhetskopplingar från källkontot läggs till på målkontot om de saknas där.
• Om samma skola/enhet finns på båda kontona behålls endast en koppling till enheten på målkontot.
• Historiska kopplingar (t.ex. tidigare skolor) bevaras i den mån de redan finns i Vklass datamodell.

Klasser, grupper och undervisningsenheter

• Medlemskap i klasser, undervisningsgrupper, arbetslag, ämnesgrupper m.m. flyttas från källkonto till målkonto.
• Om målkontot redan är medlem i samma grupp skapas ingen ny medlemskapsrad; systemet säkerställer att målkontot endast förekommer en gång per grupp.
• Tidssatta kopplingar (t.ex. historiska gruppmedlemskap) behålls med oförändrad tidslogik.

Roller och rättigheter

• Roller (elev/barn, personal, vårdnadshavare) som endast finns på källkontot läggs till på målkontot.
• Enskilda rättigheter/behörigheter (t.ex. SchoolStudentAdvisor, SchoolPrincipal, lokala adminroller) som endast finns på källkontot förs över till målkontot förutsatt att:
  • de är giltiga inom samma organisation, och
  • de inte står i strid med befintliga säkerhetsregler (t.ex. begränsande roller som ”Kan ej logga in som annan användare”).
• Om samma rättighet redan finns på målkontot uppstår ingen dubblett; behörigheten finns kvar en (1) gång.

Relationer vårdnadshavare–barn

• Alla relationer mellan källkontot (som vårdnadshavare) och barn förs över till målkontot.
• Om målkontot redan har relation till samma barn behålls en konsoliderad relation vårdnadshavare–barn.
• Eventuella spärrar eller särskilda inställningar kopplade till relationen hanteras enligt följande:
  • spärrar som uttryckligen avser relationen (t.ex. spärrad vårdnadshavare–barn‑koppling) ska överföras eller återskapas för motsvarande relation på målkontot,
  • spärrar som är knutna till hela källkontot (personbaserad spärr) utvärderas i samband med sammanslagningen och hanteras via spärrfunktionen (t.ex. flyttas, avslutas eller kvarstår beroende på verksamhetens beslut).

Övriga relationer

• Andra relationstyper – t.ex. mentorskap, elevhälsokopplingar, funktioner i arbetslag, handledaruppdrag – förs över till målkontot om de tekniskt hanteras som kopplingar till användaren.
• Om samma uppdrag finns på båda kontona för samma period ska systemet eftersträva en sammanhållen historik med en unik relation per uppdrag, utan att ta bort korrekta historiska poster.

Exempel:
En lärare har ett äldre manuellt konto där hen är mentor för klass 9A, och ett nytt synkroniserat konto där samma mentorskap också finns. Efter sammanslagning ska målkontot tydligt vara mentor för 9A (utan dubbletter), och historiken kring mentorskapet ska vara intakt.

Historik och innehåll

Historik och innehåll som är knutet till källkontot ska, där det är tekniskt och juridiskt möjligt, omkopplas till målkontot för att ge en sammanhållen bild av personens användning över tid.

Närvaro och frånvaro

• Registrerade närvaroposter och frånvaromarkeringar (lektion, dag, period) som är kopplade till källkontot kopplas om till målkontot.
• Närvarorapporter, frånvarostatistik och uppföljningsbilder ska efter sammanslagningen visa en sammanhängande historik på målkontot.

Resultat, bedömningar och omdömen

• Resultat, betyg, omdömen, bedömningsmatriser, kunskapsområde‑bedömningar och liknande data som är knuten till källkontot flyttas till målkontot så långt datamodellen medger.
• Om samma kurs/ämne och samma bedömningstillfälle finns på båda kontona kan följande uppstå:
  • två separata bedömningar/betyg för samma kurs och tidpunkt, eller
  • olika resultat för identiska betygstillfällen.
• Systemet ska tillämpa definierade prioriteringsregler, t.ex.:
  • behålla båda posterna om modellen stöder flera bedömningar (markerade som separata händelser), eller
  • markera en post som ersatt/överlagrad enligt fördefinierad logik (t.ex. senaste bedömning vinner), utan att dölja eller radera data utan spårbarhet.
• Org‑admin ska inför bekräftelse få information om att sådana konflikter kan förekomma och att resultatbilden efter sammanslagning kan innehålla parallella poster.

Uppgifter, inlämningar och feedback

• Uppgifter, inlämningsuppgifter, inlämnade filer, lärkommentarer och annan feedback som är kopplad till källkontot kopplas om till målkontot.
• Länkar mellan uppgifter, inlämningar och användare ska fungera oförändrat efter sammanslagningen, men med målkontot som referens.
• Läraren ser därmed fortsatt alla elevens inlämningar, oavsett om de ursprungligen gjorts från TF‑konto eller synkroniserat konto.

Meddelanden, konversationer och inlägg

• Meddelanden, konversationer, chattar, forum‑inlägg och anslag där källkontot varit avsändare eller mottagare ska, så långt tekniken medger, ommappas till målkontot.
• I de vyer där avsändare/mottagare listas ska målkontot därefter visas som deltagare.
• Om vissa äldre meddelanden eller inlägg av tekniska skäl inte kan ommappas:
  • ska innehållet fortfarande vara läsbart för mottagare/deltagare,
  • kopplingen kan ligga kvar mot källkontots interna ID, som då endast fungerar som en icke‑inloggningsbar teknisk referens,
  • detta får inte påverka åtkomst eller historik för andra användare negativt.

Filer och dokument

• Filer och dokument där källkontot står som ägare (t.ex. uppladdade undervisningsresurser, inlämningsfiler) ska, där det är möjligt, få målkontot som ny ägare.
• Behörigheter och delningar som är knutna till dessa filer ska bevaras, så att berörda användare har samma åtkomst efter sammanslagningen.
• Om filer är lagrade i externa system (t.ex. Google Workspace/365‑integration) styrs ägarbyte i första hand av respektive integration; Vklass ska i dessa fall inte bryta länkar eller åtkomster.

Aktivitetsloggar och intern historik

• Systeminterna aktivitetsloggar (t.ex. ”användaren öppnade uppgift X”) kan i den mån det är tekniskt möjligt kopplas om till målkontot utan att bryta revisionsspår.
• Där en exakt ommappning inte är möjlig eller lämplig (t.ex. äldre tekniska loggar) kan poster ligga kvar med anknytning till källkontots interna ID tills de gallras enligt ordinarie logg- och gallringsregler.
• Själva sammanslagningsåtgärden loggas alltid separat i åtgärdsloggen enligt reglerna om dataminimering.

Hantering av identitetsuppgifter och inloggning

Identitet / personnummer / ID

• Målkontots identitetsuppgifter (t.ex. svenskt personnummer) är styrande efter sammanslagningen och används som enda identitetsnyckel mot synkroniseringsunderlaget.
• Identiteter som endast funnits på källkontot (t.ex. tidigare TF‑nummer eller gammalt personnummer) ska inte längre användas för ny‑ eller återaktivering av konton i Vklass.
• Om det finns behov att förhindra att en gammal identitet återskapar ett nytt konto via synkronisering ska detta hanteras via:
  • uppdatering i källsystemet, och/eller
  • spärrfunktionen (spärrlista) i Vklass, inte genom kvarhållande av ett parallellt konto.

Inloggningsuppgifter och autentisering

• Konfigurationer för inloggning som hör till målkontot (t.ex. kopplingar till SSO, BankID, Freja eID, Vklass‑användarnamn) kvarstår och är de som ska användas efter sammanslagningen.
• Inloggningsuppgifter som enbart är kopplade till källkontot:
  • avaktiveras eller tas bort,
  • ska inte längre kunna användas för inloggning efter genomförd sammanslagning.
• Om källkontot är det konto personen normalt använder (t.ex. ett äldre manuellt alias) bör Org‑admin, inom ramen för lokala rutiner utanför denna funktion, säkerställa:
  • att personen informeras om vilket konto/inloggningssätt som ska användas framåt,
  • att eventuella manuella utdelade uppgifter (användarnamn/lösenord) uppdateras vid behov.

Exempel:
En lärare har tidigare loggat in med ett manuellt Vklass‑konto och får senare en SSO‑kopplad identitet från personalregistret. Det SSO‑kopplade kontot väljs som målkonto. Efter sammanslagning används endast SSO‑inloggningen; det manuella användarnamnet och lösenordet kopplade till källkontot slutar fungera.

Hantering av konflikter och dubbletter

Vid sammanslagning kan datakonflikter och dubbletter uppstå. Systemet ska då tillämpa tydliga och förutsägbara regler, med utgångspunkt i att:

• inte förstöra data i onödan,
• inte skapa felaktiga eller missvisande sammanställningar.

Övergripande regler:

• Dubbla kopplingar (t.ex. samma klass, samma barnrelation, samma arbetslag) dedupliceras så att målkontot får en (1) konsoliderad koppling per entitet.
• Parallella, men historiskt korrekta uppgifter (t.ex. två olika skolkopplingar vid olika tidpunkter) bevaras som separata poster med sin respektive tid och sammanhang.
• Oförenliga dataposter (t.ex. två betyg på exakt samma betygstillfälle där modellen inte tillåter dubblett) ska:
  • inte tas bort tyst,
  • hanteras enligt fördefinierade, dokumenterade prioriteringsregler (t.ex. senaste uppdatering vinner, manuell eftergranskning kan krävas),
  • aldrig raderas eller döljas utan att spårbarhet finns i åtgärdsloggen.

Innan Org‑admin bekräftar en sammanslagning ska systemet, i den mån det är tekniskt möjligt, visa en sammanfattande översikt över huvudsakliga effekter, t.ex.:

• antal skol-/enhetskopplingar som flyttas,
• antal klass-/gruppkopplingar som berörs,
• om det finns kända

Konflikthantering vid sammanslagning

Vid sammanslagning av två användarkonton kan olika typer av motstridiga uppgifter uppstå. Funktionen ska hantera dessa konflikter enligt fördefinierade principer som:

• i första hand bevarar korrekt och aktuell information,
• minimerar risken för felaktiga eller överdrivna behörigheter,
• inte gör ”tysta” ändringar som kan få säkerhets‑ eller åtkomstkonsekvenser.

Grundprinciperna är att:

• målkontot är normerande för grundidentitet och inloggning,
• data från källkontot kompletterar målkontot där det inte skapar konflikt,
• vid tveksamhet prioriteras säkerhet framför bekvämlighet (hellre behålla dubblerad eller ”för mycket” information än att tyst ta bort något som kan påverka åtkomst, spårbarhet eller historik).

Innan sammanslagningen genomförs ska systemet alltid visa en sammanfattande konfliktöversikt där centrala avvikelser (t.ex. olika namn, olika personnummer/ID, olika e‑postadresser, olika roller eller skolkopplingar) är tydligt markerade. Org‑admin ska utifrån denna bild kunna:

• verifiera att rätt två konton valts,
• vid behov byta vilket konto som ska vara målkonto, eller
• avbryta sammanslagningen och först rätta uppgifter i verksamhetssystemen.

---

Grundidentitet (namn, personnummer/ID, födelsedatum)

Om målkonto och källkonto har olika grundläggande identitetsuppgifter (t.ex. namn, personnummer/ID eller födelsedatum) gäller:

• Målkontots uppgifter ligger fast efter sammanslagningen; systemet skriver inte automatiskt över:
  • namn,
  • personnummer/TF‑nummer eller annat primärt ID,
  • födelsedatum eller motsvarande identitetsfält.
• Avvikelser visas tydligt i bekräftelsesteget, t.ex.:
  • ”Olika namn (Anna Andersson / Anna Karlsson)”,
  • ”Olika personnummer/ID”.
• Om källkontot i praktiken innehåller de korrekta uppgifterna framåt (t.ex. nytt personnummer eller rättat namn) är det Org‑admins ansvar att:
  • välja källkontot som målkonto, eller
  • först säkerställa att verksamhetssystemen uppdateras så att rätt konto blir normerande.
• Funktionen gör ingen egen tolkning av vilket konto som är ”rätt”; den följer enbart Org‑admins val av målkonto.

Exempel:
En elev har först ett TF‑konto 120813‑TF21 Anna Demo och får därefter ett synkroniserat konto med personnummer 20120813‑1234 Anna Andersson. Om det synkroniserade kontot väljs som målkonto ligger personnumret 20120813‑1234 och namnet Anna Andersson fast efter sammanslagningen; TF‑värdet används inte längre som primärt ID.

---

Kontaktuppgifter (e‑post, telefon)

När kontaktuppgifter skiljer sig åt mellan målkonto och källkonto gäller:

• Primära kontaktfält på målkontot (t.ex. ”E‑post”, ”Mobiltelefon”) behålls oförändrade om inget annat anges.
• Om båda kontona har värden i samma fält men med olika innehåll (t.ex. två olika e‑postadresser):
  • visas detta som en konflikt i sammanfattningen,
  • Org‑admin kan utifrån detta avgöra om kontovalet är korrekt.
• Om datamodellen stödjer flera kontaktuppgifter per person kan systemet:
  • behålla målkontots värde som primär adress, och
  • lägga till källkontots värde som alternativ adress/telefonnummer, där detta är lämpligt.
• Om endast en adress per fält tillåts:
  • behålls målkontots värde,
  • källkontots avvikande värde förs inte automatiskt över (men syns i konfliktöversikten innan sammanslagning).
• Funktionen gör ingen automatisk ändring i externa autentiseringslösningar (t.ex. AD, Skolfederation, IdP). Eventuell justering av kontaktuppgifter i dessa system hanteras av organisationen utanför Vklass.

Exempel:
En lärare har e‑post anna.larare@kommun.se på sitt synkroniserade konto och privat.anna@mail.com på ett äldre manuellt konto. Om det synkroniserade kontot är målkonto behålls anna.larare@kommun.se som primär adress. Om modellen stödjer alternativa adresser kan privat.anna@mail.com läggas till som sekundär adress; annars tas den inte över utan att Org‑admin aktivt ändrar detta efteråt.

---

Roller, behörigheter och begränsande roller

När konton har olika kombinationer av roller och behörigheter gäller:

• Roller (elev/barn, personal, vårdnadshavare) hanteras som union:
  • roller som bara finns på källkontot läggs till på målkontot,
  • roller som finns på båda kontona behålls utan dubbletter.
• Specifika rättigheter/behörigheter (t.ex. SchoolPrincipal, SchoolStudentAdvisor, supportroller, skol‑/org‑administratörsroller) slås också samman enligt unionsprincipen:
  • en behörighet som finns på minst ett av kontona ska normalt finnas kvar på målkontot,
  • funktionen tar inte bort behörigheter automatiskt för att ”städa” konflikter.
• Begränsande eller skyddande roller (t.ex. ”Kan ej logga in som annan användare”) får aldrig tas bort automatiskt:
  • om någon av kontona har en sådan roll ska denna också finnas kvar på målkontot,
  • en mer långtgående behörighet (t.ex. Principal) får inte användas för att automatiskt neutralisera en begränsande roll.
• I situationer där kombinationen av behörigheter kan uppfattas som oförenlig (t.ex. Org‑admin + flera specialroller) gäller:
  • systemet genomför sammanslagningen enligt ovanstående unionsprincip,
  • Org‑admin ansvarar för att efter sammanslagning granska och vid behov justera behörigheterna via ordinarie behörighetsgränssnitt.

Exempel:
Ett konto A är Principal och har den begränsande rollen ”Kan ej logga in som annan användare”. Konto B är ett äldre manuellt konto med Principal‑behörighet men utan den begränsande rollen. Om konto A väljs som målkonto kommer målkontot efter sammanslagning att:

• vara Principal, och
• fortsatt ha rollen ”Kan ej logga in som annan användare”.

Den begränsande rollen tas inte bort automatiskt.

---

Skol‑, klass- och gruppkopplingar

För kopplingar till skolor, klasser, undervisningsgrupper och andra grupper gäller:

• Alla skolkopplingar från båda konton förs över till målkontot:
  • om båda konton är kopplade till samma skola/enhet behålls en (1) samlad koppling till den enheten,
  • historiska skolkopplingar bevaras i den mån de redan finns i datamodellen.
• Medlemskap i klasser, undervisningsgrupper och andra grupper unions‑slås:
  • om båda konton är kopplade till samma klass/grupp behålls en konsoliderad koppling,
  • om de är kopplade till olika klasser/grupper bevaras samtliga kopplingar på målkontot.
• Tidsmässiga överlapp (t.ex. elev registrerad i två klasser under samma period) rättas inte automatiskt bort, eftersom de kan avspegla faktisk historik (t.ex. felregistreringar som redan lett till noterad undervisning eller närvaro).
  • sådana överlapp får vid behov hanteras i efterhand via ordinarie administrationsfunktioner.

Exempel:
En elev har i praktiken flyttats från klass 7A till 7B, men har under en period legat fel i källsystemet och därför haft ett konto i Vklass kopplat till båda klasserna. Efter sammanslagning kan eleven fortfarande ha historik i både 7A och 7B; det är upp till verksamheten att avgöra om någon av dessa kopplingar ska städas bort manuellt.

---

Relationer vårdnadshavare–barn och andra relationer

När relationer överlappar eller skiljer sig åt mellan konton gäller:

• Relationer vårdnadshavare–barn från källkontot förs över till målkontot:
  • om samma relation redan finns på målkontot skapas ingen dubblett,
  • målkontot får en samlad uppsättning barnkopplingar (”union”).
• Om samma vårdnadshavare–barn‑relation har olika status på kontona (t.ex. spärrad på källkontot men inte på målkontot):
  • den mest restriktiva tolkningen ska gälla efter sammanslagning,
  • en spärrad relation ska alltså fortsätta vara spärrad även efter sammanslagning,
  • en icke‑spärrad relation får aldrig automatiskt ”avspärra” en relation som tidigare varit spärrad utifrån ett verksamhetsbeslut.
• Andra relationer (t.ex. mentor–elev, elevhälsokontakter, handledarroller) unions‑slås på motsvarande sätt:
  • relationer som bara finns på källkontot läggs till,
  • dubbletter mot samma objekt och period konsolideras till en relation.

Exempel:
En vårdnadshavare har två konton. På det ena kontot är relationen till barn A spärrad (vårdnadshavaren ska inte ha digital åtkomst till barnet), på det andra kontot är relationen fortfarande aktiv. Efter sammanslagning ska relationen A–vårdnadshavare fortsatt betraktas som spärrad; funktionaliteten får inte av misstag återskapa åtkomst som verksamheten beslutat att bryta.

---

Koppling till verksamhetssystem och identitetskonflikter

När båda konton är kopplade till synkronisering mot verksamhetssystem och har olika identitetsnycklar (t.ex. olika personnummer eller olika externa ID) gäller:

• Funktionen ändrar aldrig data i källsystemen.
• Org‑admin måste välja målkonto med stor omsorg:
  • rekommendationen är att välja det konto som motsvarar den identitet som verksamhetssystemen använder framåt (gällande personnummer/ID) som målkonto,
  • avvikelser i ID (t.ex. gammalt och nytt personnummer) ska markeras tydligt i konfliktöversikten innan sammanslagning kan bekräftas.
• Efter sammanslagning ska synkroniseringen:
  • fortsätta använda målkontots identitetsnyckel som mottagare av uppdateringar,
  • inte skapa ett nytt separat konto baserat på källkontots gamla ID.
• Om det finns risk att gamla ID‑värden (t.ex. tidigare personnummer eller TF‑nummer) fortfarande kan förekomma i synkroniseringsunderlaget:
  • bör dessa hanteras genom uppdatering i käll

Use case UC01 – Radera användarkonto med karenstid

User story

Som organisationsadministratör vill jag på ett kontrollerat och spårbart sätt kunna markera ett användarkonto för radering med en standardiserad karenstid, så att kontot endast raderas permanent om personen inte längre förekommer i synkroniseringsunderlaget under hela karensperioden, och så att jag har möjlighet att ångra eller justera åtgärden innan raderingen blir irreversibel.

---

Acceptanskriterier – övergripande

1. Funktionen ska kunna användas för alla typer av användarkonton inom organisationen:

   • elev/barn,
   • personal,
   • vårdnadshavare, oavsett om kontot är synkroniserat från verksamhetssystem eller manuellt skapat i Vklass (inkl. TF‑nummer och andra avvikande identiteter).

2. Endast användare med rollen organisationsadministratör (Org‑admin), eller annan uttryckligen tilldelad systemnära administratörsroll, ska kunna:

   • markera ett konto för radering,
   • se och hantera konton i karenslista,
   • ångra planerad radering.

3. Funktionen får inte uppdatera, radera eller på annat sätt påverka data i bakomliggande verksamhetssystem. Samtliga åtgärder avser endast:

   • Vklass interna användarkonto,
   • dess kopplingar och kontorelaterade data i Vklass.

---

Acceptanskriterier – initiera radering (”Markera för radering”)

4. Org‑admin ska i den utökade användarhanteringen kunna söka fram ett användarkonto (elev/barn, personal, vårdnadshavare) via minst:

   • personnummer/ID (inklusive TF‑nummer och andra avvikande identiteter, t.ex. 120813‑TF21),
   • namn (för‑ och/eller efternamn),
   • skola/enhet,
   • klass/grupp/avdelning,
   • för vårdnadshavare: även via koppling till specifikt barn (t.ex. genom att utgå från barnets profil).

   Exempel: En Org‑admin söker fram en elev via personnummer, eller en vårdnadshavare via barnets namn och skola, och öppnar därefter kontots detaljvy.

5. När ett konto valts för radering ska systemet visa en översiktlig sammanfattning av kontot, minst innehållande:

   • namn,
   • personnummer/ID,
   • roll/roller i Vklass (elev/barn, personal, vårdnadshavare; inkl. kombinationer),
   • aktuella skol-/enhetskopplingar,
   • klass-/gruppkopplingar (i kortform),
   • eventuella vårdnadshavare–barn‑relationer (för vårdnadshavare),
   • om kontot är synkroniserat eller manuellt skapat.

6. Org‑admin ska tydligt och explicit behöva välja åtgärden Markera för radering på kontots detaljvy. Åtgärden ska inte kunna aktiveras av misstag (t.ex. genom enkel radklick i en lista).

7. Innan kontot läggs i karens ska en bekräftelsedialog visas som minst innehåller:

   • en kortfattad men tydlig beskrivning av konsekvenserna:
     • att kontot planeras att raderas permanent ur Vklass (inklusive kopplingar och kontorelaterad data enligt regler för kontoradering),
   • information om att:
     • raderingen kan ångras av Org‑admin under pågående karenstid,
   • information om villkoren för slutlig radering:
     • att permanent radering endast sker om användaren inte förekommer i synkroniseringsunderlaget under en sammanhängande karensperiod (standard 48 timmar).

8. Org‑admin måste aktivt bekräfta åtgärden i dialogen (t.ex. genom att klicka på ”Bekräfta” eller motsvarande) för att markeringen ska genomföras. Utan bekräftelse ska inget konto läggas i karens.

9. När bekräftelsen genomförts ska systemet:

   • tilldela kontot statusen ”Markerat för radering”,
   • registrera starttid för karens (tidpunkten då markeringen genomfördes),
   • lägga in kontot i karenslistan med komplett karensinformation.

   Exempel: En elev som avslutats i elevregistret markeras för radering i Vklass kl. 10:15. Från denna tidpunkt visas eleven med status ”Markerat för radering” och ingår i karenslistan.

---

Acceptanskriterier – karenstid och karenslista

10. Karenstiden ska som standard vara 48 timmar (konfigurerbar på organisationsnivå enligt Vklass generella inställningar) och tolkas som en sammanhängande period under vilken användaren inte får förekomma i synkroniseringsunderlaget för att slutlig radering ska vara möjlig.

11. Samtliga konton som är markerade för radering ska visas i en särskild karenslista (raderingskö) som:

    • endast är åtkomlig för Org‑admins (och eventuella särskilt utsedda systemnära administratörer),
    • inte är synlig för övriga roller (t.ex. SchoolAdmin, Principal, lärare, elevhälsa).

12. För varje konto i karenslista ska följande minst visas, så länge kontot inte är slutligt raderat:

    • namn,
    • personnummer/ID (i den detaljnivå som Org‑admin normalt har behörighet att se),
    • roll/roller (elev/barn, personal, vårdnadshavare),
    • primär skola/enhet,
    • tidpunkt då kontot markerades för radering (start av karens),
    • senaste tidpunkt då användaren förekom i synkroniseringsunderlaget (alternativt markering att användaren inte förekommit sedan raderingsstart),
    • aktuell status i raderingsflödet, t.ex.:
      • ”I karens – förekommer i synkronisering”,
      • ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
      • ”Redo för radering – väntar på slutlig kontroll”,
      • ”Tillfälligt stoppad – avvaktar lyckad synkronisering”,
    • beräknad tidigaste tidpunkt då radering kan ske, baserat på senast kända förekomst i synkronisering och karenstidens längd.

13. Karenslistan ska erbjuda stöd för effektiv hantering genom att minst kunna:

    • filtreras på:
      • roll (elev/barn, personal, vårdnadshavare),
      • skola/enhet,
      • status i raderingsflödet,
    • sorteras på:
      • tidpunkt för markering för radering,
      • beräknad tidigaste raderingstid,
    • sökas i på:
      • personnummer/ID,
      • namn.

Exempel: En Org‑admin filtrerar karenslistan på ”Gymnasieskola A” och ”Elev” för att se vilka gymnasieelever på en viss skola som för närvarande är markerade för radering.

---

Acceptanskriterier – interaktion med synkronisering

14. Vid varje genomförd synkroniseringskörning för organisationen ska systemet automatiskt:

    • jämföra identitetsnyckeln (personnummer/ID) för alla konton i karenslistan mot det aktuella synkroniseringsunderlaget (elev/barn, personal, vårdnadshavare),
    • uppdatera fältet ”senaste förekomst i synkronisering” för de konton där personen förekommer,
    • uppdatera status för respektive konto i karenslistan utifrån om användaren förekommer eller inte.

15. Om en användare som ligger i karens förekommer i synkroniseringsunderlaget vid en körning ska systemet:

    • sätta (eller behålla) status för kontot till ”I karens – förekommer i synkronisering”,
    • tolka detta som att karensvillkoret inte är uppfyllt,
    • nollställa 48‑timmarsräkningen, så att karenstiden börjar räknas om från tidpunkten för denna senaste förekomst.

16. Om en användare i karens inte förekommer i synkroniseringsunderlaget vid en körning ska systemet:

    • sätta/behålla status ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
    • beräkna och visa:
      • hur lång tid som gått sedan senaste förekomst (eller sedan markering, om användaren inte förekommit därefter),
      • när 48‑timmarsperioden uppnås givet nuvarande frånvarotid i synkroniseringsunderlaget.

17. Om tekniskt fel uppstår som påverkar synkroniseringsunderlaget (t.ex. misslyckad eller avbruten synkronisering) ska systemet:

    • inte genomföra någon slutlig radering baserat på utebliven eller ofullständig synkroniseringsdata,
    • markera berörda poster i karenslistan som tillfälligt stoppade (t.ex. status ”Tillfälligt stoppad – avvaktar lyckad synkronisering”),
    • återuppta normal karenshantering först efter att en lyckad synkronisering genomförts och ny kontroll mot underlaget skett.

Exempel: En nattlig synkronisering misslyckas. Konton som tidsmässigt skulle kunna raderas går inte vidare till slutlig radering förrän nästa lyckade synkronisering har verifierat att användaren fortfarande saknas i underlaget.

---

Acceptanskriterier – genomförd radering efter karenstid

18. Ett konto får endast raderas slutligt (permanent) om båda följande villkor samtidigt är uppfyllda:

    • användaren har inte förekommit i synkroniseringsunderlaget under minst 48 sammanhängande timmar (eller den konfigurerade karenstiden), och
    • en avslutande kontroll mot verksamhetssystem/senaste giltiga synkroniseringsunderlag bekräftar att användaren fortfarande inte förekommer i något av organisationens aktiva synkroniseringsflöden.

19. När båda villkoren i punkt 18 är uppfyllda ska systemet:

    • automatiskt initiera den slutliga raderingen som en bakgrundsprocess,
    • inte kräva ytterligare manuell bekräftelse av Org‑admin för just detta konto (raderingsbeslutet anses taget när kontot markerades för radering och karenstiden löpt ut utan återkomst).

20. Vid slutlig radering ska systemet:

    • ta bort användarkontot som inloggningsbar identitet i Vklass (kontot ska inte längre vara sökbart eller användbart i några gränssnitt),
    • ta bort kontots kopplingar till:
      • skolor/enheter,
      • klasser/grupper/avdelningar,
      • barn (för vårdnadshavare) och andra relationer,
    • gallra kontorelaterad data kopplad till kontot i den omfattning som definierats för kontoradering i Vklass (t.ex. närvaro, resultat, inlämningar, meddelanden), med beaktande av gällande juridiska krav,
    • ta bort kontot ur karenslistan.

21. Efter att slutlig radering genomförts ska:

    • kontot inte kunna återställas via användargränssnittet,
    • eventuell framtida förekomst av personen i verksamhetssystemen leda till att ett nytt konto skapas enligt ordinarie synkroniseringslogik, om inte en separat spärrpost finns i spärrlistan.

---

Acceptanskriterier – återkomst i synkronisering under karens

22. Om en användare som ligger i karens vid någon tidpunkt före slutlig radering åter dyker upp i synkroniseringsunderlaget ska systemet:

    • nollställa den pågående karensberäkningen (48‑timmarsperioden börjar om från den senaste förekomsten),
    • uppdatera kontots status i karenslistan till ”I karens – förekommer i synkronisering”,
    • förhindra att kontot går vidare till slutlig radering förrän en ny sammanhängande karensperiod (minst 48 timmar utan förekomst) har passerat.

23. Om användaren återkommer i synkroniseringen vid eller strax före den beräknade raderingstidpunkten ska:

    • den avslutande kontrollen mot synkroniseringsunderlaget stoppa raderingen,
    • kontot kvarstå i karenslistan med uppdaterad status ”I karens – förekommer i synkronisering”,
    • ny karenstid börja löpa från denna senaste förekomst.

Exempel: En elev avslutas och markeras för radering. 46 timmar senare återaktiveras eleven i elevregistret och dyker upp i nästa synkronisering. Raderingen stoppas och elevens karensperiod startar om från den nya förekomsten.

---

Acceptanskriterier – ångra planerad radering

24. Org‑admin ska från karenslistan kunna välja ett konto och initiera åtgärden Ångra radering för det specifika kontot.

25. När Ångra radering väljs ska systemet:

    • visa en bekräftelsedialog som tydligt anger att:
      • kontot tas bort ur karensflödet,
      • ingen automatisk radering längre kommer att ske baserat på denna markering,
    • kräva att

Use case UC02 – Direkt radering av användarkonto

User story

Som organisationsadministratör vill jag, i tydligt avgränsade undantagsfall, kunna radera ett användarkonto omedelbart – efter automatisk kontroll mot relevanta verksamhetssystem och synkroniseringsunderlag – så att kontot tas bort direkt när det är verifierat att personen inte längre ska finnas i Vklass och inte riskerar att återskapas via synkronisering.

---

Acceptanskriterier – övergripande

1. Funktionen för direkt radering ska kunna användas för samtliga typer av användarkonton inom organisationen:

   • elev/barn,
   • personal,
   • vårdnadshavare, oavsett om kontot är synkroniserat från verksamhetssystem eller manuellt skapat i Vklass (inklusive TF‑nummer och andra avvikande identiteter).

2. Endast användare med rollen organisationsadministratör (Org‑admin), och eventuellt andra uttryckligen utsedda systemnära administratörsroller enligt organisationens behörighetsmodell, ska kunna initiera och genomföra direkt radering.

3. Funktionen får inte uppdatera, radera eller på annat sätt påverka data i bakomliggande verksamhetssystem. All påverkan är begränsad till:

   • Vklass interna användarkonto,
   • kontots kopplingar och kontorelaterade data i Vklass.

4. Direkt radering ska alltid föregås av en obligatorisk teknisk kontroll mot samtliga relevanta synkroniseringsflöden/verksamhetssystem för organisationen. Om kontrollen inte kan genomföras med godkänt resultat ska direkt radering inte tillåtas.

---

Acceptanskriterier – initiera direkt radering

5. Org‑admin ska kunna söka fram det konto som ska raderas direkt via samma sökfunktionalitet som i övrig utökad användarhantering, med stöd för minst:

   • personnummer/ID (inkl. TF‑nummer och andra alternativa identiteter),
   • namn (för‑/efternamn),
   • skola/enhet,
   • klass/grupp/avdelning,
   • för vårdnadshavare: via koppling till specifikt barn (t.ex. genom att utgå från barnets konto).

6. När ett konto valts för radering ska systemet visa en översiktlig, men tillräcklig, sammanfattning av kontot, inkluderande minst:

   • namn,
   • personnummer/ID,
   • roll/roller (elev/barn, personal, vårdnadshavare),
   • aktuella skol‑ och enhetskopplingar,
   • huvudsakliga klass‑/gruppkopplingar,
   • eventuella vårdnadshavare–barn‑relationer (för vårdnadshavare),
   • om kontot är synkroniserat från verksamhetssystem eller manuellt skapat i Vklass (där sådan information finns).

7. I raderingsdialogen på kontots detaljvy ska två separata åtgärdsalternativ tydligt presenteras:

   • standardåtgärd: Markera för radering (med karenstid),
   • alternativ åtgärd: Direkt radering (utan karenstid).

8. Direkt radering ska aldrig vara förvalt val. Det ska krävas ett aktivt, medvetet val av Org‑admin för att byta från standardåtgärden (radering med karenstid) till direkt radering.

9. När Direkt radering valts ska systemet visa en tydlig varnings‑ och informationsdialog som minst klargör att:

   • kontot kommer att raderas omedelbart om kontrollen mot verksamhetssystem/synkroniseringsunderlag passerar,
   • åtgärden inte kan ångras via gränssnittet efter genomförd radering,
   • användaren inte längre kommer att kunna logga in i Vklass efter raderingen,
   • kontot inte längre kommer att vara synligt eller sökbart för administratörer i Vklass,
   • eventuell framtida förekomst av personen i verksamhetssystemen i normalfallet leder till skapande av ett nytt konto, om inte samtidig spärrning sätts.

10. Org‑admin måste genomföra en dubbel bekräftelse för att initiera direkt radering, t.ex. genom att:

    • markera en kryssruta i stil med ”Jag bekräftar att kontot ska raderas direkt och att åtgärden inte kan ångras”, och
    • därefter klicka på en separat bekräftelseknapp (t.ex. ”Radera direkt”).

11. Om Org‑admin avbryter bekräftelsedialogen (stänger den eller väljer Avbryt) ska ingen direkt radering initieras och inget i kontots status förändras.

---

Acceptanskriterier – kontroll mot verksamhetssystem och synkronisering

12. Innan någon direkt radering påbörjas ska systemet utföra en obligatorisk kontroll mot samtliga relevanta synkroniseringsunderlag/verksamhetssystem för organisationen, baserad på samma identitetsnyckel som används i integrationerna (t.ex. personnummer, TF‑nummer eller annat unikt ID).

13. Kontrollen ska verifiera att den berörda identiteten:

    • inte förekommer som aktiv post i något av organisationens aktuella synkroniseringsunderlag (elev‑, personal‑, vårdnadshavarflöden m.fl.), och
    • inte rapporteras på ett sätt som, vid nästa synkroniseringskörning, skulle skapa, återaktivera eller uppdatera ett användarkonto i Vklass.

14. Om kontot är rent manuellt skapat och saknar koppling till synkroniseringsunderlaget ska kontrollen ändå genomföras. Om ingen motsvarande identitet hittas i något verksamhetssystem/synkroniseringsflöde ska detta inte hindra direkt radering.

15. Om kontrollen visar att personen fortfarande förekommer i något synkroniseringsunderlag/verksamhetssystem ska:

    • den direkta raderingen avbrytas innan några ändringar görs,
    • inget i kontot eller dess kopplingar ändras,
    • ett tydligt informationsmeddelande visas för Org‑admin som minst anger att:
      • kontot inte kan raderas direkt eftersom användaren fortfarande är aktiv i ett eller flera verksamhetssystem,
      • användaren först behöver avslutas eller uppdateras i berört källsystem om målet är att på sikt ta bort kontot ur Vklass, eller
      • alternativt kan spärrfunktionen i Vklass användas om åtkomst i Vklass ska stoppas omedelbart trots att källdata under en övergångsperiod fortfarande visar personen som aktiv.

16. Om den tekniska kontrollen mot verksamhetssystem/synkroniseringsunderlag inte kan genomföras (t.ex. på grund av integrationsfel, otillgängligt underlag eller annan systemstörning) ska:

    • den direkta raderingen inte genomföras,
    • inget i kontot ändras,
    • ett felmeddelande visas för Org‑admin där det tydligt framgår att:
      • tekniskt fel hindrade kontrollen,
      • åtgärden får försöka igen när felet är åtgärdat, eller
      • alternativt kan standardflödet med karens användas om verksamheten inte kräver omedelbar radering.

---

Acceptanskriterier – genomförd direkt radering

17. Direkt radering får endast genomföras när båda följande villkor är uppfyllda:

    • den tekniska kontrollen mot verksamhetssystem/synkroniseringsunderlag bekräftar att personen inte förekommer där på ett sätt som skulle skapa/uppdatera kontot i Vklass, och
    • Org‑admin har genomfört den fullständiga dubbelbekräftelsen enligt punkt 10.

18. När villkoren är uppfyllda ska systemet genomföra raderingen som en omedelbar, atomär transaktion, vilket innebär att:

    • användarkontot som identitet i Vklass tas bort,
    • samtliga kopplingar till skolor/enheter, klasser/grupper, barn (för vårdnadshavare) och andra relationer avlägsnas enligt gällande regler för kontoradering,
    • kontorelaterad data i Vklass (t.ex. närvaro, resultat, inlämningar, meddelanden m.m.) gallras i den omfattning som definierats för radering av konto, med beaktande av juridiska krav,
    • alla aktiva sessions‑/inloggningstokens kopplade till kontot ogiltigförklaras så snart det är tekniskt möjligt.

19. Efter genomförd direkt radering ska:

    • kontot inte längre kunna hittas via sökfunktioner i administrationsgränssnittet,
    • kontot inte längre visas i några användar‑, klass‑, grupp‑ eller vårdnadshavarlistor,
    • användaren inte kunna logga in i Vklass med något av sina tidigare inloggningssätt (Vklass‑inloggning, BankID/Freja eID, SSO m.m.),
    • kontot inte finnas i karenslistan (direkt radering använder inte karensflödet).

20. Genomförd direkt radering ska inte kunna ångras via användargränssnittet. Om personen senare åter ska förekomma i Vklass måste detta ske genom:

    • uppdatering i verksamhetssystemen (som skapar ett nytt konto via synkronisering), eller
    • ny manuell kontoskapning i Vklass, beroende på typ av person och integrationsmodell.

---

Acceptanskriterier – interaktion med karensflödet

21. Om ett konto redan är markerat för radering (finns i karenslistan) ska Org‑admin, från karenslistan eller kontots detaljvy, kunna:

    • välja kontot, och
    • initiera Direkt radering som alternativ till att avvakta karenstiden.

22. När Direkt radering initieras för ett konto som ligger i karens ska:

    • karensstatus temporärt pausas under pågående kontroll,
    • en fullständig kontroll mot verksamhetssystem/synkroniseringsunderlag genomföras enligt punkterna 12–16, oberoende av att kontot redan befinner sig i karensflödet.

23. Om kontrollen godkänns och direkt radering genomförs för ett konto i karens ska:

    • kontot raderas omedelbart enligt punkterna 18–19,
    • kontot tas bort från karenslistan,
    • åtgärden loggas som en direkt radering (inte som ”raderad efter karens”).

24. Om kontrollen inte godkänns (personen förekommer i synkroniseringsunderlaget eller tekniskt fel uppstår) ska:

    • ingen radering genomföras,
    • kontot ligga kvar i karenslistan,
    • status i karenslistan uppdateras i enlighet med gällande regler (t.ex. ”I karens – förekommer i synkronisering” eller ”Tillfälligt stoppad – avvaktar lyckad synkronisering”),
    • Org‑admin informeras tydligt om att direkt radering inte kunde utföras och orsaken till detta.

---

Acceptanskriterier – möjlighet att kombinera med spärrning

25. I samband med direkt radering ska Org‑admin kunna välja att, inom samma flöde:

    • spärra inläsning av den berörda personen (personbaserad spärr) från framtida synkronisering, och/eller
    • för vårdnadshavare: spärra specifik relation vårdnadshavare–barn från att återskapas via synkronisering.

26. Val för spärråtgärder ska presenteras i raderingsdialogen som tydliga, separata alternativ (t.ex. kryssrutor):

    • ”Spärra inläsning av denna person via synkronisering” (gäller hela kontot), och
    • om kontot är vårdnadshavare med kopplade barn: ett eller flera alternativ i stil med ”Spärra relationen till barn <namn> (vårdnadshavare–barn)”.

27. Om Org‑admin markerar någon spärråtgärd och direkt radering genomförs ska systemet:

    • först radera kontot enligt reglerna för direkt radering, och
    • därefter automatiskt skapa motsvarande spärrpost(er) i spärrlistan:
      • personbaserad spärr om hela kontot spärrats,
      • relationsbaserad spärr för de vårdnadshavare–barn‑relationer som valts.
    • Vid efterföljande synkroniseringar ska Vklass ignorera inläsning för dessa spärrade identiteter/relationer så länge spärren är aktiv.

28. Om direkt radering avbryts (på grund av teknisk kontroll som inte godkänns eller annat fel) ska:

Use case UC03 – Ångra planerad radering

User story

Som organisationsadministratör (Org‑admin) vill jag under pågående karenstid kunna ångra en tidigare initierad radering av ett användarkonto, så att kontot inte raderas automatiskt när verksamheten beslutar att personen fortsatt ska finnas kvar i Vklass och hanteras enligt ordinarie livscykel.

---

Acceptanskriterier – övergripande

1. Funktionen Ångra radering ska kunna användas för samtliga användartyper i organisationen:

   • elev/barn,
   • personal,
   • vårdnadshavare, oavsett om kontot är synkroniserat från verksamhetssystem eller manuellt skapat i Vklass (inkl. konton med TF‑nummer och andra avvikande identiteter).

2. Endast användare med rollen Organisationsadministratör (Org‑admin) eller annan uttryckligen utsedd systemnära administratörsroll (enligt organisationens behörighetsmodell för den utökade användarhanteringen) ska kunna:

   • se karenslistan,
   • initiera och genomföra åtgärden Ångra radering.

3. Funktionen får inte uppdatera, radera eller på annat sätt påverka data i bakomliggande verksamhetssystem (elev‑, personal‑ eller vårdnadshavarregister). Samtliga effekter är begränsade till:

   • Vklass interna användarkonto,
   • kontots kopplingar och kontorelaterade data i Vklass,
   • den interna karenshanteringen.

---

Acceptanskriterier – åtkomst, urval och karenslista

4. Org‑admin ska via den utökade användarhanteringen ha åtkomst till en karenslista (raderingskö) som visar alla användarkonton som:

   • är markerade för radering (”Markerad för radering”), och
   • ännu inte raderats permanent.

5. För varje konto i karenslistan ska minst följande information visas, så länge kontot finns kvar:

   • namn,
   • personnummer/ID (inkl. TF‑nummer eller annan identitet), i den utsträckning Org‑admin normalt har behörighet att se,
   • roll/roller (elev/barn, personal, vårdnadshavare),
   • primär skola/enhet,
   • tidpunkt då kontot markerades för radering (starttid för karens),
   • tidpunkt för senast kända förekomst i synkroniseringsunderlaget (eller markering om ingen förekomst skett efter markering),
   • aktuell status i raderingsflödet (t.ex. ”I karens – förekommer i synkronisering”, ”I karens – ingen förekomst i synkronisering (karenstid pågår)”, ”Redo för radering – väntar på slutlig kontroll”).

6. Karenslistan ska ge Org‑admin möjlighet att effektivt hitta aktuella konton genom:

   • sökning minst på:
     • personnummer/ID,
     • namn,
   • filtrering minst på:
     • roll (elev/barn, personal, vårdnadshavare),
     • skola/enhet,
     • status i raderingsflödet,
   • sortering minst på:
     • tidpunkt för markering för radering,
     • beräknad tidigaste raderingstid.

   Exempel: En Org‑admin filtrerar karenslistan på ”Vuxenutbildning” och roll ”Elev” för att se vilka studerande som är markerade för radering men där raderingen eventuellt behöver pausas.

7. Endast konton som:

   • är markerade för radering (d.v.s. har en aktiv karenspost), och
   • ännu inte raderats permanent, ska kunna omfattas av åtgärden Ångra radering.
     Konton som redan raderats ska inte längre visas i karenslistan och får inte kunna ångras.

---

Acceptanskriterier – initiera åtgärden ”Ångra radering”

8. För varje konto i karenslistan ska det finnas en tydlig och entydig åtgärd för Ångra radering (t.ex. knapp eller länk i tabellraden eller i en detaljerad vy för kontot).

9. När Org‑admin väljer Ångra radering för ett konto ska systemet visa en bekräftelsedialog som minst innehåller:

   • identifierande uppgifter om kontot (namn och personnummer/ID),
   • en kortfattad beskrivning av åtgärdens innebörd, t.ex.:
     • att kontot tas bort ur karenslistan,
     • att ingen automatisk radering längre kommer att utföras baserat på den tidigare markeringen,
     • att kontot fortsatt kommer att hanteras som ett aktivt konto i Vklass och påverkas av framtida synkronisering som vanligt.

10. Org‑admin måste aktivt bekräfta åtgärden (t.ex. genom att klicka på en knapp ”Bekräfta – ångra radering”).

    • Om dialogen stängs utan bekräftelse eller Avbryt väljs ska ingen förändring ske; kontot ligger då kvar i karenslistan med oförändrad status.

Exempel: En Org‑admin får besked från skolan att en elev som slutat och markerats för radering i själva verket ska återinskrivas. Org‑admin söker upp eleven i karenslistan, väljer Ångra radering, kontrollerar elevens uppgifter i dialogen och bekräftar åtgärden.

---

Acceptanskriterier – effekter av ångrad radering

11. När åtgärden Ångra radering bekräftats för ett konto ska systemet omedelbart och atomärt:

    • ta bort kontot ur karenslistan (ingen karenspost kvarstår),
    • avbryta raderingsflödet för kontot helt (inga automatiska raderingsåtgärder kommer att utföras baserat på den tidigare markeringen),
    • nollställa all intern karensstatus kopplad till kontot.

12. Efter ångrad radering ska kontot:

    • fortsatt vara fullt sökbart och administrerbart i Vklass via ordinarie användaradministration,
    • ha kvar samtliga:
      • roller (elev/barn, personal, vårdnadshavare),
      • skol-/enhetskopplingar,
      • klass‑, grupp‑ och avdelningskopplingar,
      • vårdnadshavare–barn‑relationer och andra relationer,
        i samma läge som direkt innan åtgärden genomfördes,
    • kunna omfattas av andra administrativa åtgärder i den utökade användarhanteringen, t.ex.:
      • ny markering för radering,
      • sammanslagning med ett annat konto,
      • spärrning av kontot eller specifika relationer.

Exempel: Efter att en felaktigt initierad radering ångrats kan skoladministratören omedelbart hitta personen i vanliga användarlistor, koppla personen till klasser eller fortsätta registrera frånvaro/resultat utan avbrott.

13. Åtgärden Ångra radering ska inte automatiskt:
    • skapa, ändra eller ta bort spärrposter i spärrlistan (varken personbaserade spärrar eller spärrar av vårdnadshavare–barn‑relationer),
    • ändra befintlig spärrstatus för personen eller dess relationer,
    • påverka beslutslogik eller innehåll i bakomliggande verksamhetssystem.
      Eventuella spärrar som redan finns måste fortsatt hanteras separat via spärrfunktionen.

---

Acceptanskriterier – begränsningar, samtidighet och felhantering

14. Det ska inte vara möjligt att ångra radering för ett konto som:

    • redan har raderats slutligt (kontot ska då inte längre finnas i karenslistan eller kunna väljas), eller
    • aldrig varit markerat för radering via karensflödet.

15. Vid samtidig hantering av samma konto av flera administratörer (t.ex. två Org‑admins försöker åtgärda kontot parallellt, där en initierar direkt radering och en annan Ångra radering) ska systemet:

    • tillämpa transaktionssäkerhet så att endast en åtgärd kan slå igenom,
    • säkerställa att resultatet efter genomförd transaktion är konsekvent:
      • antingen ligger kontot kvar i karens med intakt status,
      • eller så är kontot antingen ångrat (inte längre i karens) eller raderat,
    • visa ett tydligt meddelande till den åtgärd som inte kunde genomföras, t.ex.:
      • ”Kontot är inte längre markerat för radering”,
      • ”Åtgärden kunde inte genomföras eftersom en annan administratör redan ändrat kontots status”.

16. Om ett tekniskt fel uppstår i samband med att Ångra radering genomförs (t.ex. databasfel, timeout eller avbruten anslutning) ska systemet:

    • inte lämna kontot i ett odefinierat mellanläge där det delvis omfattas av karens och delvis inte,
    • efter återställning tydligt hamna i ett av två lägen:
      • antingen:
        • kontot är fortsatt markerat för radering och kvar i karenslistan (ingen ändring har skett), eller
      • kontot är fullt ut ångrat:
        • borttaget ur karenslistan,
        • utan aktiv karensstatus,
    • visa ett fel‑ eller informationsmeddelande till Org‑admin om att åtgärden eventuellt behöver upprepas.

---

Acceptanskriterier – interaktion med synkronisering och status

17. Möjligheten att ångra en planerad radering ska:

    • vara oberoende av om användaren för närvarande förekommer i synkroniseringsunderlaget eller inte,
    • fungera för konton i samtliga relevanta karensstatusar (t.ex. ”I karens – förekommer i synkronisering”, ”I karens – ingen förekomst i synkronisering”, ”Redo för radering – väntar på slutlig kontroll”).

18. Efter att ett konto ångrats ska:

    • kontot inte längre omfattas av några kontroller kopplade till karensflödet (d.v.s. ingen ytterligare bevakning i syfte att genomföra radering),
    • kommande synkroniseringar behandla kontot enligt ordinarie logik, som om raderingsflödet aldrig hade initierats:
      • uppdateringar från verksamhetssystemen (t.ex. ändrade skolplaceringar, roller eller relationer) ska slå igenom på normalt sätt.

Exempel: En personal som felaktigt markerats för radering men snabbt ångras fortsätter att uppdateras från personalsystemet – t.ex. vid enhetsskifte – utan påverkan av det tidigare raderingsärendet.

---

Acceptanskriterier – loggning, dataminimering och gallring

19. När en planerad radering ångras ska en separat post skapas i åtgärdsloggen för den utökade användarhanteringen. Loggposten ska minst innehålla:

    • tidpunkt för åtgärden (datum och klockslag),
    • typ av åtgärd (t.ex. ”Radering ångrad”),
    • identifiering av ansvarig administratör (Org‑admin) som utförde åtgärden.

20. Identifieringen av det berörda kontot i åtgärdsloggen ska följa principerna för dataminimering:

    • så länge kontot inte är raderat kan loggposten tekniskt kopplas till kontots interna ID i Vklass,
    • om kontot senare raderas (via nytt raderingsflöde) ska visningen av loggposten i gränssnittet begränsas till:
      • högst de sex första siffrorna i personnumret/ID:t (ååmmdd eller motsvarande),
      • förnamn,
      • senaste kända skola/enhet vid åtgärdstillfället,
        utan att de fyra sista siffrorna i personnumret eller andra onödigt precisa identitetsuppgifter exponeras.

21. Loggposter för åtgärden Ångra radering ska omfattas av samma lagringstid och gallringsregler som övriga åtgärdsloggar i den utökade användarhanteringen:

    • maximal lagringstid: 30 dagar från åtgärdstidpunkt,
    • därefter automatisk gallring utan manuell handpåläggning.

---

Acceptanskriterier – användarupplevelse och avgränsningar

22. Åtgärden Ångra radering ska:

    • endast exponeras i kontexten av karenslistan och eventuellt i en detaljerad vy av ett konto som befinner sig i karens,
    • inte visas i vanliga användarsökningar eller listor för konton som inte är markerade för radering,
    • ha en neutral beteckning och beskrivning utan hänvisning till skyddad identitet eller andra särskilda personkategorier; funktionen ska vara generell och gälla alla kontotyper.

23. Ingen automatisk notifiering, e‑post eller systemmeddelande ska skickas till den berörda användaren eller andra roller (t.ex. lärare, skoladministratörer, vårdnadshavare) när en planerad radering ångras.

    • Åtgärden betraktas som en intern administrativ justering som hanteras inom ramen för organisationens egen förvaltnings‑ och informationsprocess.

24. Åtgärden Ångra radering ska inte i sig förändra hur andra delar av systemet fungerar för användaren (t.ex. frånvaroregistrering, resultatvisning, meddelandefunktion), annat än att:

    • kontot fortsatt finns kvar,
    • kontot fortsätter att fungera som ett aktivt, ordinarie konto i Vklass.

Use case UC04 – Sammanslå två användarkonton

User story

Som organisationsadministratör vill jag på ett kontrollerat och spårbart sätt kunna slå ihop två användarkonton som avser samma fysiska person, så att roller, kopplingar och relevant historik konsolideras till ett gemensamt huvudkonto. På så sätt minskar vi antalet dubbletter, undviker felaktiga eller överlappande behörigheter och skapar tydlighet kring vilken identitet som är den aktuella i Vklass.

---

Acceptanskriterier – övergripande

1. Funktionen ska kunna användas för alla typer av användarkonton inom organisationen:

   • elev/barn,
   • personal,
   • vårdnadshavare, inklusive konton som har flera roller (t.ex. personal + vårdnadshavare på samma konto).

2. Funktionen ska kunna användas oavsett kontotyp:

   • synkroniserade konton (från elev‑, personal‑ och/eller vårdnadshavarregister),
   • manuellt skapade konton (t.ex. praktikanter, konsulter, TF‑nummer, alias).

3. Endast användare med rollen Organisationsadministratör (Org‑admin), eller annan uttryckligen utsedd systemnära administratörsroll enligt organisationens behörighetsmodell, ska kunna:

   • initiera sammanslagning,
   • välja vilka två konton som ska slås ihop,
   • välja målkonto respektive källkonto,
   • bekräfta och genomföra sammanslagningen.

4. Funktionen får inte uppdatera, skapa eller radera data i bakomliggande verksamhetssystem (elev‑, personal‑, vårdnadshavarregister). Samtliga ändringar avser endast:

   • Vklass interna användarkonton,
   • deras kopplingar och kontorelaterade data i Vklass.

5. Sammanslagning får endast ske mellan konton som tillhör samma Vklass‑organisation (huvudman/kommun). Systemet ska inte tillåta sammanslagning:

   • mellan konton i olika organisationer,
   • eller på ett sätt som skulle kunna påverka en annan organisations data.

6. Sammanslagningen ska vara irreversibel via användargränssnittet. När sammanslagningen slutförts:

   • upphör källkontot att existera som separat, inloggningsbar identitet,
   • kan källkontot inte återskapas annat än genom Vklass interna tekniska åtgärder (t.ex. i samband med felrättning av Vklass drift/support).

   Exempel: Ett manuellt TF‑konto för en elev slås ihop med det nya, synkroniserade kontot med korrekt personnummer. Efter sammanslagningen kan TF‑kontot inte längre användas eller administreras – endast det synkroniserade kontot finns kvar.

---

Acceptanskriterier – initiera sammanslagning och välja konton

7. Org‑admin ska i den utökade användarhanteringen kunna söka fram kandidater för sammanslagning via samma sökfunktionalitet som i övriga delar av funktionen, med stöd för minst:

   • personnummer/ID (inkl. TF‑nummer och andra avvikande identiteter, t.ex. 120813‑TF21),
   • namn (för‑/efternamn),
   • skola/enhet,
   • klass/grupp/avdelning,
   • för vårdnadshavare: via koppling till specifikt barn (utgå från barnets konto).

8. Org‑admin ska kunna initiera sammanslagning genom att:

   • välja ett första konto (”konto A”) och därefter, via särskild funktion, söka fram och välja ett andra konto (”konto B”) att jämföra med, eller
   • i en söklista markera exakt två konton och välja åtgärden ”Slå ihop konton”.

9. Systemet ska inte tillåta att:

   • samma konto väljs både som konto A och konto B,
   • fler än två konton väljs samtidigt för en och samma sammanslagningsåtgärd.

10. Om något av de valda kontona:

    • tillhör en annan organisation än den org‑admin är inloggad i, eller
    • är ett tekniskt systemkonto eller på annat sätt markerat som icke‑sammanslagningsbart, ska systemet:
    • blockera initiering av sammanslagning,
    • visa ett tydligt felmeddelande som förklarar varför åtgärden inte kan utföras.

---

Acceptanskriterier – jämförelsevy och val av målkonto/källkonto

11. När två konton valts ska systemet visa en jämförelsevy där centrala uppgifter presenteras sida vid sida för konto A och konto B, minst:

    • namn,
    • personnummer/ID (inkl. TF‑nummer eller annat ID),
    • roll/roller (elev/barn, personal, vårdnadshavare),
    • skol‑ och enhetskopplingar,
    • klass‑, grupp‑ och avdelningstillhörighet (översiktligt),
    • vårdnadshavare–barn‑relationer (för konton med rollen vårdnadshavare),
    • kontots ursprung, där det finns, t.ex.:
      • ”Synkroniserat från Elevsystem X”,
      • ”Synkroniserat från Personalsystem Y”,
      • ”Manuellt skapat i Vklass”,
    • tydliga markeringar av uppenbara avvikelser:
      • olika personnummer/ID,
      • olika efternamn,
      • markant olika roller eller skolkopplingar.

12. I jämförelsevyn ska Org‑admin tydligt och explicit kunna välja:

    • vilket konto som ska vara målkonto (huvudkonto som finns kvar efter sammanslagning), och
    • vilket konto som ska vara källkonto (det konto vars data och kopplingar förs över och som därefter upphör).

13. Systemet ska visuellt markera målkonto, t.ex. genom:

    • rubrik ”Målkonto” över den ena kolumnen,
    • och rubrik ”Källkonto” över den andra.

14. Om något av kontona är synkroniserat från ett verksamhetssystem ska detta framgå tydligt, t.ex. via etikett:

    • ”Synkroniserat konto (rekommenderas som målkonto)”. Systemet får visa en rekommendation, men det slutliga valet av målkonto ligger alltid hos Org‑admin.

15. Om grundläggande identitetsuppgifter skiljer sig åt mellan kontona (t.ex. olika personnummer/ID, olika födelsedatum, olika efternamn) ska detta:

    • markeras tydligt i jämförelsevyn (t.ex. med varningsikon och kort text),
    • inte hindra sammanslagning i sig, men Org‑admin ska behöva bekräfta att kontona ändå avser samma person.

16. Innan sammanslagningen kan genomföras ska en bekräftelsedialog visas med:

    • tydlig angivelse av valda konton:
      • målkonto: namn + personnummer/ID,
      • källkonto: namn + personnummer/ID,
    • sammanfattning av vad som kommer att ske:
      • att målkontot blir kvar som enda aktiva konto,
      • att källkontot upphör som egen inloggningsbar identitet,
      • att roller, kopplingar och historik så långt möjligt förs över till målkontot,
    • varning om att åtgärden är irreversibel via gränssnittet.

17. Org‑admin måste aktivt:

    • bekräfta att de två kontona avser samma fysiska person (t.ex. kryssruta ”Jag bekräftar att dessa konton avser samma person”), och
    • bekräfta åtgärden via en särskild knapp (t.ex. ”Genomför sammanslagning”). Om något av dessa steg avbryts ska ingen sammanslagning genomföras.

Exempel: En elev har haft ett manuellt TF‑konto 120813‑TF21 Anna Demo och har nu ett synkroniserat konto 20120813‑1234 Anna Andersson. Org‑admin jämför kontona, väljer det synkroniserade kontot som målkonto, bekräftar att det rör samma person och genomför sammanslagningen.

---

Acceptanskriterier – förutsättningar och begränsningar före sammanslagning

18. Systemet ska inte tillåta sammanslagning om:

    • något av kontona är markerat för radering (finns i karenslista), eller
    • något av kontona är föremål för en redan pågående sammanslagningstransaktion.

19. Om ett konto är markerat för radering ska Org‑admin informeras om att:

    • raderingen först måste ångras (via funktionen Ångra radering),
    • innan det är möjligt att använda kontot i en sammanslagningsåtgärd.

20. Om ett konto finns på spärrlista (personbaserad spärr) ska detta:

    • tydligt framgå i jämförelsevyn (t.ex. etikett ”Kontot är spärrat från synkinläsning”),
    • inte automatiskt hindra sammanslagning, men Org‑admin ska informeras om att spärren behöver hanteras separat i spärrfunktionen efter sammanslagning vid behov.

21. Om tekniska kontroller (t.ex. databaslås, otillgängliga underliggande tabeller) hindrar en säker sammanslagning ska systemet:

    • avbryta åtgärden,
    • inte genomföra några ändringar på något av kontona,
    • visa ett tydligt felmeddelande som anger att åtgärden inte slutfördes.

---

Acceptanskriterier – genomförande och dataövertag (målkonto/källkonto)

22. Vid genomförd sammanslagning ska målkontots grundidentitet vara styrande:

    • personnummer/ID, födelsedatum och andra primära identitetsfält på målkontot skrivs inte automatiskt över med värden från källkontot,
    • om annan identitet ska gälla framåt är det Org‑admins ansvar att ha valt rätt konto som målkonto eller att justera i källsystemen.

23. Inloggningsuppgifter kopplade till källkontot ska efter sammanslagning:

    • avaktiveras eller tas bort,
    • inte längre kunna användas för inloggning i Vklass. Inloggning ska ske via de inloggningsmetoder som är knutna till målkontot.

Exempel: En lärare har tidigare loggat in med ett manuellt Vklass‑konto och får senare ett SSO‑baserat synkroniserat konto. Efter sammanslagning ska endast SSO‑inloggningen fungera.

24. Roller (elev/barn, personal, vårdnadshavare) ska unions‑slås:

    • alla roller som finns på något av kontona ska finnas på målkontot,
    • inga dubbletter av samma roll för samma organisatoriska kontext ska skapas.

25. Specifika behörigheter/rättigheter (t.ex. SchoolPrincipal, SchoolStudentAdvisor, stödroller, lokala adminroller, begränsande roller) ska också unions‑slås:

    • en behörighet som finns på minst ett av kontona ska finnas kvar på målkontot,
    • begränsande eller säkerhetshöjande roller (t.ex. ”Kan ej logga in som annan användare”) får inte tas bort automatiskt,
    • systemet får inte automatiskt minska en användares behörighet; eventuell ”städrensning” av behörigheter görs manuellt efter sammanslagning via ordinarie behörighetsgränssnitt.

26. Samtliga skol‑ och enhetskopplingar från båda kontona ska föras över till målkont

Use case UC05 – Användare återkommer i synkronisering

User story

Som organisationsadministratör vill jag att systemet automatiskt hanterar och tydligt visar när en användare som är markerad för radering återkommer i synkroniseringsunderlaget, så att:

• kontot inte raderas felaktigt så länge personen fortfarande betraktas som aktiv i något verksamhetssystem,
• karenstiden räknas om på ett korrekt och förutsägbart sätt, och
• jag i karenslistan kan förstå varför ett konto inte har raderats vid den tidpunkt jag först förväntade mig.

---

Acceptanskriterier – övergripande

1. Funktionen ska gälla för alla användarkonton som kan ligga i karenslista, oavsett roll:

   • elev/barn,
   • personal,
   • vårdnadshavare,
     och oavsett om kontot är synkroniserat från verksamhetssystem eller manuellt skapat i Vklass (inkl. TF‑nummer och andra avvikande identiteter).

2. Återkomst i synkronisering ska alltid hanteras automatiskt av systemet. Org‑admin ska inte behöva göra några manuella ingrepp för att stoppa eller skjuta upp radering när användaren åter finns i synkroniseringsunderlaget.

3. En återkomst i synkroniseringen får aldrig leda till omedelbar radering. Den ska alltid innebära att:

   • pågående karenstid nollställs, och
   • eventuell planerad radering senareläggs eller helt uteblir tills villkoret för radering (en sammanhängande konfigurerad karenstid, t.ex. 48 timmar, utan förekomst i synkroniseringsunderlaget) återigen är uppfyllt.

4. Funktionen får inte uppdatera, radera eller på annat sätt påverka data i bakomliggande verksamhetssystem. Den styr enbart:

   • status och tidsberäkning i karenslistan, samt
   • om och när Vklass får genomföra den slutliga raderingen av kontot.

---

Acceptanskriterier – identifiering av återkomst

5. Vid varje genomförd synkroniseringskörning för organisationen ska Vklass:

   • iterera över samtliga konton i karenslistan, och
   • jämföra respektive kontos identitetsnyckel (t.ex. personnummer, TF‑nummer eller annat unikt integrations‑ID) mot aktuellt synkroniseringsunderlag för alla relevanta flöden (elev/barn, personal, vårdnadshavare).

6. Om identitetsnyckeln för ett konto i karenslistan återfinns i synkroniseringsunderlaget ska detta registreras som en återkomst, oavsett:

   • om användaren tidigare varit frånvarande under en del av karensperioden, eller
   • om detta är första synkroniseringen sedan kontot markerades för radering.

7. Återkomst ska detekteras oberoende av vilken roll eller vilka organisatoriska kopplingar personen har i underlaget vid det aktuella tillfället. Följande förändringar ska t.ex. inte hindra att återkomst upptäcks:

   • byte av roll (t.ex. från elev/barn till personal i vuxenutbildning),
   • byte av skola/enhet, klass, grupp eller avdelning,
   • förändrade vårdnadshavare‑relationer.

   Det avgörande är en träff på samma identitetsnyckel som kontot i karenslista är kopplat till.

---

Acceptanskriterier – uppdatering av status och tidsberäkning

8. När en återkomst konstateras ska systemet omedelbart:

   • uppdatera fältet ”Senaste förekomst i synkronisering” för kontot till tidpunkten för den aktuella synkroniseringskörningen, och
   • sätta (eller behålla) kontots status i karenslistan till ”I karens – förekommer i synkronisering”.

9. Den pågående karenstiden ska nollställas vid återkomst:

   • all tidigare upparbetad tid utan förekomst i synkroniseringsunderlaget ska anses förbrukad,
   • en ny, sammanhängande karensperiod (t.ex. 48 timmar, enligt konfigurerad karenstid) måste därefter löpa utan att identiteten förekommer i någon synkronisering.

10. Om användaren, efter att ha markerats för radering, aldrig har varit frånvarande i synkroniseringsunderlaget ska kontot:

    • ligga kvar med status ”I karens – förekommer i synkronisering”,
    • inte anses ha påbörjat någon giltig karensperiod,
    • inte kunna gå vidare till status ”Redo för radering”.

11. När en synkroniseringskörning inte innehåller kontots identitet ska systemet:

    • sätta/behålla statusen ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
    • beräkna:
      • hur lång tid som hittills förflutit sedan senaste förekomst i synkronisering, och
      • hur lång tid som återstår tills karenstiden är uppfylld (t.ex. ”12 timmar kvar”),
    • uppdatera beräknad tidigaste möjliga raderingstidpunkt baserat på nuvarande frånvaroperiod och karenstiden.

---

Acceptanskriterier – påverkan på raderingsbeslut

12. Ett konto som återkommer i synkroniseringsunderlaget får inte:

    • raderas direkt i anslutning till återkomsten, eller
    • klassas som ”Redo för radering” förrän en ny, fullständig karensperiod (t.ex. 48 sammanhängande timmar utan förekomst) har passerat efter den senaste registrerade förekomsten.

13. Om ett konto ligger i status ”Redo för radering – väntar på slutlig kontroll/genomförande” och användaren åter dyker upp i synkroniseringsunderlaget innan den slutliga raderingen har påbörjats, ska den avslutande kontrollen mot synkroniseringsunderlaget:

    • upptäcka denna återkomst,
    • stoppa den planerade raderingen, och
    • återställa kontots status till ”I karens – förekommer i synkronisering”.

14. Raderingsvillkoret ”karenstiden (t.ex. 48 timmar) utan förekomst i synkroniseringen” ska alltid tolkas som en strikt sammanhängande period. Varje registrerad återkomst:

    • avbryter en pågående tidräkning, och
    • kräver att en ny fullständig karensperiod uppnås från den nya tidpunkten för senaste förekomst i synkronisering.

Exempel:
En elev markeras för radering måndag kl. 10.00. Eleven saknas i synkroniseringen måndag kväll och tisdag morgon. Tisdag kl. 15.00 återaktiveras eleven i elevregistret och förekommer i tisdagens kvällssynkronisering. Kontot byter då status till ”I karens – förekommer i synkronisering” och karenstiden börjar räknas om från tisdag kl. 22.00. De ~30 timmarna från måndag–tisdag räknas inte längre mot karensvillkoret.

---

Acceptanskriterier – presentation i karenslista (UI)

15. Karenslistan ska efter varje synkronisering uppdateras så att Org‑admin alltid ser kontots aktuella status i förhållande till synkroniseringen. För varje konto där en återkomst skett ska det tydligt framgå att:

    • användaren fortfarande förekommer i synkroniseringsunderlaget, och
    • kontot därmed inte kommer att raderas förrän en ny, fullständig karensperiod utan förekomst har förflutit.

16. För varje konto i karenslistan ska följande uppgifter minst vara synliga:

    • tidpunkt då kontot markerades för radering,
    • senast kända tidpunkt då identiteten förekom i synkroniseringsunderlaget (uppdateras vid varje återkomst),
    • aktuell status, t.ex.:
      • ”I karens – förekommer i synkronisering”,
      • ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
      • ”Redo för radering – väntar på slutlig kontroll/genomförande”,
    • beräknad tidigaste möjliga raderingstidpunkt baserad på senaste förekomst i synkronisering + karenstid,
    • en kort statusförklaring, t.ex.:
      • ”Karenstiden räknas från senaste förekomst i synkronisering”.

17. När användaren under en period inte förekommer i synkroniseringsunderlaget ska detta tydligt återspeglas genom:

    • byte av status till ”I karens – ingen förekomst i synkronisering (karenstid pågår)”, och
    • visning av hur långt in i karensperioden kontot befinner sig, t.ex. ”24 av 48 timmar uppfyllda”.

---

Acceptanskriterier – interaktion med manuella åtgärder

18. Org‑admin ska, oavsett om användaren för närvarande förekommer i synkroniseringsunderlaget eller inte, när som helst kunna:

    • Ångra radering för kontot (vilket tar bort kontot ur karenslistan och avslutar raderingsflödet),
    • initiera direkt radering (vilket då alltid måste genomgå en separat, aktuell kontroll mot synkroniseringsunderlaget),
    • lägga till, ändra eller ta bort spärrar för:
      • hela personen (personbaserad spärr), och/eller
      • specifika relationer (t.ex. spärrad vårdnadshavare–barn‑relation) via spärrfunktionen.

19. Om Org‑admin ånger radering efter att användaren återkommit i synkroniseringen ska systemet:

    • omedelbart ta bort kontot ur karenslistan,
    • nollställa all karens‑ och raderingsstatus kopplad till kontot,
    • låta kommande synkroniseringar hantera kontot enligt ordinarie logik, som om kontot aldrig varit markerat för radering.

20. Om Org‑admin försöker initiera direkt radering för ett konto vars identitet nyligen återfunnits i synkroniseringsunderlaget ska den obligatoriska kontrollen mot verksamhetssystem/synkroniseringsunderlag normalt visa att:

    • användaren fortfarande förekommer i källdata, och därmed
    • inte uppfyller villkoren för direkt radering.

    I sådant fall ska:

    • ingen radering genomföras,
    • Org‑admin få ett tydligt fel‑/informationsmeddelande om att direkt radering inte är möjlig så länge personen finns i synkroniseringsunderlaget, samt hänvisning till:
      • att invänta avslut i källsystemet,
      • eller att använda spärrfunktionen om åtkomst i Vklass trots allt måste stoppas omedelbart.

---

Acceptanskriterier – fel‑ och specialfall

21. Om en planerad radering är redo att genomföras (d.v.s. villkoret ”karenstid utan förekomst” bedöms preliminärt uppfyllt) men:

    • den senaste synkroniseringen ännu inte har genomförts, eller
    • den senaste synkroniseringen misslyckats eller bedömts som ogiltig,

    ska systemet:

    • inte genomföra slutlig radering,
    • i stället behålla kontot i karenslista, och
    • markera status som t.ex. ”Tillfälligt stoppad – avvaktar lyckad synkronisering”.

    Först efter en lyckad, komplett synkronisering som bekräftar fortsatt frånvaro får kontot gå vidare till slutlig radering.

22. Om en persons identitetsuppgifter har ändrats i verksamhetssystemen (t.ex. byte från TF‑nummer till svenskt personnummer eller ändrat personnummer) och både det gamla och det nya ID:t under en övergångsperiod förekommer i synkroniseringsunderlaget, ska följande gälla:

    • Återkomstlogiken ska alltid utgå från den identitetsnyckel som är kopplad till kontot i Vklass.
    • Ingen radering får genomföras enbart på basis av att den ”gamla” identiteten inte längre förekommer, om det samtidigt finns skäl att anta att samma fysiska person nu förekommer under ett nytt ID.
    • Sådana scenarier ska i första hand hanteras genom:
      • korrigering i verksamhetssystemen,
      • sammanslagning av konton (t.ex. TF‑konto → konto med korrekt personnummer), och/eller
      • spärrning av gammal identitet,
        inte genom att försöka kringgå återkomst‑ och karenslogiken.

Exempel:
En elev har haft identitet 120813‑TF21 och får senare personnummer 20120813‑1234. Under en övergångsperiod förekommer båda värdena i synkroniseringsunderlaget. Elevens Vklass‑konto är kopplat till det nya personnumret. Radering av kontot får inte baseras på att TF‑ID:t inte längre syns, så länge det nya personnumret fortfarande finns i synkroniseringen.

---

Acceptanskriterier – loggning och dataminimering

23. Varje enskild återkomsthändelse (d.v.s. att en användare i karens åter förekommer vid en viss synkroniseringskörning) behöver inte skapa en separat post i åtgärdsloggen. Återkomsten ska i första hand återspeglas genom:

    • uppdaterat fält ”Senaste förekomst i synkronisering”, och
    • justerad status i karenslistan.

24. Om en redan schemalagd radering stoppas vid den avslutande kontrollen på grund av att användaren åter finns i synkroniseringsunderlaget ska detta betraktas som en relevant administrativ händelse och loggas med minst:

    • tidpunkt (datum och klockslag),
    • typ av händelse, t.ex. ”Planerad radering avbruten – användare åter i synkronisering”,
    • identifiering av den Org‑admin som ursprungligen markerade kontot för radering (där sådan uppgift finns),
    • identifiering av kontot enligt gällande dataminimeringsprinciper:
      • så länge kontot inte raderats kan koppling ske via internt konto‑ID,
      • om kontot sedermera raderas får endast pseudonymiserad information visas i loggvyn (högst de sex första siffrorna i personnumret/ID:t, förnamn och skola/enhet).

25. Loggposter kopplade till avbrutna raderingar ska omfattas av samma lagrings

Sökning och urval av användare

Sökning och urval av användare sker i en gemensam vy i det utökade administrationsgränssnittet och utgör alltid startpunkt för åtgärder som radering (med eller utan karenstid), sammanslagning av konton samt spärrning av inläsning eller relationer. Funktionen är roll‑ och kontotypoberoende och omfattar:

• samtliga användarkategorier: elev/barn, personal och vårdnadshavare,
• både synkroniserade konton (från elev‑, personal‑ och vårdnadshavarregister) och manuellt skapade konton (inkl. TF‑nummer, alias m.m.).

Sökningen är en ren urvals‑ och navigationsfunktion. Den:

• förändrar aldrig några data i sig,
• skickar inga notifieringar till berörda användare,
• visar aldrig mer information än vad Org‑admin redan har behörighet att se i övriga delar av Vklass,
• är strikt avgränsad till den organisation (huvudman/kommun) där den inloggade Org‑admin har behörighet.

Org‑admin ska i samma sökgränssnitt kunna:

• söka fram en enskild användare för vidare åtgärd,
• få en filtrerbar lista över flera kandidater och förfina urvalet stegvis,
• omedelbart se om konton är aktiva, markerade för radering (karenstid) eller spärrade (helt konto eller specifika relationer).

---

Sökparametrar och filter

Sökgränssnittet ska stödja en kombination av flera parametrar samtidigt. Alla angivna kriterier kombineras med logiskt OCH, så att urvalet successivt förfinas. Minst följande parametrar ska finnas:

Personnummer/ID

• Sökning på fullständigt personnummer (10 eller 12 siffror, med eller utan sekelsiffra) eller annat unikt ID som används i Vklass och i synkroniseringsunderlaget.
• Systemet ska vara tolerant för vanliga variationer i formatering, t.ex.:
  • med eller utan bindestreck (ÅÅMMDD-XXXX / ÅÅMMDDXXXX / ÅÅÅÅMMDDXXXX),
  • eventuella mellanslag.
• TF‑nummer och andra avvikande identiteter (t.ex. 120813‑TF21) ska behandlas som vanliga ID‑värden ur söksynpunkt; ingen särskild logik för ”skyddad identitet” tillämpas.
• Vid exakt match på personnummer/ID ska användaren kunna presenteras som primär träff, med möjlighet för Org‑admin att:
  • gå direkt till kontots detaljvy, eller
  • stanna i resultatlistan om flera konton delar samma ID (t.ex. vid felregistrerad dubblett).

Exempel:
En elev med TF‑nummer 120813‑TF21 ska kunna hittas genom att Org‑admin skriver in exakt 120813TF21, 120813‑TF21 eller motsvarande formatvariation.

Namn

• Fritextsökning på förnamn, efternamn eller kombinationen ”förnamn efternamn”.
• Minsta antal tecken för att starta sökning ska kunna begränsas (t.ex. minst 2–3 tecken) för att undvika alltför breda urval.
• Sökningen ska vara:
  • oberoende av skiftläge (versaler/gemener),
  • tolerant för enklare stavningsvariationer (t.ex. ”Ann” → ”Anna”), där detta kan stödjas utan orimlig prestandapåverkan.
• Det ska vara möjligt att:
  • söka enbart på förnamn,
  • enbart på efternamn,
  • eller hela namnet i en sträng (”Anna Andersson”).

Vid flera personer med samma namn ska övriga kolumner (personnummer/ID, skola, roll) användas för att särskilja dem i resultatlistan.

Skola/enhet

• Filtrering på en eller flera skolor/enheter inom den aktuella organisationen (förskolor, grundskolor, gymnasier, vuxenutbildningsenheter m.m.).
• Endast enheter som tillhör org‑admins egen organisation ska kunna väljas i filtret.
• Kan användas:
  • fristående (t.ex. ”visa alla användare på Gymnasieskola A”), eller
  • i kombination med andra parametrar (t.ex. ”förnamn = Anna” + ”skola = Gymnasieskola A”).

Klass/grupp/avdelning

• Filtrering på undervisningsgrupp, klass, avdelning eller motsvarande grupptillhörighet för elev/barn.
• Kan kombineras med skola/enhet (t.ex. ”7A på Skola X”) och/eller med namn/personnummer.
• Flera grupper kan väljas samtidigt där detta är relevant (t.ex. för att söka alla elever i parallellklasserna 7A och 7B).

Exempel:
En Org‑admin vill hitta alla elever i klass 9C på en specifik högstadieskola för att stämma av dubbletter. Hen filtrerar på ”Skola = Högstadieskola Y” och ”Klass = 9C”.

Roll

• Filtrering på användarroll:
  • elev/barn,
  • personal,
  • vårdnadshavare.
• Det ska vara möjligt att:
  • välja en enskild roll (t.ex. endast vårdnadshavare),
  • kombinera flera roller (t.ex. personal + vårdnadshavare, för att hitta personer med flera roller på samma konto).

Exempel:
För att hitta personal som också är vårdnadshavare i samma kommun kan Org‑admin filtrera på ”Roll = Personal” OCH ”Roll = Vårdnadshavare”.

Status i den utökade användarhanteringen

• Filtrering på kontots status i relation till den utökade användarhanteringen, t.ex.:
  • Aktivt konto (ingen särskild åtgärdsstatus),
  • Markerat för radering (i karens),
  • Raderat (endast i särskilda historikvyer där så stöds),
  • Spärrat från inläsning (helt konto) – finns på spärrlista,
  • Har spärrade relationer (t.ex. spärrad vårdnadshavare–barn‑relation).
• Syftet med filtret är att snabbt ge Org‑admin överblick över:
  • vilka konton som är under pågående raderingsprocess,
  • vilka konton som inte längre ska återkomma via synkronisering,
  • vilka vårdnadshavare som har särskilt spärrade relationer till ett barn.

Exempel:
En Org‑admin vill se alla användare som för närvarande är markerade för radering. Hen filtrerar på ”Status = Markerad för radering” och kan därifrån bedöma om vissa radering ska ångras eller kompletteras med spärr.

---

Särskild sökning för vårdnadshavare via barn

För åtgärder som avser relationen mellan vårdnadshavare och ett specifikt barn (t.ex. spärr av en digital åtkomst till ett barn, men inte till syskon) ska det finnas ett särskilt sökflöde som utgår från barnet.

Flödet ska stödja:

1. Val av barn/elev
   Org‑admin söker först fram barnet via:

   • barnets personnummer/ID,
   • barnets namn,
   • eventuellt kombinerat med barnets skola/enhet och/eller klass.

2. Visning av kopplade vårdnadshavare
   När barnet valts ska systemet:

   • visa en lista över samtliga vårdnadshavarkonton som är kopplade till barnet i Vklass,
   • oavsett om vårdnadshavarnas namn, personnummer eller andra uppgifter angivits i sökningen.

3. Urval av vårdnadshavare för åtgärd
   Från denna lista ska Org‑admin kunna:

   • välja en eller flera vårdnadshavare för vidare åtgärd, t.ex.:
     • spärra eller ändra relationen vårdnadshavare–barn,
     • spärra hela vårdnadshavarkontot,
     • markera deras konto för radering (om detta är lämpligt enligt gallringsregler),
   • navigera vidare till vårdnadshavarens fullständiga kontodetaljer vid behov.

Exempel:
Kommunen har ett beslut om att vårdnadshavare A inte ska ha digital åtkomst till barn B, men fortsatt till syskonet C. Org‑admin söker fram barn B, ser vårdnadshavare A och C i listan över kopplade vårdnadshavare, väljer A och initierar spärr av relationen A–B. Relationerna A–C och eventuella andra barn förblir opåverkade.

---

Resultatlista och urval

Sökresultatet presenteras som en tabell/lista där varje rad motsvarar ett användarkonto i Vklass. Inom ramen för Org‑admins ordinarie behörigheter ska minst följande uppgifter visas per träff:

• Namn (för- och efternamn),
• Personnummer/ID:
  • i samma detaljnivå som Org‑admin normalt ser i Vklass (t.ex. fullständigt personnummer där detta är tillåtet),
• Roll/roller på kontot:
  • elev/barn,
  • personal,
  • vårdnadshavare (ev. kombinationer),
• Skola/enhet:
  • primär/huvudsaklig enhet, eller
  • flera enheter där detta är relevant (t.ex. lärare på flera skolor),
• Klass/grupp/avdelning (för elev/barn, där denna information finns),
• Statusindikatorer kopplade till den utökade användarhanteringen:
  • markerat för radering (i karens),
  • spärrat från inläsning (helt konto),
  • har en eller flera spärrade relationer (t.ex. spärrad vårdnadshavare–barn‑koppling).

Statusindikatorer ska vara tydligt visuellt särskiljbara (t.ex. ikoner eller färgmarkeringar med kort textförklaring) så att Org‑admin snabbt ser vilka konton som:

• är under pågående raderingsprocess,
• inte längre ska återkomma via synkronisering,
• har särskilda relationsbegränsningar.

Resultatlistan ska stödja:

• Sortering:
  • minst på namn, personnummer/ID och skola/enhet,
• Paginering/avgränsning:
  • t.ex. visa första 50–100 träffar med möjlighet att bläddra,
  • visa ett tydligt meddelande om urvalet är för brett (t.ex. ”För många träffar. Förfina din sökning med fler filter”),
• Urval för åtgärd:
  • markering av en enskild rad för att öppna kontots detaljvy och initiera åtgärder som:
    • markera för radering,
    • direkt radering,
    • spärrning,
    • sammanslagning (då två konton väljs),
  • möjlighet att markera flera rader för massåtgärder där detta stöds (t.ex. markera flera manuella konton för radering eller för ändring av giltighetsdatum i framtida funktionalitet).

Vid flera personer med samma namn ska kombinationen av:

• personnummer/ID,
• skola/enhet,
• roll,

göra det möjligt att skilja dem åt. Vid sökning på exakt personnummer/ID ska systemet, där det är lämpligt, erbjuda en genväg för att gå direkt till kontots detaljvy.

Exempel:
En Org‑admin söker på efternamnet ”Eriksson” utan ytterligare filter. Systemet returnerar 150 träffar och visar ett meddelande om att urvalet är stort. Org‑admin filtrerar därefter på ”Skola = Gymnasieskola B” och ”Roll = Elev” och får då en hanterbar lista med 18 elever, där varje rad visar namn, personnummer, skola, klass och status (t.ex. markering för radering).

---

Begränsningar och avgränsning

• Sökningen får endast omfatta användarkonton inom den organisation där den inloggade Org‑admin har behörighet. Konton som tillhör andra huvudmän/organisationer får aldrig visas eller väljas.
• Sökfunktionen får inte exponera fler eller mer detaljerade personuppgifter än vad Org‑admin redan har rätt att se i andra administrationsvyer i Vklass:
  • t.ex. fullständiga personnummer endast där Org‑admin‑rollen normalt ger denna insyn,
  • roll‑ och skolinformation enligt ordinarie behörighetsmodell.
• Det ska inte finnas någon särskild söklogik som automatiskt flaggar eller tolkar:
  • skyddad identitet,
  • sekretessmarkering,
  • fingerade personuppgifter.
    TF‑nummer och andra avvikande identiteter behandlas tekniskt som vanliga ID‑värden. Bedömningar kring skyddad identitet hanteras av verksamheten, inte av sökfunktionen.
• Sökningen ska inte:
  • trigga några ändringar på de konton som visas,

Sökning av vårdnadshavare via elevkoppling

Sökning av vårdnadshavare via elevkoppling utgår alltid från ett barnkonto (elev/barn) och de vårdnadshavare–barn‑relationer som finns registrerade i Vklass. Syftet är att Org‑admin på ett säkert och effektivt sätt ska kunna identifiera och välja rätt vårdnadshavare i de situationer där utgångspunkten är ett beslut eller en åtgärd som berör ett specifikt barn, t.ex.:

• spärr av en viss vårdnadshavares digitala åtkomst till barnet,
• borttag eller spärr av relationen vårdnadshavare–barn,
• initiering av radering av ett vårdnadshavarkonto (med karenstid eller direkt radering).

Funktionen är en specialisering av den generella sökfunktionen och följer samma behörighets‑ och dataskyddsprinciper.

---

Steg 1 – Välj barn/elev

Org‑admin inleder alltid med att söka fram det barn som åtgärden avser. Sökningen använder samma parametrar som den generella sökfunktionen och kan göras via t.ex.:

• personnummer/ID (inklusive TF‑nummer och andra avvikande identiteter),
• namn (för- och/eller efternamn),
• skola/enhet,
• klass/grupp/avdelning.

När Org‑admin har valt ett barnkonto visas en sammanfattande vy med barnets grunduppgifter, t.ex.:

• namn,
• personnummer/ID,
• skola/enhet och klass/grupp,
• roll (elev/barn).

Denna vy är en ren informations‑ och navigationspunkt och innebär i sig inga förändringar av kontot eller dess relationer.

---

Steg 2 – Lista över kopplade vårdnadshavare

I anslutning till barnets grunduppgifter visas en relationslista med samtliga vårdnadshavare som i Vklass är kopplade till barnet vid söktillfället, oavsett om relationerna:

• har skapats via synkronisering från verksamhetssystem, eller
• lagts till manuellt i Vklass.

För varje vårdnadshavare i listan ska minst följande uppgifter framgå:

• namn,
• personnummer/ID (i den omfattning Org‑admin normalt har behörighet att se),
• roll (vårdnadshavare),
• primär skol-/enhetskoppling om sådan finns (t.ex. om vårdnadshavaren även är personal i organisationen),
• relevanta statusindikatorer kopplade till den utökade användarhanteringen, t.ex.:
  • om vårdnadshavarkontot är:
    • aktivt,
    • markerat för radering (i karens), eller
    • spärrat från inläsning (personbaserad spärr),
  • om just relationen till det aktuella barnet är:
    • aktiv,
    • spärrad från inläsning (relationsbaserad spärr), eller
    • föremål för pågående särskild hantering.

Statusindikatorerna ska vara konsekventa med övriga vyer (t.ex. samma ikoner/färgmarkeringar som i karenslista och spärrlista), så att Org‑admin direkt kan se om det redan finns pågående eller tidigare åtgärder kopplade till vårdnadshavaren eller relationen.

Exempel:
Ett barn har två vårdnadshavare. I relationslistan visas:

• Vårdnadshavare A – aktivt konto, relationen A–barn aktiv.
• Vårdnadshavare B – konto markerat för radering (i karens), relationen B–barn aktiv.

Org‑admin ser då omedelbart att olika åtgärdslägen redan gäller för de två vårdnadshavarna.

---

Steg 3 – Val av vårdnadshavare och vidare åtgärder

Från relationslistan kan Org‑admin välja en eller flera vårdnadshavare som utgångspunkt för vidare hantering. Urvalet kan användas som startpunkt för t.ex.:

• Kontonivååtgärder på vårdnadshavaren, såsom:

  • markera hela vårdnadshavarkontot för radering (med karenstid),
  • genomföra direkt radering (när villkoren är uppfyllda),
  • spärra inläsning för hela vårdnadshavarkontot via spärrfunktionen.

• Relationsspecifika åtgärder avseende just kopplingen till det aktuella barnet, såsom:

  • spärra relationen vårdnadshavare–barn från att skapas/återskapas via synkronisering,
  • i undantagsfall ta bort relationen i Vklass (när verksamhetens beslut kräver detta och hanteringen inte kan lösas i källsystemet).

• Översyn av vårdnadshavarkontot i sin helhet, t.ex.:

  • öppna vårdnadshavarens kontodetaljer för att se övriga roller (t.ex. om personen även är personal),
  • bedöma om radering eller spärr av hela kontot skulle påverka fler relationer än den aktuella.

Sökningen via elevkoppling är här fortfarande en ren urvals‑ och navigationsfunktion. Inga förändringar sker förrän Org‑admin uttryckligen initierar en åtgärd (t.ex. radering eller spärr) från de vidare vyer som nås efter att vårdnadshavaren valts.

---

Hantering av vårdnadshavare med flera barn

När en vårdnadshavare väljs från barnets relationslista ska systemet tydligt visa om vårdnadshavarkontot har relationer till fler barn inom organisationen. I vårdnadshavarens kontodetaljer ska därför finnas en översikt över:

• samtliga barnkonton som är kopplade till vårdnadshavaren i Vklass,
• per barn:
  • namn,
  • personnummer/ID (enligt behörighet),
  • skola/enhet och klass/grupp,
  • om relationen är aktiv eller spärrad.

Detta är särskilt viktigt inför åtgärder som kan få olika räckvidd:

• Spärra hela vårdnadshavarkontot från inläsning
  – påverkar alla vårdnadshavares barnrelationer inom organisationen; vårdnadshavaren får ingen åtkomst till något barn i Vklass.

• Spärra endast relationen till det barn som sökningen utgick ifrån
  – påverkar endast just denna vårdnadshavare–barn‑relation; övriga barnrelationer fortsätter fungera som vanligt.

Exempel:
Vårdnadshavare A har barnen B och C i kommunen. Enligt beslut ska A inte ha digital åtkomst till B, men fortsatt åtkomst till C.
Org‑admin:

1. Söker upp barn B,
2. Ser A i listan över vårdnadshavare för B,
3. Väljer A och öppnar vårdnadshavarens kontodetaljer,
4. Ser att A även är kopplad till barn C,
5. Väljer åtgärden ”Spärra relation A–B” (inte spärr av hela A:s konto).

Efter detta kan A fortsatt logga in och se uppgifter om C, men inte om B. Om synkroniseringen senare försöker återskapa relationen A–B ignoreras den eftersom relationen finns på spärrlista.

---

Begränsningar, behörighet och dataskydd

Sökning av vårdnadshavare via elevkoppling är strikt begränsad enligt Vklass ordinarie behörighets‑ och organisationslogik:

• Endast Org‑admins (och eventuella särskilt utsedda systemnära administratörer) i den aktuella organisationen kan använda funktionen.
• Endast barn och vårdnadshavare som tillhör samma organisation som Org‑admin kan sökas fram och hanteras. Relationer och konton i andra huvudmän/organisationer är tekniskt otillgängliga.
• Funktionen exponerar inte fler eller mer detaljerade personuppgifter än vad Org‑admin redan har rätt att se i andra administrationsvyer:
  • visning av personnummer följer befintliga regler (t.ex. fullständigt personnummer endast för administratörer med sådan behörighet),
  • inga särskilda markeringar görs för skyddad identitet, sekretessmarkering eller fingerade personuppgifter – TF‑nummer och andra alternativa identiteter behandlas tekniskt som vanliga ID‑värden.

Själva sök‑ och urvalsflödet:

• ändrar inte några konton eller relationer,
• skapar inga loggposter i åtgärdsloggen utöver vad som gäller för normal administration,
• skickar inga notifieringar eller meddelanden till barn, vårdnadshavare eller annan personal.

Förändringar (t.ex. radering, spärrning av konto eller relation, sammanslagning) sker först när Org‑admin aktivt initierar motsvarande åtgärd i de vidare vyer som nås efter urvalet, och loggas då enligt de generella reglerna för åtgärdsloggning och dataminimering i denna specifikation.

Spärrlista för inläsning från verksamhetssystem

Spärrlistan är en intern, organisationsbunden styrstruktur i Vklass som används för att blockera inläsning av vissa personer eller specifika relationer från verksamhetssystemen. Syftet är att Vklass – oberoende av hur källsystemen är konfigurerade eller uppdaterade – ska kunna förhindra att oönskade konton eller kopplingar:

• ny‑skapas,
• återaktiveras, eller
• återskapas efter radering,

via synkroniseringsunderlaget. Funktionen används typiskt när verksamheten fattat beslut om att tillfälligt eller permanent stoppa åtkomst i Vklass, även om personen eller relationen formellt fortfarande finns kvar i elev‑, personal‑ eller vårdnadshavarregister.

En spärrpost är alltid knuten till en specifik Vklass‑organisation och påverkar endast synkroniseringar inom den organisationen. Spärrlistan:

• ändrar aldrig data i bakomliggande verksamhetssystem,
• påverkar inte hur källsystemen hanterar personen eller relationen,
• styr enbart hur Vklass tolkar och omsätter inkommande synkroniseringsunderlag.

Funktionen är generell och kan användas för samtliga roller (elev/barn, personal, vårdnadshavare) och för både synkroniserade och manuellt skapade konton.

---

Vad som kan spärras

Spärrlistan stödjer i grundutförande två huvudtyper av spärrar:

• Kontospärr (personbaserad spärr)
• Relationsspärr (relationsbaserad spärr, initialt vårdnadshavare–barn)

Kontospärr (hel person)

En kontospärr avser en hel person/identitet, oavsett vilken eller vilka roller personen kan ha (elev/barn, personal, vårdnadshavare). När en aktiv kontospärr finns för en identitet gäller vid synkronisering att:

• inga nya användarkonton skapas i Vklass för den identiteten,
• tidigare raderade konton för identiteten inte återskapas av synkroniseringen,
• inkommande poster för den spärrade identiteten i synkroniseringsunderlaget ignoreras, dvs:
  • roller och kopplingar (elev/barn, personal, vårdnadshavare, skol‑ och klasskopplingar m.m.) som rapporteras in för identiteten leder inte till ny‑ eller återaktivering i Vklass.

Ett redan existerande konto kan, beroende på situation och verksamhetens beslut, raderas i samband med att spärren sätts eller lämnas kvar som ett inaktivt/avstängt konto. Grundprincipen för kontospärren är dock alltid densamma: ingen ny inläsning från källsystemen för den spärrade identiteten.

Exempel:
En konsult har haft ett manuellt konto i Vklass under en begränsad period. När uppdraget avslutas vill kommunen säkerställa att konsulten inte får ett nytt konto om personen senare av misstag läggs in i personalsystemet. Org‑admin raderar kontot och lägger samtidigt en kontospärr på konsultens personnummer. Om personen därefter registreras i personalsystemet kommer ingen inloggningsbar identitet att skapas i Vklass.

Relationsspärr (vårdnadshavare–barn)

En relationsspärr riktar sig mot en specifik relation mellan två konton, initialt relationen mellan ett vårdnadshavarkonto och ett visst barnkonto (vårdnadshavare–barn). När en aktiv relationsspärr finns för t.ex. vårdnadshavare A – barn B gäller vid synkronisering att:

• just den utpekade relationen A–B varken skapas eller uppdateras i Vklass, även om den fortfarande finns i folkbokföring eller elevregister,
• andra relationer för samma vårdnadshavare (t.ex. A–C, syskon) fortsätter att skapas och uppdateras som vanligt,
• andra relationer för samma barn (t.ex. andra vårdnadshavare till B) påverkas inte.

En relationsspärr blockerar alltså inte hela vårdnadshavarkontot, utan endast den specifika kopplingen till ett visst barn.

Exempel:
En vårdnadshavare A har två barn, B och C, i kommunen. Genom beslut har det fastställts att A inte ska ha digital åtkomst till B, men fortsatt till C. Org‑admin lägger då en relationsspärr på kopplingen A–B. Efter detta kan A fortsatt logga in och se uppgifter om C, men inte om B – även om relationen A–B fortfarande rapporteras in från källsystemet.

Modellen kan på sikt utökas till andra relations‑typer (t.ex. särskilda handledar‑ eller mentorrelationer), men i första versionen fokuserar funktionen på kontospärrar och relationsspärrar för vårdnadshavare–barn.

---

Hur spärrposter lagras

Varje spärr representeras av en spärrpost i Vklass datamodell. Spärrposten innehåller endast de uppgifter som krävs för att:

• identifiera vilken person eller relation spärren avser,
• tillämpa spärren vid synkronisering,
• ge Org‑admin en överskådlig vy över aktiva spärrar,
• uppfylla krav på spårbarhet och dataminimering.

Minst följande information lagras per spärrpost:

• Typ av spärr

  • kontospärr (personbaserad spärr),
  • relationsspärr (t.ex. vårdnadshavare–barn).

• Teknisk referens till berörd entitet

  • För kontospärr:
    • internt användarID (om kontot finns/har funnits i Vklass),
    • identitetsnyckel som används vid synkronisering (t.ex. personnummer/ID, TF‑nummer eller annat unikt ID).
  • För relationsspärr (vårdnadshavare–barn):
    • interna ID för vårdnadshavarkonto och barnkonto,
    • eventuellt kompletterat med de identitetsnycklar som används i synkroniseringsunderlaget.

• Begränsad identifierande information för visning (dataminimering)

  • förnamn,
  • högst de sex första siffrorna i personnumret/ID:t för respektive part (ååmmdd eller motsvarande),
  • primär eller representativ skola/enhet.

• Metadata om spärren

  • organisation (huvudman) som spärren tillhör,
  • datum och tidpunkt då spärren skapades,
  • vilket Org‑admin‑konto som skapade spärren,
  • eventuell kort intern kommentar (t.ex. ”domstolsbeslut om begränsad digital åtkomst” – utan känsliga detaljer),
  • aktuell status:
    • aktiv (spärren används vid synkronisering),
    • inaktiv (spärren är hävd, men informationen bevaras för intern spårbarhet),
  • datum och tidpunkt för eventuell avspärrning (då spärren inaktiverades).

Spärrposterna lagras endast i Vklass interna databas. De är inte synliga:

• för andra användarroller än Org‑admin (och ev. särskilt utsedda systemnära administratörer),
• i ordinarie användar‑, elev‑ eller vårdnadshavarvyer,
• via externa API:er annat än där särskilt och kontrollerat beslutas.

---

Tillämpning vid synkronisering

Vid varje synkroniseringskörning från verksamhetssystemen används spärrlistan som ett filter innan inkommande data får skapa eller uppdatera konton och relationer i Vklass. Flödet kan grovt beskrivas i följande steg:

1. Inläsning av synkroniseringsunderlag
   Vklass läser in underlag för elever/barn, personal, vårdnadshavare samt deras relationer från respektive verksamhetssystem (elevregister, personalsystem, vårdnadshavarregister m.m.).

2. Kontroll mot spärrlista per post
   För varje inkommande post i underlaget kontrollerar Vklass:

   • om identitetsnyckeln (t.ex. personnummer/ID) finns i spärrlistan som aktiv kontospärr, och/eller
   • om en motsvarande aktiv relationsspärr finns registrerad (t.ex. vårdnadshavare X – barn Y).

3. Tillämpning av kontospärr
   Om en aktiv kontospärr hittas för identiteten gäller att:

   • inga nya användarkonton skapas i Vklass för den identiteten,
   • eventuella tidigare raderade konton med samma identitet inte återskapas,
   • inkommande roller, skolkopplingar, klasskopplingar och relationer som avser identiteten ignoreras i synkroniseringslogiken.

   Ett befintligt, ej raderat konto för identiteten kan vid behov hanteras separat (t.ex. raderas eller inaktiveras manuellt). Grundkravet är att ingen ny eller uppdaterande inläsning via synkroniseringen sker för den spärrade identiteten.

4. Tillämpning av relationsspärr (vårdnadshavare–barn)
   Om en aktiv relationsspärr hittas för en specifik koppling (t.ex. vårdnadshavare A – barn B) gäller att:

   • just denna relation inte skapas, återaktiveras eller uppdateras i Vklass, även om den finns i källdata,
   • andra relationer för samma vårdnadshavare (t.ex. A–C) behandlas normalt och påverkas inte,
   • andra relationer för samma barn (andra vårdnadshavare till B) påverkas inte om de inte också är spärrade.

5. Normal behandling för icke spärrade poster
   För alla inkommande poster där ingen motsvarande spärrpost träffas:

   • tillämpas Vklass ordinarie synkroniseringslogik;
   • tidigare åtgärder som radering eller sammanslagning tas fortsatt i beaktande (t.ex. vilket konto som är huvudkonto efter sammanslagning), men spärrlistan i sig är neutral.

Spärrlistan är därmed en obligatorisk kontrollpunkt i synkroniseringsflödet: inga konton eller relationer får skapas eller återaktiveras i strid med en aktiv spärrpost.

Exempel:
En vårdnadshavare–barn‑relation A–B har spärrats i Vklass. Vid nästa nattliga synkronisering rapporteras fortfarande A–B som giltig relation i vårdnadshavarunderlaget. Vklass känner igen kombinationen (A, B) i spärrlistan och ignorerar den posten. Relation A–B återskapas inte, även om den finns i källdata.

---

Administration och livscykel för spärrar

Spärrlistan administreras uteslutande av Org‑admins (och eventuella särskilt utsedda systemnära administratörer) via ett särskilt gränssnitt i den utökade användarhanteringen. Andra roller, inklusive skoladministratörer och rektorer, har ingen direkt åtkomst till spärrlistan.

Org‑admin ska i spärrgränssnittet kunna:

• Skapa nya spärrar

  • Kontospärrar:
    • utifrån ett hittat konto i den generella användarsökningen (elev/barn, personal, vårdnadshavare),
    • i samband med radering av ett konto (t.ex. ”Radera konto och spärra inläsning framåt”).
  • Relationsspärrar (vårdnadshavare–barn):
    • utifrån specialvyn ”sök vårdnadshavare via elevkoppling” (barn → lista över vårdnadshavare),
    • i samband med åtgärder på en specifik relation (t.ex. borttag av vårdnadshavare–barn‑relation i Vklass).

• Se och överblicka befintliga spärrar

  • lista samtliga aktiva spärrar inom organisationen,
  • se typ av spärr (konto/relation),
  • se begränsad identifierande information (förnamn, sex första siffror i personnummer/ID, skola/enhet),
  • se när och av vem spärren skapades,
  • se om spärren är aktiv eller inaktiv.

• Söka och filtrera i spärrlistan

  • söka på personnummer/ID, förnamn/efternamn,
  • filtrera på typ av spärr (konto/relation),
  • filtrera på skola/enhet, spärrstatus (aktiv/inaktiv) och skapandedatum.

• Ändra och häva spärrar

  • öppna en spärrpost för att se detaljer (utan att exponera mer data än nödvändigt),
  • inaktivera (häva) en spärr när verksamheten beslutat att spärren inte längre ska gälla,
  • vid behov komplettera eller uppdatera kommentar/orsak

Tillfällig avstängning av vårdnadshavare

En tillfällig avstängning av en vårdnadshavare i Vklass är en teknisk åtkomstbegränsning som tillämpas i Vklass, utan att ändra folkbokföring eller uppgifter i bakomliggande verksamhetssystem (elev‑/vårdnadshavarregister). Åtgärden används när verksamheten, med stöd av t.ex. socialtjänst- eller domstolsbeslut, har fastställt att en vårdnadshavare inte ska ha digital åtkomst i Vklass – helt eller för ett visst barn – under en viss period, även om vårdnadshavarrelationen formellt kvarstår i källsystemet.

Funktionen baseras tekniskt på spärrlistan i Vklass och kan kombineras med radering av kontot/relationen för att även gallra befintlig data. Själva besluten om avstängning fattas utanför Vklass; systemet erbjuder enbart verktyg för att verkställa och upprätthålla dessa beslut.

Övergripande arbetssätt

1. Identifiera berörd vårdnadshavare via barnet/barnen
   Org‑admin utgår alltid från det barn som avstängningen avser:

   • Sök fram barnet via den generella sökfunktionen (personnummer/ID, namn, skola/enhet, klass/grupp).
   • Öppna barnets profil och visa listan över kopplade vårdnadshavare (”Sök vårdnadshavare via elevkoppling”).
   • Välj den eller de vårdnadshavare som omfattas av beslutet.

2. Välj avstängningens omfattning
   Baserat på beslutet från verksamheten avgör Org‑admin om:

   • hela vårdnadshavarkontot ska stängas av (ingen åtkomst till något barn i Vklass), eller
   • endast relationen till ett specifikt barn ska stängas (åtkomst till övriga barn i Vklass ska finnas kvar).

3. Genomför lämplig spärråtgärd
   Org‑admin använder spärrlistan för att:

   • lägga en kontospärr (hel vårdnadshavare), och/eller
   • lägga en relationsspärr (vårdnadshavare–barn‑relation),
     eventuellt i kombination med radering av kontot eller relationen.

Scenario 1: Tillfällig avstängning av hela vårdnadshavarkontot

Detta scenario används när vårdnadshavaren inte ska ha åtkomst till något av sina barn i Vklass, eller inte ska kunna använda Vklass överhuvudtaget under en period.

Tekniskt flöde:

1. Org‑admin identifierar vårdnadshavaren via barnet (eller via den generella användarsökningen).
2. Org‑admin bedömer, i enlighet med verksamhetens beslut, om:
   • endast åtkomst ska stoppas (kontot lämnas kvar men spärras från inläsning), eller
   • både åtkomst ska stoppas och befintlig data på kontot ska gallras (kontot raderas).
3. Org‑admin kan därefter:
   • lägga upp en kontospärr för vårdnadshavarens identitet i spärrlistan, och vid behov
   • markera kontot för radering (med karenstid eller, om villkoren är uppfyllda, via direkt radering).

Effekt av kontospärren:

• Vid kommande synkroniseringar:
  • inkommande poster för den spärrade identiteten (oavsett roll/rollkombination) ignoreras av Vklass,
  • inget nytt vårdnadshavarkonto skapas, och inget tidigare raderat konto återskapas,
  • eventuella ändringar i källsystemet (t.ex. fortsatt vårdnadshavarrelation, skolbyten) slår inte igenom i Vklass så länge spärren är aktiv.
• Om kontot lämnas kvar (ej raderat) kan organisationen, enligt egna rutiner, välja att:
  • inaktivera eller byta inloggningsmetod,
  • informera berörda parter om att digital åtkomst är avstängd.

Exempel:
En vårdnadshavare A har tre barn i kommunen. Beslut har fattats om att A inte ska ha digital åtkomst till någon information i Vklass under en utredningsperiod. Org‑admin:

1. Sök upp ett av barnen och identifiera vårdnadshavare A.
2. Öppnar A:s konto och lägger en kontospärr för A:s personnummer.
3. Markera vid behov kontot för radering med karenstid, om man också vill gallra befintlig data i Vklass.

Efter detta kan A inte längre logga in i Vklass. Vid kommande synkroniseringar (där A fortsatt är registrerad som vårdnadshavare i källsystemet) skapas eller uppdateras inget konto i Vklass så länge spärren är aktiv.

Scenario 2: Tillfällig avstängning av relationen till ett specifikt barn

Detta scenario används när en vårdnadshavare enbart ska förlora åtkomst till ett visst barn, men fortsatt ska ha åtkomst till andra barn eller funktioner i Vklass.

Tekniskt flöde:

1. Org‑admin söker fram det barn som avstängningen avser.
2. I barnets relationslista identifieras aktuell vårdnadshavare.
3. Org‑admin kan därefter:
   • ta bort vårdnadshavare–barn‑relationen i Vklass (så att vårdnadshavaren omedelbart slutar se barnet i sina vyer), och
   • samtidigt lägga upp en relationsspärr för kopplingen vårdnadshavare A – barn B i spärrlistan.

Effekt av relationsspärren:

• Vklass kommer, vid varje synkronisering, att:
  • känna igen kombinationen (vårdnadshavare A, barn B) i spärrlistan, och
  • ignorera alla försök från synkroniseringsunderlaget att:
    • skapa,
    • återaktivera, eller
    • uppdatera relationen A–B.
• Övriga relationer för vårdnadshavaren, t.ex. A–C (syskon), fortsätter fungera normalt.
• Vårdnadshavaren kan således:
  • logga in i Vklass,
  • se och agera för de barn som inte omfattas av spärren,
  • men har ingen åtkomst till information om barnet B.

Exempel:
Vårdnadshavare A har barnen B och C. Domstol har beslutat att A inte ska ha digital åtkomst till barnet B, men beslutet påverkar inte relationen till C. Org‑admin:

1. Sök upp barnet B.
2. Visar listan över kopplade vårdnadshavare och väljer A.
3. Tar bort relationen A–B i Vklass.
4. Lägger upp en relationsspärr för A–B i spärrlistan.

Efter detta kan A fortfarande logga in i Vklass och se information om C, men kommer inte att se B i sina vyer. Om källsystemet även fortsättningsvis rapporterar relationen A–B kommer Vklass att ignorera den så länge spärren är aktiv.

Upphävande av tillfällig avstängning

Tillfällig avstängning är ”tillfällig” i den meningen att den styras helt av spärrlistan i Vklass och kan hävas av Org‑admin när verksamheten beslutat att åtkomsten ska återupprättas. Själva folkbokförings- och vårdnadshavaruppgifterna i källsystemen förändras aldrig av åtgärden.

När beslutet om avstängning upphör ska Org‑admin:

• För kontospärr:

  • öppna spärrlistan och inaktivera spärrposten för vårdnadshavarens personnummer/ID.
  • Vid nästa synkronisering:
    • skapas eller uppdateras åter ett vårdnadshavarkonto i Vklass baserat på källdata,
    • om kontot tidigare raderats i samband med avstängningen skapas ett nytt konto enligt ordinarie synkroniseringslogik.

• För relationsspärr (vårdnadshavare–barn):

  • öppna spärrlistan och inaktivera spärrposten för relationen vårdnadshavare A – barn B.
  • Vid nästa synkronisering:
    • återskapas/uppdateras relationen A–B enligt vad som rapporteras från källsystemet,
    • barnet B visas åter i vårdnadshavarens vyer i Vklass.

Det är verksamhetens ansvar att, vid behov, samordna upphävandet av spärr i Vklass med uppdateringar i källsystemen (t.ex. om vårdnadshavarrelationer ska ändras eller avslutas permanent i elevregistret).

Kombination med raderingsflöden och dataskydd

Tillfällig avstängning kan kombineras med raderingsfunktionerna i den utökade användarhanteringen:

• Radering med karenstid eller direkt radering kan användas för att gallra hela vårdnadshavarkontot ur Vklass i samband med en avstängning, t.ex. när:
  • kontot innehåller data som enligt gallringsplan ska tas bort, eller
  • det är verksamhetsmässigt lämpligt att rensa kontots historik.

I dessa fall är det viktigt att:

• kontospärren finns kvar eller läggs upp i direkt anslutning till raderingen, så att:
  • kontot inte återskapas vid nästa synkronisering så länge avstängningen ska gälla,
  • upphävande av avstängningen sker genom att spärren inaktiveras (varpå ett nytt konto kan skapas från källdata).

Oavsett kombination gäller att:

• inga ändringar görs i folkbokföring eller elev‑/vårdnadshavarregister,
• det är alltid spärrposten i Vklass som styr om kontot eller relationen kan återskapas av synkroniseringen,
• alla centrala åtgärder – borttag av konto/relation, skapande och hävning av spärrar samt genomförd radering – loggas i åtgärdsloggen:
  • med dataminimerad identifiering (t.ex. sex första siffror av personnummer, förnamn, enhet),
  • och lagras endast under den tidsbegränsade period som gäller för åtgärdsloggar (t.ex. 30 dagar), varefter loggarna gallras automatiskt.

På detta sätt kan kommunen verkställa och upprätthålla tillfälliga beslut om begränsad digital åtkomst i Vklass, utan att manipulera juridiskt grundade uppgifter i källsystemen och utan risk att automatiska synkroniseringar återskapar åtkomster som inte längre ska gälla.

Spärr av specifik relation vårdnadshavare–barn

En spärr av en specifik relation vårdnadshavare–barn är en riktad åtgärd som endast avser kopplingen mellan en viss vårdnadshavare och ett visst barn. Spärren påverkar inte vårdnadshavarens övriga relationer till andra barn i organisationen och inte heller eventuella andra roller som personen kan ha i Vklass (t.ex. personal). Vårdnadshavarkontot kan därför fortsätta användas normalt i alla andra avseenden, medan just det spärrade barnet inte längre blir synligt eller åtkomligt för vårdnadshavaren i Vklass.

Initiering och skapande av relationsspärr

Org‑admin initierar alltid en relationsspärr vårdnadshavare–barn genom att utgå från barnet. Flödet bygger på funktionen för ”Sökning av vårdnadshavare via elevkoppling” och ser typiskt ut så här:

1. Org‑admin söker fram barnet (elev/barn‑konto) via den generella sökfunktionen, t.ex. med:
   • personnummer/ID (inkl. TF‑nummer),
   • namn,
   • skola/enhet och/eller klass/grupp.
2. Org‑admin öppnar barnets detaljvy där samtliga kopplade vårdnadshavare listas.
3. Org‑admin identifierar rätt vårdnadshavare i listan (namn, personnummer/ID, ev. statusindikatorer) och väljer den aktuella relationen vårdnadshavare–barn.
4. Org‑admin väljer åtgärden Spärra relation vårdnadshavare–barn (eller motsvarande beteckning) för just denna koppling.

När åtgärden bekräftas skapas en relationsspärr i spärrlistan. Spärrposten innehåller endast den information som krävs för att kunna tillämpa spärren tekniskt och ge Org‑admin nödvändig översikt, t.ex.:

• teknisk referens till vårdnadshavarkontot:
  • internt användar‑ID i Vklass (om kontot finns/har funnits),
  • identitetsnyckel som används i synkroniseringen (t.ex. personnummer/ID eller TF‑nummer),
• teknisk referens till barnkontot (internt användar‑ID och/eller motsvarande identitetsnyckel),
• spärrtyp: relationsspärr vårdnadshavare–barn,
• begränsad identifierande information för visning i spärrgränssnittet, t.ex.:
  • vårdnadshavarens förnamn,
  • högst de sex första siffrorna i vårdnadshavarens personnummer/ID (ååmmdd),
  • barnets förnamn och skola/enhet,
• metadata:
  • datum och tidpunkt då spärren skapades,
  • vilket Org‑admin‑konto som skapade spärren,
  • status (aktiv/inaktiv),
  • eventuell kort intern kommentar (endast administrativ, utan känsliga detaljer om beslutets innehåll).

Själva beslutet (t.ex. domstols‑ eller socialtjänstbeslut) registreras inte i Vklass; systemet lagrar enbart nödvändig teknisk information för att kunna verkställa beslutet.

Tillämpning i synkroniseringen

Från och med att relationsspärren är aktiv utgör den en bindande instruktion till synkroniseringslogiken. Vid varje synkroniseringskörning kontrollerar Vklass inkommande vårdnadshavare–barn‑relationer mot spärrlistan:

• Om synkroniseringsunderlaget innehåller en relation mellan den spärrade vårdnadshavaren och det spärrade barnet ska just denna relation ignoreras av Vklass:
  • Vklass ska inte skapa relationen om den saknas i Vklass,
  • Vklass ska inte återaktivera relationen om den tidigare tagits bort i Vklass,
  • Vklass ska inte uppdatera relationen om den av tekniska skäl fortfarande finns kvar – i ett sådant läge ska relationen vid behov tas bort eller hållas bortkopplad enligt den definierade spärrlogiken.
• Övriga relationer för samma vårdnadshavare (t.ex. till syskon eller andra barn) behandlas enligt ordinarie synkroniseringsregler, under förutsättning att dessa relationer inte också är spärrade.
• Övriga relationer för samma barn (andra vårdnadshavare till barnet) påverkas inte av spärren, om inte separata relationsspärrar finns för dessa kopplingar.

Spärren förändrar aldrig källdata i verksamhetssystemen; den styr enbart hur Vklass får använda de relationer som rapporteras in.

Exempel:
Vårdnadshavare A har barnen B och C i kommunen. Enligt beslut ska A inte ha digital åtkomst till B, men fortsatt åtkomst till C. Org‑admin spärrrar relationen A–B. Vid nästa synkronisering rapporterar elevregistret fortfarande A som vårdnadshavare till både B och C. Vklass känner igen A–B i spärrlistan och ignorerar den relationen, men uppdaterar fortsatt relationen A–C som vanligt.

Effekt i användargränssnittet

När en relationsspärr vårdnadshavare–barn är aktiv ska effekten i Vklass gränssnitt vara tydlig och konsekvent:

• För vårdnadshavaren:
  • det spärrade barnet visas inte längre i barnlistor, startsida eller andra navigationsvyer,
  • vårdnadshavaren kan inte välja barnet i meddelandefunktioner, frånvarorapportering, samtyckesflöden eller andra barnspecifika vyer,
  • eventuella historiska vyer där barnets information normalt hade varit åtkomlig via vårdnadshavarkontot ska inte visa barnet.
• För barnet:
  • den spärrade vårdnadshavaren visas inte längre som kontakt/vårdnadshavare i elevvyer, kontaktlistor eller motsvarande vyer för personal,
  • andra vårdnadshavare till barnet visas oförändrat, så länge deras relationer inte är spärrade.

Exempel:
Efter att relationen A–B spärrats:

• Vårdnadshavare A ser endast barn C när hen loggar in i Vklass.
• Personalen på B:s skola ser inte längre A som vårdnadshavare i kontaktlistor i Vklass (oavsett att folkbokföringsregistret fortfarande anger A som vårdnadshavare).

Vanligt arbetssätt – kombinera borttag av relation och spärr

Ett vanligt och rekommenderat arbetssätt vid tillämpning av spärr är att kombinera:

1. Omedelbart borttag av relationen i Vklass, och
2. Registrering av en relationsspärr för att förhindra att synkroniseringen återskapar relationen.

Flödet kan beskrivas så här:

1. Org‑admin söker fram barnet och öppnar listan över kopplade vårdnadshavare.
2. Org‑admin tar bort relationen vårdnadshavare–barn (t.ex. A–B) i Vklass, så att åtkomsten upphör omedelbart.
3. Org‑admin skapar direkt därefter en relationsspärr för samma vårdnadshavare–barn‑par i spärrlistan.

Efter dessa steg:

• är relationen borta i Vklass (barnet syns inte längre för vårdnadshavaren),
• och synkroniseringsmotorn kan inte återskapa relationen A–B så länge spärren är aktiv, även om källdata oförändrat anger A som vårdnadshavare till B.

Hävning av relationsspärr (tidsbegränsade beslut)

Om verksamhetens beslut är tidsbegränsat, eller om förutsättningarna ändras, kan samma relationsspärr senare hävas av Org‑admin. Detta görs genom att:

1. Öppna spärrlistan och söka fram den aktuella spärrposten, t.ex. via:
   • vårdnadshavarens personnummer/ID eller förnamn,
   • barnets namn/skola,
   • spärrtyp = ”relationsspärr vårdnadshavare–barn”.
2. Öppna spärrpostens detaljer och ändra status från aktiv till inaktiv (eller motsvarande åtgärd för att häva spärren).
3. Spara ändringen.

När spärren har hävts:

• kommer nästa synkroniseringskörning åter att kunna:
  • skapa relationen vårdnadshavare–barn på nytt i Vklass, eller
  • uppdatera befintlig relation,
    i enlighet med vad som rapporteras från källsystemet,
• om relationen fortfarande finns kvar i verksamhetssystemet (d.v.s. vårdnadshavaren är fortsatt registrerad som vårdnadshavare till barnet) kommer kopplingen att dyka upp på nytt i Vklass utan att ytterligare manuella åtgärder krävs i Vklass.

Det är verksamhetens ansvar att säkerställa att hävningen av spärren tidsmässigt harmoniserar med de beslut som ligger till grund för begränsningen av åtkomst.

Loggning och dataminimering

All hantering av relationsspärrar vårdnadshavare–barn loggas i Vklass åtgärdslogg för den utökade användarhanteringen. Minst följande händelser loggas:

• skapande av en ny relationsspärr,
• ändring av en befintlig spärr (t.ex. uppdaterad kommentar),
• hävning/inaktivering av en spärr.

Varje loggpost innehåller:

• tidpunkt för åtgärden (datum och klockslag),
• åtgärdstyp (t.ex. ”Relationsspärr vårdnadshavare–barn skapad”, ”Relationsspärr vårdnadshavare–barn hävd”),
• identifiering av ansvarig Org‑admin (internt ID och visningsnamn),
• en dataminimerad identifiering av de berörda kontona, t.ex.:
  • högst de sex första siffrorna i vårdnadshavarens personnummer/ID (ååmmdd),
  • vårdnadshavarens förnamn,
  • barnets förnamn och skola/enhet.

De fyra sista siffrorna i personnummer/ID och andra detaljerade personuppgifter lagras inte i läsbar form i loggen efter genomförd åtgärd. Åtgärdsloggarna lagras endast under den begränsade tidsperiod som gäller för funktionen (t.ex. 30 dagar) och gallras därefter automatiskt. Själva spärrposten i spärrlistan finns kvar så länge spärren är aktiv och tas först bort eller inaktiveras när Org‑admin uttryckligen häver spärren.

Genom relationsspärren vårdnadshavare–barn kan organisationen därmed verkställa finmaskiga beslut om digital åtkomst på barnnivå, utan att:

• behöva stänga ned hela vårdnadshavarkontot i Vklass, eller
• ändra vårdnadshavar‑ eller folkbokföringsuppgifter i bakomliggande verksamhetssystem.

Spärr av elev- eller personalkonto

Spärr av elev‑ eller personalkonto innebär att Vklass instrueras att ignorera all inläsning och uppdatering för en viss identitet från verksamhetssystemen, även om personen fortsatt finns kvar som elev eller personal i källsystemet. Funktionen används när organisationen behöver:

• förhindra att ett konto ny‑skapas eller återskapas via synkronisering, och/eller
• stoppa att befintna konton i Vklass fortsätter uppdateras automatiskt från elev‑ eller personalsystemet,

utan att göra några ändringar i själva elev‑ eller personalsystemet.

En sådan spärr hanteras alltid som en kontospärr i spärrlistan och är knuten till personens identitetsnyckel (t.ex. personnummer eller annat integrations‑ID). När en kontospärr för elev eller personal är aktiv gäller vid varje synkronisering att Vklass:

• inte skapar nya användarkonton för den spärrade identiteten,
• inte återaktiverar tidigare raderade konton för identiteten,
• inte uppdaterar roller, skol‑, klass‑ eller rättighetskopplingar för den spärrade identiteten baserat på inkommande synkroniseringsdata.

Källdata i elev‑ och personalsystemen påverkas aldrig; spärren styr enbart hur Vklass får använda synkroniseringsunderlaget.

---

Typiska användningsfall

Exempel på situationer där kontospärr för elev eller personal är lämplig:

• En elev eller anställd ska av verksamhetsskäl inte ha något konto i Vklass, men finns kvar i elev‑ eller personalsystemet av administrativa skäl (t.ex. under en övergångsperiod eller i väntan på beslut).
• Ett konto har raderats i Vklass enligt gallringsbeslut, men personen finns fortfarande i elevregistret; organisationen vill förhindra att ett nytt konto skapas automatiskt.
• En person har felaktigt registrerats i elev‑ eller personalsystemet (t.ex. som personal trots att personen är extern resurs) och man vill säkerställa att denna registrering inte resulterar i ett Vklass‑konto innan källdata hunnit rättas.

---

Effekt på befintliga konton i Vklass

Om det redan finns ett aktivt elev‑ eller personalkonto i Vklass när kontospärren skapas, har organisationen två huvudsakliga alternativ:

• Radera konto + spärr (permanent borttagning)

  1. Org‑admin markerar kontot för radering (med karenstid eller, när villkoren är uppfyllda, via direkt radering).
  2. I samma flöde väljer Org‑admin att kontot även ska spärras från inläsning.
  3. Systemet:
     • genomför raderingen enligt reglerna för radering (inkl. kontroll mot synkroniseringsunderlaget), och
     • skapar därefter automatiskt en kontospärr i spärrlistan kopplad till samma identitet.

  Resultat: användarkontot tas bort ur Vklass, och kommande synkroniseringar kan inte skapa ett nytt konto för samma identitet så länge spärren är aktiv.

• Enbart spärr, utan omedelbar radering

  1. Org‑admin lägger en kontospärr för elevens/personens identitet i spärrlistan.
  2. Det befintliga kontot kan därefter:
     • lämnas oförändrat,
     • eller avaktiveras/stängas med befintliga funktioner för inloggning/behörighet.

  Resultat: kontot och dess historik finns kvar i Vklass (t.ex. för arkiverings‑ eller uppföljningsändamål), men synkroniseringen kommer inte att kunna återaktivera kontot, ändra skolkopplingar, lägga till nya klasser eller uppdatera roller för den spärrade identiteten.

Exempel:
En lärare avslutas i personalsystemet först vid månadsskiftet, men kommunen har beslutat att läraren omedelbart ska förlora åtkomst till Vklass. Org‑admin:

1. Avaktiverar eller raderar lärarens Vklass‑konto, och
2. lägger samtidigt en kontospärr för lärarens personnummer.

När personalsystemet senare fortfarande rapporterar personen som anställd (fram till månadsskiftet) skapas ingen ny inloggningsbar identitet i Vklass under tiden spärren är aktiv.

---

Initiering av kontospärr för elev eller personal

Org‑admin initierar en kontospärr genom att:

1. Öppna den utökade användarhanteringen.
2. Söka fram den berörda eleven eller personalen, t.ex. via:
   • personnummer/ID (inkl. TF‑nummer),
   • namn,
   • skola/enhet,
   • klass/grupp (för elev/barn).
3. Öppna användarkontots detaljvy.
4. Välja åtgärden ”Spärra inläsning av konto” (eller motsvarande beteckning).

Innan spärren skapas ska en bekräftelsedialog tydligt beskriva:

• att personen fortsatt kan finnas kvar som elev/personal i verksamhetssystemet,
• att Vklass, från och med nu, kommer att ignorera all inläsning av data för denna identitet,
• att inga nya konton kommer skapas och inga tidigare raderade konton återskapas via synkronisering.

När åtgärden bekräftas skapar systemet en kontospärrpost i spärrlistan med:

• teknisk referens till identiteten (internt konto‑ID + identitetsnyckel),
• begränsad identifierande information för visning (t.ex. förnamn, högst sex första siffrorna i personnummer/ID, primär skola/enhet),
• metadata om när spärren skapats och av vilken Org‑admin.

---

Upphävande av spärr

När en kontospärr för elev eller personal inte längre ska gälla (t.ex. efter att ett internt beslut upphävts eller ett fel rättats i elev‑ eller personalsystemet) kan Org‑admin häva spärren via spärrlistan:

1. Sök fram spärrposten, t.ex. via personnummer/ID, namn eller skola/enhet.
2. Öppna spärrpostens detaljer.
3. Ändra status från aktiv till inaktiv (eller ta bort spärrposten enligt definierad modell).
4. Spara ändringen.

Efter att spärren hävts kommer nästa synkronisering att behandla personen enligt ordinarie logik:

• Om kontot tidigare raderats:

  • skapas ett nytt användarkonto i Vklass om personen fortfarande förekommer i elev‑ eller personalsystemet.

• Om kontot finns kvar men varit ”frikopplat” från synkronisering (d.v.s. inga automatiska uppdateringar gjorts under spärrperioden):

  • börjar kommande synkroniseringar åter att uppdatera roller, skol‑ och klasskopplingar m.m. på kontot i enlighet med underlaget från källsystemet.

---

Loggning och dataskydd

Alla centrala åtgärder kopplade till spärr av elev‑ eller personalkonton loggas i den särskilda åtgärdsloggen för den utökade användarhanteringen, bl.a.:

• skapande av en ny kontospärr,
• ändring av en befintlig spärr (t.ex. uppdaterad kommentar),
• hävning/inaktivering av en kontospärr.

Varje loggpost innehåller minst:

• tidpunkt för åtgärden,
• åtgärdstyp (t.ex. ”Kontospärr skapad”, ”Kontospärr hävd”),
• identifiering av ansvarig Org‑admin,
• en dataminimerad identifiering av den berörda personen (t.ex. högst de sex första siffrorna i personnummer/ID, förnamn och skola/enhet).

Loggposter lagras endast under den tidsbegränsade period som gäller för åtgärdsloggen (t.ex. 30 dagar) och gallras därefter automatiskt. Själva spärrposterna i spärrlistan ligger kvar så länge spärren är aktiv och tas först bort eller inaktiveras när Org‑admin uttryckligen häver spärren.

Genom kontospärr för elev‑ och personalkonton kan organisationen således styra vilka identiteter som får skapas och uppdateras i Vklass – oberoende av hur dessa personer hanteras i bakomliggande elev‑ och personalsystem – samtidigt som spårbarhet och dataminimering upprätthålls.

Hantera TF-nummer och alternativa identiteter

Konton med TF‑nummer eller andra alternativa identiteter (t.ex. tillfälliga personnummer, lokala ID:n eller manuellt skapade identiteter utan svenskt personnummer) hanteras i den utökade användarhanteringen som vanliga användarkonton utifrån ett tekniskt perspektiv. Funktionen gör ingen egen tolkning av om en sådan identitet beror på t.ex. skyddad identitet, sekretessmarkering, fingerade personuppgifter, utländsk medborgare, testkonto eller annan särskild situation. All logik utgår enbart från:

• att det finns ett unikt ID‑värde som används konsekvent i Vklass, och
• att samma ID‑värde (eller en definierad motsvarighet) används i synkroniseringsunderlaget från verksamhetssystemen.

Bedömningar och beslut kring skyddad identitet eller andra särskilda rättsliga situationer fattas utanför denna funktion, enligt huvudmannens egna rutiner och gällande regelverk (t.ex. IMY:s vägledning). Funktionen tillhandahåller endast tekniska verktyg för att verkställa dessa beslut.

---

Grundprinciper för TF‑nummer och alternativa identiteter

• TF‑nummer och andra alternativa ID‑format lagras i samma personnummer/ID‑fält som övriga identiteter och fungerar som teknisk primärnyckel i Vklass för:

  • sökning och urval i den utökade användarhanteringen,
  • koppling mot synkroniseringsunderlaget från elev‑, personal‑ och/eller vårdnadshavarregister (när dessa system använder samma ID),
  • identifiering av kontot vid radering (med karens eller direkt), sammanslagning och spärrning.

• Systemet inför ingen särskild flagga eller status som markerar att ett konto har ”speciell” eller ”skyddad” identitet:

  • ett TF‑nummer (t.ex. 120813‑TF21) behandlas tekniskt som ett giltigt ID‑värde,
  • likaså andra alternativa ID:n (t.ex. lokala elev‑ID, tillfälliga personnummer eller manuella strängar).

• Ett konto med TF‑nummer eller annat alternativt ID kan:

  • vara synkroniserat från ett verksamhetssystem,
  • vara helt manuellt skapat i Vklass, eller
  • ingå i en kombination (t.ex. manuellt TF‑konto som senare kompletteras med ett synkroniserat konto med svenskt personnummer).

---

Sökning, visning och behörighet

• Vid sökning kan Org‑admin ange TF‑nummer eller annat alternativt ID på samma sätt som ett svenskt personnummer:

  • exakta träffar på ID (oavsett format) ger direkt åtkomst till kontot,
  • fritextsökning på namn, skola/enhet, klass/grupp m.m. fungerar oberoende av om identiteten är svenskt personnummer, TF‑nummer eller annat ID.

• Sökningen är tolerant för vanliga formatvariationer, t.ex.:

  • 120813TF21, 120813‑TF21 eller motsvarande,
  • 10‑/12‑siffriga personnummer med eller utan bindestreck.

• I träfflistor och detaljvyer visas TF‑nummer/ID enligt samma behörighetsregler som för ordinarie personnummer:

  • Org‑admin kan se fullständigt ID där detta redan är tillåtet i Vklass,
  • andra roller påverkas inte; den utökade användarhanteringen förändrar inte vilka andra användare som kan se hela eller delar av ett ID.

• Funktionen tillför inte någon extra maskning eller avmaskning jämfört med befintliga regler; den återanvänder Vklass ordinarie behörighetsmodell för presentation av personuppgifter.

Exempel:
En elev registreras initialt manuellt med TF‑numret 120813‑TF21. Org‑admin kan senare söka fram eleven genom att ange 120813‑TF21, 120813TF21 eller genom att kombinera namn + skola.

---

Radering, karens och kontroll mot verksamhetssystem

• När ett konto med TF‑nummer eller annan alternativ identitet markeras för radering gäller exakt samma regler som för andra konton:

  • kontot läggs i karenslista,
  • karensstatus styrs av om identiteten förekommer i synkroniseringsunderlaget,
  • slutlig radering får endast ske när:
    • karenstiden (t.ex. 48 timmar) har förflutit utan att identiteten förekommit i någon synkronisering, och
    • den avslutande kontrollen mot verksamhetssystem/synkroniseringsunderlag bekräftar fortsatt frånvaro.

• Vid direkt radering används TF‑numret/ID‑värdet som uppslag mot synkroniseringsunderlaget på samma sätt som för andra identiteter:

  • om identiteten fortfarande finns i ett verksamhetssystem får direkt radering inte genomföras,
  • om ingen motsvarande post hittas kan direkt radering genomföras efter dubbel bekräftelse från Org‑admin.

• Funktionen gör ingen automatisk tolkning av varför en identitet har ett visst format:

  • om ett TF‑nummer i praktiken avser skyddad identitet, fingerade uppgifter eller någon annan särskild situation är det upp till verksamheten att ta hänsyn till detta i beslutet om radering, inte i den tekniska funktionen.

Exempel:
En elev med TF‑nummer har slutat och finns inte längre i kommunens elevregister. Eleven ska enligt gallringsplan tas bort ur Vklass. Org‑admin markerar kontot för radering. Systemet går igenom karensflödet, kontrollerar mot synkroniseringsunderlaget (ingen förekomst) och raderar därefter kontot på samma sätt som för ett konto med svenskt personnummer.

---

Sammanslagning vid byte av identitet (t.ex. TF‑nummer → personnummer)

När en person byter identitet i källsystemen – t.ex. från TF‑nummer/alternativt ID till svenskt personnummer, eller från ett lokalt ID till ett annat – uppstår ofta dubbla konton i Vklass:

• ett ”äldre” konto kopplat till det ursprungliga ID‑värdet (t.ex. TF‑numret, ofta manuellt skapat), och
• ett ”nytt” konto kopplat till det ID som nu används i verksamhetssystemet och kommer via synkronisering.

Denna situation hanteras med funktionen för sammanslagning av konton:

• Org‑admin söker fram båda kontona och jämför dem i jämförelsevyn (namn, ID, skolor, klasser, roller m.m.).
• Org‑admin väljer vilket konto som ska vara målkonto (i normalfallet det konto som motsvarar den identitet som verksamhetssystemet använder framåt, t.ex. svenskt personnummer) och vilket som ska vara källkonto.
• Systemet:
  • för över relevanta kopplingar och historik från källkontot till målkontot,
  • avslutar/raderar källkontot som separat inloggningsbar identitet,
  • låter målkontot vara den enda aktiva identiteten.

Om det finns risk att det gamla ID‑värdet (t.ex. ett TF‑nummer) fortfarande kan förekomma i synkroniseringsunderlaget under en övergångsperiod kan Org‑admin vid behov:

• lägga en kontospärr på det gamla ID‑värdet i spärrlistan, så att:
  • synkroniseringen inte skapar ett nytt separat konto baserat på det gamla ID:t,
• kombinera sammanslagningen med:
  • radering av det gamla kontot när det är lämpligt, och
  • uppdatering av källsystemen så att enbart den nya identiteten används framåt.

Exempel:
En elev har först kontot 120813‑TF21 (manuellt skapat) och får senare ett synkroniserat konto med 20120813‑1234. Org‑admin väljer kontot med 20120813‑1234 som målkonto, slår ihop kontona så att resultat, närvaro och inlämningar följer med, och lägger vid behov en kontospärr på 120813‑TF21 om det gamla TF‑numret riskerar att dyka upp igen i synkroniseringsunderlaget.

---

Spärrlista och tillfällig blockering

TF‑nummer och alternativa identiteter kan spärras via spärrlistan på samma sätt som andra identiteter:

• Kontospärr

  • blockerar all inläsning och uppdatering för den identiteten, oavsett om personen är elev/barn, personal eller vårdnadshavare,
  • förhindrar att nya konton skapas eller tidigare konton återskapas via synkronisering.

• Relationsspärr (vårdnadshavare–barn)

  • kan användas även när vårdnadshavaren eller barnet har TF‑nummer eller annat alternativt ID,
  • blockerar specifikt just den relationen (vårdnadshavare X – barn Y) utan att påverka andra barnrelationer eller eventuella personalroller.

Spärrlistans logik är formatagnostisk:

• matchning sker på den identitetsnyckel som används i integrationen, oavsett om ID‑värdet ser ut som ett svenskt personnummer, TF‑nummer eller annan sträng,
• ingen särskild hantering eller undantagslogik införs för TF‑nummer – de behandlas som vilket annat ID‑värde som helst.

Exempel:
En vårdnadshavare med TF‑nummer ska tillfälligt inte ha digital åtkomst till sitt barn i Vklass. Org‑admin:

1. söker fram barnet,
2. väljer vårdnadshavaren i barnets relationslista,
3. tar bort relationen vårdnadshavare–barn och lägger en relationsspärr för kombinationen (TF‑ID för vårdnadshavaren, barnets ID).

Synkroniseringen kan därefter inte återskapa relationen, även om källsystemet fortsatt anger vårdnadshavaren som vårdnadshavare.

---

Loggning och dataminimering

I åtgärdsloggarna hanteras TF‑nummer och andra alternativa ID:n enligt samma principer för dataminimering som övriga identiteter:

• Så länge kontot finns kvar i Vklass kan loggpunkter tekniskt knytas till kontots interna ID. I gränssnittet visas dock endast den information som Org‑admin enligt behörighetsmodellen normalt får se.

• När ett konto har raderats permanent får loggposter som avser detta konto högst innehålla:

  • de sex första tecknen i ID‑värdet (t.ex. 120813‑ för TF‑numret 120813‑TF21, alternativt motsvarande trunkerad form för andra ID‑format),
  • förnamn,
  • skola/enhet.

  De avslutande delarna av TF‑numret/ID:t får inte lagras eller exponeras i klartext i åtgärdsloggarna efter radering.

• Loggposter som rör åtgärder på konton med TF‑nummer eller alternativa ID:n (t.ex. radering, sammanslagning, skapande/hävning av spärr) omfattas av samma tidsbegränsade lagring som övriga åtgärdsloggar (t.ex. maximalt 30 dagar) och gallras automatiskt efter denna period.

---

Sammanfattande konsekvenser

Den utökade användarhanteringen skiljer inte tekniskt ut TF‑nummer eller alternativa identiteter som en särskild kontokategori. Alla användarkonton – oavsett om identiteten representeras av:

• svenskt personnummer,
• TF‑nummer,
• tillfälligt eller lokalt ID, eller
• annan alternativ identifierare,

omfattas av samma ramverk för:

• sökning och urval,
• radering (med karenstid eller direkt),
• kontroll mot verksamhetssystem/synkroniseringsunderlag,
• sammanslagning av dubbletter,
• spärrning av konton eller specifika relationer,
• loggning, dataminimering och gallring av åtgärder.

Eventuell särskild hantering av t.ex. skyddad identitet, sekretessmarkering eller fingerade personuppgifter sker genom verksamhetens egna beslut och riktlinjer, inte genom särskild logik i denna funktion. Org‑admin använder funktionen för att genomföra de tekniska åtgärder som följer av dessa beslut på ett konsekvent och spårbart sätt i Vklass.

Hantering av skyddad identitet och känsliga fall

Funktionen för utökad användarhantering är medvetet konstruerad som tekniskt neutral och gör ingen särskiljning mellan olika typer av identiteter. Systemet:

• har ingen egen flagga för skyddad identitet (t.ex. skyddad folkbokföring, sekretessmarkering, fingerade personuppgifter),
• drar inga slutsatser av hur ett ID ser ut (t.ex. TF‑nummer, ofullständigt personnummer, manuellt alias eller annat alternativt ID),
• tillämpar samma regelverk och flöden för sökning, radering, sammanslagning och spärrning på alla användarkonton.

Detta innebär att funktionen kan användas i ärenden som rör skyddade personuppgifter och andra särskilt känsliga fall, men utan att Vklass tekniskt ”förstår” att det är just sådana ärenden. Ansvar för:

• att identifiera vilka personer och relationer som omfattas av skydd eller särskilda beslut,
• att tolka och tillämpa lagstiftning, IMY:s vägledning och lokala styrdokument,
• att välja rätt åtgärd i Vklass (t.ex. radering, sammanslagning, kontospärr, relationsspärr),

ligger fullt ut hos organisationen och den eller de Org‑admins som är utsedda att hantera dessa frågor. Funktionen är ett verktyg för verkställighet, inte ett regelverk för när skydd ska ges.

---

Användning vid skyddad identitet – övergripande principer

Vid ärenden som rör skyddade personuppgifter eller andra särskilt känsliga situationer (t.ex. pågående vårdnadstvister, placeringar eller stödinsatser) bör funktionen användas enligt följande principer.

Dataminimering i Vklass

Om verksamheten bedömer att en person inte bör förekomma alls som konto i Vklass, eller endast under mycket begränsad tid, kan Org‑admin använda:

• Radering av konto

  • Markera kontot för radering med karenstid när personen avslutats i verksamhetssystemet, eller
  • i tydligt avgränsade undantagsfall: genomföra direkt radering efter kontroll mot synkroniseringsunderlaget.

• Kontospärr i spärrlistan

  • Lägga en kontospärr på personens identitet (personnummer, TF‑nummer eller annat ID) så att synkroniseringen inte kan:
    • ny‑skapa ett konto, eller
    • återaktivera ett raderat konto för samma identitet.

På så sätt kan organisationen minimera mängden personuppgifter i Vklass, samtidigt som elev‑, personal‑ eller vårdnadshavarregister fortsatt är masterkällor och styr hur personen hanteras i övriga system.

Exempel:
En elev med skyddad folkbokföring ska inte hanteras i några internetbaserade system. Eleven har tillfälligt skapats i Vklass under en utredning. När beslut fattas att eleven inte ska finnas kvar i Vklass raderar Org‑admin kontot (efter kontroll mot elevregistret) och lägger en kontospärr på elevens identitet. Om eleven fortfarande av administrativa skäl finns kvar i elevregistret skapas inget nytt konto i Vklass så länge spärren är aktiv.

Selektiv åtkomstbegränsning utan ändring i källsystem

I många ärenden avser beslutet inte personen som sådan, utan åtkomst till ett specifikt barn eller informationsflöde. Ett typiskt exempel är när en vårdnadshavare enligt beslut inte ska ha digital åtkomst till information om ett visst barn, men fortsatt ska ha åtkomst till syskon.

I dessa fall kan Org‑admin:

• Bryta relationen i Vklass omedelbart

  • via funktionen för ”Sök vårdnadshavare via elevkoppling” ta bort relationen vårdnadshavare–barn i Vklass, så att åtkomsten upphör direkt.

• Spärra relationen långsiktigt via spärrlista

  • lägga en relationsspärr för vårdnadshavare–barn för just den kombinationen (vårdnadshavare A – barn B),
  • vilket gör att kommande synkroniseringar kan fortsätta rapportera relationen från folkbokföring/elevregister, men Vklass ignorerar den och återskapar inte åtkomst.

Exempel:
Vårdnadshavare A har barnen B och C. Domstol beslutar att A inte ska ha digital kontakt med B, men behåller vårdnaden och åtkomsten till C.
Org‑admin:

1. söker fram B,
2. tar bort relationen A–B i Vklass,
3. lägger en relationsspärr för A–B.

Efter detta kan A fortsatt logga in och se C, men kommer inte att se B i Vklass, även om relationen A–B ligger kvar i källsystemet.

Neutral hantering av alias, TF‑nummer och manuella konton

Aliasprofiler, konton med TF‑nummer, tillfälliga ID:n eller manuellt skapade identiteter används ofta just i känsliga fall (t.ex. vid skyddad identitet, vistelse på skyddad adress, eller innan en elev fått svenskt personnummer). Funktionen behandlar alla dessa som vanliga tekniska identiteter:

• Ett alias‑ eller TF‑konto kan:
  • raderas enligt gallringsregler när det inte längre ska användas,
  • slås ihop med ett nytt, synkroniserat konto (med riktigt personnummer) när identitet läggs om,
  • spärras via kontospärr för att förhindra återaktivering, om det inte får återkomma.

Systemet sparar inte information om varför ett konto har TF‑nummer eller alias; det framgår endast ur verksamhetens egna beslut och dokumentation utanför Vklass.

Exempel:
En elev placeras i kommunen med fingerade uppgifter och får därför ett manuellt alias‑konto i Vklass under påhittat namn och TF‑nummer. När eleven senare kan registreras med korrekt identitet i elevregistret skapas ett nytt, synkroniserat konto. Org‑admin slår ihop alias‑kontot med det nya kontot (sammanslagning), ser till att historiken följer med till rätt konto, och kan därefter radera alias‑kontot och vid behov spärra TF‑identiteten så att den inte används igen.

---

Begränsning av känslig information i Vklass

För att inte öka mängden känsliga uppgifter i Vklass ska funktionen inte användas för att:

• kommentera eller registrera att en person har skyddad identitet, sekretessmarkering eller fingerade personuppgifter,
• beskriva juridiska eller sociala omständigheter i fritext (t.ex. skäl till vårdnadsbegränsning, skyddsåtgärder, placeringar).

Detta innebär bland annat att:

• Fritextkommentarer i spärrposter eller andra administrativa fält endast ska innehålla korta, neutrala beskrivningar, t.ex.:
  • ”Beslut om begränsad digital åtkomst – se intern akt/dnr enligt rutin”,
  • inte detaljerade beskrivningar av beslutets innehåll eller bakgrund.
• Åtgärdsloggen:
  • registrerar endast teknisk information om åtgärden:
    • typ av åtgärd (radering, sammanslagning, spärrning m.m.),
    • tidpunkt,
    • ansvarig Org‑admin,
    • pseudonymiserad identifiering av kontot (t.ex. sex första siffror i personnummer/ID, förnamn, skola/enhet),
  • innehåller aldrig någon markering om ”skyddad identitet” eller hänvisning till sociala/juridiska beslut,
  • gallras automatiskt efter en kort, fastställd period (t.ex. 30 dagar), så att systemet inte utvecklas till ett parallellt register över känsliga ärenden.

---

Organisatoriska rutiner och ansvarsfördelning

Eftersom Vklass inte klassar eller känner igen skyddad identitet tekniskt, behöver varje organisation ha egna styrdokument och rutiner som bl.a. beskriver:

• vilka personkategorier och situationer som ska behandlas med särskilt skydd (t.ex. enligt IMY:s vägledning om skyddade personuppgifter i skolan),
• hur beslut från t.ex. socialtjänst, domstol, polis eller andra myndigheter tas emot, granskas och dokumenteras i verksamheten (utanför Vklass),
• vilka konkreta åtgärder i Vklass som ska användas i olika beslutsfall, t.ex.:
  • ”radera + spärra konto” (ingen förekomst i Vklass),
  • ”spärra en specifik vårdnadshavare–barn‑relation”,
  • ”slå ihop alias‑konto med ordinarie konto vid ändrad identitet”,
• vem eller vilka som:
  • får initiera radering, sammanslagning och spärrning i känsliga ärenden,
  • ansvarar för samverkan med systemförvaltare för elev‑/personalsystem, dataskyddsombud och arkivfunktion,
  • säkerställer att uppgifter i källsystem och Vklass hänger ihop över tid, t.ex. när skydd upphör eller ändrar omfattning.

---

Samlad bedömning

Funktionen för utökad användarhantering stödjer hantering av skyddade och andra känsliga fall genom att tillhandahålla:

• generella, roll‑oberoende mekanismer för radering, sammanslagning och spärrning av konton och relationer,
• inbyggda kontroller mot synkroniseringsunderlaget som minskar risken att felaktigt radera personer som fortfarande är aktiva i källsystemen,
• medvetet begränsad loggning och kort logglagring, i linje med GDPR:s principer om dataminimering och lagringsbegränsning.

Funktionen ersätter dock inte:

• behovet av juridiska bedömningar, riskanalyser eller särskilda skyddsåtgärder enligt IMY:s vägledning,
• organisationens interna rutiner för hur skyddade personuppgifter ska hanteras, dokumenteras och kommuniceras.

I stället utgår funktionen från att sådana bedömningar redan är gjorda och erbjuder ett konsekvent, spårbart och dataskyddsanpassat sätt att verkställa besluten i Vklass – utan att särskilt märka ut eller exponera vilka personer som har skyddad identitet eller befinner sig i känsliga situationer.

Presentation av personuppgifter i gränssnittet

Presentation av personuppgifter i den utökade användarhanteringen utgår från två övergripande principer:

• Tillräcklig identifiering: Org‑admin ska få så mycket information att rätt person och rätt relationer kan identifieras med hög säkerhet och att åtgärden kan genomföras korrekt.
• Dataminimering och konsekvens: Ingen vy i funktionen får visa fler eller mer detaljerade personuppgifter än vad org‑admin redan har tillgång till i övriga administrationsvyer i Vklass, och ingen information utöver vad som är nödvändigt för den aktuella åtgärden.

Alla vyer återanvänder befintliga uppgifter ur Vklass användarprofil och lägger inte till nya personuppgiftskategorier (t.ex. elevhälsodata, beslutstexter, skyddsklassningar). Nedan beskrivs vilka personuppgifter som exponeras i respektive vy, och med vilken detaljeringsgrad.

---

1. Sökning och träfflista (”Hitta användare”)

Sökkriterierna (personnummer/ID, namn, skola, klass, roll m.m.) styr endast urvalet; själva träfflistan visar en begränsad uppsättning uppgifter per rad:

• Namn: förnamn och efternamn.
• Personnummer/ID:
  • visas i samma detaljnivå som org‑admin normalt ser i övrig administration (vanligen fullständigt personnummer eller motsvarande ID),
  • inkluderar TF‑nummer och andra alternativa identiteter i oförändrad form.
• Roll/roller: elev/barn, personal och/eller vårdnadshavare per konto (alla roller på kontot visas översiktligt).
• Primär skola/enhet:
  • om kontot har flera enheter visas en primär eller representativ enhet (t.ex. den senast aktiva skolan).
• Primär klass/grupp för elev/barn:
  • endast en klass/grupp visas i listan (t.ex. ”9C”), detaljerade gruppkopplingar finns i detaljvyn.
• Statusindikatorer kopplade till denna funktion: utan extra personuppgifter, t.ex.:
  • ”Markerad för radering” (konto ligger i karens),
  • ”Spärrad från inläsning” (kontospärr aktiv),
  • ”Har spärrad vårdnadshavare–barn‑relation”.

I träfflistan visas inte:

• kontaktuppgifter (e‑post, telefon),
• adressuppgifter,
• känsliga eller verksamhetsnära uppgifter (t.ex. elevhälsodata, särskilda stödformer, åtgärdsprogram),
• fritextanteckningar eller beslutstexter.

Dessa finns endast i den ordinarie användarprofilen respektive verksamhetsmoduler och exponeras inte i söklistan för den utökade användarhanteringen.

Exempel:
En sökning på ”Anna” + ”Gymnasieskola A” ger träffar som visas ungefär som:

Anna Andersson – 20120813‑1234 – Elev – Gymnasieskola A – Klass: TE21B – Status: Markerad för radering

---

2. Detaljvy för valt konto

Detaljvyn används när org‑admin ska fatta beslut om t.ex. radering, sammanslagning eller spärrning. Här visas en mer komplett men fortfarande begränsad bild av kontots identitet och kopplingar.

Grundidentitet

• Förnamn och efternamn.
• Fullständigt personnummer/ID exakt som registrerat i Vklass (inkl. TF‑nummer eller annat alternativt ID).
• Eventuellt internt tekniskt ID (t.ex. intern kontonyckel) kan visas i en teknisk sektion, men är inte avsett som personuppgift för verksamhetsbruk.

Roller och organisatoriska kopplingar

• Samtliga roller på kontot:
  • elev/barn,
  • personal,
  • vårdnadshavare.
• Skol‑/enhetskopplingar:
  • lista över alla skolor/enheter inom organisationen där kontot förekommer eller har förekommit (i den mån detta redan visas för org‑admin i befintligt admin‑gränssnitt).
• Klass-/grupp‑/avdelningskopplingar (för elev/barn):
  • aktuella klasser,
  • relevanta undervisningsgrupper,
  • avdelningar/fritidshem.
• För vårdnadshavare: lista över kopplade barn med:
  • barnets namn,
  • barnets skola/enhet,
  • barnets klass/grupp,
  • barnets personnummer/ID endast i den omfattning org‑admin normalt har behörighet att se detta i andra vyer.

Detaljvyn visar inte innehållet i själva historiken (t.ex. enskilda bedömningar, meddelandetexter, elevhälsoanteckningar), utan endast att sådan data finns kopplad till kontot på en övergripande nivå när det är relevant för åtgärden (t.ex. ”Kontot har närvarodata”, ”Kontot har inlämningar”).

Kontaktuppgifter (endast vid behov)

• E‑postadress och telefonnummer kan visas i detaljvyn om:
  • dessa uppgifter redan ingår i org‑admins ordinarie behörighet, och
  • de är relevanta för åtgärden (t.ex. för att kunna verifiera att rätt konto valts vid dubblettutredning).
• Funktionen introducerar inte nya kontaktfält; den återanvänder befintliga fält från användarprofilen och exponerar dem inte om de inte behövs.

Status i den utökade användarhanteringen

• Översiktlig status för kontot, t.ex.:
  • aktivt konto (ingen pågående åtgärd),
  • markerat för radering (med hänvisning till starttid för karens),
  • spärrat från inläsning (kontospärr aktiv),
  • inblandat i spärrade relationer (t.ex. spärrad vårdnadshavare–barn‑relation),
  • utvalt som målkonto eller källkonto i en pågående sammanslagningsoperation (framgår endast för org‑admin under arbetet).

I detaljvyn visas aldrig information om skäl till åtgärden (t.ex. typ av myndighetsbeslut, sociala eller juridiska bedömningar). Sådan information får inte registreras i fritextfält eller kommentarer inom funktionen.

---

3. Jämförelsevy vid sammanslagning av konton

Jämförelsevyn används för att stödja org‑admin i bedömningen att två konton verkligen avser samma fysiska person innan sammanslagning genomförs. För respektive konto (A och B) visas sida vid sida:

• Förnamn och efternamn.
• Personnummer/ID:
  • fullständigt, i enlighet med org‑admins ordinarie behörighet,
  • inklusive TF‑nummer eller andra alternativa ID.
• Roller:
  • elev/barn, personal, vårdnadshavare (alla roller per konto).
• Skol‑/enhetskopplingar:
  • lista över skolor/enheter där kontot är eller har varit aktivt.
• Klass-/gruppkopplingar (för elev/barn):
  • översiktlig lista över aktuella klasser och huvudsakliga undervisningsgrupper.
• För vårdnadshavare:
  • kopplade barn (barnets namn, skola/enhet och klass/grupp).
• Kontotyp/ursprung:
  • t.ex. ”Synkroniserat konto (elevregister X)”,
  • ”Synkroniserat konto (personalsystem Y)”,
  • ”Manuellt skapat konto i Vklass”.

Eventuella avvikelser mellan kontona (t.ex. olika efternamn, olika personnummer/ID, olika skolkopplingar) markeras visuellt (t.ex. med ikon eller färg), men inga ytterligare känsliga uppgifter läggs till.

Exempel:
I jämförelsevyn kan org‑admin se:

• Konto A: ”Anna Karlsson, 20120813‑1234, Elev – Gymnasieskola A, Klass TE21B, synkroniserat från elevregistret”.
• Konto B: ”Anna Karlsson, 120813‑TF21, Elev – Gymnasieskola A, Klass TE20B (historik), manuellt skapat”.

Detta underlättar bedömningen att det rör samma elev som bytt från TF‑nummer till svenskt personnummer.

Adress, kontaktuppgifter, elevhälsodata och annan känslig information visas inte i jämförelsevyn; den är strikt fokuserad på identitet, roller och organisatoriska kopplingar.

---

4. Karenslista (konton markerade för radering)

Karenslistan ger en översikt över alla konton som är markerade för radering men ännu inte raderats slutligt. Så länge kontot finns kvar visas per rad:

• Förnamn och efternamn.
• Personnummer/ID:
  • i samma detaljnivå som i övrig administration för org‑admin (vanligen fullständigt).
• Roller:
  • elev/barn, personal, vårdnadshavare.
• Skola/enhet:
  • minst en primär eller senast aktiv skola/enhet.
• För elever/barn:
  • primär klass/grupp.
• Tidpunkt då kontot markerades för radering (start av karenstid).
• Senaste kända tidpunkt då identiteten förekom i synkroniseringsunderlaget.
• Status i raderingsflödet, t.ex.:
  • ”I karens – förekommer i synkronisering”,
  • ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
  • ”Redo för radering – väntar på slutlig kontroll”,
  • ”Tillfälligt stoppad – avvaktar lyckad synkronisering”.

Från karenslistan kan org‑admin:

• öppna kontots detaljvy (med samma personuppgifter som beskrivs ovan),
• ångra raderingen (utan att fler personuppgifter exponeras i listan),
• initiera direkt radering (i särskilda fall).

I karenslistan visas inte:

• kontaktuppgifter (e‑post, telefon),
• adress,
• innehåll i kontots historik (t.ex. resultat, meddelanden, elevhälsouppgifter).

När raderingen är genomförd:

• försvinner kontot från karenslistan,
• all fortsatt spårbarhet kring åtgärden finns endast i åtgärdsloggen, där personuppgifter visas i pseudonymiserad form (se nedan).

---

5. Spärrlista (konton och relationer spärrade från inläsning)

Spärrlistan visar enbart de personuppgifter som är absolut nödvändiga för att org‑admin ska kunna förstå, söka fram och administrera spärrar. Två huvudtyper särskiljs: kontospärrar (hela konton) och relationsspärrar (vårdnadshavare–barn).

Kontospärrar (hela konton)

För varje spärrad identitet visas:

• Förnamn.
• Efternamn (kan visas för att särskilja personer, men behöver inte alltid exponeras i översiktslistan om urvalet annars är tydligt).
• De sex första siffrorna i personnummer/ID (ååmmdd eller motsvarande del av TF‑nummer/alternativt ID).
  De fyra sista siffrorna visas som utgångspunkt inte i spärrlistan, även om org‑admin kan se fullständigt personnummer i andra vyer.
• Primär skola/enhet (om sådan finns eller har funnits).
• Typ av spärr:
  • t.ex. ”Kontospärr – elev”, ”Kontospärr – personal”, ”Kontospärr – vårdnadshavare”.
• Datum och tidpunkt då spärren skapades.
• Vilken org‑admin som skapade spärren (visningsnamn).

Relationsspärrar (vårdnadshavare–barn)

För varje spärrad relation visas:

• Vårdnadshavare:
  • förnamn,
  • (ev. efternamn),
  • de sex första siffrorna i personnummer/ID (ååmmdd),
  • ev. primär skola/enhet (t.ex. om vårdnadshavaren även är personal).
• Barn:
  • förnamn och efternamn,
  • skola/enhet,
  • vid behov barns personnummer/ID i samma nivå som org‑admin normalt har behörighet att se (vanligen fullständigt nummer i administratörsgränssnittet, men endast där detta redan är tillåtet).
• Typ av spärr:
  • ”Relationsspärr vårdnadshavare–barn”.
• Datum och tidpunkt då spärren skapades.
• Vilken org‑admin som skapade spärren.

Spärrlistan visar inte:

• kontaktuppgifter,
• adressuppgifter,
• skäl till spärren (t.ex. typ av myndighetsbeslut),
• elevhälsouppgifter eller andra känsliga uppgifter.

Eventuella interna kommentarer ska vara korta och neutrala (t.ex. ”Beslut om begränsad åtkomst, se intern akt/dnr”) och får inte innehålla känsliga beskrivningar.

Exempel:
En rad i spärrlistan kan se ut ungefär som:

Typ: Relationsspärr vårdnadshavare–barn – Vårdnadshavare: 120813‑****** Anna, Personal på Skola X – Barn: Erik, åk 5, Skola Y – Skapad: 2025‑03‑10 09:13 – Av: Orgadmin Kommun X

---

6. Åtgärdslogg (radering, sammanslagning, spärrning)

Åtgärdsloggen visar de administrativa åtgärder som genomförts inom den utökade användarhanteringen (t.ex. radering, sammanslagning, skapande/hävning av spärrar). Presentationen av personuppgifter i denna logg är medvetet pseudonymiserad och följer principerna i avsnitten om loggning och dataminimering.

Per loggrad visas normalt:

• **

Datamodell och entiteter

Den utökade användarhanteringen baseras i första hand på befintliga entiteter i Vklass (t.ex. användarkonto, skol‑, grupp‑ och relationskopplingar) och kompletteras med ett fåtal nya, tydligt avgränsade entiteter för karenshantering, spärrlista och åtgärdslogg. Syftet är att:

• minimera påverkan på befintlig datamodell,
• separera ”kontots identitet och historik” från ”administrativa beslut om radering/spärr”,
• säkerställa god spårbarhet utan att lagra mer personuppgifter än nödvändigt.

Nedan beskrivs de centrala entiteterna och deras inbördes relationer.

---

Användarkonto / UserAccount

(befintlig entitet, utökas endast funktionellt – inte strukturellt)

Ett UserAccount representerar en unik, inloggningsbar identitet i Vklass för en fysisk person inom en organisation. All livscykelhantering (radering, sammanslagning, spärrning) utgår från denna entitet.

Exempel på fält

• UserId – intern primärnyckel (GUID/int)
• NationalId – personnummer/ID
  • svenskt personnummer (ÅÅÅÅMMDDXXXX / ÅÅMMDDXXXX),
  • TF‑nummer (ÅÅMMDD‑TFnn),
  • annat unikt ID (t.ex. lokalt elev‑ID eller manuellt alias).
• ExternalId – referens mot källsystem (där sådan finns)
  • t.ex. elevID i elevregistret, anställningsID i personalsystemet.
• FirstName, LastName
• Roles – uppsättning roller på kontot
  • t.ex. Student, Staff, Guardian (en eller flera).
• IsActive – flagga för om kontot är aktivt/inloggningsbart i Vklass
• CreatedAt, UpdatedAt

Domänlogik och relationer

• Ett UserAccount kan ha:
  • flera skolkopplingar (UserSchoolLink),
  • flera gruppkopplingar (UserGroupLink),
  • flera relationskopplingar (t.ex. GuardianChildRelation),
  • historikobjekt (närvaro, resultat, meddelanden m.m.) i andra moduler.
• Ett konto kan vara:
  • synkroniserat från verksamhetssystem (där NationalId/ExternalId matchar data i underlaget),
  • manuellt skapat direkt i Vklass (utan koppling till källsystem).
• Funktionen för utökad användarhantering:
  • raderar aldrig data i källsystem, bara Vklass representation,
  • använder NationalId och/eller ExternalId vid kontroller mot synkroniseringsunderlaget före radering,
  • utgår från principen ”en fysisk person – ett huvudkonto per organisation”, vilket upprätthålls genom sammanslagning av dubbletter.

Exempel
En och samma person kan ha ett äldre manuellt konto (NationalId = 120813‑TF21) och ett nytt synkroniserat konto (NationalId = 20120813‑1234). Båda är UserAccount‑poster och hanteras i sammanslagningsflödet tills endast det synkroniserade kontot återstår som huvudkonto.

---

Skolkoppling / UserSchoolLink

(befintlig entitet, återanvänds)

UserSchoolLink modellerar kopplingen mellan ett användarkonto och en skola/enhet i organisationen.

Exempel på fält

• UserSchoolLinkId – primärnyckel
• UserId → referens till UserAccount
• SchoolId – referens till skol-/enhetsentitet
• RoleAtSchool – hur personen verkar på enheten
  • t.ex. StudentAtSchool, StaffAtSchool, GuardianAtSchool.
• StartDate, EndDate (valfritt) – anger giltighetsperiod

Domänlogik

• 1:N‑relation: ett UserAccount kan ha 0..N UserSchoolLink‑poster (t.ex. vid arbete på flera skolor eller byte av skola).
• Vid radering av konto:
  • tas samtliga UserSchoolLink för kontot bort.
• Vid sammanslagning:
  • överförs alla relevanta UserSchoolLink från källkonto till målkonto,
  • dubbletter (samma SchoolId + samma roll) konsolideras till en unik koppling per skola/roll.

Exempel
En specialpedagog som arbetar på tre skolor i kommunen har tre UserSchoolLink‑poster, en per skola. Vid sammanslagning av två konton för samma person ska alla tre länkar följa med till det valda målkontot.

---

Klass‑ och gruppkoppling / UserGroupLink

(befintlig entitet, återanvänds)

UserGroupLink kopplar användarkontot till klasser, undervisningsgrupper eller andra grupper/arbetslag.

Exempel på fält

• UserGroupLinkId – primärnyckel
• UserId → UserAccount
• GroupId – referens till grupp-/klassetentitet
• RoleInGroup – t.ex. StudentInGroup, TeacherInGroup, MentorInGroup
• StartDate, EndDate (valfritt)

Domänlogik

• 1:N‑relation: ett UserAccount kan ha 0..N gruppkopplingar.
• En elev kan t.ex. samtidigt:
  • tillhöra en basgrupp/klass,
  • delta i flera undervisningsgrupper (språkval, valbara kurser),
  • ingå i fritidshemsgrupp.
• Vid radering av konto:
  • tas alla UserGroupLink för kontot bort.
• Vid sammanslagning:
  • konsolideras alla gruppkopplingar till målkontot,
  • existerande dubbletter (samma GroupId + RoleInGroup) tas bort så att målkontot endast förekommer en gång per grupp/roll.

Exempel
En lärare har undervisat samma klass via två olika konton (manuellt konto och synkroniserat konto). Efter sammanslagning ska klassen endast se läraren en gång i sin grupplista och historiska lektionspass vara kopplade till målkontot.

---

Relation vårdnadshavare–barn / GuardianChildRelation

(befintlig entitet, återanvänds)

GuardianChildRelation representerar en formell koppling mellan ett vårdnadshavarkonto och ett barn-/elevkonto i Vklass.

Exempel på fält

• GuardianChildRelationId – primärnyckel
• GuardianUserId → UserAccount (med rollen vårdnadshavare)
• ChildUserId → UserAccount (med rollen elev/barn)
• StartDate, EndDate (valfritt)

Domänlogik

• En vårdnadshavare kan ha relationer till flera barn (syskon).
• Ett barn kan ha relationer till flera vårdnadshavare.
• Vid radering av vårdnadshavarkonto:
  • tas alla GuardianChildRelation med GuardianUserId = kontot bort.
• Vid radering av barnkonto:
  • tas alla GuardianChildRelation med ChildUserId = kontot bort.
• Vid relationsspärr:
  • lämnas GuardianChildRelation i sig oförändrad eller tas bort (beroende på vald åtgärd),
  • själva blockeringen av att relationen skapas/återskapas vid synkronisering modelleras via en separat BlockEntry (se nedan).

Exempel
Vårdnadshavare A har GuardianChildRelation till barn B och C. Om relationen A–B spärras i spärrlistan ska just denna relation inte skapas eller visas i Vklass, medan relationen A–C fortsätter fungera.

---

Karenspost för radering / DeletionPending

(ny entitet)

DeletionPending representerar ett pågående raderingsärende för ett konto som är markerat för radering men ännu inte raderat. Entiteten bär all karens‑ och statuslogik, medan själva UserAccount förblir intakt tills radering genomförs.

Exempel på fält

• DeletionPendingId – primärnyckel
• UserId → referens till berört UserAccount
• MarkedByAdminId – referens till UserAccount för den org‑admin som initierade åtgärden
• MarkedAt – tidpunkt då kontot markerades för radering (start av karens)
• LastSeenInSyncAt – senast kända tidpunkt då identiteten förekom i synkroniseringsunderlaget
• Status – maskinläsbart statusvärde, t.ex.:
  • WaitingForFirstSyncCheck
  • InGracePeriod_UserPresentInSync
  • InGracePeriod_UserAbsentFromSync
  • ReadyForDeletion_WaitingForFinalCheck
  • Paused_WaitingForValidSync
• EarliestDeletionAt – beräknad tidigaste tidpunkt då radering får ske (t.ex. LastSeenInSyncAt + Karenstid)
• DirectDeletionAttempted (bool) – anger om försök till direkt radering gjorts inom ramen för detta ärende

Domänlogik

• Kardinalitet:
  • ett UserAccount kan ha 0 eller 1 aktiv DeletionPending åt gången,
  • en DeletionPending kan aldrig delas mellan flera konton.
• När ett konto markeras för radering:
  • skapas en DeletionPending‑post,
  • kontot får status ”Markerat för radering” i UI,
  • ingen faktisk radering sker ännu.
• Vid varje synkronisering:
  • uppdateras LastSeenInSyncAt om personen förekommer i underlaget,
  • Status och EarliestDeletionAt uppdateras automatiskt.
• När villkoren för radering är uppfyllda (t.ex. 48 timmar utan förekomst + lyckad slutkontroll):
  • raderas det underliggande UserAccount och dess kopplingar,
  • motsvarande DeletionPending‑post tas bort.
• När org‑admin ångrar raderingen:
  • tas DeletionPending bort utan att UserAccount påverkas,
  • kontot återgår till normal status.

Exempel
En elev tas bort ur elevregistret och markeras för radering måndag kl. 10.00. DeletionPending.MarkedAt = 10.00. Om eleven inte förekommer i någon synkronisering under 48 timmar och slutkontrollen är godkänd, raderas kontot automatiskt efter karenstiden.

---

Spärrpost / BlockEntry

(ny entitet)

BlockEntry är den tekniska representationen av en spärr i spärrlistan, antingen för en hel person (kontospärr) eller en specifik relation (relationsspärr vårdnadshavare–barn). Vid varje synkronisering används BlockEntry som filter innan ny‑ eller återaktivering av konton/relationer tillåts.

Exempel på fält

• BlockEntryId – primärnyckel
• OrganisationId – organisation/huvudman som spärren tillhör
• BlockType – t.ex.:
  • AccountBlock – spärr av hel identitet/konto,
  • GuardianChildRelationBlock – spärr av specifik vårdnadshavare–barn‑relation.
• UserId – används vid AccountBlock (referens till spärrat konto om det funnits i Vklass)
• GuardianUserId, ChildUserId – används vid relationsspärr
• CreatedByAdminId – org‑admin som skapade spärren
• CreatedAt – tidpunkt då spärren skapades
• IsInactive – anger om spärren är hävd (false = aktiv, true = inaktiv)
• InactivatedByAdminId, InactivatedAt – vem/när spärren hävdes (om tillämpligt)
• Comment – kort, intern kommentar (utan känsliga beslutstexter)

Domänlogik

• Spärrar är organisationsbundna: en BlockEntry påverkar endast synkronisering inom aktuell OrganisationId.
• Vid AccountBlock:
  • synkroniseringen får inte:
    • skapa nytt konto för identiteten,
    • återaktivera tidigare raderat konto,
    • uppdatera befintligt konto (om det finns kvar).
• Vid GuardianChildRelationBlock:
  • synkroniseringen får inte skapa eller återaktivera just den spärrade kombinationen (vårdnadshavare X – barn Y),
  • övriga relationer för samma vårdnadshavare/barn påverkas inte.
• En spärr gäller tills den explicit inaktiveras (IsInactive = true) av org‑admin.
• Det kan finnas flera BlockEntry för samma person, t.ex.:
  • en AccountBlock för kontot, och
  • flera GuardianChildRelationBlock för olika barn.

Exempel
En konsults konto raderas och AccountBlock läggs på konsultens personnummer. Senare läggs personen (av misstag) in i personalsystemet. När synkroniseringen körs ignorerar Vklass posten för detta personnummer och skapar inte något nytt konto.

---

Åtgärdslogg / AdminActionLog

(ny/utökad entitet för spårbarhet i denna funktion)

AdminActionLog registrerar centrala åtgärder som genomförs i den utökade användarhanteringen (radering, sammanslagning, skapande/hävning av spärrar m.m.) på ett dataminimerat sätt.

Exempel på fält

• AdminActionLogId – primärnyckel
• OrganisationId – organisation/huvudman
• ActionType – standardiserad typ, t.ex.:
  • MarkedForDeletion
  • DeletionCompleted
  • DeletionCancelled
  • DirectDeletionCompleted
  • DirectDeletionAborted_UserInSync
  • MergeCompleted
  • BlockCreated
  • BlockInactivated
• PerformedByAdminId → UserAccount (org‑admin/systemnära admin)
• PerformedAt – tidpunkt för åtgärden
• AffectedUserId – internt ID för berört konto (primärt konto)
• AffectedSecondaryUserId – sekundärt konto vid t.ex. sammanslagning (källkonto)
• Pseudonymiserad användarinfo för visning:
  • NationalIdPrefix – högst de sex första siffrorna/tecknen i ID vid visning (ååmmdd eller motsvarande),
  • FirstNameSnapshot – förnamn vid åtgärdstillfället,
  • SchoolNameSnapshot – skola/enhet vid åtgärdstillfället (om relevant).
• Details – strukturerad teknisk metadata (t.ex. vilken typ av spärr, vilka roller som slogs ihop), utan fullständiga personnummer eller beslutstexter.

Domänlogik

• AdminActionLog används endast för:
  • spårbarhet (vem gjorde vad, när, på vilket konto),
  • teknisk revision/felsökning under en begränsad tid.
• Efter att ett konto raderats:
  • får loggvisning aldrig visa fullständigt personnummer/ID,
  • endast NationalIdPrefix, förnamn och ev. skola/enhet är synliga för org‑admin.
• Log

Entitet Användarkonto

Ett användarkonto representerar en unik, inloggningsbar identitet för en fysisk person i Vklass inom en specifik organisation (huvudman/kommun). All avancerad livscykelhantering i denna specifikation – radering, sammanslagning och spärrning – utgår från användarkontot som central entitet, oavsett:

• om personen är elev/barn, personal eller vårdnadshavare, och
• om kontot är synkroniserat från verksamhetssystem eller skapat manuellt i Vklass.

Ett och samma användarkonto kan bära flera roller samtidigt (t.ex. personal + vårdnadshavare) och ha kopplingar till flera skolor/enheter.

---

Kärnstruktur och centrala fält

Följande fält/egenskaper är centrala för den utökade användarhanteringen. Namngivningen nedan speglar den logiska modellen (svenska/engelska); exakt fysisk datamodell kan avvika.

AnvändarID / UserId

• Intern, teknisk primärnyckel för användarkontot i Vklass.
• Används som referens från:
  • skol‑ och enhetskopplingar,
  • klass‑ och gruppkopplingar,
  • relationer (t.ex. vårdnadshavare–barn),
  • karensposter (DeletionPending),
  • spärrposter (BlockEntry),
  • åtgärdslogg (AdminActionLog).

OrganisationsID / OrganisationId

• Identifierar vilken Vklass‑organisation (huvudman/kommun) kontot tillhör.
• Säkerställer att:
  • ett konto aldrig delas mellan olika huvudmän i Vklass, och
  • alla åtgärder i den utökade användarhanteringen alltid är strikt avgränsade till den egna organisationen.

Personnummer / NationalId

• Primärt identitetsfält ur verksamhetens perspektiv, t.ex.:
  • svenskt personnummer (ÅÅÅÅMMDDXXXX / ÅÅMMDDXXXX),
  • TF‑nummer (ÅÅMMDD‑TFnn, t.ex. 120813‑TF21),
  • annat unikt ID (lokalt ID, tillfälligt ID, manuellt alias).
• Används för:
  • sökning och urval i funktionen,
  • matchning mot synkroniseringsunderlag,
  • koppling mellan flera konton vid dubblettutredning,
  • pseudonymiserad identifiering i åtgärdslogg efter radering (endast de sex första tecknen, t.ex. 120813‑******).

Externt ID / ExternalId

• Referens mot källsystem, t.ex.:
  • elevID i elevregister,
  • anställningsID i personalsystem,
  • vårdnadshavar‑ID i separat register.
• Används för:
  • robust matchning mot synkroniseringsunderlag även om personnummer ändras,
  • felsökning i integrationsflöden.

Förnamn / FirstName och Efternamn / LastName

• Visas i samtliga administrationsvyer och används för att säkerställa att rätt person hanteras vid t.ex. sammanslagning av konton.
• Snapshot‑varianter av dessa kan lagras i åtgärdslogg i pseudonymiserad form efter radering.

Roller / Roles

• Uppsättning av roller som kontot har inom organisationen, t.ex.:
  • Student (elev/barn),
  • Staff (personal),
  • Guardian (vårdnadshavare).
• Ett konto kan ha en eller flera roller samtidigt.
  • Exempel: en lärare som också är vårdnadshavare i kommunen har både Staff och Guardian på samma konto.
• Rollen styr vilka andra vyer, funktioner och personuppgifter kontot indirekt får åtkomst till i Vklass, men ändrar inte datamodellen för UserAccount.

Kontostatus / AccountStatus

• Anger kontots grundläggande status i Vklass, t.ex.:
  • Active,
  • Inactive (avaktiverat konto).
• Den utökade användarhanteringen:
  • använder inte enbart statusändringar för gallring,
  • utan arbetar med faktisk radering av kontot när villkoren för radering är uppfyllda.
• Befintlig avaktiveringslogik (t.ex. enskilda skolors rutiner för att stänga konton) ersätts inte, utan kompletteras av denna funktion.

Tidsstämplar / CreatedAt, UpdatedAt

• CreatedAt: när kontot skapades i Vklass (första gången).
• UpdatedAt: när kontot senast uppdaterades (t.ex. via synkronisering eller manuell ändring).
• Används bl.a. för felsökning, revision och vid behov i avancerade gallringsscenarier.

Synkroniseringsmetadata (metafält)
Exempel på logiska fält:

• IsSynchronized (bool) – anger om kontot:
  • är skapat och/eller styrs av synkronisering från källsystem, eller
  • är rent manuellt skapat i Vklass.
• SourceSystem (enum/sträng) – vilket källsystem som primärt försörjer kontot, t.ex.:
  • StudentSystem,
  • HRSystem,
  • GuardianRegistry.
• LastSyncAt – tidpunkt då kontot senast uppdaterades via synkronisering.

Dessa fält används i raderings‑ och sammanslagningsflöden för att:

• avgöra hur kontot ska kontrolleras mot synkroniseringsunderlaget,
• ge org‑admin rätt beslutsunderlag (t.ex. ”synkroniserat lärarkonto” kontra ”manuellt skapat konsultkonto”).

---

Regler och beteende vid radering

Den utökade användarhanteringen utgår från att ett användarkonto som raderas inom denna funktion gallras tekniskt ur Vklass, inte bara sätts som inaktivt.

Vid slutlig radering av ett användarkonto ska:

• posten i användartabellen (UserAccount) tas bort,
• alla direkta kopplingar där UserId är främmande nyckel hanteras enligt definierade gallringsregler per domän, t.ex.:
  • skol‑ och enhetskopplingar (UserSchoolLink),
  • klass‑ och gruppkopplingar (UserGroupLink),
  • relationer vårdnadshavare–barn (GuardianChildRelation),
  • andra konto‑beroende entiteter,
• kontorelaterad historik (närvaro, resultat, uppgifter, meddelanden m.m.) gallras eller anonymiseras i respektive modul i den omfattning som datastrukturen och juridiken medger.

Radering inom denna funktion är alltid villkorad:

• Vid radering med karenstid:

  • kontot får inte raderas förrän karensvillkoret är uppfyllt (t.ex. 48 sammanhängande timmar utan förekomst i synkroniseringsunderlaget), och
  • slutlig kontroll mot verksamhetssystem/synkroniseringsunderlag visar att identiteten inte längre förekommer.

• Vid direkt radering:

  • kontot får endast raderas om en aktuell kontroll mot synkroniseringsunderlaget visar att personen inte längre förekommer där, och
  • org‑admin uttryckligen har bekräftat åtgärden enligt dubbelbekräftelseflödet.

Efter genomförd radering gäller:

• kontot är inte längre sökbart eller synligt för några roller i Vklass,
• inloggning med kontots tidigare identitet är inte möjlig (alla sessions‑tokens ogiltigförklaras),
• inga ytterligare åtgärder i den utökade användarhanteringen kan riktas mot kontot (t.ex. ny karens, sammanslagning eller spärr) – det betraktas som obefintligt,
• endast en pseudonymiserad ögonblicksbild av vissa identitetsuppgifter får förekomma i åtgärdsloggen under en begränsad period (t.ex. förnamn, sex första siffror i NationalId, skola/enhet).

---

Regler och beteende vid sammanslagning

Vid sammanslagning deltar två användarkonton:

• ett målkonto (TargetUser) – det konto som ska leva vidare, och
• ett källkonto (SourceUser) – det konto vars kopplingar och historik så långt möjligt förs över och som därefter upphör som egen identitet.

Identitet (NationalId, ExternalId)

• Målkontots identitetsuppgifter (NationalId, ExternalId) är normerande efter sammanslagning. Systemet:
  • skriver inte automatiskt över målkontots personnummer/ID med värden från källkontot,
  • ändrar inte automatiskt vilket ExternalId som används för koppling mot källsystem.
• Om den ”rätta” identiteten framåt finns på det konto som först valts som källkonto är det org‑admins ansvar att:
  • byta roll (göra det kontot till målkonto) innan sammanslagningen bekräftas, eller
  • först rätta uppgifter i verksamhetssystemen.

Exempel:
En elev har TF‑konto 120813‑TF21 (manuellt) och nytt synkroniserat konto 20120813‑1234 från elevregistret. Det synkroniserade kontot bör väljas som målkonto så att kopplingen mot elevregistret kvarstår oförändrad.

Roller och behörigheter

• Roller unions‑slås:
  • alla roller (elev/barn, personal, vårdnadshavare) som finns på minst ett av kontona ska finnas på målkontot efter sammanslagning,
  • inga roller tas bort automatiskt.
• Behörigheter och rättigheter (t.ex. SchoolPrincipal, SchoolStudentAdvisor, supportroller, begränsande roller):
  • konsolideras till målkontot enligt unionsprincipen,
  • begränsande roller (t.ex. ”Kan ej logga in som annan användare”) får aldrig tas bort automatiskt; finns de på något konto ska de finnas kvar på det sammanslagna kontot,
  • eventuell ”städning” av behörigheter (t.ex. ta bort föråldrade roller) måste göras manuellt efter sammanslagning via ordinarie behörighetsgränssnitt.

Kopplingar och historik

• Skol‑/enhetskopplingar (UserSchoolLink), gruppkopplingar (UserGroupLink) och relationer (GuardianChildRelation m.fl.):

  • förs över från källkonto till målkonto i den mån modellen tillåter,
  • dubbletter (samma skola + samma roll, samma grupp + samma roll, samma barnrelation) konsolideras till en unik koppling per entitet.

• Historik:

  • närvaro/poster (lektion, dag, period),
  • resultat, bedömningar, betyg, omdömen,
  • uppgifter, inlämningar, feedback,
  • meddelanden, inlägg, konversationer,
  • andra konto‑beroende dataposter
    kopplas om till målkontot så långt det är tekniskt och juridiskt möjligt, enligt domänspecifika regler.

Efter genomförd sammanslagning:

• upphör källkontot att vara ett aktivt användarkonto:
  • det går inte att logga in med,
  • det visas inte i vanliga användarlistor eller sökningar,
• all fortsatt hantering (ny radering, ny sammanslagning, ny spärr) sker via målkontot,
• systemet ska inte återskapa källkontot via synkronisering:
  • om det finns risk att källkontots tidigare identitet (t.ex. gammalt personnummer eller TF‑nummer) återkommer i underlaget kan org‑admin vid behov komplettera med en kontospärr för den identiteten.

---

Relation till karens (DeletionPending) och spärrlista (BlockEntry)

Karenstid / DeletionPending

• Ett konto som är markerat för radering har exakt en aktiv karenspost (DeletionPending) kopplad via UserId.
• Själva UserAccount:
  • är oförändrat (förutom statusflagga i UI) så länge raderingen inte genomförts,
  • fungerar fullt ut som identitet vid synkronisering, UI‑visning och sökning.
• När raderingen:
  • ångras → DeletionPending tas bort, kontot består,
  • slutförs → UserAccount raderas, DeletionPending tas bort, spårbarhet finns endast i åtgärdslogg.

Spärrlista / BlockEntry

• Kontospärrar (BlockType = AccountBlock) refererar användarkontot via:
  • UserId (om kontot finns/har funnits), och/eller
  • NationalId/ExternalId (för att blockera ny‑ och återaktivering även om kontot raderats).
• Relationsspärrar (BlockType = GuardianChildRelationBlock) refererar:
  • vårdnadshavarens UserId,
  • barnets UserId.
• Spärrposter:
  • ändrar aldrig fälten i UserAccount direkt,
  • påverkar endast hur synkroniseringen får skapa eller uppdatera konton och relationer.

---

Synkroniserade kontra manuellt skapade konton

Synkroniserade konton

• NationalId och/eller ExternalId används som primära nycklar mot verksamhetssystemet.
• Kontot:
  • skapas, uppdateras och avslutas i huvudsak via synkronisering,
  • får inte raderas förrän kontot inte längre förekommer i synkroniseringsunderlaget (kontroll vid karens och direkt radering).
• Vid sammanslagning med ett manuellt konto rekommenderas det synkroniserade kontot som målkonto för att bevara kopplingen mot källsystemet.

Manuellt skapade konton

• Saknar ofta ExternalId, men har alltid ett NationalId (som kan vara TF‑nummer, tillfälligt ID eller annat unikt värde).
• Används t.ex. för:
  • praktikanter, konsulter, tillfälliga vikarier,
  • elever utan personnummer, elever med TF‑nummer eller alias,
  • rena testkonton.
• Kontroller mot verksamhetssystem vid radering kan ge:
  • ”ingen träff” (kontot finns inte i källsystemen), vilket är ett legitimt fall för direkt radering om övriga villkor är uppfyllda.

---

Integritets‑ och dataskyddsaspekter

• Den utökade användarhanteringen introducerar inga nya personuppgiftsfält på användarkontot; funktionen återanvänder befintliga strukturer.

Entitet Karenspost för radering

En karenspost för radering (DeletionPending) representerar ett explicit, pågående raderingsärende för ett visst användarkonto. Karensposten är den tekniska ”arbetsnoden” i raderingsflödet och används för att:

• hålla isär vilka konton som är markerade för radering från de som är vanliga aktiva konton,
• styra och beräkna när villkoren för slutlig radering är uppfyllda (t.ex. 48 timmar utan förekomst i synkroniseringsunderlaget samt godkänd slutlig kontroll),
• bära den statusinformation som krävs för att karenslistan i admin‑gränssnittet alltid ska visa ett korrekt och aktuellt läge per konto.

Varje aktiv karenspost är kopplad till exakt ett användarkonto (UserAccount) inom en organisation, och ett användarkonto kan ha högst en aktiv karenspost åt gången. Detta upprätthålls tekniskt genom en unikhetsregel på (OrganisationId, UserId) för aktiva karensposter.

---

Struktur och fält

En karenspost innehåller endast de uppgifter som behövs för att driva raderingsflödet; inga personuppgifter lagras direkt i posten utöver referensen till användarkontot. Minst följande fält ingår:

• KarensID / DeletionPendingId
  Unik intern identifierare för karensposten (t.ex. GUID/int).
  Används för intern referens, felsökning och logik runt karenslistan.

• OrganisationsID / OrganisationId
  Referens till den organisation (huvudman) som raderingsärendet tillhör.
  Säkerställer att karensposter aldrig korsar organisationsgränser och att en org‑admin endast ser och hanterar karensposter inom sin egen organisation.

• AnvändarID / UserId
  Referens till det användarkonto (UserAccount) som är markerat för radering.

  • Primär koppling mellan karenspost och konto.
  • Används bl.a. för att:
    • visa rätt metadata i karenslistan (namn, roll, skola m.m.),
    • genomföra slutlig radering när villkoren är uppfyllda.
  • Det får endast finnas en aktiv karenspost per UserId och OrganisationId.

• Markerad av / MarkedByAdminId
  Referens till den org‑admin (eller systemnära administratör) som initierade raderingen.
  Används för spårbarhet och visas (i pseudonymiserad form vid behov) i åtgärdsloggen.

• Markerad tid / MarkedAt
  Tidpunkt (datum + klockslag) då kontot markerades för radering.

  • Utgör starttid för karensfönstret.
  • Används tillsammans med LastSeenInSyncAt för att avgöra när den sammanhängande karenstiden är uppfylld.

• Senast sedd i synk / LastSeenInSyncAt
  Tidpunkt då användaren senast förekom i något av organisationens synkroniseringsunderlag (elev, personal, vårdnadshavare).

  • Uppdateras automatiskt vid varje synkkörning där identiteten hittas.
  • Om användaren inte har förekommit sedan markeringen kan fältet initialt vara tomt eller lika med MarkedAt.
  • Används för att beräkna ”senaste förekomst” och därmed om karenstiden (t.ex. 48 timmar) utan förekomst har passerat.

• Planerad tidigaste radering / EarliestDeletionAt
  Beräknad tidigaste möjliga tidpunkt då radering får initieras, givet nuvarande kunskap om synkroniseringen.

  • Sätts t.ex. till LastSeenInSyncAt + Karenstid (standard 48 timmar, men tekniskt konfigurerbar).
  • Om användaren inte förekommit sedan markeringen kan det initialt bli MarkedAt + Karenstid.
  • Uppdateras automatiskt varje gång LastSeenInSyncAt ändras (d.v.s. när användaren återkommer i synk).

• Status / Status
  Maskinläsbart statusvärde som anger var i raderingsflödet kontot befinner sig (se statusvärden nedan).

  • Används av bakgrundsprocesser för att avgöra vilka karensposter som ska gå vidare i flödet.
  • Mappas i gränssnittet till begripliga textbeskrivningar (t.ex. ”I karens – förekommer i synkronisering”).

• Senast status ändrad / StatusChangedAt
  Tidpunkt då Status senast uppdaterades.

  • Underlättar felsökning och analys (t.ex. ”hur länge har posten legat i detta läge?”).
  • Kan användas i UI för sortering/filter (t.ex. hitta poster som länge varit pausade).

• Teknisk synkstatus / SyncHealthFlag (valfritt, beroende på implementation)
  Fält som kan användas för att markera att karensen är temporärt pausad på grund av synk‑/integrationsfel, t.ex.:

  • Ok – senaste synkronisering var giltig, karenslogik kan fortsätta som vanligt.
  • SyncFailed – senaste synkkörning misslyckades, inga nya raderingsbeslut får fattas tills ny lyckad körning genomförts.

Utöver ovan kan karensposten innehålla rena tekniska fält, t.ex. versionsräknare för samtidighetshantering. Inga ytterligare personuppgifter (namn, personnummer m.m.) får lagras direkt i karensposten; all sådan information hämtas från det kopplade UserAccount vid visning i gränssnittet.

---

Statusvärden

Statusfältet (Status) beskriver det aktuella läget i raderingsflödet. Följande logiska statusvärden föreslås:

• PendingFirstCheck / Väntar första kontroll

  • Karensposten har just skapats.
  • Kontot är markerat för radering, men första kontrollen mot synkroniseringsunderlaget (efter markeringen) har ännu inte genomförts.
  • MarkedAt är satt; LastSeenInSyncAt kan vara tom eller motsvara senaste kända synk innan markeringen.

• InGrace_UserPresentInSync / I karens – förekommer i synkronisering

  • Användaren finns med i det senaste synkroniseringsunderlaget.
  • LastSeenInSyncAt uppdateras vid varje körning där identiteten påträffas.
  • Karenstiden (t.ex. 48 timmar) utan förekomst har inte börjat löpa eller har avbrutits; klockan nollställs vid varje ny förekomst.
  • EarliestDeletionAt beräknas om till LastSeenInSyncAt + Karenstid varje gång användaren återkommer.

• InGrace_UserAbsentFromSync / I karens – ingen förekomst i synkronisering (karenstid pågår)

  • Användaren har inte förekommit i något synkroniseringsunderlag sedan viss tidpunkt.
  • Systemet beräknar kontinuerligt:
    • tiden sedan senaste kända förekomst (LastSeenInSyncAt, eller MarkedAt om ingen förekomst skett efter markERING),
    • hur lång tid som återstår till EarliestDeletionAt.
  • När aktuell tid ≥ EarliestDeletionAt kan status övergå till ReadyForDeletion under förutsättning att ingen tekniskt ogiltig synkronisering föreligger.

• ReadyForDeletion / Redo för radering – väntar på slutlig kontroll

  • Systemet bedömer tidsmässigt att karensvillkoret är uppfyllt (t.ex. minst 48 sammanhängande timmar utan förekomst).
  • Kontot är kandidat för slutlig radering, men en sista kontroll mot senaste fullständiga synkroniseringsunderlag/verksamhetssystem måste genomföras innan radering startar.
  • Efter godkänd slutkontroll initieras själva raderingen; om kontrollen istället visar att användaren åter finns i underlaget flyttas posten tillbaka till InGrace_UserPresentInSync.

• Paused_WaitingForValidSync / Pausad – avvaktar giltig synkronisering

  • Används när synkroniseringsunderlaget inte kan anses tillförlitligt, t.ex.:
    • senaste synkkörning har misslyckats helt,
    • inkommande data är inkomplett eller felaktig.
  • Så länge status är ”Paused”:
    • får inga karensposter flyttas över till ReadyForDeletion,
    • får ingen slutlig radering starta utifrån tidsberäkningen.
  • När en ny lyckad synkkörning genomförts:
    • uppdateras LastSeenInSyncAt vid behov,
    • Status justeras tillbaka till relevant läge (InGrace_UserPresentInSync eller InGrace_UserAbsentFromSync eller direkt ReadyForDeletion om villkoren då är uppfyllda).

Statusvärdena är avsedda för intern logik men mappas 1:1 till human‑läsbara texter i karenslistan, t.ex.:

• ”Väntar på första kontroll mot synkronisering”,
• ”I karens – förekommer i synkronisering”,
• ”I karens – ingen förekomst i synkronisering (karenstid pågår)”,
• ”Redo för radering – väntar på slutlig kontroll”,
• ”Tillfälligt stoppad – avvaktar lyckad synkronisering”.

---

Livscykel och regler

Skapande av karenspost

• En karenspost skapas endast när en behörig org‑admin, via den utökade användarhanteringen, väljer ”Markera för radering” på ett konto och bekräftar åtgärden.
• Vid skapande:
  • sätts OrganisationId och UserId,
  • MarkedAt sätts till aktuell tid,
  • Status sätts till PendingFirstCheck,
  • EarliestDeletionAt kan initialt lämnas tom eller sättas preliminärt till MarkedAt + Karenstid (uppdateras sedan när första riktiga sync‑data finns).
• Skapande får blockeras om:
  • kontot redan har en aktiv karenspost, eller
  • kontot redan är raderat (det ska inte gå att markera ett icke‑existerande konto).

Uppdatering vid synkronisering

Vid varje synkroniseringskörning för organisationen genomförs följande för samtliga aktiva karensposter:

1. Systemet kontrollerar om identitet kopplad till UserId (via NationalId/ExternalId) förekommer i något av synkroniseringsflödena.

2. Om användaren förekommer:

   • LastSeenInSyncAt uppdateras till synkkörningens tidsstämpel,
   • Status sätts (eller kvarstår) som InGrace_UserPresentInSync,
   • EarliestDeletionAt sätts till LastSeenInSyncAt + Karenstid.
   • Eventuell tidigare påbörjad karensperiod nollställs – 48‑timmarsfönstret börjar räknas om från denna senaste förekomst.

3. Om användaren inte förekommer:

   • om status tidigare var PendingFirstCheck eller InGrace_UserPresentInSync:
     • systemet tolkar detta som att karensperioden nu inleds,
     • Status sätts till InGrace_UserAbsentFromSync,
     • EarliestDeletionAt beräknas utifrån senaste kända förekomst (LastSeenInSyncAt eller MarkedAt om ingen förekomst funnits sedan markeringen),
   • om status redan är InGrace_UserAbsentFromSync:
     • systemet kontrollerar om aktuell tidpunkt ≥ EarliestDeletionAt;
       • om ja → Status uppdateras till ReadyForDeletion,
       • om nej → kontot ligger kvar i pågående karens.

4. Om den aktuella synkkörningen misslyckas eller bedöms som ogiltig:

   • ska inga statusövergångar till ReadyForDeletion eller slutlig radering ske baserat på denna körning,
   • karensposterna kan markeras via SyncHealthFlag och/eller Status = Paused_WaitingForValidSync.

Slutlig radering

• När en karenspost har Status = ReadyForDeletion kan ett bakgrundsjobb påbörja slutlig radering.

• Innan UserAccount raderas måste en sista kontroll göras mot:

  • senaste giltiga synkroniseringsunderlag, och/eller
  • direktuppslag mot verksamhetssystem (där sådan funktion finns),
    för att verifiera att identiteten fortfarande inte förekommer.

• Om slutkontrollen:

  • bekräftar frånvaro:
    • initieras och genomförs den permanenta raderingen av kontot och dess kopplingar enligt definierade gallringsregler,
    • motsvarande DeletionPending tas bort,
    • en åtgärdspost skapas i AdminActionLog.
  • visar att användaren trots allt förekommer:
    • raderingen avbryts,
    • LastSeenInSyncAt uppdateras,
    • Status sätts tillbaka till InGrace_UserPresentInSync,
    • EarliestDeletionAt räknas om från denna nya förekomst.

Ångra radering

• När en org‑admin väljer ”Ångra radering” för ett konto i karenslistan:
  • raderas DeletionPending‑posten omedelbart,
  • kontot slutar omfattas av karens‑ och raderingslogik,
  • UserAccount fortsätter som ett vanligt aktivt konto.
• Ingen data på själva kontot ändras i samband med att karensposten tas bort; eventuella spärrposter i spärrlistan (BlockEntry) påverkas inte och måste hanteras separat.

Tekniska fel och pausläge

• Om synkronisering eller slutkontroll inte kan genomföras (t.ex. integrationsfel, databastillgänglighet):
  • får inga karensposter övergå till ReadyForDeletion,
  • inga slutliga raderingar får starta baserat på ofullständig/og

Entitet Spärrpost för inläsning

En spärrpost representerar en regel i Vklass som blockerar att en viss person eller en viss relation läses in eller återskapas via synkronisering från verksamhetssystemet. Entiteten används av synkroniseringsmotorn som ett filter: om inkommande data matchar en aktiv spärrpost ska den dataposten ignoreras, även om den finns kvar i källsystemet. Själva spärrposten ändrar aldrig källdata, utan påverkar enbart hur Vklass tolkar synkroniseringsunderlaget.

Syfte

• Förhindra att raderade konton återskapas via synkronisering.
• Möjliggöra tillfällig eller permanent blockering av användare (elev/barn, personal, vårdnadshavare) utan att ändra källsystem.
• Möjliggöra finmaskig blockering av specifika vårdnadshavare–barn‑relationer, utan att påverka vårdnadshavarens övriga relationer.

---

Fält (struktur)

Minst följande fält ingår i entiteten Spärrpost:

• SpärrID / BlockEntryId
  Unik intern identifierare för spärrposten.

• OrganisationsID / OrganisationId
  Referens till organisationen (huvudman) där spärren gäller.

  • Säkerställer att spärrar aldrig får effekt utanför den egna organisationen.
  • Används av synkroniseringen för att bara tillämpa spärrar inom rätt organisationsdomän.

• Typ av spärr / BlockType
  Anger vilken sorts spärr det är. Minst följande typer stöds:

  • AccountBlock – kontospärr för hela personen (oavsett roll).
  • GuardianChildRelationBlock – relationsspärr för en specifik vårdnadshavare–barn‑relation.
    (Domänmodellen kan vid behov utökas med fler relationstyper, men dessa två är grundläggande.)

• AnvändarID / UserId (obligatoriskt vid AccountBlock)
  Referens till det användarkonto (UserAccount) som spärren avser.

  • Används för att snabbt kunna matcha inkommande synkposter mot spärrar.
  • Om kontot har raderats kan referensen ligga kvar tekniskt även om kontot inte längre är sökbart i UI.

• VårdnadshavarID / GuardianUserId (obligatoriskt vid GuardianChildRelationBlock)
  Referens till vårdnadshavarkontot (UserAccount) i den spärrade relationen.

• BarnID / ChildUserId (obligatoriskt vid GuardianChildRelationBlock)
  Referens till barnets konto (UserAccount) i den spärrade relationen.

• Extern identitetsnyckel / ExternalKey (valfritt men starkt rekommenderat)
  Ett fält som lagrar den identitet som används av synkroniseringen för att matcha personer:

  • t.ex. personnummer/ID, elev‑ID, personal‑ID.
  • För AccountBlock kan detta vara personnummer eller annat unikt ID.
  • För GuardianChildRelationBlock kan det vara en kombination av vårdnadshavarens och barnets synknycklar, beroende på hur integrationen är utformad.
  • Syftet är att synkprocessen ska kunna identifiera en spärr även om det inte finns ett aktivt UserAccount‑objekt.

• Typ av relation / RelationType (vid behov för relationsspärrar)
  Anger vilken relationstyp som spärras, t.ex. ”GuardianChild”.

  • Underlättar generisk hantering om fler relationstyper spärras i framtiden.

• Skapad av / CreatedByAdminId
  Referens till den org‑admin som skapade spärren.

• Skapad datum/tid / CreatedAt
  Tidpunkt då spärren lades till.

• Inaktiv / IsInactive
  Booleskt fält som anger om spärren är aktiv (false) eller hävd/inaktiv (true).

  • Spärrar raderas normalt inte omedelbart vid hävning, utan markeras inaktiva för att möjliggöra intern spårbarhet.

• Inaktiverad av / InactivatedByAdminId (valfritt)
  Referens till org‑admin som hävde spärren.

• Inaktiverad datum/tid / InactivatedAt (valfritt)
  Tidpunkt då spärren gjordes inaktiv.

• Kommentar / Comment (valfritt, kort textfält)
  Kan användas för en kort intern notering (t.ex. ”tillfällig spärr enligt beslut”, ”gäller endast barn X”).

  • Får inte innehålla känsliga detaljer om beslut, diagnoser eller liknande – endast neutral, administrativ information.

Spärrposten ska i övrigt inte innehålla fler personuppgifter än nödvändigt. Fullständiga personnummer, adressuppgifter, kontaktuppgifter eller andra känsliga fält lagras inte i själva spärrposten.

---

Domänlogik och regler

• Unika spärrar

  • Det ska inte finnas dubbla aktiva spärrar av samma typ för samma objekt:
    • En (1) aktiv AccountBlock per UserId och organisation.
    • En (1) aktiv GuardianChildRelationBlock per kombination av GuardianUserId + ChildUserId och organisation.
  • Försök att skapa en identisk spärr när en aktiv spärr redan finns ska antingen nekas eller återanvända befintlig spärr (utan att skapa en dubblett).

• Aktiv/inaktiv spärr

  • Synkroniseringen ska endast ta hänsyn till spärrposter där IsInactive = false.
  • Vid hävning av spärr sätts IsInactive = true och InactivatedAt + InactivatedByAdminId fylls i.
  • Inaktiva spärrposter har ingen effekt på synkprocessen men kan användas för intern uppföljning.

• Effekt vid kontospärr (AccountBlock)

  • När synkroniseringsunderlaget innehåller en person vars identitet/ExternalKey matchar en aktiv AccountBlock för organisationen:
    • Vklass får inte skapa ett nytt användarkonto för personen om det inte redan finns.
    • Ett tidigare raderat konto får inte återskapas via synk.
    • Nya skol‑, klass‑ eller rollkopplingar från synk ignoreras för denna identitet.
  • Hur ett eventuellt redan existerande konto i Vklass ska bete sig (t.ex. om det först ska raderas, avaktiveras eller lämnas orört) styrs av den övergripande livscykelhanteringen – spärrposten i sig styr endast att ny inläsning/återskapande blockeras.

• Effekt vid relationsspärr (GuardianChildRelationBlock)

  • När synkroniseringsunderlaget innehåller en relation vårdnadshavare–barn som matchar en aktiv relationsspärr:
    • Vklass får inte skapa eller återaktivera just denna relation.
    • Om relationen redan finns i Vklass kan synklogiken behöva se till att den tas bort eller inte uppdateras, beroende på implementation (huvudkravet är att vårdnadshavaren inte ska ha aktiv koppling till barnet i Vklass).
    • Övriga relationer för vårdnadshavaren och barnet fortsätter att hanteras normalt om de inte omfattas av andra spärrar.
  • På detta sätt kan organisationen stoppa åtkomst till ett specifikt barn utan att stänga hela vårdnadshavarkontot.

• Organisationsavgränsning

  • Spärrposter gäller endast inom den organisation de är skapade för.
  • Synkronisering för andra organisationer ska aldrig ta hänsyn till spärrar med annat OrganisationId.

• Livslängd

  • Själva spärrposterna omfattas inte av 30‑dagarslogik (till skillnad från åtgärdsloggarna). De ligger kvar så länge spärren ska gälla, tills org‑admin aktivt häver dem.
  • Hur länge inaktiva spärrposter bevaras kan styras av Vklass övergripande regler för systemloggar och administrativa metadata.

---

Relationer till andra entiteter

• UserAccount

  • En AccountBlock refererar ett UserAccount via UserId.
  • En GuardianChildRelationBlock refererar två UserAccount (vårdnadshavare och barn) via GuardianUserId respektive ChildUserId.
  • Spärrposten är logiskt kopplad till identiteterna även om själva användarkontona senare raderas (via ExternalKey eller motsvarande identitetsnyckel).

• GuardianChildRelation

  • Relationsspärrar är konceptuellt kopplade till GuardianChildRelation, men lagras separat:
    • själva relationen kan tas bort ur Vklass,
    • spärrposten säkerställer att synkronisering inte skapar relationen igen.

• AdminActionLog

  • Skapande, ändring och hävning av spärrposter ska loggas i åtgärdsloggen med typ av åtgärd, tidpunkt, ansvarig org‑admin och dataminimerad identifiering av berörda användare.
  • Själva spärrposten innehåller endast de fält som krävs för att styra synklogiken och för att ge org‑admin överblick i spärrlistan.

---

Användning i gränssnittet

• Spärrposterna exponeras för org‑admin i en särskild ”spärrlista”, där begränsad identifierande information visas (förnamn, sex första siffror i personnummer/ID, skola/enhet) tillsammans med typ av spärr och tidsstämplar.
• Från spärrlistan kan org‑admin:
  • söka och filtrera spärrar,
  • se om en spärr avser hela kontot eller en specifik relation,
  • öppna spärrposten för mer detaljerad vy,
  • inaktivera (häva) spärren när den inte längre ska gälla.

Genom entiteten Spärrpost separeras logiken för ”vad får synkroniseras in?” från både användarkonton och rena loggar. Det ger en tydlig, konfigurerbar mekanism för att blockera ny inläsning via synkronisering, utan att i sig lagra fler personuppgifter än vad som är absolut nödvändigt för funktionen.

Integrationer och dataflöden

Den utökade användarhanteringen bygger i hög grad på befintliga integrationer mellan Vklass och bakomliggande verksamhetssystem (elev‑, personal‑ och vårdnadshavarregister). Funktionaliteten är dock strikt läsande gentemot dessa system: inga åtgärder i den här funktionen uppdaterar, raderar eller skapar data i källsystemen. All påverkan sker i Vklass och i hur Vklass tolkar inkommande synkroniseringsdata.

Översiktligt dataflöde

1. Verksamhetssystem → Synkroniseringsunderlag
   De bakomliggande systemen (elev‑, personal‑, vårdnadshavarregister m.fl.) är ”ägare” av grunddatan:

   • vilka personer som finns,
   • deras roller (elev/barn, personal, vårdnadshavare),
   • skol‑ och klasskopplingar,
   • vårdnadshavare–barn‑relationer.

   Dessa system levererar regelbundet ett synkroniseringsunderlag till Vklass (batch, fil eller API, beroende på integration).

2. Synkronisering → Vklass användarkonton
   Vklass läser synkroniseringsunderlaget och:

   • skapar eller uppdaterar användarkonton (UserAccount),
   • uppdaterar skol‑, klass‑ och gruppkopplingar,
   • skapar/uppdaterar relationer (t.ex. vårdnadshavare–barn).

   Matchning sker normalt på personnummer/ID och/eller externa nycklar (ExternalId).

3. Utökad användarhantering → Vklass interna strukturer
   Den utökade användarhanteringen lägger till:

   • karensposter för planerad radering (DeletionPending),
   • spärrposter för inläsning (BlockEntry – konto eller specifik relation),
   • åtgärdsloggar (AdminActionLog), men ändrar inte själva integrationsflödet mot källsystemen.

4. Vklass → Övriga delar av Vklass
   Resultatet av radering, sammanslagning eller spärrning påverkar hur andra moduler i Vklass ser användare och relationer (t.ex. klasslistor, närvaro, bedömning), men inga externa system uppdateras direkt av denna funktion.

Synkronisering i relation till radering

Raderingsflödena (med karenstid och direkt radering) är tätt kopplade till synkroniseringen, men endast på läsning:

• När ett konto markeras för radering:

  • skapas en karenspost (DeletionPending) i Vklass,
  • inga omedelbara anrop görs mot källsystemet, men framtida synkroniseringar används för att följa om personen fortfarande förekommer.

• Vid varje synkroniseringskörning:

  • synkmotorn uppdaterar för varje konto i karenslistan om personen förekommer i underlaget, baserat på personnummer/ID och/eller ExternalId,
  • LastSeenInSyncAt och status i karensposten uppdateras,
  • raderingslogiken använder denna information för att avgöra om 48 sammanhängande timmar utan förekomst är uppfyllda.

• Innan slutlig radering (både efter karens och vid direkt radering):

  • görs en obligatorisk kontroll mot senaste synkroniseringsunderlaget och/eller ett riktat uppslag via integrationslagret (beroende på teknisk implementation),
  • om personen fortfarande finns i källsystemets underlag avbryts raderingen,
  • om personen inte längre förekommer i underlaget tillåts raderingen.

Ingen information skrivs tillbaka till verksamhetssystemen i samband med radering. Om en person även fortsättningsvis ska tas bort eller avslutas i källsystemet hanteras det utanför Vklass.

Synkronisering i relation till karenslista och status

Karenslistan i admin‑gränssnittet visar för varje konto i karens:

• senast kända förekomst i synkroniseringsunderlaget,
• beräknad tidigaste tidpunkt för möjlig radering,
• om det finns tekniska hinder (t.ex. misslyckad synkroniseringskörning).

Tekniskt innebär detta att:

• synkroniseringsmotorn, efter varje körning, uppdaterar metadata för aktuella DeletionPending‑poster,
• själva synklogiken för övriga användare är oförändrad – den utökade användarhanteringen lägger endast på ett extra lager av logik för de konton som ligger i karens.

Vid utebliven eller misslyckad synkronisering:

• flaggas detta mot karensflödet,
• inga slutliga raderingar tillåts förrän en lyckad synkronisering har genomförts, för att undvika beslut baserade på ofullständiga data.

Synkronisering i relation till direkt radering

Vid direkt radering görs en riktad kontroll mot synkroniseringsunderlaget innan åtgärden tillåts:

• Implementationsmässigt kan detta ske genom:

  • att läsa senaste kompletta synkroniseringssnapshot, eller
  • att anropa samma integrationslager/API som används vid ordinarie synkronisering, med personnummer/ID eller ExternalId som nyckel.

• Om kontrollen returnerar att personen fortfarande finns:

  • avbryts raderingen i Vklass,
  • synkroniseringsflödet fortsätter som vanligt.

• Om kontrollen visar att personen inte längre ingår i källtjänstens data för organisationen:

  • radering kan genomföras direkt.

Även här är integrationen strikt läsande; inga statusändringar görs i källsystemet.

Spärrlista (BlockEntry) i synkroniseringsflödet

Spärrlistan integreras i synkroniseringsmotorn som ett filter som utvärderas innan Vklass skapar eller uppdaterar konton och relationer:

1. Läs in synkroniseringsunderlag från källsystemen (oförändrat jämfört med idag).
2. För varje inkommande personpost:
   • kontrollera om det finns en aktiv AccountBlock i spärrlistan för den identiteten (via UserId/ExternalKey),
   • om ja:
     • hoppa över att skapa eller uppdatera kontot i Vklass (ingen ny inläsning sker),
     • logiken för övriga poster i underlaget fortsätter.
3. För varje inkommande relation vårdnadshavare–barn:
   • kontrollera om det finns en aktiv GuardianChildRelationBlock för kombinationen vårdnadshavare–barn,
   • om ja:
     • hoppa över att skapa/återaktivera just den relationen,
     • andra relationer för samma vårdnadshavare eller barn påverkas inte.

Synkroniseringsmotorn behöver därmed ha effektiv tillgång till spärrlistan (t.ex. via cache, indexerad tabell eller motsvarande), men behöver inte ändras i sina anrop mot källsystemen.

Sammanslagning av konton och påverkan på integrationer

Sammanslagning är intern i Vklass, men har konsekvenser för hur kommande synkroniseringar ska tolkas:

• Själva sammanslagningen:

  • uppdaterar inte källsystemen,
  • justerar primärt hur data i Vklass är kopplad (målkonto får samlade kopplingar och historik).

• Efter sammanslagning:

  • bör målkontots identitet (personnummer/ID och ExternalId) överensstämma med hur personen kommer rapporteras från källsystemen framåt,
  • om det ”gamla” ID:t från källsystemet riskerar att fortsatt leverera data parallellt med det nya ID:t finns risk att synkroniseringen försöker skapa ytterligare ett konto baserat på det gamla ID:t.

För att undvika detta kan organisationen:

• justera källsystem/integration (utanför denna funktion) så att endast aktuell identitet används, och/eller
• använda spärrlistan:
  • lägga AccountBlock på det gamla ID:t (t.ex. tidigare TF‑nummer) så att synkdata som refererar till detta ID ignoreras.

Vklass gör ingen automatisk uppdatering av external mapping mot källsystemen; ansvar för att identiteter är konsekventa över tid ligger på verksamhetssystemens konfiguration och på org‑admin i samband med sammanslagning.

Manuella konton och integrationer

För rena manuella konton (utan koppling till synkronisering):

• finns ingen motsvarande post i synkroniseringsunderlaget,
• kontroller mot verksamhetssystem vid radering kommer typiskt att resultera i ”ingen träff”,
• radering och sammanslagning påverkar enbart data i Vklass.

Spärrlista kan ändå användas för manuella konton om organisationen vill säkerställa att samma identitet inte senare läses in från källsystemet (t.ex. om en person som tidigare hanterats manuellt senare dyker upp i elev‑ eller personalsystemet med samma ID).

Påverkan på övriga integrationer och systemdelar

Den utökade användarhanteringen:

• ändrar inte befintliga autentiseringsflöden (SSO, BankID, Skolfederation m.m.),
• ändrar inte hur roller och behörigheter hämtas från andra system – den påverkar endast vilka användarkonton som finns och hur de är aggregerade,
• inför inga nya externa API:er mot källsystem; befintliga integrationsgränssnitt återanvänds, främst för läsning.

När ett konto raderas eller spärras kan det påverka:

• hur andra Vklass‑integrationer ser användaren (t.ex. om det finns kopplingar till externa lärplattformar eller dokumenttjänster via Vklass),
• hur data exponeras vidare via eventuella rapport‑ eller exportfunktioner i Vklass.

Grundprincipen är dock att alla sådana förändringar är en följd av att kontot eller relationen inte längre finns i Vklass – inte av att den utökade användarhanteringen direkt manipulerar andra integrationer.

Felhantering och robusthet

För att säkerställa korrekta beslut vid radering och spärrning gäller:

• Vid fel i synkronisering eller integrationslager:
  • pausas automatiskt alla slutliga raderingar som är beroende av aktuell synkin

Påverkan på synkronisering och importlogik

Den utökade användarhanteringen bygger vidare på befintlig synkronisering mot elev‑, personal‑ och vårdnadshavarregister, men inför ett antal nya kontroller och tillstånd som påverkar hur inläsning och uppdatering av konton sker i Vklass. Grundprincipen är att:

• källsystemen fortsätter att vara ”ägare” av grunddatan,
• Vklass fortsätter att läsa in samma typer av poster som idag,
• men den inkommande datan tolkas genom ytterligare lager av logik för karens (radering) och spärrar (blockering av inläsning).

Ingen skrivning tillbaka till verksamhetssystemen införs; alla förändringar sker i Vklass interna tolkning av importen.

1. Övergripande förändringar i inläsningslogiken

För varje synkroniseringskörning mot verksamhetssystemet kompletteras befintlig importlogik med:

• kontroll mot spärrlista (kontospärrar och relationsspärrar),
• uppdatering av karensposter (DeletionPending) för konton som är markerade för radering,
• särskilda säkerhetsregler kring när en radering får genomföras.

I övrigt ska matchningsreglerna (t.ex. hur personnummer/ID eller ExternalId används för att hitta befintliga användare) kunna vara oförändrade.

2. Spärrlista som filter i importen

En ny central del är att synkroniseringsmotorn alltid måste kontrollera inkommande data mot spärrlistan innan konton eller relationer skapas eller uppdateras:

• För varje personpost i synkunderlaget kontrolleras om det finns en aktiv kontospärr (AccountBlock) för motsvarande identitet i aktuell organisation.

  • Om ja: posten importeras inte som nytt eller uppdaterat konto. Eventuell befintlig användare skapas inte om/återaktiveras inte utifrån denna synkpost.
  • Om nej: posten hanteras enligt befintlig importlogik (skapa/uppdatera användarkonto).

• För varje vårdnadshavare–barn‑relation i underlaget kontrolleras om det finns en aktiv relationsspärr (GuardianChildRelationBlock) för kombinationen vårdnadshavare–barn.

  • Om ja: just denna relation skapas/uppdateras inte i Vklass, oavsett att den finns i källsystemet.
  • Om nej: relationen hanteras enligt ordinarie synklogik.

Denna filtrering behöver vara effektiv (t.ex. indexerad databas, cache eller liknande) eftersom den sker för varje post i synkroniseringen. Importlogiken behöver också kunna logga eller räkna hur många poster som ignorerats p.g.a. spärr, för felsökning och uppföljning.

3. Uppdatering av karensposter vid varje synkronisering

För konton som är markerade för radering (d.v.s. där en DeletionPending‑post finns) använder importlogiken synkunderlaget för att avgöra om och när kontot får raderas:

• När en synkronisering körs kontrolleras för varje konto i karenslista om identiteten förekommer i underlaget.
  • Om kontot förekommer:
    • fältet ”senast sedd i synk” (LastSeenInSyncAt) uppdateras till aktuell tidpunkt,
    • karenstidsklockan (48 timmar utan förekomst) nollställs,
    • status sätts till ”i karens – förekommer i synkronisering”.
  • Om kontot inte förekommer:
    • och detta är första gången efter markeringen: karenstiden börjar räknas från senaste kända förekomst (eller från markeringstidpunkten),
    • om frånvaron fortsätter uppdateras status till ”i karens – ingen förekomst i synkronisering” och en beräknad tid för tidigaste radering hålls uppdaterad.

Den ordinarie synklogiken för hur kontot uppdateras i övrigt ändras inte: ett konto i karens behandlas fortfarande som ett aktivt konto när det väl finns i Vklass. Skillnaden är att raderingsmotorn använder synkinformationen för att avgöra om kontot får raderas eller inte.

Dessutom gäller att:

• om en schemalagd radering är nära i tid, men aktuell synkkörning misslyckas eller uteblir, får raderingen inte genomföras förrän en lyckad synkronisering har skett och bekräftat fortsatt frånvaro i underlaget,
• importlogiken behöver kunna markera ett övergripande ”synkhälsotillstånd” som raderingslogiken beaktar (t.ex. flagga att senaste synk inte var giltig).

4. Kontroll mot synkunderlag vid direkt radering

Direkt radering kräver en explicit teknisk kontroll mot verksamhetssystemet/synkunderlaget, även om ingen ny full synkkörning görs just i samma ögonblick:

• Vid initiering av direkt radering måste integrationslagret kunna svara på om den aktuella identiteten (personnummer/ID/ExternalId) fortfarande finns i källsystemets data för organisationen.
  Detta kan lösas genom:

  • att läsa från en aktuell, sparad snapshot av senaste synkunderlag, eller
  • att göra ett riktat API‑anrop mot källsystemet eller synkkomponenten.

• Om kontrollen visar att personen finns kvar:

  • får importlogiken inte tillåta radering, utan ska returnera ett tydligt resultat till raderingsflödet (”användaren finns fortfarande i synkunderlaget”).

• Om kontrollen visar att personen är borttagen ur underlaget:

  • kan raderingen tillåtas ur synk‑perspektiv.

Detta är en förstärkning av befintlig logik: Vklass kan idag ofta se vad som kommer in, men här blir det ett krav att kunna göra uppslag för enskilda identiteter som del av raderingsflödet.

5. Samspel med sammanslagning av konton

Sammanslagning av konton är en intern åtgärd i Vklass, men den förändrar förutsättningarna för framtida import:

• Efter sammanslagning ska det ”kvarvarande” kontot (målkontot) vara det som synken fortsätter att uppdatera. Det innebär i praktiken att:

  • målkontots identitet (personnummer/ID, ExternalId) bör överensstämma med hur källsystemet kommer att rapportera personen framåt,
  • importlogiken ska fortsätta att matcha inkommande synkposter mot målkontot, inte mot det raderade källkontot.

• Om källsystemet under en övergångsperiod rapporterar både ett ”gammalt” och ett ”nytt” ID för samma person, kan importlogiken behöva:

  • blockera det gamla ID:t via en kontospärr (så att inget nytt separat konto skapas), eller
  • explicit mappa det gamla ID:t till målkontot om integrationslösningen stödjer sådan konfiguration.

I praktiken innebär det att befintlig matching‑logik (”hitta konto baserat på ID”) kan behöva kompletteras med:

• kontroll av om ett inkommande ID finns med i spärrlistan (AccountBlock),
• konfiguration eller regelverk för hur gamla ID:n ska hanteras efter sammanslagning.

Själva sammanslagningsfunktionen ställer dock inga krav på ändring av importformat eller API:er, bara på hur inkommande data tolkas.

6. Effekter på importloggar och felsökning

För att stödja felsökning och uppföljning behöver importflödet logiskt kunna skilja på:

• poster som inte läses in för att:
  • de är spärrade (konto- eller relationsspärr), eller
  • de matchar ett konto i karens (där karenstiden pågår), jämfört med
• vanliga avvikelser (t.ex. valideringsfel, saknad obligatorisk data).

Det innebär typiskt att:

• importloggar bör kunna indikera att en post ”ignorerades p.g.a. spärr” (utan att logga fulla personuppgifter, i linje med övriga dataminimeringsregler),
• det ska vara möjligt för Vklass support och, i viss mån, org‑admin att se om ”användaren finns i synkunderlaget men skapas inte i Vklass p.g.a. spärr”.

7. Ingen förändring av källsystemens ansvar

Slutligen påverkar den nya logiken inte hur källsystemen skapar, uppdaterar eller gallrar sina poster:

• elev‑, personal‑ och vårdnadshavarregister fortsätter att leverera samma typ av data som tidigare,
• inga nya krav införs på att källsystemen måste markera t.ex. ”ska inte läsas in i Vklass”.

Istället är det Vklass importlogik som, med hjälp av karensposter och spärrlistor, avgör om en viss post från källsystemet ska omsättas till ett konto eller en relation i Vklass, eller ignoreras. Detta ger organisationen större kontroll på Vklass‑sidan utan att behöva förändra befintliga register eller integrationsformat.

Kontroll av förekomst i verksamhetssystem

För att säkerställa att Vklass inte raderar eller permanent blockerar konton som fortfarande ska finnas enligt bakomliggande verksamhetssystem (elev-, personal- och vårdnadshavarregister) görs alltid en kontroll av förekomst i källsystemen som en del av raderings‑ och (i viss mån) spärrflödena. Kontrollen är strikt läsande – inga uppdateringar görs tillbaka till källsystemen.

Systemet använder samma identitetsnycklar som synkroniseringen:

• personnummer/ID (inkl. TF‑nummer eller annat alternativt ID), och/eller
• externt ID (t.ex. elev‑ID/personal‑ID) beroende på integration.

Dessa används för uppslag mot den data som används vid synkronisering från t.ex. Edlevo, Extens, Procapita, Alvis eller andra källsystem.

Kontroll före radering med karenstid

Vid radering med karenstid sker kontrollen mot verksamhetssystemen i två led:

1. Löpande kontroll via synkronisering under karenstiden

   • När ett konto markeras för radering skapas en karenspost som kopplas till kontots identitet.
   • Vid varje synkroniseringskörning (från elev-, personal- och vårdnadshavarregister) kontrollerar Vklass om personen förekommer i synkroniseringsunderlaget:
     • Om personen finns med: fältet ”senast sedd i synk” uppdateras och karenstiden (48 timmar) börjar om från denna tidpunkt.
     • Om personen inte finns med: karenstiden räknas vidare utan att nollställas.
   • På så sätt används den ordinarie synkroniseringen som löpande indikation på om kontot fortfarande ”ägs” av källsystemet.

2. Slutlig kontroll innan faktisk radering

   • När systemet ser att personen inte förekommit i synkroniseringsunderlaget under minst 48 sammanhängande timmar markeras kontot som ”redo för radering”.
   • Innan själva raderingen genomförs görs en sista obligatorisk kontroll mot verksamhetssystemet/senaste synkroniseringsunderlaget:
     • Vklass verifierar att personen fortfarande inte finns med i aktuell data från källsystemen (baserat på personnummer/ID/externt ID).
     • Om personen trots allt finns kvar i underlaget stoppas raderingen, karenstiden nollställs från senaste förekomst och kontot ligger kvar i karenslistan.
     • Om personen inte förekommer bekräftas att källsystemen inte längre ”begär” att kontot ska finnas i Vklass, och raderingen får genomföras.

Ingen slutlig radering via karensflödet får ske utan att denna slutliga kontroll passerats utan anmärkning.

Kontroll före direkt radering

Direkt radering är ett undantagsflöde där kontot tas bort utan karenstid, och ställer därför ännu högre krav på kontroll mot verksamhetssystemen.

När org‑admin initierar direkt radering:

• Vklass gör ett riktat uppslag mot den data som används för synkronisering (snapshot av senaste underlag och/eller dedikerat integrations‑API) med kontots identitet (personnummer/ID/externt ID).
• Resultatet tolkas så här:
  • Förekomst hittas
    – Personen finns fortfarande som elev, personal eller vårdnadshavare i källsystemet.
    – Direkt radering får inte genomföras. Systemet avbryter åtgärden och informerar org‑admin om att kontot fortfarande kommer in via synkronisering och därför först måste avslutas eller ändras i källsystemet (eller hanteras via spärrfunktion).
  • Ingen förekomst hittas
    – Personen finns inte längre i synkunderlaget för organisationen.
    – Direkt radering kan tillåtas ur integrationsperspektiv, förutsatt att övriga villkor (bekräftelse från org‑admin m.m.) är uppfyllda.

Om den tekniska kontrollen mot verksamhetssystemet inte kan genomföras (t.ex. p.g.a. integrationsfel eller otillgängligt underlag) ska ingen direkt radering tillåtas. Org‑admin får då ett felmeddelande och måste vänta tills kontrollen kan utföras.

Kontroll i relation till spärr (spärrlista)

Vid skapande av spärrposter (kontospärr eller relationsspärr) används kontroll av förekomst i verksamhetssystem främst informativt, inte som ett absolut krav:

• När org‑admin lägger en kontospärr (hel person) eller en relationsspärr (vårdnadshavare–barn) kan Vklass:
  • slå upp om personen/relationen i dag förekommer i synkunderlaget, och
  • visa detta för org‑admin (t.ex. ”personen finns i synk” / ”personen finns inte i synk”).
• Själva spärren kan dock skapas oavsett:
  • Om personen/relationen finns i synk innebär spärren att kommande synkkörningar ignorerar dessa data och inte skapar/återaktiverar kontot eller relationen.
  • Om personen/relationen inte finns i synk får spärren en ”framtidseffekt”: om samma identitet senare dyker upp i källsystemet blockeras inläsning i Vklass.

Kontroll av förekomst används alltså här för att stödja org‑admin i att förstå nuläget, men spärrfunktionen är medvetet mer frikopplad från källsystemet än raderingsflödena; poängen är att kunna förhindra framtida inläsning även när källsystemet inte är ändrat.

Konton utan koppling till verksamhetssystem

För konton utan koppling till synkroniseringen (t.ex. manuellt skapade konton, konton med lokala eller tillfälliga ID:n):

• Uppslag mot verksamhetssystemen kommer normalt inte att hitta någon motsvarande post.
• Vid radering tolkas detta som att det inte finns något källsystem som ”äger” kontot:
  • karensflödet kan ändå användas, men raderingsvillkoret om ”48 timmar utan förekomst i synk” uppfylls omedelbart eftersom personen aldrig förekommer i underlaget,
  • direkt radering kan tillåtas efter bekräftelse, eftersom ingen risk finns att kontot automatiskt återskapas via synk.
• Vid spärrning kan en spärrpost ändå skapas på identiteten, för att förhindra att samma identitet eventuellt läses in från källsystemen i framtiden.

Felhantering och säkerhetsprincip

Kontrollen av förekomst i verksamhetssystem följer principen ”hellre inte radera än radera fel”:

• Om synkronisering eller integrationskontroller inte kan genomföras på ett tillförlitligt sätt:
  • pausas alla slutliga raderingar som kräver aktuell synkinformation,
  • direkt radering tillåts inte,
  • karenslistan ska tydligt visa att raderingar är stoppade i väntan på fungerande synk/uppslag.
• Spärrar kan i normalfallet fortfarande läggas och hävas (de påverkar hur framtida, fungerande synkroniseringar tolkas), men org‑admin ser inte alltid om personen/relationen finns i källsystemet just nu.

Genom dessa kontroller säkerställs att Vklass inte raderar användarkonton i strid med den data som verksamhetssystemen levererar, samtidigt som org‑admin fortfarande kan använda spärrlistan för att styra vilka personer och relationer som får läsas in, även när källdata ännu inte är ändrad.

Felhantering och återställning

Felhantering och återställning i den utökade användarhanteringen utgår från principerna transaktionssäkerhet, tydlig återkoppling till org‑admin, minimal risk för delvis genomförda åtgärder samt spårbar loggning med dataminimering. Funktionen ska inte lämna systemet i inkonsistenta mellanlägen och ska, där det är möjligt, göra det möjligt att på ett kontrollerat sätt återställa önskat läge genom ordinarie verktyg (t.ex. ny synkronisering, ny sammanslagning eller manuella åtgärder).

Generella principer

• Alla kritiska åtgärder (radering, direkt radering, sammanslagning, skapande/hävning av spärr) ska behandlas som atomära transaktioner:
  • Antingen genomförs hela åtgärden, eller så genomförs ingen del.
  • Systemet ska inte lämna kvar ett konto i ett delvis ändrat läge (t.ex. halvt sammanslaget eller delvis raderat).
• Om en transaktion misslyckas:
  • ska systemet rulla tillbaka alla ändringar som påbörjats inom åtgärden,
  • ska det ursprungliga dataläget återställas så långt det är tekniskt möjligt,
  • ska org‑admin få ett tydligt felmeddelande om att åtgärden inte genomfördes och behöver göras om.
• Alla fel som rör dessa åtgärder ska loggas på ett sätt som möjliggör teknisk felsökning utan att lagra fler personuppgifter än nödvändigt.

Fel vid radering (med karenstid och direkt radering)

Fel vid initiering av radering (markera för radering)

• Om ett fel uppstår när ett konto ska markeras för radering (t.ex. databasfel vid skapande av karenspost):
  • ska ingen karenspost skapas,
  • ska kontot fortsatt betraktas som ett vanligt aktivt konto,
  • ska org‑admin få ett meddelande om att markeringen misslyckades och att åtgärden behöver upprepas.
• Delvis skapade karensposter (t.ex. skapade utan fullständig koppling till kontot) får inte kvarstå; transaktionen ska rullas tillbaka helt.

Fel under karenstid

• Fel i synkronisering (t.ex. misslyckad import, avbruten körning) ska inte leda till oavsiktlig radering:
  • om senaste synkronisering inte kan anses giltig ska ingen radering triggas, även om karenstiden tidsmässigt skulle vara uppfylld,
  • karensstatus kan markeras som pausad i väntan på nästa lyckade synkronisering.
• Om uppdatering av karensposter i samband med synkronisering misslyckas (t.ex. att ”senast sedd i synk” inte kan sparas):
  • ska raderingsmotorn anta ett försiktigt läge (inte radera),
  • ska kontot ligga kvar i karenslistan tills nästa lyckade synkronisering och uppdatering kan göras.

Fel vid slutlig radering efter karens

• När slutlig radering ska genomföras (alla villkor uppfyllda) ska själva raderingen ske som en atomär transaktion:
  • Om raderingen lyckas:
    • tas användarkontot bort,
    • tas karensposten bort,
    • skapas en åtgärdsloggpost.
  • Om raderingen misslyckas (t.ex. databasfel, beroenden som inte kan raderas):
    • ska transaktionen rullas tillbaka så att kontot finns kvar oförändrat,
    • ska karensposten finnas kvar och status indikera att raderingen inte genomförts,
    • ska org‑admin informeras om felet och att kontot inte har raderats.
• Systemet får inte ta bort karensposten om själva kontoraderingen misslyckas; annars finns risk att kontot felaktigt betraktas som raderat.

Fel vid direkt radering

• Om kontrollen mot verksamhetssystem/synkunderlag inte kan genomföras (t.ex. integrationsfel):
  • får direkt radering inte påbörjas,
  • ska inget på kontot ändras,
  • ska org‑admin få ett felmeddelande som förklarar att kontrollen inte kunde genomföras och att åtgärden behöver göras om när tekniken fungerar.
• Om raderingssteget i direkt radering misslyckas (t.ex. databasfel under själva borttagningen):
  • ska transaktionen rullas tillbaka så att kontot och dess kopplingar förblir intakta,
  • ska ingen spärrpost (om sådan valts samtidigt) skapas,
  • ska org‑admin informeras om att ingen radering genomfördes.
• Om kontot redan raderats av en annan process eller org‑admin när direkt radering initieras:
  • ska systemet upptäcka att kontot inte längre finns,
  • ska ingen ny åtgärd genomföras,
  • ska ett informativt meddelande visas (t.ex. ”Kontot är redan raderat eller inte längre tillgängligt”).

Fel vid ångra planerad radering

• Om ett fel uppstår när org‑admin ångrar en planerad radering:
  • ska systemet inte lämna kontot i ett oklart läge (t.ex. delvis ångrat),
  • antingen:
    • kvarstår karensposten oförändrad (raderingen fortsätter vara planerad), eller
    • tas karensposten bort fullständigt (raderingen är helt ångrad),
  • men aldrig ett mellanläge där karensposten är delvis uppdaterad.
• Vid samtidiga åtgärder (t.ex. två org‑admin försöker hantera samma konto):
  • ska endast den första lyckade transaktionen slå igenom,
  • den andra ska få ett fel-/informationsmeddelande om att kontots status har ändrats under tiden och att åtgärden behöver göras om utifrån aktuellt läge.

Fel vid sammanslagning av konton

Sammanslagning är en komplex åtgärd som kan beröra många tabeller (kopplingar, historik). Felhantering ska därför säkerställa att:

• hela sammanslagningen är en atomär transaktion:
  • Om sammanslagningen lyckas:
    • är målkontot uppdaterat med alla överförda kopplingar/data,
    • är källkontot avslutat som separat konto,
    • skapas en åtgärdsloggpost.
  • Om något steg misslyckas (t.ex. att vissa kopplingar inte kan flyttas):
    • ska alla ändringar rullas tillbaka,
    • ska både målkonto och källkonto vara oförändrade jämfört med läget innan sammanslagningen,
    • ska ingen delvis sammanslagen struktur förekomma.
• Om det inte går att uppfylla atomaritetskravet (t.ex. p.g.a. tekniska begränsningar för vissa historiktyper) ska dessa undantag dokumenteras tekniskt och antingen:
  • blockera sammanslagning i den specifika situationen (med tydligt felmeddelande), eller
  • genomföra sammanslagning utan att de berörda specialobjekten flyttas (men utan att förstöra befintlig data på något av kontona).

Vid fel vid sammanslagning:

• ska ingen ny synk‑ eller spärrlogik automatiskt aktiveras,
• ska org‑admin informeras om att sammanslagningen inte genomförts,
• kan org‑admin vid behov:
  • försöka igen efter tekniskt åtgärdat fel, eller
  • välja andra åtgärder (t.ex. radering eller manuell korrigering via ordinarie funktioner).

Fel vid skapande och hävning av spärrar

Skapande av spärr

• Om ett fel uppstår när en spärrpost skapas (t.ex. databasfel):
  • ska ingen spärrpost sparas delvis,
  • ska synkroniseringen fortsätta fungera som tidigare (utan extra blockering),
  • ska org‑admin få besked om att spärren inte skapats.
• Om en spärr försöker skapas för en identitet/relation som redan har en aktiv spärr:
  • ska systemet antingen:
    • neka åtgärden med information om att spärr redan finns, eller
    • återanvända befintlig spärr och informera om detta,
  • men inte skapa duplicerade spärrposter.

Hävning (inaktivering) av spärr

• Om ett fel uppstår vid hävning av spärr:
  • ska spärren fortsätta vara aktiv tills en fullständig inaktivering lyckas,
  • får inga mellantillstånd förekomma där spärren delvis gäller,
  • ska org‑admin informeras om att spärren inte kunde hävas och behöver hanteras på nytt.
• Vid samtidiga åtgärder (t.ex. två org‑admin försöker häva samma spärr):
  • ska endast den första lyckade transaktionen slå igenom,
  • den andra ska få besked om att spärren redan är ändrad.

Fel kopplade till synkronisering och integration

Eftersom radering och spärrar är beroende av korrekt information från verksamhetssystemen är fel i integrationer särskilt känsliga.

• Om en synkkörning misslyckas eller underlaget bedöms ogiltigt:
  • ska systemet inte:
    • markera konton som frånvarande i synk,
    • ta beslut om att radera konton baserat på denna körning.
  • karensstatus kan indikera ”tillfälligt stoppad – avvaktar lyckad synk”.
• Om ett riktat uppslag inför direkt radering eller informationsvisning misslyckas:
  • ska ingen radering genomföras,
  • ska ingen feldiagnos lagras som personuppgift (endast teknisk felinformation),
  • ska org‑admin få ett neutralt felmeddelande om att kontroll mot källsystem inte kunde genomföras.

När integrationer fungerar igen:

• ska systemet automatiskt kunna fortsätta:
  • uppdatera karensposter utifrån ny synk,
  • genomföra raderingar som uppfyller villkoren,
  • tillämpa spärrar på inkommande data.

Loggning av fel och åtgärder

Alla betydelsefulla fel och avbrutna åtgärder i den utökade användarhanteringen ska loggas i åtgärdsloggen eller i tekniska loggar på ett sätt som gör det möjligt att:

• i efterhand se att en viss åtgärd inte genomfördes (t.ex. ”direkt radering avbruten – användare kvar i synk”, ”radering efter karens avbruten – tekniskt fel”),
• koppla felet till:
  • tidpunkt,
  • ansvarig org‑admin (om felet uppstod vid en initierad åtgärd),
  • typ av åtgärd,
  • berört konto (med dataminimerad identifiering, t.ex. endast sex första siffror i personnummer/ID + förnamn + skola/enhet efter radering).
• skilja på:
  • användningsfel (t.ex. försök att radera konto som fortfarande finns i källsystemet),
  • tekniska fel (t.ex. integrationsfel, databaskonflikter).

Åtgärdsloggarna:

• sparas endast under den fastställda korta perioden (t.ex. 30 dagar),
• innehåller aldrig mer personuppgifter än vad som är definierat i logg‑ och dataminimeringskraven,
• kan användas av Vklass support och organisationens företrädare (org‑admin) för att förstå varför en åtgärd inte genomfördes och vid behov upprepa den när fel är åtgärdade.

Tekniska, icke‑personliga loggar (system- och fel-loggar på servernivå) kan lagra mer detaljerad information om själva felet för felsökningssyfte, men ska inte användas för att bygga upp separata personregister utan begränsas enligt Vklass generella rutiner för loggning och drift.

Återställning efter fel

Funktionen erbjuder inte automatiska ”ångra”‑flöden

Notifieringar och kvittenser till administratör

All återkoppling i funktionen ges inne i adminverktyget och riktar sig enbart till organisationsadministratörer. Inga e‑postmeddelanden, pushnotiser eller andra externa notifieringar skickas varken till administratörer eller till berörda användare; all information visas som dialoger, statusfält och meddelanderader i gränssnittet.

När org‑admin initierar en åtgärd som kan förändra konton eller relationer (t.ex. markera för radering, genomföra direkt radering, slå ihop konton, skapa/häva spärr) visas alltid en tydlig bekräftelsedialog. Dialogen:

• summerar vilken användare/relation åtgärden gäller (namn, ID, skola m.m.),
• beskriver konsekvenserna på en kort, neutral nivå (t.ex. att kontot kommer att raderas eller att en spärr kommer att hindra inläsning via synkronisering),
• kräver ett aktivt val av administratören (t.ex. klick på ”Bekräfta”/”Radera”/”Slå ihop”) för att åtgärden ska genomföras.

För särskilt ingripande åtgärder, som direkt radering eller sammanslagning av konton, ska dialogen dessutom innehålla en extra varningstext och ett krav på uttrycklig bekräftelse (t.ex. kryssruta ”Jag bekräftar att åtgärden inte kan ångras”).

Efter en genomförd åtgärd ska administratören få en direkt kvittens i gränssnittet, exempelvis i form av:

• en kort informationsrad eller banner (”Kontot har markerats för radering”, ”Direkt radering genomförd”, ”Sammanslagning slutförd”, ”Spärr skapad/hävd”), och
• uppdaterad status i relevanta listor och vyer (sökresultat, karenslista, spärrlista) utan att sidan behöver laddas om manuellt.

Om en åtgärd inte kan genomföras ska systemet alltid visa ett fel‑ eller informationsmeddelande som:

• tydligt anger att åtgärden avbrutits och ingen förändring gjorts (t.ex. ”Kontot kunde inte raderas eftersom det fortfarande förekommer i synkroniseringsunderlaget” eller ”Tekniskt fel – åtgärden har inte genomförts”),
• i möjligaste mån skiljer på verksamhetsorsaker (t.ex. fortsatt förekomst i källsystem) och tekniska orsaker (t.ex. misslyckad synkronisering, integrationsfel),
• inte exponerar mer personuppgifter än nödvändigt, utan hänvisar till den användare som redan är vald i vyn.

Status‑ och översiktsvyer fungerar också som en form av kvittens:

• Karenslistan visar löpande om ett konto är markerat för radering, när karensen startade, när användaren senast syntes i synkroniseringen och om/varför radering ännu inte genomförts.
• Spärrlistan visar vilka konton och relationer som är spärrade, när spärren skapades och om den är aktiv eller hävd.
• Sök‑ och detaljvyer för användare uppdateras så att det framgår om kontot är aktivt, markerat för radering eller påverkat av spärr.

Själva åtgärdsloggen fungerar inte som en notifiering, men ger vid behov org‑admin möjlighet att i efterhand verifiera att en åtgärd har genomförts (eller avbrutits) vid en viss tidpunkt och av en viss administratör, med begränsad personuppgiftsnivå.

Användargränssnitt – navigation

Organisationsadministratören når all funktionalitet för den utökade användarhanteringen via Vklass Admin (V2‑gränssnittet). Funktionerna samlas i en egen vy så att radering, sammanslagning och spärrning av konton hanteras på ett ställe.

Grundprinciper för navigation:

• Menyalternativet är endast synligt för användare med rollen Organisationsadministratör.
• Skoladministratörer och andra roller ser inte menyn och kan inte nå funktionen via direktlänk.
• Funktionens namn i gränssnittet är generellt (t.ex. ”Utökad användarhantering”) och refererar inte till skyddad identitet.

Huvudväg in via huvudmenyn

1. Org‑admin loggar in i Vklass Admin (V2‑gränssnittet) med de autentiseringsmetoder som organisationen använder (t.ex. SSO, BankID, Freja eID).

2. I den vänstra huvudmenyn väljer org‑admin:

   • Användare
   • därefter undermenyn Utökad användarhantering

   (Alternativ benämning om menustrukturen kräver det: t.ex. Adminverktyg → Användare → Utökad användarhantering. Den exakta placeringen kan anpassas till Vklass standard för V2, men ska ligga under användar-/organisationsnivån, inte per skola.)

3. När org‑admin öppnar Utökad användarhantering visas en huvudsida med flikar eller delvyer, t.ex.:

   • Sök & åtgärda – sök fram enskilda konton och initiera:
     • radering (med karenstid eller direkt),
     • sammanslagning,
     • spärr av konto eller specifik vårdnadshavare–barn‑relation.
   • Karenslista – översikt över alla konton som är markerade för radering med 48 timmars karens, inklusive möjlighet att:
     • se status mot synkroniseringen,
     • ångra radering,
     • växla till direkt radering (om villkoren uppfylls).
   • Spärrlista – översikt över:
     • konton som är spärrade från inläsning (kontospärr),
     • spärrade relationer vårdnadshavare–barn,
     • möjlighet att skapa/häva spärrar.
   • (Eventuellt) Sammanslagning som egen flik om man vill skilja det flödet tydligt från övriga åtgärder.

Org‑admin kan växla mellan dessa delvyer via flikrad eller sidomeny inom funktionen utan att lämna ”Utökad användarhantering”.

Snabbväg från befintliga användarvyer

För att underlätta arbetet kan det finnas genvägar från de vanliga användarvyerna i Skoladmin/Användare:

• När org‑admin har sökt fram en användare under t.ex. Skoladmin → Användare → [Elever/Personal/Vårdnadshavare] och öppnat personens profil kan en länk eller knapp visas, t.ex.:
  • ”Öppna i utökad användarhantering”.
• När org‑admin klickar på länken:
  • öppnas vyn Utökad användarhantering → Sök & åtgärda,
  • den aktuella personen är redan förvald eller förifylld i sökfältet,
  • org‑admin kan direkt välja åtgärd (radera, slå ihop, spärra).

Denna snabbväg ska endast visas för användare som både:

• har rollen org‑admin, och
• tillhör samma organisation som användaren i profilen.

Direktlänkar och behörighetskontroll

• Alla direkta URL:er till vyer inom Utökad användarhantering (t.ex. djup­länkar till ett specifikt konto i karenslistan eller en viss spärrpost) ska alltid göra en behörighetskontroll:
  • om den inloggade användaren inte är org‑admin, eller inte tillhör rätt organisation, ska åtkomst nekas och vyn inte laddas.
• Detta gäller både:
  • huvudvyn för Utökad användarhantering,
  • underflikar som Karenslista, Spärrlista och sammanslagningsvyer.

På så sätt är navigationen konsekvent: org‑admin når funktionaliteten via huvudmenyn i Vklass Admin och kan sedan arbeta med sök, karenslista, spärrlista och sammanslagning i en sammanhållen vy, medan andra roller inte exponeras för dessa delar av systemet.

Användargränssnitt – listor och filter

Samtliga listor i den utökade användarhanteringen följer samma grundprinciper: tydlig tabellvy, konsekventa kolumnrubriker, gemensam filterpanel och visuell indikation på status (aktiv, markerad för radering, spärrad m.m.). Alla listor är endast åtkomliga för org‑admin och visar aldrig mer personuppgifter än vad org‑admin redan har behörighet till i övrig administration.

Gemensamma principer för listor

• Listor visas som tabeller med paginering (t.ex. 25–50 rader per sida).
• Kolumnrubriker är klickbara för sortering (stigande/fallande) på minst:
  • Namn,
  • Personnummer/ID (där det visas),
  • Skola/enhet,
  • Status,
  • Datumfält (t.ex. markerad för radering, spärr skapad).
• Ovanför tabellen finns en filterpanel med:
  • fritextfält (namn/personnummer/ID),
  • rullistor/multival för roll, skola/enhet, status,
  • eventuell specialfiltrering (t.ex. ”Visa endast konton i karens”).
• Filter kombineras logiskt med OCH (t.ex. ”vårdnadshavare” OCH ”Skola X” OCH ”i karens”).
• Tomma resultat visas med en neutral tomt‑läge‑text (t.ex. ”Inga poster matchar dina filter”) och länk/knapp för att rensa filter.
• Listorna uppdateras direkt när filter ändras eller sökning görs (ingen separat ”Sök”‑knapp krävs, om inte prestanda kräver det).

Lista: Sök & åtgärda (användarlista)

Detta är standardlistan som visas efter en sökning i fliken ”Sök & åtgärda”. Den används som startpunkt för radering, sammanslagning och spärrning.

Kolumner

Minst följande kolumner visas:

• Namn – förnamn + efternamn.
• Personnummer/ID – fullständigt enligt org‑admins vanliga rättigheter (inkl. TF‑nummer eller annat ID).
• Roll(er) – ikon eller etikett(er) för elev/barn, personal, vårdnadshavare.
• Skola/enhet – primär enhet, med möjlighet att expandera för fler vid behov.
• Klass/grupp – primär klass för elev/barn (om finns).
• Status (utökad användarhantering) – t.ex.:
  • Aktiv,
  • Markerad för radering (i karens),
  • Spärrad från inläsning (konto),
  • Har spärrade relationer (t.ex. vårdnadshavare–barn).
• Åtgärder – ikoner/knappar per rad, t.ex.:
  • ”Öppna detaljvy”,
  • ”Markera för radering”,
  • ”Direkt radering”,
  • ”Sammanslå med annat konto”,
  • ”Hantera spärr”.

Filter och sökparametrar

Filterpanelen över listan ska minst stödja:

• Fritext:
  • Sök på namn (för‑ och/eller efternamn),
  • Personnummer/ID (helt eller delar; vid exakt träff kan personen markeras direkt).
• Roll:
  • Elev/barn,
  • Personal,
  • Vårdnadshavare,
  • Flera roller kan väljas samtidigt.
• Skola/enhet:
  • En eller flera enheter inom organisationen.
• Klass/grupp (för elev/barn):
  • Nedrullningslista baserad på vald skola, eller fristående sökbar lista.
• Status:
  • Aktiv (ingen karens, ingen spärr),
  • Markerad för radering,
  • Spärrat konto,
  • Har spärrad relation (t.ex. vårdnadshavare–barn).

Filtersammansättning ska göra det möjligt att snabbt hitta t.ex.:

• ”Alla vårdnadshavare på Skola A med spärrade relationer”,
• ”Alla personal med kontospärr”,
• ”Alla elever i klass 9B som är markerade för radering”.

Från listan kan enstaka rader väljas för åtgärd; massåtgärder (flera rader samtidigt) kan införas senare men är inte ett krav här.

Lista: Karenslista (konton markerade för radering)

Karenslistan är en specialvy som visar alla konton med aktiv karenspost (DeletionPending). Den används för översikt, statuskontroll och åtgärder som ”Ångra radering” eller ”Initiera direkt radering”.

Kolumner

Minst följande kolumner visas:

• Namn.

• Personnummer/ID – fullständigt, enligt ordinarie org‑admin‑behörighet (kontot är ännu inte raderat).

• Roll(er).

• Skola/enhet – primär skola/enhet.

• Klass/grupp – för elev/barn.

• Markerad för radering – datum/tid (MarkedAt).

• Senast sedd i synk – datum/tid (LastSeenInSyncAt), eller tydlig markering om användaren inte setts sedan markering.

• Tidigaste möjliga radering – beräknat datum/tid (EarliestDeletionAt), om karenstid är påbörjad.

• Status – kort, begriplig text baserad på statuskoder, t.ex.:

  • ”I karens – förekommer i synkronisering”,
  • ”I karens – ingen förekomst i synkronisering (X timmar kvar)”,
  • ”Redo för radering – väntar på slutlig kontroll”,
  • ”Pausad – väntar på lyckad synkronisering”.

• Åtgärder – per rad, t.ex.:

  • ”Visa detaljer” (öppnar användarens detaljvy),
  • ”Ångra radering”,
  • ”Initiera direkt radering” (om funktionen är tillåten och tekniska krav uppfylls).

Filter

Filterpanelen ska minst stödja:

• Fritext:
  • namn,
  • personnummer/ID.
• Roll:
  • elev/barn,
  • personal,
  • vårdnadshavare.
• Skola/enhet.
• Status:
  • I karens – förekommer i synkronisering,
  • I karens – ingen förekomst i synkronisering,
  • Redo för radering,
  • Pausad p.g.a. synkfel.

Sorteringsmöjligheter är särskilt viktiga här, t.ex.:

• sortera på ”Markerad för radering” (äldst → nyast),
• sortera på ”Tidigaste möjliga radering” (näst på tur överst),
• sortera på ”Senast sedd i synk” (för att se vilka som fortfarande ligger kvar i källsystemet).

På detta sätt får org‑admin ett arbetsbord för raderingsärenden, med tydlig överblick och möjlighet att prioritera vilka konton som behöver granskas eller ångras.

Lista: Spärrlista (konton och relationer spärrade från inläsning)

Spärrlistan visar alla aktiva spärrposter (BlockEntry) inom organisationen, både kontospärrar och relationsspärrar. Här hanterar org‑admin vilka konton/relatoner som är blockerade från att läsas in från verksamhetssystemet.

Kolumner

För kontospärrar (AccountBlock):

• Typ – ikon eller text som visar att det är en kontospärr (t.ex. ”Konto”).
• Namn – förnamn + efternamn (om finns).
• Personnummer/ID – endast de sex första siffrorna/tecknen (ååmmdd‑del eller motsvarande prefix).
• Skola/enhet – primär skola/enhet om tillgänglig.
• Roll(er) – om känt (t.ex. elev/barn, personal, vårdnadshavare).
• Skapad datum/tid.
• Skapad av (org‑admin).
• Status – Aktiv / Inaktiv (filtreras normalt så att endast aktiva visas som standard).
• Åtgärd – t.ex.:
  • ”Visa detaljer”,
  • ”Häv spärr”.

För relationsspärrar (GuardianChildRelationBlock):

• Typ – ikon eller text som visar att det är en relationsspärr (t.ex. ”Relation vårdnadshavare–barn”).
• Vårdnadshavare – förnamn + eventuell efternamn, sex första siffror i personnummer/ID.
• Barn – namn (för‑ och efternamn), skola/enhet, ev. klass.
• Skapad datum/tid.
• Skapad av.
• Status – Aktiv / Inaktiv.
• Åtgärd – t.ex.:
  • ”Visa detaljer” (visar både vårdnadshavare och barn samt relationens kontext),
  • ”Häv spärr”.

Filter

Filterpanelen ska minst stödja:

• Typ av spärr:
  • Konto,
  • Relation vårdnadshavare–barn.
• Fritext:
  • namn (vårdnadshavare eller barn),
  • personnummerprefix (sex första siffrorna),
  • ev. skolnamn.
• Skola/enhet:
  • filtrera på elevens/barnets skola vid relationsspärr,
  • filtrera på primär skola för kontospärr (om sådan finns).
• Skapad datumintervall – t.ex. ”spärrar skapade senaste 30 dagarna”.
• Status:
  • Aktiv (standard),
  • Inaktiv (endast vid behov, t.ex. vid historikgranskning).

Listan sorteras som standard på ”Skapad datum/tid” (nyaste överst), men ska även kunna sorteras på namn och typ.

Åtgärdslogglista (om visning för org‑admin införs)

Om åtgärdsloggen exponeras i UI (t.ex. enkel historikvy för org‑admin) ska listan följa särskilda dataminimeringsregler:

• Kolumner:
  • Tidpunkt,
  • Åtgärdstyp (t.ex. ”Markerad för radering”, ”Radering genomförd”, ”Spärr skapad”, ”Sammanslagning slutförd”),
  • Utförd av (org‑admin),
  • Identifiering av användare:
    • förnamn,
    • sex första siffror i personnummer/ID,
    • skola/enhet (snapshot).
• Filter:
  • datumintervall (standard: senaste 30 dagar),
  • åtgärdstyp,
  • utförd av,
  • fritext på namn/personnummerprefix.

Listan visar endast åtgärder inom den egna organisationen och omfattas av samma tidsbegränsning som loggarna (t.ex. max 30 dagar tillbaka).

---

Samlat ska listor och filter i den utökade användarhanteringen ge org‑admin:

• snabb navigering till rätt användare, rätt karensärende eller rätt spärr,
• god statusöverblick utan att behöva öppna varje enskild detaljvy,
• tydliga, konsekventa filter som gör det enkelt att arbeta systematiskt med radering, sammanslagning och spärrning – samtidigt som exponeringen av personuppgifter hålls inom befintliga behörighetsramar och kompletteras med dataminimering där det är möjligt (spärrlista, logglista).

Användargränssnitt – detaljerad vy

Detaljvy för användare

När org‑admin väljer en användare i fliken Sök & åtgärda (eller via genväg från annan adminvy) öppnas en detaljerad vy för kontot. Vyn är uppdelad i tydliga sektioner/paneler:

Grunduppgifter
Visar de uppgifter som behövs för säker identifiering av personen:

• Förnamn och efternamn.
• Personnummer/ID i samma detaljnivå som org‑admin normalt har tillgång till (inkl. TF‑nummer eller annat ID).
• Organisations-/systeminformation, t.ex. om kontot är synkroniserat eller manuellt skapat, och eventuellt källsystem (Edlevo, Extens m.fl.).

Inga extra känsliga uppgifter (adress, elevhälsa etc.) exponeras här utöver vad org‑admin redan kan se i den vanliga personprofilen.

Roller och kopplingar
En separat panel visar kontots roll(er) och viktigaste kopplingar:

• Roller: elev/barn, personal, vårdnadshavare (en eller flera).
• Skolor/enheter: lista över samtliga enheter kontot är kopplat till inom organisationen.
• Klasser/grupper (för elev/barn): aktuella och/eller senaste relevanta grupper (klass, undervisningsgrupp, fritidshem m.m.).
• Barnrelationer (för vårdnadshavare): lista över kopplade barn med namn, skola/enhet och klass/grupp. Härifrån kan org‑admin klicka vidare till barnets profil eller initiera åtgärder kopplade till specifik relation (t.ex. spärr av vårdnadshavare–barn).

Status i utökad användarhantering
Denna panel summerar hur kontot berörs av den utökade funktionen:

• Om kontot är:
  • Aktivt (ingen pågående radering, ingen kontospärr).
  • Markerat för radering (i karens), med länk till karensinformation.
  • Föremål för kontospärr (spärrat från inläsning).
  • Inblandat i spärrade relationer (t.ex. spärrad vårdnadshavare–barn‑koppling).
• Kortfattad text beskriver vad statusen innebär, t.ex. ”Kontot är markerat för radering och tas bort när karenstid och kontroller mot verksamhetssystem är uppfyllda” eller ”Kontot är spärrat från inläsning via synkronisering”.

Tillgängliga åtgärder
Längst ned eller i en åtgärdspanel visas de åtgärder som kan utföras på kontot, beroende på status:

• Markera för radering (om kontot inte redan ligger i karens).
• Direkt radering (om funktionstypen är aktiverad och tekniska förutsättningar finns).
• Sammanslå med annat konto (öppnar sammanslagningsflöde där detta konto förvals som A eller målkonto).
• Spärra inläsning av konto (skapa kontospärr).
• För vårdnadshavare: Hantera relationer till barn (öppnar vy för att ev. ta bort eller spärra enskilda relationer).

Knappar som inte är tillåtna för det aktuella läget (t.ex. direkt radering för konto som bevisligen fortfarande finns i synk) är inaktiverade med förklarande tooltip/text.

---

Detaljvy för karenspost (konto markerat för radering)

När org‑admin från karenslistan väljer ”Visa detaljer” för ett konto i karens öppnas en vy som kombinerar användarinformation med en tydlig bild av raderingsflödet för just detta konto.

Övre del – kontoinformation
Visar samma grunduppgifter som i den vanliga användardetaljen, så länge kontot ännu inte är raderat:

• Namn.
• Personnummer/ID.
• Roller.
• Skolor/enheter.
• Klass/grupp (för elev/barn).
• Eventuella barnrelationer (för vårdnadshavare).

Det ska vara tydligt att kontot fortfarande finns i Vklass och fungerar tills radering faktiskt genomförts.

Nedre del – raderingsstatus och tidslinje

En särskild panel visar karensspecifik information:

• Datum/tid då kontot markerades för radering.
• Senaste tidpunkt då användaren förekom i synkroniseringsunderlaget.
• Aktuell beräkning av karenstid:
  • hur lång tid som har gått utan förekomst,
  • hur lång tid som återstår till 48 timmar (om relevant),
  • tidigaste möjliga raderingstidpunkt om användaren fortsätter att inte förekomma i synk.
• Nuvarande status i textform, t.ex.:
  • ”I karens – användaren förekommer fortfarande i synkronisering, raderas inte”,
  • ”I karens – användaren har inte förekommit i synkroniseringen sedan [tidpunkt], radering kan ske tidigast [tidpunkt]”,
  • ”Redo för radering – väntar på slutlig kontroll mot verksamhetssystem”.
• Indikation på eventuella tekniska hinder:
  • t.ex. ”Radering pausad – senaste synkronisering misslyckades. Ingen radering sker förrän en lyckad synk genomförts.”

Åtgärder i karensdetaljvyn

Här finns direkt åtkomst till de karensrelaterade åtgärderna:

• Ångra radering – tar bort kontot ur karensflödet efter bekräftelse.
• Initiera direkt radering – om org‑admin vill gå från karens till omedelbar radering:
  • initierar kontroll mot verksamhetssystem,
  • är endast aktiv om direkt radering är tekniskt möjlig.
• Länk tillbaka till användarens vanliga detaljvy för ytterligare bedömning (t.ex. se fler kopplingar innan beslut).

Visningen ska ge org‑admin en tydlig förståelse för varför ett visst konto ännu inte raderats och vad som kommer att hända automatiskt respektive kräver manuell insats.

---

Detaljvy för spärrpost (konto- eller relationsspärr)

När org‑admin väljer en post i spärrlistan (kontospärr eller relationsspärr) öppnas en detaljvy som beskriver vad spärren innebär och vilket konto/vilken relation den berör.

Grundinformation om spärren

Övre delen av vyn visar metadata om spärren:

• Typ av spärr:
  • ”Spärr av konto (inläsning blockeras)”, eller
  • ”Spärr av relation vårdnadshavare–barn (inläsning blockeras)”.
• Status: Aktiv / Inaktiv (hävd).
• Skapad datum/tid.
• Skapad av (org‑admin).
• Om inaktiv: inaktiverad datum/tid och av vem.
• Kort, neutral kommentar (om sådan registrerats).

Berörd person – kontospärr

Om spärren gäller ett helt konto (AccountBlock) visas en begränsad identifikation:

• Förnamn (som vid spärrtillfället).
• Ev. efternamn (om vald presentationsnivå medger detta).
• De sex första siffrorna i personnummer/ID (ååmmdd‑prefix, aldrig de fyra sista).
• Primär skola/enhet (om kontot finns/kunnat härledas).
• Eventuellt roller (elev/barn, personal, vårdnadshavare), i den mån det är relevant och tillgängligt.

Om det fortfarande finns ett aktivt användarkonto i Vklass kopplat till spärren kan en länk visas: ”Öppna användardetalj” som leder till den ordinarie detaljvyn för kontot.

Berörd relation – relationsspärr vårdnadshavare–barn

Om spärren gäller en specifik relation visas två delpaneler:

• Vårdnadshavare

  • Förnamn (och ev. efternamn).
  • Sex första siffrorna i personnummer/ID.
  • Ev. primär skola/enhet.
  • Länk till vårdnadshavarens användardetaljvy om kontot finns.

• Barn

  • För‑ och efternamn.
  • Skola/enhet och klass/grupp.
  • Personnummer/ID i samma nivå som org‑admin normalt ser för elev/barn.
  • Länk till barnets användardetaljvy.

Under dessa paneler finns en kort text som beskriver effekten, t.ex.:
”Denna spärr gör att relationen mellan vårdnadshavaren och barnet inte skapas eller uppdateras via synkronisering, även om relationen finns kvar i verksamhetssystemet.”

Åtgärder i spärrdetaljvyn

Längst ned eller i en åtgärdspanel visas:

• Häv spärr – gör spärren inaktiv efter bekräftelse.
  • När spärren hävs visas en informationstext om att nästa synkronisering åter kan skapa/uppdatera kontot eller relationen om den finns i källsystemet.
• (Vid aktiv spärr) information om rekommenderat nästa steg, t.ex.:
  • ”Om spärren skapades i samband med radering av konto kan du nu låta synkroniseringen skapa ett nytt konto när personen åter blir aktuell i källsystemet.”

Vyn innehåller inga detaljer om bakomliggande beslut (t.ex. sociala eller juridiska skäl) utan är strikt teknisk/administrativ. All visning av personuppgifter följer kraven på dataminimering: i spärrdetaljer används högst förnamn, sex första siffror av personnummer/ID och skol-/barnkopplingar i den utsträckning som behövs för att org‑admin säkert ska kunna förstå vilken spärr som hanteras.

Bekräftelsedialoger och varningar

Bekräftelsedialoger och varningar ska ha en enhetlig utformning genom hela funktionen, så att org‑admin alltid tydligt ser:

• vilken användare/relation åtgärden gäller,
• vad som faktiskt kommer att hända om åtgärden bekräftas,
• om åtgärden går att ångra eller inte,
• om det finns särskilda risker (t.ex. att åtgärden är permanent eller beroende av synkronisering).

Gemensamt för alla dialoger är:

• Titelrad – kort, tydlig och konsekvent, t.ex. ”Markera konto för radering”, ”Radera konto direkt”, ”Slå ihop konton”, ”Spärra inläsning av konto”.
• Identifiering av berörd(a) användare/relation(er) – en liten sammanfattning högst upp i dialogen:
  • Förnamn + efternamn,
  • Personnummer/ID (enligt org‑admins ordinarie rättigheter),
  • Roll(er),
  • Skola/enhet och ev. klass (för elev/barn),
  • För vårdnadshavare–barn‑relationer: både vårdnadshavare och barn.
• Beskrivning av åtgärden – 1–3 korta stycken som, i klarspråk, förklarar:
  • vad åtgärden gör,
  • vilka konsekvenser den får för åtkomst och data i Vklass,
  • i förekommande fall: hur åtgärden samspelar med synkroniseringen.
• Eventuella extra varningstexter – visuellt avskilda (t.ex. med varningsikon eller färgton) för särskilt ingripande åtgärder.
• Primär knapp – t.ex. ”Markera för radering”, ”Radera direkt”, ”Slå ihop konton”, ”Skapa spärr”, ”Häv spärr”.
• Sekundär knapp – alltid ett tydligt ”Avbryt” (stänger dialogen utan ändring).
• Eventuellt krav på extra bekräftelse – för vissa åtgärder krävs att org‑admin markerar en kryssruta (”Jag bekräftar …”) innan primärknappen kan aktiveras.

Nedan beskrivs innehåll och varningar mer specifikt per åtgärdstyp.

---

Dialog: Markera konto för radering (karenstid)

• Titel
  ”Markera konto för radering”

• Identifieringsdel
  Kort lista, t.ex.:
  – Namn: Anna Andersson
  – Personnummer/ID: 20101231‑1234
  – Roll(er): Elev
  – Skola: Exempelskolan, Klass: 7A

• Brödtext/information
  1–2 korta stycken som förklarar:

  • att kontot inte raderas omedelbart, utan läggs i en kö med 48 timmars karenstid,
  • att Vklass under karenstiden kontrollerar om användaren fortfarande förekommer i synkroniseringsunderlaget,
  • att kontot endast raderas om användaren inte förekommit i synkroniseringen under minst 48 sammanhängande timmar,
  • att åtgärden kan ångras under hela karenstiden via karenslistan.

  Exempeltext (att anpassa språkligt efter Vklass ton):
  ”Detta konto kommer att markeras för radering. Kontot raderas inte omedelbart utan först när användaren inte har förekommit i synkroniseringsunderlaget från verksamhetssystemet under minst 48 sammanhängande timmar. Under karenstiden kan du ångra raderingen i listan över konton som är markerade för radering.”

• Särskild varning
  En kort varningsruta, t.ex.:
  ”När kontot väl har raderats tas det bort ur Vklass tillsammans med tillhörande data enligt gällande regler. Åtgärden kan inte ångras efter genomförd radering.”

• Interaktion

  • Primär knapp: ”Markera för radering”
  • Sekundär knapp: ”Avbryt”
  • Ingen extra kryssruta krävs; själva åtgärden är reversibel under karenstiden.

---

Dialog: Direkt radering av konto

• Titel
  ”Radera konto direkt”

• Identifieringsdel
  Samma struktur som ovan (namn, ID, roll, skola/klass).

• Brödtext/information

  Ett första stycke som tydliggör att detta är ett undantag från standardflödet:

  • att kontot raderas omedelbart om tekniska kontroller tillåter,
  • att Vklass först kontrollerar mot verksamhetssystem/synkunderlag att användaren inte längre förekommer där,
  • att åtgärden inte går att ångra när raderingen väl genomförts.

  Exempeltext:
  ”Detta konto kommer att raderas omedelbart om kontrollen mot verksamhetssystemet visar att användaren inte längre förekommer i synkroniseringsunderlaget. När kontot har raderats kan åtgärden inte ångras. Användaren kommer inte längre att kunna logga in i Vklass och kontot tas bort tillsammans med tillhörande data enligt gällande regler.”

• Extra varning (tydligt markerad)

  T.ex. i en markerad ruta:

  • ”Detta är en permanent åtgärd.”
  • ”Kontot får inte raderas om användaren fortfarande finns i verksamhetssystemet. Vklass kommer att avbryta raderingen om användaren fortfarande förekommer i synkroniseringen.”

• Val för kombination med spärr (om detta ska stödjas i UI direkt här)

  En eller två kryssrutor, t.ex.:

  • ”Spärra inläsning av denna person via synkronisering efter radering”
  • (Vid vårdnadshavare med valt barn:) ”Spärra även relationen till [Barnets namn]”

• Extra bekräftelse

  En kryssruta som måste markeras innan raderingsknappen aktiveras, t.ex.:

  • ”Jag bekräftar att kontot ska raderas direkt och att åtgärden inte kan ångras.”

• Interaktion

  • Primär knapp: ”Radera direkt”
  • Sekundär knapp: ”Avbryt”

Vid tekniskt avbrott eller om användaren fortfarande finns i synkunderlaget visas en separat fel-/informationsdialog (se längre ned under fel- och varningsdialoger).

---

Dialog: Ångra planerad radering

• Titel
  ”Ångra planerad radering”

• Identifieringsdel
  Namn, ID, roll, skola/klass.

• Brödtext/information

  Kort beskrivning av vad som händer:

  • att kontot tas bort från karenskön,
  • att ingen automatisk radering längre kommer att genomföras,
  • att kontot fortsätter att fungera som ett vanligt aktivt konto.

  Exempeltext:
  ”Detta konto är markerat för radering men ännu inte raderat. Om du ångrar raderingen tas kontot bort från listan över konton som ska raderas och ingen automatisk radering kommer att ske. Kontot fortsätter då att vara aktivt i Vklass.”

• Interaktion

  • Primär knapp: ”Ångra radering”
  • Sekundär knapp: ”Avbryt”

Ingen extra varningsruta behövs eftersom åtgärden är avlastande (tar bort en planerad radering).

---

Dialog: Sammanslagning av konton

Denna dialog används i bekräftelsesteget, efter att två konton valts och jämförts.

• Titel
  ”Slå ihop konton”

• Identifieringsdel

  Två separata block i dialogen:

  • Målkonto (kommer att finnas kvar)
    – Namn
    – Personnummer/ID
    – Roller
    – Skola/enhet
  • Källkonto (kommer att slås in och upphöra)
    – Namn
    – Personnummer/ID
    – Roller
    – Skola/enhet

  Skillnader (t.ex. olika personnummer, olika namn) kan markeras tydligt (t.ex. med ”!”‑ikon eller färg) mellan blocken.

• Brödtext/information

  En sammanfattande text som beskriver:

  • att all relevant historik och alla kopplingar så långt möjligt förs över från källkontot till målkontot,
  • att källkontot inte längre kan användas efter sammanslagning,
  • att sammanslagningen inte kan ångras via gränssnittet när den väl genomförts,
  • att framtida synkroniseringar kommer att uppdatera målkontot utifrån källsystemet (framför allt viktigt när ett av kontona är synkroniserat).

  Exempeltext:
  ”Du håller på att slå ihop två konton som avser samma person. All relevant data och alla kopplingar som går att flytta kommer att föras över från källkontot till målkontot. Källkontot upphör att vara ett separat konto och kan inte längre användas. Åtgärden kan inte ångras efter att den har genomförts.”

• Extra varning

  En markerad varningsruta, t.ex.:

  • ”Kontrollera noggrant att båda kontona avser samma fysiska person.”
  • ”Felaktig sammanslagning kan leda till felaktig åtkomst till information.”

• Extra bekräftelse

  En kryssruta som måste markeras:

  • ”Jag bekräftar att dessa konton avser samma person och att källkontot ska slås ihop med målkontot.”

• Interaktion

  • Primär knapp: ”Slå ihop konton”
  • Sekundär knapp: ”Avbryt”

Om vissa konflikter inte kan lösas automatiskt, kan en kort lista i dialogen markera detta (t.ex. ”Följande objekt flyttas inte” med länk till teknisk dokumentation), men det viktiga är att org‑admin vet att sammanslagningen i sin helhet antingen genomförs eller avbryts.

---

Dialog: Skapa kontospärr (spärra inläsning av konto)

• Titel
  ”Spärra inläsning av konto”

• Identifieringsdel
  Namn, ID‑prefix (eller helt ID enligt behörighet), roll, skola/enhet.

• Brödtext/information

  Kort förklaring:

  • att Vklass inte längre kommer att skapa eller återaktivera kontot via synkronisering så länge

Rättsliga krav och dataskydd (GDPR)

Funktionen för utökad användarhantering ska stödja organisationens ansvar enligt dataskyddsförordningen (GDPR) och kompletterande svensk reglering, utan att tillföra nya personuppgiftsbehandlingar utöver vad som är nödvändigt för ändamålet. Den är ett verktyg för personuppgiftsansvarig (huvudmannen/organisationen) att kunna uppfylla krav på bl.a. riktighet, åtkomstkontroll, dataminimering och gallring – inte ett eget, fristående ändamål.

Behandlingen av personuppgifter i funktionen sker inom ramen för samma rättsliga grunder som övrig användarhantering i Vklass, exempelvis myndighetsutövning/allmänt intresse eller avtal, beroende på skolform och huvudmannens bedömning. Åtgärderna (radering, sammanslagning, spärrning) förändrar hur befintlig data i Vklass organiseras, men skapar inte nya typer av uppgifter eller ändamål. Funktionen förutsätter att varje organisation själv har dokumenterat sina gallringsregler, rättsliga grunder och interna rutiner; systemet varken definierar eller prövar dessa.

Principen om ändamålsbegränsning respekteras genom att funktionen enbart används för administrativa åtgärder kring konton (korrigering, gallring, åtkomstbegränsning). Personuppgifter i den utökade användarhanteringen får inte återanvändas för andra syften, t.ex. analys, uppföljning eller särskild registrering av känsliga ärenden. Spärrlistor, karenslistor och åtgärdsloggar är tekniska hjälpmedel för att skydda uppgifter och styra livscykeln för konton – inte egna ”register” över elev- eller personalinformation.

Principen om dataminimering säkerställs på flera nivåer:

• Funktionen återanvänder befintliga personuppgifter från användarkonton, men inför inte nya fält med t.ex. adress, känsliga uppgifter eller beslutstexter.
• Karenslistan innehåller fullständiga identitetsuppgifter endast så länge kontot finns kvar och raderingsärendet är aktivt.
• Åtgärdsloggen sparar endast den minsta mängd information som behövs för spårbarhet: tidpunkt, administratör, åtgärdstyp och en begränsad identifiering (t.ex. förnamn, sex första siffror i personnummer/ID, skola/enhet efter radering). Fullständiga personnummer eller fulla profiler lagras inte i loggen efter att ett konto har raderats.
• Spärrlistan lagrar endast den identitet som krävs för att kunna blockera inläsning (knytning till konto och/eller relation) tillsammans med snålt tilltagen visningsinformation; känsliga fritextanteckningar eller beslutsskäl ska inte föras in.

Principen om lagringsminimering (lagringsbegränsning) hanteras genom:

• Tidsbegränsad lagring av åtgärdsloggar: loggar över radering, sammanslagning och spärrning sparas endast under en kort, fastställd period (t.ex. 30 dagar) och gallras därefter automatiskt. Detta begränsar risken att loggarna utvecklas till ett långsiktigt personregister.
• Själva spärrposterna ligger kvar så länge spärren måste gälla av säkerhets- och åtkomstskäl, men innehåller minimalt med persondata. Organisationen avgör i sin roll som personuppgiftsansvarig om och när en spärr ska hävas.
• Raderade konton tas bort från Vklass i enlighet med systemets regler för kontoradering; kvarvarande referenser är begränsade till anonymiserad eller starkt beskuren information i loggar.

Principen om riktighet stödjs genom att ingen slutlig radering får ske utan kontroll mot verksamhetssystemen/synkroniseringsunderlaget. Funktionen förhindrar att konton som fortfarande betraktas som aktiva i källsystemet raderas i Vklass, vilket minskar risken för inkonsekvent eller felaktig datahantering mellan system. Sammanslagning av konton används för att korrigera dubbletter och felaktiga identiteter, så att varje fysisk person representeras korrekt och entydigt i Vklass.

Principen om integritet och konfidentialitet (säkerhet) uppfylls genom tekniska och organisatoriska åtgärder:

• Åtkomst är strikt begränsad till organisationsadministratörer. Andra roller (lärare, skoladmins, vårdnadshavare, elever) kan varken se karenslistor, spärrlistor eller åtgärdsloggar, och kan inte initiera dessa åtgärder.
• Funktionerna genomförs i Vklass Admin och kan kombineras med krav på stark autentisering (t.ex. BankID/SSO) enligt befintliga säkerhetsinställningar.
• Det införs inga nya möjligheter att dela eller exportera personuppgifter från dessa vyer utöver vad som redan gäller i Vklass.
• Åtgärdsloggning är i sig en säkerhetsåtgärd enligt GDPR (art. 32) eftersom den möjliggör upptäckt av obehöriga eller felaktiga administrativa ingrepp, men är samtidigt begränsad i detaljgrad och lagringstid.

Funktionen bidrar till att organisationen kan uppfylla rätten till radering och gallring i praktiken: när en person ska gallras enligt kommunal gallringsplan eller när ett konto ska avslutas av andra skäl kan org‑admin radera kontot och tillhörande data i Vklass på ett kontrollerat sätt. Samtidigt förhindrar karenslogiken och kontrollerna mot verksamhetssystemen att radering genomförs i strid med pågående behandling i källsystemen. Funktionen ersätter inte den rättsliga bedömningen av när radering ska ske, utan ger verktyg för att genomföra beslut som redan fattats.

Vid hantering av personer i särskilt känsliga situationer (t.ex. sekretessmarkerade uppgifter, känsliga beslut kring vårdnadshavare–barn‑relationer) innebär funktionen en förhöjd risk som måste hanteras av organisationen genom interna rutiner: vilka får göra vad, hur beslut dokumenteras utanför Vklass, hur behörigheter till org‑admin‑rollen tilldelas och följs upp. Systemet gör ingen automatisk klassning av skyddade eller känsliga fall, utan utgår från att sådana överväganden görs av personuppgiftsansvarig och att funktionen används i enlighet med dessa beslut och med IMY:s vägledning.

Slutligen ska åtgärderna i den utökade användarhanteringen ingå i organisationens övergripande dokumentation av personuppgiftsbehandling (t.ex. registerförteckning/”record of processing activities”), inklusive:

• att radering, sammanslagning och spärrning är särskilda behandlingar av personuppgifter i Vklass,
• att loggning av administratörsåtgärder sker med begränsat innehåll och begränsad lagringstid,
• att spärrlistor används som en del av åtkomstkontrollen vid synkronisering.

På så sätt kan huvudmannen visa att man uppfyller kravet på ansvarsskyldighet (accountability) och att den utökade användarhanteringen är utformad och används i enlighet med gällande dataskyddsregler.

Säkerhet och åtkomstkontroll

Funktionen för utökad användarhantering innebär kraftfulla administrativa möjligheter (radering, sammanslagning och spärrning av konton och relationer) och ställer därför särskilda krav på säkerhet och åtkomstkontroll. Säkerhetskraven bygger vidare på Vklass befintliga säkerhetsmodell men skärps för just dessa åtgärder.

Autentisering och inloggning

• Endast användare med rollen Organisationsadministratör (org‑admin) kan använda funktionen.
• Om organisationen har aktiverat krav på stark autentisering för användare med högre behörighet (t.ex. BankID, Freja eID eller SSO med definierad LOA‑nivå) gäller detta även för alla åtgärder i den utökade användarhanteringen.
• Det ska vara möjligt för huvudmannen att besluta att funktionen endast får användas när org‑admin är inloggad med stark autentisering, inte med enklare inloggningsmetoder (t.ex. lokalt användarnamn/lösenord).
• Sessioner för org‑admin ska följa Vklass skärpta regler för tidsgränser och inaktivitet. Vid längre inaktivitet ska ny inloggning krävas innan åtgärder kan utföras.

Behörighet och åtkomstkontroll

• Funktionens menyer, vyer (sök, karenslista, spärrlista, sammanslagning) och API‑anrop är endast tillgängliga för konton med rollen Org‑admin i den aktuella organisationen.
• Åtkomst kontrolleras både i användargränssnittet och i backend; direkta URL:er eller API‑anrop kan inte användas för att kringgå begränsningen.
• En org‑admin kan enbart se och hantera konton och spärrar inom den egna organisationen. Användare, karensärenden, spärrar och loggar från andra huvudmän är helt avskilda.
• Skoladministratörer, rektorer, lärare, elevhälsa, vårdnadshavare och elever får varken se menyalternativet för utökad användarhantering eller nå funktionen via direkta länkar.

Principen om minsta möjliga behörighet

• Funktionen ger inte andra roller någon utökad insyn i personuppgifter; den samlar endast redan känsliga åtgärder hos org‑admin på ett tydligt och spårbart sätt.
• Rollen org‑admin bör i organisationens interna rutiner tilldelas restriktivt, endast till ett fåtal betrodda personer med särskilt ansvar för personuppgifter och behörighetshantering.
• Åtgärder som kan påverka många användare (t.ex. radering och sammanslagning) är koncentrerade till ett fåtal vyer, vilket förenklar uppföljning och intern kontroll.

Begränsning av känsliga data i gränssnittet

• Vyn Sök & åtgärda samt användardetaljvyer visar inte mer persondata än org‑admin redan har rätt att se i ordinarie användarprofiler.
• Karenslistan visar fullständigt personnummer/ID endast så länge kontot finns kvar i Vklass; efter radering finns bara en starkt begränsad ögonblicksbild kvar i loggen.
• Spärrlistan och spärrdetaljvyer visar som huvudregel:
  • förnamn,
  • högst de sex första siffrorna i personnummer/ID,
  • skola/enhet,
    och inte de fyra sista siffrorna eller andra onödigt identifierande uppgifter.
• Varken spärrposter, karensposter eller loggar får innehålla känsliga beslutsskäl, elevhälsouppgifter eller andra integritetskänsliga fritextanteckningar. Eventuella kommentarsfält ska begränsas till neutral, administrativ information (t.ex. ”tillfällig spärr enligt beslut”).

Loggning, spårbarhet och gallring

• Alla väsentliga åtgärder i funktionen loggas i en särskild åtgärdslogg:
  • markering för radering,
  • genomförd radering (efter karens eller direkt),
  • ångrad radering,
  • genomförd sammanslagning,
  • skapande och hävning av spärrar,
  • avbrutna åtgärder p.g.a. tekniska fel eller kvarstående förekomst i synkroniseringen.
• Varje loggpost innehåller:
  • tidpunkt,
  • typ av åtgärd,
  • vilken org‑admin som utfört åtgärden,
  • dataminimerad identifiering av berörd användare (efter radering högst sex första siffror i personnummer/ID, förnamn och skola/enhet).
• Loggarna är endast åtkomliga för org‑admin inom den egna organisationen.
• Åtgärdsloggarna omfattas av strikt lagringsbegränsning (t.ex. 30 dagar) och gallras automatiskt därefter, så att de inte blir ett permanent sidoregister över användare.

Skydd mot felaktig eller obehörig användning

• Alla kritiska åtgärder (radering, sammanslagning, skapande/hävning av spärrar) kräver en aktiv bekräftelse i dialogruta, med tydlig beskrivning av konsekvenserna. Vissa åtgärder (t.ex. direkt radering, sammanslagning) kräver dessutom att org‑admin markerar en extra bekräftelseruta innan knappen aktiveras.
• Systemet genomför tekniska kontroller innan åtgärder slutförs:
  • radering får inte genomföras om personen fortfarande förekommer i synkroniseringsunderlaget,
  • sammanslagning och radering utförs som transaktioner – antingen genomförs de fullt ut eller inte alls.
• Vid tekniska fel (t.ex. misslyckad synkronisering, integritetskonflikter i databasen) ska systemet automatiskt välja det säkra läget:
  • inga slutliga raderingar,
  • inga delvis genomförda sammanslagningar,
  • tydlig felinformation till org‑admin.
• Administrationsgränssnittet skyddas med samma tekniska skydd som övriga Vklass (t.ex. skydd mot CSRF, XSS och obehöriga API‑anrop enligt Vklass generella säkerhetsarkitektur).

Organisatoriska säkerhetsaspekter

• Funktionen förutsätter att huvudmannen har interna rutiner för:
  • vem som får vara org‑admin,
  • hur åtgärder som radering, sammanslagning och spärrning initieras (t.ex. krav på underlag/beslut),
  • hur loggar och spärrlistor får läsas och av vem.
• Vklass tillhandahåller tekniska möjligheter till spårbarhet och begränsning av persondata; det är organisationen som ansvarar för att dessa möjligheter används i linje med gällande lagstiftning, interna riktlinjer och rollfördelning.

Samlat innebär detta att den utökade användarhanteringen koncentrerar avancerade och integritetskänsliga åtgärder till ett säkrat gränssnitt för ett fåtal betrodda administratörer, med stark autentisering, tydlig åtkomstkontroll, begränsad exponering av personuppgifter och full spårbarhet under en kort och kontrollerad logglagringstid.

Prestanda och skalbarhet

Funktionen för utökad användarhantering ska dimensioneras för stora organisationer med många användare, samtidigt som svarstiderna i gränssnittet upplevs som snabba och förutsägbara. All prestandaoptimering ska genomföras utan att påverka ordinarie drift av Vklass eller befintliga synkroniseringsflöden negativt.

Användargränssnittet ska vara responsivt även vid stora datamängder:

• Inläsning av huvudsidan för utökad användarhantering (inkl. grundläggande filtervy) ska normalt ske inom cirka 1–2 sekunder för en typisk organisation.
• Sökning efter enstaka användare via personnummer/ID eller fullständigt namn ska i normalfallet ge träfflista inom cirka 1 sekund, även i organisationer med tiotusentals konton.
• Bredare sökningar (t.ex. namn + skola, rollfilter) får ta längre tid men bör normalt inte överstiga 2–3 sekunder. Om urvalet är mycket stort ska systemet tydligt be användaren förfina sökkriterierna istället för att returnera mycket stora resultatmängder.
• Uppdatering av listor vid filterändring (karenslista, spärrlista) ska upplevas som omedelbar; servern ska returnera nya resultatsidor inom 1–2 sekunder i normalfallet.

För att klara stora datamängder används konsekvent server‑side‑paginering och indexerade sökningar:

• Alla listor (sökresultat, karenslista, spärrlista m.fl.) visar endast ett begränsat antal rader per sida (t.ex. 25–100), med möjlighet att bläddra.
• Sökningar och filteroperationer görs alltid mot indexerade kolumner, t.ex.:
  • Organisation, UserId,
  • personnummer/ID (inkl. TF‑nummer),
  • roll, skola/enhet,
  • status (markerad för radering, spärrtyp, aktiv/inaktiv spärr),
  • tidsstämplar (markerad för radering, skapad spärr m.m.).
• Fritextsökning på namn får antingen utnyttja lämpliga index (t.ex. prefix) eller begränsas genom krav på minsta antal tecken, för att undvika fullbordssökningar på mycket stora tabeller.

Tunga åtgärder (själva raderingen, sammanslagning av konton, gallring av loggar) ska i största möjliga mån behandlas asynkront i backend:

• När en org‑admin initierar en åtgärd (markera för radering, starta sammanslagning, skapa spärr) ska UI få snabb bekräftelse på att ärendet är initierat, utan att vänta på hela interna bearbetningen.
• Själva slutliga raderingen av konton (efter uppfylld karens eller vid godkänd direkt radering) utförs i bakgrundsprocesser eller schemalagda jobb som:
  • kan hantera flera raderingar i följd eller i batch utan att blockera användargränssnittet,
  • kan throttlas så att de inte påverkar prestandan för andra delar av Vklass (t.ex. undervisning, meddelanden).
• Sammanslagning av konton ska också hanteras så att UI‑tråden endast väntar den tid som krävs för att:
  • validera förutsättningar,
  • initiera en transaktion i backend.
    Vid förväntat tyngre merge‑fall kan backend utföra operationen i bakgrunden och UI visa en kort ”bearbetar …”/”uppdaterar”‑indikation, dock utan orimligt långa svarstider. I normalfallet bör en sammanslagning av enstaka konton slutföras inom några sekunder.

Integrationen mot synkroniseringsflödet får inte bli en flaskhals:

• Karenslogiken (uppdatering av ”senast sedd i synk” och status) ska byggas så att den kan bearbeta alla karensposter effektivt vid varje synkkörning, även om antalet konton i karens är stort.
• Uppslag i spärrlistan vid synk ska vara mycket snabba, eftersom varje inkommande post i underlaget kan behöva kontrolleras. Det kräver:
  • att spärrtabellerna är indexerade på relevanta nycklar (Organisation + personnummer/ID resp. kombinationer för relationer),
  • att eventuella cachemekanismer används där det är lämpligt (t.ex. i form av inläst spärrmängd per organisation under pågående synckörning).
• Kontroll mot synkunderlag/verksamhetssystem vid direkt radering ska designas så att den:
  • använder befintliga, optimerade strukturer (t.ex. senaste synksnapshot eller dedikerade uppslags‑API:er),
  • inte triggar kompletta extrakörningar av synkronisering för enstaka konton.

Systemet ska klara att hantera:

• organisationer med potentiellt hundratusentals användarkonton,
• karenslistor med upp till åtminstone några tusen samtidiga poster utan märkbar försämring i listvyer,
• spärrlistor med motsvarande storlek (kontospärrar och relationsspärrar).

Designen ska också ta hänsyn till konkurrerande åtkomst och samtidiga administratörer:

• Åtgärder som radering, sammanslagning och spärrning ska använda lämpliga lås- eller versionsmekanismer (optimistic concurrency) för att:
  • undvika deadlocks och långa låsningar av centrala tabeller,
  • förhindra att två administratörer samtidigt genomför motstridiga åtgärder på samma konto.
• Vid konflikt (t.ex. att ett konto ändrats eller raderats av en annan administratör under tiden) ska åtgärden avbrytas snabbt och org‑admin få information om att läget ändrats, utan tung återläsning eller omräkning.

Gallring av åtgärdsloggar (t.ex. 30‑dagarslogik) och städning av tekniska hjälpstrukturer ska:

• ske via schemalagda bakgrundsjobb med låg prioritet,
• vara uppdelad i mindre batchar så att stora rensningar inte påverkar prestanda märkbart,
• inte blockera synkronisering eller ordinarie användarflöden.

Vid hög belastning eller tillfälliga prestandaproblem ska funktionen degradera på ett kontrollerat sätt:

• UI kan t.ex. visa meddelanden om att vissa vyer (stora listor) tar längre tid än normalt och uppmana till mer precisa filter.
• Tunga administrativa åtgärder kan temporärt prioriteras ned i förhållande till slutanvändarflöden (elever/lärare), så att undervisningsrelaterade funktioner påverkas minimalt.
• Raderings- och sammanslagningsjobb i bakgrunden kan begränsa antalet samtidiga transaktioner per tidsenhet om databasen är hårt belastad.

Sammanfattningsvis ska arkitektur och implementation säkerställa att:

• enstaka åtgärder i gränssnittet upplevs som snabba och förutsägbara,
• funktionaliteten skalar till stora användarbaser och många pågående ärenden (karens, spärrar),
• synkroniseringsflödena kan köras i normal takt trots extra kontroller,
• administrativa batchar (raderingar, gallringar, uppdatering av status) kan hanteras utan att belasta resten av Vklass orimligt mycket.

Spårbarhet och revision

Funktionen för utökad användarhantering ska ge hög spårbarhet utan att skapa onödigt omfattande eller långlivade loggar. Alla kritiska administrativa ingrepp på användarkonton och relationer ska kunna följas upp i efterhand, både för intern kontroll hos huvudmannen och för teknisk felsökning hos Vklass.

Följande åtgärder måste alltid vara spårbara på individnivå:

• Markering av konto för radering (start av karens).
• Ångrad planerad radering (konto tas ur karenslistan).
• Genomförd radering efter karenstid.
• Genomförd direkt radering (utan karenstid), inklusive om den initierats från ett konto i karens.
• Misslyckade eller avbrutna försök till radering där orsaken är:
  • att användaren fortfarande förekommer i synkroniseringsunderlaget, eller
  • tekniskt fel (t.ex. misslyckad kontroll mot verksamhetssystemet).
• Initiering och genomförd sammanslagning av två konton:
  • vilket konto som var målkonto,
  • vilket konto som var källkonto.
• Skapande av spärrposter:
  • kontospärr (blockering av inläsning av en person),
  • relationsspärr (blockering av en specifik vårdnadshavare–barn‑relation).
• Hävning (inaktivering) av spärrposter.
• Andra förändringar av spärrar om sådana införs (t.ex. ändring av kommentar eller statustyp).

Varje sådan åtgärd ska generera en post i en särskild åtgärdslogg som minst innehåller:

• Tidpunkt för åtgärden (datum och klockslag, i organisationens tidszon).
• Typ av åtgärd (standardiserad kod/benämning, t.ex. MarkedForDeletion, DeletionCompleted, MergeCompleted, BlockCreated, BlockInactivated).
• Referens till den org‑admin som utförde åtgärden (administratörskonto/ID).
• Referens till berört konto (intern UserId) och, vid behov, sekundärt konto (vid sammanslagning) eller berörd relation (vårdnadshavare–barn).
• Dataminimerad identifiering för visning i UI:
  • förnamn (snapshot vid åtgärdstillfället),
  • högst de sex första siffrorna i personnummer/ID,
  • skola/enhet (snapshot) där det är relevant.

Efter att ett konto har raderats får loggvisningen aldrig innehålla fullständigt personnummer eller kompletta personprofiler. Loggen får inte heller innehålla fritextanteckningar om beslutsskäl, sekretess, sociala förhållanden eller annan känslig information; sådant ska hanteras i organisationens egna system och dokument, inte i Vklass.

Åtgärdsloggen är endast åtkomlig för org‑admin inom respektive organisation och visas i form av en historiklista med filter på:

• datumintervall (maximalt den tid loggen sparas, t.ex. 30 dagar bakåt),
• åtgärdstyp,
• administratör,
• dataminimerad användaridentifiering (namn/personnummerprefix/skola).

Det ska även vara möjligt att, vid behov, söka fram loggposter knutna till ett specifikt konto från konto‑detaljvyn, så att en org‑admin kan se vad som gjorts med just det kontot under loggens livslängd.

För revisions- och kontrolländamål ska organisationen kunna ta fram revisionsunderlag baserat på denna logg, exempelvis:

• Skärmbilder eller export av åtgärdslogg för en given period (inom ramen för loggens lagringstid) med:
  • vilka konton som raderats,
  • vilka konton som slogs ihop,
  • vilka spärrar som lagts eller hävts,
  • vem (vilket admin‑konto) som utfört åtgärderna.
• Utsökning av alla åtgärder som en viss org‑admin har gjort under en given tidsperiod, t.ex. vid intern kontroll av behörighetsanvändning.
• Utsökning av alla åtgärder på ett enskilt konto i samband med intern incidentutredning (t.ex. ”varför ser inte denna användare sitt barn längre?” eller ”när togs kontot bort?”).

All export eller utskrift av logginformation ska följa samma dataminimeringsprinciper som visningen i UI; det får inte gå att via export få mer detaljerade personuppgifter än vad som visas.

Utöver åtgärdsloggen förekommer även tekniska driftloggar (system‑ och fel‑loggar) som hanteras av Vklass driftorganisation. Dessa kan innehålla mer tekniska detaljer (felkoder, stacktraces etc.) men ska inte användas som primärt revisionsunderlag för organisationen, och får inte utvecklas till parallella personregister. Vid behov av fördjupad teknisk revision (t.ex. vid allvarliga incidenter) kan Vklass, inom ramen för gällande avtal och dataskyddsregler, bistå med utdrag och tolkning av sådana loggar.

Åtgärdsloggen omfattas av strikt lagringsbegränsning (t.ex. 30 dagar). En schemalagd gallringsprocess rensar bort loggposter som är äldre än den definierade tiden, så att:

• loggarna alltid speglar den senaste perioden (kort historik för spårbarhet och intern kontroll),
• äldre åtgärder inte ligger kvar som långvariga personuppgifter i Vklass.

Eventuella säkerhetskopior av databasen hanteras enligt Vklass generella backup‑rutiner och får inte användas som ett sätt att förlänga loggarnas faktiska lagringstid; efter återställning ska gallringsreglerna tillämpas på nytt.

Sammanfattningsvis ger funktionen:

• full spårbarhet för alla kritiska åtgärder på konton och relationer under en begränsad period,
• möjligheter för huvudmannen att ta fram revisionsunderlag för intern kontroll, incidenthantering och extern granskning,
• kontroll över mängden och livslängden på loggad persondata i enlighet med dataminimering och lagringsbegränsning enligt GDPR.

Teststrategi och acceptanskriterier

Teststrategin för funktionen Utökad användarhantering syftar till att säkerställa att alla delar av funktionaliteten fungerar korrekt, är robusta över tid och uppfyller både tekniska och juridiska krav (särskilt kring dataskydd). Testningen ska omfatta både funktionella och icke‑funktionella aspekter och genomföras i en miljö som så långt som möjligt speglar produktionsförhållanden (inklusive realistisk synkronisering mot testkopior av verksamhetssystem).

Översikt över testtyper

Följande testtyper ska ingå som minimum:

• Enhetstester (unit tests)
  Testar domänlogik och hjälpfunktioner isolerat, t.ex.:

  • beräkning av karenstider (48 timmar utan förekomst i synk),
  • statusövergångar för karensposter,
  • logik för sammanslagning av kopplingar och historik,
  • matchning mot spärrposter (konto och relation).

• Integrationstester
  Säkerställer att funktionen samverkar korrekt med:

  • synkroniseringsmotorn och tolkningen av synkunderlag,
  • befintliga användar- och behörighetsmodeller,
  • eventuella uppslagsfunktioner mot ”senaste synk”-data eller integrationslager.
    Fokus på:
  • att karensposter uppdateras korrekt efter synkkörningar,
  • att spärrlista faktiskt blockar inläsning av berörda poster,
  • att radering inte sker när källdata visar att personen fortfarande är aktiv.

• System- och end‑to‑end‑tester
  Verifierar kompletta flöden i UI, inklusive:

  • sökning → val av konto → initiering av åtgärd → uppföljning i listor,
  • samspelet mellan karenslista, spärrlista och ordinarie användarvyer,
  • fulla scenarier med synkronisering ”före och efter” administratörsåtgärder.
    Dessa tester ska köras med representativa roller (org‑admin) och data (elever/barn, personal, vårdnadshavare).

• Säkerhetstester
  Kontrollerar att:

  • endast org‑admin kan komma åt funktionen (via UI och API),
  • andra roller inte kan nå funktionerna via direkta URL:er,
  • dataavgränsning mellan organisationer respekteras,
  • loggning inte läcker mer information än tillåtet (t.ex. inte hela personnummer efter radering),
  • åtgärder är skyddade mot typiska angrepp (t.ex. CSRF, otillåtna API‑anrop).

• Prestanda- och lasttester
  Säkerställer att:

  • sökningar, karenslista och spärrlista fungerar med stora datamängder (många konton, många spärrar),
  • synkroniseringsflödet inte påverkas oacceptabelt av extra kontroller (karenstid, spärrlista),
  • batchvis radering/sammanslagning i bakgrund inte degraderar annan funktionalitet i Vklass.

• Användbarhetstester (UX)
  Fokuserar på org‑admin som målgrupp:

  • att det är tydligt vilka åtgärder som finns och vad de innebär,
  • att dialoger och varningar är begripliga och minimerar risken för felklick,
  • att status i karenslista och spärrlista går att förstå utan teknisk bakgrund.

• Regressions- och återkommande tester
  Genomförs vid:

  • ändringar i synkroniseringslogik,
  • ändringar i användarmodell eller behörigheter,
  • vidareutveckling av funktionen (nya typer av spärrar, nya flöden).
    Säkerställer att redan fungerande delar (t.ex. radering, loggning) inte påverkas negativt.

Generella acceptanskriterier på systemnivå

Följande övergripande kriterier gäller för att funktionen som helhet ska anses godkänd:

1. Behörighet och åtkomst

   • Endast org‑admin kan:
     • se menyalternativet för utökad användarhantering,
     • nå sökvyn, karenslistan, spärrlistan och sammanslagningsflöden,
     • genomföra radering, sammanslagning och spärrning.
   • Orsaker till nekad åtkomst hanteras korrekt (ingen data exponeras för obehöriga, tydlig men neutral felinformation).

2. Täckning av alla användartyper

   • Alla huvudroller kan hanteras:
     • elev/barn,
     • personal,
     • vårdnadshavare.
   • Funktionens logik (sökning, radering, sammanslagning, spärrning) fungerar konsekvent oavsett om kontot är synkroniserat eller manuellt skapat, och oavsett typ av identitet (personnummer, TF‑nummer, annat ID).

3. Synkronisering och källsystem

   • Ingen slutlig radering (varken efter karens eller direkt) sker om användaren fortfarande förekommer i synkunderlaget/verksamhetssystemet.
   • Vid tekniskt fel i synk eller uppslag mot källsystem får radering inte genomföras; systemet väljer säkert läge (hellre inte radera än radera fel).
   • Spärrlista påverkar synkroniseringen korrekt:
     • spärrade konton återskapas inte,
     • spärrade vårdnadshavare–barn‑relationer skapas inte,
     • övriga poster fortsätter att läsas in normalt.

4. Data- och loggkvalitet

   • Åtgärdslogg innehåller korrekta uppgifter:
     • rätt typ av åtgärd,
     • rätt administratör,
     • rätt (dataminimerad) användarreferens.
   • Loggar innehåller aldrig mer än tillåtet:
     • efter radering: högst sex första siffror i personnummer/ID, förnamn, skola/enhet.
   • Loggar gallras automatiskt efter definierad tid (t.ex. 30 dagar); äldre loggar är inte åtkomliga.

5. Stabilitet och prestanda

   • Funktionens UI är responsivt även i stora organisationer.
   • Synkroniseringsflöden kan köras med funktionerna aktiva utan oacceptabel fördröjning.
   • Radering, sammanslagning och gallring hanteras utan att orsaka inkonsistens i data (ingen delvis raderad eller delvis sammanslagen användare).

6. Integritet och dataminimering

   • Spärrlista, karenslista och loggvyer visar inte onödiga eller otillåtna personuppgifter.
   • Inga känsliga beslutsskäl, elevhälsodata eller liknande fritext skrivs till spärrposter, karensposter eller loggar.
   • Funktionen lägger inte till nya fält med känsliga uppgifter i användarprofilen.

7. Inga oavsiktliga notifieringar

   • Inga e‑post, pushnotiser eller interna meddelanden går ut till användare (elever/barn, personal, vårdnadshavare) som en följd av att deras konto raderas, slås ihop eller spärras.
   • Endast interna UI‑kvittenser till org‑admin förekommer.

Specifika acceptanskriterier per huvudfunktion

Radering med karenstid

• Ett konto kan markeras för radering via UI med tydlig bekräftelsedialog.
• När ett konto markerats:
  • skapas exakt en karenspost,
  • kontot visas i karenslistan med korrekt starttid, status och synkroniseringsinformation.
• Under karenstiden:
  • uppdateras ”senast sedd i synk” korrekt vid varje synk,
  • status i karenslistan återspeglar verkligheten (förekommer/inte förekommer, pausad vid synkfel).
• Radering genomförs automatiskt först när:
  • användaren inte förekommit i synkunderlaget under minst 48 sammanhängande timmar, och
  • slutlig kontroll mot verksamhetssystem/senaste synk bekräftar fortsatt frånvaro.
• Efter radering:
  • kontot kan inte längre hittas via vanlig användarsökning,
  • kontot försvinner ur karenslistan,
  • endast en loggrad med dataminimerad identifiering finns kvar under loggens lagringstid.

Direkt radering

• Direkt radering kan endast väljas aktivt (inte standardval) och kräver extra bekräftelse i dialogen.
• Innan direkt radering genomförs:
  • görs ett uppslag mot synkunderlag/verksamhetssystem,
  • om användaren finns kvar i underlaget avbryts raderingen och org‑admin informeras,
  • om uppslaget misslyckas (tekniskt fel) avbryts raderingen.
• När direkt radering är tillåten:
  • tas kontot bort omedelbart i en atomär transaktion,
  • eventuella valda spärrar skapas endast om raderingen slutförs,
  • kontot kan inte återställas via UI.

Ångra planerad radering

• För konton i karenslista är åtgärden ”Ångra radering” alltid tillgänglig (så länge radering inte är genomförd).
• Vid bekräftad åtgärd:
  • tas karensposten bort,
  • kontot återgår direkt till aktivt läge,
  • ingen automatisk radering sker längre.
• Inga mellanlägen uppstår (inget konto är ”halvt i karens”).

Sammanslagning av konton

• Det går inte att sammanslå:
  • ett konto med sig självt,
  • konton från olika organisationer,
  • konton där någon del är tekniskt låst för merge enligt systemregler.
• Jämförelsevyn visar båda kontonas centrala uppgifter så att org‑admin kan bedöma om de avser samma person.
• Org‑admin väljer tydligt målkonto och källkonto och bekräftar åtgärden.
• Efter bekräftad sammanslagning:
  • konsolideras roller, skolkopplingar, klass-/gruppkopplingar och relationer enligt definierad logik (inga dubbletter skapas i onödan),
  • relevant historik (t.ex. närvaro, resultat, uppgifter, meddelanden) kopplas om till målkontot i den utsträckning det är tekniskt och juridiskt tillåtet,
  • källkontot upphör att vara aktivt och kan inte längre användas för inloggning eller administration.
• Hela sammanslagningen är atomär; vid fel rullas alla ändringar tillbaka och båda kontona lämnas oförändrade.
• Framtida synkronisering uppdaterar målkontot korrekt; risk för återuppkomst av källkontot via gammalt ID ska kunna hanteras (t.ex. med spärr).

Spärrlista (kontospärr och relationsspärr)

• Kontospärr:
  • en aktiv spärr förhindrar att ett konto skapas eller återaktiveras via synk,
  • spärren kan kombineras med radering av kontot men är inte beroende av det,
  • endast en aktiv spärr per konto och organisation kan finnas.
• Relationsspärr (vårdnadshavare–barn):
  • den spärr

Driftsättning och migrering

Driftsättningen av den utökade användarhanteringen ska ske kontrollerat och bakåtkompatibelt, så att befintlig drift och synkronisering inte påverkas negativt och så att verksamheten hinner anpassa sina rutiner.

Teknisk driftsättning (plattform och databas)

Vid införande i Vklass görs följande tekniska steg:

• Nya databastabeller och/eller kolumner läggs till för:
  • karensposter (t.ex. DeletionPending),
  • spärrposter (t.ex. BlockEntry),
  • åtgärdsloggar (t.ex. AdminActionLog), med nödvändiga index för organisation, användar‑ID och identitetsnycklar.
• Nya backend‑tjänster och API:er för:
  • hantering av karensflödet,
  • spärrlista och kontroller mot denna i synkflödet,
  • loggning av åtgärder.
• Synkroniseringsmotorn utökas med:
  • läsning av spärrlista vid varje synkkörning,
  • uppdatering av karensposter efter genomförd synkronisering,
  • stöd för riktade uppslag (”finns denna identitet i underlaget?”) vid direkt radering.
• UI‑komponenter i Vklass Admin (V2) läggs till:
  • menyalternativ för utökad användarhantering (begränsat till org‑admin),
  • vyer för sök, karenslista, spärrlista och sammanslagning.

Samtliga förändringar införs så att de är bakåtkompatibla:

• Om funktionen inte är aktiverad för en organisation:
  • körs synkroniseringen vidare som tidigare,
  • skapas inga karensposter,
  • spärrlogik är inaktiv,
  • UI‑delar för funktionen visas inte.
• Befintlig standardfunktionalitet för användaradministration i Vklass påverkas inte (sök användare, ändra behörighet, etc.).

Aktivering per organisation (feature toggle)

Funktionen bör aktiveras per organisation genom en konfigurationsinställning/feature‑toggle, så att utrullning kan ske stegvis:

1. Teknisk aktivering i test-/stagemiljö

   • Funktion, databasschema och UI sätts upp i en testmiljö.
   • Synkronisering mot testkopior av verksamhetssystemen körs med aktiverad karens‑ och spärrlogik.
   • Organisationens systemförvaltare och utvalda org‑admins kan prova flöden utan att påverka produktion.

2. Pilot i produktion för utvald organisation

   • Funktionen aktiveras för 1–2 pilotorganisationer (kommuner/huvudmän) efter överenskommelse.
   • Menyalternativet visas endast för org‑admin i dessa organisationer.
   • Under pilotperioden rekommenderas:
     • begränsad användning initialt (t.ex. endast radering med karens, inte sammanslagning i komplexa fall),
     • tät dialog mellan organisation och Vklass kring eventuella justeringar.

3. Breddinförande

   • När funktionen verifierats i pilot kan den successivt aktiveras för fler organisationer.
   • Org‑admin får samtidigt kort dokumentation och/eller länkar till användarstöd (intern utbildning, handböcker).

Vid aktivering ska org‑admin inte behöva göra några tekniska inställningar själva för att funktionen ska fungera; allt nödvändigt är färdigkonfigurerat i Vklass. Det enda som krävs på organisationssidan är att man:

• säkerställer att rätt personer har rollen org‑admin,
• beslutar hur funktionen ska användas i relation till befintliga rutiner.

Påverkan på pågående synkronisering vid driftsättning

Vid själva driftsättningen (kod och databasschema) ska ingen pågående synkkörning avbrytas:

• Ändringar i synklogiken (kontroll mot spärrlista, uppdatering av karensposter) aktiveras först när ny kodversion är fullt driftsatt och testad.
• Under en övergångsperiod kan synkkomponenten:
  • köra i ”observerande” läge där spärr- och karenslogik loggas internt utan att påverka resultat (endast i testmiljö), eller
  • direkt respektera spärrar och uppdatera karensposter i produktion efter att funktionen aktiverats för organisationen.

Ingen initial full‑reimport av samtliga användare krävs enbart för att funktionen ska fungera. Den börjar gälla från och med den tidpunkt då den aktiveras:

• Konton som redan finns i Vklass fortsätter som vanligt.
• Karensposter skapas endast för konton som markeras för radering efter aktivering.
• Spärrar börjar gälla från det att de läggs upp av org‑admin.

Migrering av befintliga manuella rutiner (spärrar/blockeringar)

Många organisationer har i dag manuella eller halvmanuella rutiner för att begränsa åtkomst och blockera vissa konton/relationskopplingar, t.ex.:

• särskilda överenskommelser med Vklass support om att vissa personer inte ska läsas in,
• lokala justeringar i integrationskonfigurationer (filtrering i export från verksamhetssystem),
• manuell borttagning av konton i Vklass med efterföljande ”bevakning” för att hindra att de dyker upp igen.

Införandet av spärrlista i Vklass innebär att mycket av detta kan hanteras direkt i systemet av org‑admin. Själva migreringen kan göras stegvis och är i grunden organisatorisk, inte teknisk:

• Befintliga manuella spärrar i källsystemen (t.ex. filterregler i export) kan fortsätta gälla som tidigare; funktionen kräver inte att dessa tas bort.
• Organisationen kan, när funktionen är på plats, successivt:
  • inventera vilka personer/relationer som i dag hanteras manuellt,
  • lägga in motsvarande spärrar i Vklass spärrlista (kontospärrar eller relationsspärrar),
  • dokumentera i sina lokala rutiner att Vklass spärrlista nu är det primära verktyget för blockering på Vklass‑sidan.
• Om Vklass idag har interna, kundspecifika lösningar för vissa spärrfall (t.ex. hårdkodade undantag i importlogiken) kan dessa vid behov:
  • fasas ut när motsvarande spärrar finns i den nya spärrlistan,
  • eller ligga kvar om de av tekniska skäl inte lämpligen flyttas; i så fall dokumenteras att vissa spärrar fortsatt hanteras på ”gammalt” sätt.

Ingen automatiserad massmigrering av befintliga manuella spärrlistor till den nya spärrstrukturen förutsätts i denna funktion; det bedöms i första hand som ett verksamhetsprojekt per organisation att:

• identifiera vilka blockeringar man vill spegla i Vklass,
• lägga in dem successivt via gränssnittet.

Migrering av befintliga alias/TF‑konton och dubbletter

Funktionen inför inga automatiska sammanslagningar eller raderingar av existerande konton vid driftsättning. Alla åtgärder är manuellt initierade av org‑admin. Det innebär att:

• Alias‑konton, TF‑konton och dubbletter som redan finns i Vklass fortsätter som tidigare tills org‑admin aktivt:
  • slår ihop dem,
  • markerar dem för radering,
  • eller spärra inläsning.
• Organisationen kan välja att:
  • genomföra en riktad genomgång av kända problemfall (t.ex. dubbletter, gamla alias som inte längre ska användas) och åtgärda dessa med den nya funktionen, eller
  • använda funktionen framåtriktat i samband med att nya fall upptäcks, utan att göra en stor initial ”storstädning”.

Det krävs ingen datamigrering på tabellnivå för att befintliga konton ska kunna omfattas av funktionen; allt bygger på att kontona redan finns i den ordinarie användarstrukturen och kan sökas fram.

Övergång från supportärenden till lokal hantering

I nuläget behöver många organisationer vända sig till Vklass support för t.ex.:

• gallring/radering av konton och data,
• hopslagning av konton,
• specialfall kring blockering av vårdnadshavare eller specifika relationer.

Med den nya funktionen är avsikten att:

• en stor del av dessa ärenden ska kunna hanteras lokalt av org‑admin,
• Vklass support främst behöver involveras vid:
  • komplex felsökning (t.ex. historiska organisationskopplingar, systemfel),
  • ändringar på systemnivå utanför funktionen (t.ex. ändrad integrationskonfiguration, specialfall med flera organisationer).

I samband med driftsättning bör Vklass:

• uppdatera externa hjälpartiklar så att organisationer vet:
  • vilka typer av åtgärder de nu kan göra själva,
  • när de fortfarande behöver skapa supportärenden,
• informera befintliga kunder (särskilt pilotkunder) om hur övergången från gamla rutiner sker praktiskt.

Utbildning och införandestöd

För att funktionen ska användas korrekt och säkert behöver org‑admin få grundläggande utbildning och dokumentation. I samband med att funktionen aktiveras för en organisation bör följande finnas tillgängligt:

• Kortfattad administratörsguide (PDF/webb) som beskriver:
  • syfte och övergripande flöden (radering med karens, direkt radering, sammanslagning, spärrar),
  • hur man söker fram användare och relationer,
  • vad spärrlista och karenslista innebär och hur de används.
• Exempel på rekommenderade interna rutiner hos huvudmannen, t.ex.:
  • vem får radera och slå ihop konton,
  • hur beslut om att spärra vårdnadshavare–barn‑relationer dokumenteras utanför Vklass,
  • när man ska använda spärr kontra när man ska ändra i källsystemet.
• Eventuellt kortare webbutbildning eller genomgång för pilotorganisationer, där man tillsammans går igenom:
  • typfall (t.ex. dubbla konton, vårdnadshavare som ska stängas av tillfälligt),
  • hur funktionen kopplas till befintliga gallringsplaner.

Återställning och rollback‑strategi

Eftersom funktionen påverkar centrala delar av användarhanteringen bör en rollback‑plan definieras:

• Om allvarliga fel upptäcks vid driftsättning (t.ex. synkroniseringsproblem, felaktig blockering):
  • kan funktionen tillfälligt inaktiveras per organisation via kon

Förvaltning och vidareutveckling

Funktionen för utökad användarhantering är tänkt som en långsiktigt förvaltad kärnkomponent i Vklass, med tydlig ägare på produktsidan och väl definierade gränssnitt mot övriga delar av systemet (särskilt synkronisering, befintlig användarhantering och behörighetssystemet). Förvaltningen omfattar både löpande drift och anpassningar vid förändringar i omvärlden (nya verksamhetssystem, ändrad lagstiftning, nya interna rutiner hos huvudmännen).

I den tekniska förvaltningen ingår:

• Övervakning och hälsa för funktionen
  – Löpande övervakning av bakgrundsjobb kopplade till karensflöde, raderingar, gallring av loggar och tillämpning av spärrlista i synkroniseringsflödet.
  – Larm vid avvikande beteende, t.ex. om raderingar blockeras under längre tid p.g.a. upprepade synkfel, eller om spärrlistan inte kan läsas in.

• Regelbunden gallring och databasunderhåll
  – Säkerställande av att åtgärdsloggar alltid gallras enligt beslutad lagringstid (t.ex. 30 dagar) och att underliggande tabeller inte växer ohämmat.
  – Översyn av index och prestanda för tabeller som används av sökning, karenslista och spärrlista, särskilt i stora organisationer.

• Versionshantering och bakåtkompatibilitet
  – Alla förändringar i funktionen ska vara bakåtkompatibla gentemot befintliga organisationer så långt det är möjligt; ändringar i datamodell och synklogik ska föregås av regressionstester.
  – Feature‑flaggor/konfiguration per organisation ska användas för att kunna rulla ut nya delmoment stegvis.

• Samordning med integrationsförvaltning
  – Varje förändring av synkroniseringslogik i Vklass eller uppdateringar av stödet för nya verksamhetssystem (t.ex. nya versioner av elevregister) ska testas mot karenslogik, spärrlista och kontroller mot synkunderlaget.
  – Tydliga rutiner för hur integrationsförändringar kan påverka raderings‑ och spärrflöden, så att regressioner inte skapas.

• Support och incidenthantering
  – Första linjens support (hos kund) får vägledning via dokumentation och hjälpartiklar; Vklass support fungerar som andra linjen för mer komplexa fel (t.ex. felaktiga synkflöden, historiska kopplingar mot andra organisationer).
  – Incidenter som rör felaktig radering/sammanslagning eller utebliven spärr ska kunna utredas med hjälp av åtgärdsloggar och tekniska loggar inom gällande logglagringstid.

• Dokumentation och utbildningsstöd
  – Löpande uppdatering av administratörsdokumentation, inklusive exempel på rekommenderade arbetssätt.
  – Anpassning av vägledningar vid förändringar i lagstiftning, IMY‑rekommendationer eller vanliga användningsmönster hos kommuner och huvudmän.

På funktionell nivå är vidareutveckling möjlig i flera riktningar. Följande områden bedöms vara särskilt relevanta som potentiella framtida utbyggnader:

• Utökad och mer automatiserad gallring
  – Bygga vidare på de manuella raderings‑ och spärrfunktionerna till mer regelbaserad gallring där organisationen centralt kan definiera tidsregler (t.ex. ”radera konton X år efter avslut”) som sedan körs schemalagt.
  – Förhandsgranskning (”simulering”) av vilka konton och vilken data som skulle påverkas av en viss gallringsregel innan den körs skarpt.

• Massåtgärder och batch‑hantering
  – Stöd för att markera flera konton samtidigt för radering, skapa många spärrar i ett steg eller göra enkla masskorrigeringar (inom samma skyddslogik som i dag).
  – Import av spärrposter från fil (t.ex. CSV) utifrån kommunens egna listor över personer eller relationer som ska blockeras.

• Fler typer av relationer i spärrlistan
  – Utöka spärrfunktionen från vårdnadshavare–barn till andra relationstyper (t.ex. vissa mentorskap, elevhälsorelationer) där det finns behov av att temporärt hindra visning eller åtkomst utan att ändra källdata.
  – Göra spärrlogiken mer konfigurerbar per organisation, t.ex. vilka relationstyper som ska kunna spärras.

• Förfinad delegering av behörighet
  – Införa möjlighet att ge vissa begränsade delar av funktionen till andra roller än org‑admin (t.ex. skolnivåadministratörer som endast får spärra relationer vårdnadshavare–barn på ”sin” enhet, men inte radera konton eller göra sammanslagningar).
  – Finmaskiga rättigheter inom funktionen (”får radera konton”, ”får endast arbeta med spärrlista”, ”får endast se karenslista”).

• Förbättrade rapporter och uppföljning
  – En översiktsvy eller enkel rapportering där organisationen kan se statistik över:

  • antal raderade konton per period,
  • antal genomförda sammanslagningar,
  • hur många och vilka typer av spärrar som är aktiva.
    – Möjlighet att exportera aggregerad, anonymiserad statistik utan personidentifikation, som underlag för intern kvalitetsuppföljning.

• Förbättrade användarflöden och UX‑stöd
  – Guidade flöden för vanliga scenarier (t.ex. ”dubbelkonto vid ändrat personnummer”, ”tillfällig avstängning av vårdnadshavare från ett barn”) som steg‑för‑steg visar vilka åtgärder som är lämpliga i vilken ordning.
  – Kontextuell hjälp direkt i gränssnittet, t.ex. korta förklaringar vid statusfält och knappar (”varför kan jag inte radera detta konto just nu?”).

• API‑stöd och integration mot ärendehanteringssystem
  – På sikt kan det vara aktuellt att exponera vissa delar av funktionaliteten via säkrade API:er, så att kommunens egna ärendehanteringssystem kan initiera eller följa upp åtgärder (t.ex. markera för radering eller spärra relationer) utan att dubbelregistrering krävs.
  – Sådan utbyggnad förutsätter noggrann analys av säkerhet, behörighet och loggning samt tydlig styrning av vilka åtgärder som ska kunna triggas externt.

• Konfigurerbarhet per organisation
  – Möjlighet att konfigurera parametrar som karenstid (standard 48 timmar i dag), logglagringstid eller vilka varningstexter som ska visas, utifrån organisationens interna policys.
  – Stöd för olika ”profileringar” mellan organisationer (t.ex. vissa huvudmän kan vilja arbeta mer med spärrar än med radering).

Varje sådan vidareutveckling behöver vägas mot systemets övergripande arkitektur, säkerhetskrav och dataskyddsprinciper. Grundprincipen även framåt är att:

• funktionaliteten ska vara generell (inte kundspecifik),
• verktygen ska vara kraftfulla men tydligt avgränsade till behöriga administratörer,
• loggning, dataminimering och gallring ska vara inbyggda från början i nya delkomponenter,
• förändringar i synk- och användarmodell alltid föregås av test med verklighetsnära scenarier (inklusive konton med alternativa identiteter som TF‑nummer, manuella konton m.m.).

På så sätt kan funktionen för utökad användarhantering utvecklas vidare över tid utan att kompromissa med robusthet, prestanda eller regelefterlevnad, och samtidigt ge organisationerna mer stöd i sin egen livscykel‑ och gallringshantering.