Skip to main content
New Member ⭐⭐⭐⭐
February 11, 2026
Question

Automatische controle op inactieve behandelaarsaccounts

  • February 11, 2026
  • 22 replies
  • 490 views

Goedendag, 😉

Wij ontvangen regelmatig aanvragen voor behandelaarsaccounts. Na het verlenen van toegang blijkt echter dat deze accounts vaak slechts sporadisch of zelfs helemaal niet worden gebruikt.

Daarom overweeg ik om een automatische controle in te richten (bijvoorbeeld op basis van “Laatste actief”), waarbij wordt gekeken naar de activiteit van behandelaarsaccounts. Wanneer er gedurende een bepaalde periode (x aantal weken) geen activiteit of inlogmoment is geweest, zou het account automatisch kunnen worden gearchiveerd.

Mijn idee is om dit via Power Automate in te richten met dan gelijktijdig een informatiemail die naar de betreffende gebruiker wordt verstuurd. Of zou dit binnen TOPdesk ook haalbaar zijn?

Mijn vraag is of iemand hier al ervaring mee heeft en of de TOPdesk-API’s de juiste velden ondersteunen om dit goed te kunnen inrichten.

Groet,

22 replies

JeroenvdK
Explorer ⭐⭐⭐
May 22, 2026

@JeroenvdK Bedankt voor het mooie voorbeeld!

Ik ben op dit moment met een soort gelijke actiereeks bezig maar loop tegen een probleem aan, ik ben benieuwd of jij die ook bent tegengekomen.

Het lijkt er bij mij op alsof /services/active-user-overview/api/all-user-activity alleen ‘lastActive’ data geeft als de gebruiker in de laatste 3 maanden is ingelogd. Er zijn veel gebruikers waarvan ik in de TOPdesk GUI kan zien dat ze inlogdata hebben (bijvoorbeeld, Laatst actief: 13 februari 2026) maar die vervolgens in de JSON geen ‘lastActive’ veld hebben, waardoor ze niet door de ‘GetExpiredOperators’ stap worden gedetecteerd.

Ik ben benieuwd of dit jou ook bekend voorkomt.

Ja hier liep ik ook tegenaan.

Ik heb dit opgelost door de introductie van een vrij datumveld op de Operator kaart waar ik de LastActive date op wegschrijf. Daarna bepaal ik de operators die ik wil verwerken door te checken of op de operator kaart zowel de vrije datum als de create date “verlopen” zijn.

Als dat beide zo is dan disable ik de operator.

Hieronder de query voor de GET om de “te disablen” operators op te halen. Je ziet dat beide data (via een AND) “te oud” moeten zijn. Dat is stap 6 in de Action Sequence.

/tas/api/operators?query=archived==false;apiAccount==false;loginPermission==true;optionalFields1.date5=lt=${((.now?long - _variables["LastLogonDateOffsetDays"]?number)?number_to_date?string("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"))?no_esc};creationDate=lt=${((.now?long - _variables["CreateDateOffsetDays"]?number)?number_to_date?string("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"))?no_esc}&fields=id,surName,loginPermission

JeroenvdK
Explorer ⭐⭐⭐
May 22, 2026

@JeroenvdK Bedankt voor het mooie voorbeeld!

Ik ben op dit moment met een soort gelijke actiereeks bezig maar loop tegen een probleem aan, ik ben benieuwd of jij die ook bent tegengekomen.

Het lijkt er bij mij op alsof /services/active-user-overview/api/all-user-activity alleen ‘lastActive’ data geeft als de gebruiker in de laatste 3 maanden is ingelogd. Er zijn veel gebruikers waarvan ik in de TOPdesk GUI kan zien dat ze inlogdata hebben (bijvoorbeeld, Laatst actief: 13 februari 2026) maar die vervolgens in de JSON geen ‘lastActive’ veld hebben, waardoor ze niet door de ‘GetExpiredOperators’ stap worden gedetecteerd.

Ik ben benieuwd of dit jou ook bekend voorkomt.

Bijkomend voordeel (vind ik) is dat je door het vullen van dat vrije veld ook op een “gewone” manier (via een TOPdesk selectie) kan checken welke mensen te lang niets hebben gedaan. Je kunt dan eigenlijk doen wat het TOPdesk user dashboard laat zien, maar dan met veel meer selectiemogelijkheden, zoals bijvoorbeeld… Alleen verlopen users van vestiging X, of afdeling Y.

JeroenvdK
Explorer ⭐⭐⭐
May 22, 2026

Dank voor de reminder trouwens ​@JobdL ;-).

Jouw vraag was voor mij aanleiding om weer een de AS in te duiken. Toen heb ik hem meteen maar eens afgemaakt met de archiveerstap die ik nog wilde toevoegen. Kan ik dat ook weer afstrepen.

Fijn weekend!

Joost Oostindie
Contributor
May 28, 2026

Ter info voor degenen die een actiereeks op de ongedocumenteerde endpoint actief hebben voor hun actieve behandelaren:

In dit KI staan een aantal toepassingen die uitgefaseerd worden: TOPdesk feature deprecations - November 2026 - My TOPdesk SSP

Daaronder vallen de volgende:

Active operator overview
This was an overview of operators that showed the license status, the last time they logged in and whether they were online at the moment. This overview will be replaced with the Operator License overview.
Active user overview
This was an overview that showed which operators were online at the moment. This overview will be replaced with the Operator License overview.

Ik weet niet of dit ook betekend dat de API endpoint die nu gebruikt wordt verdwijnt, maar gezien de benaming van die endpoint (/services/active-user-overview/api/all-user-activity) verwacht ik wel dat die of verdwijnt of wordt aangepast.

Voor nu ben ik nog niet bekend met een nieuwe endpoint die beschikbaar is/wordt voor de Operator License overview.
Je kunt er wel alvast rekening mee houden dat deze vanaf November waarschijnlijk niet meer werkt.

Hopelijk wordt er voor die tijd meer bekend over een nieuwe endpoint!

 

Joost mag het weten, jij ook!
JeroenvdK
Explorer ⭐⭐⭐
May 28, 2026

Thanks! Weer iets om naar uit te kijken ...

JeroenvdK
Explorer ⭐⭐⭐
May 29, 2026

Ik vermoed dat ik een nieuwe weg gevonden heb… Ga het nog verder testen en verwerken in een nieuwe Action Sequence.

 

Het endpoint: /services/license-overview-backend/user-activity/<principalId>

 

Geeft je de volgende response:

{
"self": {
"href": "<your topdesk url>/services/license-overview-backend/user-activity/<principalId>",
"type": "application/x.topdesk-user-activity-v1+json"
},
"principalId": "<principalId>",
"lastActive": "<datetime_value>"
}

Dus dat moet te verwerken zijn in een stap per operator.

Joost Oostindie
Contributor
May 29, 2026

Ik vermoed dat ik een nieuwe weg gevonden heb… Ga het nog verder testen en verwerken in een nieuwe Action Sequence.

 

Het endpoint: /services/license-overview-backend/user-activity/<principalId>

 

Geeft je de volgende response:

{
"self": {
"href": "<your topdesk url>/services/license-overview-backend/user-activity/<principalId>",
"type": "application/x.topdesk-user-activity-v1+json"
},
"principalId": "<principalId>",
"lastActive": "<datetime_value>"
}

Dus dat moet te verwerken zijn in een stap per operator.

Topper!
Hoe heb je die gevonden?

Joost mag het weten, jij ook!
JeroenvdK
Explorer ⭐⭐⭐
June 1, 2026

@Joost Oostindie Gevonden via de Developer tools van de browser. Je kunt dan de achterliggende (netwerk)activiteit zien als je browst. Dus TOPdesk openen, developer tools starten, het operator license overzicht openen en dan zoeken in wat er op de achtergrond gebeurd is om te kijken welke service werd aangesproken.

Ik heb inmiddels een Action Sequence in concept werkend dat per operator acties gaat ondernemen op basis van de lastlogin uit de nieuwe user-activity service en/of creationDate op de Operator kaart. Ik wil nog wat dingen verbeteren. Zo ben ik om naar ODATA voor het ophalen van de operators (vanwege een size limit van 200 op het operators endpoint en de uitdaging die ik daarin zag om de noodzakelijk details betrouwbaar op te halen). Maar ODATA is eigenlijk niet ideaal, want via ODATA mag je van bepaalde “system” operators wel informatie opvragen van wie je via de API die informatie niet mag opvragen (en dat leidt dus weer tot fouten waarop ik moest corrigeren). Ook is filteren van operators via ODATA te minimaal door de minimale hoeveelheid aan velden, dus ik vraag nu eigenlijk van veel teveel operator informatie op.

Ook jammer… Die user-activity service geeft een 404 error als hij een operator niet kan vinden. Dat gebeurt bijvoorbeeld als iemand (lang?) niet ingelogd heeft. En een 404 is niet netjes af te handelen in de Action Sequence. De Action Sequence geeft die stap altijd als Failed terug en daarmee Failed ook de hele Action Sequence… (met error mail tot gevolg).

Dat heb ik afgevangen door alle opvolgende stappen te laten lopen zonder Error controle (Keuze voor “Always” in de dropdown). Dat betekent dan wel weer dat ik nog wat Error checking in de vervolgstappen zelf of in de run condities daarvan moest/moet opnemen.

Dus… Ik heb bij TOPdesk aangegeven dat ik (en mogelijk met mij ook andere beheerders) het erg op prijs zou stellen als deze service van “undocumented” naar “netjes” omgezet wordt OF dat de lastlogin “gewoon” een API veld binnen het operator API endpoint wordt (dit heb ik al eens eerder aangevraagd).

Mijn melding daarvan bij TOPdesk… Mocht iemand willen aansluiten → TDR26 05 6399

Eerste reactie van TOPdesk was… “Gebruik geen undocumented services.” 🙃

Als ik mijn AS netjes genoeg vind zal ik hem hier weer posten. Weet alleen niet of dat deze week nog lukt.

Joost Oostindie
Contributor
June 1, 2026

@Joost Oostindie Gevonden via de Developer tools van de browser. Je kunt dan de achterliggende (netwerk)activiteit zien als je browst. Dus TOPdesk openen, developer tools starten, het operator license overzicht openen en dan zoeken in wat er op de achtergrond gebeurd is om te kijken welke service werd aangesproken.

Ik heb inmiddels een Action Sequence in concept werkend dat per operator acties gaat ondernemen op basis van de lastlogin uit de nieuwe user-activity service en/of creationDate op de Operator kaart. Ik wil nog wat dingen verbeteren. Zo ben ik om naar ODATA voor het ophalen van de operators (vanwege een size limit van 200 op het operators endpoint en de uitdaging die ik daarin zag om de noodzakelijk details betrouwbaar op te halen). Maar ODATA is eigenlijk niet ideaal, want via ODATA mag je van bepaalde “system” operators wel informatie opvragen van wie je via de API die informatie niet mag opvragen (en dat leidt dus weer tot fouten waarop ik moest corrigeren). Ook is filteren van operators via ODATA te minimaal door de minimale hoeveelheid aan velden, dus ik vraag nu eigenlijk van veel teveel operator informatie op.

Ook jammer… Die user-activity service geeft een 404 error als hij een operator niet kan vinden. Dat gebeurt bijvoorbeeld als iemand (lang?) niet ingelogd heeft. En een 404 is niet netjes af te handelen in de Action Sequence. De Action Sequence geeft die stap altijd als Failed terug en daarmee Failed ook de hele Action Sequence… (met error mail tot gevolg).

Dat heb ik afgevangen door alle opvolgende stappen te laten lopen zonder Error controle (Keuze voor “Always” in de dropdown). Dat betekent dan wel weer dat ik nog wat Error checking in de vervolgstappen zelf of in de run condities daarvan moest/moet opnemen.

Dus… Ik heb bij TOPdesk aangegeven dat ik (en mogelijk met mij ook andere beheerders) het erg op prijs zou stellen als deze service van “undocumented” naar “netjes” omgezet wordt OF dat de lastlogin “gewoon” een API veld binnen het operator API endpoint wordt (dit heb ik al eens eerder aangevraagd).

Mijn melding daarvan bij TOPdesk… Mocht iemand willen aansluiten → TDR26 05 6399

Eerste reactie van TOPdesk was… “Gebruik geen undocumented services.” 🙃

Als ik mijn AS netjes genoeg vind zal ik hem hier weer posten. Weet alleen niet of dat deze week nog lukt.

Dankjewel!

Fijn ook om te zien hoe ver je al bent met het uitzoeken.
Ben zelf van plan om deze week ook aan de slag te gaan en de mogelijkheden verder uit te zoeken, als ik wat nuttigs tegenkom laat ik het hier ook zeker weten.

Helemaal eens dat het echt heel fijn zou zijn als TOPdesk deze endpoint officieel zou maken, daar ga ik ook op blijven aansporen!

Joost mag het weten, jij ook!
JeroenvdK
Explorer ⭐⭐⭐
June 4, 2026

Daar is ie dan… De nieuwe versie gebaseerd op het nieuwe endpoint. Ik heb de AS volledig opnieuw opgebouwd.

Er is 1 “jammer maar helaas” - Het nieuwe endpoint geeft een 404 als een operator niet gevonden kan worden. Die response code ziet TOPdesk onherroepelijk als een Failure… Dus de AS zal altijd het resultaat “failure” geven.

Maar… hij werkt wel. Korte uitleg van de stappen:

  1. debug
  2. debug
  3. debug
  4. GET archive reasons (voor het later ophalen van het juiste unid voor de archive stap)
  5. debug
  6. GET all operators via ODATA (want via API loop je tegen een max_size aan)
  7. Repeat over alle operators
    1. Haal beperkte details op van de operator kaart
    2. Haal de last login op via de undocumented service
    3. Vul LIST variabele aan met informatie van deze operator
  8. Bouw de hele LIST met operators op naar een variabele in JSON format
  9. debug
  10. Werk operators bij
    1. Zoek operator die voldoet aan voorwaarde A
    2. Zet details van operator in LIST variabele als deze voldoet aan voorwaarde A
    3. PATCH operator (login op false) als deze voldoet aan voorwaarde A
    4. Stuur mail aan operator als deze voldoet aan voorwaarde A
    5. Zoek operator die voldoet aan voorwaarde B
    6. Zet details van operator in LIST variabele als deze voldoet aan voorwaarde B
    7. PATCH operator (archiveer operator) als deze voldoet aan voorwaarde B
    8. Stuur mail aan operator als deze voldoet aan voorwaarde B
  11. Maak nieuwe variabele aan en neem daarin een lijst op met de operators die verwerkt zijn vanwege voorwaarde A en welke verwerkt zijn vanwege voorwaarde B

Voorwaarde A: Lastlogin voor lastloginoffset AND createdate voor createdateoffset AND loginpermission TRUE AND APIaccount FALSE AND networkloginname NOT EMPTY AND AccountType = ‘regular’

Voorwaarde B: Lastlogin voor lastloginarchiveoffset AND createdate voor createdateoffset AND loginpermission FALSE AND APIaccount FALSE AND networkloginname NOT EMPTY AND AccountType = ‘regular’

Lees de Description voor gebruik (activeren patch en email) en advies t.a.v. eerste probeersels.

In de log kun je aan het einde het lijstje van operators vinden op wie actie A en actie B zal worden genomen resp. is genomen (na activatie van PATCH stappen). Ik vond dat wel handig. Zelf ga ik de webhook ombouwen naar een AS op een Operationele Serie die dan ook het resultaat wegschrijft in een Action veld van de OA die de AS aftrapt. Dan is dat ook makkelijk vindbaar voor de Servicedesk.

Veel plezier ermee voor diegene die het aandurft ;-)