Automatisch seintje (melding / wijziging) bij archiveren persoon die ook behandelaar is

​@Sanne Haller : ik ben een nieuweling op het gebied van automatische acties en ik vond het toch nog niet zo makkelijk. Ik heb hem uiteindelijk wel aan de praat gekregen (met een beetje hulp van een collega), maar hij is niet zo sjiek als die van jou.

Bij mij geeft hij steeds de melding {"message":"The value for the field 'callerLookup.id' cannot be parsed."}. En als ik deze opgelost heb, dan meld hij hetzelfde over entrytype enzovoort.

Als ik "entryType": "Service request", intyp heb ik dan de syntax fout?

Ook kwam ik erachter dat mensen die een gearchiveerde behandelaaraccount hebben, alsnog uit deze actie komen. Maar die had je waarschijnlijk zelf inmiddels ook al ontdekt.

Ik heb bewust geen uitsluiting gedaan op gearchiveerde behandelaarskaarten. Mogelijk moeten er nog aanpassingen gedaan worden, nu de persoon de organisatie gaat verlaten ;)

Wil je archiveerde behandelaarskaarten niet mee tellen, dan wordt de URL in stap 1: /tas/api/operators?query=loginName==${tasloginnaam};archived==false

Dan wordt er geen melding meer aangemaakt, omdat stap 1 dus alleen actieve kaarten ophaalt.

De error: "The value for the field 'callerLookup.id' cannot be parsed." krijg je veelal als er een fout in je json zit. Een “ te veel of te weinig bijvoorbeeld.

De regel moet echt zijn "callerLookup": {"id" : "UNID van aanmelder"},
Bij het vervangen van de tekst UNID van aanmelder, moet je goed opletten dat je niet per ongeluk een leesteken weg haalt. Daarbij moet je echt een ID invoeren en niet een naam van een persoonskaart.

Zelfde geldt voor de syntax fout bij entryType. Je moet hier een ID invullen en geen naam. Wil je bij hier een naam invullen ipv een ID, dan moet de regel anders (Ler op alle leestekens):
"entryType": {"name":"naam invoeren"},

Hoop dat dit je weer wat verder helpt!

Succes.

Met alle mooie actiereeksen die al zijn aangeboden, kan deze er ook nog bij.😉
Deze actiereeks kijkt naar de personenkaart en archiveert automatisch de bijbehorende behandelaarskaart.
Importeer de JSON in “Ondersteunende bestanden – Persoon” en koppel vervolgens de trigger/gebeurtenis aan de actiereeks.

 

 

Lekker bezig! Ik heb er eentje die nog verder gaat ;p (maar nog geen tijd om hem helemaal uit te schrijven).

Hij doet ook controleren of de persoon nog aanvragen goed te keuren heeft (zoja, dan worden deze op de nieuwe manager van de aanvrager gezet). En voor de behandelaar wordt er gekeken of er niet nog ticket (alle smaakjes) op de naam open staan (zoja, dan worden ze terug gezet naar behandelaarsgroepen). En omdat wij opzoekvelden gebruiken voor Afdeling en budgethouder, worden deze ook nog even leeg gehaald. 

De volgende stap van verbetering wordt het documenteren van taken, behandelaarsgroepen en rechtengroepen. Om ze daarna te ontkoppelen.

Met alle mooie actiereeksen die al zijn aangeboden, kan deze er ook nog bij.😉
Deze actiereeks kijkt naar de personenkaart en archiveert automatisch de bijbehorende behandelaarskaart.
Importeer de JSON in “Ondersteunende bestanden – Persoon” en koppel vervolgens de trigger/gebeurtenis aan de actiereeks.

 

 

Lekker bezig! Ik heb er eentje die nog verder gaat ;p (maar nog geen tijd om hem helemaal uit te schrijven).

Hij doet ook controleren of de persoon nog aanvragen goed te keuren heeft (zoja, dan worden deze op de nieuwe manager van de aanvrager gezet). En voor de behandelaar wordt er gekeken of er niet nog ticket (alle smaakjes) op de naam open staan (zoja, dan worden ze terug gezet naar behandelaarsgroepen). En omdat wij opzoekvelden gebruiken voor Afdeling en budgethouder, worden deze ook nog even leeg gehaald. 

De volgende stap van verbetering wordt het documenteren van taken, behandelaarsgroepen en rechtengroepen. Om ze daarna te ontkoppelen.

Ik ben benieuwd hoe je een check hebt gedaan met openstaande: meldingen, wijzigingen, problemen, etc en deze op de groep terug te zetten. Het gevaar is dat je weer een lege behandelaarsgroep overhoudt.

Verder kunnen behandelaren koppelingen hebben met sjablonen, persoonlijke selecties/rapportages, kunnen zij aanspreekpunt zijn van een behandelaarsgroep.

En vind ik het altijd wijs om alle taken van een behandelaar voor het archiveren eraf te halen, eventuele rechtengroepen die bij uitzondering op een behandelaar zitten eraf te halen.
 

​@Alexander Ik snap niet wat je bedoeld met “Het gevaar is dat je weer een lege behandelaarsgroep overhoudt”. 
Je zet meldingen juist op de behandelaarsgroep, zodat andere behandelaren sneller zien dat de tickets overgepakt moeten worden.

Hoe de ticket (MLB en WZB enkel nog) op te halen, met een GET stap, met een query die enkel de openstaande tickets die op die specifieke behandelaar staat. Ik kan de actiereeks delen, wil je die vanuit de persoonskaart of vanuit de behandelaarskaart? (zonder verdere uitleg erbij, want daar heb ik op dit moment echt geen tijd voor helaas).

Ik heb ik de omgeving alle sjablonen op behandelaarsgroepen gezet ipv specifieke personen, dus dat komt hier al niet meer voor.

Voor de rest ja, dat is nog niet opgevangen, behalve het piepjes systeem. Maar de automatisering scheelt nu al zoveel werk, dat er langzaam aan meer tijd komt voor meer verbeteringen (zover als er endpoint voor zijn natuurlijk).

Ik doel op de mogelijkheid dat als je automatisch accounts opruimt en tickets op de groep zet, dat het mogelijk is dat je een groep overhoudt zonder behandelaren en dat de tickets dus alsnog door niemand opgepakt worden. 

Bij ons zitten vaak behandelaren in meerdere groepen en over meerdere “domeinen” (datascheiding), waardoor er helaas veel handmatige acties benodigd zijn. 

Ik heb de tickets liever op een behandelaarsgroep staan, ookal zitten er geen behandelaren meer in.. Dan op een gearchiveerde behandelaar. De kans dat een behandelaarsgroep een nieuwe behandelaar krijgt en daardoor het ticket weer ziet, is naar mijn idee groter dan dat wanneer de ticket op de gearchiveerde behandelaar staat.

Wel weer een leuk moment om automatisering te maken… Eentje die je contactpersoon of het beheer op de hoogte stelt dat een behandelaarsgroep zonder behandelaren is…

Over je 2e punt, maar een ticket is altijd gekoppeld aan een behandelaar vanuit een behandelaarsgroep… Dus dan maakt het toch niet uit dat een behandelaar meerdere behandelaarsgroepen heeft, de automatisering kijkt naar het specifieke ticket en vanuit welke behandelaarsgroep het ticket op de behandelaar gezet is…. (ten minste, mijn automatisering kijkt zo)