Klantinteracties en OpenKlant

Bij het koppelen van KISS aan de Klanteracties-API’s zoals die in Open Klant 2 zijn geimplementeerd, hebben we een aantal keuzes gemaakt bij de inrichting van de gegevens, die in Klantinteracties door de VNG zijn beschreven als items op een Referentielijst.

Klantcontact

De volgende properties uit het Klantcontact vullen we hard in met de volgende waarden:

  • indicatieContactGelukt: altijd true

  • taal: altijd nld

  • vertrouwelijk: altijd false

  • plaatsgevondenOp: altijd de datum van registratie van het klantcontact.

Partij-identificatoren

Sinds de aansluiting op Open Klant 2.7.0 maakt KISS gebruik van partij-identificatoren op de manier zoals dit vanaf deze versie van Open Klant noodzakelijk is. Zie #944

Let op: dit betekent dat KISS versies vóór 1.0.0 niet kunnen koppelen met Open Klant 2.6 of hoger.

Digitale adressen

Sinds de aansluiting op Open KLant 2.2 gebruikt KISS de soorten digitaal adres zoals de API dit voorschrijft. Zie issue #891. De benodigde validatie die sinds Open Klant 2.4 noodzakelijk is, is middels validatie in de KISS-frontend ondersteund. Zie issue #939.

Actor-identificator

Actor klantcontact

De Actor die we opslaan bij het Klantcontact, vullen we op basis van de gegevens van de ingelogde gebruiker, waarbij we er in eerste instantie vanuit gaan dat dit altijd is o.b.v. e-mailadres:


"actoridentificator": {
    "objectId": "user@domein.nl",
    "codeObjecttype": "mdw",
    "codeRegister": "msei",
    "codeSoortObjectId": "email"
    }

Actor Contactverzoek (interneTaak)

Van de Actor die we opslaan bij een interne taak hebben we geen gegevens uit EntraID / OIDC, maar alleen uit Objectenregister. Dus voorlopig slaan we bij deze Actoren ook vast in de code de Actor-identificator properties op, die verwijzen naar het Objectenregister. Bij zowel Afdelingen, Groepen als Medewerkers gebruikt KISS als SoortObjectId de waarde van het property identificatie.

Actoridentificator als medewerker

"actoridentificator": {
    "objectId": "hassel006",
    "codeObjecttype": "mdw",
    "codeRegister": "obj",
    "codeSoortObjectId": "idf"
    }

Actoridentificator medewerker bij handmatig opgevoerd e-mailadres

Op verzoek van de gemeente Utrecht is het mogelijk gemaakt om Contactverzoeken aan te maken voor medewerkers, zonder dat er een Smoelenboek is gekoppeld. Hiervoor is een feature-switch aanwezig (zie ook Installatiehandleiding, onderdeel configuratie, bij Feature switches)

In dat geval wordt de actoridentificator op een iets andere manier opgebouwd.

"actoridentificator": {
	"objectId": "surbhi.jha@info.nl",
	"codeObjecttype": "mdw",
	"codeRegister": "handmatig",
	"codeSoortObjectId": "email"
	}

Actoridentificator als AFDELING

"actoridentificator": {
    "objectId": "PaBH",
    "codeObjecttype": "afd",
    "codeRegister": "obj",
    "codeSoortObjectId": "idf"
    }

Actoridentificator als GROEP

"actoridentificator": {
    "objectId": "VTH_OVG_ZV",
    "codeObjecttype": "grp",
    "codeRegister": "obj",
    "codeSoortObjectId": "idf"
    }

Onderwerp van het Klantcontact: maximale lengte

Binnen KISS kan een KCM zowel een Vraag als een Specifieke vraag opgeven. Een Vraag is altijd de titel van een Kennisartikel, of de Vraag binnen een VAC. Een KCM kan daarbij een specifieke vraag opgeven. Als er géén Kennisartikel of VAC is geraadpleegd, of als er géén is geselecteerd als Vraag, dan is Specifieke vraag verplicht.

Deze twee gegevens worden bij het wegschrijven van een Contactmoment opgeslagen in het property klantcontact.onderwerp. Dit is een property met een maximale lengte van 200 tekens. We gaan een wijzigingsverzoek indienen bij OpenKlant, om te vragen of dit getal kan worden opgehoogd.

Tot die tijd geldt, dat de kans dat de gecombineerde lengte van de twee gegevens groter is dan 200, aanzienlijk is. Om te voorkomen dat een KCM het Contactmoment niet kan opslaan vanwege de lengte, zijn er in KISS de volgende restricties toegevoegd:

  • Een KCM kan niet meer dan 180 tekens invoeren in het veld Specifieke vraag.

  • De inhoud van Specifieke vraag wordt altijd in zijn geheel opgenomen in klantcontact.onderwerp.

  • De inhoud van Vraag wordt afgekapt, zodat de totale lengte niet meer dan 200 teken is.

  • Als er alleen Vraag is, dan wordt Vraag afgekapt tot 197 tekens, en staan er 3 puntjes achter

  • Als er een Vraag én een Specifiek vraag is, dan worden er 6 tekens van Vraag afgehaald: 3 puntjes om aan te geven dat het is afgekapt, en daarna een spatie en de inhoud van Vraag tussen twee haakjes.

De reden dat we Vraag afkappen, is dat deze uiteindelijk altijd gevuld wordt vanuit een Bron. We gaan ervan uit dat men die bron altijd kan opzoeken. We willen Specifieke vraag niet afkappen, omdat dit specifieke info is door de KCM ingevuld.
Vraag wordt altijd wel volledig opgeslagen in de Contactmomentdetails in KISS zelf.

Als OpenKlant wordt aangepast, en de maximale lengte van klantcontact.onderwerp groter wordt, dan zullen deze restricties herzien. Omdat er zeer waarschijnlijk altijd een Maximalen lengte is, zal het principe waarbij we Vraag afkappen waarschijnlijk wel gehandhaafd blijven.