Skip to main content
Winnie Tsang
Employee
Employee
June 4, 2026

One TOPdesk User mijlpaal: alle human accounts hebben een persoonskaart

  • June 4, 2026
  • 16 replies
  • 482 views

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
Inspirer
June 8, 2026

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?
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
Starter ⭐
June 11, 2026
  • 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?

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
Starter ⭐
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.
 

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.

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
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.

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
Employee
June 15, 2026

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

 

Sanne van Opstal-Brakel, your TOPdesk Community Fairy Godmother
Suzanne Machielsen-Bijleveld
Starter ⭐
June 22, 2026

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.