SolarWinds Two-Way integration with Ticketing Systems

They have integration with ServiceNow -- I don't know if it will do what you want, but I think it will.

We have service now, but do not use the API because:

a) we had something years before Solarwinds built their API

b) we don not resolve incidents automatically when service is restores.

I am the ITIL Event and the Incident process manager in my department; I feel that resolving incident tickets immediately that an interface or node restores may be a bad idea process-wise. It might be a good idea to note the time that service is restored in the incident record automatically or update a public status board, but I feel NOC staff ought to be looking at these records, e.g. to request a RFO from a carrier, create a problem record to have UPS installed, power recabled, busted switch replaced, or a myriad of other things that could prevent future incidents.

[My team works about 2000 incidents/ month, of which at least 2/3rd were created automatically by Orion NPM]

I feel Every Alert / incident should have actions performed by the NOC, even if the action is to turn down the alert.

Im looking at API using the get and post in the actions of an alert.

Using Manage engine as the ticket system.

So would see if any of them have instructions for there api

i believe two way should be possible now as well. If solarwinds sends down alert and then and Up alert for reset, the ticketing system should have the rules to understand that and close it...in my experience this is what i have seen it. Not only Solarwinds but it could be any other tool.. The monitoring tool send the traps/email or through API and the ticketing system has some rules or there will be a Manager Of Manager(MoM) which correlates in its bucket and then sends to ticketing tool....

The company I am currently at uses the Service Now integration. It works pretty well but has some bugs.

At a previous gig. We sent all Solarwinds tickets to our helpdesk's queue. Then literally through custom SQL and our naming standard having all nodes in 'x' site with the same naming standard (CHICAGO) for example we would auto-route the ticket to the Chicago queue. We added a custom property for the 'app' a device supports and gave the helpdesk a key for datacenter servers. The helpdesk would then reference the key and assign the ticket to 'x' team. (IE: Application = AutoCad. AutoCad = IT Engineering team). It wasn't perfect and we didn't get all the way there but it was good enough to resolve issues as if we saw a server go down or something it was all hands on deck