We want to give you a heads-up about a series of changes coming from the One TOPdesk User Project. With this milestone, all human accounts will have a person card, and the person card increasingly becomes the leading card in TOPdesk.
The goal of this milestone is to manage linked operators and persons in one consistent way, to make sure the product works as intended, and to use the operator-person linkto make user management easier. Below you'll find an overview of all the changes.
A number of them affect how you work today — especially around integrations, archiving, anonymization, and managing your licenses. Some parts come with a hard deadline. That's why we're sharing them now, so nothing catches you off guard and you can take action in time.
We expect to release most of these features between mid-June and the end of July. Where a part follows a different timeline, we'll mention it below. And as soon as something actually goes live, we'll of course let you know here.
Every user gets a person card
By the end of this milestone, every user has their own person card. Last year and the beginning of this year, you already linked operator cards with their matching person card. The remaining Operators without a linked person card will get one too. This way, every person in TOPdesk is recorded and found in one consistent way.
What does this mean for you? Persons are managed more consistently across the whole application. There's nothing you need to do yourself: the change is applied automatically. Operators who don't have a linked person card yet will be assigned one automatically. This card holds the same general information as the operator card, with two important remarks: it does not have access to the Self Service Portal and can't be selected as a caller.
Easier management of linked operators and persons
Because the person card becomes the leading card, we're adding a few conveniences for when you manage users via the person card.
Archiving and unarchiving
We align archiving and unarchiving behavior with the linked person card, so you can manage a user consistently in a single action. When you archive a person card, the linked operator card is now archived as well. This also applies when it happens through an integration.
What does this mean for you? Check your integrations, especially if you use name or email address as the unique identifier to import users. Consider to change the unique identifier to for example employeeID. This helps you avoid archiving operator cards unintentionally.
Deleting
We align deletion behavior with the link between operator and person card. When you delete a person card that holds no links, the linked operator card is deleted as well.
Anonymization
Because operators now also have a person card, we're bringing the anonymization of operators and persons together into one approach. This has two concrete consequences:
- The separate anonymization settings for operators are going away. Until now, you managed these through their own, separate settings.
- Operator anonymization is linked to person anonymization. Anonymizing an operator now follows the same route and the same rules as anonymizing a person.
What does this mean for you? If you use operator anonymization (for example in the context of GDPR), the place and the way you set it up will change. Review your current way of working and any internal agreements around it, and align this with your application manager or privacy officer.
Integrations: using the API via the SSP? Update your integrations
In our API, there are endpoints that serve both persons and operators, where some behave differently depending on who makes the call. As we move toward one unified user model, we're splitting this: the person (SSP) behavior gets its own, alternative endpoints. This was already mentioned in the February 2026 release notes, but we'd like to highlight it once more.
The affected endpoints include: GET /branches, GET /persons (v2 only), GET /persons/{id}, GET /locations, and GET /avatars/operator/{id}. The accompanying KI article (KI 18843) contains the full overview of the affected endpoints and how to use them.
What does this mean for you? If you call these endpoints from a person context (for example via the Self Service Portal), update your integrations to the new /tas/api/requester/... endpoints. Do this before the end of June. Do you have integrations built by a partner or supplier? Then align with them in good time.
Convert API account functionality is being removed
After July 2026, it will no longer be possible to convert an existing operator account into an API account. If you need an API account after that, you'll create a new one.
What does this mean for you? Make sure you've converted the API accounts you need before the end of July.
Changes in the overviews
Operator license overview also shows person data
In the operator license overview, the last active date column will also show data from persons. The date indicates when the user (operator or person) last logged in — this can be either the SSP or the operator portal. This takes effect from August 2026 onwards; keep this in mind when managing your licenses.
Questions or input?
Do you have questions, are you running into something, or do you want to share something with us about these changes? Feel free to let us know in the comments below. We're happy to think along with you.