Skip to main content
Question

IDU inrichitng wijzigingen

  • July 6, 2026
  • 5 replies
  • 50 views

Forum|alt.badge.img+4

Hallo,

 

Wij hebben momenteel het IDU proces dat loopt via de actiereeks KI 12091 van TOPdesk zelf.

 

We willen de volgende dingen aanpassen, heb al met Gemini zitten stoeien en kom ver, maar ik vermoed dat de API van TOPdesk dingen tegenhoudt.

 

Wij krijgen een mail uit AFAS binnen die onderstaand format heeft:

Naam: ACHTERNAAM, VOORNAAM
Personeelsnummer: XXXXXX (waarde kan verschillde lengte hebben, maar in principe geen probleem)
Functie: NAAM FUNCTIE
OE: ORGINISATORISCHE EENHEID
Datum functiewijziging: DD-MM-YYYY
Bedrijfsmiddel: SOORT HARDWARE (dit gaat al goed)
Actie: De medewerker dient een BEDRIJFSMIDDEL in te leveren / Leven een BEDRIJFSMIDDEL uit aan

Wij hebben meerdere actiereeksen, met bijbehorende sjablonen, triggers en mailimports voor de scenario’s In dienst, Uit dienst, Doorstroom (in en uitgifte), dit per type middel.

 

Wij willen meerdere dingen bewerkstelligen.

 

Het zou fijn zijn als we automatisch de implementatie datum konden invullen uit de tekst van de mail.

Tevens willen we aan de hand van het personeelsnummer de persoon koppelen, in elk geval voor wijzigingen die betrekking hebben op Uit dienst en doorstroom, want soms komt de wijziging eerder dan de persoon in TOPdesk.

 

Concreet waar ik tegenaan loop is:

Bij gebruik van de API: /tas/api/operatorChanges/{identifier} met de PATCH actie lukt het niet om deze dingen te implementeren.

 

Als ik kijk zie ik niet staan dat de implementatiedatum is in te vullen op basis van de genoemde velden.

Verder staat er wél als endpoint de /caller bij, echter, hoe deze aan te roepen is mij een raadsel. Gemini blijft beweren dat de documentatie zichzelf tegenspreekt, maar ik hoop dat anderen hier wel een idee voor hebben.

 

Ik heb ook getracht deze waarden te injecteren voor het toepassen van het sjabloon, maar ook dacht mocht niet slagen.

 

Als het antwoord nee, dit is niet mogelijk, is dan is dat ook duidelijk, maar het feit dat /caller genoemd wordt vind ik op z’n minst opvallend.

 

Ik hoop dat iemand een idee heeft.

 

Alvast bedankt! 

 

Groetjes,

Sascha

5 replies

KevinStouthandel
Forum|alt.badge.img+3

Hi Sascha,

In de developers.topdesk.com documentatie zie ik in /operatorChanges (Change Management | TOPdesk API) de implementation date staan:

 

Echter zie ik hem alleen bij "simple” staat wat zou betekenen dat bij een uitgebreide wijziging dit niet kan.

Dan nog wat ongevraagd advies/vragen 😁:

Jullie situatie lijkt mij een ingewikkelde constructie, als ik het goed begrijp krijg je dus uit AFAS alle soorten wijzigingen terug, maar dus ook per type asset een wijziging? 

Heb je in TOPdesk ook alle assets per persoon staan? Dan zou je kunnen kijken naar een opzet waarbij je per soort (In dienst, Uit dienst, Functiewijziging) een wijzigingssjabloon hebt en dan via een automated action de wijzigingsactiviteiten erbij haalt op basis van:

  1. In dienst en Functiewijziging: Functieprofielen assets
  2. Uit dienst: Toegewezen assets op naam van de gebruiker

Ik kan mij voorstellen dat dit natuurlijk wel een andere aanpak en een impact voor inrichten is, maar misschien een denkrichting waar je iets mee kunt.

Daarbij hebben wij de implementation date op de uitgebreide wijziging op automatisch staan waarbij de laatste wijzigingsactiviteit de einddatum bepaald.


Forum|alt.badge.img+1

Waarschijnlijk niet direct een antwoord op je vraag, maar wij gebruiken ook AFAS en importeren de mail voor het IDU proces (we doen daarbij niets met assets).

Waar ik tegen aanliep was dat we problemen hadden met bijwerken van de geïmporteerde mail/change.
Uiteindelijk in ik in de geautomatiseerde actie verschillende stappen moeten opnemen waarbij in de eerste stap de changetype wordt gewijzigd naar uitgebreide wijziging.
In de tweede stap wordt het juiste sjabloon gekoppeld.
En in de vervolgstappen worden pas andere zaken aangepast, zoals aanmelder, korte omschrijving.

Het samenvoegen van deze stappen leidde bij ons steeds tot foutmeldingen.

 


tverschuur
Forum|alt.badge.img+5
  • Explorer ⭐⭐⭐
  • July 6, 2026

@Sascha  Op jouw vraag:  Het zou fijn zijn als we automatisch de implementatie datum konden invullen uit de tekst van de mail.

 

Toevallig heb ik vorige week ook een vraag over de implementatiedatum bij TOPdesk Support neergelegd.

Verzoek
- Op verschillende manieren willen we via een API een Wijziging kunnen aanmaken, bijvoorbeeld met een koppeling tussen Jira en TOPdesk.
Vanuit Jira wordt dan de opdracht gegeven om in TOPdesk een Wijziging aan te maken. 
Waar ik nu tegenaan loop, is dat het mij niet lukt om de Autorisatiedatum of Implementatiedatum aan te passen. In de achtergrond lijkt dit hetzelfde veld te zijn: plannedEndDate.

Klopt het dat je binnen een actiereeks de waarde van plannedEndDate niet kunt meegeven voor:
Autorisatiedatum (plannedEndDate) bij een Uitgebreide Wijziging: Aanvraag → In Uitvoering
Implementatiedatum (plannedEndDate) bij een Uitgebreide Wijziging: Aanvraag → In Uitvoering

Antwoord Support:
Beide velden berekenen een datum op basis van andere gegevens op de wijzigingskaart. Om die reden is het niet mogelijk deze te wijzigen via een automatische actie. 

Dit was mijn iets uitgebreidere antwoord aan mijn aanvrager: 😉

Scenario 1: Wijziging komt binnen als 'In aanvraag'
Wanneer een wijziging wordt goedgekeurd (status Approved) verschijnt de melding 'Sjabloon toepassen'.
Hier kunnen de volgende velden worden ingevuld:
•    Startdatum activiteiten → Starten op
•    Implementeren voor
Op dat moment wordt de implementatiedatum van de wijziging gevuld.
 
Scenario 2: Wijziging komt binnen als 'In uitvoering'
Wanneer een wijziging direct in uitvoering wordt aangemaakt, kunnen de wijzigingsactiviteiten direct starten.
Standaard wordt dan een implementatiedatum berekend op basis van de ingestelde planning.

Wanneer vervolgens de geplande einddatum van de wijzigingsactiviteit wordt aangepast, wordt de implementatiedatum van de wijziging automatisch mee aangepast.

Het rechtstreeks vullen van de implementatiedatum via de TOPdesk API is dus niet mogelijk. Als we de implementatiedatum willen beïnvloeden, zal dit via de gekoppelde wijzigingsactiviteit moeten gebeuren door de geplande start- en/of einddatum aan te passen.
Met andere woorden: de keuze voor de workflow (In aanvraag of Direct goedgekeurd) en de wijzigingsactiviteit bepaalt mede hoe we de implementatiedatum kunnen laten aansluiten op de werkwijze binnen TOPdesk.

 

 


Joost Oostindie
Forum|alt.badge.img+9

Hi Sascha,

Volgens mij zijn dit eigenlijk twee verschillende beperkingen.

De implementatiedatum is denk ik goed beantwoord door ​@tverschuur, voor een uitgebreide wijziging wordt deze berekend en kun je hem niet rechtstreeks invullen.

Voor /caller verwacht de TOPdesk API dan een referentie naar een bestaand persoon.
Dit kan op twee manieren:

  • Middels de dynamicName (op te halen via /tas/api/persons/{id})
  • Middels het id van de persoon (bijvoorbeeld op te halen via /tas/api/persons?query=lastName==Oostindie)

Het kan natuurlijk ook zo zijn dat je deze informatie al uit eerdere stappen haalt en hier kan gebruiken.
Werken met id is het meest veilig, omdat iets naam zou kunnen veranderen, maar beide werkt!

Als je dit niet al doet betekent dit dat je eerst de persoon via de persons API zou moeten opzoeken en daarna pas /caller kunt gebruiken.

  • dynamicName is op te halen via "/tas/api/persons/{id}”, maar dan heb je vaak het id al en die volstaat ook
  • id is op te halen met een algemene get op personen en te specificeren middels een query, bijvoorbeeld "/tas/api/persons?query=lastName==Oostindie”

Uiteindelijk kun je hem in je patch request als volgt noteren:

[
  {
    "op": "replace",
    "path": "/caller",
    "value": ""
  }
]

Bij de value vul je dan de response in van het id dat je hebt, of de dynamicName van de persoon (bijvoorbeeld ‘Joost Oostindie’, of ‘Oostindie, Joost’)

Hopelijk helpt dit!


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

Wij krijgen via een extern systeem ook dit soort text via API ingeschoten en kunnen dan de velden eruit halen:

 

Type of Request: New
AFAS Personeelsnummer: 1000001
Name Employee: Johannes de Vries
Manager: Pietje Puk
Comment:
Manager Email: pietje.puk@zijnemail.nl
New access righs : Directeur
Date hired: 2026-07-06T00:00:00Z
Date change: 2026-07-06T00:00:00Z
Date Exit:
Afdeling: Ergens in NL
Function: Allround Medewerker Directie
New location: 210 Directie

 

Eerst een GetInfoFromChange query en dan bv: