Ik zoek een manier om met een actiereeks of iets anders automatisch op de hoogte gehouden te worden wanneer er een medewerker gearchiveerd wordt.
Vanuit AFAS worden personen automatisch gearchiveerd na uit dienst, maar het behandelaarsaccount blijft dan nog steeds actief.
Gezien wij nu sinds kort een (ruime) verdubbeling hebben aan behandelaren door de inhuizing van facilitair in onze TOPdesk omgeving is het niet meer eenvoudig bij te houden wanneer er een behandelaar de organisatie verlaat.
Mijn vraag is concreet, hoe kan ik het beste geautomatiseerd een piepsysteem maken dat dagelijks checkt bij de personen of er ook behandelaars aan gekoppeld zitten?
Ik heb wel met de instructie van MyTOPdesk een selectie gebouwd die dit handmatig kan doen, maar ik zie geen mogelijkheid deze gepland uit te voeren en in een actiereeks mee te nemen.
Hebben jullie nog ideeën?
Groetjes,
Sascha
Best answer by Sanne Haller
Maak een gebeurtenis aan die triggert op het archiveren van de persoonskaart. Mijn gebeurtenissen is:
Ik heb het ADMIN account uitgesloten, omdat dit het account is wat het anonimiseren in de omgeving uitvoert (als dit aan staat), dit moet deze actie niet (opnieuw) triggeren. De tijd x minuten na, kan ook verkleind worden, maar dit zorgt er bij ons voor dat de HelloID koppeling klaar is, voordat deze gebeurtenis af gaat.
De actiereeks: Lijkt aan de hand van de gearchiveerde persoonskaart of er een behandelaarskaart is met dezelfde inloggegevens. Je zou deze FIQL query in stap 1 kunnen aanpassen naar een andere waarde. Ik heb gekozen voor de inlognaam omdat deze uniek in TOPdesk moet zijn. Als er een behandelaarskaart gevonden is, dan wordt er een melding aangemaakt. Let op, je moet wel zelf de waardes voor de melding verder invullen.
Mocht je de ‘verbindingen’ gebruiken, dan wordt de autorisatie header vanzelf aangepast en kan je de variabelen verwijderen. Mocht je het nog old skool doen, dan staan de variabelen al klaar en moet je deze enkel invullen.
Later zal ik nog de actiereeks plaatsen die direct controle uitvoert op openstaande tickets. Maar gezien dat niet direct jullie vraag was, hierbij de actiereeks voor het automagische seintje.
Wil je een actiereeks die enkel een signaal geeft (als zijne een melding aanmaakt ofzo)?
Of zou je liefst een actiereeks hebben die de behandelaar archiveert en eventueel kijkt of er meldingen/wijzigingen/activiteiten op diens naam heeft zijn en deze op de behandelaarsgroep (of dergelijk) terug zet?
Ik had gehoopt nu er een behandelaars koppeling op de persoonskaart is de behandelaar ook wordt gearchiveerd. Maar blijkbaar is dat niet zo anders had jij de vraag niet gesteld. Ik heb er zelf nog niet naar gekeken.
Mooie vraag, ik ben ook erg benieuwd of hier een mogelijkheid voor is. Wat mij betreft hoeft het niet geautomatiseerd, maar als hierover een melding gemaakt kan worden met daarin welke accounts het betreft, dan kan ik hier handmatig naar kijken en beoordelen wat de vervolgacties zijn.
Ik zoek vooral een manier om te weten als de betreffende persoonskaart een behandelaar heeft, gearchiveerd is. Ik wil dan nog steeds het liefst handmatig de behandelaar uitzetten (ter controle op de automatisering). Maar de ideeën die ik lees zijn ook interessant. Hopelijk heeft iemand al een manier uitgevonden om dat seintje te krijgen.
Voor nu is weten wanneer de persoonskaart gearchiveerd is voldoende. Alleen dan wel automatisch en het liefst met een wijziging, maar melding of mail mag ook als dat niet anders kan.
Wil je een actiereeks die enkel een signaal geeft (als zijne een melding aanmaakt ofzo)?
Of zou je liefst een actiereeks hebben die de behandelaar archiveert en eventueel kijkt of er meldingen/wijzigingen/activiteiten op diens naam heeft zijn en deze op de behandelaarsgroep (of dergelijk) terug zet?
Dit betreft dus het eerste punt @Sanne Haller dat je bedoelt. Ik zie geen mogelijkheid hierop te monitoren.
Ik zoek vooral een manier om te weten als de betreffende persoonskaart een behandelaar heeft, gearchiveerd is. Ik wil dan nog steeds het liefst handmatig de behandelaar uitzetten (ter controle op de automatisering). Maar de ideeën die ik lees zijn ook interessant. Hopelijk heeft iemand al een manier uitgevonden om dat seintje te krijgen.
Voor nu is weten wanneer de persoonskaart gearchiveerd is voldoende. Alleen dan wel automatisch en het liefst met een wijziging, maar melding of mail mag ook als dat niet anders kan.
Wil je een actiereeks die enkel een signaal geeft (als zijne een melding aanmaakt ofzo)?
Of zou je liefst een actiereeks hebben die de behandelaar archiveert en eventueel kijkt of er meldingen/wijzigingen/activiteiten op diens naam heeft zijn en deze op de behandelaarsgroep (of dergelijk) terug zet?
Dit betreft dus het eerste punt @Sanne Haller dat je bedoelt. Ik zie geen mogelijkheid hierop te monitoren.
Ik heb een actiereeks gemaakt die het automatische archiveren doet, met de check op openstaande tickets. Het is niet heel moeilijk om vandaaruit een melding aan te laten maken zodat jullie een controle kunnen uitvoeren. Je kan natuurlijk ook een actiereeks maken de enkel controleert of er een behandelaar is, en niet zelf acties uitvoert maar enkel een melding aan maakt.
Als ik volgende week wat tijd heb, kan ik de aciereeks wel uitschrijven en het JSON bestand anonimiseren.
Ik zoek vooral een manier om te weten als de betreffende persoonskaart een behandelaar heeft, gearchiveerd is. Ik wil dan nog steeds het liefst handmatig de behandelaar uitzetten (ter controle op de automatisering). Maar de ideeën die ik lees zijn ook interessant. Hopelijk heeft iemand al een manier uitgevonden om dat seintje te krijgen.
Voor nu is weten wanneer de persoonskaart gearchiveerd is voldoende. Alleen dan wel automatisch en het liefst met een wijziging, maar melding of mail mag ook als dat niet anders kan.
Wil je een actiereeks die enkel een signaal geeft (als zijne een melding aanmaakt ofzo)?
Of zou je liefst een actiereeks hebben die de behandelaar archiveert en eventueel kijkt of er meldingen/wijzigingen/activiteiten op diens naam heeft zijn en deze op de behandelaarsgroep (of dergelijk) terug zet?
Dit betreft dus het eerste punt @Sanne Haller dat je bedoelt. Ik zie geen mogelijkheid hierop te monitoren.
Ik heb een actiereeks gemaakt die het automatische archiveren doet, met de check op openstaande tickets. Het is niet heel moeilijk om vandaaruit een melding aan te laten maken zodat jullie een controle kunnen uitvoeren. Je kan natuurlijk ook een actiereeks maken de enkel controleert of er een behandelaar is, en niet zelf acties uitvoert maar enkel een melding aan maakt.
Als ik volgende week wat tijd heb, kan ik de aciereeks wel uitschrijven en het JSON bestand anonimiseren.
Dat zou geweldig zijn als je die deelt, ik kom gewoon niet uit de uitvoering. Het gaat dus om de koppeling wanneer een persoon wordt gearchiveerd en dan om de behandelaar die daarmee linkt te signaleren.
Maak een gebeurtenis aan die triggert op het archiveren van de persoonskaart. Mijn gebeurtenissen is:
Ik heb het ADMIN account uitgesloten, omdat dit het account is wat het anonimiseren in de omgeving uitvoert (als dit aan staat), dit moet deze actie niet (opnieuw) triggeren. De tijd x minuten na, kan ook verkleind worden, maar dit zorgt er bij ons voor dat de HelloID koppeling klaar is, voordat deze gebeurtenis af gaat.
De actiereeks: Lijkt aan de hand van de gearchiveerde persoonskaart of er een behandelaarskaart is met dezelfde inloggegevens. Je zou deze FIQL query in stap 1 kunnen aanpassen naar een andere waarde. Ik heb gekozen voor de inlognaam omdat deze uniek in TOPdesk moet zijn. Als er een behandelaarskaart gevonden is, dan wordt er een melding aangemaakt. Let op, je moet wel zelf de waardes voor de melding verder invullen.
Mocht je de ‘verbindingen’ gebruiken, dan wordt de autorisatie header vanzelf aangepast en kan je de variabelen verwijderen. Mocht je het nog old skool doen, dan staan de variabelen al klaar en moet je deze enkel invullen.
Later zal ik nog de actiereeks plaatsen die direct controle uitvoert op openstaande tickets. Maar gezien dat niet direct jullie vraag was, hierbij de actiereeks voor het automagische seintje.
Maak een gebeurtenis aan die triggert op het archiveren van de persoonskaart. Mijn gebeurtenissen is:
Ik heb het ADMIN account uitgesloten, omdat dit het account is wat het anonimiseren in de omgeving uitvoert (als dit aan staat), dit moet deze actie niet (opnieuw) triggeren. De tijd x minuten na, kan ook verkleind worden, maar dit zorgt er bij ons voor dat de HelloID koppeling klaar is, voordat deze gebeurtenis af gaat.
De actiereeks: Lijkt aan de hand van de gearchiveerde persoonskaart of er een behandelaarskaart is met dezelfde inloggegevens. Je zou deze FIQL query in stap 1 kunnen aanpassen naar een andere waarde. Ik heb gekozen voor de inlognaam omdat deze uniek in TOPdesk moet zijn. Als er een behandelaarskaart gevonden is, dan wordt er een melding aangemaakt. Let op, je moet wel zelf de waardes voor de melding verder invullen.
Mocht je de ‘verbindingen’ gebruiken, dan wordt de autorisatie header vanzelf aangepast en kan je de variabelen verwijderen. Mocht je het nog old skool doen, dan staan de variabelen al klaar en moet je deze enkel invullen.
Later zal ik nog de actiereeks plaatsen die direct controle uitvoert op openstaande tickets. Maar gezien dat niet direct jullie vraag was, hierbij de actiereeks voor het automagische seintje.
Hoop dat dit is wat jullie zoeken.
Dit kan voor ons ook een mooie worden. Als de controle er ook nog bij kan is dat helemaal mooi 😀
Maak een gebeurtenis aan die triggert op het archiveren van de persoonskaart. Mijn gebeurtenissen is:
Ik heb het ADMIN account uitgesloten, omdat dit het account is wat het anonimiseren in de omgeving uitvoert (als dit aan staat), dit moet deze actie niet (opnieuw) triggeren. De tijd x minuten na, kan ook verkleind worden, maar dit zorgt er bij ons voor dat de HelloID koppeling klaar is, voordat deze gebeurtenis af gaat.
De actiereeks: Lijkt aan de hand van de gearchiveerde persoonskaart of er een behandelaarskaart is met dezelfde inloggegevens. Je zou deze FIQL query in stap 1 kunnen aanpassen naar een andere waarde. Ik heb gekozen voor de inlognaam omdat deze uniek in TOPdesk moet zijn. Als er een behandelaarskaart gevonden is, dan wordt er een melding aangemaakt. Let op, je moet wel zelf de waardes voor de melding verder invullen.
Mocht je de ‘verbindingen’ gebruiken, dan wordt de autorisatie header vanzelf aangepast en kan je de variabelen verwijderen. Mocht je het nog old skool doen, dan staan de variabelen al klaar en moet je deze enkel invullen.
Later zal ik nog de actiereeks plaatsen die direct controle uitvoert op openstaande tickets. Maar gezien dat niet direct jullie vraag was, hierbij de actiereeks voor het automagische seintje.
Hoop dat dit is wat jullie zoeken.
Ik heb eindelijk tijd gehad hem in elkaar te zetten in de testomgeving!
Wat is dit geweldig en super voorbereid en uitgewerkt!
Bij ons loopt een gelijkaardig process, maar bij ons wordt de behandelaar automatisch gearchiveerd. Ik heb de actiereeks ietwat aangepast om jouw aan noden te voldoen. Ik voeg hier ook de actiereeksen toe.
Wat doet het process?
Archivering van een persoon
De actiereeks IUD - Leaver wordt geactiveerd van zodra een persson is gearchiveerd.
Deze actiereeks volgt volgende stappen
Opzoeken van de persoon uit dienst
Opzoeken van de gekoppelde behandelaar (indien er een is)
Volgende parameters zijn in te stellen in de variabelen.
Opzoekveld
Opzoekwaarde
Een ticket aanmaken op tweede lijn.
Behandelaar updaten met het meldingen nummer in een vrij tekst veld. Dit zal later gebruikt worden bij het archiveren van de behandelaar
Archiveren van de behandelaar
De actiereeks IUD - Leaver - 1.0 - Operator Archived wordt geactiveerd van zodra een behandelaar is gearchiveerd.
Deze actiereeks stuurt de gegevens door naar de webhook automatisatie : IUD - Leaver - 2.0 - Lookup Tasks of Operator
Volgende gegevens worden meegegeven naar de webhook
Meldingen nummer
ID van de behandelaar
De actiereeks IUD - Leaver - 2.0 - Lookup Tasks of Operator voert volgende stappen uit
Ophalen van de melding
Ophalen van niet gesloten meldingen gekoppeld aan de behandelaar.
Controleren of er taken zijn
Indien er taken zijn, gegevens doorsturen naar de webhook IUD - Leaver - 2.1 - Reassign calls
Volgende gegevens worden meegegeven naar de webhook
Meldingen nummer
ID van de behandelaar
Indien er geen taken zijn, actie toevoegen in de melding.
De actiereeks IUD - Leaver - 2.1 - Reassign calls voert volgende stappen uit
Ophalen van de melding
Ophalen van niet gesloten meldingen gekoppeld aan de behandelaar. in groepjes (batch) van 20 meldingen per keer. (Dit is in te stellen in variabelen.)
Controleren of het aantal meldingen groter of gelijk is dan de batch
Herhaalde stap
Melding ophalen
Melding terug toewijzen aan de behandelaarsgroep
Indien de batch groter of gelijk aan het aantal meldingen uit stap 2, stuur volgende gegevens terug naar IUD - Leaver - 2.1 - Reassign calls
Meldingen nummer
ID van de behandelaar
Indien de batch kleiner is dan aan het aantal meldingen uit stap 2, actie toevoegen in de melding
Je kan dit process uitbreiden naar de andere modulles zoals wijzigingsbeheer, operationeelbeheer, probleembeheer
@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.
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.
@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"},
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).
@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.
@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)
