In case your time is short

INOC’s ITSM integration streamlines communication between your system and INOC’s Incident Management Platform via a RESTful API interface. This integration allows you to manage tickets within your existing ITSM platform while leveraging INOC’s operational workflows.

We offer two integration types:

Standard Integration: A simplified setup supporting basic ticketing and standard data fields. Ideal for organizations needing visibility into INOC-managed incidents without extensive customization.
Custom Integration: A tailored solution supporting multiple ticket types, custom fields, and advanced workflows for organizations requiring deeper collaboration.

You can choose between unidirectional (tickets created in one system) or bidirectional (tickets created and updated in both systems) integration patterns based on your operational model.

The guide covers:

Integration options and their technical requirements
Steps for a successful setup, from kickoff to testing
Common challenges and solutions
Best practices for preparation and security

Whether you need basic visibility or comprehensive collaboration, INOC ensures a seamless and secure integration experience.

Integration with INOC's Incident Management Platform is a critical component of transitioning to outsourced NOC support with us. It significantly improves the communication workflow between INOC and our clients, which is particularly crucial for organizations with strict Service Level Objectives (SLOs) around metrics like Time to Notify and Time to Acknowledge.

At its core, our ITSM integrations facilitate communication and data transfer between the INOC Platform and your system via a RESTful API interface. This integration enables you to work within your own familiar ticketing system while leveraging the operational framework and workflows inherent in the INOC Platform.

The INOC Ops 3.0 Platform at a glance

ino-Platform3.0-01

Learn more about Ops 3.0 »

The result is a more efficient process that eliminates the need for separate emails or phone calls. You receive timely notifications of new tickets and can update them directly within your system. We've developed and refined our integration process to ensure it's as smooth and efficient as possible, and we can integrate with all major platforms. Our integration platform as a service (iPaaS) has out-of-the-box integrations with popular platforms like ServiceNow, ConnectWise, and Jira. We can still work with any platform that supports RESTful API functionality.

This guide walks you through our approach to ITSM integration, helping you understand what to expect and how to prepare for success.

INOC Integration Options

imageonline-co-roundcorner (2)

We offer two distinct types of ITSM integration to meet varying client needs. Let me explain each type in detail so you can better understand which might be right for your organization.

INOC Integration Options at a Glance

Integration Option	Description	Ticket Type	Data Flow	Data Fields	Data Requirement
Standard	Standard integration that includes all data that would be sent in a ticket email	Incident	INOC is responsible for all creates and updates by either side	A standard set of fields	Ticket data and CMDB data are stored within the INOC Platform
Custom	Includes all Standard integration data flows plus any custom code or API calls as required	Incident, Change, Dispatch, Customer Notification, Problem	Creates and Updates can occur from either side	Custom set of fields as shown in the Custom Integration section	All Standard integration data requirements plus custom API calls to INOC or client Platform

Standard Integration

Our Standard Integration provides a streamlined approach to connecting your ITSM platform with ours. This option includes INOC incident ticket creation in your system and supports either unidirectional or bidirectional ticket updates using a predetermined authentication method.

Here's what's included in a Standard Integration:

Incident ticket handling (the primary ticket type for standard integration)
Integration via either our out-of-box templates or RESTful API calls
Data transfer of standard fields, including title, client ticket number, INOC ticket number, affected devices, impacted services, and client notes
INOC-controlled workflow management where we map our status states to your platform
Resolution control from the INOC side

It's important to note what's not included in Standard Integration:

Custom API calls for gathering additional data (like customer information or location data)
Special field mapping beyond our standard set
Integration with other ticket types like Changes, Customer Notifications, or Problem tickets
Custom field population in your platform
While these capabilities aren't included in Standard Integration, they are all possible through our Custom Integration process with additional scoping and planning.

Standard Integration works best for organizations with relatively standard ITSM configurations who primarily need visibility into our ticket handling and basic update capabilities.

Custom Integration

Custom Integration builds upon our Standard Integration foundation to provide more sophisticated capabilities. This option includes unidirectional or bidirectional data exchange between systems and can be tailored to your specific requirements.

A Custom Integration includes everything in Standard Integration plus:

Support for multiple ticket types (Incidents, Changes, Dispatches, Customer Notifications, and Problems)
Custom API calls to gather or place specific data
Ability to populate custom fields in your platform
More complex data mapping and workflow configurations

Which integration type do you need?

The choice between Standard and Custom Integration typically depends on how you plan to work with us. If you simply need visibility into the incidents we manage—to see our updates, track progress, and maintain records in your system—standard Integration will likely meet your needs. This is particularly true if you're using a common ITSM platform like ServiceNow, ConnectWise, or Jira in a relatively standard configuration.

However, there are several clear indicators that you'll need Custom Integration:

You'll be handling tier 2/3 support while INOC manages tier 1
You need integration for changes or maintenance windows in addition to incidents
You send customer notifications through your ITSM platform
Your ITSM platform has been significantly customized
You need specific data mapped to custom fields in your system

During our initial discussions, we'll help you determine which option best suits your needs. Sometimes, our clients start with Standard Integration and move to Custom Integration as their requirements evolve. The key is understanding your operational model and how you plan to interact with our services. We’ll guide you through this decision by examining your current ITSM configuration, support model, and integration requirements.

Understanding Integration Patterns: Unidirectional vs. Bidirectional

imageonline-co-roundcorner

Another key decision point is choosing between unidirectional and bidirectional ticket creation patterns. Let’s quickly run through the differences and help you understand which might be right for your needs.

Unidirectional Integration

In a unidirectional integration, tickets can only be created in one system — either INOC's platform or yours, but not both. However, once a ticket exists, updates can flow in both directions. This is often a good choice when you want to maintain a clear, single source for ticket creation.

Note: If you need tickets to originate from your system to INOC, this requires our Custom Integration option.

Bidirectional Integration

Bidirectional integration allows tickets to be created in either system—yours or ours. This provides maximum flexibility but requires more careful consideration of workflow design. Updates flow freely between systems, and both teams can initiate new work. However, it requires clear protocols to prevent duplicate tickets.

The figure below visualizes the dynamics of each integration approach.

Choosing between a unidirectional or bidirectional integration pattern also depends on your operational model. For instance, if your team handles Tier 2/3 support and needs to create tickets for INOC to address, bidirectional integration might be most appropriate. Conversely, if you're primarily looking for visibility into INOC-managed incidents, unidirectional integration might be the better choice.

Common Integration Scenarios

Having overseen many ITSM integrations at INOC, I've found that clients typically fall into two main categories regarding their integration needs. Understanding which category you fall into is crucial, as it affects both the timing and approach we take with your integration.

Scenario 1: Visibility-Only Integration

The first category includes organizations primarily seeking visibility into our ticket-handling process. In these cases, the integration serves mainly as a window into our operations, allowing you to monitor and track the status of incidents we manage. This typically involves a standard integration that includes a set group of basic fields, such as ticket title, description, latest note, and ticket number.

For these clients, we often implement the ITSM integration as a second phase after the initial onboarding is complete. This approach works well because, during the initial setup phase, email notifications can sufficiently keep you informed of ticket updates and status changes. By separating the integration from the initial onboarding, we can keep everyone focused on getting the core services up and running without adding unnecessary complexity.

Scenario 2: Full Tier 2/3 Support Integration

The second category comprises organizations that will be actively involved in ticket management. These organizations typically handle Tier 2 and 3 support while we manage Tier 1. These integrations are more complex and critical to day-to-day operations, as both teams need to work seamlessly together within their respective systems. These scenarios often require custom integrations, including additional data fields and more sophisticated API calls, to support the collaborative workflow.

For these clients, we implement the ITSM integration in parallel with the main onboarding process because the integration needs to be fully functional when the service goes live. Your team needs to be able to receive and work on tickets from day one.

This distinction is important because it helps us determine the timing, depth, and complexity of the integration we'll need to implement. For visibility-focused clients, we can often use simpler integration patterns, while active management scenarios require more sophisticated bi-directional synchronization and careful attention to workflow mapping between our systems.

In both scenarios, our goal remains the same: to create a seamless connection between our ITSM platforms that supports your operational needs while maintaining the integrity and efficiency of both systems. The key is understanding your requirements upfront so we can plan and execute the integration in a way that aligns with your timeline and operational model.

Technical Requirements and Prerequisites

imageonline-co-roundcorner (5)

Before beginning an ITSM integration with INOC, it's important to understand our technical framework and ensure your environment is properly configured to support it. We've designed our integration approach to be as flexible as possible while maintaining security and reliability.

Integration Methods

We use Zapier as our middleware solution. We chose it specifically because it's platform-agnostic and supports RESTful API functionality. This allows us to integrate with virtually any modern ITSM platform. The INOC iPaaS also offers out-of-the-box integrations with popular platforms such as ServiceNow, ConnectWise, Jira, and others.

We offer two primary approaches to integration:

1. Out-of-the-Box Integration Templates

Our iPaaS includes pre-built integration templates for many popular platforms. These templates simplify the integration process by eliminating the need for custom payload configurations. The integration logs into your system and performs several functions, including pulling all Created or Updated tickets and placing data into ticket fields. Updates are synchronized every 5 minutes through this polling process.

While we don't use these as frequently anymore due to their limitations with customized client systems, they can be an excellent option for organizations using relatively standard configurations of common ITSM platforms.

2. API-Based Custom Integration

For clients with more complex needs or customized ITSM implementations, we typically recommend our API-based integration approach. In this scenario, INOC will provide you with Create and Update endpoints that will receive payloads from your system.

Your team will need to create a way to send data on create and update from your system. However, most modern platforms like ServiceNow and Jira have this functionality built in. (If you need assistance with your platform configuration, we can recommend contractors familiar with your specific system.)

Technical Prerequisites

To ensure a successful integration, several technical elements need to be in place:

API Infrastructure Requirements

Your system must be capable of making RESTful API calls.
You'll need to configure endpoints for posting on your side.
Your system must support webhooks for posting to INOC endpoints.
You'll need technical staff who understand API calls and webhooks or be prepared to work with recommended contractors.

System Configuration Requirements

A custom field must be added to your system to capture and store the INOC ticket number.
Your system must be able to return the INOC ticket number with every update from your ITSM platform.
At a minimum, your system must be able to pass these required fields:
- For ticket creation: client ticket number, title, status, and comment
- For updates: client ticket number, INOC ticket number, title, status, and comment

Security Configuration

For authentication, our iPaaS supports several methods that apply to both Standard and Custom integrations:

Basic Auth
Bearer Tokens
OAuth (recommended as the industry standard)
Tokens in HTTP headers

Note that we cannot support multi-factor authentication or uniquely generated keys with each API call. The security of the integration is maintained through encrypted credentials and unique URLs with authentication keys.

Another important note on security: Security through our integration URLs is maintained through both the unique URL and an associated key. You need both elements to access the integration. We frequently work with clients with strict security requirements, and we're happy to schedule technical discussions to explain our security measures in detail.

Keep in mind that these are the base technical requirements. Depending on your integration needs—particularly for Tier 2/3 support scenarios—additional technical configurations may be necessary. We'll work with your team during the planning phase to identify any additional requirements specific to your implementation.

The Integration Process—Step by Step

imageonline-co-roundcorner (4)

We follow a structured yet flexible approach to ITSM integration that ensures thorough preparation, careful implementation, and comprehensive testing.

Let me walk you through each phase of this process, which typically spans a few weeks, depending on the complexity of your integration needs.

1. Initial Setup and Kickoff

The integration process begins with a kickoff call that sets the foundation for the entire project. During this critical meeting, we bring together key stakeholders from both organizations to align on objectives and share essential information.

First, we provide a high-level overview of how tickets flow through our system. At INOC, incidents move through a few possible stages:

New (set upon initial create)
In Progress (NOC actively working)
Pending (waiting on third party)
Pending Reason (indicates which third party we're waiting on)
Follow Up (indicates NOC needs to review)
Resolved (issue mitigated)
Closed

Understanding this lifecycle is crucial because we'll need to map these states to your system's status workflow. During the kickoff, we'll review your system's status progression and begin thinking about how these states will align.

We'll also discuss field mapping requirements. While there's flexibility in how data can be structured, we have some minimum requirements for successful integration.

At a bare minimum, we'll need to exchange:

Title
Description
Client Ticket Number
INOC Ticket Number
Affected Devices
Impacted Services
Client Notes

2. Workflow Development

After the kickoff, we develop detailed workflow documentation that serves as our blueprint for the integration. We create two critical workflow diagrams:

1. The Create Workflow

This documents how new incidents will flow through both systems. We detail:

Initial trigger points (phone calls, emails, alarms)
Data payload requirements
Field mapping specifications
Status handling
Verification checks

2. The Update Workflow

This outlines how updates will synchronize between systems, including:

Update triggers
Data requirements for updates
Status mapping
Comment handling
Resolution processes

We'll review these workflows with your team and get a formal sign-off before implementing. This step is crucial. About half the time, when we get to testing, we discover nuances that weren't apparent during the initial workflow design, so a thorough review at this stage can save significant time later.

Title
Description
Client Ticket Number
INOC Ticket Number
Affected Devices
Impacted Services
Client Notes

3. Implementation

Once workflows are approved, we move into development. We use a sprint methodology, with implementation typically spanning several two-week sprints depending on complexity. We begin implementation in our development environment, and depending on your capabilities, we'll work with either your development or test environment.

This phase involves:

Configuring the iPaaS with the agreed-upon integration patterns
Setting up authentication methods
Establishing API endpoints
Creating necessary custom fields
Implementing status mapping logic
Setting up data transformation rules

The duration of this phase can vary significantly — from as little as a day for standard integrations to several weeks for complex custom integrations involving multiple ticket types or sophisticated workflow requirements.

4. Testing

Testing is perhaps the most critical phase of the integration process. We follow a comprehensive testing protocol that examines every possible ticket creation and update scenario.

Test Scenarios

We systematically test ticket creation from all possible sources:

Phone calls to the NOC
Email submissions
Alarm-triggered incidents from our correlation tool
If applicable, tickets originating from your system

Then, for each scenario, we verify:

Proper field population
Status mapping accuracy
Comment synchronization
Update flow in both directions

Environment Testing

Testing occurs in two phases:

Development/Test Environment

Complete the full test suite in the development environment
Verify all workflows and mappings
Make necessary adjustments based on the findings
Get client sign-off on test results

Production Validation

Repeat the full test suite in the production environment
Verify security measures
Confirm proper configuration promotion
Validate end-to-end communication

Throughout the testing phase, we document all results and refine the integration as needed. We don't move to production until all test scenarios have been successfully validated and you're completely satisfied with the results.

One important note about testing: we've built our integration platform with an on/off capability. This means if we encounter any issues during testing, we can quickly disable the integration without affecting other systems or processes. This gives us the flexibility to troubleshoot and refine without risk to your production environment.

A Few Key Considerations for ITSM Integration

imageonline-co-roundcorner (3)

While the technical setup of an ITSM integration is important, several key operational considerations significantly impact the success of the integration.

Here's a quick walkthrough of two of the most critical aspects: status management and work assignment configuration.

Status Management

One of the most crucial aspects of our ITSM integration approach is ticket status management. I've seen integrations become problematic when not properly configured, so we maintain a very clear policy on status control.

INOC maintains control of ticket status in our system, which is relatively non-negotiable. Here's why: Our platform has sophisticated automation in place that triggers various workflows based on status changes. When a ticket update comes in from a client's system, our status control ensures it automatically goes into a follow-up state and gets presented to our NOC team for review and action. If clients could directly modify our ticket status, it would disrupt these automated workflows and could lead to missed updates or delayed responses.

That said, we do provide comprehensive status mapping between systems. We'll work with you to understand your status workflow and map our statuses to equivalent states in your system.

For example, a typical mapping might look like this:

INOC "New" → Client "Created"
INOC "Pending - Awaiting Client" → Client "Pending"
INOC "Resolved" → Client "Closed"

While you can't directly change the status in our system, you have complete control over how you map and use our status updates. We send you all status changes, and you can configure your system to handle these updates according to your internal processes.

Work Assignment and Team Configuration

For clients who handle their own Tier 2/3 support, proper work assignment configuration is essential for efficient operation. We've developed a flexible approach accommodating various team structures and routing needs.

On our side, we use what we call "client groups" to manage different support teams. For example, if you have separate network and database teams, we can configure distinct client groups for each. This allows us to route tickets to the appropriate team based on the issue type or category.

Here's how it typically works:

During integration setup, we identify your different support teams and their responsibilities.
We create corresponding client groups in our system.
We establish routing rules based on issue type, category, or other criteria.
When our tier 1 team identifies an issue that requires escalation, they can assign it to the appropriate client group.
The integration then ensures the ticket is routed to the correct team in your system.

This configuration is particularly valuable for organizations with specialized support teams. For instance, if our NOC team identifies a database issue that requires Tier 2 support, they can assign it directly to your database team's client group, ensuring it reaches the right experts without unnecessary routing delays.

A key benefit of this approach is its flexibility. We can adjust the routing rules and team configurations as your organization evolves. If you add new teams or redistribute responsibilities, we can update the client groups and routing logic accordingly.

The goal of these configurations is to ensure that tickets flow smoothly between our organizations while maintaining the integrity of both systems' workflows. Taking the time to properly set up status management and team configuration during the integration process will pay dividends in operational efficiency once the integration is live.

Common Integration Challenges (and Solutions)

imageonline-co-roundcorner (4)

Let me walk you through the main challenges we typically encounter during ITSM integration and how we address them. Being aware of these upfront can help us navigate them more smoothly during implementation.

Field Mapping

The most common challenge we face is field mapping, particularly when working with heavily customized ITSM platforms. While our out-of-box integration templates work well with standard configurations, customized systems often require our custom integration approach.

At a minimum, we need to map certain basic fields: ticket number, title, status, and comment. Where clients need specific information placed in particular fields — for instance, caller information in a designated field — we need to configure additional API calls from both platforms. This moves us into custom integration territory, but it's something we handle regularly.

Data Standardization

Different systems often handle data formats differently, which can create unexpected challenges during integration. We need to establish clear data transformation rules, standardized formatting requirements, and consistent handling of special characters. This is particularly important when dealing with location information, customer data, and special field formatting. We'll work with your team to understand your data structure and ensure proper transformation between systems.

Authentication Methods

Security implementation often presents challenges, particularly around authentication methods. While we support Basic Auth, Bearer Tokens, OAuth (our recommended approach), and tokens in HTTP headers, we cannot support multi-factor authentication or per-call generated keys. We sometimes encounter situations where a client's security requirements don't align with available methods, requiring us to work together to find a secure alternative that meets both organizations' needs.

Security Validation

We frequently need to demonstrate why our Zapier-based integration approach is secure, particularly to clients with strict security requirements. While the integration might appear simple on the surface — utilizing what I often call a "big, long, gobbledygook URL" — there's sophisticated security behind it. Our security relies on unique URLs paired with authentication keys, providing a robust security model while maintaining ease of use. We're always happy to schedule technical discussions with security teams to explain our security measures in detail.

A Few Best Practices to Keep In Mind

imageonline-co-roundcorner (1)

After overseeing numerous ITSM integrations, I've found that thorough preparation and a clear understanding of security considerations are crucial to ensuring a smooth integration process. Let me share some key practices that will help set your integration up for success.

Preparation Essentials

The most successful integrations I've seen have one thing in common: thorough preparation before we even begin the technical work. Here are the best practices I give to teams ahead of time:

1. Review your API capabilities.

Verify your ITSM platform's API functionality.
Confirm your ability to make RESTful API calls.
Make sure you can configure webhooks for posting to our endpoints.
Identify any API limitations or restrictions in your environment.

2. Document your current workflows.

We'll need to understand how tickets flow through your system, including:

Current ticket statuses and their definitions.
Any automatic workflows that might change ticket status.
How you handle ticket assignments and escalations.
Current notification processes.

3. Assess your field requirements.

Identify the custom fields you'll need (especially the required INOC ticket number field).
Map out where our standard fields will align with your system.
Document any special field mapping requirements.
Consider any additional data points you'll need to capture.

Security Considerations

Security is a critical aspect of our ITSM integration, and it's an area where I often see clients have questions. To ensure the highest level of security:

Maintain secure storage of integration credentials.
Regularly review your access permissions.
Document your security requirements upfront.
Keep security contact information updated.
Follow your internal security protocols for API access and authentication.

One important note about security: don't let the simplicity of our integration approach make you question its security. We've successfully integrated with clients with extremely strict security requirements, and we're always happy to schedule technical discussions with your security team to explain our security measures in detail.

Timeline and Integration Phases

imageonline-co-roundcorner

The timeline for ITSM integration varies significantly based on your requirements and integration type. Let me break down the typical timelines and what you can expect during each phase.

Visibility-Only Integration Timeline

For clients primarily seeking visibility into our ticket handling, we can implement the integration as a separate phase after the main onboarding is complete.

This approach typically follows this timeline:

Initiate & Planning: 1-2 weeks

Kickoff meeting
Design sessions
Workflow document creation and approval

Execute & Test: 2-4 weeks

Development environment configuration
Initial testing
Refinements based on test results
Production environment setup

This phased approach allows your team to become comfortable with our basic NOC services first, using email notifications during the initial period before adding the complexity of system integration.

Active Management Integration Timeline

For clients where we'll be handling tier one support while your team manages tier two and three, the integration becomes a critical component of service delivery. This requires parallel implementation with the main onboarding process:

Initial Setup: 1-2 weeks

Technical requirement review
Security validation
Design sessions
Workflow documentation and approval

Development: 1-2 weeks

System configuration
API endpoint setup
Custom field creation
Initial testing in development environment

Testing & Validation: 2-3 weeks

Comprehensive testing of all scenarios
Refinement of workflows
Production environment setup
Final validation

Because this integration is critical for day-one operations, we typically start the process early in the overall onboarding timeline to ensure everything is ready for go-live.

A Few FAQs

What exactly is an INOC ITSM integration?
An INOC ITSM integration facilitates communication and data transfer between the INOC Platform and your system via a RESTful API interface. The data exchange is typically bidirectional, allowing you to receive and work on tickets opened by INOC within your own ITSM platform, and likewise enabling INOC to receive and update tickets raised by you within your platform.

Which ITSM platforms can you integrate with?
We can integrate with all major platforms. Our iPaaS has out-of-box integrations with popular platforms like ServiceNow, ConnectWise, and Jira, but we can work with any platform that supports RESTful API functionality.

How do you handle custom fields and data mapping?
For standard integrations, we work with a predetermined set of fields. If you need custom field mapping or specific data placement, we can accommodate this through our custom integration option, which allows for specific API calls to gather or place data as needed.

What if we want to integrate multiple ticket types (incidents, changes, etc.)?
While standard integration only supports incident tickets, our custom integration can handle multiple ticket types, including Changes, Customer Notifications, Dispatches, and Problems. Each type requires its own sub-project within the overall integration project.

Final Thoughts and Next Steps

A successful ITSM integration is about more than just connecting two systems — it's about creating a seamless operational framework that enhances both organizations' ability to deliver excellent service.

Throughout this guide, we've covered the essential elements that make this possible:

Understanding your integration needs and choosing the appropriate approach
Preparing your technical environment and security framework
Following our proven integration process
Anticipating and addressing common challenges
Planning for appropriate timelines based on your requirements

If you're considering ITSM integration with INOC, I recommend:

Reviewing your current ITSM platform's capabilities and customizations
Documentingyour security requirements and current workflows
Identifying which integration type (visibility-only or active management) best suits your needs
Preparing technical documentation about your current system
Scheduling an initial discussion with our team to review your requirements

Remember, our team is here to guide you through every step of this process. While ITSM integration may seem complex, our structured approach and experience with numerous platforms and scenarios ensures we can create a solution that meets your specific needs while maintaining security and efficiency.

Let's Talk NOC Schedule a free NOC consultation

Have questions? Want to see if our solutions are a fit? Let's talk! Request a free NOC consultation and we'll schedule some time to connect.

Get in touch

ITSM Integration with INOC: A Step-by-Step Guide to Onboarding Success