Automatische controle op inactieve behandelaarsaccounts

Staat op onze backlog om dit te bouwen in een Action Sequence. Proces ongeveer als volgt:

1. Haal alle actieve (non-archive, login actief) operators op die:
   1. Geen API zijn
   2. Langer dan x tijd niet zijn ingelogd
   3. Langer dan x tijd geleden zijn aangemaakt
2. Zet op deze operators het vinkje “Can login” uit
3. Mail elke operator dat het vinkje uitstaat
4. Haal alle operators op die
   1. Langer dan 2x tijd niet zijn ingelogd
   2. Langer dan x tijd geleden zijn aangemaakt (dit zou niet nodig hoeven zijn)
5. Archiveer deze operators

Wij bieden dan ook nog in de periode tussen 3 en 5 de operators de mogelijkheid om via Self-Service hun account weer te activeren mocht dat nodig zijn. Daarvoor hebben we een SSP form dat een change met een automation erachter activeert. Scheelt ons echt behoorlijk wat werk na elke opruimactie.

Er is een service in TOPdesk die je de last login datums kan verstrekken (wel undocumented/unsupported helaas - ik heb gevraagd dit veld aan de API toe te voegen). De rest van de benodige gegevens kun je volgens mij wel opvragen via de API. Dan zijn we niet afhankelijk van een andere tool, zoals we dat nu wel zijn (we exporteren nu wat data via SQL daarvoor).

Dat is een hele mooie oplossing. Zou ook voor ons erg interessant kunnen zijn. Alhoewel het aantal behandelaars niet zo heel groot is en ik dit nog met de hand zou kunnen doen. Maar altijd interessant om eens naar te kijken.

Ah dit gaat mij enorm helpen! ik heb net het gebruikersbeleid afgeschreven voor ons bedrijf, en dit zal helpen!

Wie durft mee te testen… ;-)?

Een expliciete disclaimer vind ik hier wel belangrijk… al is het eigenlijk impliciet al van toepassing. Let op wat je doet en gebruik dit script voor eigen risico! Je kunt door gebruik van verkeerde waardes jezelf namelijk uit je eigen TOPdesk omgeving buitensluiten. Check ook of de condities die ik heb gebruikt voldoende passend zijn voor jouw eigen TOPdesk omgeving.

Stappen die zaken echt aanpassen/uitsturen heb ik geel gemarkeerd. Je wilt die waarschijnlijk eerst disablen om te kijken en te dubbelchecken wat er geraakt gaat worden…

Type Action Sequence is een webhook.

Ik gebruik een vrij veld op de operator kaart (ExtraFields1.Date5), omdat ik dat in het script makkelijker vond. Daarnaast heeft het als voordeel dat je dan ook op andere momenten via reguliere TOPdesk selecties kan checken wat de Last login datum van je operator accounts was bij de laatste run van dit script.

Een mooie. Wij hebben hem ook draaien, maar op een andere manier.

De werking is als volgt:

• Eén keer per week wordt via een ingeplande actie de laatste login en het type licentie (betaald of gratis) opgehaald.

• De licentiesoort en de datum van de laatste login worden weggeschreven naar vrije velden op de behandelaarskaart.

• Vervolgens wordt berekend hoeveel dagen een behandelaar inactief is.

• Wanneer een behandelaar langer dan x dagen inactief is (in ons geval 360 dagen), wordt het account automatisch gearchiveerd.

• Als er geen laatste login bekend is, wordt het aantal inactieve dagen berekend vanaf de aanmaakdatum van de behandelaarskaart.

De actie wordt uitsluitend uitgevoerd op behandelaren met de volgende kenmerken:

• status: “operator”

• accountType: “regular”

• apiAccount: “false”

• archive: “false”

Daarnaast hebben wij een specifieke behandelaarsgroep uitgesloten van deze automatisering. Behandelaren die lid zijn van deze groep worden niet gearchiveerd. Denk hierbij bijvoorbeeld aan leveranciersaccounts of een “glass break” account.

Ook mooi ​@Niels Henriët en dank voor het delen!

Ik heb er bewust voor gekozen om er een tweetrapsraket van te maken (eerst login deactiveren, daarna pas operator archiveren). Mijn script hierboven doet trap 1 daarvan. De rest moet nog volgen.

Reden om het in 2 stappen te doen is dat ik wil dat na de initiele loginblokkade de operator nog een bepaalde tijd zelf zijn account kan heractiveren. Daarvoor heb ik een form op de SSP met een change die een AS aftrapt om de blokkade weer ongedaan te maken (door de koppeling tussen Person en Operator kan dat tegenwoordig op een nette/veilige manier).

En die werkwijze in 2 stappen geeft mij de mogelijkheid om relatief snel al de login te deactiveren op inactieve accounts. Na een langere periode nog altijd inactief ga ik de operator dus wel ook echt archiveren waarna de “heractivatie self-service” niet meer werkt. De persoon krijgt dan een reactie op de change om zich te melden voor heractivatie van het operator account.

Zo houden we de licenties flink strakker in de gaten dan voorheen en die SelfService heractivatie scheelt ons als beheerder een hoop gedoe.

In ons bedrijf hadden we hetzelfde probleem.
Dit hebben we opgelost via een geautomatiseerd process waarbij de sporadische behandelaars standaard geen rechten hebben, maar deze tijdelijk (max 30 dagen) kunnen aanvragen via een formulier in het SSP.

Wat heb je hiervoor nodig?

• Een formulier het object veld waarin de assets zitten gelinkt aan de behandelaarsgroepen.
• Assets met daarin de behandelaarsgroep
• Behandelaarsgroepen gelinkt aan de permission groups
• Een automatisatie om de behandelaar te koppelen aan de groep en taken
• Een automatisatie om de behandelaar te ontkoppelen van de groep en taken.

De actiereeks die ik gemaakt heb die dit gebruikt staat 1 keer per dag ingepland om 2 uur in de nacht ofzo.

WARNING:
Gebruik van de endpoints is op eigen risico. TOPdesk kan op elk moment wijzigingen doorvoeren of de endpoint uitschakelen, zonder voorafgaande melding.
Dit kan dan leiden tot breaking changes.

even een disclaimer omdat de service in stap 1 niet gedocumenteerd staat. 

stappen:
1 Get op /services/active-user-overview/api/all-user-activity

2 get op archiveer redenen 

3 herhalende stap

     3.1 get op behandelaar /tas/api/operators/id/${_responses.getActiveUsers.body.operators[i].id}

     3.2 stuurt mail naar behandelaar 

     3.3 archiveert behandelaar. 

de voorwaarde voor stap 3.2 en 3.3  werkt als volgt waarin ik kijk naar of ze een betaalde licentie hebben en dan vergelijk is nog het aantal dagen in mijn variabele met de huidige dag en als dat een match is dan is het true en anders niet. wij hebben archiveren op 6 maanden daarom de namen van de variabele en assign  

<#setting time_zone="Europe/Amsterdam">
<#if _responses.getActiveUsers.body.operators[i].lastActive??>
<#assign interval = _variables.Archiveren?number * 60 * 60 * 24 * 1000>
<#assign unixTime = _responses.getActiveUsers.body.operators[i].lastActive>
<#assign inlogDatumPlus6Maand = unixTime + interval>

<#if inlogDatumPlus6Maand?number_to_date?string["yyyy-MM-dd"]==.now?string["yyyy-MM-dd"] && _responses.getActiveUsers.body.operators[i].licensed == true>true</#if>
<#else>
<#assign interval = _variables.Archiveren?number * 60 * 60 * 24 * 1000>
<#assign unixTime = _responses.getBehandelaar.body.creationDate?date("yyyy-MM-dd")?long>
<#assign inlogDatumPlus6Maand = unixTime + interval>
<#if inlogDatumPlus6Maand?number_to_date?string["yyyy-MM-dd"]==.now?string["yyyy-MM-dd"] && _responses.getActiveUsers.body.operators[i].licensed == true>true</#if>
</#if>

​@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

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.

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!

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!

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

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.

{
    "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>"
}

Topper!
Hoe heb je die gevonden?

​@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!

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 ;-)

Dankjewel voor het delen ​@JeroenvdK!

Afgelopen woensdag een klein begin kunnen maken, maar dit gaat zeker helpen om het verder uit te werken. Erg fijn dat je dit zo snel hebt gebouwd en deelt, daar plukken wij de vruchten van. 🙂

Als ik meer tijd heb gehad om hier ook mee aan de slag te gaan deel ik zeker nog mijn bevindingen!

Laatste update van mij op dit draadje. Ik heb na wat beter tracen in de browser een beter werkende - nog altijd undocumented - service endpoint gevonden voor het ophalen van de lastlogin date.

Voordeel: Geen 404 errors meer op operators die te lang niet waren ingelogd.

Nadeel: Het endpoint geeft de last logins van ALLE gebruikers terug, niet enkel van de operators. Dus die lijst kan heel snel heel groot worden, vandaar dat ik er een filter in heb gezet op de lastActive date.

Mijn nog wat slordig weergegeven Action Sequence in de bijlage. Hij werkt als je een archiefreden invult. Let op! De PATCH en email stappen staan aan in deze versie!