You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In KISS / PodiumD Contact there is a use case where the employee can search for a specific klantcontact based on the digitaleAdressen that have been provided by the betrokkene. Specifically, only klantcontacten matching the following conditions are shown:
The betrokkene specified digitaleAdressen matching the search query by the employee
The klantcontact resulted in interneTaken
The betrokkene was NOT a partij
These klantcontacten need to be sorted descending on plaatsgevondenOp (I believe this is the default behavior for the api endpoint for klantcontacten).
Right now, the most efficient way to do this seems to be to
Start at /digitaleadressen
Use adres__icontains to filter on the search query by the employee
Expand to verstrektDoorBetrokkene.hadKlantcontact.leiddeTotInterneTaken
Aggregate all pages and deduplicate all klantcontacten (client-side)
Filter out klantcontacten without interneTaken (client-side)
Filter out klantcontacten with a betrokkenen that is a partij (client-side)
Sort on plaatsgevondenOp (client-side)
Possible solution
The following query parameters on the /klantcontacten endpoint would be a big improvement for this use case. In order of priority:
hadBetrokkene__verstrektedigitaalAdres__adres__icontains: this would allow us to use the pagination and sorting of the api endpoint as-is, removing the need to aggregate all pages and deduplicate klantcontacten. We would still need to filter out specific records, possibly resulting in inconsistent page sizes. This can be solved by the next point:
hadBetrokkene__wasPartij=false and leiddeTotInterneTaken=true: this would remove the need to do any filtering client-side, allowing us to offer consistent page sizes.
Toegevoegde waarde / Added value
KCC employees handling questions about customers regarding existing klantcontacten would be able to find the klantcontact they are looking for a lot quicker.
Aanvullende opmerkingen / Additional context
No response
The text was updated successfully, but these errors were encountered:
Thema / Theme
Klantinteracties API
Omschrijving / Description
Context
In KISS / PodiumD Contact there is a use case where the employee can search for a specific
klantcontact
based on thedigitaleAdressen
that have been provided by thebetrokkene
. Specifically, only klantcontacten matching the following conditions are shown:betrokkene
specifieddigitaleAdressen
matching the search query by the employeeklantcontact
resulted ininterneTaken
betrokkene
was NOT apartij
These klantcontacten need to be sorted descending on
plaatsgevondenOp
(I believe this is the default behavior for the api endpoint for klantcontacten).Right now, the most efficient way to do this seems to be to
/digitaleadressen
adres__icontains
to filter on the search query by the employeeverstrektDoorBetrokkene.hadKlantcontact.leiddeTotInterneTaken
plaatsgevondenOp
(client-side)Possible solution
The following query parameters on the
/klantcontacten
endpoint would be a big improvement for this use case. In order of priority:hadBetrokkene__verstrektedigitaalAdres__adres__icontains
: this would allow us to use the pagination and sorting of the api endpoint as-is, removing the need to aggregate all pages and deduplicate klantcontacten. We would still need to filter out specific records, possibly resulting in inconsistent page sizes. This can be solved by the next point:hadBetrokkene__wasPartij=false
andleiddeTotInterneTaken=true
: this would remove the need to do any filtering client-side, allowing us to offer consistent page sizes.Toegevoegde waarde / Added value
KCC employees handling questions about customers regarding existing klantcontacten would be able to find the klantcontact they are looking for a lot quicker.
Aanvullende opmerkingen / Additional context
No response
The text was updated successfully, but these errors were encountered: