Ärendehanterare

Ärendehanteraren är uppbyggd kring en tydlig separation mellan vad ärendet är, hur ärendet ska bete sig, var det hanteras, vem som arbetar med det och vad som har hänt under ärendets livscykel.

Systemets kärna består av konfigurerbara ärendetyper, statusflöden, köer, deltagare, dynamiska komponenter, fält, tabeller, timeline-händelser och eventdriven processlogik. Målet är att nya ärendetyper ska kunna läggas till genom konfiguration i stället för att varje ärendetyp behöver hårdkodas.

När en användare skapar ett ärende börjar flödet i ett klassificeringsträd. Klassificeringsträdet beskriver verksamhetens sätt att kategorisera ärenden, till exempel process, kategori, underkategori och specifik ärendeorsak.

CaseClassificationNode beskriver noderna i detta träd. Varje nod kan ha en överordnad nod, vilket gör att trädet kan ha valfritt antal nivåer. En slutnod kan peka på en CaseType.

CaseType är den centrala definitionen för hur ett ärende ska fungera. Den styr statusar, initial status, default-prioritet, default-kö, eventuell default-handläggare, komponenter, fält, tabeller, triggers, actions och eskaleringsregler.

Det är möjligt att flera klassificeringsnoder pekar på samma CaseType om de ska hanteras enligt samma process.

Case är den faktiska ärendeinstansen. Den innehåller ärendets aktuella kärndata och pekar på sin CaseType, vald klassificeringsnod, aktuell status och aktuell prioritet.

Case innehåller även uppgifter som ärendenummer, titel, beskrivning, skapare, aktuell handläggare, inlämningsdatum, statusändringsdatum, tilldelningsdatum, senaste hanteringsdatum och stängningsdatum.

Case är den centrala noden i modellen. Övriga objekt, exempelvis timeline, fältvärden, tabellrader, deltagare, bilagor och konversationer kopplas direkt eller indirekt till Case.

CaseQueue beskriver en ärendekö eller arbetsyta, till exempel Inköp – Leveransavvikelser, Logistik – Transportskador eller MDM – Artikelupplägg.

CaseQueueItem beskriver kopplingen mellan ett ärende och en kö. Ett ärende kan ha flera aktiva kökopplingar samtidigt. Detta gör att samma ärende kan vara synligt i flera arbetskontexter utan att dupliceras.

Den faktiska handläggaren anges på Case genom CurrentAssigneeUserId. Om värdet är tomt är ärendet inte operativt tilldelat en specifik person. Om värdet är satt arbetar den personen med ärendet.

Kömedlemskap och handläggartilldelning är två separata begrepp:

• CaseQueueItem anger vilka köer ärendet tillhör och därmed kan vara synligt i.
• CurrentAssigneeUserId anger vem som för närvarande handlägger ärendet.

När en användare plockar ett ärende från kö kontrollerar systemet att ärendet inte är stängt, att det inte redan är tilldelat en annan användare och att det finns minst en aktiv kökoppling. Därefter sätts CurrentAssigneeUserId, AssignedOn och LastHandledOn. Systemet skriver även assignment history, timeline event och outbox event.

Ett ärende kan också tilldelas direkt till en specifik användare utan att vara kopplat till någon kö. I dessa fall krävs ingen kökoppling.

När ett ärende skickas vidare till en kö utan specifik handläggare säkerställs kökopplingen, aktuell handläggare nollas och ärendet blir åter tillgängligt som köbaserat arbete.

CasePriority beskriver tillgängliga prioriteter, exempelvis Låg, Medel, Hög och Kritisk.

Case pekar på en CasePriority. CaseType kan ange en DefaultCasePriorityId som används när ett nytt ärende skapas om ingen explicit prioritet anges vid submit.

Prioritetsupplösningen sker i följande ordning:
1. explicit prioritet från submit-flödet
2. default-prioritet från CaseType
3. fel om ingen prioritet kan fastställas

CaseTypeStatus beskriver en status som hör till en specifik ärendetyp. Olika ärendetyper kan därför ha helt olika statusar och statusflöden.

Exempel för en leveransavvikelse:

• Nytt
• Tilldelat
• I arbete
• Väntar på svar från leverantör
• Pris klart
• Slutfört

Exempel för ett chefsbeslut:

• Nytt
• Väntar på godkännande från chef
• Godkänt
• Avslaget
• Slutfört

CaseTypeStatusTransition beskriver vilka statusbyten som är tillåtna för en CaseType. Både manuella statusbyten och statusbyten via actions valideras mot dessa transitions.

När status ändras kontrollerar systemet aktuell status, målstatus, att målstatus hör till samma CaseType och att en aktiv transition finns. Därefter uppdateras Case med ny status, StatusChangedOn, LastHandledOn och eventuellt ClosedOn om målstatus är terminal.

Systemet är eventdrivet. Viktiga förändringar i ett ärende skapar händelser som kan användas för timeline, outbox, notifieringar, integrationer och processlogik.

Exempel på event:

• CaseSubmitted
• CaseStatusChanged
• CaseAssigned
• CaseForwarded
• CaseClaimed
• CasePriorityChanged
• CaseEscalated

CaseTypeEventTrigger definierar att något ska hända när ett visst event inträffar för en viss ärendetyp. Triggers kan filtreras med ConditionJson, exempelvis på från-status, till-status eller statuskod.

CaseEventTriggerAction beskriver vad systemet ska göra när en trigger matchar. Exempel på actiontyper:

• AssignQueue
• AssignUser
• SetStatus
• SetPriority
• AddTimelineEvent

Exempel: När ett ärende ändras till status Pris klart kan en trigger matcha CaseStatusChanged och köra en AssignUser-action som tilldelar ärendet tillbaka till den användare som skapade ärendet.

CaseTimelineEvent sparar vad som har hänt i ärendet och används för att bygga ärendets historik i UI.

Timeline-händelser lagras som:

• EventType
• DataJson
• Summary
• PerformedById
• OccurredOn
• IsSystemGenerated

EventType är den stabila händelsekoden. DataJson innehåller strukturerad eventdata som varierar beroende på händelsetyp. Summary används endast för fri användartext, till exempel en kommentar vid statusbyte eller vidarebefordran.

UI ansvarar för att rendera rätt text på rätt språk utifrån EventType och DataJson.

Exempel för CaseStatusChanged:
{
"fromCaseTypeStatusId": 3,
"toCaseTypeStatusId": 4,
"fromStatusCode": "IN_PROGRESS",
"toStatusCode": "PRICE_READY"
}

Exempel för CaseAssigned:
{
"changeType": "Assign",
"previousCaseQueueId": 10,
"previousAssigneeUserId": null,
"newCaseQueueId": 10,
"newAssigneeUserId": "abc123"
}

CaseOutboxMessage är systemets tekniska utbox för event som ska kunna konsumeras av bakgrundsjobb, notifieringar, integrationer, SignalR-uppdateringar eller workflows.

När CaseService gör en viktig affärsändring skapas ett outbox-meddelande i samma databasflöde. Ett bakgrundsjobb (Hangfire), kan därefter läsa och bearbeta meddelandet.

Principen är:
1. CaseService gör affärsändringen.
2. CaseService skriver CaseOutboxMessage.
3. Bakgrundsjobb konsumerar outbox.
4. Notifieringar, integrationer eller workflows körs i efterhand.

Detta ger robusthet eftersom event inte behöver hanteras synkront i samma UI-anrop.

CaseAssignmentHistory sparar strukturerad historik över tilldelningar, claims, vidarebefordringar, omfördelningar, automatiska tilldelningar och eskaleringar.

Den innehåller bland annat:

• tidigare kö
• ny kö
• tidigare handläggare
• ny handläggare
• ChangeType
• kommentar
• ändrad av
• ändrad tidpunkt
• om ändringen var systemgenererad

Timeline används för presentation av händelser. Assignment history används för mer detaljerad spårbarhet kring just tilldelningslogik.

CaseEscalationRule definierar när ett ärende ska eskaleras. En regel kan kopplas till CaseType, eventuell CaseTypeStatus, tidsgräns, mål-kö och mål-användare.

Exempel:
För ärendetyp Leveransavvikelse, om status är Väntar på svar från leverantör och ärendet inte har hanterats på tre dagar, eskalera till en chefskö eller en viss användare.

CaseEscalationExecution sparar att en eskaleringsregel faktiskt har körts för ett ärende. Det gör att systemet kan undvika dubbla körningar och ger spårbarhet kring när och varför en eskalering utfördes.

Ett bakgrundsjobb kan regelbundet kontrollera vilka ärenden som uppfyller aktiva eskaleringsregler och därefter utföra eskaleringen.

CaseTypeComponent beskriver vilka byggblock en ärendetyp använder. Detta gör att olika ärendetyper kan ha olika innehåll utan specialkod per ärendetyp.

Exempel på komponenttyper:

• Form
• FileCollection
• Table
• Discussion
• ThirdPartyThreads
• Participants
• CustomStructuredData

Varje komponent kan ha typ, sorteringsordning, settings json och kopplingar till fält eller tabellkonfiguration.

Exempel:
CaseType Leveransavvikelse kan innehålla:
1. formulär med ordernummer, leverantör och leveransdatum
2. tabell med artikelrader
3. bilagor
4. diskussion
5. deltagare

En annan ärendetyp kan använda helt andra komponenter.

CaseFieldDefinition beskriver ett återanvändbart fält, exempelvis Ordernummer, Leverantör, Leveransdatum, Beskrivning eller Önskad lösning.

CaseTypeField kopplar ett fält till en specifik komponent och definierar hur fältet används i just den kontexten. Här kan man ange sorteringsordning, obligatoriskt fält, inställningar och eventuell presentation.

CaseFieldValue innehåller det faktiska värdet på ett specifikt ärende. Det pekar på Case och CaseTypeField.

Detta gör att samma fältdefinition kan återanvändas över flera ärendetyper men med olika beteende per ärendetyp eller komponent.

Vissa ärendetyper behöver tabellbaserad data, exempelvis artikelrader, orderrader, kontrollpunkter eller avvikelserader.

CaseTableDefinition beskriver en tabelltyp för en komponent.
CaseTableColumnDefinition beskriver kolumnerna i tabellen.
CaseTableRow beskriver en faktisk rad på ett ärende.
CaseTableCell beskriver cellvärdet i en viss rad och kolumn.

Exempel: Case INT-14589 Tabell: Artiklar i ärendet Rad 1:

• Artikelnummer = XPZ 1287 XEP
• Antal beställt = 5
• Antal levererat = 3

Denna modell gör att tabellstrukturer kan definieras per ärendetyp utan att skapa specialtabeller för varje variant.

CaseParticipant beskriver vem eller vad som deltar i ett ärende.

Det kan vara:

• skapare
• handläggare
• intern deltagare
• extern part
• grupp
• systemaktör

Deltagare används som grund för kommunikation, synlighet och behörighet. Ett ärende kan ha flera deltagare, och deltagare kan användas som författare i meddelanden och konversationstrådar.

CaseDiscussionMessage är huvudkanalen för ärendenära diskussion. Detta är den vanliga ärendechatten där deltagare kan skriva meddelanden.

Den pekar på:

• Case
• CaseParticipant som författare

Denna diskussion kan användas av interna och externa deltagare beroende på åtkomstregler.

CaseConversationThread beskriver en separat diskussionstråd i ett ärende. Den används när en avgränsad konversation behövs, exempelvis med en extern leverantör, kund eller tredje part.

CaseConversationParticipant kopplar deltagare till en viss konversationstråd. Alla deltagare i ärendet behöver inte vara deltagare i alla trådar.

CaseConversationMessage är ett meddelande i en specifik tråd och pekar på tråden samt den CaseParticipant som är författare.

Detta gör att ett ärende kan ha flera parallella konversationer med olika deltagaruppsättning.

CaseAttachment representerar filer som kopplas till ärendet.

En bilaga kan kopplas till:

• själva ärendet
• ett diskussionsmeddelande
• ett konversationsmeddelande

Det gör att filer kan placeras i rätt kontext. Exempelvis kan följesedlar och foton kopplas direkt till ärendet, medan en leverantörsbekräftelse kan kopplas till ett specifikt konversationsmeddelande.

När användaren skapar ett ärende sker följande:

1. användaren väljer nod i klassificeringsträdet
2. systemet hämtar kopplad CaseType
3. systemet hämtar initial CaseTypeStatus
4. systemet fastställer prioritet
5. systemet fastställer routing
6. Case skapas
7. ärendenummer genereras
8. CaseQueueItem skapas för relevanta köer
9. eventuell handläggare sätts
10. timeline event CaseSubmitted skapas
11. assignment history skrivs vid routing eller tilldelning
12. outbox event CaseSubmitted skapas
13. event actions för CaseSubmitted körs

När en handläggare plockar ett ärende sker följande:

1. systemet hämtar ärendet
2. systemet kontrollerar att status inte är terminal
3. systemet kontrollerar att ärendet inte är tilldelat annan användare
4. systemet kontrollerar att ärendet har aktiv kökoppling
5. CurrentAssigneeUserId sätts
6. AssignedOn sätts
7. LastHandledOn sätts
8. assignment history skapas
9. timeline event CaseClaimed skapas
10. outbox event CaseAssigned skapas

När ett ärende skickas vidare till en kö sker följande:

1. systemet säkerställer aktiv CaseQueueItem för mottagande kö
2. om ingen handläggare anges nollas CurrentAssigneeUserId
3. AssignedOn nollas
4. LastHandledOn uppdateras
5. assignment history skrivs
6. timeline event, exempelvis CaseForwarded, skapas
7. outbox event skapas

När ett ärende skickas direkt till en användare sätts CurrentAssigneeUserId och AssignedOn. Även då skrivs assignment history, timeline event och outbox event.

När status ändras sker följande:

1. systemet kontrollerar aktuell status
2. systemet kontrollerar målstatus
3. systemet verifierar att målstatus hör till samma CaseType
4. systemet verifierar att en aktiv CaseTypeStatusTransition finns
5. ärendet uppdateras med ny status
6. StatusChangedOn och LastHandledOn uppdateras
7. ClosedOn sätts om målstatus är terminal
8. timeline event CaseStatusChanged skapas
9. outbox event CaseStatusChanged skapas
10. event triggers och actions körs

När ett event inträffar, exempelvis CaseStatusChanged, sker följande:

1. systemet hämtar aktiva CaseTypeEventTrigger för ärendets CaseType
2. systemet filtrerar på EventCode
3. systemet kontrollerar ConditionJson
4. matchande actions körs i sorteringsordning
5. varje action kan uppdatera ärendet

En action kan exempelvis:

• lägga till kökoppling
• tilldela användare
• ändra status
• ändra prioritet
• lägga till timeline event

På detta sätt kan olika ärendetyper reagera olika på samma typ av event.

Flowmotorn kommer startas via actions i CaseTypeEventTrigger

Systemet är en konfigurerbar ärendeplattform där CaseType definierar process, statusar, komponenter, fält, regler och routing, medan Case är den faktiska instansen som rör sig genom systemet.

Klassificeringsträdet hjälper användaren att välja rätt ärendetyp. Statusar och transitions styr livscykeln. Köer och tilldelning styr arbetsfördelningen. Timeline, assignment history och outbox ger spårbarhet, presentation och robust eventhantering. Komponenter, fält och tabeller gör ärendedata dynamisk. Deltagare, diskussioner, konversationstrådar och bilagor stödjer samarbete och kommunikation.

Helheten gör det möjligt att skapa en flexibel ärendehanterare där nya ärendetyper kan införas genom konfiguration och där processlogik kan byggas stegvis genom event, triggers och actions.