Enterprises rely on complex ecosystems of applications — from monitoring tools and incident management systems to CRMs and DevOps platforms. Keeping data consistent, accurate, and relevant across these systems is critical for operational efficiency and decision-making.

ZigiOps is designed to bridge these systems by enabling real-time, bi-directional integrations without coding. However, seamless data flow doesn’t just mean transferring everything — it means transferring the right data, at the right time, to the right place.

This is where Lookup actions play a crucial role.

Lookups allow ZigiOps to validate or filter data before taking action — such as creating or updating records in a target system. By checking conditions in advance (e.g., does a record already exist? is it still active?), Lookups help avoid duplication, prevent redundant updates, and enforce intelligent correlation logic tailored to business needs.

What Is a Lookup?

A lookup is a fundamental operation in data management where a system searches for a specific piece of data using a unique identifier. This identifier could be a primary key, a foreign key, or a custom field that ensures uniqueness.

Lookups are used in a wide range of applications, such as:

• Retrieving existing records from a database

• Validating whether an entity already exists

• Preventing duplication in record creation

• Ensuring updates are only applied to valid targets

In integration platforms like ZigiOps, lookups serve as a mechanism to inspect the target system before committing any changes—allowing smarter and more controlled data flows.

What Is the Lookup Action in ZigiOps?

The Lookup Action in ZigiOps is a specialized integration step that introduces pre-validation logic before data is sent to a target system. It enhances the traditional create/update workflows by adding a conditional checkpoint. This checkpoint ensures that the system doesn’t redundantly create or update data that already exists or doesn’t meet the defined criteria.

ZigiOps Workflow with Lookup Action

Here’s how the Lookup Action fits into the ZigiOps integration lifecycle:

1. Trigger Event
   The process starts with a trigger—this could be a change, an alert, or any event that matches the defined trigger conditions in the source system.

2. Data Collection
   An HTTP request is made to the source system to fetch relevant data based on trigger and child conditions.

3. Internal Transformation
   The data is internally mapped and transformed using integration field mappings (e.g., translating field names and formats between systems).

4. Lookup Action (Conditional Request)
   Before any data is sent to the target system, a lookup request is performed:

• It checks whether a corresponding record already exists.

• It applies custom filtering criteria (e.g., status = open).

• It determines if the next step should proceed or be skipped.

5. Conditional Execution Based on Lookup Results

• If the lookup finds a match, ZigiOps can decide to update the record or ignore it.

• If no match is found, the system may create a new record or take another defined action.

Why Lookup Actions Matter in Integrations?

In complex IT environments, systems like ServiceNow, Jira, SolarWinds, and OBM continuously generate large volumes of data. Without intelligent filtering and validation, integration platforms may:

• Create duplicate records

• Overwrite important data unintentionally

• Trigger unnecessary workflows in target systems

Lookup Actions solve this by

• Providing deduplication logic

• Enforcing business validation rules

• Making integration context-aware

• Preventing noise and redundancy

This is especially important in scenarios involving alerts, incident management, or asset tracking—where precision is essential.

‍

Use Case: Preventing Duplicate Incidents in ServiceNow with ZigiOps Lookup Action

Scenario: Ensuring a Single Incident per Configuration Item

In complex monitoring environments, especially those using tools like OBM (Operations Bridge Manager) or SolarWinds, it's common for multiple alerts to be triggered by the same underlying issue. For example, repeated alerts can be generated due to persistent disk space issues or CPU spikes on a single node.

Business Requirement

The customer requires that:

• Only one ServiceNow incident be generated for a given Configuration Item (CI), even if multiple related alerts are generated.

• Subsequent alerts for the same issue should be suppressed or correlated rather than triggering new incidents.

• This logic must be dynamic, handle high-frequency alerts, and integrate seamlessly with ServiceNow incident lifecycle rules.

Default Behavior Without Lookup Logic

Without any special handling, ZigiOps treats each alert as unique based on its system-specific ID, such as AlertHistoryID in SolarWinds. This means:

• Every incoming alert triggers a Create action.

• Each alert leads to a new incident in ServiceNow, regardless of context.

• Even minor variations (like different timestamps) cause separate incidents to be raised.

Example: Multiple Alerts for Same Node

Consider the following OBM/SolarWinds alerts:

• Node: vdsolarwinds01

• Alert ID: 107 (e.g., “High CPU Utilization”)

• Event Type: 0 (Open)

• Different AlertHistoryID values (due to different trigger times)

These should ideally map to one incident in ServiceNow. However, with default logic, ZigiOps creates multiple incidents, leading to:

• Incident duplication

• Increased workload for support teams

• Poor incident correlation and tracking

Solution: Using Lookup with a Custom Correlation Key

To meet the business requirement, ZigiOps can be configured to:

1. Construct a custom correlation key using relevant alert fields.

2. Use Lookup-Create logic to check ServiceNow for existing incidents before creating a new one.

Step-by-Step Logic:

1. Custom Correlation Key

• Constructed as:
  correlation_id = {nodename}:{alertid}:{eventtype}
  For example: solarwinds01:107:0

2. Lookup-Create Action

• ZigiOps issues a lookup request to ServiceNow:

SELECT * FROM incidents

WHERE correlation_id = 'solarwinds01:107:0'

 AND state NOT IN (6, 7) -- (6: Resolved, 7: Closed)

• If no such incident is found:

• ZigiOps creates a new incident with:

• Correlation ID: solarwinds01:107:0

• Alert details: timestamp, severity, etc.

• If a matching incident exists:

• ZigiOps skips creation, avoiding duplication.

Additional Logic for Updates

Once an incident exists, follow-up alerts should be evaluated for potential updates:

Lookup-Fetch-Update Action

• When an alert is received that might require updating an incident:

1. Perform a lookup using the same correlation key:

SELECT * FROM incidents

WHERE correlation_id = 'solarwinds01:107:0'

 AND state IN (1, 2) -- (1: New, 2: In Progress)

2. If an incident is found:

• ZigiOps updates it with the latest alert data.

• Possible updates: timestamps, alert message, impacted resources, etc.

3. If no incident is found:

• ZigiOps skips the update, ensuring data integrity.

Some Optional Enhancements that need to be considered:

1. Time-Based Filtering

You can enhance the logic to only correlate alerts within a certain time window (e.g., 1 hour) to prevent outdated alerts from updating fresh incidents.

2. Alert Severity Correlation

Correlate only alerts with the same or higher severity to avoid downgrading an incident due to a lower-priority follow-up alert.

3. Incident Comments

Even if no new incident is created, ZigiOps can be configured to add a comment to the existing incident, maintaining visibility without duplication.

Use Case: Smart Incident Updates

Scenario Overview

You want to ensure that only open or in-progress incidents in ServiceNow are updated with new alert information. Once an incident is resolved or closed, it should not be modified.

Solution: Lookup-Fetch-Update Action

1. A new alert arrives from SolarWinds.

2. ZigiOps performs a lookup on ServiceNow:

correlation_id = solarwinds01:107:0 AND state IN (1,2)

3. If a matching open or in-progress incident is found:

• ZigiOps updates the record with the latest alert data.

4. If no matching open record is found:

• ZigiOps skips the update, preserving historical integrity.

This ensures that only active records are touched, reducing risks of post-closure modifications.

Business Benefits of Lookup Actions

Using Lookup Actions in ZigiOps provides both technical and strategic advantages:

Operational Efficiency

• Reduces duplicate tickets and unnecessary processing.

• Minimizes clutter in target systems like ServiceNow or Jira.

Business Alignment

• Supports compliance with ITIL and internal SLA rules.

• Aligns integration logic with real-world business workflows.

Customization & Flexibility

• Fully supports custom correlation keys and conditions.

• Works with any API-enabled system—on-prem or cloud-based.

Error Prevention

• Avoids updates on closed or irrelevant records.

• Ensures that integration actions are always context-aware.

Final Thoughts

The Lookup Action is one of ZigiOps’ most powerful tools for building intelligent, high-quality integrations. It goes beyond simple data transfer by embedding real-time validation, conditional logic, and deduplication capabilities directly into the workflow.

Whether you're integrating monitoring tools like SolarWinds or OBM with ITSM systems like ServiceNow, the Lookup Action ensures that your data flow is not only seamless—but also relevant, efficient, and controlled.

If you’re interested in knowing more about ZigiOps and its full capabilities, do not hesitate to book a personalized demo with our team or directy start your free ZigiOps trial.

You might be interested in ZigiOps other functionalities:

1. Custom API integration: ZigiOps Webhook integrations

2. Field Mapping in integrations – explained

3. ZigiOps Web Poller

4. Custom API integration: ZigiOps Webhook integrations

5. Expressions in integrations: RegEx