Apr 04

Is Your Tool Integration Ready? The nature of ITSM Tool Integration

Integration Made Simple

The purpose of the SIAM Broker is to connect processes of different IT Service Management tools between consumer of services and provider organizations.
To make this possible each tool and process must be integrated to the SIAM Broker.

Is your tool fit for integration?

Lomnido integrated a lot of ITSM workflows in multi-provider environments in the last years. Here are some experiences we made. The considerations what will be the effort to achieve the integration depend on the following facts.


If your tool has a well-known and documented API you will have the smallest amount of work to do because the technical functions procedures to create, send and update cases is already defined and you can go in detail about the functional requirements. In practical life this is the most uncommon situation we focus in integration tasks.

Programmable API

If your tool has the possibility to create a functional API you will have to do more work in your tool and provide the technical functions to create, send and update cases before you can start to think about the behavior for your processes. In practical life this is the common situation we focus in integration tasks.


In practical life this is also common situation we focus in integration tasks.

If your tool has no API with available documentation, integration is at least very hard. You could maybe directly access the database with SQL or build any other “hacks” to retrieve data or change data in your tool. The possibilities are:

  • Make it simple … to participate in a process you can use the email function to exchange data and parse the content to create, send or update cases in your system. The complexity should not exceed the possibilities of the parsing mechanism. To increase the reliability some mechanisms for asynchronous communication must be integrated, such as “confirm the retrieval” messages.
  • Use methods like SQL or other transport protocols to update cases in your system and consider the complexity and reliability.

For sure this are complex situations which needs more time for specification and testing during the process of creating the connection. It can be also a strategy to upgrade to a different tool/version which includes the possibilities you are looking for.

What kind of integration do you need?

Here are some thoughts you should consider in designing the functional specification.

Status codes? forget them!

No not really, but change your view on them. Integrations will not send status information between tools. It will send the action to change a status in a ticket. You should think in use cases like:

  • At this point I want to OPEN a ticket in the partner system
  • At this point the partner system can update the ticket to SOLVED
  • At this point I handover the ownership to the partner for answering my question

Consumer or Provider

First, you must be clear about if your tool/process will act as consumer or as provider of services. This will influence the type of complexity.

The most common case is that if your tool acts as a consumer you want to raise cases at the external system and waits for the fulfillment of the request. The other way around if your tool acts as a provider system you will waits for request and will provide updates to the consumer.

But there are more use cases like informational tickets and ownership changes during a workflow which will increase the need of a accurate design in the communication.

Clear ownership & lock ticket

If you share tickets with your partner, it must be clear at any time who is responsible for the ticket. If the ticket has not the ownership lock the ticket in your tool! With locking the ticket, you ensure, that your tool agents must wait until your partner hands over the ticket again to your tool. Then take the ownership and keep on going in your workflow.

Not having a clear ownership will produce unsynchronized situations where it is not clear who is responsible and leads to a lot of technical errors in the API communication that needs in worst case manual intervention to setup the ticket synchronization again. Organizational rules will not heal this kind of technical deficits.

Do not care about the details of your partner’s workflow

Focus on your workflow, describe the handovers and the expectations on the reenter points to your workflow. Define your expectations on the connected partner. Define the “Must Haves” and “Nice to Haves”.

If you start in detail comparing the single workflow steps of your partner tools with your workflows, you have already reached the first step of failing integration. As soon as you want to integrate the second or third tool you will definitely fail, because not all of your partners can handle your full expectations and vice versa.

Focus on the results you want to achieve

The main purpose if your system act as consumer is that you will have a contractual agreed service request that should be fulfilled by the provider. On other hand when you act as a provider you will wait for a request an provide the updates until you finish the issue. No matter if this is an Incident, Problem, Change, or even to order food online.

In an Incident ticket case, the expected result is the recovery of a service. In a Change ticket case, it is getting the Approval or Deny. Do not take so much effort in mapping the steps in between, just care about the steps you need to track for contractual or practical reasons. Focus on getting/sending the “Solve” and “Approved”.

Example of an workflow enhancement

Her you see a simple Incident workflow as it is used often in helpdesk tools.

Switching between the helpdesk levels or groups is done in “In Progress” with an “Update”.

So, handover from first level to second level is an “Update” within status “In Progress” just by changing the assigned group.

The responsibility is defined with the assigned group.

Handover ticket to partner as a group

I you want now to enhance your workflow to handover a ticket to your partner systems, you could either work with a new group and assign the ticket to the group “Partner Provider” and this should raise the trigger to create the message to the external system or add an explicit status like described in the next session.

Handover ticket to partner as a status

If you prefer assigning tickets to the partner with groups or with an explicit status depends on technical requirements in your tool.

Most important is, that the ticket can be locked when it is at your partner’s side.

Your agents should not be allowed to solve the ticket anymore. This is now the job of your partner.

Another thing is the SLA measurement. Is this easier with a group or a status?

The hack with mandatory fields

On every different process and transaction, tools need mandatory content to write the case into the system.  This is the baseline for the integration. But for the work some additional content is a must to send in a correct way. Some systems can create a ticket over the API only with a bunch of information that the partner system cannot supply. To set default values or map values correctly is a task that only the people who use the systems can answer. So, the number of mandatory content should be as low as possible.

 Configuration Item

Both systems must talk about the same service and the same item. In most cases they are in a different structure and in different names stored. So, one of the partner system have to use the values of the other system or the translation has to be done in the integration layer.