Wat is de TOPdesk API?
Kort antwoord: een REST-interface bovenop je TOPdesk-omgeving waarmee externe applicaties gegevens kunnen opvragen en wegschrijven. Je hoeft dus niet in TOPdesk zelf te werken om een melding aan te maken of een status bij te werken. De API ontsluit de objecten waar een servicedesk dagelijks mee werkt: meldingen, wijzigingen, assets, personen, vestigingen en operatorgroepen. Dat laatste object is belangrijker dan het lijkt, want daarin zit de autorisatiestructuur van je organisatie verstopt. Wat de API niet doet, is bepalen wat er met die data gebeurt, en dat is precies het deel dat je zelf bouwt of laat bouwen.
Waarvoor organisaties TOPdesk gebruiken.
TOPdesk is een ITSM-pakket: IT service management, oftewel het inrichten en bijhouden van dienstverlening rond IT en facilitaire zaken. Je vindt het bij gemeenten, onderwijsinstellingen, zorgorganisaties en managed service providers, en de rode draad is er altijd dezelfde. Er is een servicedesk, er komen meldingen binnen, en er is een afsprakenkader over hoe snel die worden opgepakt. TOPdesk registreert dat proces uitstekend, maar het probleem begint zodra de mensen die een melding indienen zelf niet in TOPdesk werken.
Wat je met TOPdesk kunt.
Binnen TOPdesk beheer je meldingen van intake tot afhandeling, houd je een configuratiedatabase bij met assets, en registreer je wijzigingen en SLA-afspraken. Voor een IT-afdeling die intern werkt is dat compleet. Waar het pakket ophoudt is aan de randen: een huurder die een storing wil doorgeven, een dealer die een RMA aanmeldt, een medewerker die een laptop nodig heeft. Die mensen geef je niet allemaal een TOPdesk-licentie en een inlog, en je wil ze ook niet in een omgeving zetten die voor operators is ontworpen. Dat is het gat dat een koppeling dicht.
Wat een TOPdesk-koppeling oplevert.
Met een TOPdesk-koppeling laat je andere systemen het werk doen dat nu handmatig gebeurt. Meldingen worden aangemaakt vanuit een eigen omgeving, bijvoorbeeld een werknemersportaal of een klantportaal: de gebruiker vult een formulier in, de melding staat in TOPdesk en niemand tikt iets over. Statusupdates gaan dezelfde weg terug, zodat de indiener in het portaal ziet wat er met zijn melding gebeurt zonder te bellen. Daarnaast houd je assets en personen synchroon met je bronsysteem, zodat de configuratiedatabase actueel blijft, en zet je SLA-data door naar een dashboard of een data-integratielaag, zodat rapportage niet meer uit exports komt.
Welke data tussen TOPdesk en je systemen stroomt.
Richting TOPdesk gaan nieuwe meldingen, bijlagen, wijzigingen op bestaande meldingen en assetgegevens. Richting je eigen systemen komen statussen, doorlooptijden, operatortoewijzingen en SLA-informatie terug. De richting per objecttype is daarbij een ontwerpkeuze en geen technische: wie is eigenaar van de personenlijst, TOPdesk of je HR-systeem? Dat besluit bepaalt de hele koppeling, en het is het gesprek dat je aan het begin wil voeren in plaats van halverwege.
TOPdesk-integratie in de praktijk: hoe Cube koppelt.
Cube bouwde een TOPdesk-integratie met asynchrone push jobs die meldingen en updates buiten het gebruikersproces om verwerken. Dat betekent dat een gebruiker nooit op TOPdesk staat te wachten: het formulier is direct verzonden, de koppeling handelt de aflevering af en biedt de melding opnieuw aan als de API even niet bereikbaar is. Voor de servicedesk verandert er niets aan hoe meldingen binnenkomen, alleen zit er geen mens meer tussen die ze overtikt.
Autorisaties per operatorgroep: de rechtenmatrix.
Hier lopen TOPdesk-koppelingen in de praktijk op vast, want een melding is niet zichtbaar voor iedereen. Welke operatorgroep welke melding mag zien, bewerken of afsluiten verschilt per organisatie en soms per vestiging, en als je dat niet expliciet modelleert krijg je een van twee uitkomsten: gebruikers zien te veel, of ze zien te weinig en gaan alsnog bellen. Cube bouwde daarvoor een rechtenmatrix in de koppeling zelf, die per operatorgroep en per meldingstype vastlegt wat zichtbaar en wijzigbaar is, los van wat er in TOPdesk aan rechten staat. Zo blijft de logica op een plek staan en is hij te testen.
Standaardconnector of maatwerkkoppeling.
Eerlijk antwoord: begin bij het standaardaanbod. TOPdesk heeft een marketplace met apps en met actiereeksen kom je al een heel eind zonder een regel code, dus voor een koppeling met een bekend pakket en zonder afwijkende autorisaties is dat vaak genoeg en aanzienlijk goedkoper. Maatwerk wordt pas de betere keuze zodra een van drie dingen speelt: je koppelt aan een systeem waarvoor geen app bestaat zoals je eigen portaal, je autorisatiestructuur past niet in wat de standaard biedt, of je hebt volume en wil grip op wat er gebeurt als de API eruit ligt. Zit je daar niet, dan zeggen we dat ook.
Een TOPdesk-koppeling laten bouwen.
We beginnen met de vraag welke data waarheen moet en wie eigenaar is van welk object. Daaruit volgt de koppelrichting, het autorisatiemodel en de foutafhandeling, en pas daarna bouwen we. Onze aanpak voor API-koppelingen beschrijft hoe dat traject eruitziet.
Kort samengevat.
De TOPdesk API ontsluit meldingen, assets, personen en operatorgroepen via REST. Een koppeling is zinvol zodra de mensen die meldingen indienen buiten TOPdesk werken. Voor bekende pakketten volstaat de marketplace vaak, maar bij een eigen portaal, afwijkende autorisaties of volume wordt maatwerk de betere keuze. Cube bouwde zo'n integratie met asynchrone push jobs en een rechtenmatrix per operatorgroep.
Meldingen uit je eigen portaal in TOPdesk krijgen?
Benieuwd wat een TOPdesk-koppeling voor jouw servicedesk betekent? Neem contact op, dan kijken we samen naar de objecten, de koppelrichting en de autorisaties.