Skip to main content

One TOPdesk User mijlpaal: alle human accounts hebben een persoonskaart

  • June 4, 2026
  • 16 replies
  • 417 views

Winnie Tsang
Employee
Forum|alt.badge.img+1

We brengen je graag op tijd op de hoogte van een reeks wijzigingen die eraan komt vanuit het One TOPdesk User Project. Met deze mijlpaal krijgen alle human accounts een persoonskaart en wordt de persoonskaart steeds meer de leidende kaart in TOPdesk.

Het doel van deze mijlpaal is om gekoppelde behandelaars en personen op één eenduidige manier te beheren, te zorgen dat het product werkt zoals bedoeld, en de koppeling te benutten om gebruikersbeheer makkelijker te maken. Hieronder vind je een overzicht van alle wijzigingen.

Een aantal hiervan heeft impact op hoe je vandaag werkt — vooral bij integraties, archiveren, anonimiseren en het beheren van je licenties. Sommige onderdelen kennen een harde deadline. Daarom delen we ze nu, zodat je niet voor verrassingen komt te staan en op tijd actie kunt ondernemen.

De meeste van deze features verwachten we uit te brengen tussen midden juni en eind juli. Bij onderdelen met een afwijkende planning vermelden we dat hieronder. Zodra een onderdeel daadwerkelijk live is, laten we je dat hier natuurlijk weten.

Alle gebruikers krijgen een persoonskaart

Tegen het einde van deze mijlpaal heeft elke gebruiker een eigen persoonskaart. Vorig jaar en in het begin van het jaar hebben jullie al behandelaarskaarten gekoppeld aan hun persoonskaarten. Nu zullen ook behandelaars zonder gekoppelde persoonskaart er één krijgen. Zo zorgen we ervoor dat iedere persoon in TOPdesk op één eenduidige manier wordt vastgelegd en teruggevonden.

Wat betekent dit voor jou? Personen worden hierdoor consistenter beheerd in de hele applicatie. Je hoeft hier zelf niets voor te doen: de wijziging wordt automatisch doorgevoerd. Behandelaars die nog geen gekoppelde persoonskaart hebben, krijgen er automatisch één toegewezen. Deze kaart bevat dezelfde algemene informatie als de behandelaarskaart, met twee belangrijke kanttekeningen: de kaart geeft geen toegang tot de Self Service Portal en is niet selecteerbaar als melder.

Gemak bij het beheren van gekoppelde behandelaars en personen

Omdat de persoonskaart de leidende kaart wordt, voegen we een aantal gemakken toe wanneer je gebruikers via de persoonskaart beheert.

Archiveren en de-archiveren

Het gedrag rondom archiveren en de-archiveren stemmen we af op de gekoppelde persoonskaart, zodat je een gebruiker in één handeling consistent beheert. Archiveer je een persoonskaart, dan wordt de gekoppelde behandelaarskaart voortaan ook gearchiveerd. Dit geldt ook wanneer dit via een integratie gebeurt.

Wat betekent dit voor jou? Controleer je integraties, vooral als je naam of e-mailadres als unieke identifier gebruikt om gebruikers te importeren. Overweeg om de unieke identifier te veranderen in bijvoorbeeld werknemer nummer. Zo voorkom je dat behandelaarskaarten onbedoeld worden gearchiveerd.

Verwijderen

Het verwijdergedrag stemmen we af op de koppeling tussen behandelaar en persoonskaart. Verwijder je een persoonskaart die geen koppelingen bevat, dan wordt de gekoppelde behandelaarskaart ook verwijderd.

Anonimiseren

Omdat behandelaars voortaan ook een persoonskaart hebben, trekken we het anonimiseren van behandelaars en personen naar één werkwijze. Dat heeft twee concrete gevolgen:

  • De aparte anonimisatie-instellingen voor behandelaars verdwijnen. Die regelde je tot nu toe via eigen, losse instellingen.
  • Behandelaar-anonimisatie wordt gekoppeld aan persoon-anonimisatie. Het anonimiseren van een behandelaar verloopt voortaan via dezelfde route en dezelfde regels als die van een persoon.

Wat betekent dit voor jou? Gebruik je het anonimiseren van behandelaars (bijvoorbeeld in het kader van AVG/GDPR), dan verandert de plek en de manier waarop je dat instelt. Loop je huidige werkwijze en interne afspraken hierover na, en stem dit af met je functioneel beheerder of privacyverantwoordelijke.

Integraties: gebruik je de API via de SSP? Werk je integraties bij

In onze API zijn er endpoints die zowel personen als behandelaars bedienen, waarbij een deel zich anders gedraagt afhankelijk van wie de aanroep doet. In de aanloop naar één uniform gebruikersmodel splitsen we dit: het persoons- (SSP-)gedrag krijgt eigen, alternatieve endpoints. Dit stond al in de release notes van februari 2026, maar we brengen het graag nog een keer extra onder de aandacht.

De geraakte endpoints zijn onder andere: GET /branches, GET /persons (alleen v2), GET /persons/{id}, GET /locations en GET /avatars/operator/{id}. In het bijbehorende KI-artikel: KI 18843 vind je het volledige overzicht van de geraakte endpoints en hoe je die gebruikt.

Wat betekent dit voor jou? Roep je deze endpoints aan vanuit een persoonscontext (bijvoorbeeld via de Self Service Portal), werk je integraties dan bij naar de nieuwe /tas/api/requester/...-endpoints. Doe dit vóór eind juni. Heb je koppelingen die door een partner of leverancier zijn gebouwd? Stem dan tijdig met hen af.

Convert API account functionaliteit verdwijnt

Na juli 2026 is het niet langer mogelijk om een bestaand behandelaarsaccount om te zetten naar een API-account. Heb je daarna een API-account nodig, dan maak je dit opnieuw aan.

Wat betekent dit voor jou? Zorg dat je de benodigde API-accounts vóór eind juli hebt omgezet.

Wijzigingen in de overzichten

Licentieoverzicht voor behandelaars toont ook persoonsdata

In het licentieoverzicht voor behandelaars (Operator license overview) gaat de kolom last active date ook gegevens van personen tonen. De datum geeft aan wanneer de gebruiker (behandelaar óf persoon) voor het laatst is ingelogd — dit kan zowel de SSP als het behandelaarsportaal zijn. Dit gaat in vanaf augustus 2026; houd hier rekening mee bij het beheren van je licenties.

Vragen of input?

Heb je vragen, loop je ergens tegenaan of wil je iets met ons delen over deze wijzigingen? Laat het gerust weten in de reacties hieronder. We denken graag met je mee.

 

16 replies

Sanne Haller
Forum|alt.badge.img+8

Archiveren en de-archiveren

Het gedrag rondom archiveren en de-archiveren stemmen we af op de gekoppelde persoonskaart, zodat je een gebruiker in één handeling consistent beheert. Archiveer je een persoonskaart, dan wordt de gekoppelde behandelaarskaart voortaan ook gearchiveerd. Dit geldt ook wanneer dit via een integratie gebeurt.

Wat betekent dit voor jou? Controleer je integraties, vooral als je naam of e-mailadres als unieke identifier gebruikt om gebruikers te importeren. Overweeg om de unieke identifier te veranderen in bijvoorbeeld werknemer nummer. Zo voorkom je dat behandelaarskaarten onbedoeld worden gearchiveerd.

 

Krijgen we vooraf bericht wanneer we worden overgezet naar een versie waarin deze wijziging actief is?

Wij hebben bijvoorbeeld automatiseringen die bij het archiveren van een persoonskaart ook de gekoppelde behandelaarskaart archiveren. Dat lijkt mogelijk te kunnen botsen met deze nieuwe standaardfunctionaliteit. Daarom zou ik dit graag vooraf willen weten, zodat we eventuele aanpassingen kunnen doorvoeren en de werking kunnen monitoren.

Daarnaast ben ik benieuwd hoe de volgende scenario's worden afgehandeld:

  • Wanneer een persoonskaart wordt gedearchiveerd, wordt de gekoppelde behandelaarskaart dan automatisch ook direct gedearchiveerd?
  • Wat gebeurt er wanneer een behandelaarskaart wordt gedearchiveerd terwijl de gekoppelde persoonskaart nog gearchiveerd is?
  • Wanneer een automatisering een persoonskaart tijdelijk de-archiveert voor het opschonen van gegevens, wordt de behandelaarskaart dan automatisch ook gedearchiveerd?
  • Wanneer een automatisering juist de behandelaarskaart de-archiveert voor opschoningsdoeleinden, wordt de persoonskaart dan ook automatisch gedearchiveerd?
  • Zijn er situaties denkbaar waarbij automatiseringen en deze nieuwe standaardfunctionaliteit elkaar blokkeren, bijvoorbeeld omdat er maar één wijziging tegelijk op een kaart kan plaatsvinden?
  • Is het mogelijk om de automatische synchronisatie van archiveren/de-archiveren uit te schakelen of uit te zonderen voor wijzigingen die via de API worden uitgevoerd?

Forum|alt.badge.img
  • Employee
  • June 8, 2026

Hoi ​@Sanne Haller,

Hier Tom als medewerker van de Support afdeling bij TOPdesk en Product Cell Support voor het development team wat hiermee bezig is.

Ik zal proberen als je vragen hieronder te beantwoorden:

Krijgen we vooraf bericht wanneer we worden overgezet naar een versie waarin deze wijziging actief is?

  • Klanten zullen niet individueel bericht worden wanneer de update plaats zal vinden. Zodra deze update uitgerold wordt zal dit gepubliceerd worden in de release notes (releasenotes.topdesk.com), dit zal binnenkort zijn waarbij ik niet in kan gaan op een specifiekere tijdframe. Omdat TOPdesk werkt met verschillende release groepen zal ook niet elke klant op dezelfde dag de upgrade krijgen.
    Ik raad aan om de release notes de komende tijd in de gaten te houden.

Daarnaast ben ik benieuwd hoe de volgende scenario's worden afgehandeld:

  • Wanneer een persoonskaart wordt gedearchiveerd, wordt de gekoppelde behandelaarskaart dan automatisch ook direct gedearchiveerd?
    • Nee, wanneer een persoonskaart wordt gedearchiveerd via de API of de import wordt niet gelijk de behandelaarskaart gedearchiveerd. De logica hierbij is dat als een gebruiker opnieuw in dienst komt, het niet hoeft te betekenen dat de gebruiker direct ook een behandelaar is. Het zou daarbij dan niet wenselijk zijn om ook de behandelaarskaart te dearchiveren.
    • Wanneer je manueel de persoonskaart dearchiveerd, dan zal je de optie krijgen om de behandelaarskaart wel of niet te dearchiveren.
  • Wat gebeurt er wanneer een behandelaarskaart wordt gedearchiveerd terwijl de gekoppelde persoonskaart nog gearchiveerd is?
    • Hierbij zal de persoonskaart altijd gedearchiveerd worden. Dit geldt zowel voor de import, de API en manueel. Een behandelaarskaart kan niet actief zijn zonder een actieve persoonskaart.
  • Wanneer een automatisering een persoonskaart tijdelijk de-archiveert voor het opschonen van gegevens, wordt de behandelaarskaart dan automatisch ook gedearchiveerd?
    • Nee, zie het eerste antwoord. Als een persoonskaart via automatisering wordt gedearchiveerd zal de behandelaarskaart niet automatisch gedearchiveerd worden.
  • Wanneer een automatisering juist de behandelaarskaart de-archiveert voor opschoningsdoeleinden, wordt de persoonskaart dan ook automatisch gedearchiveerd?
    • Ja, de persoonskaart zal gedearchiveerd worden.
  • Zijn er situaties denkbaar waarbij automatiseringen en deze nieuwe standaardfunctionaliteit elkaar blokkeren, bijvoorbeeld omdat er maar één wijziging tegelijk op een kaart kan plaatsvinden?
    • Nee dit zou niet het geval moeten zijn en de 2 zouden elkaar niet moeten blokkeren.
  • Is het mogelijk om de automatische synchronisatie van archiveren/de-archiveren uit te schakelen of uit te zonderen voor wijzigingen die via de API worden uitgevoerd?
    • Nee dit is niet mogelijk

Om ook nog in te gaan op de volgende zin in je bericht: "Wij hebben bijvoorbeeld automatiseringen die bij het archiveren van een persoonskaart ook de gekoppelde behandelaarskaart archiveren. Dat lijkt mogelijk te kunnen botsen met deze nieuwe standaardfunctionaliteit."

  • Dit hangt af van hoe de automatisering is opgebouwd. Als de geautomatiseerde actie uit KI 15036 op MyTOPdesk wordt gebruikt, dan zal dit geen probleem geven. Deze actie kijkt naar of een behandelaar bestaat met dezelfde inlognaam en heeft daarbij de FIQL query archived==false in de url. Hierbij zal de actie dus alleen kijken of er nog een actieve behandelaar is. Als deze er niet is doordat deze nu automatisch al gearchiveerd wordt, dan zal de actie de stap daarna overslaan en geen foutmelding tonen.
    Natuurlijk kan deze automatisering na de aanpassing rondom het archiveren ook uitgeschakeld worden.

Weet ook dat er gewerkt wordt aan een docs pagina (docs.topdesk.com) met uitleg over hoe dit na de aanpassing zal werken.


Suzanne Machielsen-Bijleveld
Forum|alt.badge.img+1
  • Wat gebeurt er wanneer een behandelaarskaart wordt gedearchiveerd terwijl de gekoppelde persoonskaart nog gearchiveerd is?
    • Hierbij zal de persoonskaart altijd gedearchiveerd worden. Dit geldt zowel voor de import, de API en manueel. Een behandelaarskaart kan niet actief zijn zonder een actieve persoonskaart.

Hoi ​@Tom Baak. Wij hebben ondersteunende bestanden imports die de personen en behandelaars vanuit onze autorisatietool importeren. We hebben nu een aantal behandelaars die eerst gearchiveerd waren en onlangs weer in dienst zijn gekomen. De import geeft nu een foutmelding omdat er geen persoonskaart is gekoppeld. Dit zal vermoedelijk hiermee wel opgelost worden maar worden de behandelaars dan aan een bestaande (actieve) persoonskaart met dezelfde gegevens gekoppeld als deze aanwezig is of wordt er altijd een nieuwe kaart aangemaakt?

M.b.t. “In het licentieoverzicht voor behandelaars (Operator license overview) gaat de kolom last active date ook gegevens van personen tonen. De datum geeft aan wanneer de gebruiker (behandelaar óf persoon) voor het laatst is ingelogd — dit kan zowel de SSP als het behandelaarsportaal zijn. Dit gaat in vanaf augustus 2026; houd hier rekening mee bij het beheren van je licenties.”
Gaat dit dan nog goed met het berekenen van het aantal actieve behandelaars voor de facturatie? We betalen namelijk in staffel per behandelaar. Als nu gefactureerd wordt op personen die op het SSP kunnen inloggen, dan is het aantal vele malen hoger. Kunnen we het aantal (actieve) behandelaars dan wel ergens terugzien als het niet meer in dat overzicht kan?


Forum|alt.badge.img
  • Employee
  • June 11, 2026

Hoi ​@Suzanne Machielsen-Bijleveld,

Tijdens de periode dat het koppelen mogelijk was is er aangeraden als best-practice om ook behandelaars te koppelen aan de juiste persoonskaart als er een kans bestaat dat een behandelaar weer terug in dienst komt. De periode is sinds Februari afgelopen waarbij het nu niet mogelijk meer is om deze koppeling aan te passen.

Tijdens een volgende fase van dit project zullen persoonskaarten automatisch aangemaakt worden voor alle behandelaars die nu geen gekoppeld persoon hebben.
Vanaf dat moment kan je dan kijken of je beter die persoonskaart kan gaan gebruiken en de oude ongekoppelde persoonskaart archiveren.
De import zal dus niet al bestaande persoonskaarten gaan koppelen aan de behandelaarskaarten aangezien dit niet mogelijk is.

Mocht je hier nog vragen over hebben dan raad ik aan even een melding bij ons aan te maken waarbij je mag verwijzen naar deze post en mij hierbij kan benoemen. Dan help ik je graag verder.

Voor het licentieoverzicht. Het licentieoverzicht zal nog steeds tonen hoeveel betaalde behandelaars er zijn en zal nog steeds alleen behandelaars tellen die betaalde rechten hebben. De aanpassing zal hier dus geen effect op hebben.


Suzanne Machielsen-Bijleveld
Forum|alt.badge.img+1

Hoi ​@Suzanne Machielsen-Bijleveld,

Tijdens de periode dat het koppelen mogelijk was is er aangeraden als best-practice om ook behandelaars te koppelen aan de juiste persoonskaart als er een kans bestaat dat een behandelaar weer terug in dienst komt. De periode is sinds Februari afgelopen waarbij het nu niet mogelijk meer is om deze koppeling aan te passen.

Tijdens een volgende fase van dit project zullen persoonskaarten automatisch aangemaakt worden voor alle behandelaars die nu geen gekoppeld persoon hebben.
Vanaf dat moment kan je dan kijken of je beter die persoonskaart kan gaan gebruiken en de oude ongekoppelde persoonskaart archiveren.
De import zal dus niet al bestaande persoonskaarten gaan koppelen aan de behandelaarskaarten aangezien dit niet mogelijk is.
 

Bedankt voor je reactie. Ik reageer toch even hier want ik kan me voorstellen dat dit ook voor anderen geldt. Bij CZ komt het vaak voor dat dezelfde (vaak externe) medewerkers “uit dienst“ gaan en, soms jaren, later weer voor ons komen werken. We hebben gigantisch veel gearchiveerde behandelaars dus het was niet wenselijk om deze allemaal te dearchiveren en aan de (altijd aanwezige) persoonskaarten te koppelen. Kunnen we wel de oude persoonskaarten alsnog koppelen? Ze moeten kunnen inloggen in het SSP dus we kunnen dan niet de nieuwe kaart aanpassen aangezien de inlognaam hetzelfde zal zijn als op de oude kaart. Dan moeten we dus 2 kaarten per behandelaar gaan aanpassen. Hopelijk kunnen we dit automatiseren. Dat kan ik aan onze consultant (Hub) vragen.


Forum|alt.badge.img
  • Employee
  • June 11, 2026

Hoi ​@Suzanne Machielsen-Bijleveld ,

Voor het koppelen was het niet nodig geweest om de gearchiveerde behandelaars te dearchiveren. Daarbij was het prima geweest om deze gearchiveerd te laten waarbij ze ook gekoppeld hadden kunnen worden.

Er is nu helaas geen mogelijkheid meer om al bestaande behandelaars te koppelen aan personen. De deadline hiervoor was februari. Alle bestaande behandelaars die geen gekoppeld persoon hebben zullen in de volgende fase van het project automatisch een nieuwe persoonskaart gekoppeld krijgen.

De enige opties zijn dus of om te wachten tot deze kaarten aangemaakt zijn en op dat moment deze persoonskaart te gebruiken waarbij met behulp van een import of geautomatiseerde actie gekeken kan worden of de inlognaam van de bestaande persoonskaart aangepast kan worden.
Of er kunnen nieuwe behandelaarskaarten aangemaakt worden vanuit de bestaande persoonskaarten.
KI 19084 op MyTOPdesk gaat hier verder op in.


edwintalsma
Forum|alt.badge.img+5
  • Explorer ⭐⭐⭐⭐⭐
  • June 15, 2026

Hoi ​@Suzanne Machielsen-Bijleveld ,

Voor het koppelen was het niet nodig geweest om de gearchiveerde behandelaars te dearchiveren. Daarbij was het prima geweest om deze gearchiveerd te laten waarbij ze ook gekoppeld hadden kunnen worden.

Er is nu helaas geen mogelijkheid meer om al bestaande behandelaars te koppelen aan personen. De deadline hiervoor was februari. Alle bestaande behandelaars die geen gekoppeld persoon hebben zullen in de volgende fase van het project automatisch een nieuwe persoonskaart gekoppeld krijgen.

De enige opties zijn dus of om te wachten tot deze kaarten aangemaakt zijn en op dat moment deze persoonskaart te gebruiken waarbij met behulp van een import of geautomatiseerde actie gekeken kan worden of de inlognaam van de bestaande persoonskaart aangepast kan worden.
Of er kunnen nieuwe behandelaarskaarten aangemaakt worden vanuit de bestaande persoonskaarten.
KI 19084 op MyTOPdesk gaat hier verder op in.

Daarom hebben wij begin dit jaar al zoveel mogelijk zelf persoonskaarten gemaakt en gekoppeld voor zover die er nog niet waren.


Forum|alt.badge.img
  • New Member ⭐⭐⭐
  • June 15, 2026


Voor het licentieoverzicht. Het licentieoverzicht zal nog steeds tonen hoeveel betaalde behandelaars er zijn en zal nog steeds alleen behandelaars tellen die betaalde rechten hebben. De aanpassing zal hier dus geen effect op hebben.


Wij voeren periodieke controles uit waarbij behandelaars welke langdurig niet zijn ingelogd worden gearchiveerd. Ik vermoed dat Suzanne's vraag hier ook een beetje op doelde. Licentiebeheer wordt dan knap lastig als de laatste login datum in het licentieoverzicht niet meer gebaseerd is op gebruik van de licentie. Je ziet niet of dit users zijn die bijv. het afgelopen half jaar alleen faciliteiten via de SSP hebben gereserveerd. Hoe kunnen we in de toekomst controleren of betaalde licenties daadwerkelijk in gebruik zijn?


Sanne van Opstal-Brakel
Employee
Forum|alt.badge.img+15

@Tom Baak zou jij naar de vraag van ​@Marina  kunnen kijken?

In de tussentijd kan ik wel de update plaatsen dat enkele features al gereleast zijn of in de pijplijn zitten, zie ook: 

 


Suzanne Machielsen-Bijleveld
Forum|alt.badge.img+1

Daarom hebben wij begin dit jaar al zoveel mogelijk zelf persoonskaarten gemaakt en gekoppeld voor zover die er nog niet waren.

@edwintalsma Elke behandelaar heeft een persoonskaart, dat is in automatie vanuit onze autorisatietool al ingericht. Alleen zijn medewerkers die “uit dienst” zijn, gearchiveerd (zowel persoon als behandelaar). Medewerkers (veelal uitzendkrachten) die weer voor ons komen werken, krijgen hetzelfde personeelsnummer en warden via de import weer geactiveerd. Zowel persoon als, indien aanwezig, behandelaar. Nu zijn deze dus niet gekoppeld omdat ze ten tijde van het in bulk koppelen beide gearchiveerd waren. En nu hebben we dus geen mogelijkheid om ze alsnog te koppelen en levert de import foutmeldingen op.


edwintalsma
Forum|alt.badge.img+5
  • Explorer ⭐⭐⭐⭐⭐
  • June 22, 2026

Het is wel jammer dat de handmatige koppeling mogelijkheid al weg is gehaald, imho had dat pas gehoeven als de niet-gekoppelde behandelaars ook een automatisch gegenereerde persoonskaart hadden gekregen.


Forum|alt.badge.img


Voor het licentieoverzicht. Het licentieoverzicht zal nog steeds tonen hoeveel betaalde behandelaars er zijn en zal nog steeds alleen behandelaars tellen die betaalde rechten hebben. De aanpassing zal hier dus geen effect op hebben.


Wij voeren periodieke controles uit waarbij behandelaars welke langdurig niet zijn ingelogd worden gearchiveerd. Ik vermoed dat Suzanne's vraag hier ook een beetje op doelde. Licentiebeheer wordt dan knap lastig als de laatste login datum in het licentieoverzicht niet meer gebaseerd is op gebruik van de licentie. Je ziet niet of dit users zijn die bijv. het afgelopen half jaar alleen faciliteiten via de SSP hebben gereserveerd. Hoe kunnen we in de toekomst controleren of betaalde licenties daadwerkelijk in gebruik zijn?

@Tom Baak Ook wij hebben eenzelfde soort werkwijze als Marina en Suzanne. Vanuit mij dus ook de vraag hoe wij straks nog kunnen controleren of onze behandelaars nog actief zijn geweest in het behandelaarsgedeelte.


Forum|alt.badge.img+3
  • New Member ⭐⭐⭐
  • June 29, 2026

“  Convert API account functionaliteit verdwijnt

Na juli 2026 is het niet langer mogelijk om een bestaand behandelaarsaccount om te zetten naar een API-account. Heb je daarna een API-account nodig, dan maak je dit opnieuw aan.

Wat betekent dit voor jou? Zorg dat je de benodigde API-accounts vóór eind juli hebt omgezet. “   

Mag ik er in deze vanuit gaan dat de mogelijkheid van omzetting naar API-accounts echt tot 31 juli beschikbaar is en niet een week daarvoor al verdwijnt bij een of meerdere klanten vanwege verschillende release groepen?

Achterliggende reden van de vraag;
Bij onze klanten hebben we de meeste accounts al omgezet maar nu bestaan er nog een aantal (legacy) accounts waarvan we aan het uitzoeken zijn in hoeverre die nog relevant zijn en naar API account kunnen worden omgezet. Daar zit veel uitzoekwerk bij. Daarom is het fijn om te weten tot wanneer we de tijd hebben om deze laatste accounts aan te passen wanneer nodig.

Alvast bedankt! 


Forum|alt.badge.img
  • Employee
  • June 29, 2026

Hoi ​@Marina en ​@Marian van der Sluis 

Er wordt gekeken naar een manier om dit te kunnen doen. Het feit dat straks de laatste inlogdatum ook het inloggen van een persoon zal tellen is helaas niet te voorkomen en is een side effect van de volgende stap in het One User project.

Er is een TIP wens gepubliceerd om goed bij te kunnen houden welke behandelaars actief in de omgeving zijn zodat de licenties beheerd kunnen worden. Ik heb jullie inzichten die jullie hier hebben gedeeld in het TIP-verzoek meegenomen en jullie inzicht staat geregistreerd in het TIP verzoek. De link naar het specifieke verzoek: https://tip.topdesk.com/c/248-operator-usage-visibility-in-license-overview


Forum|alt.badge.img
  • Employee
  • June 30, 2026

@Kim Duinmeijer De verwachting is dat het weghalen van deze knop gereleased wordt rond 24-27 juli. Met een volgende herstart zal de optie daarna weg zijn.

Ik raad echter heel sterk aan om niet tot het laatste moment te wachten, als je twijfelt of een behandelaar voor automatiserings doeleinden wordt gebruikt zou ik de kaart sowieso overzetten naar een API-account waarbij de kaart dan altijd nog gearchiveerd kan worden zodra duidelijk is of die nog gebruikt wordt.


Forum|alt.badge.img+3
  • New Member ⭐⭐⭐
  • July 3, 2026

@Kim Duinmeijer De verwachting is dat het weghalen van deze knop gereleased wordt rond 24-27 juli. Met een volgende herstart zal de optie daarna weg zijn.

Ik raad echter heel sterk aan om niet tot het laatste moment te wachten, als je twijfelt of een behandelaar voor automatiserings doeleinden wordt gebruikt zou ik de kaart sowieso overzetten naar een API-account waarbij de kaart dan altijd nog gearchiveerd kan worden zodra duidelijk is of die nog gebruikt wordt.

Hoi Tom, dankjewel voor je reactie. Uiteraard proberen we de accounts ruim voor eind juli te hebben doorlopen en waar nodig aangepast. Er zijn een aantal accounts niet gewoon om te zetten omdat de toepassing niet duidelijk is (legacy) of omdat deze bijvoorbeeld nog voor HTTP acties worden gebruikt. We werken aan omzetting van die HTTP acties maar voor enkelen is dat (nog) niet mogelijk dus kan het account niet omgezet naar een API-account. We gaan er met onze planning dan nu vanuit dat de omzet mogelijkheid per 24 juli weg is.

In het algemeen omtrent de communicatie van de releases: 
Hoewel ik snap dat een specifieke datum voor een omgeving lastig te geven is vanwege pipelines is een specifieke “Vanaf datum” al heel fijn. Natuurlijk weet ik niet helemaal hoe het aan de achterkant technisch werkt maar ik neem aan dat het vooraf bekend is wanneer een nieuwe/oude functionaliteit wordt aan- dan wel uitgezet. Dat het dan, afhankelijk van de pipeline waar de specifieke omgeving in zit, nog enkele dagen of weken kan duren is te overzien. Het is vervelender als er”Begin augustus” wordt gezegd en dat voor sommige omgevingen dit al eind juli blijkt te zijn. 

Als voorbeeld de communicatie omtrent omzetten naar API accounts; in de tekst staat te lezen “Na juli 2026 is...”. Ik interpreteer dat als vanaf 1 augustus is de functie weg. Uit Tom's reactie begrijp ik dat dit mogelijk al per 24 juli is. Met 20+ klanten kan dat ene weekje net die week zijn waarin we de laatste klanten zouden gaan aanpassen.