Oklara kundkopplingar behöver en fast rutin
Att skicka igen löser inte en oklar kundkoppling. Integrationen behöver en spårbar väg från utredning till ett bekräftat resultat i målsystemet.
Om en integration inte säkert kan koppla kunden till en åtgärd ska fallet fortfarande gå att hantera. Det behövs en ansvarig roll, nödvändig information och en kontrollerad väg tillbaka till bearbetningen. En fellogg och uppmaningen att skicka igen senare löser inte en oklar verksamhetsidentitet.
Microsoft beskriver även manuella ingrepp med en spårbar felorsak i flerstegsförlopp. Vårt exempel väntar innan det skriver till målsystemet.
Ett öppet fall behöver ett synligt resultat
I det helt fiktiva exemplet ska projektförfrågan R-28 skapa ett projektutkast i ERP. CRM-kunden C-508 saknar en bekräftad koppling. Den ansvariga personen fastställer att det befintliga ERP-kundkontot K-410 ska användas. Tabellen beskriver det önskade förloppet.
Tillstånd | Betydelse i exemplet | Vad som återstår |
|---|---|---|
| Kundkopplingen är oklar; inget utkast skapas i målsystemet. | Kontrollera identiteten och bekräfta kopplingen. |
| En koppling har granskats av verksamheten. | Kontrollera aktuella rättigheter och om kundkontot får användas före skrivningen. |
| Överföringen bearbetas. | Bekräftelse av resultatet i målsystemet. |
| Det bekräftade projektutkastet | Den överenskomna överföringen är klar. |
Ett namn i en lista får inte ensamt avgöra kundvalet. Handläggningen måste hålla ihop anledning, kontrollerad källversion, tidigare och vald koppling samt beslutets motivering. Bara den behöriga rollen får åtkomst till dessa fall.
Rättelsen måste ta hänsyn till det aktuella läget
Data eller behörigheter kan ändras mellan visning och bekräftelse. Kontrollera före fortsättningen aktuell behörighet och om det valda kundkontot fortfarande får användas. OWASP kräver behörighetskontroll vid varje begäran. Ett redan öppet redigeringsfönster ersätter inte kontrollen.
Inte heller två samtidiga handläggare får spara motstridiga beslut utan att det märks. Ändrade förutsättningar eller ett redan löst fall måste upptäckas vid bekräftelsen. Om villkoren inte längre stämmer förblir åtgärden öppen för ny utredning.
En upprepning får inte skapa ett andra projektutkast
Alla försök är fortsatt kopplade till samma projektförfrågan. Det kräver också skydd i målsystemet: exempelvis idempotent skapande som inte ger ett extra utkast vid en identisk upprepning, eller en extern referens vars unikhet upprätthålls i målsystemet med tillförlitlig resultatkontroll. Ärendeidentifieraren ensam förhindrar inte dubbletter.
Saknas svaret efter skrivningen ska resultatet av den befintliga åtgärden först klarläggas. AWS påpekar att en timeout inte utesluter redan inträffade sidoeffekter. Innan resultatet har klarlagts får det inte behandlas som ett säkert misslyckande och ersättas med en godtycklig ny förfrågan.
Begränsa den manuella vägen till nödvändiga fall
En entydig, granskad koppling kan bearbetas automatiskt. Mänskligt godkännande behövs inte för varje post. För övriga fall måste ansvar, överenskommen svarstid och eskalering vara synliga; en växande lista utan ansvarig löser inte problemet.
Vårt exempel stannar före projektskapandet. Om något redan har skapats för fel kund behövs en separat verksamhetsmässig rättelse som tar hänsyn till de uppkomna relationerna.
Källor
Läs vidare
Alla artiklar
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade