Integration MS DYNAMICS with OTRS

Date: 05 May 2020


One of the key goals of the project in which we had the opportunity to participate in some time ago was the advanced integration of OTRS 5 Community Edition and Microsoft Dynamics CRM 2011 systems. At Intalio, we were responsible for providing functionality on the ticket system’s side, of course in close cooperation with dedicated people on the client’s side.

  • Of course, both systems - OTRS and Dynamics - contain certain elements that, with a little effort and several hundred lines of code, can process identical sets of information. Then you just have to force them to share among themselves...


OTRS and the not-almighty Generic Interface

Something that initially seemed to be a good training in the use of the GenericInterface module, showed that this element of the system - though prepared thoughtfully and after many iterations - does not allow achieving full synchronization of both systems. The deeper we went into the nuances of protocols, objects and security issues, the more we began to realize that we have a lot more work ahead of us than we initially expected.

  • Generic Interface was created mainly for reports (Ticket objects) and notes / e-mails (Article objects). We also needed to exchange information about Organizations (CustomerCompany), their employees (CustomerUser), services (Service) and ... contracts, which would also be an integral part of OTRS on many levels (e.g. panels with information about customers and the AgentTicketZoom screen, i.e. a detailed view of the notification).

So we had to start by creating a completely new and non-trivial module that allows full transparency of time and costs generated by Organizations and their employees. Thanks to intensive testing, both on the client's side and in Intalio (of course we also use OTRS ourselves), it was possible to bring this colossal subproject to the expected shape. More details about it can be found here.


Incidents and requests

While the OTRS role of the information server is nothing special, handling incidents occurring inside the system is something worth mentioning. Few even modern solutions have such a mechanism, and certainly not of such class as OTRS. Without going into technical details, I will just write that it is a paradise for both the administrator and the programmer.

Exactly that has enabled us to implement agile security that always ensures full data integrity, even historical one, if any external technical problems arise with OTRS and MS Dynamics communication.


Controlled flow of information

The synchronization module written and based on our experience with OTRS always cares for the correct order of information sent to CRM. After all, we won't create a CustomerUser object without first creating CustomerCompany. And you have to remember that the integration mechanism allows you to support the entire life cycle of all major objects...

  • The Client has Contracts under which Services are provided to him. Services are marked in Reports created by Customer Users. Agents handling these Reports save the necessary billing information so that the Contract can be settled later.


This is how it is saved on the side of the OTRS system and our integration module. It's almost the same on MS Dynamics’ side... Unfortunately, the way incidents are handled within CRM is not as refined as in the notification system. Repeated and tedious tests finally allowed to determine the "regularities" that govern Microsoft Dynamics when it comes to sending data "out".

Unfortunately, this does not mean that they are always logical: in fact, CRM first tries to create a CustomerUser object in OTRS, and then a CustomerCompany - although it does not allow such things on its own (simply, technically - it is impossible). The other objects / entities themselves proved to be another problem - e.g. the "notification title" field (required in OTRS already at the stage of its creation) -CRM "sends it later" in one of the POST requests...

All the problems mentioned above could not be eliminated on the Microsoft system side. To be able to bring the project to a happy ending, it was necessary to handle these incidents in the verification mechanisms of the integration module. The power of open source. :)