# Welcome to ZigiOps Docs ZigiOps documentation — step-by-step guides, API references, and connector templates for no-code ITSM, DevOps, and Monitoring integrations across enterprise systems. Getting StartedIntegrationsDeploymentTroubleshooting *** ### Most Popular Integrations ***
Cover image

Jira ServiceNow Integration

Explore how to integrate Jira and ServiceNow5/files/NppkEHS7h61qZkGCdZ6L/pages/dbb77252abac08198d7318f896c5954ceffe0b99

Jira Remedy Integration

Connect Jira and BMC Remedy5/files/lA0MDpKkjhFyxOWYN0uE/pages/a00e5979bdf70fcfcfbb7990c6f6432baae878c8

Jira ADO Integration

Bridge Jira and Azure DevOps5/files/noXO7sGzmEQaic49rU1y/pages/d8e39657f0f67e5454ea19d45bccff8af89f2af8

OBM ServiceNow Integration

Route OBM alerts to ServiceNow incidents 5/files/D6rkhder7hvx3Nfm7s2y/pages/98704fbfbc0f1f031f9ca6dee5f756441df6162b

Jira Salesforce Integration

Align Salesforce and Jira in real-time5/files/oGHAlJhiEuB3FYBy5Xni/pages/43481841cbe86d1462109faaaee0faf0d098f52f

ServiceNow ADO Integration

Sync ServiceNow and Azure DevOps5/files/1lELe9Hl2QosB8f1SGF6/pages/be012617a7cb2fef6de169598b153185e3675a2f
*** {% columns %} {% column width="50%" %} ### Integration Platform {% content-ref url="/pages/hf7XxjASV4qA8o2A7d73" %} [What is ZigiOps](/integration-platform/what-is-zigiops) {% endcontent-ref %} {% content-ref url="/pages/9Nw7ll9wr8c8Mqp445mo" %} [ZigiOps Terminology](/integration-platform/zigiops-terminology) {% endcontent-ref %} {% content-ref url="/pages/be3c8cd315e36bc4b5f86d0f1d19a86372744f5a" %} [Available Systems](/available-systems) {% endcontent-ref %} {% content-ref url="/pages/b92547f92ab286442cd5a3bd3a6e903549eecc84" %} [System Requirements](/integration-platform/system-requirements) {% endcontent-ref %} {% content-ref url="/pages/ZEuoMkDglUuzIQRUZzvq" %} [Integration Catalog](/integration-catalog) {% endcontent-ref %} {% endcolumn %} {% column width="50%" %} ### [Troubleshooting](/operations-and-monitoring/troubleshooting) {% hint style="success" %} Operations & Monitoring Track integration health, review execution logs, diagnose sync issues, and optimize performance under high data volumes. {% endhint %} {% hint style="success" %} Troubleshooting Download HTTP data, review data-in and out. Diagnose action issues in the Troubleshooting menu. {% endhint %} {% hint style="success" %} Administration Manage users, reset passwords, configure licenses, and review audit logs across your ZigiOps environment. {% endhint %} {% endcolumn %} {% endcolumns %} *** {% columns %} {% column width="50%" %}
ZigiOps logo with navigation icons for Blog, Tutorials, Guides, and Integrations
{% endcolumn %} {% column width="50%" valign="middle" %} ## Learn more about our Integration Tool Read guides, watch tutorials, and learn more about working with the ZigiOps platform and integrating it with your own stack. Integrations Start Trial {% endcolumn %} {% endcolumns %} # Integration Platform Learn what ZigiOps is, explore platform terminology, review supported systems, and choose the right deployment option for your environment. Learn what ZigiOps is, explore platform terminology, review supported systems, and choose the right deployment option for your environment. {% content-ref url="/pages/hf7XxjASV4qA8o2A7d73" %} [What is ZigiOps](/integration-platform/what-is-zigiops) {% endcontent-ref %} {% content-ref url="/pages/b92547f92ab286442cd5a3bd3a6e903549eecc84" %} [System Requirements](/integration-platform/system-requirements) {% endcontent-ref %} {% content-ref url="/pages/04cf36df58ac0461eedc60da1967fb913eb6f507" %} [Broken mention](broken://pages/04cf36df58ac0461eedc60da1967fb913eb6f507) {% endcontent-ref %} {% content-ref url="/pages/be3c8cd315e36bc4b5f86d0f1d19a86372744f5a" %} [Available Systems](/available-systems) {% endcontent-ref %} {% content-ref url="/pages/9Nw7ll9wr8c8Mqp445mo" %} [ZigiOps Terminology](/integration-platform/zigiops-terminology) {% endcontent-ref %} # What is ZigiOps Official ZigiOps docs: What is ZigiOps. Configuration steps, requirements, and supported versions for your integration. It eliminates manual work, accelerates cross-team collaboration, and ensures precise, bi-directional data synchronization across complex enterprise environments — without scripting or API development. ZigiOps works natively with the APIs of 60+ enterprise systems and provides complete visibility, control, and reliability throughout the entire integration lifecycle.
ZigiOps dashboard
### Why Organizations Use ZigiOps Enterprises rely on ZigiOps to: * automate data synchronization across multiple teams and systems * reduce manual ticketing, escalations, and cross-platform updates * eliminate API complexity with a fully no-code interface * maintain strict security, governance, and compliance standards * scale integrations reliably under high data volume and high availability setups * standardize workflows across IT operations, CloudOps, DevOps, and Support teams ZigiOps transforms multi-system data flow from a slow, error-prone process into a streamlined, real-time part of the organization’s operational fabric. ### How ZigiOps Works ZigiOps acts as the central integration hub between your enterprise tools. It communicates with each system via their public APIs and performs the exact operations required by your integration use case — without requiring you to write or maintain code. Key principles of how it works: **1. API-Level Connectivity** ZigiOps connects to each system using secure, authenticated API calls and supports all available CRUD operations (Create, Read, Update, Delete) exposed by the system’s API. **2. Poller & Listener Engine** ZigiOps detects and processes data changes using two mechanisms: * Pollers → Periodically check source systems for updates * Listeners → Receive real-time events via webhooks or alerts This ensures timely and reliable synchronization based on your scenario. **3. Mapping and Transformation Layer** ZigiOps includes a powerful no-code mapping engine: * Field mappings * Conditional logic * Transformations & expressions * Lookups * Attachment & comment syncing * Custom field support All logic is handled inside the UI without any scripting. **4. Multi-System Orchestration** A single integration can involve multiple actions and workflows, each tailored to the objects, events, or entities you need to synchronize. **5. High Reliability Architecture** ZigiOps is built to operate in demanding production environments: * High Availability mode * Network storage for runtime files (Linux setups) * Scalable polling * Detailed logs & monitoring * Retry and conflict-handling mechanisms ### Key Capabilities **No-Code Integration Framework** * Create, modify, and deploy integrations directly from the UI with no scripting or API expertise required. **Bi-Directional Data Sync** * Automatically transfers updates between systems so that both sides stay constantly aligned. **Fully Customizable Workflows** * Start with a pre-built template or build your integration from scratch using: * conditions * transformations * lookups * advanced mappings **Real-Time Observability** * Track execution, errors, and integration health from the dashboard. **Extensible & Secure** * Supports 60+ enterprise systems * Encrypted communication * Authentication via API tokens, OAuth, Basic, Bearer * Works with ServiceNow MID Server, listener endpoints, and webhook-based flows * ISO-aligned security model ### Pre-Built Integration Templates ZigiOps includes a library of ready-to-use templates for the most common enterprise use cases (e.g., ServiceNow ↔ Jira, Azure DevOps ↔ ServiceNow, Jira ↔ Salesforce, OBM ↔ ServiceNow, and more). Each template can be: * loaded with one click * inspected * tailored with your own conditions, mappings, and transformations Templates help teams get started in minutes while still allowing full customization. ### What You Can Do With ZigiOps * Sync incidents, problems, alerts, change requests, and tasks * Transfer metrics, topology, and events between monitoring systems * Connect ITSM and DevOps tools for real-time collaboration * Automate end-to-end cross-team workflows * Expose your enterprise systems directly to ChatGPT using MCP * Standardize data exchange across IT, DevOps, Cloud, and Operations teams # System Requirements This page outlines the hardware, software, operating system, network, and browser requirements for deploying and running ZigiOps across all supported environments: Windows, Linux, and ZigiWave-hosted ## What Hardware Do I Need to Run ZigiOps? ZigiOps is lightweight and designed to operate efficiently in enterprise, hybrid cloud, and on-premise environments. Hardware requirements depend on deployment size, expected workload, and the number of workflows and integrated systems. ### Hardware Sizing Tiers | Deployment Size | CPU | RAM | Disk | | --------------- | ------------------------------------- | ------------ | ------------- | | **Small** | Dual-Core Processor (2.8 GHz or more) | 4 GB or more | 20 GB or more | | **Enterprise** | Quad-Core Processor (2.8 GHz or more) | 8 GB or more | 20 GB or more | For high-throughput or large-scale environments, refer to the [Scaling and Sizing ](/installation-and-deployment/scaling-and-sizing)documentation. ## Which Operating Systems Are Supported? ZigiOps can run on Windows and Linux server environments. Operating systems listed below are supported when used. Any OS not listed may work but has not been officially tested or certified. ### Supported Windows Versions * Windows Server 2008 R2 * Windows Server 2012 / 2012 R2 * Windows Server 2016 * Windows Server 2019 * Windows Server 2022 * Windows Server 2025 ### Supported Linux Distributions * Red Hat Enterprise Linux (RHEL) * CentOS * Ubuntu Server * Rocky Linux * AlmaLinux Both older and newer versions are supported when used. End-of-life distributions may continue to work but are not recommended for new deployments. ### What Software and Java Versions Are Required? ZigiOps requires a supported Java Runtime Environment (JRE) to be installed by the customer. ### Current ZigiOps Versions * **Java 17 is required** * The Java runtime is **not bundled** with ZigiOps * Customers must install a supported Java 17 distribution separately ### Older ZigiOps Versions Older releases (prior to version **2023.08.2.18**) may require Java 8 or Java 17, depending on the specific build. If you are upgrading from an older version, refer to the compatibility table below. | Requirement | Details | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Operating System** | Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022, 2025; Ubuntu 14.04 or newer; CentOS 7 or newer; RHEL 7 or newer | | **Install Privileges** | Administrator account (Windows); Super User account (Linux) | | **Runtime Privileges - Windows** | Run as a Service (admin account); Run as a Process is not supported | | **Runtime Privileges - Linux** | Run as a Process (non-root account); Run as a Service (root account) | | **Java for ZigiOps 2023.08.1.598 or older** | Oracle Java 8, Update 211+ (64-bit); Open Java 8, Update 211+ (64-bit) | | **Java for ZigiOps 2023.08.2.18 or newer** | Oracle Java 17 (64-bit); Open Java 17 (64-bit); Azul Java 17 (64-bit) | | **Web Browser** | Google Chrome; Microsoft Edge (Chromium) | | **Screen Resolution** | 1280 x 720 or higher | ### What Are the Requirements for ZigiOps Cloud Deployment? ZigiOps Cloud has **no system requirements on the customer side**. ZigiWave manages: * Installation * Hosting * Updates * Maintenance * High availability Cloud customers simply receive secure access credentials, log in through a supported browser, and start integrating systems immediately. ## What Network Prerequisites Should I Prepare? ZigiOps communicates with integrated systems using secure outbound connections. ### Network Requirements * Outbound access to the APIs or endpoints of integrated systems * HTTPS access to the ZigiOps UI * TLS-secured communication * Proxy support (standard HTTP/HTTPS proxies) Listener ports are configurable during installation and are not fixed by default. ## What User Privileges Are Required to Run ZigiOps? ZigiOps requires specific privileges during installation and runtime to ensure stability and security. ### Installation Privileges * Administrator or root privileges are required during installation ### Runtime Privileges * **Windows:** ZigiOps must run as a Windows service * **Linux:** ZigiOps can run as a non-root service, but installation requires elevated permissions No additional privileges are required beyond standard enterprise best practices. ## Which Browsers Are Supported for Accessing the ZigiOps UI? ZigiOps supports modern Chromium-based browsers. ### Supported Browsers * Google Chrome * Microsoft Edge (Chromium) ### Display Requirements * Minimum resolution: **1280 x 720** ## Summary of ZigiOps System Requirements | Area | Requirement | | ---------------------- | ----------------------------------------------------------------------------------- | | **Supported OS** | Windows, Linux, Cloud | | **Java Version** | Java 17 (current); Java 8 or 17 (older versions) | | **Java Runtime** | Must be installed separately | | **Hardware** | Small: Dual-Core, 4 GB RAM, 20 GB disk; Enterprise: Quad-Core, 8 GB RAM, 20 GB disk | | **Cloud Deployment** | No customer-side infrastructure required | | **Supported Browsers** | Google Chrome, Microsoft Edge (Chromium) | | **Network** | Outbound-focused, TLS-secured, proxy-compatible | # Deployment Options Description: Explore ZigiOps deployment models: on-premise (Linux/Windows), ZigiWave-hosted cloud, and Docker. Choose the right option for your enterprise. This page provides a concise overview of the available deployment models and helps you choose the best option for your organization. ZigiOps offers flexible deployment options designed to meet the security, compliance, and operational needs of enterprise environments. ### Deployment Models Overview ZigiOps supports the following deployment models: * On-Premise Deployment (Linux or Windows) * ZigiWave-Hosted Cloud Deployment * Docker Deployment (Self-Hosted Container) All deployment options use the same ZigiOps integration engine and provide a consistent security and functional baseline, including: * FIPS 140-2-compliant encryption for sensitive data * TLS-secured UI and listener endpoints (TLS 1.2 / TLS 1.3) * Support for enterprise-grade security and access controls * Full compatibility with all ZigiOps integration templates ### On-Premise Deployment (Linux and Windows) On-premise deployment gives organizations full control over infrastructure, network access, and operational processes. #### Supported Operating Systems * **Linux:** Installed under `/opt/zigiwave/zigiops`, managed via systemd service * **Windows:** Installed under `C:\ZigiWave\ZigiOps`, running as a Windows service #### When to Choose On-Premise * Highly restricted or closed network environments * Strict data residency or regulatory requirements * Environments requiring full control over networking and security * Use cases requiring on-premise listener endpoints * Organizations that need to manage SSL certificates and encryption locally #### Availability and Operations * Supports high-availability configurations using a primary/backup model * HA can be implemented on both Linux and Windows * Customers manage installation, upgrades, and infrastructure * ZigiWave Support can assist with installation and upgrades when needed For detailed installation instructions, see [Installation on Linux](broken://pages/fb76b8de19351fdba5009f2ff50723cd4365a9df) or [Installation on Windows](broken://pages/84a43520a9c37f3cf6e6f39e3ff6d8cd6f82ca04). ### ZigiWave-Hosted Cloud Deployment The ZigiWave-hosted cloud option delivers the fastest time-to-value with minimal operational overhead. #### Key Characteristics * Each customer receives a dedicated, isolated ZigiOps instance * Single-tenant deployment (multi-tenancy is not currently supported) * Hosted on Amazon Web Services (AWS) #### Access Model * Secure, dedicated regional URL * EU: `https://.zigiwave.eu` * US: `https://.zigiwave.us` * Access credentials are provided by ZigiWave * No installation or infrastructure management required #### Security and Availability * Each instance is secured with its own SSL certificate * High availability is enabled by default * Monitored with a target uptime of 99% * Dynamic IP addresses by default * A static IP can be assigned on request for customer-side whitelisting #### Listener Support in Cloud Listener (webhook) endpoints are not enabled by default but can be enabled upon customer request, depending on the use case and security requirements. #### Updates and Maintenance * Fully managed by ZigiWave * Bug fixes, updates, and new features are delivered by ZigiWave * Updates are applied only after customer approval ### Docker Deployment (Self-Hosted Container) The Docker deployment option packages all ZigiOps services into a single container image. This model is suited for organizations that use containerized infrastructure and want a portable, self-managed ZigiOps installation. #### Key Characteristics * All ZigiOps services (platform, frontend, persistence, troubleshooting) are bundled in a single image * Services start sequentially inside the container; startup takes approximately 1-2 minutes * Named Docker volumes ensure data persists across restarts and upgrades * The ZigiOps UI is accessible at `http://:8080` #### When to Choose Docker * Organizations using containerized infrastructure * Teams that prefer portable, image-based deployments * Environments where a self-managed container model is preferred over a traditional OS service #### Availability and Operations * Customers manage the Docker host, container lifecycle, and upgrades * High availability is configurable via container orchestration tools * ZigiWave provides the image archive and a license file For detailed setup instructions, see the [Docker Deployment Guide](broken://pages/025c650ee5de102ff12becb7625cdba22e0ac5b4). ### Security Overview (All Deployments) Across all deployment options, ZigiOps applies consistent security controls: * Sensitive data visible in the UI or filesystem is encrypted using a FIPS 140-2-compliant AES/CBC algorithm with a 256-bit key Encrypted data includes: * Authentication credentials (passwords, tokens, API keys) * Security-related HTTP headers (Authorization, Set-Cookie, and others) * Configuration and log files * All UI and listener endpoints are secured with TLS * Customers can use their own SSL certificates for on-premise and Docker deployments ### Licensing Overview ZigiOps uses the same licensing model for all deployment types. | Deployment | Licensing | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | On-Premise | ZigiWave provides a license file. Customers apply it to their local ZigiOps instance. High Availability requires additional license files for backup/failover instances. | | Cloud | ZigiWave issues and applies licenses transparently as part of the cloud service. | | Docker | ZigiWave provides a license file. Customers apply it to the ZigiOps instance running in Docker. | ### Choosing the Right Deployment Option | Factor | On-Premise (Linux or Windows) | ZigiWave-Hosted Cloud | Docker (Self-Hosted) | | ---------------------- | ------------------------------------------- | ------------------------------ | ------------------------------------ | | Infrastructure control | Full control | Managed by ZigiWave | Full control | | Network restrictions | Suitable for highly restricted environments | Requires outbound connectivity | Suitable for restricted environments | | Time to value | Requires installation | Immediate access | Requires Docker setup | | High availability | Configurable | Enabled by default | Configurable via orchestration | | Maintenance | Customer-managed | Fully managed by ZigiWave | Customer-managed | | SSL certificates | Customer-managed | Included per instance | Customer-managed | | Container support | Not applicable | Not applicable | Native Docker support | ### Related Documentation * [Installation on Linux](/installation-and-deployment/installation-linux) * [Installation on Windows](/installation-and-deployment/installation-windows) * [Docker Deployment Guide](/installation-and-deployment/docker-deployment-guide) * [System Requirements](/integration-platform/system-requirements) # ZigiOps Terminology A complete glossary of core concepts, UI elements, architecture terms, mapping logic, and transformation mechanisms used throughout the ZigiOps Integration Platform. **A. Core Integration Concepts** #### Workflow The main entity users work with in ZigiOps.\ The workflow represents a goal (or use case) that needs to be achieved by the customer.\ It contains all the configuration and logic for systems, correlation, actions, filters, mappings, conditions that are required for achieving a use case. \ A workflow is defined by a pair of systems and the type of data which will be used, for example:\ • jira\_production task ↔︎ servicenow\_production incident\ • solarwinds\_test alert → operations\_bridge\_test event #### Workflow Template A predefined workflow blueprint that includes mappings, triggers, and actions for a specific system pair. ### System The system describes what ZigiOps can connect to, for example “System: Jira” means that ZigiOps has the capability to connect and integrate with Jira systems. #### System Instance This represents the actual connection between ZigiOps and a system. It contains the configuration that describes the connection, like name, url, authentication, proxy, etc. \ Examples:\ • System Instance: new-jira-1 with url [https://jira1.atlassian.com](https://jira1.atlassian.com/)\ • System Instance: new-jira-2 with url [https://jira2.atlassian.com](https://jira2.atlassian.com/) #### System Entity This is the type of data which will be used for a particular System Instance as part of a workflow. \ Examples:\ • new-jira-1 with entity: TEST.task\ • new-snow-1 with entity: incident #### System Pair The two connected systems involved in an integration (e.g., ServiceNow ↔ Jira). ### Correlation Correlation is a feature of every workflow and defines where ZigiOps will store unique key information which can be used for synchronizing updates between records in both directions. Correlation information can be stored in the Source system, Target system or in both at the same time.
ZigiOps uses that information during update actions to validate what is the correct entity that needs to be updated. \ Common Examples:\ • ServiceNow uses the default “correlation\_id”\ • Jira uses a dedicated custom field\ • Remedy uses “Vendor Ticket Number” ### Integration The automated connection between two systems that enables data exchange based on a defined workflow. #### Custom Integration A manually created integration, configured from scratch using the ZigiOps UI. ![Shape](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAANSURBVBhXY2BgYGAAAAAFAAGKM+MAAAAAAElFTkSuQmCC) ### B. Data Mapping Concepts #### Transformation A function applied to data during mapping (e.g., format change, prefix, concatenation). #### Lookup A mechanism for retrieving a related value from the target system based on a source field. #### Correlation Field A field used to maintain a unique link between related records across systems. #### Static Value Mapping A constant assigned to a field during sync (e.g., “priority = 3”). #### Dynamic Value Mapping Field values determined at runtime based on source fields. #### Attachment Sync The process of transferring file attachments between systems. #### Comment / Journal Sync Synchronizing comments, work notes, or journal entries. ### Field Mapping Field mappings are used to specify what data is going to be delivered to the target system of the action. Values may be source fields, hardcoded strings, or combinations. \ Examples:\ summary = {short\_description}\ summary = {number}: {short\_description}\ comments/body = {comments/body} #### Field Mapping Conditions Conditional mappings define when a certain field should be reported or how values change based on specific criteria.\ Examples include lifecycle conversions or conditional reporting. **Respond Field Mapping** Mapping from the target system back to the source system.\ Commonly used to create comments that contain confirmation or drilldown links. ### C. Execution Mechanisms #### Poller The mechanism that periodically checks a source system for changes. #### Web Listener A listener that receives event-based data from monitoring or DevOps tools. #### Bulk Transfer The ability to transfer large batches of records in a single request. #### Retry Logic A built-in mechanism for automatically reattempting failed actions. #### Action The component within a workflow that directly works with data.\ A workflow may contain multiple actions such as Create, Update, or Sync operations. #### Source Where data is collected from. Includes filters, triggers, related filters, expressions, lasttime, and more. #### Target The destination system where the action delivers data.\ Each action defines its own target configuration, including mappings and conditions. #### Trigger Defines when an action is executed:\ • poller – runs on a timed interval\ • web listener – fires immediately on incoming data #### Filter Specifies which records should be collected. Related Filter Used to collect related records such as attachments or comments. ### D. API & Authentication #### API Token A secret token used to authenticate ZigiOps against the system API. #### Personal Access Token (PAT) Authentication mechanism used by tools like Azure DevOps and Jira Cloud. #### Client ID / Client Secret OAuth-based credentials used for authentication. #### Bearer Token Authentication token added to HTTP headers. #### Basic Authentication Username + password (or token) authentication. #### REST API The standard interface ZigiOps uses to communicate with integrated systems. #### Webhook A mechanism that allows an external system to send data to ZigiOps in real time. #### MCP (Model Context Protocol) MCP protocol that allows ZigiOps to expose systems directly to ChatGPT or AI models. ### E. System Configuration Terms #### Proxy Settings Configuration allowing ZigiOps to route traffic through a proxy server. #### MID Server A ServiceNow component that facilitates secure communication with external systems. #### Listener URL The endpoint where ZigiOps receives incoming data from systems such as Dynatrace, Azure Monitor, or SAP SolMan. #### Instance Type Defines whether a system is Cloud, Server, SaaS, etc. #### Server URL Base URL of the connected system used for API communication. #### Management Pack / Connector Additional components required by certain systems (e.g., vROps). #### License The license allows the user to enable the automation for workflows and actions. It is bound by a pair of systems and number of points. ### F. Error Handling & Troubleshooting Terms #### Error Log A log of failures, exceptions, or rejected records generated by ZigiOps. #### Permission Error An error caused by insufficient access rights. #### Authentication Failure A failure due to incorrect credentials or expired tokens. #### Transformation Error An issue caused by a mapping or expression. #### Payload The JSON body sent to or from a connected system during integration. ### G. Platform Architecture Terms #### Integration Hub The core engine running ZigiOps integrations. #### Runtime Files Files generated during operations (logs, temporary data, etc.). #### Scaling & Load How ZigiOps handles volume, concurrency, and heavy workloads. HA (High Availability) Multi-node setup for reliability. Network Storage External storage for runtime files in HA deployments. ### H. ZigiOps UI Terms #### Configurator The main UI section for building and modifying integrations. #### Dashboard The overview screen showing system health and integration status. #### Activity Log A record of executed actions, polling cycles, and listener events. #### System Instances The list of configured connected systems. #### Accessible by AI The toggle enabling MCP exposure for a specific system instance. #### Mapping Table UI interface for field-to-field mappings. #### Condition Builder UI tool for constructing logical conditions and filters. ![](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAANSURBVBhXY2BgYGAAAAAFAAGKM+MAAAAAAElFTkSuQmCC) #### I. Security & Compliance Terms * Encryption at Rest * Encryption of stored data. * Encryption in Transit * HTTPS/TLS encryption during communication. * ISO 27001 * Security certification. * Hardening * Security configurations that restrict access and strengthen defenses. ### J. Expressions & Transformations #### Expressions Expressions are used for additional data transformations after data collection and before delivery to the target system. They may be reused inside field mappings. **Expression: Pattern** Allows regex-based data extraction or modification. * Expression: Extract from Array * Extracts a specific object from an array. **Expression: Build Array** * Combines multiple values into an array using a separator. **Expression: To Lower Case** * Converts text to lowercase. **Expression: To Upper Case** * Converts text to uppercase. **Expression: First N Characters** * Trims text to the first N characters. **Expression: Last N Characters** * Trims text to the last N characters. **Expression: Replace Text** * Replaces specified text with another text. **Expression: Replace Pattern** * Uses regex to replace matched patterns. **Expression: Date and Time Format** * Converts timestamps to human-readable formats. **Expression: Last Time** * Records the latest timestamp of collected data to avoid duplicates. # Available Systems ZigiOps integrates with 60+ enterprise systems across ITSM, DevOps, Observability, Cloud, CRM, and Automation. Each system includes a connection guide, supported versions, prerequisites, and integrati *** ## A-Z Navigation Jump directly to any system: **A** - [Amazon CloudWatch](/available-systems/amazon-cloudwatch), [AppDynamics](/available-systems/appdynamics), [Azure DevOps](/available-systems/azure-devops), [Azure Monitor](/available-systems/azure-monitor)\ **B** - [Bitbucket](/available-systems/bitbucket), [BMC TrueSight OM](/available-systems/truesight-om)\ **C** - [ConnectWise](/available-systems/connectwise), [Cherwell](/available-systems/cherwell), [CircleCI](/available-systems/circleci)\ **D** - [Datadog](/available-systems/datadog), [Dynatrace](/available-systems/dynatrace)\ **F** - [File Connector](/available-systems/file-connector), [Foglight](/available-systems/foglight), [Freshdesk](/available-systems/freshdesk), [Freshservice](/available-systems/freshservice)\ **G** - [GitHub](/available-systems/github)\ **I** - [Icinga](/available-systems/icinga), [IFS Assyst](/available-systems/ifs-assyst), [Incoming Emails](/available-systems/incoming-emails), [Ivanti](/available-systems/ivanti)\ **J** - [Jenkins](/available-systems/jenkins), [Jira](/available-systems/jira)\ **K** - [Kubernetes](/available-systems/kubernetes)\ **M** - [Microsoft Dynamics 365](/available-systems/microsoft-dynamics-365), [Microsoft SCOM](/available-systems/microsoft-scom)\ **N** - [Nagios XI](/available-systems/nagios-xi), [New Relic](/available-systems/new-relic), [Nutanix](/available-systems/nutanix)\ **O** - [OBM / OpsBridge](/available-systems/operations-bridge-manager-obm), [OpenAI](/available-systems/openai), [Optic Data Lake](/available-systems/optic-data-lake-odl), [Oracle Enterprise Manager](/available-systems/oracle-enterprise-manager-oem)\ **P** - [PagerDuty](/available-systems/pagerduty), [Prometheus](/available-systems/prometheus)\ **R** - [Remedy](/available-systems/remedy), [Remedyforce](/available-systems/remedyforce)\ **S** - [Salesforce](/available-systems/salesforce), [SAP Solution Manager](/available-systems/sap-solution-manager), [ServiceNow](/available-systems/servicenow), [ServiceNow MID Server](/available-systems/servicenow-mid-server), [Signl4](/available-systems/signl4), [SolarWinds](/available-systems/solarwinds), [Splunk Enterprise](/available-systems/splunk-enterprise), [Splunk Observability](/available-systems/splunk-observability-cloud-signalfx)\ **T** - [TOPdesk](/available-systems/topdesk), [TrueSight OM](/available-systems/truesight-om)\ **U** - [uCMDB](/available-systems/ucmdb)\ **V** - [vROps](/available-systems/vrops)\ **W** - [Web Listener](/available-systems/web-listener), [Web Poller](/available-systems/web-poller), [Webhook](/available-systems/webhook)\ **X** - [xMatters](/available-systems/xmatters)\ **Z** - [Zabbix](/available-systems/zabbix), [Zendesk](/available-systems/zendesk), [Zendesk Sell](/available-systems/zendesk-sell), [Zoho ME OpManager](/available-systems/zoho-me-opmanager), [Zoho ME ServiceDesk Plus](/available-systems/zoho-me-servicedesk-plus) *** ## System Categories ### ITSM Platforms [ServiceNow](/available-systems/servicenow), [Remedy](/available-systems/remedy), [Remedyforce](/available-systems/remedyforce), [Cherwell](/available-systems/cherwell), [TOPdesk](/available-systems/topdesk), [Ivanti](/available-systems/ivanti), [Salesforce](/available-systems/salesforce), [Zendesk](/available-systems/zendesk), [Zendesk Sell](/available-systems/zendesk-sell), [IFS Assyst](/available-systems/ifs-assyst), [ConnectWise](/available-systems/connectwise) ### DevOps and Agile [Jira](/available-systems/jira), [Azure DevOps](/available-systems/azure-devops), [Bitbucket](/available-systems/bitbucket), [GitHub](/available-systems/github), [CircleCI](/available-systems/circleci), [Jenkins](/available-systems/jenkins), [xMatters](/available-systems/xmatters) ### Monitoring and Observability [OBM/OpsBridge](/available-systems/operations-bridge-manager-obm), [Dynatrace](/available-systems/dynatrace), [Datadog](/available-systems/datadog), [Splunk Enterprise](/available-systems/splunk-enterprise), [Splunk Observability](/available-systems/splunk-observability-cloud-signalfx), [SolarWinds](/available-systems/solarwinds), [New Relic](/available-systems/new-relic), [Zabbix](/available-systems/zabbix), [Icinga](/available-systems/icinga), [Nagios XI](/available-systems/nagios-xi), [Prometheus](/available-systems/prometheus), [Foglight](/available-systems/foglight), [vROps](/available-systems/vrops) ### Cloud and Infrastructure [Amazon CloudWatch](/available-systems/amazon-cloudwatch), [Azure Monitor](/available-systems/azure-monitor), [Kubernetes](/available-systems/kubernetes), [Nutanix](/available-systems/nutanix), [Oracle Enterprise Manager](/available-systems/oracle-enterprise-manager-oem), [Optic Data Lake](/available-systems/optic-data-lake-odl) ### AI and Automation [OpenAI](/available-systems/openai), [Webhook](/available-systems/webhook), [Web Listener](/available-systems/web-listener), [Web Poller](/available-systems/web-poller), [File Connector](/available-systems/file-connector), [Incoming Emails](/available-systems/incoming-emails) *** ## What Is Included on Each System Page? Each system page contains: * Supported versions * Environmental prerequisites * Authentication parameters * Step-by-step connection instructions * Related integration templates * System-specific notes (webhooks, topology, API tokens, limits) *** ## Supported Systems Overview Table The table below provides a unified comparison of all systems supported by ZigiOps, including authentication methods, supported entities, and typical integration scenarios. Click any system name to open its dedicated page. | System | Category | Authentication | Key Entities Supported | Typical Use Cases | | ---------------------------------------------------------------------------------- | ---------------- | ------------------------------------- | ------------------------------------ | ------------------------------------------------------------ | | [**Amazon CloudWatch**](/available-systems/amazon-cloudwatch) | Cloud Monitoring | Access Key + Secret | Alerts, Metrics | Push AWS alerts to ITSM or OBM | | [**AppDynamics**](/available-systems/appdynamics) | Monitoring | Username + Account, API Token | Events, Metrics, Topology | APM to ITSM/OBM sync | | [**Azure DevOps**](/available-systems/azure-devops) | DevOps | PAT | Work Items, Tasks | DevOps and ITSM flows | | [**Azure Monitor**](/available-systems/azure-monitor) | Cloud Monitoring | Client ID/Secret, Tenant | Alerts, Metrics | Azure to OBM/SNOW | | [**Bitbucket**](/available-systems/bitbucket) | DevOps | API Key | Commits, Issues | Repo events to ITSM | | [**Cherwell**](/available-systems/bitbucket) | ITSM | API Token + Username | Incidents, Changes | Cherwell and DevOps | | [**CircleCI**](/available-systems/circleci) | DevOps CI/CD | API Key | Builds, Jobs | CI alerts to Jira/SNOW | | [**ConnectWise**](/available-systems/connectwise) | ITSM | Company ID + Public Key + Private Key | Service Tickets, Notes, Attachments | ConnectWise PSA and Jira/SNOW | | [**Datadog**](/available-systems/datadog) | Monitoring | API + App Key | Events, Metrics, Hosts | Datadog to OBM/ITSM | | [**Dynatrace**](/available-systems/dynatrace) | Monitoring | API Token | Problems, Topology, Metrics | Dynatrace to Jira/SNOW/OBM | | [**File Connector**](/available-systems/file-connector) | Automation | N/A | Exported File Data | File-based workflows | | [**Foglight**](/available-systems/foglight) | Monitoring | API Token | Alarms | Foglight to OBM | | [**Freshdesk**](/available-systems/freshdesk) | ITSM | API Key | Tickets | Freshdesk and Jira/SNOW | | [**Freshservice**](/available-systems/freshservice) | ITSM | Email + API Token | Tickets | Freshservice and DevOps | | [**GitHub**](/available-systems/github) | DevOps | PAT | Issues, PRs | GitHub to SNOW/Jira | | [**Icinga**](/available-systems/icinga) | Monitoring | Username/Password | Events, Status | Icinga to OBM/ITSM | | [**IFS Assyst**](/available-systems/ifs-assyst) | ITSM | Username/Password | Tickets | IFS and ITSM/DevOps | | [**Incoming Emails**](/available-systems/incoming-emails) | Automation | IMAP/POP3 | Emails | Email to Ticket/Lead | | [**Ivanti**](/available-systems/ivanti) | ITSM | API Key | Incidents | Ivanti and OBM/Jira | | [**Jenkins**](/available-systems/jenkins) | DevOps CI/CD | Username/Password | Jobs, Builds | Jenkins to Jira/SNOW | | [**Jira**](/available-systems/jira) | DevOps/ITSM | Username/Token | Tasks, Issues, Comments | Jira and ServiceNow/Azure DevOps | | [**Kubernetes**](/available-systems/kubernetes) | Cloud | Basic/OAuth/Token | Clusters, Nodes | K8s to Monitoring | | [**Microsoft Dynamics 365**](/available-systems/microsoft-dynamics-365) | CRM | OAuth (Client ID/Secret) | Incidents, Cases | Dynamics and Jira/SNOW | | [**Microsoft Intune**](/available-systems/microsoft-intune) | Cloud/MDM | OAuth (Client ID/Secret, Tenant ID) | Devices, Compliance Policies | Intune device compliance to ITSM/DevOps | | [**Microsoft SCOM**](/available-systems/microsoft-scom) | Monitoring | Username/Password | Alerts | SCOM to OBM/ITSM | | [**Nagios XI**](/available-systems/nagios-xi) | Monitoring | API Key | Alerts | Nagios to OBM/SNOW | | [**New Relic**](/available-systems/new-relic) | Monitoring | API Key | Metrics, Violations | New Relic to OBM/vROps | | [**Nutanix**](/available-systems/nutanix) | Monitoring | Username/Password | Alerts, Topology | Nutanix to OBM/ITSM | | [**OBM / OpsBridge Manager**](/available-systems/operations-bridge-manager-obm) | Monitoring | Multi-credential | Events, Topology, Metrics | OBM and SNOW/Jira | | [**OpenAI**](/available-systems/openai) | AI | API Key | Chat/LLM API | AI workflows, MCP | | [**Operations Agent (OA)**](/available-systems/operations-agent-oa) | Monitoring | No Auth / Basic / Token | Events, Topology | OA to OBM events and topology sync | | [**Optic Data Lake**](/available-systems/optic-data-lake-odl) | Monitoring | Username/Password | Datasets (AppD, Dynatrace, etc.) | Data Lake ingestion | | [**Oracle EM**](/available-systems/oracle-enterprise-manager-oem) | Monitoring | DB Credentials | Alerts, Metrics | OEM to ITSM | | [**PagerDuty**](/available-systems/pagerduty) | DevOps/On-Call | API Token | Incidents, Alerts | PagerDuty and Jira/SNOW | | [**Prometheus**](/available-systems/prometheus) | Monitoring | No Auth | Alerts, Metrics | Prometheus to OBM | | [**Remedy**](/available-systems/remedy) | ITSM | Username/Password | Incidents, Changes | Remedy and Jira/OBM | | [**Remedyforce**](/available-systems/remedyforce) | ITSM | OAuth | Incidents | Remedyforce and Jira/SNOW | | [**Salesforce**](/available-systems/salesforce) | CRM | OAuth | Cases, Objects | Salesforce and DevOps | | [**SAP Solution Manager**](/available-systems/sap-solution-manager) | ITSM/Monitoring | Username/Password | Alerts, Topology | SolMan to OBM | | [**ServiceNow**](/available-systems/servicenow) | ITSM | Username/Password | Incidents, Changes, CMDB | SNOW and Jira/Azure DevOps | | [**ServiceNow MID Server**](/available-systems/servicenow-mid-server) | ITSM Infra | Username/Password | Staging App, MID flows | SNOW Mid Server mode | | [**Signl4**](/available-systems/signl4) | On-Call | Webhook Secret | Alerts | Signl4 to ITSM | | [**SMTP**](/available-systems/smtp) | Automation | Username/Password | Emails | Email notifications on ZigiOps Self-Health events; alerts | | [**SolarWinds**](/available-systems/solarwinds) | Monitoring | Username/Password | Alerts, Metrics, Topology | SolarWinds to OBM/ITSM | | [**Splunk Enterprise**](/available-systems/splunk-enterprise) | Monitoring | API Token | Events, Alerts | Splunk HEC to ITSM/OBM | | [**Splunk Observability**](/available-systems/splunk-observability-cloud-signalfx) | Monitoring | Token | Metrics, Events | SignalFx to OBM | | [**TOPdesk**](/available-systems/topdesk) | ITSM | Username/Password | Tickets | TOPdesk and Jira/SNOW | | [**TrueSight OM**](/available-systems/truesight-om) | Monitoring | Username/Password | Topology, Alerts | BMC OM to ITSM | | [**uCMDB**](/available-systems/ucmdb) | CMDB | Username/Password | CMDB Entities | CMDB and SNOW | | [**vROps**](/available-systems/vrops) | Monitoring | Username/Password | Metrics, Alerts | vROps and ITSM/OBM | | [**Web Listener**](/available-systems/web-listener) | Automation | N/A | JSON Payloads | Webhook ingestion | | [**Web Poller**](/available-systems/web-poller) | Automation | Basic Auth | Polled JSON | Polling-based integration | | [**Webhook**](/available-systems/webhook) | Automation | Basic Auth | JSON Payloads | Custom webhook flows | | [**xMatters**](/available-systems/xmatters) | On-Call | API Key / OAuth | Alerts | xMatters to ITSM | | [**Zabbix**](/available-systems/zabbix) | Monitoring | Username/Password | Alerts, Topology | Zabbix to SNOW/OBM | | [**Zendesk**](/available-systems/zendesk) | ITSM/Support | Basic/OAuth/Bearer | Tickets | Zendesk and Jira/SNOW | | [**Zendesk Sell**](/available-systems/zendesk-sell) | CRM | Token | Leads | Sell and Email/CRM | | [**Zoho ME OpManager**](/available-systems/zoho-me-opmanager) | Monitoring | API Key | Alerts, Topology | OpManager to ITSM | | [**Zoho ME ServiceDesk Plus**](/available-systems/zoho-me-servicedesk-plus) | ITSM | OAuth (Client ID + Client Secret) | Tickets, Incidents, Service Requests | ServiceDesk Plus and Jira/SNOW; monitoring alerts to tickets | *** # Amazon CloudWatch Learn how to connect Amazon CloudWatch to ZigiOps. Supported versions, IAM access keys, prerequisites, and connected system configuration. ### What is Amazon CloudWatch integration in ZigiOps? Amazon CloudWatch is a cloud-based monitoring and observability service that provides metrics, logs, and events for AWS resources and applications. ZigiOps enables secure, agentless integration between Amazon CloudWatch and ITSM, DevOps, and enterprise systems. Using ZigiOps, CloudWatch metrics, alarms, and events can be forwarded to downstream systems where they can trigger incidents, tasks, or automated workflows. With ZigiOps, Amazon CloudWatch can: * Send monitoring events and alerts to ITSM systems * Trigger incident and task creation in external platforms * Participate in end-to-end monitoring-to-resolution workflows * Operate without installing agents or custom scripts ### Which Amazon CloudWatch versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ----------------- | -------------------------- | ------------------ | | Amazon CloudWatch | Cloud | All | ### Are there any environmental prerequisites for Amazon CloudWatch? {% hint style="info" %} Before configuring Amazon CloudWatch, always confirm the prerequisites of the corresponding integration template, as **some templates may not require all environmental prerequisites described below**. See the **Related Templates** section at the end of this page. {% endhint %} ### How do I generate an Amazon CloudWatch Access Key? An **AWS Access Key and Secret Key** are required to authenticate Amazon CloudWatch with ZigiOps. **Steps:** 1. Log in to your AWS account. 2. Navigate to **Identity and Access Management (IAM)**. 3. Go to **Users > Security Credentials**. 4. Click **Create Access Key** to generate a new key. 5. Save the **Access Key** and **Secret Key** securely. {% hint style="warning" %} Make sure the IAM user has sufficient permissions to access the required CloudWatch resources. {% endhint %} ### How do I connect Amazon CloudWatch to ZigiOps? #### Amazon CloudWatch - Connected System Configuration Follow the steps below to add Amazon CloudWatch as a connected system in ZigiOps. {% stepper %} {% step %} **Log in to ZigiOps** Log in to your **ZigiOps** instance. {% endstep %} {% step %} **Open the Amazon CloudWatch connected system setup** Navigate to **Connected Systems > Add New System > Amazon CloudWatch**. {% endstep %} {% step %} **Configure the parameters** Configure the following parameters: **Access Key**\ Enter the first part of your AWS access key. **Secret Key**\ Enter the second part of your AWS access key. **AWS Region**\ Enter the AWS region where your CloudWatch instance is located. The region can be identified from the AWS console or instance URL. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} **Review the configuration** Review the configuration. {% endstep %} {% step %} **Save the connected system** Click **Save** to store the connected system. Once saved, Amazon CloudWatch becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Amazon CloudWatch integration use cases? #### Use case 1: Sending CloudWatch alerts to ITSM systems When Amazon CloudWatch detects threshold breaches or alarm conditions, ZigiOps can forward these events to ITSM platforms as incidents or tickets. Alert details, severity, timestamps, and metadata are mapped automatically, enabling faster incident response. #### Use case 2: Monitoring-driven automation workflows CloudWatch metrics and events can be used to trigger automated workflows across DevOps and operations systems. ZigiOps allows teams to react to infrastructure or application anomalies without manual intervention. #### Use case 3: Centralized monitoring across enterprise tools ZigiOps can act as a bridge between Amazon CloudWatch and multiple downstream systems, enabling organizations to consolidate monitoring data into a single operational workflow while maintaining traceability back to CloudWatch. ### What integration templates are available for Amazon CloudWatch? ZigiOps provides prebuilt integration templates for Amazon CloudWatch, depending on the target system and use case. #### Related Templates ZigiOps integration templates for Amazon CloudWatch are available depending on the paired system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Amazon CloudWatch integrations, please contact: **Email:** ### Summary The Amazon CloudWatch integration in ZigiOps provides: * Agentless, secure connectivity to AWS monitoring data * Support for all Amazon CloudWatch versions * IAM-based authentication using access keys * Flexible deployment with optional proxy support * Ready-to-use templates for monitoring-driven workflows # AppDynamics Learn how to connect AppDynamics to ZigiOps. Supported versions, prerequisites, authentication details, and connected system configuration. ### What is AppDynamics integration in ZigiOps? AppDynamics is an application performance monitoring (APM) platform that provides visibility into application health, performance metrics, topology, and events. ZigiOps enables secure, agentless integrations between AppDynamics and ITSM, monitoring, and analytics platforms. Using ZigiOps, AppDynamics metrics, events, topology data, and violations can be synchronized with external systems to support monitoring-driven workflows and automated incident management. With ZigiOps, AppDynamics can: * Send application and node metrics to monitoring platforms * Forward events and violations to ITSM systems * Enrich topology data in downstream tools * Participate in end-to-end observability workflows without custom scripting ### Which AppDynamics versions are supported? {% hint style="warning" %} Using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | ----------------------- | -------------------------- | ---------------------------------------------------- | | AppDynamics (LITE, PRO) | Cloud, Server |

4.2 (or newer)
4.5 (or newer) for EUM data

| ## Are there any environmental prerequisites for AppDynamics? {% hint style="info" %} There are no environmental prerequisites for this product. {% endhint %} Before configuring AppDynamics, always confirm the prerequisites of the corresponding integration template, as some templates may have system-specific requirements. ### How do I connect AppDynamics to ZigiOps? #### AppDynamics - Connected System Configuration Follow the steps below to add AppDynamics as a connected system in ZigiOps. {% stepper %} {% step %} **Log in** Log in to your **ZigiOps** instance. {% endstep %} {% step %} **Add AppDynamics as a connected system** Navigate to **Connected Systems > Add New System > AppDynamics** and configure the following parameters: **Server URL**\ Input the URL of your AppDynamics instance. Examples: * `https://example.appdynamics.com:8090` * `https://example.saas.appdynamics.com` **Username**\ Enter your username followed by the AppDynamics account name.\ Example: `user@yourAccount` **Password**\ Enter the password for the specified user. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} **Review the configuration** Review the configuration. {% endstep %} {% step %} **Save** Click **Save** to store the connected system. Once saved, AppDynamics becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common AppDynamics integration use cases? #### Use case 1: Forwarding application metrics to monitoring platforms ZigiOps can synchronize AppDynamics application, node, and transaction metrics with monitoring systems such as OBM or vROps. This enables unified visibility across application and infrastructure monitoring tools. #### Use case 2: Sending AppDynamics events and violations to ITSM systems When AppDynamics detects performance violations or critical events, ZigiOps can forward them to ITSM platforms as events or incidents. This allows operations teams to react quickly to application issues using established ITSM workflows. #### Use case 3: Topology enrichment and observability workflows AppDynamics topology data can be synchronized to external systems using ZigiOps, enriching monitoring and analytics platforms with application-level context and relationships. ### What integration templates are available for AppDynamics? ZigiOps provides a variety of prebuilt integration templates for AppDynamics, organized by target system and data type. #### Related Templates * AppDynamics application metrics - OBM metrics * AppDynamics application metrics - vROps metrics * AppDynamics events - OBM events * AppDynamics node metrics - OBM metrics * AppDynamics node metrics - Splunk Enterprise events * AppDynamics node topology - vROps topology enrichment * AppDynamics topology - OBM topology * AppDynamics transaction metrics - vROps metrics * AppDynamics violations - OBM events * AppDynamics violations - Remedy incidents Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for AppDynamics integrations, please contact: \ **Email:** ### Summary The AppDynamics integration in ZigiOps enables: * Agentless, secure connectivity to AppDynamics environments * Support for AppDynamics LITE and PRO editions * Cloud and on-premises deployments * No environmental prerequisites * Ready-to-use templates for metrics, events, topology, and ITSM workflows # Azure DevOps Learn how to connect Azure DevOps to ZigiOps. Step-by-step Personal Access Token setup, connected system configuration, and supported integration templates. ### What is Azure DevOps integration in ZigiOps? Azure DevOps is a cloud-based DevOps platform providing work item tracking, repositories, pipelines, and release management. ZigiOps enables secure, agentless, bi-directional integrations between Azure DevOps and ITSM, DevOps, and monitoring systems. With ZigiOps, Azure DevOps can: * Receive incidents and tickets from ITSM platforms * Synchronize work items with external systems * Participate in end-to-end DevOps and IT operations workflows * Maintain traceability across tools without custom scripting ### Which Azure DevOps versions are supported? **Using a supported version is mandatory.** | Product | Supported Deployment Types | Supported Versions | | ------------ | -------------------------- | ------------------ | | Azure DevOps | All | All | ### Are there any environmental prerequisites for Azure DevOps? Before proceeding, always confirm the prerequisites of the specific integration template you plan to use. Some integration templates may not require all environmental prerequisites described below. See the **Related Templates** section at the end of this page. #### How do I create a Personal Access Token (PAT) in Azure DevOps? A Personal Access Token (PAT) is required for authenticating Azure DevOps with ZigiOps. {% stepper %} {% step %} Sign in to your Azure DevOps organization Example: `https://dev.azure.com/{yourOrganization}`. Choose the correct organization from the menu on the left.
{% endstep %} {% step %} Open User Settings and select Personal Access Tokens
{% endstep %} {% step %} Click + New Token
{% endstep %} {% step %} Configure the token * **Name** - a descriptive name for the integration * **Organization** - select the organization where the token will be used * **Expiration** - choose a lifespan for the token {% endstep %} {% step %} Select the required **Scopes**, depending on the integration use case: * For build and release agents: **Agent Pools (Read and Manage)** * For audit log access: **Read Audit Log**
{% endstep %} {% step %} Click Create {% endstep %} {% step %} Copy the token and store it securely The token is shown **only once** and will not be displayed again.
{% endstep %} {% endstepper %} ### How do I connect Azure DevOps to ZigiOps? #### Connected System Configuration Follow the steps below to add Azure DevOps as a connected system. {% stepper %} {% step %} Log in to your ZigiOps instance {% endstep %} {% step %} Navigate to Connected Systems - Add New System - Azure DevOps {% endstep %} {% step %} Configure the following parameters * **Server URL** - Enter the Azure DevOps service URL. **For Azure DevOps Cloud (most commonly used):** Use the standard Microsoft cloud endpoint: `https://dev.azure.com` This is the default and official Azure DevOps Services URL. It must be entered exactly as shown above - do not add organization names, paths, or additional segments. **For Azure DevOps On-Premises (TFS / Azure DevOps Server):** Use the specific server URL provided by your Azure DevOps Server installation. For example: `http://yourserver:8080/tfs`. On-premises deployments are significantly less common than cloud deployments. * **Instance Type** - Select the type of your Azure DevOps instance: * Cloud (Azure DevOps Services) * On-Premises (Azure DevOps Server / TFS) The selected instance type determines how ZigiOps handles the connection and naming conventions internally. * **Organization / Collection** - Enter the name of your Azure DevOps organization (Cloud) or collection (On-Premises). Although the concept is technically the same, Microsoft uses different terminology: * In **Azure DevOps Cloud**, it is called an **Organization** * In **Azure DevOps Server (On-Premises)**, it is called a **Collection** ZigiOps automatically adjusts the label based on the selected Instance Type, so there is no confusion during configuration. * **Username** - Enter your Azure DevOps username. * **Private Access Token** - Enter the previously generated Personal Access Token (PAT). Ensure the PAT has the required permissions for the integration scenario (for example: Work Items - Read/Write, Project and Team - Read). * **Proxy Settings** (optional) - Enable this option only if your environment requires communication through a proxy server. {% endstep %} {% step %} Review the configuration {% endstep %} {% step %} Click Save to store the connected system {% endstep %} {% endstepper %} ### Common Configuration Mistakes Below are the most frequent issues encountered when connecting Azure DevOps to ZigiOps. **1. Incorrect Server URL** For Azure DevOps Cloud, the Server URL must be: `https://dev.azure.com` Do not add organization names, project paths, or any additional segments. Example of incorrect format: `https://dev.azure.com/ventsi0957/Ventsi%20Basic` For On-Premises deployments, ensure the full server URL (including port if applicable) matches your Azure DevOps Server configuration. **2. Organization / Collection Name Mismatch** Ensure the Organization (Cloud) or Collection (On-Premises) name is entered exactly as defined in Azure DevOps. It is case-sensitive. Do not include URL prefixes, slashes, or extra spaces. Correct example (Cloud): `organization-name` Incorrect: `https://dev.azure.com/organization-name` **3. Insufficient PAT Permissions** The Personal Access Token (PAT) must have adequate permissions for the integration scenario. Typical required scopes include: * Work Items - Read and Write * Project and Team - Read * Build / Release - if CI/CD synchronization is required If permissions are insufficient, authentication may succeed but synchronization actions will fail. **4. Expired or Revoked PAT** If the integration stops working after a period of time, verify that the PAT: * Has not expired * Has not been manually revoked * Has not been regenerated If necessary, generate a new PAT and update it in the Connected System configuration. **5. Proxy Misconfiguration** If a proxy is required in your environment: * Ensure proxy settings are enabled in ZigiOps * Verify proxy credentials (if authentication is required) * Confirm outbound HTTPS connectivity to Azure DevOps If issues persist after reviewing the above checks, consult the Troubleshooting section or contact ZigiWave Support with the relevant logs from the ZigiOps instance. ### What are the most common Azure DevOps integration use cases? #### **Use Case 1: Synchronizing ITSM incidents with Azure DevOps work items** When incidents are created in ITSM platforms such as ServiceNow, ZigiOps can automatically create corresponding work items in Azure DevOps. Incident details such as priority, description, attachments, and comments are mapped directly to Azure DevOps work items. As developers update or resolve the work item, the changes are synchronized back to the ITSM system, ensuring consistent status tracking across teams. #### **Use Case 2: Bridging development teams working in Jira and Azure DevOps** In environments where different teams use different DevOps tools, ZigiOps enables seamless collaboration between Jira and Azure DevOps. Tasks, bugs, or user stories created in one system can be automatically created or updated in the other. This allows organizations to maintain tool flexibility while preserving traceability, visibility, and synchronized workflows across platforms. #### **Use Case 3: Centralizing operational work from ITSM into Azure DevOps** Azure DevOps is often used as the primary platform for development and operational execution. ZigiOps enables incidents, problems, or service requests from ITSM systems to be funneled into Azure DevOps as structured work items. This ensures that development teams receive actionable, well-contextualized tasks while IT operations teams retain governance and lifecycle control in their native systems. ### What integration templates are available for Azure DevOps? ZigiOps provides a set of predefined Azure DevOps integration templates, covering common ITSM and DevOps scenarios. #### **Related Azure DevOps Templates** | Template | Direction | | ---------------------------------------------- | -------------- | | Azure DevOps tasks - Jira tasks | Bi-directional | | Azure DevOps work items - Remedy incidents | Bi-directional | | Azure DevOps work items - ServiceNow incidents | Bi-directional | | Cherwell incidents - Azure DevOps issues | Bi-directional | | Remedy problems - Azure DevOps work items | Bi-directional | | ServiceNow incidents - Azure DevOps issues | Bi-directional | Each template includes predefined entity mappings, direction of synchronization, and field-level configuration logic. For detailed information about available templates for Azure DevOps integrations, please contact: \ **Email:** ### Summary The Azure DevOps integration in ZigiOps provides: * Secure, PAT-based authentication * Agentless connectivity * Support for all Azure DevOps versions and deployment types * Bi-directional synchronization with ITSM and DevOps tools * Ready-to-use integration templates # Azure Monitor Learn how to connect Azure Monitor to ZigiOps. Supported versions, prerequisites, authentication details, webhook setup, and connected system configuration. ### What is Azure Monitor integration in ZigiOps? Azure Monitor is a cloud-native monitoring service that collects metrics, logs, alerts, and events from Azure resources and applications. ZigiOps enables secure, agentless integration between Azure Monitor and ITSM, monitoring, and enterprise systems. Using ZigiOps, Azure Monitor alerts, metrics, and topology data can be forwarded to downstream systems to trigger incidents, events, or automated workflows. With ZigiOps, Azure Monitor can: * Send alerts and metrics to ITSM and monitoring platforms * Trigger incident or event creation based on Azure alerts * Participate in monitoring-to-resolution workflows * Integrate using APIs and webhooks, without custom code ### Which Azure Monitor versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------- | -------------------------- | ------------------ | | Azure Monitor | All | All | ### Are there any environmental prerequisites for Azure Monitor? {% hint style="info" %} Always confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} > See the **Related Templates** section at the end of this page. ### How do I get my Subscription ID from Azure Monitor? {% stepper %} {% step %} Log in to your Azure portal at [https://portal.azure.com](https://portal.azure.com/). {% endstep %} {% step %} Click **Subscriptions**. {% endstep %} {% step %} Locate and copy your **Subscription ID** from the list. {% endstep %} {% endstepper %} ### How do I get my Client ID, Client Secret Password, and Tenant ID from Azure Monitor? These credentials are required for authenticating Azure Monitor with ZigiOps. {% stepper %} {% step %} Log in to your Azure portal at [https://portal.azure.com](https://portal.azure.com/). {% endstep %} {% step %} Open the **Cloud Shell** console. {% endstep %} {% step %} Execute the command: ```bash az login ``` This generates a temporary login code. {% endstep %} {% step %} Open and enter the generated code to authorize the session. {% endstep %} {% step %} In **Cloud Shell**, execute: ```bash az account set --subscription "" ``` {% endstep %} {% step %} Execute: ```bash az ad sp create-for-rbac -n "" ``` {% endstep %} {% step %} Copy the generated values: * **Client ID** - AppID * **Client Secret Password** - Password * **Tenant ID** - Tenant {% endstep %} {% endstepper %} ### How do I create a Webhook Action in Azure Monitor? Webhook actions are required for integrations that rely on Azure Monitor alerts. {% stepper %} {% step %} Create a Webhook Action by following Microsoft's documentation:\ {% endstep %} {% step %} Configure the **Webhook URL** to point to the ZigiOps listener endpoint.\ Example: `https://zigiops.example.com:8899/azure/alerts` {% endstep %} {% endstepper %} ### How do I connect Azure Monitor to ZigiOps? #### Azure Monitor - Connected System Configuration Follow the steps below to add Azure Monitor as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Azure Monitor** and configure the following parameters: **URL**\ Enter the Azure management URL.\ Example: `https://management.azure.com` **Subscription ID**\ Enter your Azure subscription identifier. **Client ID**\ Enter your client identifier. **Client Secret Password**\ Enter your client secret password. **Tenant ID**\ Enter your tenant identifier. **Proxy Settings (optional)**\ Enable this option if a proxy server is required. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, Azure Monitor becomes available for use in ZigiOps integration templates. ### What are the most common Azure Monitor integration use cases? #### Use case 1: Forwarding Azure Monitor alerts to ITSM systems ZigiOps can forward Azure Monitor alerts to ITSM platforms as incidents or events. Alert details, severity, timestamps, and metadata are mapped automatically, enabling faster response to infrastructure and application issues. #### Use case 2: Centralized monitoring with downstream systems Azure Monitor metrics and alerts can be synchronized to monitoring platforms using ZigiOps, allowing organizations to consolidate Azure monitoring data into existing observability tools. #### Use case 3: Webhook-based automation workflows Using Azure Monitor webhooks, ZigiOps can trigger automated workflows based on alert conditions, enabling real-time integration without polling. ### What integration templates are available for Azure Monitor? ZigiOps provides prebuilt integration templates for Azure Monitor, depending on the target system and use case. #### Related Templates * Azure Monitor alerts - OBM events * Azure Monitor VM metrics - OBM metrics * Azure Monitor VM topology - OBM topology * Azure Monitor webhook alerts - OBM events Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Azure Monitor integrations, please contact: \ **Email:** ### Summary The Azure Monitor integration in ZigiOps enables: * Secure, agentless integration with Azure monitoring services * Support for all Azure Monitor versions * Authentication using Azure AD service principals * Webhook-based alert processing * Ready-to-use templates for alerts, metrics, and topology workflows # Bitbucket Learn how to connect Bitbucket to ZigiOps. Supported versions, prerequisites, authentication details, and connected system configuration. ### What is Bitbucket integration in ZigiOps? Bitbucket is a Git-based source code management platform used for version control, collaboration, and CI/CD workflows. ZigiOps enables secure, agentless integration between Bitbucket and ITSM, DevOps, and enterprise systems. Using ZigiOps, Bitbucket commits, issues, and repository events can be synchronized with downstream systems to support development-to-operations workflows. With ZigiOps, Bitbucket can: * Send commit and issue information to ITSM systems * Trigger incident or ticket creation based on repository activity * Support DevOps-to-ITSM workflows * Integrate without custom scripts or plugins ### Which Bitbucket versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------- | -------------------------- | ------------------ | | Bitbucket | All | All | ### Are there any environmental prerequisites for Bitbucket? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. See the **Related Templates** section at the end of this page. {% endhint %} ### How do I connect Bitbucket to ZigiOps? #### Bitbucket - Connected System Configuration Follow the steps below to add Bitbucket as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Bitbucket** and configure the following parameters: **Server URL**\ Input the URL of your Bitbucket instance.\ Example: `https://api.bitbucket.org` **API Key**\ Input your Bitbucket API key. **Client Secret**\ Input your Bitbucket client secret. **Workspace**\ Input your Bitbucket workspace name. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} Click **Save** to store the connected system. Once saved, Bitbucket becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Bitbucket integration use cases? #### Use case 1: Creating ITSM incidents from Bitbucket commits ZigiOps can forward Bitbucket commit information to ITSM systems, allowing teams to automatically create incidents or tickets based on repository activity or commit patterns. #### Use case 2: Synchronizing Bitbucket issues with ITSM platforms Bitbucket issues can be synchronized with ITSM systems to ensure visibility between development and operations teams, reducing manual communication and context switching. #### Use case 3: DevOps-to-ITSM workflow automation By integrating Bitbucket with ITSM platforms, ZigiOps enables automated workflows that connect code changes with operational processes, improving traceability and incident response. ### What integration templates are available for Bitbucket? ZigiOps provides prebuilt integration templates for Bitbucket, depending on the target system and use case. #### Related Templates * Bitbucket commits - ServiceNow incidents * Bitbucket issues - ServiceNow incidents Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Bitbucket integrations, please contact: \ **Email:** ### Summary The Bitbucket integration in ZigiOps provides: * Secure, agentless integration with Bitbucket repositories * Support for all Bitbucket versions and deployment types * API-based authentication using API key and client secret * Flexible proxy support * Ready-to-use templates for DevOps and ITSM workflows # Cherwell Learn how to connect Cherwell Service Management to ZigiOps. Supported versions, API key creation, correlation ID setup, and configuration steps. ### What is Cherwell integration in ZigiOps? Cherwell Service Management is an ITSM platform used to manage incidents, change requests, service requests, and other service management processes. ZigiOps enables secure, agentless integration between Cherwell and ITSM, DevOps, and monitoring systems. Using ZigiOps, Cherwell entities can be synchronized with external platforms to support cross-tool workflows, automated ticket creation, and end-to-end service management processes. With ZigiOps, Cherwell can: * Exchange incidents, change requests, and service records with external systems * Receive events and alerts from monitoring platforms * Participate in ITSM-to-DevOps and monitoring-to-ITSM workflows * Synchronize data securely without custom scripts or plugins ### Which Cherwell versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------------------- | -------------------------- | ------------------ | | Cherwell Service Management | Server | 8.x (or newer) | ### Are there any environmental prerequisites for Cherwell? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. See the **Related Templates** section at the end of this page. {% endhint %} ### How do I create an API Key in Cherwell Service Management? An API key is required to authenticate Cherwell with ZigiOps. **Steps:** 1. Open the **Cherwell Administrator** application. 2. Click **Security** on the left side. 3. Select **Edit REST API Client Settings**. 4. Click **File > New** to create a new **API Key**. 5. Configure the key: * Enter a **Display Name**. * Enable **API Access is Enabled**. 6. Save the configuration. ### How do I create a Correlation ID field in Cherwell Service Management? A **Correlation ID** field is recommended to ensure reliable bi-directional synchronization and record traceability. **Steps:** 1. Open the **Cherwell Administrator Application** and log in with an administrator account. 2. Click **Create New Blueprint** from the Common Tasks pane. 3. Double-click the desired **Business Object**. 4. Click **Add Field**. 5. Configure the new field: * **Name** - Correlation ID (Internal name is automatically set to CorrelationId; keep the default.) * **Track Changes to the Field** - Enabled * **Include in Full-Text Search** - Enabled * **Length** - 150 (to avoid trimming) 6. Save and publish the blueprint. ### How do I connect Cherwell to ZigiOps? #### Cherwell - Connected System Configuration Follow the steps below to add Cherwell as a connected system in ZigiOps. 1. Log in to your **ZigiOps** instance. 2. Navigate to **Connected Systems > Add New System > Cherwell**. 3. Configure the following parameters: **URL**\ Enter the URL of your Cherwell instance.\ Example: `https://cherwell.example.com` **Username**\ Enter your Cherwell username. **Password**\ Enter the password for the specified user. **API Token**\ Enter the API key generated earlier. **Proxy Settings (optional)**\ Enable this option if a proxy server is required. 4. Review the configuration. 5. Click **Save** to store the connected system. Once saved, Cherwell becomes available for use in ZigiOps integration templates. ### What are the most common Cherwell integration use cases? #### Use case 1: Synchronizing Cherwell incidents with DevOps tools Cherwell incidents can be synchronized with DevOps platforms such as Jira or Azure DevOps, enabling seamless collaboration between service and development teams. #### Use case 2: Forwarding monitoring events to Cherwell ZigiOps can forward events and alerts from monitoring platforms into Cherwell as incidents, supporting faster incident creation and response. #### Use case 3: Cross-ITSM workflows Cherwell change requests and service records can be synchronized with other ITSM tools, ensuring data consistency across service management environments. ### What integration templates are available for Cherwell? ZigiOps provides prebuilt integration templates for Cherwell. #### Related Templates * Cherwell change requests - ServiceNow change requests * Cherwell incidents - Azure DevOps issues * Cherwell incidents - Jira tasks * OBM events - Cherwell incidents Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filters For detailed information about available templates for Amazon Cherwell integrations, please contact: \ **Email:** ### Summary The Cherwell integration in ZigiOps enables: * Secure, agentless connectivity to Cherwell Service Management * Support for Cherwell 8.x and newer versions * Authentication using REST API keys * Correlation ID-based record traceability * Ready-to-use templates for ITSM, DevOps, and monitoring workflows # CircleCI Learn how to connect CircleCI to ZigiOps. Supported versions, authentication details, connected system configuration, and available integration templates. ### What is CircleCI integration in ZigiOps? CircleCI is a cloud-based continuous integration and delivery (CI/CD) platform used to automate build, test, and deployment pipelines. ZigiOps enables secure, agentless integration between CircleCI and ITSM, DevOps, and enterprise systems. Using ZigiOps, CircleCI build events, pipeline results, and related metadata can be synchronized with downstream systems to support DevOps-to-ITSM workflows and automated operational processes. With ZigiOps, CircleCI can: * Trigger incidents or tasks based on pipeline failures * Send build and job information to ITSM systems * Support CI/CD-driven automation workflows * Integrate without custom scripts or plugins ### Which CircleCI versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------- | -------------------------- | ------------------ | | CircleCI | All | All | ### Are there any environmental prerequisites for CircleCI? **Note:** There are no environmental prerequisites for this product. Before configuring CircleCI, always confirm the prerequisites of the corresponding integration template, as some templates may introduce additional requirements. > See the **Related Templates** section at the end of this page. ### How do I connect CircleCI to ZigiOps? #### CircleCI - Connected System Configuration Follow the steps below to add CircleCI as a connected system in ZigiOps. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Add CircleCI as a connected system Navigate to **Connected Systems > Add New System > CircleCI**. {% endstep %} {% step %} Configure the following parameters **Server URL**\ Enter the URL of your CircleCI instance.\ Example: `https://circleci.com` **API Key**\ Enter the API key used for authentication against your CircleCI instance. **VCS**\ Enter the version control system used with CircleCI.\ Example: `github` **Organization**\ Enter the name of your CircleCI organization.\ Example: `zigiwave` **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review and save the configuration Review the configuration. Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, CircleCI becomes available for use in ZigiOps integration templates. ### What are the most common CircleCI integration use cases? #### Use case 1: Creating ITSM incidents from failed pipelines When CircleCI pipelines or jobs fail, ZigiOps can forward the failure details to ITSM systems, automatically creating incidents or tasks with contextual build information. #### Use case 2: CI/CD-driven DevOps workflows CircleCI build and job data can be synchronized with DevOps and ITSM platforms, enabling traceability between code changes, builds, and operational issues. #### Use case 3: Automated operational response ZigiOps can trigger automated workflows based on CircleCI events, allowing organizations to respond to build and deployment issues without manual intervention. ### What integration templates are available for CircleCI? ZigiOps provides prebuilt integration templates for CircleCI. #### Related Templates For detailed information about available CircleCI integration templates, please contact: **Email:** Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules ### Summary The CircleCI integration in ZigiOps enables: * Secure, agentless connectivity to CircleCI * Support for all CircleCI versions and deployment models * API key-based authentication * Optional proxy support * Ready-to-use templates for CI/CD and ITSM workflows # ConnectWise Learn how to connect ConnectWise to ZigiOps. Supported versions, prerequisites, authentication setup, and connected system configuration. ### What is ConnectWise integration in ZigiOps? ConnectWise PSA (formerly ConnectWise Manage) is a professional services automation platform widely used by Managed Service Providers (MSPs) and IT service teams. It centralizes service desk operations, ticket management, project tracking, and billing workflows. ZigiOps enables secure, no-code integration between ConnectWise PSA and DevOps, ITSM, and enterprise systems. Using ZigiOps, ConnectWise service tickets, notes, attachments, and custom fields can be synchronized with downstream systems to support service-to-development workflows. With ZigiOps, ConnectWise PSA can: * Sync service tickets bi-directionally with Jira, Azure DevOps, Remedy, ServiceNow, and other DevOps and ITSM systems * Transfer notes, attachments, and custom fields as part of each sync operation * Trigger automatic ticket or work item creation in connected systems * Support MSP service-desk-to-engineering workflows without manual handoffs * Integrate without custom scripts, plugins, or code of any kind ### Which ConnectWise PSA versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------- | -------------------------- | ------------------ | | ConnectWise PSA | Cloud, On-Premise | 2019.1 or older | ### Are there any environmental prerequisites for ConnectWise PSA? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. {% endhint %} See the **Related Templates** section at the end of this page. The following prerequisites apply to ConnectWise PSA integrations: * A ConnectWise PSA instance accessible over HTTPS. * A dedicated ConnectWise PSA user account created for ZigiOps, with the required API permissions for your integration use case. * API access enabled on your ConnectWise PSA instance. * A valid Public Key and Private Key pair generated for the integration user. #### How to generate API Keys in ConnectWise PSA {% stepper %} {% step %} Log in to ConnectWise PSA Log in to your ConnectWise PSA instance with an administrator account. {% endstep %} {% step %} Open API Keys Navigate to **My Account** (top-right user menu) and select **API Keys**. {% endstep %} {% step %} Add a new key pair Click the **Add (+)** button to create a new API key pair. {% endstep %} {% step %} Enter a description Enter a **Description** to identify the key. For example: `ZigiOps Integration`. {% endstep %} {% step %} Save the key pair Click **Save**. The Public Key and Private Key are generated and displayed once. {% endstep %} {% step %} Copy and store the keys securely Copy both values immediately and store them securely. The Private Key is not shown again after you leave the page. {% endstep %} {% endstepper %} ### How do I connect ConnectWise PSA to ZigiOps? #### ConnectWise PSA - Connected System Configuration Follow the steps below to add ConnectWise PSA as a connected system in ZigiOps. {% stepper %} {% step %} Log in to ZigiOps Log in to your ZigiOps instance. {% endstep %} {% step %} Add ConnectWise PSA Navigate to **Connected Systems → Add New System → ConnectWise PSA** and configure the following parameters: * **Server URL** - Input the base URL of your ConnectWise PSA instance. For example: `https://na.myconnectwise.net` * **Company ID** - Input the Company ID associated with your ConnectWise PSA instance. * **Public Key** - Input the Public Key generated in the API Keys section of your ConnectWise PSA account. * **Private Key** - Input the Private Key generated alongside your Public Key. * **Proxy Settings (optional)** - Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration {% endstep %} {% step %} Save the system Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, ConnectWise PSA becomes available for use in ZigiOps integration templates. ### What are the most common ConnectWise PSA integration use cases? #### Use case 1: Syncing ConnectWise PSA service tickets with Jira ZigiOps monitors ConnectWise PSA for new and updated service tickets. When a qualifying ticket is detected, it is extracted, including summary, status, priority, company, contact, site, owner, notes, attachments, and custom fields, and a corresponding Jira issue is created or updated automatically. All required and optional Jira fields are populated. Changes in Jira flow back to ConnectWise PSA in real time, keeping both teams working from current data. #### Use case 2: Syncing ConnectWise PSA service tickets with Azure DevOps ZigiOps monitors ConnectWise PSA for new and updated service tickets. Each qualifying ticket is extracted with full field coverage and a corresponding Azure DevOps work item is created or updated automatically. Updates made in Azure DevOps flow back to ConnectWise PSA in real time. This is a recommended workflow for MSPs managing development pipelines alongside customer service operations. #### Use case 3: Automating service-desk-to-engineering handoffs By integrating ConnectWise PSA with DevOps tools via ZigiOps, service desk and engineering teams stay aligned without switching systems. Ticket context, notes, and attachments travel automatically, eliminating duplicate data entry and reducing the risk of errors introduced by manual processes. ### What entities does ZigiOps support for ConnectWise PSA? The following entities are supported in ConnectWise PSA integrations: | Entity | Description | | ------------------- | ------------------------------------------------------------------------------------ | | Service Tickets | Incidents, requests, and service tickets managed in ConnectWise PSA. | | Notes | Internal and external notes attached to service tickets. | | Attachments | File attachments linked to tickets, transferred as part of the sync. | | Custom Fields | All standard and custom fields, detected automatically via dynamic schema discovery. | | Status | Ticket status values, mapped to corresponding statuses in the target system. | | Priority | Priority levels, mapped and transformed as needed across integrated systems. | | Company and Contact | Company and contact information associated with each ticket record. | | Site and Owner | Site location and ticket owner fields, included in full-record sync operations. | ### What integration templates are available for ConnectWise PSA? ZigiOps provides prebuilt integration templates for ConnectWise PSA, depending on the target system and use case. ZigiOps integration templates for ConnectWise are available depending on the paired system. Contact for detailed template availability. #### Related Templates | Template | Description | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | ConnectWise PSA to Jira | Bi-directional sync of ConnectWise service tickets and Jira issues, including notes, attachments, and custom fields. | | ConnectWise PSA to Azure DevOps | Bi-directional sync of ConnectWise service tickets and Azure DevOps work items, including notes, attachments, and custom fields. | Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filtering rules Templates are documented individually in the Integration Catalog. ### Summary The ConnectWise PSA integration in ZigiOps provides: * Secure, no-code integration with ConnectWise PSA service desk workflows * Support for ConnectWise PSA versions up to and including 2019.1 * Support for both cloud and on-premise ConnectWise PSA deployments * API-based authentication using Company ID, Public Key, and Private Key * Bi-directional sync of tickets, notes, attachments, and custom fields * Dynamic schema discovery for automatic custom field detection * Flexible proxy support * Ready-to-use templates for Jira and Azure DevOps workflows # Datadog Learn how to connect Datadog to ZigiOps. Supported versions, API and application key setup, connected system configuration, and integration templates. ### What is Datadog integration in ZigiOps? Datadog is a cloud-based monitoring and observability platform that provides metrics, events, logs, and topology visibility across applications and infrastructure. ZigiOps enables secure, agentless integration between Datadog and ITOM, ITSM, and monitoring platforms. Using ZigiOps, Datadog metrics, events, and topology data can be synchronized with downstream systems to support centralized monitoring, event correlation, and automated incident workflows. With ZigiOps, Datadog can: * Send events and alerts to ITSM or event management systems * Synchronize metrics with centralized monitoring platforms * Share topology data for enriched observability * Participate in end-to-end monitoring and operations workflows without custom scripts ### Which Datadog versions are supported? {% hint style="warning" %} Using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Datadog | All | All | ### Are there any environmental prerequisites for Datadog? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} See the **Related Templates** section at the end of this page. ### How do I create an API Key and Application Key in Datadog? An **API Key** and **Application Key** are required to authenticate Datadog with ZigiOps. **Steps:** 1. Log in to your Datadog instance. 2. From the left-hand navigation menu, go to **Integrations > APIs**. 3. Expand the **API Keys** section. 4. Click **Create API Key** to generate a new API key. 5. Click **Create Application Key** to generate a new application key. 6. Copy and store both keys securely. ### How do I connect Datadog to ZigiOps? #### Datadog - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open the Datadog connected system setup Navigate to **Connected Systems > Add New System > Datadog**. {% endstep %} {% step %} Configure the connection Configure the following parameters: **Server URL**\ Enter the URL of your Datadog instance.\ Examples: * `https://app.datadog.com` * `https://app.datadoghq.eu` **API Key**\ Enter the API key generated earlier. **Application Key**\ Enter the application key generated earlier. **Proxy Settings (optional)**\ Enable this option if a proxy server is required. {% endstep %} {% step %} Review the configuration {% endstep %} {% step %} Save the connected system Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, Datadog becomes available for use in ZigiOps integration templates. ### What are the most common Datadog integration use cases? #### Use case 1: Forwarding Datadog events to event management platforms ZigiOps can forward Datadog events to event management systems such as OBM, enabling centralized event processing and correlation across multiple monitoring sources. #### Use case 2: Synchronizing Datadog metrics Datadog metrics can be synchronized with centralized monitoring platforms to provide unified visibility across applications and infrastructure. #### Use case 3: Topology synchronization and enrichment ZigiOps can synchronize Datadog host and infrastructure topology to downstream systems, enriching topology views and supporting advanced root-cause analysis workflows. ### What integration templates are available for Datadog? ZigiOps provides prebuilt integration templates for Datadog. #### Related Templates * Datadog events - OBM events * Datadog host topology - OBM topology * Datadog metrics - OBM metrics Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Datadog integrations, please contact: \ **Email:** ### Summary The Datadog integration in ZigiOps enables: * Secure, agentless connectivity to Datadog * Support for all Datadog versions and deployment types * Authentication using API and application keys * Optional proxy support * Ready-to-use templates for events, metrics, and topology synchronization # Dynatrace Learn how to connect Dynatrace to ZigiOps. Supported versions, API token creation, webhook setup, connected system configuration, and templates. ### What is Dynatrace integration in ZigiOps? Dynatrace is a software intelligence and observability platform that provides monitoring for applications, infrastructure, user experience, and cloud environments. ZigiOps enables secure, agentless integration between Dynatrace and ITOM, ITSM, and monitoring platforms. Using ZigiOps, Dynatrace problems, metrics, events, and topology data can be synchronized with downstream systems to support centralized monitoring, event correlation, and automated incident workflows. With ZigiOps, Dynatrace can: * Forward problems and events to event management and ITSM systems * Synchronize metrics with centralized monitoring platforms * Share application and host topology data * Support both polling-based and listener (webhook) integrations ### Which Dynatrace versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------- | -------------------------- | ------------------ | | Dynatrace | Managed, SaaS | All | ### Are there any environmental prerequisites for Dynatrace? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} See the **Related Templates** section at the end of this page. ### How do I generate an API Token in Dynatrace? An API token is required to authenticate Dynatrace with ZigiOps. {% stepper %} {% step %} Log in and open the API token settings Log in to your Dynatrace instance and navigate to **Settings > Integration > Dynatrace API**. {% endstep %} {% step %} Generate and configure the token Click **Generate Token** and configure the following: **Display Name**\ Enter a meaningful name for the token. **Permissions** Enable the following permissions: *API v1:* * Access problem and event feed, metrics, and topology *API v2:* * Read entities * Read metrics * Read problems {% endstep %} {% step %} Generate and save the token Click **Generate**, then copy the generated token and store it securely. {% hint style="warning" %} The token is visible only once at creation time and cannot be retrieved later. {% endhint %} {% endstep %} {% endstepper %} ### How do I create a Webhook Problem Notification in Dynatrace? Webhook notifications are required for listener-based integrations where Dynatrace pushes problems directly to ZigiOps. {% stepper %} {% step %} Open Problem Notifications Log in to your Dynatrace instance and navigate to **Settings > Integration > Problem Notifications**. {% endstep %} {% step %} Add a custom integration notification Click **Add Notification** and select **Custom Integration** and configure: **Display Name**\ Freeform name shown in Dynatrace. **Webhook URL**\ Target URL of the ZigiOps listener for the **Receive Problems** action. Example: `http://zigiops.example.com:9094/listener/dynatracesaas/problem` If the ZigiOps listener uses HTTPS, you must enable **Accept any SSL certificate (Self-signed or invalid)**. **Custom Payload**\ This payload is sent via HTTP POST when a problem is detected or resolved. The payload below is mandatory: ```json { "problem_title": "{ProblemTitle}", "problem_details": "{ProblemDetailsText}", "status": "{State}", "severitylevel": "{ProblemSeverity}", "impactlevel": "{ProblemImpact}", "rankedimpacts": {ImpactedEntities}, "tagsofaffectedentities": "{Tags}", "problem_url": "{ProblemURL}", "id": "{PID}" } ``` {% endstep %} {% step %} Enable and test the notification Enable the **Receive Problems** action in ZigiOps, then click **Send Test Notification** to validate connectivity. Click **Save**. {% endstep %} {% endstepper %} ### How do I connect Dynatrace to ZigiOps? #### Dynatrace - Connected System Configuration Follow the steps below to add Dynatrace as a connected system in ZigiOps. {% stepper %} {% step %} Open the connected system setup Log in to your **ZigiOps** instance and navigate to **Connected Systems > Add New System > Dynatrace**. {% endstep %} {% step %} Configure the system Configure the following parameters: **Server URL**\ URL of your Dynatrace environment. Examples: * `https://{your-environment-id}.live.dynatrace.com` * `https://{your-domain}/e/{your-environment-id}` **API Token**\ Enter the API token generated earlier. **Proxy Settings (optional)**\ Enable this option if a proxy server is required. {% endstep %} {% step %} Save the connected system Review the configuration, then click **Save** to store the connected system. Once saved, Dynatrace becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Dynatrace integration use cases? #### Use case 1: Sending Dynatrace problems to event management systems Dynatrace problems can be forwarded to event management platforms such as OBM, enabling centralized event correlation and faster incident response. #### Use case 2: Synchronizing Dynatrace metrics Dynatrace metrics can be synchronized with centralized monitoring systems, providing unified visibility across infrastructure and applications. #### Use case 3: Topology synchronization and enrichment Dynatrace application and host topology can be synchronized to downstream systems, enriching topology models and supporting root-cause analysis workflows. ### What integration templates are available for Dynatrace? ZigiOps provides multiple prebuilt integration templates for Dynatrace. #### Related Templates * Dynatrace application topology - OBM topology * Dynatrace application topology - vROps topology * Dynatrace host topology - OBM topology * Dynatrace listener problems - OBM events * Dynatrace polling problems - OBM events * Dynatrace metrics - OBM metrics Each template includes: * Predefined entity mappings * Direction of synchronization (polling or listener-based) * Entity-specific logic and filters For detailed information about available templates for Dynatrace integrations, please contact: \ **Email:** ### Summary The Dynatrace integration in ZigiOps enables: * Secure, agentless connectivity to Dynatrace (Managed and SaaS) * Support for all Dynatrace versions * API token-based authentication * Webhook-based and polling-based integrations * Ready-to-use templates for problems, metrics, and topology synchronization # File Connector Learn how to configure the ZigiOps File Connector. Export integration data to files using configurable output directories, file naming, and chunking options. ### What is the File Connector in ZigiOps? The **File Connector** is a generic ZigiOps connector designed to export integration data to structured files. Unlike officially supported systems (such as Jira, ServiceNow, or monitoring tools), the File Connector is intended for: * Systems that are not natively supported * Custom-built internal applications * File-based middleware integrations * Data archival or auditing purposes It enables ZigiOps to generate structured output files containing synchronized data from integration workflows. The File Connector acts as a flexible output mechanism within ZigiOps integrations. ### When should I use the File Connector? Use the File Connector when: * The target system supports file ingestion (such as CSV or JSON logs) * You need to export integration payloads for auditing * You are integrating with legacy or internal applications * A middleware solution processes file-based data * You want to decouple ZigiOps from downstream systems ### Are there any environmental prerequisites? {% hint style="info" %} Confirm the prerequisites of the corresponding integration configuration before continuing, as some integration flows may not require all parameters. {% endhint %} There are no version requirements for the File Connector. However, you must ensure: * The specified output directory exists * ZigiOps has write permissions to the directory * Sufficient disk space is available * The file retention policy aligns with your infrastructure standards ### How do I configure the File Connector in ZigiOps? #### File Connector - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Add the File Connector Navigate to **Connected Systems > Add New System > File Connector**. {% endstep %} {% step %} Configure the parameters Configure the following parameters: **Output File Directory**\ Specify the directory where generated output files will be stored.\ Example: `/zigiops/platform/connector-logs/` Ensure the directory exists and ZigiOps has write access. **Output File Name**\ Define the file naming pattern.\ Example: `connector-{system_name}-{yy-mm-dd-hh:mm:ss}.log` You can use dynamic placeholders to generate timestamped files. **File Generation Mode**\ Select the desired file generation behavior: * **Accumulated** - Multiple executions are stored within a single output file. * **Not Accumulated** - Each execution generates a separate output file. **Maximum Number of Output Files**\ Define the maximum number of generated output files retained.\ Default: `50` When the maximum is reached, older files are rotated or removed according to system logic. **Output Chunk Size**\ Set the desired output chunk size (number of records per write operation).\ Default: `10000` This parameter controls batching behavior for large data exports. {% endstep %} {% step %} Examine the settings {% endstep %} {% step %} Save the system Click **Save** to store the system. Once saved, the File Connector becomes available as a target in integration workflows. {% endstep %} {% endstepper %} ### File Connector use case scenarios #### Use case 1: Exporting monitoring events to a legacy system A legacy application cannot consume REST APIs but supports file imports. ZigiOps synchronizes monitoring events and exports them as structured files, which are periodically imported by the legacy system. #### Use case 2: Integration with internal custom applications An internally developed application processes structured logs. The File Connector exports integration data into a predefined directory, where the internal application reads and processes it. #### Use case 3: Compliance and audit logging Organizations may require archival of integration payloads for compliance. The File Connector enables structured file output, preserving synchronization data for auditing purposes. #### Use case 4: Middleware-based processing A middleware solution (such as an ETL tool or enterprise bus) monitors a directory and processes new files. ZigiOps generates files that trigger automated downstream workflows. ### Limitations and scope The File Connector: * Does not provide prebuilt integration templates * Does not validate target system schemas * Does not enforce version compatibility * Acts solely as a structured file export mechanism Integration logic, mapping, and transformation are defined within ZigiOps integration configurations. ### Summary The File Connector in ZigiOps provides: * Generic file-based export functionality * Flexible file naming and batching options * Configurable accumulation behavior * Rotation control via maximum file limits * Support for legacy and internal system integrations It is ideal for environments where API-based integration is not available or not desired. # Foglight Learn how to connect Foglight to ZigiOps. Supported versions, API token creation, authentication options, and connected system configuration. ### What is Foglight integration in ZigiOps? Foglight is an enterprise monitoring platform used to collect alarms, metrics, and performance data across applications, databases, and infrastructure. ZigiOps enables secure, agentless integration between Foglight and ITOM, ITSM, and monitoring platforms. Using ZigiOps, Foglight alarms and monitoring data can be synchronized with downstream systems to support centralized event management and automated incident workflows. With ZigiOps, Foglight can: * Send alarms to event management systems * Trigger incident creation in ITSM tools * Participate in monitoring-to-resolution workflows * Integrate without custom scripts or agents ### Which Foglight versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------- | -------------------------- | ------------------ | | Foglight | All | All | ### Are there any environmental prerequisites for Foglight? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. See the **Related Templates** section at the end of this page. {% endhint %} #### How do I generate an API Token in Foglight? An API token is required when using token-based authentication. **Steps:** 1. Log in to your Foglight instance. 2. Navigate to **Administration > Users and Security Management > User Management**. 3. Select the desired user. 4. Click **Set Auth Token**. 5. Store the generated token securely, as Foglight does not store this token. ### How do I connect Foglight to ZigiOps? #### Foglight - Connected System Configuration Follow the steps below to add Foglight as a connected system in ZigiOps. 1. Log in to your **ZigiOps** instance. 2. Navigate to **Connected Systems > Add New System > Foglight**. 3. Configure the following parameters: **Server URL**\ Enter the URL of your Foglight instance.\ Example: `https://foglight.example.com` **Authentication Type**\ Select your preferred authentication method. **Username**\ Enter your Foglight username. **Password**\ Enter the password for the specified user *(required only when Basic authentication is selected)*. **API Token**\ Enter the API token generated earlier *(required only when API Token authentication is selected)*. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. 4. Review the configuration. 5. Click **Save** to store the connected system. Once saved, Foglight becomes available for use in ZigiOps integration templates. ### What are the most common Foglight integration use cases? #### Use case 1: Forwarding Foglight alarms to event management platforms ZigiOps can forward Foglight alarms to event management systems such as OBM, enabling centralized event processing and correlation across monitoring tools. #### Use case 2: Monitoring-driven incident creation Foglight alarms can be automatically converted into ITSM incidents, allowing operations teams to respond faster using established service management workflows. #### Use case 3: Centralized monitoring workflows By integrating Foglight with downstream systems, ZigiOps enables unified monitoring-to-resolution workflows while maintaining traceability back to Foglight. ### What integration templates are available for Foglight? ZigiOps provides prebuilt integration templates for Foglight. #### Related Templates * Foglight alarms - OBM events Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filters ZigiOps integration templates for Foglight are available depending on the paired system. For detailed information about available templates for Foglight integrations, please contact: \ **Email:** ### Summary The Foglight integration in ZigiOps enables: * Secure, agentless connectivity to Foglight * Support for all Foglight versions and deployment types * Flexible authentication using basic credentials or API tokens * Optional proxy support * Ready-to-use templates for alarm and event synchronization # Freshdesk Learn how to connect Freshdesk to ZigiOps. Supported versions, API key retrieval, connected system configuration, and available integration templates. ### What is Freshdesk integration in ZigiOps? Freshdesk is a cloud-based customer support and IT service desk platform used to manage tickets, conversations, and customer requests. ZigiOps enables secure, agentless integration between Freshdesk and ITSM, DevOps, and enterprise systems. Using ZigiOps, Freshdesk tickets can be synchronized with external platforms to support cross-team workflows, automated ticket creation, and end-to-end service management processes. With ZigiOps, Freshdesk can: * Synchronize tickets with DevOps and ITSM tools * Participate in customer-support-to-engineering workflows * Enable automated ticket creation and updates * Integrate without custom scripts or plugins ### Which Freshdesk versions are supported? {% hint style="warning" %} Using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | --------- | -------------------------- | ------------------ | | Freshdesk | All | All | ### Are there any environmental prerequisites for Freshdesk? Before configuring Freshdesk, confirm the prerequisites of the **corresponding integration template**, as some templates may not require all environmental prerequisites. > See the **Related Templates** section at the end of this page. ### How do I find my API Key in Freshdesk? An **API Key** is required to authenticate Freshdesk with ZigiOps. {% stepper %} {% step %} Log in to your Freshdesk instance. {% endstep %} {% step %} Open **Profile Settings**. {% endstep %} {% step %} Locate and copy your **API Key**. {% endstep %} {% endstepper %} ### How do I connect Freshdesk to ZigiOps? #### Freshdesk - Connected System Configuration Follow the steps below to add Freshdesk as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Freshdesk**. {% endstep %} {% step %} Configure the following parameters. **Server URL**\ Enter the URL of your Freshdesk instance.\ Example: `https://example.freshdesk.com` **API Key**\ Enter the API key retrieved from your Freshdesk profile. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, Freshdesk becomes available for use in ZigiOps integration templates. ### What are the most common Freshdesk integration use cases? #### Use case 1: Synchronizing Freshdesk tickets with Jira Freshdesk tickets can be synchronized with Jira tasks, allowing customer-reported issues to flow directly into engineering backlogs with full context. #### Use case 2: Customer-support-to-DevOps workflows ZigiOps enables automated workflows where customer requests in Freshdesk trigger DevOps tasks or incidents, improving response times and collaboration. #### Use case 3: Unified service visibility By integrating Freshdesk with ITSM or DevOps tools, organizations gain centralized visibility across customer support and internal service processes. ### What integration templates are available for Freshdesk? ZigiOps provides prebuilt integration templates for Freshdesk. #### Related Templates * Freshdesk tickets - Jira tasks Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filters For detailed information about available templates for Freshdesk integrations, please contact: \ **Email:** ### Summary The Freshdesk integration in ZigiOps enables: * Secure, agentless connectivity to Freshdesk * Support for all Freshdesk versions and deployment types * Simple authentication using API keys * Optional proxy support * Ready-to-use templates for customer support and DevOps workflows # Freshservice Learn how to connect Freshservice to ZigiOps. Supported versions, authentication details, connected system configuration, and integration templates. ### What is Freshservice integration in ZigiOps? Freshservice is a cloud-based IT service management (ITSM) platform used to manage incidents, service requests, problems, and changes. ZigiOps enables secure, agentless integration between Freshservice and ITSM, DevOps, and monitoring systems. Using ZigiOps, Freshservice tickets and service records can be synchronized with external platforms to support cross-team workflows, automated ticket creation, and end-to-end service management processes. With ZigiOps, Freshservice can: * Synchronize incidents and service requests with DevOps tools * Receive events and alerts from monitoring platforms * Support ITSM-to-DevOps and monitoring-to-ITSM workflows * Integrate securely without custom scripts or plugins ### Which Freshservice versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------ | -------------------------- | ------------------ | | Freshservice | All | All | ### Are there any environmental prerequisites for Freshservice? Before configuring Freshservice, confirm the prerequisites of the **corresponding integration template**, as some templates may not require all environmental prerequisites. > See the **Related Templates** section at the end of this page. ### How do I connect Freshservice to ZigiOps? #### Freshservice - Connected System Configuration Follow the steps below to add Freshservice as a connected system in ZigiOps. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open Freshservice connected system setup Navigate to **Connected Systems > Add New System > Freshservice**. {% endstep %} {% step %} Configure the parameters Configure the following parameters: **Server URL**\ Enter the URL of your Freshservice instance.\ Example: `https://example.freshservice.com` **Email**\ Enter the email address used to log in to Freshservice.\ Example: `youremail@example.com` **API Token**\ Enter your Freshservice API token. **Proxy Settings (optional)**\ Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration {% endstep %} {% step %} Save the connected system Click **Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, Freshservice becomes available for use in ZigiOps integration templates. ### What are the most common Freshservice integration use cases? #### Use case 1: Synchronizing Freshservice incidents with DevOps tools Freshservice incidents can be synchronized with systems such as Jira or Azure DevOps, enabling seamless collaboration between service and development teams. #### Use case 2: Forwarding monitoring events to Freshservice ZigiOps can forward events and alerts from monitoring platforms into Freshservice as incidents or service requests, supporting faster incident creation and response. #### Use case 3: Unified ITSM workflows across tools By integrating Freshservice with other ITSM or DevOps platforms, organizations can maintain consistent service workflows and data synchronization across multiple systems. ### What integration templates are available for Freshservice? ZigiOps provides prebuilt integration templates for Freshservice, depending on the target system and use case. #### Related Templates * Freshservice ticket - Jira incident Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filters For detailed information about available templates for Freshservice integrations, please contact: \ **Email:** ### Summary The Freshservice integration in ZigiOps enables: * Secure, agentless connectivity to Freshservice * Support for all Freshservice versions and deployment types * Authentication using email and API token * Optional proxy support * Ready-to-use templates for ITSM and DevOps workflows # GitHub Learn how to connect GitHub to ZigiOps. Supported versions, personal access token configuration, connected system setup, and available integration templates. ### What is GitHub integration in ZigiOps? GitHub is a Git-based source code hosting and collaboration platform used for repository management, issue tracking, and DevOps workflows. ZigiOps enables secure, agentless integration between GitHub and ITSM, DevOps, and enterprise systems. Using ZigiOps, GitHub issues and repository data can be synchronized with downstream platforms to support cross-team workflows and automated development-to-operations processes. With ZigiOps, GitHub can: * Synchronize issues with ITSM systems * Trigger incident or ticket creation based on GitHub activity * Support DevOps-to-ITSM collaboration workflows * Integrate securely without custom scripts or plugins ### Which GitHub versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | GitHub | All | All | ### Are there any environmental prerequisites for GitHub? The environmental prerequisites for this product are listed below. **Note:** Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. #### How do I create a Personal Access Token (API Key) in GitHub? Authentication between GitHub and ZigiOps requires a **Personal Access Token (PAT)**. **Steps:** 1. Log in to your GitHub account. 2. Navigate to . 3. Generate a **Personal Access Token**. 4. Store the token securely - it will be used in the connected system configuration. ### How do I connect GitHub to ZigiOps? #### GitHub - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Add GitHub as a connected system Navigate to **Connected Systems > Add New System > GitHub**. {% endstep %} {% step %} Configure the connection parameters Configure the following parameters: **Server URL**\ Input the URL of your GitHub instance.\ Example: `https://api.github.com` **Username**\ Input the username of the GitHub integration user. **API Key**\ Input GitHub's personal access token for authentication against the GitHub API. **Proxy Settings (optional)**\ Enables the usage of a proxy server if required. {% endstep %} {% step %} Save the system If the settings are correct, click **Save** to store the system. Once saved, GitHub becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common GitHub integration use cases? #### Use case 1: Synchronizing ServiceNow incidents with GitHub issues ZigiOps can automatically create GitHub issues from ServiceNow incidents, enabling seamless collaboration between ITSM and development teams. #### Use case 2: DevOps-to-ITSM traceability GitHub issues can be synchronized with ITSM platforms to maintain traceability between development tasks and operational incidents. #### Use case 3: Automated cross-team workflows By integrating GitHub with service management systems, ZigiOps enables automated workflows that reduce manual communication and improve resolution time. ### What integration templates are available for GitHub? ZigiOps provides prebuilt integration templates for GitHub. #### Related Templates * ServiceNow incidents - GitHub issues Each template includes: * Predefined entity and field mappings * Direction of synchronization * Entity-specific logic and filters For detailed information about available templates for GitHub integrations, please contact: \ **Email:** ### Summary The GitHub integration in ZigiOps enables: * Secure, agentless connectivity to GitHub * Support for all GitHub versions and deployment types * Authentication using personal access tokens * Optional proxy support * Ready-to-use templates for DevOps and ITSM workflows # Icinga Learn how to connect Icinga to ZigiOps. Supported versions, integration user setup, connected system configuration, and available templates. ### What is Icinga integration in ZigiOps? Icinga is an open-source monitoring platform used to supervise infrastructure, services, hosts, and applications. ZigiOps enables secure, agentless integration between Icinga and ITOM, ITSM, and monitoring platforms. Using ZigiOps, Icinga service status problems, metrics, host data, and topology information can be synchronized with downstream systems to support centralized monitoring and automated incident workflows. With ZigiOps, Icinga can: * Send service status problems as events to monitoring platforms * Synchronize metrics to centralized observability systems * Share host and hostgroup topology data * Participate in end-to-end monitoring-to-resolution workflows ### Which Icinga versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Icinga | All | 2.x (or newer) | ### Are there any environmental prerequisites for Icinga? The environmental prerequisites for this product are listed below. {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. {% endhint %} ### How do I prepare an Icinga integration user? To ensure proper authentication and access control, it is recommended to create a dedicated integration user in Icinga. **Steps:** 1. Log in to your Icinga instance. 2. Navigate to **Icinga > Configuration > Access Control > Users**. 3. Click **Add a New User**. 4. Enter the required details. 5. Click **Add** to create the user. 6. Navigate to **Icinga > Configuration > Access Control > Roles**. 7. Select the **Administrators** role. 8. Add the username of the newly created integration user to the **Users** field. 9. Click **Update Role**. The integration user must have sufficient privileges to retrieve monitoring data. ### How do I connect Icinga to ZigiOps? #### Icinga - Connected System Configuration Follow the steps below to add Icinga as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your ZigiOps instance Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to the Icinga connected system Navigate to **Connected Systems > Add New System > Icinga**. {% endstep %} {% step %} Configure the required parameters Configure the following parameters: **Server URL**\ Input the URL of your Icinga instance.\ Example: `https://icinga.example.com:5665` **Username**\ Input the username of the Icinga integration user. **Password**\ Input the password of the Icinga integration user. **Proxy Settings (optional)**\ Enables the usage of a proxy server if required. {% endstep %} {% step %} Save the system If the settings are correct, click **Save** to store the system. Once saved, Icinga becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Icinga integration use cases? #### Use case 1: Sending service status problems to event management platforms Icinga service status problems can be forwarded to event management systems such as OBM, enabling centralized event correlation. #### Use case 2: Synchronizing Icinga metrics Icinga metrics can be synchronized with monitoring platforms for unified visibility across infrastructure layers. #### Use case 3: Topology synchronization Icinga hosts and hostgroups topology can be synchronized with downstream systems to enrich topology models and support root-cause analysis. ### What integration templates are available for Icinga? ZigiOps provides prebuilt integration templates for Icinga. #### Related Templates * Icinga hostgroups topology - OBM topology * Icinga hosts topology - OBM topology * Icinga metrics - OBM metrics * Icinga service status problems - OBM events Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Icings integrations, please contact: \ **Email:** ### Summary The Icinga integration in ZigiOps enables: * Secure, agentless connectivity to Icinga * Support for Icinga 2.x and newer versions * Authentication using a dedicated integration user * Optional proxy configuration * Ready-to-use templates for metrics, events, and topology synchronization # IFS Assyst Learn how to connect IFS Assyst to ZigiOps. Supported versions, connected system configuration, authentication details, and integration templates. ### What is IFS Assyst integration in ZigiOps? IFS Assyst is an IT service management (ITSM) platform used to manage incidents, service requests, and operational processes. ZigiOps enables secure, agentless integration between IFS Assyst and ITSM, DevOps, and monitoring systems. Using ZigiOps, IFS Assyst records can be synchronized with external platforms to support cross-team workflows and automated service management processes. With ZigiOps, IFS Assyst can: * Synchronize incidents and service records with DevOps tools * Receive monitoring events from observability platforms * Support ITSM-to-DevOps and monitoring-to-ITSM workflows * Integrate securely without custom scripts or plugins ### Which IFS Assyst versions are supported? Please note that using a supported version is mandatory. ### Are there any environmental prerequisites for IFS Assyst? There are no environmental prerequisites for this product. **Note:** Always confirm the prerequisites of the corresponding integration template before continuing, as some templates may define additional requirements. ### How do I connect IFS Assyst to ZigiOps? #### IFS Assyst - Connected System Configuration Follow the steps below to add your IFS Assyst instance as a connected system in ZigiOps. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open the IFS Assyst connected system page Navigate to **Connected Systems > Add New System > IFS Assyst**. {% endstep %} {% step %} Configure the connection parameters Configure the following parameters: * **Server URL**\ Input the URL of your IFS Assyst instance. * **Username**\ Input the username that will be used to authenticate against the IFS Assyst instance. * **Password**\ Input the password that will be used to authenticate against the IFS Assyst instance. * **Proxy Settings**\ Enables the usage of a proxy server if required. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, IFS Assyst becomes available for use in ZigiOps integration templates. ### What are the most common IFS Assyst integration use cases? #### Use case 1: Synchronizing incidents with DevOps platforms IFS Assyst incidents can be synchronized with DevOps tools such as Jira or Azure DevOps, enabling seamless collaboration between service and development teams. #### Use case 2: Monitoring-to-ITSM workflows Monitoring events from platforms such as Dynatrace, Datadog, or Icinga can be automatically converted into IFS Assyst incidents, supporting faster response and resolution. #### Use case 3: Cross-system ITSM integration IFS Assyst can be integrated with other ITSM systems to support hybrid service management environments. ### What integration templates are available for IFS Assyst? Currently, template information for IFS Assyst is available upon request. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For more information regarding available templates for this system, please contact: **Email:** ### Summary The IFS Assyst integration in ZigiOps enables: * Secure, agentless connectivity to IFS Assyst * Support for all deployment types and versions * Authentication using username and password * Optional proxy configuration * Template-based integrations available via request # Incoming Emails Connect email servers to ZigiOps using IMAP or POP3. Configuration guide for Incoming Emails connected system. ### What is Incoming Emails integration in ZigiOps? Incoming Emails is a ZigiOps connector that enables integration with email servers using standard mail retrieval protocols. It allows ZigiOps to read and process incoming emails and use their content to trigger workflows in connected systems. ZigiOps supports IMAP and POP3 protocols with both plain and SSL/TLS connection types, making the Incoming Emails connector compatible with most enterprise and cloud email servers. With ZigiOps, Incoming Emails can: * Read emails from a configured mailbox and parse their content * Create records in CRM, ITSM, or helpdesk platforms based on incoming email data * Trigger automated workflows from email-based notifications * Integrate without custom scripts or middleware ### Which email protocols and connection types are supported? Using a supported protocol and connection type is mandatory. | Product | Supported Protocols | Supported Connection Types | | --------------- | ------------------- | -------------------------- | | Incoming Emails | IMAP, POP3 | None, SSL/TLS | ### Are there any environmental prerequisites for Incoming Emails? *Note: Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites.* See the Related Templates section at the end of this page. ### How do I connect an email server to ZigiOps? #### Incoming Emails - Connected System Configuration Follow the steps below to add an email server as a connected system using the Incoming Emails connector. {% stepper %} {% step %} Log in to your ZigiOps instance. {% endstep %} {% step %} Navigate to Connected Systems → Add New System → Incoming Emails and configure the following parameters: * **Instance URL:** Input the fully qualified domain name (FQDN) and port of the email server. Example: emailserver.example.com:443. * **Protocol Type:** Select the protocol your email server uses (IMAP or POP3). * **Connection Type:** Select the connection type of your email server (None or SSL/TLS). * **Username:** Input the username of the email account ZigiOps will use to access the mailbox. * **Password:** Input the password for the configured email account. * **Proxy Settings (optional):** Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} Click Save to store the connected system. {% endstep %} {% endstepper %} Once saved, the Incoming Emails connector becomes available for use in ZigiOps integration templates. ### What are the most common Incoming Emails integration use cases? #### Use case 1: Creating CRM leads from incoming emails ZigiOps can parse incoming emails and use their content to create leads or contacts in CRM platforms such as Zendesk Sell. This is useful for sales teams managing inbound email inquiries. #### Use case 2: Generating ITSM tickets from email notifications Teams that receive system alerts or user requests via email can configure ZigiOps to automatically create tickets or incidents in ITSM platforms, eliminating manual data entry. #### Use case 3: Email-driven workflow automation By connecting email mailboxes to other systems via ZigiOps, organizations can build automated workflows triggered by specific email patterns, subjects, or senders. ### What integration templates are available for Incoming Emails? #### Related Templates * [Incoming Emails to Zendesk Sell leads](https://docs.zigiwave.com/zigiops/incoming-emails-emails-to-zendesk-sell-leads) Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Incoming Emails integrations, please contact: \ **Email:** ### **Summary** The Incoming Emails integration in ZigiOps provides: * Support for IMAP and POP3 protocols * Compatible with None and SSL/TLS connection types * Username and password authentication * Flexible proxy support * Ready-to-use templates for CRM and ITSM workflows # Ivanti ### What is Ivanti integration in ZigiOps? Ivanti is an enterprise service and IT management platform used to manage incidents, service requests, and operational workflows. ZigiOps enables secure, agentless integration between Ivanti and ITSM, DevOps, and monitoring systems. Using ZigiOps, Ivanti records can be synchronized with external platforms to support cross-team collaboration and automated service management workflows. With ZigiOps, Ivanti can: * Synchronize incidents with monitoring or DevOps systems * Receive events from observability platforms * Participate in ITSM-to-monitoring workflows * Integrate securely without custom scripts or plugins ### Which Ivanti versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Ivanti | All | All | ### Are there any environmental prerequisites for Ivanti? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. {% endhint %} ### How do I obtain an API Key in Ivanti? An API Key is required to authenticate Ivanti with ZigiOps. {% stepper %} {% step %} * Log in to Ivanti Log in to your Ivanti instance. {% endstep %} {% step %} * Open the API Key settings Navigate to **Settings > Security Controls > API Key** and select the desired key group. {% endstep %} {% step %} * Copy the API Key The API Key is available in the right part of the screen. Store the API Key securely - it will be required during connected system configuration. {% endstep %} {% endstepper %} ### How do I connect Ivanti to ZigiOps? #### Ivanti - Connected System Configuration Follow the steps below to add your Ivanti instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Add Ivanti as a connected system Navigate to **Connected Systems > Add New System > Ivanti** and configure the following parameters: **Server URL**\ Input the URL of your Ivanti instance.\ Example: `https://example.vantosi.com/HEAT` **API Key**\ Input the API Key required for authentication. **Proxy Settings**\ Enables the usage of a proxy server, if required. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. Once saved, Ivanti becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Ivanti integration use cases? #### Use case 1: Monitoring-to-Ivanti incident automation Monitoring events from platforms such as OBM can automatically create Ivanti incidents, enabling faster response and centralized service management. #### Use case 2: Cross-system ITSM workflows Ivanti can be integrated with other ITSM tools to support hybrid environments and synchronized service processes. #### Use case 3: Event-driven service management ZigiOps can synchronize external system events into Ivanti, ensuring operational visibility and traceability. ### What integration templates are available for Ivanti? ZigiOps provides prebuilt integration templates for Ivanti. #### Related Templates * OBM events - Ivanti incidents Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Ivanti integrations, please contact: \ **Email:** ### Summary The Ivanti integration in ZigiOps enables: * Secure, agentless connectivity to Ivanti * Support for all Ivanti deployment types and versions * Authentication using API keys * Optional proxy configuration * Ready-to-use templates for event and incident synchronization # Jenkins Learn how to connect Jenkins to ZigiOps. Supported versions, authentication methods, connected system configuration, and available integration templates. ### What is Jenkins integration in ZigiOps? Jenkins is an automation server used for continuous integration (CI) and continuous delivery (CD). It enables development teams to automate builds, testing, and deployment pipelines. ZigiOps enables secure, API-based integration between Jenkins and ITSM, ITOM, DevOps, and monitoring systems. Using ZigiOps, Jenkins jobs, builds, and pipeline events can be synchronized with external platforms to support automated workflows and cross-team collaboration. With ZigiOps, Jenkins can: * Trigger ITSM incidents when builds fail * Synchronize pipeline execution status with change management systems * Update DevOps issues based on deployment progress * Participate in event-driven CI/CD workflows * Enable bidirectional synchronization between Jenkins and external platforms The integration is fully customizable and does not require custom scripts or plugins. ### Which Jenkins versions are supported? Please note that using a supported version is mandatory. Jenkins must expose a functional REST API and allow authenticated access. ### Are there any environmental prerequisites for Jenkins? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing further, as some templates may not require all environmental prerequisites. {% endhint %} **Jenkins Requirements:** * Jenkins instance accessible from ZigiOps * REST API enabled * Valid Jenkins user account * API Token generated (recommended for secure authentication) **Network and Connectivity Requirements:** * HTTPS access to the Jenkins server * If Jenkins is hosted on-premises behind a firewall: * Install the ZigiOps agent within the customer environment * Ensure outbound encrypted communication over TLS 1.2 ZigiOps supports secure communication via HTTPS and encrypted protocols. ### How do I connect Jenkins to ZigiOps? #### Jenkins - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your ZigiOps instance. {% endstep %} {% step %} Open Jenkins connected system setup Navigate to **Connected Systems > Add New System > Jenkins**. {% endstep %} {% step %} Configure the connection parameters Configure the following parameters: **Server URL**\ Input the full base URL of your Jenkins instance.\ Example: `https://jenkins.company.com` **Authentication Type**\ Select the authentication method. **Username**\ Input the Jenkins username. **API Token / Password**\ Input the generated Jenkins API token (recommended for secure authentication). **Proxy Settings**\ Enables the usage of a proxy server, if required. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, Jenkins becomes available for use in ZigiOps integration templates. ### What are the most common Jenkins integration use cases? #### Use case 1: CI failure to incident automation When a Jenkins build fails, ZigiOps can automatically create an incident in an ITSM platform (such as ServiceNow, Ivanti, or Jira), enabling faster resolution and centralized service management. #### Use case 2: Deployment-driven change updates Pipeline execution results in Jenkins can update change requests in external ITSM systems, ensuring accurate deployment tracking. #### Use case 3: DevOps visibility across tools Jenkins build and pipeline data can be synchronized with issue tracking systems, ensuring development and operations teams share consistent, real-time information. #### Use case 4: Automated ticket closure Successful builds or deployments can automatically update or resolve related tickets in connected systems. ### What integration templates are available for Jenkins? Currently, template information for Jenkins is available upon request. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For more information regarding available templates for Jenkins, please contact: **Email:** ### Summary The Jenkins integration in ZigiOps enables: * Secure, API-based connectivity to Jenkins * Support for on-premises and cloud deployments * Authentication using username and API token * Optional proxy configuration * Agent-based connectivity for on-prem environments * Fully customizable synchronization workflows * Secure communication using encrypted protocols ZigiOps allows Jenkins to participate in enterprise-grade DevOps, ITSM, and monitoring automation workflows without custom development. # Jira Learn how to connect Jira Software and Jira Service Management to ZigiOps. Step-by-step configuration, API token setup, correlation fields, and integration templates. ### What is Jira integration in ZigiOps? Jira is a widely used issue tracking and service management platform for DevOps and ITSM teams. ZigiOps enables secure, agentless, bi-directional integrations between Jira and ITSM, monitoring, CRM, and enterprise systems. With ZigiOps, Jira can: * Receive incidents, alerts, and events from monitoring tools * Sync issues, tasks, bugs, and service requests * Participate in end-to-end ITSM and DevOps workflows * Support backward synchronization (updates flow both ways) ### Which Jira products and versions are supported? **Using a supported version is mandatory.** | Product | Supported Deployment Types | Supported Versions | | ----------------------- | -------------------------- | ------------------ | | Jira Software | All | 7.x (or newer) | | Jira Service Management | All | 7.x (or newer) | ### Are there any environmental prerequisites for Jira? Before configuring Jira, always confirm the prerequisites of the corresponding integration template, as some templates may not require all steps described below. See the **Related Templates** section at the end of this page. #### How do I create an API Token in Jira Cloud? An API Token is required when integrating Jira Cloud with ZigiOps. {% stepper %} {% step %} Log in to your Jira instance Log in to your Jira instance using the Atlassian account intended for integration. {% endstep %} {% step %} Open the Atlassian API Token page Open the Atlassian API Token page: `https://id.atlassian.com/manage-profile/security/api-tokens`
{% endstep %} {% step %} Create the token Click **Create API Token**.
{% endstep %} {% step %} Copy and store it securely Copy and store the token securely. The token is visible **only once** after creation.
{% endstep %} {% endstepper %} ### How do I create a correlation field in Jira? Correlation fields allow ZigiOps to track and synchronize records across systems. {% stepper %} {% step %} Log in to Jira Log in to your Jira instance. {% endstep %} {% step %} Open Custom Fields Navigate to: **Administration - Issues - Custom Fields**
{% endstep %} {% step %} Create a new field Click the **Create new field** button in the upper right corner. {% endstep %} {% step %} Configure the field Create a new custom field: * **Type:** Text Field (single line) * **Name:** Correlation ID (or another suitable name)
{% endstep %} {% step %} Edit the field Navigate to **Edit Field**.
{% endstep %} {% step %} Associate the field Associate the field with: * Create Issue Screen * Edit Issue Screen * View Issue Screen (for the relevant projects)
{% endstep %} {% step %} Update the integration template Update your integration template in ZigiOps to replace the default correlation field with the newly created one.
{% endstep %} {% endstepper %} ### How do I connect Jira Software to ZigiOps? #### Jira Software - Connected System Configuration Follow the steps below to add Jira Software as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open the Jira connected system setup Navigate to: **Connected Systems - Add New System - Jira** {% endstep %} {% step %} Configure the parameters Configure the following parameters: * **Server URL** - Example: `https://name.atlassian.net` * **Username** - Jira username or Atlassian account email * **Password** - User password or API Token * **Proxy Settings** (optional) - Enable if a proxy server is required {% endstep %} {% step %} Save the settings Review the settings and click **Save**. {% endstep %} {% endstepper %} ### How do I connect Jira Service Management to ZigiOps? Jira Service Management requires an additional configuration step. #### Jira Service Management - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open the Jira connected system setup Navigate to: **Connected Systems - Add New System - Jira** {% endstep %} {% step %} Configure the parameters Configure the following parameters: * **Server URL** - Example: `https://name.atlassian.net` * **Username** - Jira Service Management user * **Password** - Password or API Token * **Proxy Settings** (optional) {% endstep %} {% step %} Save the system Click **Save** to store the system. {% endstep %} {% step %} Open advanced settings Open **Options - Advanced Settings**. {% endstep %} {% step %} Enable JiraSD Enable the **JiraSD** option. {% endstep %} {% step %} Apply the changes Click **Apply**. {% endstep %} {% endstepper %} This setting ensures proper handling of Jira Service Management entities such as requests and service desk tickets. ### What are the most common Jira integration use cases? #### **Use Case 1: Incident escalation from monitoring tools to Jira** When a critical alert is detected in a monitoring system (such as infrastructure or application monitoring), ZigiOps can automatically create or update a Jira issue. The alert details, severity, timestamps, and related metadata are mapped directly into Jira tasks or bugs. As the incident is acknowledged or resolved in Jira, updates can be synchronized back to the source system, ensuring full visibility and closed-loop incident management. #### **Use Case 2: Bi-directional ITSM workflows between ServiceNow and Jira** Many organizations use ServiceNow for IT operations and Jira for development teams. With ZigiOps, incidents or service requests created in ServiceNow can automatically generate Jira tasks or bugs, including comments, attachments, and priority changes. Updates made by developers in Jira are synchronized back to ServiceNow, eliminating manual handoffs and status mismatches between teams. #### **Use Case 3: Centralizing DevOps work from multiple tools into Jira** Jira is often used as the central system for tracking development and operational work. ZigiOps enables tasks, issues, and events from tools like Azure DevOps, monitoring platforms, or CRM systems to be consolidated into Jira. This allows teams to manage all incoming work in a single Jira project while maintaining traceability back to the original source system. ### What integration templates are available for Jira? ZigiOps provides a wide range of prebuilt Jira integration templates, organized by system pair. | Template | Direction | | --------------------------------------------- | -------------- | | Azure DevOps tasks - Jira tasks | Bi-directional | | Cherwell incidents - Jira tasks | Bi-directional | | Freshdesk tickets - Jira tasks | Bi-directional | | Jira tasks - Remedy incidents | Bi-directional | | Jira tasks - Remedy problems | Bi-directional | | Jira tasks - Salesforce cases | Bi-directional | | Jira tasks - ServiceNow incidents | Bi-directional | | Microsoft Dynamics incidents - Jira tasks | Bi-directional | | OBM events - Jira tasks | Bi-directional | | PagerDuty incidents - Jira tasks | Bi-directional | | Remedy change requests - Jira tasks | Bi-directional | | Remedy incidents - Jira tasks | Bi-directional | | Remedy problems - Jira tasks | Bi-directional | | Remedy work orders - Jira tasks | Bi-directional | | Salesforce cases - Jira tasks | Bi-directional | | ServiceNow incidents - Jira tasks | Bi-directional | | ServiceNow problems - Jira bugs | Bi-directional | | ServiceNow service catalog tasks - Jira tasks | Bi-directional | | SolarWinds alerts - Jira tasks | Bi-directional | Each template includes field mappings, direction of synchronization, and entity-specific logic. For detailed information about available templates for Jira integrations, please contact: \ **Email:** ### Summary The Jira integration in ZigiOps enables: * Agentless, secure connectivity * Support for Jira Software and Jira Service Management * API Token-based authentication * Correlation-aware synchronization * Prebuilt templates for ITSM, DevOps, and monitoring use cases # Kubernetes Learn how to connect Kubernetes to ZigiOps. Supported versions, authentication methods, connected system configuration, and integration templates. ### What is Kubernetes integration in ZigiOps? Kubernetes is a container orchestration platform used to automate the deployment, scaling, and management of containerized applications. ZigiOps enables secure API-based integration between Kubernetes and ITSM, ITOM, DevOps, and monitoring systems. Using ZigiOps, Kubernetes events and cluster data can be synchronized with external platforms to enable automated incident management, DevOps visibility, and cross-team collaboration. With ZigiOps, Kubernetes can: * Send cluster events to ITSM systems * Trigger automation workflows based on container state changes * Synchronize deployment information with DevOps tools * Participate in monitoring-to-incident automation scenarios * Enable one-way or bi-directional integration workflows The integration is configurable and does not require custom development. ### Which Kubernetes versions are supported? Please note that using a supported version is mandatory. ZigiOps supports all Kubernetes deployment types and versions that expose a functional Kubernetes API. ### Are there any environmental prerequisites for Kubernetes? There are no environmental prerequisites for this product. However, ensure the following basic connectivity requirements are met: * Kubernetes API endpoint is accessible from ZigiOps * Proper authentication method is configured * Network communication is allowed over HTTPS ### How do I connect Kubernetes to ZigiOps? #### Kubernetes - Connected System Configuration Follow the steps below to add your Kubernetes cluster as a connected system. {% stepper %} {% step %} Log in to your ZigiOps instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Kubernetes**. {% endstep %} {% step %} Configure the following parameters: **Server URL**\ Input the URL of your Kubernetes API server.\ Example: `https://kubernetes.example.com:8443` **Authentication Type**\ Select the desired authentication type that ZigiOps will use to authenticate against the Kubernetes API. Available authentication methods: * **No Auth** - ZigiOps will not authenticate against the Kubernetes API * **Basic Auth** - ZigiOps will use a username and password * **Bearer Token** - ZigiOps will use a token to authenticate **Proxy Settings**\ Enables the usage of a proxy server if required. {% endstep %} {% step %} Examine the settings and click **Save** to store the system. Once saved, Kubernetes becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Kubernetes integration use cases? #### Use case 1: Kubernetes events to ITSM incidents Automatically create incidents in ITSM platforms when Kubernetes detects pod failures, container crashes, or deployment errors. #### Use case 2: Cluster monitoring automation Synchronize Kubernetes cluster events with monitoring and observability platforms to enable unified operational visibility. #### Use case 3: DevOps change tracking Update change management records when Kubernetes deployments occur. #### Use case 4: Infrastructure-to-DevOps synchronization Bridge infrastructure-level Kubernetes data with DevOps and ticketing systems for improved traceability. ### What integration templates are available for Kubernetes? Template availability information is provided upon request. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For information regarding integration templates for Kubernetes, please contact: **Email:** ### Summary The Kubernetes integration in ZigiOps enables: * Secure API-based connectivity to Kubernetes clusters * Support for all Kubernetes deployment types and versions * Multiple authentication options (No Auth, Basic Auth, Bearer Token) * Optional proxy configuration * Automated event-driven integration workflows * Participation in enterprise ITSM, ITOM, and DevOps automation scenarios ZigiOps allows Kubernetes to be integrated into broader enterprise automation processes without requiring custom code. # Microsoft Dynamics 365 Learn how to connect Microsoft Dynamics 365 to ZigiOps. Supported versions, OAuth 2.0 configuration, connected system setup, and available integration templates. ### What is Microsoft Dynamics 365 Integration in ZigiOps? Microsoft Dynamics 365 is a cloud-based CRM and ERP platform used for sales, customer service, field service, and business operations management. ZigiOps enables secure, API-based integration between Microsoft Dynamics 365 and ITSM, DevOps, and monitoring platforms. Using ZigiOps, incidents and records from Dynamics 365 can be synchronized with external systems to support automated workflows and cross-team collaboration. With ZigiOps, Microsoft Dynamics 365 can: * Sync CRM incidents and cases with ITSM platforms such as Jira and ServiceNow * Participate in bi-directional cross-team workflows between sales and IT operations * Trigger automated ticket creation in DevOps tools based on Dynamics 365 events * Exchange data with monitoring and cloud platforms for end-to-end visibility The integration is fully customizable and does not require custom scripts or plugins. ### Which Microsoft Dynamics 365 Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------------------- | -------------------------- | ------------------ | | Microsoft Dynamics 365 | All | All | ### Are There Any Environmental Prerequisites for Microsoft Dynamics 365? > **Note:** Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. **System Requirements:** * Azure AD application with API access enabled * Client ID, Client Secret, and Tenant ID from the Azure App Registration * Integration user account with appropriate Dynamics 365 permissions **Network and Connectivity Requirements:** * HTTPS access to the Dynamics 365 instance endpoint * Outbound connectivity from ZigiOps to the Dynamics 365 API ### How Do I Connect Microsoft Dynamics 365 to ZigiOps? #### Microsoft Dynamics 365 - Connected System Configuration Follow the steps below to add your Microsoft Dynamics 365 instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > MS-Dynamics** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of your instance. For example, `https://example.crmX.dynamics.com` * **Client ID** - Input the Client ID from your Azure App Registration. * **Client Secret** - Input the Client Secret from your Azure App Registration. * **Tenant ID** - Input the Tenant ID from your Azure App Registration. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Microsoft Dynamics 365 becomes available for use in ZigiOps integration templates. ### What Are the Most Common Microsoft Dynamics 365 Integration Use Cases? #### Use Case 1: Incident Escalation from Dynamics 365 to Jira When a customer case is created or escalated in Dynamics 365, ZigiOps can automatically create a corresponding Jira task, including case details, priority, and contact information. Updates in Jira are synchronized back to Dynamics 365 for full closed-loop visibility. #### Use Case 2: Bi-Directional Case Sync Between Dynamics 365 and ServiceNow Customer incidents managed in Dynamics 365 can be mirrored as ServiceNow incidents for IT operations teams. ZigiOps keeps both records in sync, eliminating manual data entry across CRM and ITSM platforms. #### Use Case 3: Automated Cross-Team Workflows for Field Service Field service work orders created in Dynamics 365 can trigger corresponding tasks in DevOps or ITSM tools, ensuring that field operations and IT teams work from a single synchronized data set. ### What Integration Templates Are Available for Microsoft Dynamics 365? ZigiOps provides integration templates for Microsoft Dynamics 365, depending on the paired system. * Microsoft Dynamics incidents to Jira tasks Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Microsoft Dynamics 365 integrations, please contact: \ **Email:** ### Summary The Microsoft Dynamics 365 integration in ZigiOps enables: * Secure, OAuth 2.0-based API connectivity * Support for all Dynamics 365 deployment types * Integration with ITSM, DevOps, and monitoring platforms * Flexible authentication using Client ID, Client Secret, and Tenant ID * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Microsoft Dynamics 365 to participate in enterprise-grade ITSM, DevOps, and automation ecosystems without requiring custom development. # Microsoft Intune Learn how to connect Microsoft Intune to ZigiOps. OAuth 2.0 setup, connected system configuration, and integration templates for endpoint management workflows. ### What is Microsoft Intune Integration in ZigiOps? Microsoft Intune is a cloud-based endpoint management platform used for device enrollment, compliance policy enforcement, and mobile application management across enterprise environments. ZigiOps enables secure, API-based integration between Microsoft Intune and ITSM, monitoring, and DevOps platforms. Using ZigiOps, device compliance events and endpoint data from Intune can be synchronized with external systems to support automated incident creation and cross-team workflows. With ZigiOps, Microsoft Intune can: * Trigger automated incident creation in ITSM platforms based on device compliance violations * Synchronize endpoint status data with monitoring and operations tools * Participate in cross-team workflows between IT security and service management teams * Support closed-loop remediation flows between Intune and ticketing systems The integration is fully customizable and does not require custom scripts or plugins. ### Which Microsoft Intune Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------------- | -------------------------- | ------------------ | | Microsoft Intune | All | All | ### Are There Any Environmental Prerequisites for Microsoft Intune? > **Note:** Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. **System Requirements:** * Azure AD application with Microsoft Graph API access enabled * Client ID, Client Secret, and Tenant ID from the Azure App Registration * Integration user or service account with appropriate Intune permissions **Network and Connectivity Requirements:** * HTTPS access to the Microsoft Graph API endpoint (`https://graph.microsoft.com`) * Outbound connectivity from ZigiOps to the Microsoft Graph API ### How Do I Connect Microsoft Intune to ZigiOps? #### Microsoft Intune - Connected System Configuration Follow the steps below to add your Microsoft Intune instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Systems > Microsoft Intune** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the Microsoft Graph API URL. For example, `https://graph.microsoft.com` * **Client ID** - Input the Client ID from your Azure App Registration. * **Client Secret** - Input the Client Secret from your Azure App Registration. * **Tenant ID** - Input the Tenant ID from your Azure App Registration. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Microsoft Intune becomes available for use in ZigiOps integration templates. ### What Are the Most Common Microsoft Intune Integration Use Cases? #### Use Case 1: Automated Incident Creation from Device Compliance Failures When a device managed by Intune fails a compliance policy check, ZigiOps can automatically create an incident in ServiceNow or Jira, including device details, policy name, and failure reason. IT teams can remediate and close the incident, with status updates synced back to Intune records. #### Use Case 2: Endpoint Event Forwarding to Monitoring Platforms Device enrollment events, compliance state changes, and policy assignment updates from Intune can be forwarded to monitoring or observability platforms, providing a unified view of endpoint health alongside infrastructure and application data. #### Use Case 3: Cross-Team Security and Service Management Workflows Intune non-compliance events can trigger security review tasks in DevOps tools, ensuring that security and IT service management teams work from synchronized, real-time data without manual hand-offs. ### What Integration Templates Are Available for Microsoft Intune? ZigiOps provides integration templates for Microsoft Intune, depending on the paired system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Microsoft Intune integration in ZigiOps enables: * Secure, OAuth 2.0-based connectivity via the Microsoft Graph API * Support for all Microsoft Intune deployment types * Integration with ITSM, monitoring, and DevOps platforms * Flexible authentication using Client ID, Client Secret, and Tenant ID * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Microsoft Intune to participate in enterprise-grade endpoint management, ITSM, and security automation ecosystems without requiring custom development. # Microsoft SCOM Connect Microsoft SCOM to ZigiOps. Supported versions 2019 and 2022, Windows authentication setup, connected system configuration, and integration templates. ### What is Microsoft SCOM Integration in ZigiOps? Microsoft System Center Operations Manager (SCOM) is an infrastructure monitoring platform used to monitor the health, performance, and availability of Windows-based IT environments, including servers, applications, and network devices. ZigiOps enables secure, API-based integration between Microsoft SCOM and ITSM, DevOps, and other monitoring platforms. Using ZigiOps, alerts and monitoring events from SCOM can be synchronized with external systems to support automated incident management and cross-team operational workflows. With ZigiOps, Microsoft SCOM can: * Forward monitoring alerts and health events to ITSM platforms such as ServiceNow, Jira, or Remedy * Participate in bi-directional workflows where ITSM ticket updates are reflected back in SCOM * Contribute infrastructure health data to observability and operations management platforms * Support automated escalation and notification workflows across IT operations teams The integration is fully customizable and does not require custom scripts or plugins. ### Which Microsoft SCOM Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------------- | -------------------------- | ------------------ | | Microsoft SCOM | All | 2019, 2022 | ### Are There Any Environmental Prerequisites for Microsoft SCOM? There are no environmental prerequisites for this product. ### How Do I Connect Microsoft SCOM to ZigiOps? #### Microsoft SCOM - Connected System Configuration Follow the steps below to add your Microsoft SCOM instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > MS SCOM** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL and corresponding port of your SCOM instance. For example, `https://scom.example.com` * **Username** - Input the username ZigiOps will use to authenticate against the Microsoft SCOM API. * **Password** - Input the password ZigiOps will use to authenticate against the Microsoft SCOM API. * **Domain** - Input the domain of the Microsoft SCOM user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Microsoft SCOM becomes available for use in ZigiOps integration templates. ### What Are the Most Common Microsoft SCOM Integration Use Cases? #### Use Case 1: Alert Forwarding from SCOM to ITSM When SCOM detects a health degradation or alert threshold breach, ZigiOps can automatically create an incident in ServiceNow, Jira, or Remedy. Alert details, severity, and source information are mapped directly into the ITSM record for immediate triage. #### Use Case 2: Bi-Directional Incident Management Between SCOM and ServiceNow SCOM alerts that generate ServiceNow incidents can be updated in both directions. When an incident is resolved in ServiceNow, ZigiOps can acknowledge or close the corresponding SCOM alert, ensuring consistency across monitoring and service management. #### Use Case 3: Infrastructure Health Data Aggregation SCOM infrastructure health data can be forwarded to centralized operations management platforms, providing a unified view of Windows environment health alongside data from other monitoring tools. ### What Integration Templates Are Available for Microsoft SCOM? ZigiOps provides integration templates for Microsoft SCOM, depending on the paired system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Microsoft SCOM integration in ZigiOps enables: * Secure, domain-authenticated API connectivity * Support for Microsoft SCOM 2019 and 2022 * Integration with ITSM, monitoring, and operations platforms * Username, password, and domain-based authentication * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Microsoft SCOM to participate in enterprise-grade monitoring, ITSM, and automation ecosystems without requiring custom development. # Nagios XI Connect Nagios XI to ZigiOps. Supported versions, API key generation, and connected system configuration. ### What is Nagios XI integration in ZigiOps? Nagios XI is an enterprise-grade IT infrastructure monitoring platform used to track the health of hosts, services, and network devices. It provides alerting, reporting, and event management capabilities for IT operations teams. ZigiOps enables secure, agentless integration between Nagios XI and ITSM, AIOps, and enterprise platforms. Using ZigiOps, Nagios XI alerts and events can be forwarded to downstream systems to automate incident management and reduce manual effort. With ZigiOps, Nagios XI can: * Forward alerts and events to ITSM platforms such as ServiceNow or Jira * Trigger automatic incident or ticket creation from monitoring alerts * Synchronize monitoring data with operations management platforms * Integrate without custom scripts or additional plugins ### Which Nagios XI versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------- | -------------------------- | ------------------ | | Nagios XI | All | 5.x or newer | ### Are there any environmental prerequisites for Nagios XI? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} See the Related Templates section at the end of this page. ### How do I generate or find an API key in Nagios XI? {% stepper %} {% step %} Log in to your Nagios XI instance. {% endstep %} {% step %} Go to Admin → Users → Manage Users and select the desired user. {% endstep %} {% step %} Copy your existing API Key located under the API Settings menu. {% endstep %} {% step %} Click the Generate New API Key button to generate a new key. {% endstep %} {% step %} Click Update User to save the changes. This step is required only if you generated a new key. {% endstep %} {% endstepper %} ### How do I connect Nagios XI to ZigiOps? #### Nagios XI - Connected System Configuration Follow the steps below to add Nagios XI as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your ZigiOps instance. {% endstep %} {% step %} Navigate to Connected Systems → Add New System → Nagios XI and configure the following parameters: * **Server URL:** Input the URL of your Nagios XI instance. Example: . * **Password:** Input the API key that you copied or generated in the previous section. * **Proxy Settings (optional):** Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} Click Save to store the connected system. {% endstep %} {% endstepper %} Once saved, Nagios XI becomes available for use in ZigiOps integration templates. ### What are the most common Nagios XI integration use cases? #### Use case 1: Forwarding Nagios XI alerts to ITSM platforms ZigiOps can automatically forward Nagios XI alerts to ITSM platforms such as ServiceNow, Jira, or Remedy, enabling teams to create incidents or tickets without manual intervention. #### Use case 2: Bidirectional event synchronization ZigiOps supports bidirectional synchronization between Nagios XI and ITSM or AIOps platforms, ensuring that status updates made on either side are reflected across systems in real time. #### Use case 3: Monitoring-to-operations workflow automation By connecting Nagios XI with operations management platforms, ZigiOps enables automated workflows that reduce alert noise and accelerate incident resolution. ### What integration templates are available for Nagios XI? ZigiOps provides prebuilt integration templates for Nagios XI depending on the target system and use case. #### Related Templates ZigiOps provides prebuilt integration templates for Nagios XI depending on the target system and use case. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Nagios XI integrations, please contact: \ **Email:** ### **Summary** The Nagios XI integration in ZigiOps provides: * Secure, agentless integration with Nagios XI 5.x or newer * Support for all deployment types * API key-based authentication * Flexible proxy support * Ready-to-use templates for monitoring and ITSM workflows # New Relic Connect New Relic APM to ZigiOps. API key generation steps, connected system configuration, and templates for syncing APM metrics and violations with OBM and vROps. ### What is New Relic Integration in ZigiOps? New Relic is a cloud-based observability and application performance monitoring (APM) platform used to track application health, infrastructure metrics, and distributed traces across enterprise environments. ZigiOps enables secure, API-based integration between New Relic APM and ITSM, ITOM, and monitoring platforms. Using ZigiOps, APM metrics, topology data, and violation events from New Relic can be synchronized with external systems to support automated incident management and observability workflows. With ZigiOps, New Relic can: * Forward APM violations and alerts to operations management platforms such as OBM * Synchronize application topology data with infrastructure management tools * Feed host and application metrics into centralized monitoring platforms * Participate in automated incident creation and escalation workflows The integration is fully customizable and does not require custom scripts or plugins. ### Which New Relic Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------- | -------------------------- | ------------------ | | New Relic APM | All | All | ### Are There Any Environmental Prerequisites for New Relic? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How Do I Generate an API Key in New Relic? {% stepper %} {% step %} Log in to your New Relic instance. {% endstep %} {% step %} Navigate to: **Account > Account Settings > API Keys** {% endstep %} {% step %} Click the **Create a Key** button and enter the required details. {% endstep %} {% step %} Select **User** as the key type. {% endstep %} {% step %} Click **Create a Key** to generate and store the key securely. {% endstep %} {% endstepper %} ### How Do I Connect New Relic to ZigiOps? #### New Relic - Connected System Configuration Follow the steps below to add your New Relic instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > NewRelic APM** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of your New Relic instance. For example, `https://api.eu.newrelic.com` * **API Key** - Input the API Key generated in the prerequisites step. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, New Relic APM becomes available for use in ZigiOps integration templates. ### What Are the Most Common New Relic Integration Use Cases? #### Use Case 1: APM Violation Forwarding to OBM When New Relic detects an application performance violation or threshold breach, ZigiOps forwards the event to Operations Bridge Manager as a structured event. Operations teams can triage, correlate, and act on the alert within OBM without switching tools. #### Use Case 2: Application Topology Sync with OBM New Relic application and host topology data can be synchronized with OBM, providing infrastructure operations teams with an up-to-date view of application dependencies and hosting relationships. #### Use Case 3: Host Metrics Ingestion into Monitoring Platforms APM host and application metrics collected by New Relic can be fed into platforms like vROps or OBM, enabling centralized performance monitoring and capacity planning across hybrid environments. ### What Integration Templates Are Available for New Relic? ZigiOps provides the following integration templates for New Relic APM: * New Relic APM application host metrics to OBM metrics * New Relic APM application metrics to OBM metrics * New Relic APM application topology to OBM topology * New Relic APM violations to OBM events * New Relic APM application host metrics to vROps metrics Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for New Relic integrations, please contact: \ **Email:** ### Summary The New Relic integration in ZigiOps enables: * Secure, API key-based connectivity * Support for all New Relic APM deployment types * Integration with OBM, vROps, and other monitoring platforms * Metrics, topology, and violation data synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows New Relic APM to participate in enterprise-grade ITOM, observability, and monitoring ecosystems without requiring custom development. # Nutanix Connect Nutanix to ZigiOps. Supported from version 5.x, basic auth setup, and templates for syncing Nutanix alerts, metrics, and topology with OBM. ### What is Nutanix Integration in ZigiOps? Nutanix is a hyperconverged infrastructure (HCI) platform used for cloud computing, virtualization, and enterprise storage management across on-premises and hybrid cloud environments. ZigiOps enables secure, API-based integration between Nutanix and ITSM, ITOM, and monitoring platforms. Using ZigiOps, alerts, metrics, and topology data from Nutanix can be synchronized with external systems to support automated incident management and infrastructure visibility workflows. With ZigiOps, Nutanix can: * Forward infrastructure alerts to operations management platforms such as OBM * Synchronize cluster and node topology data with infrastructure monitoring tools * Feed performance metrics into centralized monitoring and capacity planning platforms * Participate in automated incident creation workflows triggered by infrastructure events The integration is fully customizable and does not require custom scripts or plugins. ### Which Nutanix Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Nutanix | All | 5.x (or newer) | ### Are There Any Environmental Prerequisites for Nutanix? There are no environmental prerequisites for this product. ### How Do I Connect Nutanix to ZigiOps? #### Nutanix - Connected System Configuration Follow the steps below to add your Nutanix instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Nutanix** {% endstep %} {% step %} Configure the Nutanix parameters Configure the following parameters: * **Server URL** - Input the URL of your Nutanix instance. For example, `https://nutanix.example.com:9440` * **Username** - Input your Nutanix username. * **Password** - Input the password for the above user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, Nutanix becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What Are the Most Common Nutanix Integration Use Cases? #### Use Case 1: Nutanix Alert Forwarding to OBM Infrastructure alerts generated by Nutanix, including cluster failures, storage warnings, and performance threshold breaches, can be forwarded to OBM as structured events. Operations teams can correlate and act on Nutanix alerts alongside data from other infrastructure platforms. #### Use Case 2: Topology Data Synchronization with OBM Nutanix cluster and node topology data can be synchronized with OBM, keeping the operations platform's configuration model up to date with the actual state of the Nutanix HCI environment. #### Use Case 3: Metrics Ingestion into Monitoring Platforms Nutanix performance metrics can be forwarded to centralized monitoring platforms, enabling infrastructure teams to track capacity utilization and performance trends across their hyperconverged environment. ### What Integration Templates Are Available for Nutanix? ZigiOps provides the following integration templates for Nutanix: * Nutanix alerts to OBM events * Nutanix metrics to OBM metrics * Nutanix topology to OBM topology Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules For detailed information about available templates for Nutanix integrations, please contact: \ **Email:** ### Summary The Nutanix integration in ZigiOps enables: * Secure, username/password-based API connectivity * Support for Nutanix 5.x and newer * Integration with OBM and other monitoring platforms * Alerts, metrics, and topology synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Nutanix to participate in enterprise-grade ITOM and infrastructure monitoring ecosystems without requiring custom development. # OpenAI Connect OpenAI to ZigiOps. API key setup, model configuration, connected system steps, and how to expose enterprise systems to AI models via ZigiOps. ### What is OpenAI Integration in ZigiOps? OpenAI is an AI research and deployment platform providing access to large language models (LLMs) such as GPT-4 via a REST API. These models can process, generate, and act on natural language inputs at enterprise scale. ZigiOps enables secure, API-based integration between OpenAI and enterprise systems including ITSM, DevOps, and monitoring platforms. Using ZigiOps, enterprise system data can be exposed to OpenAI models to support AI-driven automation, summarization, and decision support workflows. With ZigiOps, OpenAI can: * Receive structured data from ITSM and monitoring tools for AI-assisted triage and summarization * Generate automated responses, recommendations, or documentation from incident and event data * Participate in AI-augmented workflows that combine enterprise system context with LLM capabilities * Support MCP-based exposure of connected systems directly to AI models The integration is fully customizable and does not require custom scripts or plugins. ### Which OpenAI Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | OpenAI | All | All | > **Note:** Due to the dynamic nature of available OpenAI models, you may need to update the default model used by ZigiOps. The current default is `gpt-4`. To change the model, go to **ZigiOps > Systems**, select your OpenAI instance, click **Dots > Advanced Settings**, enter the desired Model ID, and click **Apply**. Refer to the OpenAI Platform documentation for a current list of available Model IDs. ### Are There Any Environmental Prerequisites for OpenAI? **System Requirements:** * An active OpenAI Platform account with API access enabled * A Service Account API key generated for the ZigiOps integration **Network and Connectivity Requirements:** * HTTPS access to the OpenAI API endpoint (`https://api.openai.com`) * Outbound connectivity from ZigiOps to the OpenAI API ### How Do I Generate an API Key in OpenAI? {% stepper %} {% step %} Log in to the OpenAI Platform. {% endstep %} {% step %} Navigate to the **API Keys** section and click **Create new secret key**. {% endstep %} {% step %} Configure the new key as follows: * **Service Account ID** - Enter a suitable name, such as `zigiops`. * **Project** - Select the desired project. {% endstep %} {% step %} Click **Create secret key** to generate the key. {% endstep %} {% endstepper %} {% hint style="warning" %} **Important:** Save the key immediately. For security reasons, the key cannot be viewed again after creation. If lost, a new key must be generated. {% endhint %} ### How Do I Connect OpenAI to ZigiOps? #### OpenAI - Connected System Configuration Follow the steps below to add your OpenAI instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > OpenAI** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the OpenAI API URL: `https://api.openai.com` * **API Key** - Input the API Key generated in the prerequisites step. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, OpenAI becomes available for use in ZigiOps integration templates. ### What Are the Most Common OpenAI Integration Use Cases? #### Use Case 1: AI-Assisted Incident Summarization ZigiOps can forward incident records from ITSM platforms to OpenAI for automated summarization, root cause analysis suggestions, or resolution recommendations, reducing mean time to resolution for operations teams. #### Use Case 2: AI-Augmented Alert Enrichment Raw monitoring alerts forwarded through ZigiOps can be enriched with AI-generated context before reaching ITSM or notification platforms, helping on-call engineers understand impact and urgency without manual investigation. #### Use Case 3: Enterprise System Exposure via MCP ZigiOps supports the Model Context Protocol (MCP), allowing connected enterprise systems to be exposed directly to OpenAI models. This enables AI models to read from and act on live enterprise data within governed, auditable workflows. ### What Integration Templates Are Available for OpenAI? ZigiOps integration templates for OpenAI are available depending on the paired system and use case. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The OpenAI integration in ZigiOps enables: * Secure, API key-based connectivity to OpenAI models * Support for all OpenAI API deployment types * AI-assisted automation within enterprise ITSM and monitoring workflows * MCP-based exposure of connected enterprise systems to LLMs * Configurable model selection via Advanced Settings * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows OpenAI to participate in enterprise-grade AI automation, ITSM, and observability ecosystems without requiring custom development. # Operations Agent (OA) Connect Operations Agent (OA) to ZigiOps. Supported versions, policy configuration, and connected system setup. ### What is Operations Agent integration in ZigiOps? Operations Agent (OA), also known as Operations Connector, is an HP / Micro Focus agent used to collect and forward events, metrics, and topology data to Operations Bridge Manager (OBM). It acts as a bridge between monitored systems and the OBM platform. ZigiOps enables secure, agentless integration with Operations Agent, allowing events, metrics, and topology data from a wide range of monitoring and APM tools to be forwarded into OBM through the OA REST Web Service Listener. With ZigiOps, Operations Agent can: * Receive events and metrics from external monitoring tools such as Datadog, Dynatrace, and SolarWinds * Forward topology data from APM and cloud platforms into OBM * Serve as a data relay for multi-source AIOps workflows * Integrate without custom scripts or additional connectors ### Which Operations Agent versions are supported? Using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------------------------------- | -------------------------- | ------------------ | | Operations Agent / Operations Connector | All | 12.x or newer | ### Are there any environmental prerequisites for Operations Agent? {% hint style="info" %} *Note: Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites.* See the Related Templates section at the end of this page. {% endhint %} ### How do I import and assign REST Web Service Listener policies? Before configuring Operations Agent as a connected system in ZigiOps, you must import and assign the ZigiOps policy content pack to your OBM instance. 1. **Download the ZigiOps Policies Content Pack** from: * 2. Sign in to your OBM instance using an account with sufficient administrative permissions. 3. **Go to Administration → Setup and Maintenance → Content Packs,** click the Import button, and select the content pack file. 4. **Go to Administration → Monitoring → Policy Templates,** select the ZigiOps Policies template group, choose one of the policies, and click the Assign and Deploy button. 5. Select the desired instance or instances and click the Assign button to assign the policy. Repeat steps 4 and 5 for each remaining policy in the content pack. ### How do I connect Operations Agent to ZigiOps? #### Operations Agent - Connected System Configuration Follow the steps below to add Operations Agent as a connected system in ZigiOps. 1. Log in to your ZigiOps instance. 2. **Navigate to Connected Systems → Add New System → Operations Agent** and configure the following parameters: * **Server URL:** Input the URL of your OA instance followed by the default listener port (30005 by default). Example: . * **Policy Path:** Input the path of the REST Web Service Listener policies. The default value is zigiwave. * **Authentication Type:** Select the desired authentication type that ZigiOps will use to authenticate against the OA. The default is No Auth. * **Proxy Settings (optional):** Enable this option if a proxy server is required for outbound communication. 3. Review the configuration. 4. **Click Save** to store the connected system. Once saved, Operations Agent becomes available for use in ZigiOps integration templates. ### What integration templates are available for Operations Agent? #### Related Templates The following prebuilt templates are available for Operations Agent: * AppDynamics application metrics to OBM metrics * AppDynamics events to OBM events * AppDynamics node metrics to OBM metrics * AppDynamics topology to OBM topology * AppDynamics violations to OBM events * Azure Monitor alerts to OBM events * Azure Monitor VM metrics to OBM metrics * Azure Monitor VM topology to OBM topology * Azure Monitor webhook alerts to OBM events * CA UIM alarms to OBM events * CA UIM computer systems topology to OBM topology * CA UIM metrics to OBM metrics * Datadog events to OBM events * Datadog host topology to OBM topology * Datadog metrics to OBM metrics * Dynatrace application topology to OBM topology * Dynatrace host topology to OBM topology * Dynatrace listener problems to OBM events * Dynatrace metrics to OBM metrics * Dynatrace polling problems to OBM events * Foglight alarms to OBM events * Icinga hostgroups topology to OBM topology * Icinga hosts topology to OBM topology * Icinga metrics to OBM metrics * Icinga service status problems to OBM events * New Relic APM application host metrics to OBM metrics * New Relic APM application metrics to OBM metrics * New Relic APM application topology to OBM topology * New Relic APM violations to OBM events * Nutanix alerts to OBM events * Nutanix metrics to OBM metrics * Nutanix topology to OBM topology * Prometheus alerts to OBM events * Prometheus endpoints topology to OBM topology * Prometheus events to OBM events (OA) * Prometheus memstat metrics to OBM metrics * Prometheus node topology to OBM topology * Prometheus process CPU metrics to OBM metrics * SAP SolMan alerts to OBM events (OA) * SAP SolMan topology to OBM topology (OA) * SolarWinds alerts to OBM events * SolarWinds cluster metrics to OBM metrics * SolarWinds CPU and memory metrics to OBM metrics * SolarWinds DPA topology to OBM topology * SolarWinds events to OBM events * SolarWinds host and ESXi metrics to OBM metrics * SolarWinds NPM topology to OBM topology * SolarWinds SAM topology to OBM topology * SolarWinds VIM topology to OBM topology * SolarWinds VM metrics to OBM metrics * SolarWinds VMW topology to OBM topology * Splunk Enterprise alerts to OBM events * Splunk Enterprise events to OBM events * vROps alerts to OBM events * vROps Linux topology to OBM topology * vROps metrics to OBM metrics * vROps topology to OBM topology * vROps Windows topology to OBM topology * Zabbix trigger events to OBM events Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template information. ### Summary The Operations Agent integration in ZigiOps provides: * Secure, agentless integration with Operations Agent 12.x or newer * Support for all deployment types * Policy-based REST Web Service Listener configuration * Flexible authentication and proxy support * Extensive library of prebuilt templates for AIOps and monitoring workflows # Operations Bridge Manager (OBM) Connect OBM to ZigiOps. Connected Server setup, Event Forwarding rules, connected system configuration, and templates for ITSM and monitoring integrations. ### What is OBM Integration in ZigiOps? Operations Bridge Manager (OBM) is an IT operations management platform used for event correlation, topology-aware monitoring, and service-centric operations across hybrid IT environments. ZigiOps enables secure, API-based integration between OBM and ITSM, DevOps, and other monitoring platforms. Using ZigiOps, events, topology data, and operational alerts from OBM can be synchronized with external systems to support automated incident management and cross-platform operations workflows. With ZigiOps, OBM can: * Forward correlated events to ITSM platforms such as ServiceNow, Jira, Remedy, and Cherwell * Receive topology and infrastructure data from monitoring tools for enrichment * Participate in bi-directional event and incident workflows with ITSM systems * Support downtime and RTSM-based configuration management integrations The integration is fully customizable and does not require custom scripts or plugins. ### Which OBM Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------------------------- | -------------------------- | ------------------ | | Operations Bridge Manager (OBM) | Server | 10.x (or newer) | {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} ### How Do I Create a Connected Server in OBM? A Connected Server must be created in OBM before ZigiOps can receive events from it. {% stepper %} {% step %} Access the Connected Servers page Access the OBM web console and navigate to: **Administration > Setup and Maintenance > Connected Servers** {% endstep %} {% step %} Create an External Event Processing Connected Server Create a new Connected Server of type **External Event Processing** and configure the following: **General:** * **Display Label** - Enter a display label to identify this connected server. * **Identifier** - The Connected Server username ZigiOps uses to authenticate against OBM. Accept the default or enter a valid value. **Server Properties:** * **Fully Qualified Domain Name** - The FQDN or IP of the ZigiOps server, which OBM uses to send event data. * **CI Type** - The CI Type OBM creates in RTSM for this connected server. Select **Management System** if unsure. * **Delivery Options** - Accept the default unless advised otherwise by an OBM administrator. **Integration Type:** * **Type** - Select **Call External Event Web Service**. * **URL Path** - Enter `/listener/omi` unless specified otherwise in the ZigiOps template settings. * **Supports Bulk Transfer** - Enable if bulk transfer of events is required. Check the ZigiOps template for a BULK action name before enabling. **Outgoing Connection:** * **Username** - Enter `notused` (OBM requires a value but ZigiOps does not use it). * **Password** - Enter `notused` (same reason as above). * **Port** - Enter the ZigiOps listener port as specified in the corresponding ZigiOps template. * **Transfer Control** - Enable this option to allow event transfer through this connected server. **Incoming Connection:** * **Password** - The password ZigiOps uses to authenticate against OBM for backward synchronization. {% endstep %} {% endstepper %} ### How Do I Create an Event Forwarding Rule in OBM? Event Forwarding rules define which OBM events are automatically sent to ZigiOps and connected ITSM platforms. {% stepper %} {% step %} Log in and open Event Forwarding Log in to the OBM web console. Navigate to: **Administration > Event Processing > Automation > Event Forwarding** and click **New**. {% endstep %} {% step %} Configure the forwarding rule Configure the forwarding rule: * **Display Name** - A descriptive name to identify this rule. * **Event Filter** - The condition criteria that events must match to be forwarded. * **Target Servers** - The connected server to which the rule forwards events. Set the forwarding type to **Synchronize and Transfer Control**. {% endstep %} {% step %} Save the rule Click **Create** to save the Event Forwarding rule. {% endstep %} {% endstepper %} ### How Do I Connect OBM to ZigiOps? #### OBM - Connected System Configuration Follow the steps below to add your OBM instance as a connected system. {% stepper %} {% step %} Open the OpsBridge system setup Log into your ZigiOps instance. Navigate to: **Connected Systems > Add New System > OpsBridge** {% endstep %} {% step %} Configure the connection parameters Configure the following parameters: * **Server URL** - Input the URL of your OBM instance. For example, `https://obm.example.com` * **Username** - Input your Connected Server username (required for event integrations). * **Password** - Input the password for the above user (required for event integrations). * **Downtime Service Username** - Input an OBM Downtime Service username (required for downtime integrations). * **Downtime Service Password** - Input the password for the Downtime Service username (required for downtime integrations). * **RTSM Username** - Input an OBM RTSM username (required for downtime or uCMDB integrations). * **RTSM Password** - Input the password for the RTSM username (required for downtime or uCMDB integrations). * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, OBM becomes available for use in ZigiOps integration templates. ### What Are the Most Common OBM Integration Use Cases? #### Use Case 1: OBM Event Forwarding to ITSM Correlated OBM events can be automatically forwarded to ITSM platforms including ServiceNow, Jira, Remedy, Cherwell, Ivanti, and Zendesk. ZigiOps maps event fields to the target system's incident schema, ensuring full context is preserved. #### Use Case 2: Bi-Directional ITSM and OBM Synchronization When an ITSM incident linked to an OBM event is updated or resolved, ZigiOps synchronizes the status change back to OBM, keeping event ownership and lifecycle state consistent across both platforms. #### Use Case 3: Topology Data Ingestion from Monitoring Tools ZigiOps can forward topology and infrastructure data from monitoring tools such as SAP SolMan into OBM, keeping the OBM topology model up to date without manual configuration. ### What Integration Templates Are Available for OBM? ZigiOps provides the following integration templates for OBM: * OBM events to Cherwell incidents * OBM events to Ivanti incidents * OBM events to Jira tasks * OBM events to Remedy incidents * OBM events to Remedy problems * OBM events to ServiceNow incidents * OBM events to ServiceNow incidents (Staging Table) * OBM events to Zendesk tickets * SAP SolMan Alerts to OBM Events Backsync Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template information. ### Summary The OBM integration in ZigiOps enables: * Secure, Connected Server-based event integration * Support for OBM 10.x and newer (Server deployment) * Integration with ITSM, DevOps, and other monitoring platforms * Event forwarding, bi-directional sync, and topology data exchange * Configurable downtime and RTSM-based integration options * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows OBM to participate in enterprise-grade ITSM, ITOM, and automation ecosystems without requiring custom development. # Optic Data Lake (ODL) Connect Optic Data Lake to ZigiOps. Retention profile imports for AppDynamics, Datadog, Dynatrace, New Relic, and SolarWinds, plus connected system configuration. ### What is Optic Data Lake integration in ZigiOps? Optic Data Lake (ODL) is a data management and analytics platform used to store, retain, and query large volumes of metrics and topology data from enterprise monitoring tools. ZigiOps enables secure, API-based integration between Optic Data Lake and monitoring, APM, and infrastructure management platforms. Using ZigiOps, metrics, topology, and performance data from tools such as AppDynamics, Datadog, Dynatrace, New Relic, and SolarWinds can be ingested into ODL for long-term retention and analytics. With ZigiOps, Optic Data Lake can: * Receive and store metrics and topology data from multiple monitoring platforms * Support retention profile-based data management for raw, hourly, and daily aggregations * Provide a centralized analytics layer for cross-platform operational data * Enable historical trend analysis and capacity planning across hybrid environments The integration is fully customizable and does not require custom scripts or plugins. ### Which Optic Data Lake versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------- | -------------------------- | ------------------ | | Optic Data Lake | All | All | ### Are there any environmental prerequisites for Optic Data Lake? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} Before configuring the ZigiOps connected system, the appropriate retention profiles and datasets must be imported into Vertica for each monitoring tool you plan to integrate. Download the Optic Data Lake datasets and retention profiles from: `https://download.zigiwave.com/zigiops/opticdl/opticdl_datasets_ret_profiles_v1_2024-01-16.zip` Follow the OPTIC DL documentation for the import procedure (Product: OPTIC Data Lake, Service: OPTICDL Open Data Ingestion Administration API V3). #### AppDynamics retention profiles and datasets Unzip the archive and locate the `AppDynamics_ret_prof` folder. Import the following retention profiles: * `appdynamics_retention_raw.json` * `appdynamics_retention_hourly.json` * `appdynamics_retention_daily.json` Import the following datasets: * **AppDynamics\_application\_set:** `appdynamics_application_task_flow.json` and associated raw/1h/1d files * **AppDynamics\_node\_set:** `appdynamics_node_task_flow.json` and associated raw/1h/1d files #### Datadog retention profiles and datasets Locate the `DataDog_ret_profiles` folder and import: * `datadog_retention_raw.json` * `datadog_retention_hourly.json` * `datadog_retention_daily.json` * **DataDog\_host\_set:** `datadog_host_task_flow.json` and associated raw/1h/1d files #### Dynatrace retention profiles and datasets Locate the `Dynatrace_ret_profiles` folder and import: * `dynatrace_retention_raw.json` * `dynatrace_retention_hourly.json` * `dynatrace_retention_daily.json` Import the following datasets: `Dynatrace_app_bowser_set`, `Dynatrace_app_user_type_set`, `Dynatrace_disk_set`, `Dynatrace_host_set`, `Dynatrace_network_set`, `Dynatrace_service_set` (each with corresponding `task_flow.json` and raw/1h/1d files). #### New Relic retention profiles and datasets Locate the `NewRelic_ret_prof` folder and import: * `newrelic_retention_raw.json` * `newrelic_retention_hourly.json` * `newrelic_retention_daily.json` * **NewRelic\_app\_set** and **NewRelic\_host\_set** with corresponding `task_flow.json` and raw/1h/1d files #### SolarWinds retention profiles and datasets Locate the `Solarwinds_ret_profiles` folder and import: * `solarwinds_retention_raw.json` * `solarwinds_retention_hourly.json` * `solarwinds_retention_daily.json` Import the following datasets: `Solarwinds_cluster_set`, `Solarwinds_esxi_set`, `Solarwinds_host_set`, `Solarwinds_vm_set` (each with corresponding `task_flow.json` and raw/1h/1d files). ### How do I connect Optic Data Lake to ZigiOps? #### Optic Data Lake - Connected System Configuration Follow the steps below to add your Optic Data Lake instance as a connected system. 1. Log into your ZigiOps instance. 2. Navigate to: **Connected Systems > Add New System > Optic DL** 3. Configure the following parameters: * **URL** - Input the URL of your Optic DL instance. For example, `https://opticdl.example.com` * **Username** - The username ZigiOps uses to authenticate and obtain a token from the OPTIC DL API. * **Password** - The password ZigiOps uses to authenticate against the OPTIC DL API. * **Tenant Name** - The name of the Micro Focus OPTIC DL tenant. * **Proxy Settings** - Enables the usage of a proxy server. 4. Examine the settings and if they are correct, click the **Save** button to store the system. 5. Once saved, Optic Data Lake becomes available for use in ZigiOps integration templates. ### What are the most common Optic Data Lake integration use cases? #### Use case 1: Metrics ingestion from APM tools ZigiOps forwards application and host metrics from tools like AppDynamics, New Relic, and Dynatrace into ODL, where they are stored according to defined retention profiles for reporting and trend analysis. #### Use case 2: Topology data storage from monitoring platforms Infrastructure topology data from SolarWinds and other monitoring tools can be ingested into ODL via ZigiOps, providing a persistent, queryable record of the infrastructure landscape over time. #### Use case 3: Centralized long-term data retention for multi-tool environments Organizations running multiple monitoring platforms can use ZigiOps to funnel all operational data into ODL under a consistent retention schema, enabling cross-platform analytics without custom ETL pipelines. ### What integration templates are available for Optic Data Lake? ZigiOps integration templates for Optic Data Lake are available depending on the paired monitoring system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Please contact for detailed template availability. ### Summary The Optic Data Lake integration in ZigiOps enables: * Secure, token-based API connectivity * Support for all ODL deployment types * Metrics and topology data ingestion from AppDynamics, Datadog, Dynatrace, New Relic, and SolarWinds * Retention profile-based data management in Vertica * Optional proxy configuration * Fully customizable data forwarding workflows ZigiOps allows Optic Data Lake to serve as a centralized data retention layer for enterprise monitoring ecosystems without requiring custom development. # Oracle Enterprise Manager (OEM) Connect Oracle Enterprise Manager to ZigiOps. Database connection setup, host, schema, and port configuration, and integration templates for OEM workflows. ### What is Oracle Enterprise Manager Integration in ZigiOps? Oracle Enterprise Manager (OEM) is an enterprise IT management platform used for monitoring, managing, and automating Oracle databases, middleware, and cloud infrastructure environments. ZigiOps enables secure, database-level integration between Oracle Enterprise Manager and ITSM, monitoring, and operations platforms. Using ZigiOps, alerts, incidents, and infrastructure data from OEM can be synchronized with external systems to support automated incident management and cross-platform visibility. With ZigiOps, Oracle Enterprise Manager can: * Forward database and infrastructure alerts to ITSM platforms for automated incident creation * Synchronize Oracle environment health data with operations management platforms * Participate in automated escalation and notification workflows across IT and DBA teams * Support bi-directional data exchange between Oracle management and enterprise ticketing systems The integration is fully customizable and does not require custom scripts or plugins. ### Which Oracle Enterprise Manager Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------------------------- | -------------------------- | ------------------ | | Oracle Enterprise Manager (OEM) | All | All | ### Are There Any Environmental Prerequisites for Oracle Enterprise Manager? There are no environmental prerequisites for this product. ### How Do I Connect Oracle Enterprise Manager to ZigiOps? #### Oracle Enterprise Manager - Connected System Configuration Follow the steps below to add your Oracle Enterprise Manager instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Oracle Enterprise Manager** {% endstep %} {% step %} Configure the following parameters: * **Host** - The IP address, hostname, or FQDN of the Oracle database server. For example, `oem.example.com` * **Database Name** - The name of the database on the server. * **Port** - The TCP connection port. For example, `1521` * **Schema** - The Oracle schema name used for the integration. * **Username** - The database user used for the connection. * **Password** - The password for the database user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, Oracle Enterprise Manager becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What Are the Most Common Oracle Enterprise Manager Integration Use Cases? #### Use Case 1: Database Alert Forwarding to ITSM Oracle database alerts and threshold breaches detected by OEM can be forwarded to ITSM platforms, automatically creating incidents for DBA and operations teams with full alert context and severity information. #### Use Case 2: Infrastructure Monitoring Event Synchronization OEM infrastructure and middleware health events can be synchronized with centralized operations platforms, giving IT operations teams a unified view of Oracle environment health alongside data from other infrastructure tools. #### Use Case 3: Automated DBA and IT Operations Workflows ZigiOps can bridge Oracle management events with DevOps tools and notification platforms, enabling automated escalation paths that route Oracle incidents to the correct team without manual intervention. ### What Integration Templates Are Available for Oracle Enterprise Manager? ZigiOps integration templates for Oracle Enterprise Manager are available depending on the paired system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Oracle Enterprise Manager integration in ZigiOps enables: * Secure, database-level connectivity using host, schema, and credentials * Support for all OEM deployment types * Integration with ITSM, monitoring, and operations platforms * Alert and infrastructure data synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Oracle Enterprise Manager to participate in enterprise-grade ITSM, ITOM, and automation ecosystems without requiring custom development. # PagerDuty Connect PagerDuty to ZigiOps. API key generation, connected system setup, and templates for syncing PagerDuty incidents with Jira and other ITSM platforms. ### What is PagerDuty Integration in ZigiOps? PagerDuty is an incident management and digital operations platform used for real-time alerting, on-call scheduling, and incident response coordination across DevOps and IT operations teams. ZigiOps enables secure, API-based integration between PagerDuty and ITSM, DevOps, and monitoring platforms. Using ZigiOps, incidents and alerts from PagerDuty can be synchronized with external systems to support automated escalation, ticket creation, and cross-team incident workflows. With ZigiOps, PagerDuty can: * Forward incidents to ITSM platforms such as Jira and ServiceNow for structured ticket management * Participate in bi-directional workflows where ITSM resolution updates are reflected in PagerDuty * Trigger automated escalation paths based on incident severity and on-call schedules * Integrate with monitoring platforms for end-to-end alert-to-incident lifecycle management The integration is fully customizable and does not require custom scripts or plugins. ### Which PagerDuty Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------- | -------------------------- | ------------------ | | PagerDuty | All | All | ### Are There Any Environmental Prerequisites for PagerDuty? > **Note:** Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. #### How Do I Create an API Token in PagerDuty? 1. Sign in to your PagerDuty instance. For example, `https://example.eu.pagerduty.com` 2. Navigate to: **Integrations > API Access Keys** 3. Click **Create New API Key**, enter a suitable description, and click **Create Key**. > **Important:** Store the API token securely. It is only visible at the time of creation. ### How Do I Connect PagerDuty to ZigiOps? #### PagerDuty - Connected System Configuration Follow the steps below to add your PagerDuty instance as a connected system. 1. Log into your ZigiOps instance. 2. Navigate to: **Connected Systems > Add New System > PagerDuty** 3. Configure the following parameters: * **Server URL** - Input the PagerDuty API URL. For example, `https://api.pagerduty.com` * **API Token** - Input a valid, active PagerDuty API key. * **Proxy Settings** - Enables the usage of a proxy server. 4. Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, PagerDuty becomes available for use in ZigiOps integration templates. ### What Are the Most Common PagerDuty Integration Use Cases? #### Use Case 1: PagerDuty Incident Escalation to Jira When a PagerDuty incident is created or escalated, ZigiOps can automatically create a corresponding Jira task with incident details, severity, and on-call assignee information. Development and operations teams can manage remediation in Jira while PagerDuty retains the incident timeline. #### Use Case 2: Bi-Directional Sync Between PagerDuty and ITSM PagerDuty incidents can be mirrored as ServiceNow or Jira tickets, with status updates flowing in both directions. When an incident is resolved in the ITSM tool, ZigiOps updates the corresponding PagerDuty incident, maintaining consistency across both platforms. #### Use Case 3: Alert-to-Incident Lifecycle Management Alerts from monitoring platforms forwarded through ZigiOps can trigger PagerDuty incidents, ensuring that the full alert-to-resolution lifecycle is captured across monitoring, on-call management, and ITSM systems. ### What Integration Templates Are Available for PagerDuty? ZigiOps provides the following integration templates for PagerDuty: * PagerDuty incidents to Jira tasks Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The PagerDuty integration in ZigiOps enables: * Secure, API token-based connectivity * Support for all PagerDuty deployment types * Integration with Jira, ServiceNow, and other ITSM platforms * Incident forwarding and bi-directional status synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows PagerDuty to participate in enterprise-grade ITSM, DevOps, and incident management ecosystems without requiring custom development. # Prometheus Connect Prometheus to ZigiOps. Simple URL-based setup and templates for forwarding Prometheus alerts, events, metrics, and topology to OBM. ### What is Prometheus Integration in ZigiOps? Prometheus is an open-source systems monitoring and alerting toolkit designed for reliability and scalability in cloud-native and hybrid infrastructure environments. ZigiOps enables secure, API-based integration between Prometheus and ITSM and operations management platforms. Using ZigiOps, Prometheus alerts, events, metrics, and topology data can be synchronized with external systems to support automated incident management and centralized monitoring workflows. With ZigiOps, Prometheus can: * Forward alerts and events to operations management platforms such as OBM * Synchronize endpoint and node topology data with infrastructure management tools * Feed performance metrics into centralized monitoring and capacity planning platforms * Participate in automated incident creation workflows triggered by alert threshold breaches The integration is fully customizable and does not require custom scripts or plugins. ### Which Prometheus Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------- | -------------------------- | ------------------ | | Prometheus | All | All | ### Are There Any Environmental Prerequisites for Prometheus? There are no environmental prerequisites for this product. ### How Do I Connect Prometheus to ZigiOps? #### Prometheus - Connected System Configuration {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Prometheus** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of your Prometheus instance. For example, `https://prometheus.example.com:9090` * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Prometheus becomes available for use in ZigiOps integration templates. ### What Are the Most Common Prometheus Integration Use Cases? #### Use Case 1: Prometheus Alert Forwarding to OBM Prometheus alerting rules that fire on threshold breaches can be forwarded by ZigiOps to OBM as structured events, enabling centralized event correlation and incident management alongside data from other monitoring sources. #### Use Case 2: Endpoint and Node Topology Synchronization Prometheus endpoint and node topology data can be synchronized with OBM, keeping the operations platform's topology model aligned with the actual state of monitored infrastructure. #### Use Case 3: Metrics Ingestion for Capacity Planning Memory, CPU, and process metrics collected by Prometheus can be forwarded to centralized monitoring platforms, enabling infrastructure teams to perform capacity planning and trend analysis from a single data source. ### What Integration Templates Are Available for Prometheus? ZigiOps provides the following integration templates for Prometheus: * Prometheus alerts to OBM events * Prometheus endpoints topology to OBM topology * Prometheus events to OBM events (OA) * Prometheus memstat metrics to OBM metrics * Prometheus node topology to OBM topology * Prometheus process CPU metrics to OBM metrics Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Prometheus integration in ZigiOps enables: * Simple, URL-based API connectivity with no authentication credentials required * Support for all Prometheus deployment types * Integration with OBM and other monitoring and operations platforms * Alert, event, metrics, and topology data synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Prometheus to participate in enterprise-grade ITOM and infrastructure monitoring ecosystems without requiring custom development. # Remedy Connect BMC Remedy to ZigiOps. Supported from version 9.1.x, REST API-based setup, connected system configuration, and templates for ITSM and DevOps integrations. ### What is BMC Remedy Integration in ZigiOps? BMC Remedy (also known as BMC Helix ITSM) is an enterprise IT service management platform used for incident, problem, change, and work order management across large and complex IT environments. ZigiOps enables secure, REST API-based integration between BMC Remedy and ITSM, DevOps, and monitoring platforms. Using ZigiOps, incidents, problems, change requests, and work orders from Remedy can be synchronized with external systems to support automated cross-team workflows and end-to-end ITSM automation. With ZigiOps, BMC Remedy can: * Sync incidents and problems with DevOps tools such as Jira and Azure DevOps * Receive alerts and events from monitoring platforms as Remedy incidents * Participate in bi-directional workflows between Remedy and other ITSM platforms * Support change request and work order synchronization across team boundaries The integration is fully customizable and does not require custom scripts or plugins. ### Which BMC Remedy Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Remedy | All | 9.1.x (or newer) | ### Are There Any Environmental Prerequisites for BMC Remedy? There are no environmental prerequisites for this product. ### How Do I Connect BMC Remedy to ZigiOps? #### BMC Remedy - Connected System Configuration Follow the steps below to add your BMC Remedy instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Remedy** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of your Remedy instance. For example, `https://remedy.example.com:8443` * **Username** - Input your Remedy username. * **Password** - Input the password for the above user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} > **Note:** ZigiOps integrates with BMC Remedy using its REST API service. Once saved, BMC Remedy becomes available for use in ZigiOps integration templates. ### What Are the Most Common BMC Remedy Integration Use Cases? #### Use Case 1: Bi-Directional Incident Sync Between Remedy and Jira Remedy incidents can be automatically mirrored as Jira tasks, with status, priority, and comment updates flowing in both directions. Development teams work in Jira while ITSM teams manage the full incident lifecycle in Remedy. #### Use Case 2: Monitoring Alert Escalation to Remedy Alerts from monitoring tools such as OBM and AppDynamics can be forwarded to Remedy as incidents, ensuring that infrastructure events are captured in the ITSM system for tracking and SLA management. #### Use Case 3: Change Request and Work Order Synchronization Remedy change requests and work orders can be synchronized with external DevOps or project management tools, enabling IT operations and engineering teams to coordinate work without leaving their native platforms. ### What Integration Templates Are Available for BMC Remedy? ZigiOps provides the following integration templates for BMC Remedy: * AppDynamics violations to Remedy incidents * Azure DevOps work items to Remedy incidents * Jira tasks to Remedy incidents * Jira tasks to Remedy problems * OBM events to Remedy incidents * OBM events to Remedy problems * Remedy change requests to Jira tasks * Remedy incidents to Jira tasks * Remedy problems to Azure DevOps work items * Remedy problems to Jira tasks * Remedy work orders to Jira tasks Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The BMC Remedy integration in ZigiOps enables: * Secure, REST API-based connectivity * Support for Remedy 9.1.x and newer * Integration with Jira, Azure DevOps, OBM, AppDynamics, and other platforms * Bi-directional incident, problem, change request, and work order synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows BMC Remedy to participate in enterprise-grade ITSM, DevOps, and automation ecosystems without requiring custom development. # Remedyforce Connect BMC Remedyforce to ZigiOps. OAuth Consumer Key and Secret setup, connected system configuration, and available integration templates. ### What is Remedyforce Integration in ZigiOps? BMC Remedyforce is a cloud-based IT service management platform built on the Salesforce platform, used for incident, problem, change, and service request management in enterprise environments. ZigiOps enables secure, OAuth-based integration between Remedyforce and ITSM, DevOps, and monitoring platforms. Using ZigiOps, tickets and service records from Remedyforce can be synchronized with external systems to support automated cross-team workflows. With ZigiOps, Remedyforce can: * Sync service tickets and incidents with DevOps and monitoring platforms * Participate in bi-directional workflows with ITSM tools such as Jira and ServiceNow * Receive alerts and events from monitoring platforms as Remedyforce records * Support end-to-end ITSM automation across cloud and on-premises systems The integration is fully customizable and does not require custom scripts or plugins. ### Which Remedyforce Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ----------- | -------------------------- | ------------------ | | Remedyforce | Cloud | All | ### Are There Any Environmental Prerequisites for Remedyforce? > **Note:** Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. #### How Do I Create a Consumer Key and Consumer Secret in Remedyforce? 1. Log into your Remedyforce instance. 2. Navigate to: **Setup > App Manager** 3. Click the **View** button for the desired application. 4. The **Consumer Key** and **Consumer Secret** are available in the Manage Application menu. ### How Do I Connect Remedyforce to ZigiOps? #### Remedyforce - Connected System Configuration Follow the steps below to add your Remedyforce instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Remedyforce** {% endstep %} {% step %} Configure the following parameters: * **URL** - Input the URL of your Remedyforce instance. For example, `https://example.my.salesforce.com` * **Username** - Input your Remedyforce username. * **Password** - Input the password for the above user. * **Consumer Key** - Input the Consumer Key from your Salesforce App Manager. * **Consumer Secret** - Input the Consumer Secret from your Salesforce App Manager. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, Remedyforce becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What Are the Most Common Remedyforce Integration Use Cases? #### Use Case 1: Incident and Ticket Synchronization with DevOps Tools Remedyforce service tickets can be synchronized with Jira or Azure DevOps, enabling development teams to track and resolve IT service incidents from within their native DevOps environment while ITSM teams manage the full lifecycle in Remedyforce. #### Use Case 2: Monitoring Alert Escalation to Remedyforce Alerts from monitoring platforms can be forwarded through ZigiOps to Remedyforce as structured tickets, capturing infrastructure events in the service management system for triage, assignment, and SLA tracking. #### Use Case 3: Cross-Platform ITSM Automation Remedyforce can be connected to other ITSM platforms to enable automated escalation, routing, and resolution workflows that span multiple service management systems without requiring manual hand-offs. ### What Integration Templates Are Available for Remedyforce? ZigiOps provides integration templates for Remedyforce depending on the paired system. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Remedyforce integration in ZigiOps enables: * Secure, OAuth-based connectivity using Consumer Key and Consumer Secret * Support for cloud-based Remedyforce deployments * Integration with ITSM, DevOps, and monitoring platforms * Ticket and incident synchronization workflows * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Remedyforce to participate in enterprise-grade ITSM, DevOps, and automation ecosystems without requiring custom development. # Salesforce Connect Salesforce to ZigiOps. OAuth Client ID and Secret setup, attachment sync note, connected system configuration, and templates for CRM and ITSM workflows. ### What is Salesforce Integration in ZigiOps? Salesforce is a cloud-based CRM platform used for sales, customer service, marketing automation, and business operations management across enterprise organizations. ZigiOps enables secure, OAuth-based integration between Salesforce and ITSM, DevOps, and monitoring platforms. Using ZigiOps, cases, incidents, and records from Salesforce can be synchronized with external systems to support automated cross-team workflows and end-to-end customer service operations. With ZigiOps, Salesforce can: * Sync cases and incidents with ITSM platforms such as Jira and ServiceNow * Receive monitoring alerts as Salesforce records for customer-facing visibility * Participate in bi-directional workflows between CRM and DevOps or service management systems * Support automated escalation and routing of customer service cases The integration is fully customizable and does not require custom scripts or plugins. ### Which Salesforce Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------- | -------------------------- | ------------------ | | Salesforce | All | All | ### Are There Any Environmental Prerequisites for Salesforce? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} {% hint style="warning" %} Salesforce does not update the `lastmodifieddate` field when an attachment is added to a record. ZigiOps relies on this field to detect changes. To collect attachments from Salesforce, a mechanism that updates `lastmodifieddate` on attachment creation must be implemented on the Salesforce side before enabling attachment sync. {% endhint %} #### How Do I Create a Client ID and Client Secret in Salesforce? {% stepper %} {% step %} Log into your Salesforce instance. {% endstep %} {% step %} Navigate to: **Settings > Setup > Apps > App Manager** {% endstep %} {% step %} Click the **View** button for the desired application. {% endstep %} {% step %} The **Client ID** and **Client Secret** are available in the Manage Application menu. {% endstep %} {% endstepper %} ### How Do I Connect Salesforce to ZigiOps? #### Salesforce - Connected System Configuration Follow the steps below to add your Salesforce instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Salesforce** {% endstep %} {% step %} Configure the following parameters: * **URL** - Input the URL of your Salesforce instance. For example, `https://example.lightning.force.com` * **Username** - Input your Salesforce username. * **Password** - Input the password for the above user. * **Client ID** - Input the Client ID from Salesforce App Manager. * **Client Secret** - Input the Client Secret from Salesforce App Manager. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Salesforce becomes available for use in ZigiOps integration templates. ### What Are the Most Common Salesforce Integration Use Cases? #### Use Case 1: Case Synchronization Between Salesforce and Jira Customer cases created in Salesforce can be automatically mirrored as Jira tasks for development or operations teams. Updates made in Jira, including resolution notes and status changes, are synchronized back to Salesforce, keeping customer-facing records up to date. #### Use Case 2: Monitoring Alert Escalation to Salesforce SolarWinds alerts or other infrastructure events forwarded through ZigiOps can create or update Salesforce records, giving customer success and account management teams visibility into infrastructure issues affecting their customers. #### Use Case 3: Bi-Directional CRM and ITSM Workflow Automation Salesforce cases and ServiceNow incidents can be synchronized bidirectionally, ensuring that customer-reported issues tracked in CRM are also visible to IT service management teams without manual data duplication. ### What Integration Templates Are Available for Salesforce? ZigiOps provides the following integration templates for Salesforce: * Jira tasks to Salesforce cases * Salesforce cases to Jira tasks * SolarWinds alerts to Salesforce alerts Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Salesforce integration in ZigiOps enables: * Secure, OAuth-based connectivity using Client ID and Client Secret * Support for all Salesforce deployment types * Integration with Jira, ServiceNow, SolarWinds, and other platforms * Case and incident synchronization workflows * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Salesforce to participate in enterprise-grade CRM, ITSM, and automation ecosystems without requiring custom development. # SAP Solution Manager Connect SAP Solution Manager to ZigiOps. Integration package import, RFC connection setup, ZGW\_CONNECTIONS configuration, and available OBM templates. ### What is SAP Solution Manager Integration in ZigiOps? SAP Solution Manager is an IT and application lifecycle management platform used to monitor, support, and manage SAP and non-SAP systems across enterprise IT landscapes. ZigiOps enables secure integration between SAP Solution Manager and ITSM and operations management platforms. Using ZigiOps, SAP Solution Manager alerts and topology data can be forwarded to external systems to support automated incident creation and cross-platform operations workflows. With ZigiOps, SAP Solution Manager can: * Forward monitoring alerts to operations management platforms such as OBM * Participate in automated alert-to-incident workflows across IT and SAP operations teams * Synchronize SAP topology data with external infrastructure management platforms * Support bi-directional event flows between SAP operations and ITSM tools The integration is fully customizable and does not require custom scripts or plugins. ### Which SAP Solution Manager Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------------------- | -------------------------- | -------------------- | | SAP Solution Manager | All | 7.2 (including SP14) | ### Are There Any Environmental Prerequisites for SAP Solution Manager? {% hint style="info" %} **Note:** Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} {% hint style="warning" %} **Important:** The SAP Solution Manager integration requires importing an integration package and configuring RFC connections. These steps are advanced SAP configurations and should be performed by an SAP administrator. {% endhint %} #### How Do I Import the ZigiOps Integration Package for SAP Solution Manager? {% stepper %} {% step %} Unzip and copy the transport files Unzip `ZigiOps_Integration_package_for_SAP_Solman_v4.zip` to your SAP Solution Manager system. * Navigate to the `trans` directory on the development server. * Copy the K Type Transport to the `cofile` directory and the R Type Transport to the `data` directory. {% endstep %} {% step %} Import the transport into SAP Enter **STMS** as the transaction code in SAP Solution Manager. * Click **Import**, navigate to the import queue, and double-click the appropriate development system. * Click **Extras > Other Requests > Add**. {% endstep %} {% step %} Add the transport request In the Add Transport Request dialog: * Enter your target client number (for example, `100`). * Select the **Transp. Request** field and search for your transports using a wildcard (`*`) followed by the digit code. * Select the transport number and confirm. {% endstep %} {% step %} Add the integration as a third-party component Enter **SOLMAN\_SETUP** as the transaction code and navigate to the **SAP Solution Manager: Configuration** tab. * Select the desired monitoring configuration (for example, Job Monitoring, System Monitoring, User Experience Monitoring). * Go to **Step 2 (Configure Infrastructure) > Step 2.3 (Default Settings)**. * Click **Edit** and set **Third-Party Components** to **Active** on the Third-Party Components tab. * Click **Add**, select **BAdI Definition for Alert Reactions**, and click **OK**. * Click **Read Only** and save your changes. {% endstep %} {% endstepper %} #### How Do I Configure the RFC Connection to ZigiOps? {% stepper %} {% step %} Open the RFC connection In SAP GUI, search for **SM59** and expand **HTTP Connections to External Server**. Find or create **ZGW\_NEW\_ALERT**. {% endstep %} {% step %} Configure the technical settings Under the **Technical Settings** tab, configure: * **Target Host** - The FQDN, hostname, or IP of the ZigiOps server. * **Service No.** - The ZigiOps listener port (`9292` by default). * **Path Prefix** - The ZigiOps listener context path (`/listener/sap-solman/alerts` by default). Must start with `/`. * **Proxy Host, Proxy Service, Proxy User, Proxy Password** - Optional proxy settings if required. {% endstep %} {% endstepper %} #### How Do I Configure the ZGW\_CONNECTIONS Mapping Table? The ZGW\_CONNECTIONS table defines which SAP Solution Manager alert types are forwarded to ZigiOps via the configured RFC connection. {% stepper %} {% step %} Open the configuration table In SAP GUI, search for **ZGW\_CONNECTIONS** and execute it to open the configuration table. {% endstep %} {% step %} Create a new record * Click **Change Display**, then click **New Entries**. * Search for a Context ID or enter `*` to match all entries. * Search for an Alert Type ID or enter `*` to match all entries. * Search for the ZGW\_NEW\_ALERT RFC connection and click **Save**. {% endstep %} {% endstepper %} **Priority handling for multiple records (four levels, evaluated in order):** | Priority | Context ID | Alert Type ID | | ---------- | ------------- | ------------------------ | | Priority 1 | Matching | Matching | | Priority 2 | Matching | Wildcard (\*) | | Priority 3 | Wildcard (\*) | Matching | | Priority 4 | Wildcard (\*) | Wildcard (\*) - fallback | ### How Do I Connect SAP Solution Manager to ZigiOps? #### SAP Solution Manager - Connected System Configuration Follow the steps below to add your SAP Solution Manager instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log into your ZigiOps instance. {% endstep %} {% step %} Open the connected system setup Navigate to: **Connected Systems > Add New System > SAP-SolMan** {% endstep %} {% step %} Configure the parameters Configure the following parameters: * **URL** - Input the URL of your SAP Solution Manager instance. For example, `https://sap.example.com` * **Username** - The username ZigiOps uses to authenticate against SAP Solution Manager. * **Password** - The password for the above user. * **Client Number** - The client number of the SAP Solution Manager instance. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, SAP Solution Manager becomes available for use in ZigiOps integration templates. ### What Are the Most Common SAP Solution Manager Integration Use Cases? #### Use Case 1: SAP Alert Forwarding to OBM SAP Solution Manager monitoring alerts can be forwarded to OBM as structured events via ZigiOps, enabling operations teams to correlate SAP alerts with data from other infrastructure monitoring tools from a single platform. #### Use Case 2: Bi-Directional Alert and Event Synchronization with OBM ZigiOps supports backward synchronization between OBM and SAP Solution Manager, ensuring that event status updates made in OBM are reflected in the originating SAP alert, maintaining a consistent operational picture across both platforms. #### Use Case 3: SAP Topology Synchronization SAP Solution Manager topology data can be synchronized with OBM, keeping the operations platform's topology model aligned with the SAP landscape configuration. ### What Integration Templates Are Available for SAP Solution Manager? ZigiOps provides the following integration templates for SAP Solution Manager: * SAP SolMan Alerts to OBM Events (OA) * SAP SolMan Alerts to OBM Events Backsync * SAP Solman topology to OBM topology (OA) Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The SAP Solution Manager integration in ZigiOps enables: * Secure, RFC-based and REST API connectivity * Support for SAP Solution Manager 7.2 (including SP14) * Integration with OBM and other operations management platforms * Alert and topology data synchronization with bi-directional support * RFC connection and ZGW\_CONNECTIONS table-based routing * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows SAP Solution Manager to participate in enterprise-grade ITSM, ITOM, and automation ecosystems without requiring custom development. # ServiceNow Official ZigiOps docs: ServiceNow. Configuration steps, requirements, and supported versions for your integration. ### What is ServiceNow Integration in ZigiOps? ServiceNow is an enterprise IT service management platform used for incident, problem, change, and service request management across large and complex IT environments. ZigiOps enables secure, API-based integration between ServiceNow and ITSM, DevOps, monitoring, and cloud platforms. Using ZigiOps, incidents, problems, change requests, and service catalog tasks from ServiceNow can be synchronized with external systems to support automated cross-team workflows. With ZigiOps, ServiceNow can: * Sync incidents and problems with DevOps tools such as Jira and Azure DevOps * Receive correlated alerts and events from monitoring platforms as ServiceNow incidents * Participate in bi-directional workflows with monitoring, CRM, and DevOps platforms * Support topology and configuration management integrations via uCMDB and vROps The integration is fully customizable and does not require custom scripts or plugins. ### Which ServiceNow Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------- | -------------------------- | --------------------------------------------- | | ServiceNow | All | Utah, Vancouver, Washington, Xanadu, Yokohama | ### Are There Any Environmental Prerequisites for ServiceNow? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How Do I Set the Required ZigiOps Integration User Permissions in ServiceNow? The ZigiOps integration user requires read, create, and write access to the primary integrated entity (incident, event, problem, etc.) in ServiceNow. {% hint style="info" %} The steps below are optional and provided as a reference. You may adapt them to your organization's security model. {% endhint %} {% stepper %} {% step %} Create a custom role (optional) 1. Navigate to: **ServiceNow > User Administration > Roles** and create a new role. 2. Save the changes. {% endstep %} {% step %} Create the required ACLs 1. Elevate the `security_admin` privilege. 2. Navigate to: **ServiceNow > System Security > Access Control (ACL)** and create ACLs for the following: * `sys_db_object`: READ (row-level) and READ\* (field-level) - allows ZigiOps to fetch available ServiceNow tables * `sys_dictionary`: READ (row-level) and READ\* (field-level) - allows ZigiOps to fetch references between the integrated entity and related tables * `sys_glide_object`: READ (row-level) and READ\* (field-level) - allows ZigiOps to fetch field types of ServiceNow tables * `sys_journal_field`: READ (row-level) and READ\* (field-level) - allows ZigiOps to collect comments and work notes 3. Assign the newly created ACLs to the `zigiops_integration_role` custom role. 4. Assign the `zigiops_integration_role` and `itil` roles to the ZigiOps integration user. {% endstep %} {% endstepper %} {% hint style="info" %} Integrating entities outside the `itil` role scope, such as custom tables, will require additional permission configuration. {% endhint %} ### How Do I Connect ServiceNow to ZigiOps? #### ServiceNow - Connected System Configuration Follow the steps below to add your ServiceNow instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to ServiceNow Navigate to: **Connected Systems > Add New System > ServiceNow** {% endstep %} {% step %} Configure the following parameters * **Server URL** - Input the URL of your ServiceNow instance. For example, `https://example.service-now.com` * **Username** - Input the username of the ServiceNow integration user. * **Password** - Input the password for the ServiceNow integration user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, ServiceNow becomes available for use in ZigiOps integration templates. ### What Are the Most Common ServiceNow Integration Use Cases? #### Use Case 1: Bi-Directional Incident Sync Between ServiceNow and Jira ServiceNow incidents can be automatically mirrored as Jira tasks for development teams. Status updates, comments, and resolution details flow in both directions, eliminating manual hand-offs between ITSM and DevOps teams. #### Use Case 2: Monitoring Alert Escalation to ServiceNow Correlated events from monitoring platforms such as OBM, SolarWinds, and Zabbix can be forwarded to ServiceNow as structured incidents, capturing infrastructure alerts in the ITSM system for triage, assignment, and SLA tracking. #### Use Case 3: DevOps and ITSM Workflow Automation Azure DevOps work items, Bitbucket commits, and GitHub issues can be synchronized with ServiceNow incidents, providing ITSM teams with full traceability from infrastructure events through to code changes and deployments. ### What Integration Templates Are Available for ServiceNow? ZigiOps provides the following integration templates for ServiceNow: * Azure DevOps work items to ServiceNow incidents * Bitbucket commits to ServiceNow incidents * Bitbucket issues to ServiceNow incidents * Cherwell change requests to ServiceNow change requests * Jira tasks to ServiceNow incidents * OBM events to ServiceNow incidents * OBM events to ServiceNow incidents (Staging Table) * ServiceNow incidents to Azure DevOps issues * ServiceNow incidents to GitHub issues * ServiceNow incidents to Jira tasks * ServiceNow problems to Jira bugs * ServiceNow server topology to uCMDB node topology * ServiceNow service catalog tasks to Jira tasks * ServiceNow VMware instances topology to vROps custom group members topology * ServiceNow VMware instances topology to vROps topology * SolarWinds alerts to ServiceNow incidents * Zabbix host topology to ServiceNow topology * Zabbix topology to OBM topology * Zabbix trigger events to ServiceNow events * Zabbix trigger events to ServiceNow incidents Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The ServiceNow integration in ZigiOps enables: * Secure, username/password-based API connectivity * Support for ServiceNow Utah, Vancouver, Washington, Xanadu, and Yokohama * Integration with Jira, Azure DevOps, OBM, SolarWinds, Zabbix, Bitbucket, GitHub, and more * Bi-directional incident, problem, change request, and topology synchronization * Optional OBM staging table application for advanced event integration * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows ServiceNow to participate in enterprise-grade ITSM, DevOps, and monitoring ecosystems without requiring custom development. # ServiceNow MID Server Connect ServiceNow MID Server to ZigiOps. MID Server API URL and credential setup, connected system configuration, and available integration templates. ### What is ServiceNow MID Server Integration in ZigiOps? The ServiceNow MID (Management, Instrumentation, and Discovery) Server is a Java application that facilitates secure communication between the ServiceNow cloud platform and systems located within a customer's internal network, including on-premises and firewalled environments. ZigiOps supports direct integration with the ServiceNow MID Server, enabling data exchange between ZigiOps and ServiceNow instances where direct cloud connectivity is restricted by network or security policies. With ZigiOps, ServiceNow MID Server can: * Serve as the communication bridge for ZigiOps to reach on-premises ServiceNow environments * Enable secure, firewall-compliant data exchange between ZigiOps and ServiceNow * Support integration workflows that require internal network access for data collection or delivery * Participate in ITSM automation scenarios in environments with strict outbound connectivity controls The integration is fully customizable and does not require custom scripts or plugins. ### Which ServiceNow MID Server Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------------- | -------------------------- | ------------------ | | ServiceNow MID Server | All | All | ### Are There Any Environmental Prerequisites for ServiceNow MID Server? There are no environmental prerequisites for this product. ### How Do I Connect ServiceNow MID Server to ZigiOps? #### ServiceNow MID Server - Connected System Configuration Follow the steps below to add your ServiceNow MID Server instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > ServiceNow MID Server** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of the MID Server API. For example, `https://midserver.example.com:9060` * **Username** - Input the username of the ServiceNow MID Server. * **Password** - Input the password for the ServiceNow MID Server. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, ServiceNow MID Server becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What Are the Most Common ServiceNow MID Server Integration Use Cases? #### Use Case 1: Secure ITSM Integration in Restricted Network Environments Organizations with strict outbound connectivity policies can use the ServiceNow MID Server as the secure communication layer between ZigiOps and their ServiceNow instance. ZigiOps communicates with the MID Server, which then relays data to and from ServiceNow within the internal network. #### Use Case 2: On-Premises Monitoring Alert Forwarding to ServiceNow Monitoring tools deployed in on-premises environments behind firewalls can forward alerts through ZigiOps to ServiceNow via the MID Server, ensuring that infrastructure events are captured as ITSM incidents without requiring direct cloud access from internal systems. #### Use Case 3: Internal Data Collection for Hybrid ITSM Workflows The MID Server enables ZigiOps to reach ServiceNow entities and data sources that are not directly accessible from the cloud, supporting integration workflows that span both cloud and on-premises components. ### What Integration Templates Are Available for ServiceNow MID Server? ZigiOps provides integration templates for ServiceNow MID Server depending on the paired system and deployment scenario. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The ServiceNow MID Server integration in ZigiOps enables: * Secure, credential-based connectivity to the MID Server API * Support for all ServiceNow MID Server deployment types * Firewall-compliant communication between ZigiOps and on-premises ServiceNow environments * Support for hybrid and restricted network integration scenarios * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows ServiceNow MID Server to serve as a secure communication bridge in enterprise-grade ITSM and automation ecosystems without requiring custom development. # SIGNL4 Connect SIGNL4 to ZigiOps. Webhook URL and Team Secret retrieval, connected system configuration, and available integration templates for alert notifications. ### What is SIGNL4 Integration in ZigiOps? SIGNL4 is a mobile alerting and incident notification platform used to deliver critical alerts to on-call teams via push notifications, SMS, and voice calls across enterprise IT and operational environments. ZigiOps enables secure, webhook-based integration between SIGNL4 and ITSM, monitoring, and DevOps platforms. Using ZigiOps, alerts and operational events from connected systems can be forwarded to SIGNL4 to trigger immediate on-call notifications and escalations. With ZigiOps, SIGNL4 can: * Receive forwarded alerts from monitoring and ITSM platforms for immediate on-call notification * Participate in automated escalation workflows triggered by infrastructure or application events * Integrate with ITSM ticketing systems to notify responsible teams when new incidents are created * Support closed-loop alerting where acknowledgment in SIGNL4 triggers updates in the source system The integration is fully customizable and does not require custom scripts or plugins. ### Which SIGNL4 Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | SIGNL4 | All | All | ### Are There Any Environmental Prerequisites for SIGNL4? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How Do I Obtain My Webhook URL and Team Secret in SIGNL4? 1. Log in to your SIGNL4 instance. 2. Navigate to: **SIGNL4 > Teams** 3. Click the **Team** tile to expand it. Your Webhook URL and Team Secret are displayed in the expanded section. The Team Secret is the last segment of the Webhook URL. > **Example:** Webhook URL: `https://connect.signl4.com/webhook/exampleSecret` | Team Secret: `exampleSecret` ### How Do I Connect SIGNL4 to ZigiOps? #### SIGNL4 - Connected System Configuration Follow the steps below to add your SIGNL4 instance as a connected system. 1. Log into your ZigiOps instance. 2. Navigate to: **Connected Systems > Add New System > SIGNL4** 3. Configure the following parameters: * **Instance URL** - Input your SIGNL4 Team Webhook URL. For example, `https://connect.signl4.com/webhook/` * **Team Secret** - Input the Team Secret of your SIGNL4 team. * **Proxy Settings** - Enables the usage of a proxy server. 4. Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, SIGNL4 becomes available for use in ZigiOps integration templates. ### What Are the Most Common SIGNL4 Integration Use Cases? #### Use Case 1: Monitoring Alert Notification via SIGNL4 Infrastructure alerts from monitoring platforms forwarded through ZigiOps can trigger immediate SIGNL4 push notifications to on-call engineers, ensuring that critical events reach the right person within seconds. #### Use Case 2: ITSM Incident Notification When a high-priority incident is created in ServiceNow or Jira, ZigiOps can forward the incident details to SIGNL4, triggering an on-call alert with full context so that the responsible team is notified immediately. #### Use Case 3: Escalation and Acknowledgment Workflows SIGNL4 acknowledgments can be configured to trigger status updates in the originating ITSM or monitoring system via ZigiOps, enabling closed-loop alerting without requiring engineers to manually update multiple platforms. ### What Integration Templates Are Available for SIGNL4? ZigiOps provides integration templates for SIGNL4 depending on the paired system and use case. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The SIGNL4 integration in ZigiOps enables: * Secure, webhook-based connectivity using Webhook URL and Team Secret * Support for all SIGNL4 deployment types * Integration with monitoring, ITSM, and DevOps platforms * Real-time mobile alerting and on-call notification workflows * Optional proxy configuration * Fully customizable alert forwarding workflows ZigiOps allows SIGNL4 to participate in enterprise-grade alerting, ITSM, and automation ecosystems without requiring custom development. # SMTP Configure SMTP in ZigiOps to send email notifications for monitoring alerts, incidents, and change requests. ### What is SMTP integration in ZigiOps? Simple Mail Transfer Protocol (SMTP) is the standard protocol for sending email messages between servers. In ZigiOps, the SMTP connector enables the platform to send email notifications to users and user groups when specific events, alerts, incidents, or workflow triggers occur. The SMTP integration does not pull data from an external system. Instead, it acts as an outbound notification channel within ZigiOps integration templates. With ZigiOps, SMTP can be used to: * Notify users and user groups when monitoring alerts or incidents are generated * Send email notifications for ITSM events such as ticket creation or assignment * Deliver change request notifications when approvals or completions occur * Support self-health monitoring alerts from ZigiOps itself ### What systems support SMTP notifications in ZigiOps? The SMTP connector can be paired with templates from a wide range of connected systems. The table below outlines the supported areas and systems. | **Area** | **Description** | **Connected Systems** | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | Self-Health Monitoring | Notify users and/or user groups by email on ZigiOps Self-Health event generation. | ZigiOps | | Monitoring | Notify users and/or user groups by email whenever a specific Alert, Event, Incident, Problem, or Status Change occurs. | Cherwell, DataDog, Dynatrace, Kubernetes, Nagios, NewRelic, OpsBridge, Prometheus, Remedy, Remedyforce, ServiceNow, SolarWinds, Zabbix, vROps | | DevOps and IT Support | Notify users and/or user groups whenever a specific Epic, Story, Issue, Task, Work Item, or Case is created or assigned. | Azure DevOps, Jira, Salesforce, ServiceNow | | Change Management | Notify users and/or user groups whenever a specific Change Request is created, approved, or completed. | Remedy, ServiceNow | ### Are there any environmental prerequisites for SMTP? {% hint style="info" %} *Note: Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites.* See the Related Templates section at the end of this page. {% endhint %} ### How do I connect an SMTP server to ZigiOps? #### SMTP - Connected System Configuration Follow the steps below to add an SMTP server as a connected system in ZigiOps. {% stepper %} {% step %} Log in to your ZigiOps instance. {% endstep %} {% step %} **Navigate to Connected Systems → Add New System → SMTP** and configure the following parameters: * **URL:** Input the URL of the SMTP server followed by its port. Example: mailserver.example.com:587. * **Connection Type:** Select the connection type of the SMTP server. * **Username:** Input the username (typically an email address) used to authenticate against the SMTP server. * **Password:** Input the password for the SMTP server username. * **Proxy Settings (optional):** Enable this option if a proxy server is required for outbound communication. {% endstep %} {% step %} Review the configuration. {% endstep %} {% step %} **Click Save** to store the connected system. {% endstep %} {% endstepper %} Once saved, the SMTP connector becomes available for use in ZigiOps integration templates. ### What are the most common SMTP integration use cases? #### Use case 1: Monitoring alert email notifications ZigiOps can be configured to send email notifications to on-call teams or user groups when alerts or events are detected in monitoring systems such as Nagios, Prometheus, Dynatrace, or SolarWinds. #### Use case 2: ITSM workflow email notifications When issues, tasks, or stories are created or assigned in platforms such as Jira, ServiceNow, or Azure DevOps, ZigiOps can send targeted email notifications to the responsible users or groups. #### Use case 3: Change management notifications ZigiOps can notify stakeholders by email when change requests are created, approved, or completed in Remedy or ServiceNow, supporting compliance and communication requirements. #### Use case 4: ZigiOps self-health monitoring The SMTP connector can also be used to notify administrators when ZigiOps generates internal self-health events, enabling proactive platform management. ### What integration templates are available for SMTP? #### Related Templates SMTP is used as a notification output in templates across multiple categories. Please contact the ZigiWave support team at for the full list of SMTP-enabled templates. Each template includes: * Predefined notification triggers * Target system and event-type mapping * User and user group delivery configuration ### Summary The SMTP integration in ZigiOps provides: * Outbound email notification support for monitoring, ITSM, and change management workflows * Compatible with major monitoring and ITSM platforms * Username and password authentication for SMTP servers * Flexible proxy support * Support for ZigiOps self-health event notifications # SolarWinds Connect SolarWinds NPM, SAM, DPA, and VIM to ZigiOps. Supported versions, basic auth setup, and templates for alert, metrics, topology, and event synchronization. ### What is SolarWinds Integration in ZigiOps? SolarWinds is a network and IT infrastructure monitoring platform used for network performance management (NPM), server and application monitoring (SAM), database performance analysis (DPA), and virtualization infrastructure monitoring (VIM). ZigiOps enables secure, API-based integration between SolarWinds and ITSM, monitoring, and cloud platforms. Using ZigiOps, alerts, events, metrics, and topology data from SolarWinds can be synchronized with external systems to support automated incident management and centralized infrastructure monitoring. With ZigiOps, SolarWinds can: * Forward network and infrastructure alerts to ITSM platforms such as ServiceNow, Jira, and Salesforce * Synchronize network and server topology data with operations management platforms such as OBM * Feed performance metrics (CPU, memory, cluster, VM, ESXi) into centralized monitoring platforms * Participate in automated incident creation and escalation workflows triggered by network events The integration is fully customizable and does not require custom scripts or plugins. ### Which SolarWinds Versions Are Supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------------- | -------------------------- | ------------------ | | SolarWinds NPM | All | 10.5.x (or newer) | | SolarWinds SAM | All | 6.1.x (or newer) | | SolarWinds DPA | All | 2020.x (or newer) | | SolarWinds VIM | All | 2020.x (or newer) | ### Are There Any Environmental Prerequisites for SolarWinds? There are no environmental prerequisites for this product. ### How Do I Connect SolarWinds to ZigiOps? #### SolarWinds - Connected System Configuration Follow the steps below to add your SolarWinds instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > SolarWinds** {% endstep %} {% step %} Configure the following parameters: * **Server URL** - Input the URL of your SolarWinds instance: * SolarWinds 22.1 or newer: `https://solarwinds.example.com:17774` * Older SolarWinds versions: use port `17778` * **Username** - Input your SolarWinds username. * **Password** - Input the password for the above user. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. Once saved, SolarWinds becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What Are the Most Common SolarWinds Integration Use Cases? #### Use Case 1: SolarWinds Alert Forwarding to ITSM Network and infrastructure alerts detected by SolarWinds NPM can be forwarded to ServiceNow, Jira, or Salesforce as structured incidents or cases. Operations teams receive fully contextualized tickets without manual log review. #### Use Case 2: Topology Data Synchronization with OBM SolarWinds NPM, SAM, DPA, and VIM topology data can be synchronized with OBM, keeping the operations platform's topology model aligned with the current state of the network and virtualization infrastructure. #### Use Case 3: Performance Metrics Ingestion for Capacity Planning CPU, memory, cluster, VM, and ESXi metrics collected by SolarWinds can be forwarded to OBM or other monitoring platforms, enabling centralized capacity planning and performance trend analysis across the entire infrastructure. ### What Integration Templates Are Available for SolarWinds? ZigiOps provides the following integration templates for SolarWinds: * SolarWinds alerts to Jira tasks * SolarWinds alerts to OBM events * SolarWinds alerts to Salesforce alerts * SolarWinds alerts to ServiceNow incidents * SolarWinds cluster metrics to OBM metrics * SolarWinds CPU and memory metrics to OBM metrics * SolarWinds DPA topology to OBM topology * SolarWinds events to OBM events * SolarWinds events to Splunk Enterprise events * SolarWinds host and ESXi metrics to OBM metrics * SolarWinds NPM topology to OBM topology * SolarWinds SAM topology to OBM topology * SolarWinds VIM topology to OBM topology * SolarWinds VM metrics to OBM metrics * SolarWinds VMW topology to OBM topology Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The SolarWinds integration in ZigiOps enables: * Secure, username/password-based API connectivity * Support for SolarWinds NPM 10.5.x+, SAM 6.1.x+, DPA 2020.x+, and VIM 2020.x+ * Integration with ServiceNow, Jira, Salesforce, OBM, and Splunk * Alert, event, metrics, and topology data synchronization * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows SolarWinds to participate in enterprise-grade ITSM, ITOM, and infrastructure monitoring ecosystems without requiring custom development. # Splunk Enterprise Connect Splunk Enterprise to ZigiOps. API token generation via HTTP Event Collector, connected system setup, and templates for alert and event synchronization with OBM. ### What is Splunk Enterprise Integration in ZigiOps? Splunk Enterprise is a data analytics and security information and event management (SIEM) platform used for log management, operational intelligence, security monitoring, and infrastructure event analysis across enterprise environments. ZigiOps enables secure, API-based integration between Splunk Enterprise and ITSM, monitoring, and operations management platforms. Using ZigiOps, Splunk alerts and events can be synchronized with external systems to support automated incident creation and cross-platform security and operations workflows. With ZigiOps, Splunk Enterprise can: * Forward Splunk alerts to operations management platforms such as OBM as structured events * Receive infrastructure events from other monitoring platforms for centralized log ingestion * Participate in automated incident creation workflows triggered by Splunk search alerts * Support bi-directional event flows between SIEM and ITOM or ITSM platforms The integration is fully customizable and does not require custom scripts or plugins. ### Which Splunk Enterprise Versions Are Supported? {% hint style="info" %} Please note that using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | ----------------- | -------------------------- | ------------------ | | Splunk Enterprise | Cloud, Server | 7.x (or newer) | ### Are There Any Environmental Prerequisites for Splunk Enterprise? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How Do I Generate an API Token in Splunk Enterprise? 1. Log in to your Splunk Enterprise instance. 2. Navigate to: **Settings > Data Inputs** 3. Create an **HTTP Event Collector** entry. 4. Click **New Token** to generate the API token. {% hint style="warning" %} Store the token securely. It is required for the ZigiOps connected system configuration. {% endhint %} ### How Do I Connect Splunk Enterprise to ZigiOps? #### Splunk Enterprise - Connected System Configuration Follow the steps below to add your Splunk Enterprise instance as a connected system. {% stepper %} {% step %} Log into your ZigiOps instance. {% endstep %} {% step %} Navigate to: **Connected Systems > Add New System > Splunk** {% endstep %} {% step %} Configure the following parameters: * **URL** - Input the URL of your Splunk instance. For example, `https://splunk.example.com:8089` * **Username** - Input your Splunk username. * **Password** - Input the password for the above user. * **API Token** - Input the API token generated via the HTTP Event Collector. * **Proxy Settings** - Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and if they are correct, click the **Save** button to store the system. {% endstep %} {% endstepper %} Once saved, Splunk Enterprise becomes available for use in ZigiOps integration templates. ### What Are the Most Common Splunk Enterprise Integration Use Cases? #### Use Case 1: Splunk Alert Forwarding to OBM Splunk Enterprise alerts triggered by saved search queries can be forwarded to OBM as structured events via ZigiOps, enabling operations teams to correlate Splunk-detected anomalies with data from other monitoring tools. #### Use Case 2: Infrastructure Event Ingestion into Splunk Events from monitoring platforms such as AppDynamics and SolarWinds can be forwarded into Splunk Enterprise via ZigiOps, enriching the Splunk data set with infrastructure event context for security and operational analytics. #### Use Case 3: SIEM-to-ITSM Automated Escalation Security events detected and alerted by Splunk can be escalated to ITSM platforms through ZigiOps, creating structured incident records for security operations teams to triage and remediate without manual log review. ### What Integration Templates Are Available for Splunk Enterprise? ZigiOps provides the following integration templates for Splunk Enterprise: * AppDynamics node metrics to Splunk Enterprise events * SolarWinds events to Splunk Enterprise events * Splunk Enterprise alerts to OBM events * Splunk Enterprise events to OBM events Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Splunk Enterprise integration in ZigiOps enables: * Secure, API token and username/password-based connectivity * Support for Splunk Enterprise 7.x and newer (Cloud and Server) * Integration with OBM, AppDynamics, and SolarWinds * Alert and event forwarding in both directions * HTTP Event Collector-based token authentication * Optional proxy configuration * Fully customizable synchronization workflows ZigiOps allows Splunk Enterprise to participate in enterprise-grade SIEM, ITOM, and security automation ecosystems without requiring custom development. # Splunk Observability Cloud (SignalFx) Connect Splunk Observability Cloud (SignalFx) to ZigiOps. API token setup, connected system configuration, and integration templates for monitoring workflows. ### What is Splunk Observability Cloud (SignalFx) integration in ZigiOps? Splunk Observability Cloud, formerly known as SignalFx, is a cloud and server-based observability platform used for real-time monitoring, alerting, and performance analysis of infrastructure and application environments. ZigiOps enables integration between Splunk Observability Cloud and ITSM, DevOps, and service management platforms. Using an API token for authentication, ZigiOps can route alerts, metrics, and events from Splunk Observability Cloud into connected systems to support automated incident management and cross-team workflows. With ZigiOps, Splunk Observability Cloud can: * Forward alerts and events to ITSM platforms such as ServiceNow or Jira * Participate in bi-directional workflows between monitoring and service management tools * Support automated escalation and routing of infrastructure incidents * Integrate with other observability and operations platforms without custom scripting ### Which Splunk Observability Cloud versions are supported? {% hint style="info" %} Please note that using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | ------------------------------------- | -------------------------- | ------------------ | | Splunk Observability Cloud (SignalFx) | Cloud, Server | All | ### Are there any environmental prerequisites for Splunk Observability Cloud? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How do I create an API token in Splunk Observability Cloud? A user-generated Access Token is required for authentication against the Splunk SignalFx API. This token is entered as the **Splunk SignalFx Token** field during connected system setup in ZigiOps. Refer to the Splunk Observability Cloud documentation for instructions on generating an Access Token. ### How do I connect Splunk Observability Cloud to ZigiOps? #### Splunk Observability Cloud (SignalFx) - Connected System Configuration Follow the steps below to add your Splunk Observability Cloud instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Add Splunk Observability Cloud as a connected system Navigate to **Connected Systems > Add New System > Splunk Observability Cloud (Signal FX)**. {% endstep %} {% step %} Configure the system parameters Configure the following parameters: **URL**\ Input the URL of your instance.\ Example: `https://app.eu0.signalfx.com` **Splunk SignalFx Token**\ This is a user-generated Access Token that ZigiOps uses for authentication against the Splunk SignalFx API. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. Once saved, Splunk Observability Cloud becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common Splunk Observability Cloud integration use cases? #### Use case 1: Monitoring alert forwarding to ITSM Alerts and events from Splunk Observability Cloud can be automatically forwarded to ITSM platforms such as ServiceNow or Jira, creating incidents or tickets for operations teams without manual intervention. #### Use case 2: Cross-platform observability workflow automation Splunk Observability Cloud data can be correlated with events from other monitoring or operations platforms, enabling unified alerting and automated response workflows across the enterprise. ### What integration templates are available for Splunk Observability Cloud? ZigiOps provides integration templates for Splunk Observability Cloud. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The Splunk Observability Cloud (SignalFx) integration in ZigiOps enables: * API token-based authentication for Cloud and Server deployments * Support for all Splunk Observability Cloud versions * Alert and event forwarding to ITSM and DevOps platforms * Automated monitoring-to-incident workflows * Optional proxy configuration * Fully customizable synchronization workflows without custom scripting ZigiOps allows Splunk Observability Cloud to participate in enterprise-grade observability and IT operations ecosystems without requiring custom development. # TOPdesk Connect TOPdesk to ZigiOps. Username and password setup, connected system configuration, and integration templates for ITSM workflows. ### What is TOPdesk integration in ZigiOps? TOPdesk is an IT service management platform used by organizations to manage incidents, requests, changes, and assets. It supports both cloud and on-premises deployments and is widely used in enterprise and mid-market ITSM environments. ZigiOps enables integration between TOPdesk and other ITSM, DevOps, and monitoring platforms. Using username and password authentication, ZigiOps connects TOPdesk to external systems to support automated ticket synchronization, incident management, and cross-team workflows. With ZigiOps, TOPdesk can: * Sync incidents and service requests with platforms such as Jira or ServiceNow * Receive alerts from monitoring tools as TOPdesk tickets * Participate in bi-directional workflows between ITSM and DevOps systems * Support automated escalation and routing of service desk cases ### Which TOPdesk versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | TOPdesk | All | All | ### Are there any environmental prerequisites for TOPdesk? There are no environmental prerequisites for this product. ### How do I connect TOPdesk to ZigiOps? #### TOPdesk - Connected System Configuration Follow the steps below to add your TOPdesk instance as a connected system. 1. Log in to your **ZigiOps** instance. 2. Navigate to **Connected Systems > Add New System > TOPdesk**. 3. Configure the following parameters: **Server URL**\ Input the URL of your instance.\ Example: `https://example.topdesk.net` **Username**\ Input your integration user username. **Password**\ Input the password of your integration user. **Proxy Settings (optional)**\ Enables the usage of a proxy server. 4. Examine the settings and, if they are correct, click **Save** to store the system. Once saved, TOPdesk becomes available for use in ZigiOps integration templates. ### What are the most common TOPdesk integration use cases? #### Use case 1: Incident synchronization between TOPdesk and Jira Incidents created in TOPdesk can be automatically mirrored as Jira issues for development or operations teams. Updates made in Jira are synchronized back to TOPdesk, keeping service desk records current. #### Use case 2: Monitoring alert escalation to TOPdesk Infrastructure alerts from monitoring platforms can be forwarded through ZigiOps to create or update TOPdesk tickets, enabling automated incident creation without manual intervention. ### What integration templates are available for TOPdesk? ZigiOps provides integration templates for TOPdesk. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The TOPdesk integration in ZigiOps enables: * Username and password-based connectivity for all TOPdesk deployment types * Support for all TOPdesk versions * No environmental prerequisites required * Integration with Jira, ServiceNow, monitoring tools, and other platforms * Incident and service request synchronization workflows * Optional proxy configuration * Fully customizable synchronization workflows without custom scripting ZigiOps allows TOPdesk to participate in enterprise-grade ITSM and automation ecosystems without requiring custom development. # TrueSight OM Connect BMC TrueSight Operations Manager to ZigiOps. Dual-URL setup for Infrastructure Management and Presentation Server, authentication types, and integration templates. ### What is TrueSight OM integration in ZigiOps? BMC TrueSight Operations Manager (TrueSight OM) is an enterprise IT operations management platform used for event management, infrastructure monitoring, and automated remediation. It consists of two primary components: the Infrastructure Management server and the Presentation Server. ZigiOps enables integration between TrueSight OM and ITSM, DevOps, and other monitoring platforms. The integration supports separate authentication configurations for the Infrastructure Management and Presentation Server components, allowing ZigiOps to interact with both layers of the TrueSight OM architecture. With ZigiOps, TrueSight OM can: * Forward events and alerts to ITSM platforms such as ServiceNow or Jira * Participate in bi-directional workflows between event management and service management systems * Synchronize infrastructure topology data with connected platforms * Support automated incident creation and escalation workflows ### Which TrueSight OM versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------------------------- | -------------------------- | ------------------ | | TrueSight Operations Manager | All | 11.3 (or newer) | ### Are there any environmental prerequisites for TrueSight OM? There are no environmental prerequisites for this product. ### How do I connect TrueSight OM to ZigiOps? {% stepper %} {% step %} Log in and add the connected system Log in to your **ZigiOps** instance. Navigate to **Connected Systems > Add New System > BMC TrueSight OM**. {% endstep %} {% step %} Configure the TrueSight OM parameters Configure the following parameters: **TrueSight Infrastructure Management URL**\ Input the URL of the BMC TrueSight Infrastructure Management, followed by the API port.\ Example: `https://tsom.example.com:446` **TrueSight Presentation Server URL**\ Input the URL of the BMC TrueSight Presentation Server, followed by the API port.\ Example: `https://tsom.example.com` **Authentication Type for Infrastructure Management**\ Select the preferred authentication type for Infrastructure Management. **Authentication Type for Presentation Server**\ Select the preferred authentication type for Presentation Server. **Username for Infrastructure Management**\ Input a username to connect to the BMC TrueSight Infrastructure Management. **Password for Infrastructure Management**\ Input the password or the token for the above user. **Username for Presentation Server**\ Input a username to connect to the BMC TrueSight Presentation Server. **Password for Presentation Server**\ Input the password or the token for the above user. **Tenant Name**\ Input the name of the tenant of the BMC TrueSight OM server. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. Once saved, TrueSight OM becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common TrueSight OM integration use cases? #### Use case 1: Event forwarding from TrueSight OM to ServiceNow Events detected by TrueSight OM can be automatically forwarded to ServiceNow as incidents, enabling operations teams to manage infrastructure issues within their existing ITSM workflows. #### Use case 2: Bi-directional event and incident management TrueSight OM events and ServiceNow or Jira records can be synchronized bidirectionally, ensuring that infrastructure issues tracked in event management are also visible to IT service management teams. ### What integration templates are available for TrueSight OM? ZigiOps provides integration templates for TrueSight OM. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The TrueSight OM integration in ZigiOps enables: * Dual-URL configuration for Infrastructure Management and Presentation Server * Flexible authentication types for each TrueSight OM component * Support for TrueSight OM version 11.3 and newer * No environmental prerequisites required * Event forwarding and incident synchronization with ITSM platforms * Tenant-aware connectivity * Optional proxy configuration ZigiOps allows TrueSight OM to participate in enterprise-grade IT operations and service management ecosystems without requiring custom development. # uCMDB Connect Universal Discovery and CMDB (uCMDB) to ZigiOps. Version requirements, environmental prerequisites, and templates for topology synchronization. ### What is uCMDB integration in ZigiOps? Universal Discovery and CMDB (uCMDB) is a configuration management database platform used for IT asset discovery, topology mapping, and configuration item tracking across enterprise environments. It provides a centralized repository of infrastructure data that supports IT service management and operations. ZigiOps enables integration between uCMDB and ITSM platforms such as ServiceNow, allowing topology and configuration data to be synchronized across systems. This supports automated CMDB population, topology enrichment, and cross-platform asset management workflows. With ZigiOps, uCMDB can: * Receive topology data from ITSM platforms such as ServiceNow * Synchronize configuration item and node topology records with connected systems * Support automated CMDB population and enrichment workflows * Participate in cross-platform infrastructure asset management processes ### Which uCMDB versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------------------------------ | -------------------------- | ------------------ | | Universal Discovery and CMDB (uCMDB) | Server | 2019.x (or newer) | ### Are there any environmental prerequisites for uCMDB? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} The environmental prerequisites for uCMDB are listed within the corresponding integration template documentation. Review the specific template prerequisites before proceeding with the connected system configuration. ### How do I connect uCMDB to ZigiOps? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} Connected system configuration steps for uCMDB are documented within each integration template. Refer to the specific template documentation for the full setup instructions applicable to your deployment. ### What are the most common uCMDB integration use cases? #### ServiceNow server topology to uCMDB node topology Server topology data from ServiceNow can be synchronized into uCMDB as node topology records. This enables automated population of the configuration management database with infrastructure data originating from ITSM workflows. ### What integration templates are available for uCMDB? ZigiOps provides the following integration template for uCMDB: * ServiceNow server topology - uCMDB node topology Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The uCMDB integration in ZigiOps enables: * Server-based deployment support for uCMDB 2019.x and newer * Topology synchronization between ServiceNow and uCMDB * Automated CMDB population and node topology enrichment * Cross-platform configuration management workflows * Template-specific prerequisite configuration ZigiOps allows uCMDB to participate in enterprise-grade configuration management and ITSM ecosystems without requiring custom development. # vROps Connect VMware vRealize Operations (vROps) to ZigiOps. Management Pack installation, correlation field setup, connected system configuration, and available integration templates. ### What is vROps integration in ZigiOps? VMware vRealize Operations (vROps) is an AI-driven IT operations management platform used for monitoring, performance optimization, capacity management, and automated troubleshooting of VMware-based infrastructure and multi-cloud environments. ZigiOps enables integration between vROps and ITSM, monitoring, and IT operations platforms. Using username and password authentication, ZigiOps connects vROps to external systems to support automated alert forwarding, topology synchronization, and metrics exchange workflows. With ZigiOps, vROps can: * Forward alerts and events to operations platforms such as OBM * Synchronize Linux and Windows topology data with connected platforms * Exchange metrics with OBM and other monitoring systems * Receive topology enrichment data from AppDynamics, Dynatrace, NewRelic, and ServiceNow * Participate in bi-directional workflows between VMware infrastructure monitoring and service management ### Which vROps versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | vROps | All | 7.5.x (or newer) | ### Are there any environmental prerequisites for vROps? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %}
How do I install the ZigiOps Management Pack to vROps? Contact the ZigiWave support team at [https://support.zigiwave.com](https://support.zigiwave.com/) for details on installing the ZigiOps Management Pack to vROps.
How do I create a correlation field in vROps? Contact the ZigiWave support team at [https://support.zigiwave.com](https://support.zigiwave.com/) for details on creating a correlation field in vROps.
### How do I connect vROps to ZigiOps? #### vROps - Connected System Configuration {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > vROps**. {% endstep %} {% step %} Configure the following parameters: **Server URL**\ Input the URL of your instance.\ Example: `https://vrops.example.com` **Username**\ Input the vROps integration user username. **Password**\ Input the vROps integration user password. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Examine the settings and, if they are correct, click **Save** to store the system. Once saved, vROps becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common vROps integration use cases? #### Use case 1: vROps alerts and topology forwarding to OBM Alerts, topology data, and metrics from vROps can be automatically forwarded to OBM, enabling unified event management and infrastructure visibility across VMware and operations platforms. #### Use case 2: Topology enrichment from AppDynamics, Dynatrace, and ServiceNow Application topology data from AppDynamics, Dynatrace, and NewRelic, as well as VMware instance topology from ServiceNow, can be synchronized into vROps to enrich its infrastructure model and improve operational context. ### What integration templates are available for vROps? ZigiOps provides the following integration templates for vROps: * AppDynamics application metrics - vROps metrics * AppDynamics node topology - vROps topology enrichment * AppDynamics transaction metrics - vROps metrics * Dynatrace application topology - vROps topology * NewRelic APM application host metrics - vROps metrics * ServiceNow VMware instances topology - vROps custom group members topology * ServiceNow VMware instances topology - vROps topology * vROps alerts - OBM events * vROps Linux topology - OBM topology * vROps metrics - OBM metrics * vROps topology - OBM topology * vROps Windows topology - OBM topology Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The vROps integration in ZigiOps enables: * Username and password-based connectivity for all vROps deployment types * Support for vROps 7.5.x and newer * ZigiOps Management Pack installation for extended functionality * Correlation field setup for topology enrichment workflows * Alert, topology, and metrics synchronization with OBM * Topology enrichment from AppDynamics, Dynatrace, NewRelic, and ServiceNow * Optional proxy configuration ZigiOps allows vROps to participate in enterprise-grade VMware infrastructure monitoring and IT operations ecosystems without requiring custom development. # Web Listener Learn how to configure the ZigiOps Web Listener. Accept inbound JSON payloads, extract records using document paths, and enable push-based integrations. ### What is the Web Listener in ZigiOps? The **Web Listener** is a generic ZigiOps connector designed to receive inbound HTTP requests from external systems. Unlike officially supported systems (such as Jira, ServiceNow, or monitoring tools), the Web Listener is intended for: * Systems that can send HTTP POST requests * Applications that support webhook-style integrations * Internal custom-built platforms * Middleware solutions * Event-driven architectures The Web Listener operates in a **push-based model** - external systems send data directly to ZigiOps, which then extracts the relevant records and processes them within an integration workflow. The Web Listener: * Does not have supported versions * Does not provide prebuilt templates * Is schema-driven and fully configurable ### When should I use the Web Listener? Use the Web Listener when: * The external system supports outbound webhooks * The integration must be real-time or near real-time * Polling is not desirable * The system cannot be accessed via pull-based APIs * You are integrating internal or unsupported applications ### Are there any environmental prerequisites? {% hint style="info" %} Confirm the prerequisites of the corresponding integration configuration before continuing, as some flows may require additional setup. {% endhint %} Before configuring the Web Listener, ensure: * The ZigiOps host is reachable from the external system * Required inbound ports are open * Firewall rules allow HTTP POST requests * The sending system can deliver structured JSON payloads There are no version requirements for the Web Listener. ### How does the Web Listener work? 1. ZigiOps exposes an inbound HTTP endpoint. 2. An external system sends a POST request with structured data. 3. ZigiOps parses the incoming JSON payload. 4. The configured document path extracts individual records. 5. Extracted data is mapped and synchronized to the target system. This enables real-time, event-driven integrations. ### How do I configure the Web Listener in ZigiOps? {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to the Web Listener configuration Navigate to **Connected Systems > Add New System > Generic Web Listener**. {% endstep %} {% step %} Configure the parameters Configure the following parameters: **Incoming Data Format**\ Select **JSON** as the incoming data format. **Document Extract Path**\ Input the path to the desired record(s) within the request body. Example: `records/items` This parameter defines which portion of the JSON payload will be processed as individual records. {% endstep %} {% step %} Review and save Examine the settings. Click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, the Web Listener becomes available for use within integration workflows. ### Web Listener use case scenarios #### Use case 1: Receiving monitoring alerts via webhook A monitoring platform sends alerts via HTTP POST. Web Listener receives the payload and automatically creates incidents in an ITSM system. #### Use case 2: Integrating custom internal applications An internal application sends structured JSON events whenever a business action occurs. Web Listener receives the event and synchronizes it to downstream systems. #### Use case 3: Real-time DevOps event integration A CI/CD system sends deployment notifications via webhook. ZigiOps processes the incoming payload and updates change records in an ITSM platform. #### Use case 4: Middleware event gateway An enterprise service bus forwards events from multiple systems to a centralized endpoint. Web Listener receives and distributes the events to multiple integration flows. ### Limitations and scope The Web Listener: * Accepts JSON payloads only * Requires proper document path configuration * Does not validate external schema automatically * Does not provide prebuilt templates * Operates only in a push-based model All transformation logic and mapping are defined within the integration configuration. ### Summary The Web Listener in ZigiOps provides: * Generic inbound HTTP endpoint capability * Real-time, push-based integration * Configurable JSON record extraction * Schema-driven data processing * Flexible mapping and synchronization logic It is ideal for integrating unsupported or custom-built systems that can send structured HTTP requests. # Web Poller Learn how to configure the ZigiOps Web Poller. Connect to external REST endpoints, extract data using document paths, and enable pull-based integrations. ### What is the Web Poller in ZigiOps? The **Web Poller** is a generic ZigiOps connector designed to retrieve data from external web endpoints using scheduled HTTP requests. Unlike officially supported systems (such as Jira, ServiceNow, or monitoring tools), the Web Poller is intended for: * Systems that expose REST APIs but are not natively supported * Internal custom-built applications * Middleware APIs * Legacy platforms with HTTP endpoints * Data aggregation services The Web Poller works in a **pull-based model** - ZigiOps periodically polls the configured endpoint, retrieves the response, extracts the relevant records, and processes them within an integration workflow. The Web Poller: * Does not have supported versions * Does not provide prebuilt templates * Is fully configurable and schema-driven ### When should I use the Web Poller? Use the Web Poller when: * The external system exposes a REST endpoint * The integration must be pull-based (not event-driven) * You need scheduled synchronization * The system cannot send webhooks * You are integrating with internal or unsupported applications ### Are there any environmental prerequisites? {% hint style="info" %} Confirm the prerequisites of the corresponding integration configuration before continuing, as some flows may require additional setup. {% endhint %} Before configuring the Web Poller, ensure: * The endpoint is reachable from the ZigiOps host * Required ports are open * Authentication credentials are available (if required) * The endpoint returns structured JSON or XML data There are no version requirements for the Web Poller. ### How does the Web Poller work? 1. ZigiOps sends an HTTP request to the configured URL. 2. The endpoint returns a response payload. 3. ZigiOps extracts the desired records using the defined document path. 4. Extracted data is mapped within the integration workflow. 5. Records are synchronized to the target system. This process runs based on the configured polling schedule. ### How do I configure the Web Poller in ZigiOps? #### Web Poller - Connected System Configuration Follow the steps below to add Web Poller as a connected system. {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Web Poller**. {% endstep %} {% step %} Configure the following parameters: **URL**\ Input the URL and port number of the web endpoint that returns the required response.\ Example: `https://api.example.com:8080/events` **Document Extract Path**\ Specify the path to the desired record(s) within the request body.\ Example: `parentItem/childItem` This parameter determines which portion of the JSON/XML payload will be processed as individual records. **Timestamp Format for Schema**\ Define the endpoint's timestamp format. This ensures correct parsing and schema alignment during synchronization. **Authentication**\ Select **Basic** authentication if required. If Basic authentication is selected: * **Username** - Input the username required for authentication. * **Password** - Input the password required for authentication. {% endstep %} {% step %} Examine the settings. {% endstep %} {% step %} Click **Save** to store the system. Once saved, the Web Poller becomes available for use within integration configurations. {% endstep %} {% endstepper %} ### Web Poller use case scenarios #### Use case 1: Pulling events from a custom internal API An internal application exposes operational events via REST. ZigiOps polls the endpoint every few minutes and synchronizes events into an ITSM platform. #### Use case 2: Integrating a non-supported monitoring tool A monitoring solution provides a REST endpoint but does not support outbound webhooks. Web Poller periodically retrieves alerts and forwards them to an event management system. #### Use case 3: Scheduled data synchronization A third-party system provides periodic batch updates via API. ZigiOps polls the endpoint on a schedule and synchronizes new records. #### Use case 4: Middleware data aggregation An enterprise middleware aggregates multiple data sources into a unified API. Web Poller retrieves the aggregated data and distributes it to multiple downstream systems. ### Limitations and scope The Web Poller: * Does not validate external API schemas automatically * Does not enforce version compatibility * Does not provide prebuilt templates * Requires proper document path configuration * Operates only in a pull-based model All transformation logic and mappings are defined within the integration configuration. ### Summary The Web Poller in ZigiOps provides: * Generic HTTP pull-based integration * REST endpoint connectivity * Configurable document extraction * Support for Basic authentication * Flexible schema-based mapping It is ideal for integrating unsupported, internal, or custom-built systems that expose HTTP APIs. # Webhook Learn how to configure the ZigiOps Webhook connector. Send outbound HTTP requests using POST, PUT, or PATCH with configurable authentication and JSON payload structure. ### What is the Webhook in ZigiOps? The **Webhook** is a generic ZigiOps connector designed to send outbound HTTP requests to external systems. Unlike officially supported systems (such as Jira, ServiceNow, or monitoring tools), the Webhook connector is intended for: * Systems that expose REST endpoints but are not natively supported * Custom-built internal applications * Middleware platforms * Event-driven architectures * Lightweight outbound integrations The Webhook operates in an **outbound push model** — ZigiOps sends data to an external endpoint whenever an integration event occurs. The Webhook: * Does not have supported versions * Does not provide prebuilt templates * Is fully configurable and schema-driven ### When should I use the Webhook? Use the Webhook when: * You need ZigiOps to send data to an external REST endpoint * The target system supports HTTP POST, PUT, or PATCH * You are integrating with a custom-built or unsupported platform * You want real-time outbound notifications * You are building event-driven integrations ### Are there any environmental prerequisites? {% hint style="info" %} Confirm the prerequisites of the corresponding integration configuration before continuing, as some flows may require additional setup. {% endhint %} Before configuring the Webhook, ensure: * The external endpoint is reachable from the ZigiOps host * Required outbound ports are open * Authentication credentials (if required) are available * The receiving system can process JSON payloads There are no version requirements for the Webhook connector. ### How does the Webhook work? 1. A defined integration event occurs in ZigiOps. 2. ZigiOps prepares the payload according to the configured schema. 3. ZigiOps sends an HTTP request to the specified endpoint. 4. The receiving system processes the payload. This enables real-time, event-driven outbound integrations. ### How do I configure the Webhook in ZigiOps? #### Webhook - Connected System Configuration {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to Webhook Navigate to **Connected Systems > Add New System > Webhook**. {% endstep %} {% step %} Configure the parameters Configure the following parameters: **Request Method**\ Select the desired HTTP method: * POST * PUT * PATCH **Data Format**\ Select: `JSON` **Data Location**\ Input the path to the data location in the payload.\ Example: `root/result` This defines how the outgoing data is structured. **Authentication**\ Select **Basic** authentication if required. If Basic authentication is selected: * **Username** — Input the username required to authenticate against the Webhook. * **Password** — Input the password required to authenticate against the Webhook. {% endstep %} {% step %} Examine the settings {% endstep %} {% step %} Save the system Click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, the Webhook becomes available for use within integration workflows. ### Webhook use case scenarios #### Use case 1: Sending incident updates to an internal application When an incident is updated in an ITSM system, ZigiOps sends a JSON payload to an internal application endpoint. #### Use case 2: Triggering external automation ZigiOps sends a POST request to an automation platform whenever a monitoring event is created. #### Use case 3: Integrating with unsupported SaaS platforms A SaaS application provides a REST endpoint but no official connector. Webhook enables direct outbound communication. #### Use case 4: Event-driven enterprise architecture ZigiOps acts as an event publisher, sending structured JSON payloads to a message-processing endpoint. ### Limitations and scope The Webhook: * Supports JSON payloads only * Requires proper data path configuration * Does not validate external schemas automatically * Does not provide prebuilt templates * Operates only in an outbound push model All transformation logic and mapping are defined within the integration configuration. ### Summary The Webhook connector in ZigiOps provides: * Generic outbound HTTP capability * Support for POST, PUT, and PATCH methods * Basic authentication support * Configurable JSON payload structure * Flexible integration with unsupported systems It is ideal for sending integration data to custom, internal, or non-supported external platforms. # xMatters Connect xMatters to ZigiOps. Basic Auth, API Token, and OAuth configuration, connected system setup, and integration templates for alerting and incident workflows. ### What is xMatters integration in ZigiOps? xMatters is an intelligent communications platform used for automated alerting, on-call scheduling, and incident response coordination across IT and DevOps teams. It supports multi-channel notifications and integrates with a wide range of ITSM and monitoring tools. ZigiOps enables integration between xMatters and ITSM, monitoring, and DevOps platforms. Supporting Basic Auth, API Token, and OAuth authentication methods, ZigiOps connects xMatters to external systems to support automated alert routing, incident escalation, and cross-team notification workflows. With ZigiOps, xMatters can: * Receive alerts and incidents from ITSM platforms and trigger automated notifications * Participate in bi-directional workflows between alerting and service management systems * Support automated on-call escalation and incident response coordination * Integrate with monitoring and DevOps platforms without custom scripting ### Which xMatters versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | -------- | -------------------------- | ------------------ | | xMatters | All | All | ### Are there any environmental prerequisites for xMatters? There are no environmental prerequisites for this product. ### How do I connect xMatters to ZigiOps? #### xMatters - Connected System Configuration Follow the steps below to add your xMatters instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to the xMatters connected system Navigate to **Connected Systems > Add New System > xMatters**. {% endstep %} {% step %} Configure the system parameters Configure the following parameters: **Server URL**\ Input the URL of your instance.\ Example: `https://example.xmatters.com` **Authentication Details**\ Select the desired authentication type: **Basic Auth:** * **Username** - Input your username. * **Password** - Input the password for the above user. **API Token:** * **API Key** - Input your API key. * **Client Secret** - Input your Client Secret. **OAuth:** * **Username** - Input your username. * **Password** - Input your password. * **Client Application ID** - Input your Client Application ID. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. Once saved, xMatters becomes available for use in ZigiOps integration templates. {% endstep %} {% endstepper %} ### What are the most common xMatters integration use cases? #### Use case 1: Automated alert routing from monitoring to xMatters Alerts from monitoring platforms can be forwarded through ZigiOps to xMatters, triggering automated on-call notifications and escalation workflows without manual intervention. #### Use case 2: Incident escalation between xMatters and ITSM platforms xMatters alerts and incidents can be synchronized with ITSM platforms such as ServiceNow or Jira, ensuring that critical incidents tracked in alerting systems are also visible to service management teams. ### What integration templates are available for xMatters? ZigiOps provides integration templates for xMatters. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The xMatters integration in ZigiOps enables: * Three authentication methods: Basic Auth, API Token, and OAuth * Support for all xMatters deployment types and versions * No environmental prerequisites required * Alert routing and incident escalation workflows * Integration with ITSM, monitoring, and DevOps platforms * Optional proxy configuration * Fully customizable synchronization workflows without custom scripting ZigiOps allows xMatters to participate in enterprise-grade alerting, incident response, and IT operations ecosystems without requiring custom development. # Zabbix Connect Zabbix to ZigiOps. Username and password setup, connected system configuration, and templates for topology and event synchronization with ServiceNow and OBM. ### What is Zabbix integration in ZigiOps? Zabbix is an open-source enterprise monitoring platform used for tracking the availability and performance of networks, servers, applications, and cloud services. It provides real-time monitoring, alerting, and data visualization capabilities across a wide range of IT infrastructure. ZigiOps enables integration between Zabbix and ITSM and IT operations platforms. Using username and password authentication, ZigiOps connects Zabbix to external systems to support automated topology synchronization and event forwarding workflows. With ZigiOps, Zabbix can: * Synchronize host topology data with ITSM platforms such as ServiceNow * Forward trigger events to ServiceNow as incidents or events * Synchronize topology data with OBM * Forward trigger events to OBM * Support automated incident creation based on Zabbix monitoring alerts ### Which Zabbix versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Zabbix | All | 4.2.x (or newer) | ### Are there any environmental prerequisites for Zabbix? There are no environmental prerequisites for this product. ### How do I connect Zabbix to ZigiOps? #### Zabbix - Connected System Configuration Follow the steps below to add your Zabbix instance as a connected system. {% stepper %} {% step %} Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to **Connected Systems > Add New System > Zabbix**. {% endstep %} {% step %} Configure the following parameters: * **Server URL**\ Input the URL of your instance.\ Example: `https://zabbix.example.com` * **Username**\ Input the username of your integration user. * **Password**\ Input the password of your integration user. * **Proxy Settings (optional)**\ Enables the usage of a proxy server if needed. {% endstep %} {% step %} Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, Zabbix becomes available for use in ZigiOps integration templates. ### What are the most common Zabbix integration use cases? #### Use case 1: Zabbix host topology synchronization to ServiceNow Host topology data from Zabbix can be automatically synchronized to ServiceNow, enabling automated CMDB population and infrastructure visibility within ITSM workflows. #### Use case 2: Zabbix trigger event forwarding to ServiceNow Zabbix trigger events can be forwarded to ServiceNow as incidents or events, enabling automated incident creation for IT service management teams based on real-time monitoring alerts. #### Use case 3: Zabbix topology and event synchronization with OBM Zabbix topology and trigger events can be synchronized with OBM, enabling unified event management and infrastructure visibility across monitoring and operations platforms. ### What integration templates are available for Zabbix? ZigiOps provides the following integration templates for Zabbix: * Zabbix host topology - ServiceNow topology * Zabbix topology - OBM topology * Zabbix trigger events - OBM events * Zabbix trigger events - ServiceNow events * Zabbix trigger events - ServiceNow incidents Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Zabbix integration in ZigiOps enables: * Username and password-based connectivity for all Zabbix deployment types * Support for Zabbix 4.2.x and newer * No environmental prerequisites required * Host topology synchronization with ServiceNow and OBM * Trigger event forwarding to ServiceNow and OBM * Automated incident creation from Zabbix monitoring alerts * Optional proxy configuration ZigiOps allows Zabbix to participate in enterprise-grade monitoring and IT service management ecosystems without requiring custom development. # Zendesk Connect Zendesk to ZigiOps. API token and OAuth client setup, Basic Auth, Bearer Token, and OAuth configuration, and templates for ITSM and monitoring workflows. ### What is Zendesk integration in ZigiOps? Zendesk is a cloud-based customer service and IT service management platform used by organizations to manage support tickets, customer communications, and service workflows. It is widely used across customer support, IT helpdesk, and enterprise service management teams. ZigiOps enables integration between Zendesk and ITSM, monitoring, and IT operations platforms. Supporting Basic Auth, Bearer Token, and OAuth authentication methods, ZigiOps connects Zendesk to external systems to support automated ticket creation, incident synchronization, and cross-team service workflows. With ZigiOps, Zendesk can: * Receive events from monitoring platforms such as OBM as Zendesk tickets * Participate in bi-directional workflows between customer service and IT operations systems * Support automated ticket creation and escalation based on monitoring alerts * Integrate with ITSM and DevOps platforms without custom scripting ### Which Zendesk versions are supported? {% hint style="info" %} Please note that using a supported version is mandatory. {% endhint %} | Product | Supported Deployment Types | Supported Versions | | ------- | -------------------------- | ------------------ | | Zendesk | All | All | ### Are there any environmental prerequisites for Zendesk? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How do I create an API token in Zendesk? 1. Log in to your instance. 2. Go to **Settings > Channels > API > Settings** and click **Add API Token** to create a token. 3. Copy the newly generated token for further use. #### How do I create an OAuth client in Zendesk? 1. Log in to your instance. 2. Go to **Settings > Channels > API > OAuth Clients** and click **Add OAuth Client** to create a client. 3. Copy the unique identifier (client ID) and the client secret for further use. ### How do I connect Zendesk to ZigiOps? #### Zendesk - Connected System Configuration Follow the steps below to add your Zendesk instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open Zendesk connected system setup Navigate to **Connected Systems > Add New System > Zendesk**. {% endstep %} {% step %} Configure the connection Configure the following parameters: **Server URL**\ Input the URL of your instance.\ Example: `https://example.zendesk.com` **Authentication Type**\ Select the desired authentication type: * **Basic Auth** - The platform will use the provided username and password for authentication. * **Bearer Token** - The platform will use the provided username and client application ID for authentication. * **OAuth** - The platform will use the provided username, password, client application ID, and client secret for authentication. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, Zendesk becomes available for use in ZigiOps integration templates. ### What are the most common Zendesk integration use cases? #### Use case 1: OBM events to Zendesk tickets Events from OBM (Operations Bridge Manager) can be automatically forwarded through ZigiOps to create Zendesk tickets, enabling customer service and IT teams to manage infrastructure events within their existing Zendesk workflows. #### Use case 2: Bi-directional ITSM and customer service workflow automation Zendesk tickets and records from ITSM platforms can be synchronized bidirectionally, ensuring that customer-reported issues and IT incidents are visible across both customer service and IT service management teams. ### What integration templates are available for Zendesk? ZigiOps provides the following integration template for Zendesk: * OBM events - Zendesk tickets Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Zendesk integration in ZigiOps enables: * Three authentication methods: Basic Auth, Bearer Token, and OAuth * Support for all Zendesk deployment types and versions * API token and OAuth client setup in Zendesk Settings * Event-to-ticket workflows from OBM and other monitoring platforms * Bi-directional ITSM and customer service workflows * Optional proxy configuration ZigiOps allows Zendesk to participate in enterprise-grade customer service, ITSM, and IT operations ecosystems without requiring custom development. # Zendesk Sell Connect Zendesk Sell to ZigiOps. OAuth API token setup, connected system configuration, and integration templates for CRM and sales lead workflows. ### What is Zendesk Sell integration in ZigiOps? Zendesk Sell is a sales CRM platform used for managing leads, contacts, deals, and sales pipelines. It provides sales teams with tools for activity tracking, pipeline visibility, and customer engagement across the sales lifecycle. ZigiOps enables integration between Zendesk Sell and other CRM, ITSM, and communication platforms. Using OAuth-based API token authentication, ZigiOps connects Zendesk Sell to external systems to support automated lead creation, sales data synchronization, and cross-team workflows. With ZigiOps, Zendesk Sell can: * Receive incoming email leads and automatically create Zendesk Sell lead records * Participate in bi-directional workflows between CRM and other business platforms * Support automated sales data synchronization across connected systems * Integrate with communication and ITSM tools without custom scripting ### Which Zendesk Sell versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ------------ | -------------------------- | ------------------ | | Zendesk Sell | All | All | ### Are there any environmental prerequisites for Zendesk Sell? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} ### How do I create an API token in Zendesk Sell? {% stepper %} {% step %} Log in to Zendesk Sell Log in to your instance using your credentials and navigate to the **OAuth 2 Settings** page. {% endstep %} {% step %} Add a user token In the **Access Tokens** section, click **+Add User Token**. {% endstep %} {% step %} Save the token Fill in the **Description** field and click **Save**. {% endstep %} {% step %} Copy the access token A modal window will display your newly generated access token. Copy the access token and store it for further use, as it will be required during your first call. {% endstep %} {% endstepper %} {% hint style="warning" %} Once the modal window is closed, it is impossible to retrieve your access token. If you cannot find your token information, you will need to generate a new token. {% endhint %} ### How do I connect Zendesk Sell to ZigiOps? #### Zendesk Sell - Connected System Configuration Follow the steps below to add your Zendesk Sell instance as a connected system. {% stepper %} {% step %} Log in to ZigiOps Log in to your **ZigiOps** instance. {% endstep %} {% step %} Open Zendesk Sell connected systems Navigate to **Connected Systems > Add New System > Zendesk Sell**. {% endstep %} {% step %} Configure the system Configure the following parameters: **Server URL**\ Input the URL of your instance.\ Example: `https://zendesksell.example.com` **API Token**\ Input the Zendesk Sell API token. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, Zendesk Sell becomes available for use in ZigiOps integration templates. ### What are the most common Zendesk Sell integration use cases? #### Incoming email leads to Zendesk Sell Incoming email communications can be automatically processed by ZigiOps and converted into Zendesk Sell lead records, enabling sales teams to capture and track new leads without manual data entry. ### What integration templates are available for Zendesk Sell? ZigiOps provides the following integration template for Zendesk Sell: * Incoming Emails - Zendesk Sell leads Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact for detailed template availability. ### Summary The Zendesk Sell integration in ZigiOps enables: * OAuth API token-based authentication for all Zendesk Sell deployment types * Support for all Zendesk Sell versions * Automated lead creation from incoming email communications * CRM data synchronization workflows * Important: API tokens cannot be retrieved after the modal is closed; store them immediately * Optional proxy configuration ZigiOps allows Zendesk Sell to participate in enterprise-grade CRM and sales automation ecosystems without requiring custom development. # Zoho ME OpManager Connect Zoho ManageEngine OpManager to ZigiOps. REST API key setup, connected system configuration, and integration templates for network monitoring workflows. ### What is Zoho ME OpManager integration in ZigiOps? Zoho ManageEngine OpManager (Zoho ME OpManager) is a network and infrastructure monitoring platform used for tracking the availability and performance of servers, routers, switches, firewalls, and other network devices across enterprise environments. ZigiOps enables integration between Zoho ME OpManager and ITSM, service management, and IT operations platforms. Using REST API key authentication, ZigiOps connects Zoho ME OpManager to external systems to support automated alert forwarding and cross-team operational workflows. With ZigiOps, Zoho ME OpManager can: * Forward network monitoring alerts to ITSM platforms such as ServiceNow or Jira * Participate in bi-directional workflows between network monitoring and service management systems * Support automated incident creation based on OpManager monitoring events * Integrate with IT operations and observability platforms without custom scripting ### Which Zoho ME OpManager versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | --------------------------- | -------------------------- | ------------------ | | Zoho ManageEngine OpManager | All | All | ### Are there any environmental prerequisites for Zoho ME OpManager? {% hint style="info" %} Confirm the prerequisites of the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How do I generate a REST API key in Zoho ME OpManager? 1. Log in to your instance. 2. Go to **Settings > REST API Key** and toggle the **Enable REST API Access** option. 3. Copy an existing or a newly generated REST API Key, which is needed when setting up the Zoho ME OpManager system in ZigiOps. ### How do I connect Zoho ME OpManager to ZigiOps? #### Zoho ME OpManager - Connected System Configuration Follow the steps below to add your Zoho ME OpManager instance as a connected system. {% stepper %} {% step %} Log in to your ZigiOps instance. Log in to your **ZigiOps** instance. {% endstep %} {% step %} Navigate to the Zoho ME OpManager connected system. Navigate to **Connected Systems > Add New System > Zoho ME OpManager**. {% endstep %} {% step %} Configure the parameters. Configure the following parameters: **Server URL**\ Input the URL and corresponding port of your instance.\ Example: `https://zoho.example.com:8061` **API Key**\ ZigiOps will use the provided REST API Key to authenticate against Zoho's API. **Proxy Settings (optional)**\ Enables the usage of a proxy server. {% endstep %} {% step %} Save the system. Examine the settings and, if they are correct, click **Save** to store the system. {% endstep %} {% endstepper %} Once saved, Zoho ME OpManager becomes available for use in ZigiOps integration templates. ### What are the most common Zoho ME OpManager integration use cases? #### Use case 1: Network alert forwarding to ITSM Network monitoring alerts and events from Zoho ME OpManager can be automatically forwarded to ITSM platforms such as ServiceNow or Jira, creating incidents for operations teams without manual intervention. #### Use case 2: Cross-platform network and operations workflow automation Zoho ME OpManager events can be correlated with data from ITSM or other monitoring platforms, enabling unified alerting and automated response workflows across network and IT operations teams. ### What integration templates are available for Zoho ME OpManager? ZigiOps provides integration templates for Zoho ME OpManager. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The Zoho ME OpManager integration in ZigiOps enables: * REST API key authentication for all Zoho ME OpManager deployment types * Support for all Zoho ME OpManager versions * Port-inclusive URL configuration for the connected system * Network alert forwarding to ITSM and operations platforms * Automated incident creation from OpManager monitoring events * Optional proxy configuration * Fully customizable synchronization workflows without custom scripting ZigiOps allows Zoho ME OpManager to participate in enterprise-grade network monitoring and IT service management ecosystems without requiring custom development. # Zoho ME ServiceDesk Plus Connect Zoho ManageEngine ServiceDesk Plus to ZigiOps. Client ID and Client Secret setup via Zoho API Console, connected system configuration, and integration templates. ### What is Zoho ME ServiceDesk Plus integration in ZigiOps? Zoho ManageEngine ServiceDesk Plus (Zoho ME ServiceDesk Plus) is an ITSM platform used for IT service management, incident tracking, asset management, and change management. It is available in on-premises and cloud deployment models and supports a wide range of enterprise service management workflows. ZigiOps enables integration between Zoho ME ServiceDesk Plus and other ITSM, DevOps, and monitoring platforms. Using OAuth-based Client ID and Client Secret authentication via the Zoho API Console, ZigiOps connects Zoho ME ServiceDesk Plus to external systems to support automated ticket synchronization and cross-team service workflows. With ZigiOps, Zoho ME ServiceDesk Plus can: * Sync incidents and service requests with platforms such as Jira or ServiceNow * Receive monitoring alerts as ServiceDesk Plus tickets * Participate in bi-directional workflows between ITSM and DevOps systems * Support automated escalation and routing of service management cases ### Which Zoho ME ServiceDesk Plus versions are supported? Please note that using a supported version is mandatory. | Product | Supported Deployment Types | Supported Versions | | ---------------------------------- | -------------------------- | ------------------ | | Zoho ManageEngine ServiceDesk Plus | All | All | ### Are there any environmental prerequisites for Zoho ME ServiceDesk Plus? {% hint style="info" %} Confirm the prerequisites for the corresponding integration template before continuing, as some templates may not require all environmental prerequisites. {% endhint %} #### How do I create or get a Client ID and Client Secret for Zoho ME ServiceDesk Plus? 1. Go to the Zoho API Console by navigating to and logging in with your Zoho account. 2. Add a new client by clicking **Add Client** and choosing **Self Client** from the list of client types. If a confirmation pop-up appears, click **OK** to enable it. 3. Once the Self Client is created, click on it on the API Console main page to retrieve your Client ID and Client Secret. 4. Go to the **Client Secret** tab - your Client ID and Client Secret are displayed there. ### How do I connect Zoho ME ServiceDesk Plus to ZigiOps? #### Zoho ME ServiceDesk Plus - Connected System Configuration Follow the steps below to add your Zoho ME ServiceDesk Plus instance as a connected system. 1. Log in to your **ZigiOps** instance. 2. Navigate to **Connected Systems > Add New System > Zoho ME ServiceDesk Plus**. 3. Configure the following parameters: **URL**\ Input the URL of your instance.\ Example: `https://sdpondemand.manageengine.com` **Portal**\ Input the portal name of your instance. The portal name is typically the part of the URL path after `/app/`.\ Example: For `https://sdpondemand.manageengine.com/app/yourPortal/...`, the portal name is `yourPortal`. **Client ID**\ Input your Client ID. **Client Secret**\ Input your Client Secret. **Proxy Settings (optional)**\ Enables the usage of a proxy server. 4. Examine the settings and, if they are correct, click **Save** to store the system. Once saved, Zoho ME ServiceDesk Plus becomes available for use in ZigiOps integration templates. ### What are the most common Zoho ME ServiceDesk Plus integration use cases? #### Use case 1: Incident synchronization between Zoho ME ServiceDesk Plus and Jira Incidents created in Zoho ME ServiceDesk Plus can be automatically mirrored as Jira issues for development or operations teams. Updates made in Jira are synchronized back to ServiceDesk Plus, keeping ITSM records current. #### Use case 2: Monitoring alert escalation to Zoho ME ServiceDesk Plus Infrastructure alerts from monitoring platforms can be forwarded through ZigiOps to create or update ServiceDesk Plus tickets, enabling automated incident creation without manual data entry. ### What integration templates are available for Zoho ME ServiceDesk Plus? ZigiOps provides integration templates for Zoho ME ServiceDesk Plus. Each template includes: * Predefined entity mappings * Direction of synchronization * Entity-specific logic and filtering rules Contact the ZigiWave support team at for more information regarding available templates for this system. ### Summary The Zoho ME ServiceDesk Plus integration in ZigiOps enables: * OAuth-based authentication using Client ID and Client Secret from the Zoho API Console * Support for all Zoho ME ServiceDesk Plus deployment types and versions * Portal name configuration for instance identification * Integration with Jira, ServiceNow, monitoring platforms, and other systems * Incident and service request synchronization workflows * Optional proxy configuration * Fully customizable synchronization workflows without custom scripting ZigiOps allows Zoho ME ServiceDesk Plus to participate in enterprise-grade ITSM and automation ecosystems without requiring custom development. # Installation & Deployment Get ZigiOps up and running with step-by-step installation guides for Linux and Windows, plus disaster recovery, upgrade, and scaling configurations. Everything you need to get ZigiOps up and running — system requirements, step-by-step installation guides for Linux and Windows, disaster recovery setup, upgrade procedures, and scaling configurations. {% content-ref url="/pages/bd6d37860d4736188cf45fc1c3a585551d6d04b3" %} [Installation General](/installation-and-deployment/installation-general) {% endcontent-ref %} {% content-ref url="/pages/822c9a6b56d1f02b1e55e8fad54879e997aebc76" %} [Installation Windows](/installation-and-deployment/installation-windows) {% endcontent-ref %} {% content-ref url="/pages/b24694444fef5782f01eeb20287f035430437e03" %} [Installation Linux](/installation-and-deployment/installation-linux) {% endcontent-ref %} {% content-ref url="/pages/81f21ce08c3eb456135e4a3e771bf87cb4ebe39d" %} [Scaling and Sizing](/installation-and-deployment/scaling-and-sizing) {% endcontent-ref %} # Installation General This page summarizes the main installation steps for ZigiOps. Detailed instructions are available in the dedicated OS pages. ZigiOps can be deployed on **Linux**, **Windows**, or used as a fully managed **Cloud (SaaS)** service. *** ## Which Deployment Options Require Installation? * **On-premises (Linux or Windows):** Installation is required. * **Cloud (SaaS):** No installation required. You receive a URL and login credentials and can start using ZigiOps immediately. *** ## What Should I Prepare Before Installing ZigiOps? Before starting installation: * Check [System Requirements](/integration-platform/system-requirements) (OS, CPU/RAM, ports, Java, connectivity). * Verify you have the necessary permissions: * **Linux:** root or sudo access * **Windows:** administrator rights * Ensure network access to all systems you plan to integrate. *** ## How Do I Install ZigiOps on Linux?
For full steps, see [Install on Linux.](/installation-and-deployment/installation-linux) **Main steps:** {% stepper %} {% step %} Upload the installer JAR to the Linux server. {% endstep %} {% step %} Run the installer with sudo: ```bash sudo java -jar zigiops-installer.jar ``` {% endstep %} {% step %} Follow the GUI or console mode wizard. {% endstep %} {% step %} Set the installation directory, ports, and service settings. {% endstep %} {% step %} Start the ZigiOps service and confirm it is running. {% endstep %} {% step %} Open the ZigiOps URL in a browser and log in. {% endstep %} {% endstepper %} *** ## How Do I Install ZigiOps on Windows? For full steps, see [Install on Windows.](/installation-and-deployment/installation-windows) **Main steps:** {% stepper %} {% step %} Copy the installer JAR to the Windows host. {% endstep %} {% step %} Run it as Administrator (via right-click or elevated Command Prompt). {% endstep %} {% step %} Complete the installation wizard: directory, ports, and service options. {% endstep %} {% step %} Verify the ZigiOps Windows service is running. {% endstep %} {% step %} Open the ZigiOps URL in a browser and log in. {% endstep %} {% endstepper %} *** ## What Changes With ZigiOps Cloud (SaaS)? * No installation required. * ZigiWave provides a cloud URL and credentials or SSO. * Your team only configures systems and workflows in the web UI. *** ## What Should I Do After Installation? * Verify access to the ZigiOps web UI. * Apply required security settings (HTTPS, firewall rules). * Add connected systems. * Load templates or create workflows. # Installation Windows This page provides the complete installation guide for running ZigiOps on a Windows server. This page covers prerequisites, installer launch, setup wizard steps, service management, and post-installation tasks. *** ## What Are the Prerequisites for Installing ZigiOps on Windows? Before installing ZigiOps, ensure the following conditions are met. ### Supported Windows Versions ZigiOps supports modern Windows Server editions. See the full list in [System Requirements.](/integration-platform/system-requirements) ### Required Permissions You must have **local Administrator rights** on the Windows server to run the installer and configure services. ### Java Requirements ZigiOps ships with its own embedded Java environment, so no separate Java installation is typically needed unless stated in additional requirements. ### Network and Ports Confirm the following: * The ZigiOps UI port (HTTPS) can be opened in Windows Firewall. * Outbound connectivity exists to all systems ZigiOps must integrate with (ServiceNow, Jira, Azure DevOps, monitoring tools, and others). * Any proxies, SSL inspection, or NAC policies are accounted for. ### System Resources Follow CPU, RAM, disk, and network guidelines from the [System Requirements](/integration-platform/system-requirements) page. *** ## How Do I Download and Prepare the ZigiOps Installer on Windows? 1. Download the ZigiOps installer from ZigiWave. 2. Copy it to the target Windows host. 3. Ensure you can run it with **Administrator** privileges: * Right-click and select **Run as Administrator** * If this option does not appear, run it via an elevated command prompt *** ## How Do I Run the ZigiOps Installer on Windows? You can start the installer in two ways. ### Option 1: Use "Run as Administrator" (Recommended) In File Explorer: 1. Right-click the installer `.jar` file. 2. Select **Run as Administrator**. If available, this method automatically runs the installer with the proper elevation. ### Option 2: Use an Elevated Command Prompt If the right-click option is unavailable: 1. Open **Command Prompt as Administrator**: Start menu, search for "cmd", right-click, and select **Run as Administrator**. 2. Navigate to the installer directory: ```bash cd C:\Installers\ZigiOps\ ``` 3. Run the installer manually: ```bash java -jar "zigiwave-zigiops-installer.jar" ``` This ensures the installation wizard launches with the required privileges. *** ## What Steps Do I Follow in the Windows Installation Wizard? {% stepper %} {% step %} ### Welcome Screen Click **Next** to begin. {% endstep %} {% step %} ### License Agreement You must accept the ZigiOps license to proceed. {% endstep %} {% step %} ### Select Installation Folder Choose where ZigiOps will be installed. Common path: ```bash C:\ZigiWave\ZigiOps\ ``` You may customize this according to company policies. {% endstep %} {% step %} ### Configure Ports Set the HTTPS port for the ZigiOps UI. Ensure the ports you select are free and allowed through Windows Firewall. {% endstep %} {% step %} ### Configure the ZigiOps Installation Packages All packages are mandatory on Windows. {% endstep %} {% step %} ### Installation The wizard installs the ZigiOps files, registers the Windows service, and prepares the runtime environment. {% endstep %} {% step %} ### Completion A final screen confirms successful installation and provides the next steps. {% endstep %} {% endstepper %} *** ## How Do I Start and Manage the ZigiOps Service on Windows? After installation, ZigiOps appears in the **Services** console as a Windows service. ### Open Services 1. Press **Win + R** 2. Type `services.msc` 3. Press **Enter** ### Start, Stop, or Restart the Service Locate **ZigiWave ZigiOps** and: * **Start:** right-click and select *Start* * **Stop:** right-click and select *Stop* * **Restart:** right-click and select *Restart* *** ## How Do I Verify the Installation Was Successful? ### 1. Check Service Status Ensure the ZigiOps service is displayed as **Running** in `services.msc`. ### 2. Verify Listening Ports Use PowerShell: ```bash Get-NetTCPConnection -LocalPort ``` *** ## How Do I Access the ZigiOps Web Interface After Installation? Open your preferred browser and navigate to: ```bash https://:/ ``` Use the default ZigiOps credentials, after which you will be prompted to set your own password. If a self-signed certificate is used initially, your browser may display a security warning. This is expected. *** ## What Post-Installation Steps Should I Complete? {% stepper %} {% step %} ### Secure the Deployment * Replace self-signed certificates with trusted certificates * Configure firewall rules * Set user roles and permissions in ZigiOps {% endstep %} {% step %} ### Add Connected Systems In the ZigiOps UI, go to **Systems** and add the systems you plan to integrate (ServiceNow, Jira, Azure DevOps, monitoring tools, and others). {% endstep %} {% step %} ### Create or Load Integration Workflows Use: * Pre-built templates, or * Custom workflows for your use cases {% endstep %} {% endstepper %} *** # Installation Linux This page provides the complete installation guide for running ZigiOps on a Linux machine. This page includes prerequisites, installer preparation, GUI/console installation, service management, and post-installation steps. *** ## What Are the Prerequisites for Installing ZigiOps on Linux? Before starting the installation, ensure the following conditions are met. ### Supported Operating Systems ZigiOps supports major Linux distributions. Recommended versions are listed in the [System Requirements](/integration-platform/system-requirements) page. ### Required Permissions You need **root or sudo privileges** to run the installer. ### Java Requirements The installer runs as a standalone `.jar` package and uses the embedded Java runtime that ships with ZigiOps. No separate manual Java installation is required unless using a custom runtime. ### Network and Ports Confirm the following: * You can open the port that ZigiOps listens on (the HTTPS UI port). * Outbound connectivity is available to the systems you plan to integrate (for example, Jira, ServiceNow, or other ITSM and monitoring tools). * Firewalls allow traffic according to your security policies. ### System Resources Follow the recommended CPU, RAM, and disk guidelines from [System Requirements](broken://pages/98ef6561e252bbe0be3ca3cff01f0f0a6a2e9b77). *** ## How Do I Download and Prepare the ZigiOps Installer on Linux? {% stepper %} {% step %} ### Obtain the installer Obtain the ZigiOps installer from ZigiWave. {% endstep %} {% step %} ### Copy it to the target server Copy it to the target Linux server. {% endstep %} {% step %} ### Make it executable Ensure you have permission to execute it: ```bash sudo chmod +x zigiwave-zigiops-installer.jar ``` {% endstep %} {% step %} ### Have sudo access ready Have sudo access ready, as installation requires elevated privileges. {% endstep %} {% endstepper %} *** ## How Do I Run the ZigiOps Installer in GUI or Console Mode? The ZigiOps installer supports two modes: * **GUI mode** (graphical interface) * **Console mode** (terminal-based wizard) ### Launching the Installer Run the installer using: ```bash sudo java -jar /zigiwave-zigiops-installer.jar ``` Replace `` with the directory containing the file. ### When Does GUI Mode Appear? If your system has **X11 libraries** installed and supports graphical output, the installer will automatically start in GUI mode. This is useful when installing from a desktop-enabled environment. ### When Does It Switch to Console Mode? If X11 libraries are not installed (which is typical for servers), the installer **automatically falls back to console mode** and presents an interactive, terminal-based wizard. No additional flags are required - ZigiOps detects the mode automatically. *** ## What Steps Do I Follow in the Installation Wizard? Regardless of GUI or console mode, the installer guides you through the same steps: 1. **Welcome screen** - A brief introduction to ZigiOps installation. 2. **License Agreement** - You must read and accept the license to proceed. 3. **Select Installation Directory** - Choose where ZigiOps will be installed (for example, `/opt/zigiops`). The path must allow write permissions for the ZigiOps service user. 4. **Configure Ports** - Set the Web UI port (HTTPS) and any listener ports used by your workflows. 5. **Configure Service Settings** - Including service run user (default: root, or a designated user if allowed) and optional JVM settings. 6. **Confirm Settings and Install** - Once confirmed, the installer copies all required files, configures ZigiOps as a Linux service, and prepares runtime directories and dependencies. 7. **Completion** - The wizard displays a success message and instructions to start the service. *** ## How Do I Start and Manage the ZigiOps Service on Linux? After installation, ZigiOps is registered as a Linux service (systemd-based). **Start the service:** ```bash sudo systemctl start zigiops ``` **Stop the service:** ```bash sudo systemctl stop zigiops ``` **Restart the service:** ```bash sudo systemctl restart zigiops ``` **Check service status:** ```bash sudo systemctl status zigiops ``` **Enable automatic startup on boot:** ```bash sudo systemctl enable zigiops ``` > If your distribution uses a different service name, the installation wizard will display it. *** ## How Do I Verify the Installation Was Successful? {% stepper %} {% step %} ### Check service status Ensure `active (running)` is displayed. {% endstep %} {% step %} ### Verify that the required ports are listening ```bash sudo netstat -tulpn | grep ``` {% endstep %} {% step %} ### Review logs Check the ZigiOps log directory (typically inside the installation folder) for startup messages or errors. {% endstep %} {% step %} ### Test the UI Open a browser and check whether the ZigiOps login page loads successfully. {% endstep %} {% endstepper %} *** ## How Do I Access the ZigiOps Web Interface After Installation? Open a browser and navigate to: ```bash https://:/ ``` **Notes:** * The installer sets ZigiOps to use **HTTPS**. * If you are using a self-signed certificate, your browser may display a security warning. This is expected during initial installations. * Use the default ZigiOps credentials, after which you will be asked to set your own password. *** ## What Post-Installation Steps Should I Complete? {% stepper %} {% step %} ### Secure Access * Replace self-signed certificates with production certificates * Restrict access via firewall rules * Configure authentication and user rights {% endstep %} {% step %} ### Add Your Systems Go to **Systems** and start connecting systems such as ServiceNow, Jira, Azure DevOps, Dynatrace, AppDynamics, and more. {% endstep %} {% step %} ### Load or Create Integration Workflows * Use built-in templates, or * Create custom workflows matching your data flow requirements {% endstep %} {% step %} ### Configure Backups or Monitoring (Optional) Integrate with your logging/monitoring stack for ongoing health visibility. {% endstep %} {% endstepper %} *** # Docker Deployment Guide Step-by-step guide to deploying ZigiOps using Docker. Learn how to run, upgrade, roll back, and configure the ZigiOps container image. ZigiOps can be deployed as a self-hosted Docker container, bundling all required services into a single image. This deployment model is suited for organizations that use containerized infrastructure and want a portable, self-managed ZigiOps installation. The Docker image includes the following ZigiOps services: * Platform * Frontend * Persistence * Troubleshooting All services start sequentially inside the container. Startup typically takes 1-2 minutes. *** ### Prerequisites Before you begin, make sure the following requirements are met: * Docker Engine is installed and running on the target host. * The target host has internet access to download the ZigiOps image archive (or the archive has been transferred manually). * A valid ZigiOps license file has been provided by ZigiWave. * Port 8080 is available on the host for the ZigiOps UI. Additional ports may be needed for listener endpoints. *** ### Downloading the Docker Image The ZigiOps Docker image is distributed as a `.tar` archive. Download the image for your target version from the following URL: ``` https://download.zigiwave.com/zigiops/docker/zigiwave.zigiops.{build-number}.tar ``` Replace `{build-number}` with the specific version number for your deployment. After downloading, load the image: ```bash docker load -i zigiwave.zigiops..tar ``` *** ### Named Volumes Named volumes are used so that data survives both container restarts and upgrades. Create the following volumes once and reuse them across all deployments: | Volume Name | Container Path | Notes | | ------------------------------ | ------------------------------- | ------------------------------ | | `zigiops-persistence-conf` | `/zigiops/persistence/conf` | Seeded from image on first run | | `zigiops-persistence-logs` | `/zigiops/persistence/logs` | Output only | | `zigiops-troubleshooting-data` | `/zigiops/troubleshooting/data` | Seeded from image on first run | | `zigiops-troubleshooting-logs` | `/zigiops/troubleshooting/logs` | Output only | | `zigiops-frontend-logs` | `/zigiops/frontend/logs` | Output only | | `zigiops-platform-audit` | `/zigiops/platform/audit` | Output only | | `zigiops-platform-conf` | `/zigiops/platform/conf` | Seeded from image on first run | | `zigiops-platform-logs` | `/zigiops/platform/logs` | Output only | > **Note:** Volumes marked "Seeded from image on first run" are declared as `VOLUME` in the Dockerfile. Docker copies the default content from the image into the volume automatically the first time the container starts. On subsequent runs, including upgrades, the existing volume content is preserved and the image content is ignored. *** ### Scenario 1: Clean New Deployment Use this when deploying ZigiOps for the first time on a host with no existing data. {% stepper %} {% step %} **Load the image** ```bash docker load -i zigiwave.zigiops...tar ``` {% endstep %} {% step %} **Create named volumes** Run once. Skip if volumes already exist. ```bash docker volume create zigiops-persistence-conf docker volume create zigiops-persistence-logs docker volume create zigiops-troubleshooting-data docker volume create zigiops-troubleshooting-logs docker volume create zigiops-frontend-logs docker volume create zigiops-platform-audit docker volume create zigiops-platform-conf docker volume create zigiops-platform-logs ``` {% endstep %} {% step %} **Run the container** ```bash docker run -d \ --name zigiops \ --restart unless-stopped \ -p 8080:8080 \ -v zigiops-persistence-conf:/zigiops/persistence/conf \ -v zigiops-persistence-logs:/zigiops/persistence/logs \ -v zigiops-troubleshooting-data:/zigiops/troubleshooting/data \ -v zigiops-troubleshooting-logs:/zigiops/troubleshooting/logs \ -v zigiops-frontend-logs:/zigiops/frontend/logs \ -v zigiops-platform-audit:/zigiops/platform/audit \ -v zigiops-platform-conf:/zigiops/platform/conf \ -v zigiops-platform-logs:/zigiops/platform/logs \ zigiwave/zigiops: ``` The ZigiOps UI is available at `http://:8080` once all services have started. {% endstep %} {% endstepper %} *** ### Scenario 2: Restart Use this to restart the container without losing any data or configuration. Named volumes ensure all data is preserved automatically. ```bash docker restart zigiops ``` Or stop and start separately: ```bash docker stop zigiops docker start zigiops ``` *** ### Scenario 3: Upgrade Use this when deploying a new version of ZigiOps over an existing installation. The same named volumes are reused, so all data and configuration is preserved. {% stepper %} {% step %} **Load the new image** ```bash docker load -i zigiwave.zigiops...tar ``` {% endstep %} {% step %} **Stop and remove the current container** ```bash docker stop zigiops docker rm zigiops ``` > **Note:** The named volumes are not removed by `docker rm`. All data is safe. > {% endstep %} {% step %} **Run the new container with the same volumes** ```bash docker run -d \ --name zigiops \ --restart unless-stopped \ -p 8080:8080 \ -v zigiops-persistence-conf:/zigiops/persistence/conf \ -v zigiops-persistence-logs:/zigiops/persistence/logs \ -v zigiops-troubleshooting-data:/zigiops/troubleshooting/data \ -v zigiops-troubleshooting-logs:/zigiops/troubleshooting/logs \ -v zigiops-frontend-logs:/zigiops/frontend/logs \ -v zigiops-platform-audit:/zigiops/platform/audit \ -v zigiops-platform-conf:/zigiops/platform/conf \ -v zigiops-platform-logs:/zigiops/platform/logs \ zigiwave/zigiops: ``` > **Configuration note:** The conf volumes (`zigiops-persistence-conf`, `zigiops-platform-conf`) are not re-seeded from the new image during an upgrade. Docker keeps the existing volume content. If the new version introduces changes to default configuration files, those changes must be applied manually. To inspect what the new image ships as defaults before upgrading: ```bash docker run --rm zigiwave/zigiops: cat /zigiops/platform/conf/ ``` {% endstep %} {% endstepper %} *** ### Rollback If an upgrade needs to be rolled back, stop the new container and rerun the previous image version with the same volumes: ```bash docker stop zigiops docker rm zigiops docker run -d \ --name zigiops \ --restart unless-stopped \ -p 8080:8080 \ -v zigiops-persistence-conf:/zigiops/persistence/conf \ -v zigiops-persistence-logs:/zigiops/persistence/logs \ -v zigiops-troubleshooting-data:/zigiops/troubleshooting/data \ -v zigiops-troubleshooting-logs:/zigiops/troubleshooting/logs \ -v zigiops-frontend-logs:/zigiops/frontend/logs \ -v zigiops-platform-audit:/zigiops/platform/audit \ -v zigiops-platform-conf:/zigiops/platform/conf \ -v zigiops-platform-logs:/zigiops/platform/logs \ zigiwave/zigiops: ``` *** ### Useful Commands ```bash # View container logs docker logs zigiops # Follow logs in real time docker logs -f zigiops # Open a shell inside the running container docker exec -it zigiops bash # List all named volumes docker volume ls # Inspect a volume (shows mount path on host) docker volume inspect zigiops-platform-conf # Remove the old image after a successful upgrade docker rmi zigiwave/zigiops: ``` *** ### Optional Steps #### Opening an Additional Custom Port Some integrations require an extra port to be exposed. Add a `-p` flag to the `docker run` command for each additional port needed. Multiple ports can be added by repeating the flag: ```bash -p 9090:9090 -p 9091:9091 ``` #### Adding a Custom Certificate to the Truststore Some connected systems use certificates that are not trusted by default. These must be imported into the truststore. The truststore is not a declared `VOLUME` in the Dockerfile, so the volume must be created and seeded manually before importing the certificate. {% stepper %} {% step %} **Create the truststore volume** ```bash docker volume create zigiops-platform-truststore ``` {% endstep %} {% step %} **Seed the volume with the default truststore from the image** Mount the volume at a separate `/target` path so the original image path remains accessible for copying: ```bash docker run --rm \ -v zigiops-platform-truststore:/target \ zigiwave/zigiops: \ cp -r /zigiops/platform/truststore/. /target/ ``` {% endstep %} {% step %} **Import the custom certificate** Place the certificate file (`.pem` or `.cer`) on the Docker host, then run `keytool` inside a temporary container: ```bash docker run --rm \ -v zigiops-platform-truststore:/zigiops/platform/truststore \ -v /path/to/custom-cert.pem:/tmp/custom-cert.pem \ zigiwave/zigiops: \ keytool -import -trustcacerts -alias custom-cert \ -file /tmp/custom-cert.pem \ -keystore /zigiops/platform/truststore/truststore.jks \ -storepass -noprompt ``` {% endstep %} {% step %} **Run the container with the truststore volume** Add the truststore volume mount to the `docker run` command alongside the standard volumes: ```bash docker run -d \ --name zigiops \ --restart unless-stopped \ -p 8080:8080 \ -v zigiops-persistence-conf:/zigiops/persistence/conf \ -v zigiops-persistence-logs:/zigiops/persistence/logs \ -v zigiops-troubleshooting-data:/zigiops/troubleshooting/data \ -v zigiops-troubleshooting-logs:/zigiops/troubleshooting/logs \ -v zigiops-frontend-logs:/zigiops/frontend/logs \ -v zigiops-platform-audit:/zigiops/platform/audit \ -v zigiops-platform-conf:/zigiops/platform/conf \ -v zigiops-platform-logs:/zigiops/platform/logs \ -v zigiops-platform-truststore:/zigiops/platform/truststore \ zigiwave/zigiops: ``` > **Note:** The truststore volume persists across restarts and upgrades. Additional certificates can be imported at any time by repeating Step 3 with a different `-alias` value, without needing to restart the container. > {% endstep %} > {% endstepper %} *** ### Related Documentation * [Deployment Options](/integration-platform/deployment-options) * [Installation on Linux](/installation-and-deployment/installation-linux) * [Installation on Windows](/installation-and-deployment/installation-windows) * [System Requirements](/integration-platform/system-requirements) # Scaling and Sizing This page provides guidance on scaling and sizing your ZigiOps deployment based on the expected amount of integration data flowing through your integrations. Depending on the integration use case, data volume, and deployment scenario, ZigiOps supports two complementary scaling approaches: * Vertical scaling * Horizontal scaling ## How Do You Choose the Right Deployment Size? ### Deployment Types Overview The table below provides recommendations on which deployment type to use, based on the average expected integration throughput. Use this table as a starting point when planning a new deployment or evaluating growth. | Deployment | Configuration Items | Events per Second | Metrics per Second | ITSM / DevOps Records per Second | | -------------- | ------------------- | ----------------- | ------------------ | -------------------------------- | | **Small** | Up to 10,000 | 100 | 100 | 100 | | **Enterprise** | 10,000 to 100,000 | 200 | 300 | 200 | ## What Infrastructure Resources Are Required? ### Infrastructure Requirements by Deployment Type The table below provides recommendations for CPU, memory, and disk resources based on the selected deployment size. Actual requirements may vary depending on integration complexity, transformation logic, and workflow design. | Deployment | CPU | Memory | Disk | | -------------- | ------------------------------------- | ------ | ----- | | **Small** | Dual-Core Processor (2.8 GHz or more) | 4 GB | 10 GB | | **Enterprise** | Quad-Core Processor (2.8 GHz or more) | 8 GB | 20 GB | ## Scaling Strategies in ZigiOps ZigiOps supports two primary scaling strategies. These approaches can be used independently or combined, depending on growth patterns and architecture requirements. ## Vertical Scaling ### What Is Vertical Scaling? Vertical scaling increases the capacity of a ZigiOps deployment by adding more resources to an existing server. This can be achieved by: * Increasing CPU cores * Increasing memory (RAM) * Increasing available disk space ### When Should You Use Vertical Scaling? Vertical scaling is suitable when: * You are within the Small or Enterprise deployment range * You want a quick capacity increase * You prefer to avoid architectural changes ## Horizontal Scaling ### What Is Horizontal Scaling? Horizontal scaling increases capacity by adding more ZigiOps instances and distributing the workload across multiple servers. This approach enables ZigiOps to handle significantly higher data volumes and parallel workloads. Horizontal scaling is recommended when the actual data volume exceeds the Enterprise deployment thresholds. ## General Recommendations * Start with **vertical scaling** for predictable growth * Move to **horizontal scaling** for high-volume or enterprise-wide integrations * Combine both approaches when required * Reassess sizing regularly as integration usage grows ## Related Documentation * [System Requirements](/integration-platform/system-requirements) * [Installation on Linux](/installation-and-deployment/installation-linux) * [Installation on Windows](/installation-and-deployment/installation-windows) # Upgrade Learn how to upgrade ZigiOps to a newer release: backup steps, release-specific actions, and the backout plan for SOA versions. How to move your ZigiOps instance to a newer release while keeping your existing configuration intact. ### ZigiOps upgrade path ZigiOps supports upgrading from previous versions while retaining your existing configuration. To upgrade successfully, first identify your current ZigiOps release, then follow the standard upgrade instructions together with any release-specific steps that apply between your current version and the version you want to reach. {% hint style="info" %} **Example:** If you are currently running ZigiOps 2021.01.x and want to upgrade to ZigiOps 2024.04.x, you must apply the release-specific instructions for every version between your current release and the target release, in order. {% endhint %} ZigiOps upgrade path: apply release-specific steps in sequence between your current and target versions. ### Upgrade instructions {% stepper %} {% step %} **Stop ZigiOps** {% endstep %} {% step %} **Back up the existing installation** Back up the existing ZigiOps installation folder to another location. * Linux only, if ZigiOps was installed as a service: back up the ZigiOps service file (`/etc/systemd/system/zigiwave.service`). {% endstep %} {% step %} **Install the new release** Start the installation of the new ZigiOps release in your existing ZigiOps installation folder. {% endstep %} {% endstepper %} {% hint style="info" %} You must follow the corresponding release-specific instructions for every release between your current and desired version. If none of the versions in between require release-specific steps, you can skip that section and continue with the rest of the upgrade. {% endhint %} #### Release-specific instructions Some ZigiOps releases require extra steps during the upgrade. The table below summarizes them; expand each entry for the full instructions. | ZigiOps release | Required action | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2021.07.648 | Delete the `/conf/settings/accounts`, `/conf/settings/credentials`, and `/conf/settings/users` folders. | | 2021.10.145 | Remove the `key-password` and `key-manager-pass` lines from `/conf/config.properties` and save the file. | | 2023.01.191 | Delete the contents of the `/conf/settings/queries` folder. | | 2023.08.2.18 | Replace Java 8 (64-bit) with Oracle Java 17 (64-bit) or Open Java 17 (64-bit), update `JAVA_HOME`, and redeploy the ZigiOps service with the **OS Service** option. | | 2024.05.1.303 | Redeploy the ZigiOps service with the **OS Service** option to pick up the new startup parameters introduced in this release. |
ZigiOps 2021.07.648 (release-specific steps) Delete the following folders: * `/conf/settings/accounts` * `/conf/settings/credentials` * `/conf/settings/users`
ZigiOps 2021.10.145 (release-specific steps) Remove the following lines from the `/conf/config.properties` file and save the changes afterward: * `key-password` * `key-manager-pass`
ZigiOps 2023.01.191 (release-specific steps) Delete the contents of the `/conf/settings/queries` folder.
ZigiOps 2023.08.2.18 (release-specific steps) {% stepper %} {% step %} ## Uninstall Java 8 Uninstall the old Java 8 (64-bit) from the ZigiOps host and restart it. {% endstep %} {% step %} ## Install Java 17 Install Oracle Java 17 (64-bit) or Open Java 17 (64-bit). * Ensure the `JAVA_HOME` variable is set to the Java 17 deployment. {% endstep %} {% step %} ## Redeploy the ZigiOps service Redeploy the ZigiOps service so the platform picks up the new Java 17 deployment required by this release. * Select the **OS Service** option during the installation. {% endstep %} {% endstepper %}
ZigiOps 2024.05.1.303 (release-specific steps) Redeploy the ZigiOps service, since this release introduces new startup parameters. * Select the **OS Service** option during the installation.
After completing the applicable release-specific steps: * Wait for the installation to finish, then start the ZigiOps service or process. * Go to the **Connected Systems** page and confirm that the test connection is successful. * Go to the **Configurator** page, then select and enable the integration template you need. * Confirm that the integration works as expected. ### Backout plan If you need to revert to the previous version after an upgrade, follow these steps. {% stepper %} {% step %} **Stop ZigiOps** {% endstep %} {% step %} **Restore the previous backup** Restore the previous version's backup to the application's installation folder, replacing all files. {% endstep %} {% step %} **Start ZigiOps** {% endstep %} {% endstepper %} ### Backout plan: from ZigiOps 2024.11.3.173 (or newer) to an earlier release {% hint style="warning" %} The ZigiOps 2024.11.3.173 release introduced a service-oriented architecture (SOA). Because of this change, reverting to a version older than 2024.11.3.173 requires additional steps beyond the standard backout plan. {% endhint %} #### Windows {% stepper %} {% step %} **Stop ZigiOps** {% endstep %} {% step %} **Uninstall the ZigiOps SOA release and its services** * Run `C:\ZigiWave\ZigiOps\webapp\service\uninstall_service.bat` to uninstall the **ZigiOps Web App** service. * Run `C:\ZigiWave\ZigiOps\platform\service\uninstall_service.bat` to uninstall the **ZigiOps Platform** service. * Manually delete the ZigiOps installation folder, typically `C:\ZigiWave\ZigiOps`, unless a different location was specified during installation. {% endstep %} {% step %} **Restore the ZigiOps installation** Restore the ZigiOps installation from your backup. {% endstep %} {% step %} **Reinstall the old ZigiOps service** Run `C:\ZigiWave\ZigiOps\service\install_service.bat` to reinstall the old (non-SOA) ZigiOps service. {% endstep %} {% step %} **Start ZigiOps** {% endstep %} {% endstepper %} #### Linux {% stepper %} {% step %} **Stop ZigiOps** {% endstep %} {% step %} **Uninstall the ZigiOps SOA release and its services** * Delete the `/etc/systemd/system/zigiwave_webapp.service` **ZigiOps Web App** service file (skip this step if you did not install the ZigiOps services). * Delete the `/etc/systemd/system/zigiwave_platform.service` **ZigiOps Platform** service file (skip this step if you did not install the ZigiOps services). * Manually delete the ZigiOps installation folder, typically `/opt/zigiwave/zigiops`, unless a different location was specified during installation. {% endstep %} {% step %} **Restore the ZigiOps installation** Restore the ZigiOps installation from your backup. * Linux only, if ZigiOps was installed as a service: restore the old (non-SOA) `zigiwave.service` file from your backup to the `/etc/systemd/system/` folder. {% endstep %} {% step %} **Start ZigiOps** {% endstep %} {% endstepper %} ### Frequently asked questions
Can I upgrade ZigiOps directly to the latest version? Only if no release-specific instructions apply between your current release and the target release. If any release in between has release-specific instructions, apply them in order before moving on.
Does upgrading ZigiOps affect my existing configuration? No. The new release is installed directly into your existing ZigiOps installation folder, so your configuration is retained.
What changed with the ZigiOps 2024.11.3.173 release? This release introduced a service-oriented architecture (SOA) that splits the platform into separate Web App and Platform services. Reverting from this release or a newer one to an earlier version requires the additional backout steps described above.
Related: [System Requirements](broken://pages/2a29c8fdcf7ac221fe2e700aa9fa7098d15af13a) · [Scaling and Sizing](broken://pages/9dbd8c4a45a154938a2973ab5707557214ffd558) · [Install on Linux](broken://pages/d0392c9513ad033363f5927ccf234c3e58838c96) · [Install on Windows](broken://pages/3bfc9bf28885539358e09083d9b248c1667540ee) # Integration Catalog Pre-built ZigiOps integration guides for Jira, ServiceNow, Azure DevOps, Salesforce, BMC Remedy, Freshservice, TOPdesk, and more. Step-by-step guides for each pre-built integration. Select your connector pair to find prerequisites, field mapping examples, configuration walkthroughs, and FAQs. {% content-ref url="/pages/dbb77252abac08198d7318f896c5954ceffe0b99" %} [Jira ServiceNow Integration](/integration-catalog/jira-servicenow-integration) {% endcontent-ref %} {% content-ref url="/pages/d8e39657f0f67e5454ea19d45bccff8af89f2af8" %} [Jira Azure DevOps Integration](/integration-catalog/jira-azure-devops-integration) {% endcontent-ref %} {% content-ref url="/pages/43481841cbe86d1462109faaaee0faf0d098f52f" %} [Salesforce Jira Integration](/integration-catalog/salesforce-jira-integration) {% endcontent-ref %} {% content-ref url="/pages/be012617a7cb2fef6de169598b153185e3675a2f" %} [ServiceNow Azure DevOps Integration](/integration-catalog/servicenow-azure-devops-integration) {% endcontent-ref %} {% content-ref url="/pages/a00e5979bdf70fcfcfbb7990c6f6432baae878c8" %} [Remedy and Helix with Jira Integration](/integration-catalog/remedy-and-helix-with-jira-integration) {% endcontent-ref %} {% content-ref url="/pages/54eea4a6dd850b1dd07f9ff3c161a70dac48b813" %} [TOPdesk Jira Integration](/integration-catalog/topdesk-jira-integration) {% endcontent-ref %} {% content-ref url="/pages/cd89d699bbe32a07c909774480dbfee126d19582" %} [Freshdesk Jira Integration](/integration-catalog/freshdesk-jira-integration) {% endcontent-ref %} {% content-ref url="/pages/bdd64b7a3f5e95496037925ae8fe476a7d4f9fad" %} [Freshservice Jira Integration](/integration-catalog/freshservice-jira-integration) {% endcontent-ref %} # Jira ServiceNow Integration Learn how to configure and manage Jira–ServiceNow integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate Jira and ServiceNow to synchronize incidents, problems, service requests, bugs, and tasks across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Jira and ServiceNow.
alt="ZigiOps interface showing the 'Update SC Task' step in a ServiceNow to Jira Cloud workflow, with field mappings for description, state, urgency, short_description, work notes, and attachments on a purple-to-green gradient background"
ZigiOps interface showing the 'Create Task' step in a ServiceNow to Jira Cloud workflow, displaying source and target system settings, correlation fields, polling trigger configuration, and filter ruleс
ZigiOps interface showing the 'Field Mapping' target configuration for a ServiceNow to Jira Cloud workflow, mapping fields such as summary, description, status, priority, attachments, and comments
ZigiOps interface showing the 'Update Task' source configuration in a ServiceNow to Jira Cloud workflow, with system settings, polling trigger, filter rules for sys_updated_on and sys_updated_by, and a lasttime expressions
### Integration video {% embed url="" %} *** ### What can I integrate between Jira and ServiceNow? ZigiOps can integrate any Jira issue type (Tasks, Issues, Comments, etc.) with any ServiceNow entity (Incidents, Changes, CMDBs, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common and widely used Jira and ServiceNow scenarios, including: * Jira Tasks to ServiceNow Incidents * ServiceNow Incidents to Jira Tasks * ServiceNow Problems to Jira Bugs * ServiceNow Service Catalog Tasks to Jira Tasks These templates serve as preconfigured starting points and can be customized or extended to support additional Jira issue types, ServiceNow tables, and business-specific workflows. Each integration scenario can be configured as one-way or bi-directional, with full control over field mappings, filters, triggers, and synchronization rules. | Common ServiceNow entities | Common Jira issue types | Common fields typically synchronized | | -------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Incident | Task / Issue | Summary / Short description, Description, Priority, Status / State, Assignee, Comments, Attachments | | Change Request (CR) | Issue / Task | Summary, Description, Priority, Status / State, Owner / Assignee, Comments, Attachments | | Problem | Bug / Issue | Summary, Description, Priority / Severity, Status / State, Assignee, Comments, Attachments | | Service Catalog Task | Task / Issue | Summary, Description, Priority, Status / State, Requested for / Reporter, Comments, Attachments | | CMDB (Configuration Items) | Issue (custom) / Task | Name / Identifier, Description, Attributes (custom fields), Relationships (when applicable), Comments/Notes, Attachments (optional) | | **Any ServiceNow table** | **Any Jira issue type** | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | > **Note:** ZigiOps supports synchronization of all standard and custom fields for Jira and ServiceNow. The table above lists only the most commonly used fields for clarity and illustration purposes. *** ### How does the Jira and ServiceNow integration work? ZigiOps connects Jira and ServiceNow using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. *** ### Prerequisites and permissions Before enabling the Jira and ServiceNow integration, ensure the following prerequisites are met. The prerequisites below apply to all Jira and ServiceNow integration scenarios. Scenario-specific behavior is handled at the mapping and workflow level. | Integration Scenario | ServiceNow - Authentication | ServiceNow - Permissions | ServiceNow - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ---------------------------------------------- | --------------------------- | ------------------------------------------------ | ------------------------------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | Jira Tasks to ServiceNow Incidents | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | ServiceNow Incidents to Jira Tasks | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | ServiceNow Problems to Jira Bugs | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software, Version 7.x or newer | | ServiceNow Service Catalog Tasks to Jira Tasks | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | *** ### Setup Follow the steps below to enable the Jira and ServiceNow integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired Jira and ServiceNow integration template. 4. Select the corresponding Integrated Systems (Jira and ServiceNow). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Mapping examples Below are typical field-mapping examples used across the Jira and ServiceNow integration scenarios. Mappings can be customized per use case. **Example: Jira Task to ServiceNow Incident** | Jira field | ServiceNow field | Advanced Field Mapping Example | | ----------- | -------------------------------- | ------------------------------------ | | Summary | Short description | - | | Description | Description | - | | Priority | Priority | - | | Status | State | To Do - 1, In Progress - 2, Done - 6 | | Assignee | Assigned to | - | | Comments | Work notes / Additional comments | - | | Attachments | Attachments | - | **Example: ServiceNow Incident to Jira Task** | ServiceNow field | Jira field | Advanced Field Mapping Example | | -------------------------------- | ----------- | ------------------------------------ | | Short description | Summary | - | | Description | Description | - | | Priority | Priority | - | | State | Status | 1 - To Do, 2 - In Progress, 6 - Done | | Assigned to | Assignee | - | | Work notes / Additional comments | Comments | - | | Attachments | Attachments | - | **Example: ServiceNow Problem to Jira Bug** | ServiceNow field | Jira field | Advanced Field Mapping Example | | ------------------- | ----------- | ------------------------------------ | | Short description | Summary | - | | Problem description | Description | - | | Severity | Priority | - | | State | Status | 1 - To Do, 2 - In Progress, 6 - Done | | Work notes | Comments | - | **Example: ServiceNow Service Catalog Task to Jira Task** | ServiceNow field | Jira field | | ----------------- | ------------- | | Short description | Summary | | Description | Description | | Requested for | Reporter | | Assignment group | Project | | Catalog variables | Custom fields | *** ### What data can be synchronized? ZigiOps supports synchronization of: * Standard fields * Custom fields * Status / state transitions * Comments * Attachments * Users and assignments (configurable) Each field can be mapped independently for each direction. *** ### Frequently asked questions (FAQ)
Can I use one template for multiple projects or assignment groups? Yes. Filters and conditions allow you to scope synchronization by project, assignment group, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my Jira or ServiceNow data? No. ZigiOps does not permanently store transferred business data.
*** ### Related resources * [How to connect Jira to ZigiOps](/available-systems/jira) * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Jira and ServiceNow integration troubleshooting](/operations-and-monitoring/troubleshooting) # Jira Azure DevOps Integration Learn how to configure and manage Jira-Azure DevOps integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate Jira and Azure DevOps to synchronize work items, tasks, bugs, and issues across DevOps and project management teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Jira and Azure DevOps.
### **Integration video** {% embed url="" %} *** ### What can I integrate between Jira and Azure DevOps? ZigiOps can integrate any Jira issue type (Tasks, Bugs, Epics, Stories, etc.) with any Azure DevOps work item type (Tasks, Bugs, User Stories, Epics, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common Jira and Azure DevOps scenarios, including: * Jira Tasks to Azure DevOps Tasks * Azure DevOps Tasks to Jira Tasks * Jira Bugs to Azure DevOps Bugs * Azure DevOps Work Items to Jira Issues These templates serve as preconfigured starting points and can be customized or extended to support additional issue types, work item types, and business-specific workflows. Each integration scenario can be configured as one-way or bi-directional, with full control over field mappings, filters, triggers, and synchronization rules. | Common Azure DevOps entities | Common Jira issue types | Common fields typically synchronized | | ------------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------- | | Task | Task / Issue | Title / Summary, Description, Priority, Status / State, Assignee, Comments, Attachments | | Bug | Bug / Issue | Title / Summary, Description, Priority, Severity, Status / State, Assignee, Comments, Attachments | | User Story | Story / Issue | Title / Summary, Description, Priority, Status / State, Assignee, Comments, Attachments | | Epic | Epic | Title / Summary, Description, Priority, Status / State, Owner / Assignee, Comments, Attachments | | Any Azure DevOps work item type | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | {% hint style="info" %} ZigiOps supports synchronization of all standard and custom fields for Jira and Azure DevOps. The table above lists only the most commonly used fields for clarity and illustration purposes. {% endhint %} *** ### How does the Jira and Azure DevOps integration work? ZigiOps connects Jira and Azure DevOps using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. *** ### Prerequisites and permissions Before enabling the Jira and Azure DevOps integration, ensure the following prerequisites are met. The prerequisites below apply to all Jira and Azure DevOps integration scenarios. Scenario-specific behavior is handled at the mapping and workflow level. | Integration Scenario | Jira - Authentication | Jira - Permissions | Jira - Environment | Azure DevOps - Authentication | Azure DevOps - Permissions | Azure DevOps - Environment | | -------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------- | ------------------------------------------------- | ---------------------------------------------------- | | Jira Tasks to Azure DevOps Tasks | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | Username + PAT | Read / Write work items; Access to target project | Azure DevOps (any supported version) Cloud or Server | | Azure DevOps Tasks to Jira Tasks | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | Username + PAT | Read / Write work items; Access to target project | Azure DevOps (any supported version) Cloud or Server | | Jira Bugs to Azure DevOps Bugs | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software, Version 7.x or newer | Username + PAT | Read / Write work items; Access to target project | Azure DevOps (any supported version) | *** ### Setup Follow the steps below to enable the Jira and Azure DevOps integration using a prebuilt ZigiOps template. {% stepper %} {% step %} Log in to your ZigiOps instance {% endstep %} {% step %} Navigate to ZigiOps - Configurator {% endstep %} {% step %} Load the desired Jira and Azure DevOps integration template {% endstep %} {% step %} Select the corresponding Integrated Systems (Jira and Azure DevOps) {% endstep %} {% step %} Click **Save** to continue {% endstep %} {% step %} Enable the integration using the slider button located in the middle section of the screen {% endstep %} {% endstepper %} Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Mapping examples Below are typical field-mapping examples used across the Jira and Azure DevOps integration scenarios. Mappings can be customized per use case. **Example: Jira Task to Azure DevOps Task** | Jira field | Azure DevOps field | Advanced Field Mapping Example | | ----------- | ------------------ | ------------------------------------------------ | | Summary | Title | - | | Description | Description | - | | Priority | Priority | - | | Status | State | To Do - New, In Progress - Active, Done - Closed | | Assignee | Assigned To | - | | Comments | Comments | - | | Attachments | Attachments | - | **Example: Azure DevOps Task to Jira Task** | Azure DevOps field | Jira field | Advanced Field Mapping Example | | ------------------ | ----------- | ------------------------------------------------ | | Title | Summary | - | | Description | Description | - | | Priority | Priority | - | | State | Status | New - To Do, Active - In Progress, Closed - Done | | Assigned To | Assignee | - | | Comments | Comments | - | | Attachments | Attachments | - | *** ### What data can be synchronized? ZigiOps supports synchronization of: * Standard fields * Custom fields * Status / state transitions * Comments * Attachments * Users and assignments (configurable) Each field can be mapped independently for each direction. *** ### Frequently asked questions (FAQ)
Can I use one template for multiple projects? Yes. Filters and conditions allow you to scope synchronization by project, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Does ZigiOps store my Jira or Azure DevOps data? No. ZigiOps does not permanently store transferred business data.
*** ### Related resources * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [How to connect Azure DevOps to ZigiOps](/available-systems/azure-devops#how-do-i-connect-azure-devops-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Jira and Azure DevOps integration troubleshooting](/operations-and-monitoring/troubleshooting) # Freshservice Jira Integration Learn how to configure and manage Freshservice-Jira integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate Freshservice and Jira to synchronize incidents, service requests, and tasks across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Freshservice and Jira.
### **Integration video** {% embed url="" %} ### What can I integrate between Freshservice and Jira? ZigiOps can integrate any Freshservice entity (Incidents, Service Requests, etc.) with any Jira issue type (Tasks, Bugs, Issues, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common Freshservice and Jira scenarios, including: * Freshservice Incidents to Jira Tasks * Jira Tasks to Freshservice Incidents * Freshservice Service Requests to Jira Tasks | Common Freshservice entities | Common Jira issue types | Common fields typically synchronized | | ---------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------- | | Incident | Task / Issue | Subject / Summary, Description, Priority, Status / State, Agent / Assignee, Comments, Attachments | | Service Request | Task / Issue | Subject / Summary, Description, Priority, Status / State, Requested by / Reporter, Comments, Attachments | | Ticket Note | Comment | Body / Comment text, Author, Created date | | Any Freshservice entity | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | ### How does the Freshservice and Jira integration work? ZigiOps connects Freshservice and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data ### Prerequisites and permissions Before enabling the Freshservice and Jira integration, ensure the following prerequisites are met. | Integration Scenario | Freshservice - Authentication | Freshservice - Permissions | Freshservice - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ------------------------------------------- | ----------------------------- | --------------------------------------- | ------------------------------------------ | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | Freshservice Incidents to Jira Tasks | Email + API Token | Read / Write access to Incidents | Freshservice (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to Freshservice Incidents | Email + API Token | Read / Write access to Incidents | Freshservice (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Freshservice Service Requests to Jira Tasks | Email + API Token | Read / Write access to Service Requests | Freshservice (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | ### Setup {% stepper %} {% step %} Log in to your ZigiOps instance. {% endstep %} {% step %} Navigate to ZigiOps - Configurator. {% endstep %} {% step %} Load the desired Freshservice and Jira integration template. {% endstep %} {% step %} Select the corresponding Integrated Systems (Freshservice and Jira). {% endstep %} {% step %} Click **Save** to continue. {% endstep %} {% step %} Enable the integration using the slider button located in the middle section of the screen. {% endstep %} {% endstepper %} ### Mapping examples Below are typical field-mapping examples used across the Freshservice and Jira integration scenarios. Mappings can be customized per use case. **Example: Freshservice Incident to Jira Task** | Freshservice field | Jira field | Advanced Field Mapping Example | | ------------------ | ----------- | ------------------------------------------------------------------- | | Subject | Summary | - | | Description | Description | - | | Priority | Priority | Low - Low, Medium - Medium, High - High, Urgent - Highest | | Status | Status | Open - To Do, Pending - In Progress, Resolved - Done, Closed - Done | | Agent | Assignee | - | | Notes / Replies | Comments | - | | Attachments | Attachments | - | **Example: Freshservice Service Request to Jira Task** | Freshservice field | Jira field | Advanced Field Mapping Example | | ------------------ | ----------- | ------------------------------ | | Subject | Summary | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | - | | Requested by | Reporter | - | | Agent | Assignee | - | | Notes | Comments | - | ### What data can be synchronized? * Standard fields * Custom fields * Status transitions * Comments and notes * Attachments * Agent / Assignee and Reporter (configurable) ### Frequently asked questions (FAQ)
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time from the ZigiOps UI.
Does ZigiOps store my data? No. ZigiOps does not permanently store transferred business data.
### Related resources * [How to connect Freshservice to ZigiOps](/available-systems/freshservice#how-do-i-connect-freshservice-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Freshservice and Jira integration troubleshooting](/operations-and-monitoring/troubleshooting) # Freshdesk Jira Integration Learn how to configure and manage Freshdesk-Jira integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate Freshdesk and Jira to synchronize tickets, tasks, and issues across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Freshdesk and Jira. ### Integration video {% embed url="" %} *** ### What can I integrate between Freshdesk and Jira? ZigiOps can integrate any Freshdesk entity (Tickets, etc.) with any Jira issue type (Tasks, Bugs, Issues, etc.), allowing you to build custom workflows tailored to your processes and data models.
Out of the box, ZigiOps provides ready-made integration templates for the most common Freshdesk and Jira scenarios, including: * Freshdesk Tickets to Jira Tasks * Jira Tasks to Freshdesk Tickets | Common Freshdesk entities | Common Jira issue types | Common fields typically synchronized | | ------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------- | | Ticket | Task / Issue | Subject / Summary, Description, Priority, Status / State, Agent / Assignee, Tags, Comments, Attachments | | Ticket Reply / Note | Comment | Body / Comment text, Author, Created date | | Any Freshdesk entity | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | *** ### How does the Freshdesk and Jira integration work? ZigiOps connects Freshdesk and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data *** ### Prerequisites and permissions Before enabling the Freshdesk and Jira integration, ensure the following prerequisites are met. | Integration Scenario | Freshdesk - Authentication | Freshdesk - Permissions | Freshdesk - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ------------------------------- | -------------------------- | ------------------------------ | --------------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | Freshdesk Tickets to Jira Tasks | API Key | Read / Write access to Tickets | Freshdesk (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to Freshdesk Tickets | API Key | Read / Write access to Tickets | Freshdesk (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | **How to find your API Key in Freshdesk:** 1. Log in to your Freshdesk instance. 2. Go to the Profile Settings menu. 3. Your API Key is displayed in the Profile Settings panel. *** ### Setup 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired Freshdesk and Jira integration template. 4. Select the corresponding Integrated Systems (Freshdesk and Jira). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. *** ### Mapping examples Below are typical field-mapping examples used across the Freshdesk and Jira integration scenarios. Mappings can be customized per use case. **Example: Freshdesk Ticket to Jira Task** | Freshdesk field | Jira field | Advanced Field Mapping Example | | --------------- | ----------- | --------------------------------------------------------- | | Subject | Summary | - | | Description | Description | - | | Priority | Priority | Low - Low, Medium - Medium, High - High, Urgent - Highest | | Status | Status | Open - To Do, Pending - In Progress, Resolved - Done | | Agent | Assignee | - | | Replies / Notes | Comments | - | | Attachments | Attachments | - | *** ### What data can be synchronized? * Standard fields * Custom fields * Status transitions * Comments and replies * Attachments * Agent / Assignee (configurable) *** ### Frequently asked questions (FAQ)
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Does ZigiOps store my data? No. ZigiOps does not permanently store transferred business data.
*** ### Related resources * [How to connect Freshdesk to ZigiOps](/available-systems/freshdesk#how-do-i-connect-freshdesk-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Freshdesk and Jira integration troubleshooting](/operations-and-monitoring/troubleshooting) # TOPdesk Jira Integration Learn how to configure and manage TOPdesk-Jira integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate TOPdesk and Jira to synchronize incidents, tasks, and service requests across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between TOPdesk and Jira.
### **Integration video** {% embed url="" %} ### What can I integrate between TOPdesk and Jira? ZigiOps can integrate any TOPdesk entity (Incidents, Changes, etc.) with any Jira issue type (Tasks, Bugs, Issues, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common TOPdesk and Jira scenarios, including: * TOPdesk Incidents to Jira Tasks * Jira Tasks to TOPdesk Incidents These templates serve as preconfigured starting points and can be customized or extended to support additional TOPdesk entities, Jira issue types, and business-specific workflows. | Common TOPdesk entities | Common Jira issue types | Common fields typically synchronized | | ----------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------- | | Incident (First Line) | Task / Issue | Brief description / Summary, Description, Priority, Status / State, Operator / Assignee, Comments, Attachments | | Incident (Second Line) | Task / Issue | Brief description / Summary, Description, Priority, Status / State, Operator / Assignee, Comments, Attachments | | Change | Issue / Task | Brief description / Summary, Description, Priority, Status / State, Operator / Assignee, Comments, Attachments | | Any TOPdesk entity | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | ### How does the TOPdesk and Jira integration work? ZigiOps connects TOPdesk and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data ### Prerequisites and permissions Before enabling the TOPdesk and Jira integration, ensure the following prerequisites are met. | Integration Scenario | TOPdesk - Authentication | TOPdesk - Permissions | TOPdesk - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ------------------------------- | ------------------------ | --------------------------------------------------- | ---------------------------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | TOPdesk Incidents to Jira Tasks | Username + Password | Read / Write access to Incidents and target modules | TOPdesk (any supported version) Cloud or On-Premises | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to TOPdesk Incidents | Username + Password | Read / Write access to Incidents and target modules | TOPdesk (any supported version) Cloud or On-Premises | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | ### Setup 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired TOPdesk and Jira integration template. 4. Select the corresponding Integrated Systems (TOPdesk and Jira). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. ### Mapping examples Below are typical field-mapping examples used across the TOPdesk and Jira integration scenarios. Mappings can be customized per use case. **Example: TOPdesk Incident to Jira Task** | TOPdesk field | Jira field | Advanced Field Mapping Example | | ----------------- | ----------- | ----------------------------------------------------------- | | Brief description | Summary | - | | Request | Description | - | | Priority | Priority | - | | Processing status | Status | Logged - To Do, In Progress - In Progress, Completed - Done | | Operator | Assignee | - | | Action (comments) | Comments | - | | Attachments | Attachments | - | ### What data can be synchronized? * Standard fields * Custom fields * Status transitions * Comments and actions * Attachments * Operator / Assignee (configurable) ### Frequently asked questions (FAQ)
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Does ZigiOps store my data? No. ZigiOps does not permanently store transferred business data.
### Related resources * [How to connect TOPdesk to ZigiOps](/available-systems/topdesk#how-do-i-connect-topdesk-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [TOPdesk and Jira integration troubleshooting](/operations-and-monitoring/troubleshooting) # Remedy and Helix with Jira Integration Learn how to configure and manage BMC Remedy and Helix with Jira integrations in ZigiOps, including prerequisites, setup steps and mappings. Integrate BMC Remedy/Helix and Jira to synchronize incidents, problems, change requests, and tasks across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Remedy/Helix and Jira.
### **Integration video** {% embed url="" %} *** ### What can I integrate between Remedy/Helix and Jira? ZigiOps can integrate any Remedy/Helix entity (Incidents, Problems, Change Requests, Work Orders, etc.) with any Jira issue type (Tasks, Bugs, Issues, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common Remedy/Helix and Jira scenarios, including: * Remedy Incidents to Jira Tasks * Jira Tasks to Remedy Incidents * Remedy Problems to Jira Tasks * Jira Tasks to Remedy Problems * Remedy Change Requests to Jira Tasks * Remedy Work Orders to Jira Tasks **Note:** ZigiOps integrates with BMC Remedy using its REST API service. | Common Remedy/Helix entities | Common Jira issue types | Common fields typically synchronized | | ---------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------- | | Incident | Task / Issue | Summary / Short description, Description, Priority, Status / State, Assignee, Comments, Attachments | | Problem | Bug / Issue | Summary / Short description, Description, Severity / Priority, Status / State, Assignee, Comments, Attachments | | Change Request | Issue / Task | Summary, Description, Priority, Status / State, Owner / Assignee, Comments, Attachments | | Work Order | Task | Summary, Description, Priority, Status / State, Assignee, Comments, Attachments | | Any Remedy entity | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | *** ### How does the Remedy/Helix and Jira integration work? ZigiOps connects Remedy/Helix and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data *** ### Prerequisites and permissions Before enabling the Remedy/Helix and Jira integration, ensure the following prerequisites are met. | Integration Scenario | Remedy/Helix - Authentication | Remedy/Helix - Permissions | Remedy/Helix - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ------------------------------------ | ----------------------------- | ------------------------------------------------- | ------------------------------------------------------------ | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | Remedy Incidents to Jira Tasks | Username + Password | Read / Write access to Incidents and target forms | BMC Remedy (any supported version); REST API service enabled | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to Remedy Incidents | Username + Password | Read / Write access to Incidents and target forms | BMC Remedy (any supported version); REST API service enabled | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Remedy Problems to Jira Tasks | Username + Password | Read / Write access to Problems | BMC Remedy (any supported version); REST API service enabled | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software, Version 7.x or newer | | Remedy Change Requests to Jira Tasks | Username + Password | Read / Write access to Change Requests | BMC Remedy (any supported version); REST API service enabled | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | *** ### Setup 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired Remedy/Helix and Jira integration template. 4. Select the corresponding Integrated Systems (Remedy/Helix and Jira). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. *** ### Mapping examples Below are typical field-mapping examples used across the Remedy/Helix and Jira integration scenarios. Mappings can be customized per use case. **Example: Remedy Incident to Jira Task** | Remedy/Helix field | Jira field | Advanced Field Mapping Example | | ------------------ | ----------- | ------------------------------------------------------- | | Short description | Summary | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | New - To Do, In Progress - In Progress, Resolved - Done | | Assignee | Assignee | - | | Work notes | Comments | - | | Attachments | Attachments | - | **Example: Jira Task to Remedy Incident** | Jira field | Remedy/Helix field | Advanced Field Mapping Example | | ----------- | ------------------ | ------------------------------------------------------- | | Summary | Short description | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | To Do - New, In Progress - In Progress, Done - Resolved | | Assignee | Assignee | - | | Comments | Work notes | - | | Attachments | Attachments | - | *** ### What data can be synchronized? * Standard fields * Custom fields * Status / state transitions * Comments * Attachments * Users and assignments (configurable) *** ### Frequently asked questions (FAQ)
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
Does ZigiOps require the Remedy REST API? Yes. ZigiOps integrates with BMC Remedy using its REST API service, which must be enabled on your Remedy/Helix instance.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
*** ### Related resources * [How to connect Remedy/Helix to ZigiOps](/available-systems/remedy#how-do-i-connect-bmc-remedy-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Remedy and Jira integration troubleshooting](/operations-and-monitoring/troubleshooting) # ServiceNow Azure DevOps Integration Learn how to configure and manage ServiceNow-Azure DevOps integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate ServiceNow and Azure DevOps to synchronize incidents, work items, and tasks across ITSM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between ServiceNow and Azure DevOps. ### **Integration video** {% embed url="" %} ### What can I integrate between ServiceNow and Azure DevOps? ZigiOps can integrate any ServiceNow entity (Incidents, Changes, Problems, etc.) with any Azure DevOps work item type (Tasks, Bugs, User Stories, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common ServiceNow and Azure DevOps scenarios, including: * ServiceNow Incidents to Azure DevOps Work Items * Azure DevOps Work Items to ServiceNow Incidents These templates serve as preconfigured starting points and can be customized or extended to support additional ServiceNow tables, Azure DevOps work item types, and business-specific workflows. | Common ServiceNow entities | Common Azure DevOps work item types | Common fields typically synchronized | | -------------------------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------- | | Incident | Task / Bug | Short description / Title, Description, Priority, Status / State, Assignee, Comments, Attachments | | Change Request | User Story / Task | Short description / Title, Description, Priority, Status / State, Owner / Assignee, Comments, Attachments | | Problem | Bug / Issue | Short description / Title, Description, Severity / Priority, Status / State, Assignee, Comments | | Any ServiceNow table | Any Azure DevOps work item | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | ### How does the ServiceNow and Azure DevOps integration work? ZigiOps connects ServiceNow and Azure DevOps using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data * Compatible with ServiceNow MID Server for secure on-premises deployments ### Prerequisites and permissions Before enabling the ServiceNow and Azure DevOps integration, ensure the following prerequisites are met. | Integration Scenario | ServiceNow - Authentication | ServiceNow - Permissions | ServiceNow - Environment | Azure DevOps - Authentication | Azure DevOps - Permissions | Azure DevOps - Environment | | ----------------------------------------------- | --------------------------- | ------------------------------------------------ | ------------------------------------------------------- | ----------------------------- | ------------------------------------------------- | ---------------------------------------------------- | | ServiceNow Incidents to Azure DevOps Work Items | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + PAT | Read / Write work items; Access to target project | Azure DevOps (any supported version) Cloud or Server | | Azure DevOps Work Items to ServiceNow Incidents | Username + Password | x\_ziw\_obm.admin, personalize\_read\_dictionary | ServiceNow (any supported version); Optional MID Server | Username + PAT | Read / Write work items; Access to target project | Azure DevOps (any supported version) Cloud or Server | ### Setup Follow the steps below to enable the ServiceNow and Azure DevOps integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired ServiceNow and Azure DevOps integration template. 4. Select the corresponding Integrated Systems (ServiceNow and Azure DevOps). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. ### Mapping examples Below are typical field-mapping examples used across the ServiceNow and Azure DevOps integration scenarios. Mappings can be customized per use case. **Example: ServiceNow Incident to Azure DevOps Work Item** | ServiceNow field | Azure DevOps field | Advanced Field Mapping Example | | -------------------------------- | ------------------ | ------------------------------- | | Short description | Title | - | | Description | Description | - | | Priority | Priority | - | | State | State | 1 - New, 2 - Active, 6 - Closed | | Assigned to | Assigned To | - | | Work notes / Additional comments | Comments | - | | Attachments | Attachments | - | **Example: Azure DevOps Work Item to ServiceNow Incident** | Azure DevOps field | ServiceNow field | Advanced Field Mapping Example | | ------------------ | ----------------- | ------------------------------- | | Title | Short description | - | | Description | Description | - | | Priority | Priority | - | | State | State | New - 1, Active - 2, Closed - 6 | | Assigned To | Assigned to | - | | Comments | Work notes | - | | Attachments | Attachments | - | ### What data can be synchronized? * Standard fields * Custom fields * Status / state transitions * Comments * Attachments * Users and assignments (configurable) ### Frequently asked questions (FAQ)
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
Can I use a ServiceNow MID Server? Yes. ZigiOps is compatible with ServiceNow MID Server for secure on-premises communication.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Does ZigiOps store my data? No. ZigiOps does not permanently store transferred business data.
### Related resources * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow#how-do-i-connect-servicenow-to-zigiops) * [How to connect Azure DevOps to ZigiOps](/available-systems/azure-devops#how-do-i-connect-azure-devops-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [ServiceNow and Azure DevOps integration troubleshooting](/operations-and-monitoring/troubleshooting) # Salesforce Jira Integration Learn how to configure and manage Salesforce-Jira integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate Salesforce and Jira to synchronize cases, tasks, and custom objects across CRM and DevOps teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Salesforce and Jira. ### Integration video {% embed url="" %} ### What can I integrate between Salesforce and Jira? ZigiOps can integrate any Salesforce entity (Cases, Custom Objects, etc.) with any Jira issue type (Tasks, Issues, Bugs, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common Salesforce and Jira scenarios, including: * Salesforce Cases to Jira Tasks * Jira Tasks to Salesforce Cases These templates serve as preconfigured starting points and can be customized or extended to support additional Salesforce entities, Jira issue types, and business-specific workflows. Each integration scenario can be configured as one-way or bi-directional, with full control over field mappings, filters, triggers, and synchronization rules. {% hint style="warning" %} **Important note on Salesforce attachments:** Salesforce uses the `lastmodifieddate` attribute to detect record changes. ZigiOps relies on this value. However, Salesforce does not update `lastmodifieddate` when an attachment is added to a record. A mechanism to update `lastmodifieddate` when attachments are added is required on the Salesforce side. {% endhint %} | Common Salesforce entities | Common Jira issue types | Common fields typically synchronized | | -------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------- | | Case | Task / Issue | Subject / Summary, Description, Priority, Status / State, Owner / Assignee, Comments, Attachments | | Case Comment | Comment | Body / Comment text, Author, Created date | | Custom Object | Issue (custom) | Custom fields, Status, Assignee, Comments, Attachments | | Any Salesforce entity | Any Jira issue type | Standard + custom fields, Comments, Attachments, Status/State mappings, Correlation ID (recommended) | {% hint style="info" %} ZigiOps supports synchronization of all standard and custom fields for Salesforce and Jira. The table above lists only the most commonly used fields for clarity and illustration purposes. {% endhint %} ### How does the Salesforce and Jira integration work? ZigiOps connects Salesforce and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. ### Prerequisites and permissions Before enabling the Salesforce and Jira integration, ensure the following prerequisites are met. | Integration Scenario | Salesforce - Authentication | Salesforce - Permissions | Salesforce - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ------------------------------ | ------------------------------------------------------- | ----------------------------------------------- | ---------------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | Salesforce Cases to Jira Tasks | OAuth (Username + Password + Client ID + Client Secret) | Read / Write access to Cases and target objects | Salesforce (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to Salesforce Cases | OAuth (Username + Password + Client ID + Client Secret) | Read / Write access to Cases and target objects | Salesforce (any supported version) Cloud | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | ### Setup Follow the steps below to enable the Salesforce and Jira integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired Salesforce and Jira integration template. 4. Select the corresponding Integrated Systems (Salesforce and Jira). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Mapping examples Below are typical field-mapping examples used across the Salesforce and Jira integration scenarios. Mappings can be customized per use case. **Example: Salesforce Case to Jira Task** | Salesforce field | Jira field | Advanced Field Mapping Example | | ---------------- | ----------- | ----------------------------------------------------- | | Subject | Summary | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | New - To Do, In Progress - In Progress, Closed - Done | | Owner | Assignee | - | | Comments | Comments | - | | Attachments | Attachments | - | **Example: Jira Task to Salesforce Case** | Jira field | Salesforce field | Advanced Field Mapping Example | | ----------- | ---------------- | ----------------------------------------------------- | | Summary | Subject | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | To Do - New, In Progress - In Progress, Done - Closed | | Assignee | Owner | - | | Comments | Comments | - | | Attachments | Attachments | - | ### What data can be synchronized? ZigiOps supports synchronization of: * Standard fields * Custom fields * Status transitions * Comments * Attachments * Users and assignments (configurable) Each field can be mapped independently for each direction. ### Frequently asked questions (FAQ)
Can I sync custom Salesforce objects? Yes. ZigiOps supports any Salesforce entity including custom objects.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Does ZigiOps store my Salesforce or Jira data? No. ZigiOps does not permanently store transferred business data.
### Related resources * [How to connect Salesforce to ZigiOps](/available-systems/salesforce#how-do-i-connect-salesforce-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Salesforce and Jira integration troubleshooting](/operations-and-monitoring/troubleshooting) # ServiceNow Remedy Integration Integrate ServiceNow and BMC Remedy to synchronize incidents, problems, and change requests across ITSM teams *** ### What Can I Integrate Between ServiceNow and Remedy? ZigiOps can integrate any ServiceNow entity with any Remedy form, enabling custom workflows tailored to your ITSM processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common ServiceNow to Remedy scenarios, including: * ServiceNow Incidents - Remedy Incidents * Remedy Incidents - ServiceNow Incidents * ServiceNow Problems - Remedy Problem Investigations These templates serve as preconfigured starting points and can be customized or extended to support additional entities, Remedy forms, and business-specific workflows. | Common ServiceNow entities | Common Remedy entities | Common fields typically synchronized | | -------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------- | | Incident | Incident | Short description/Summary, Description, Priority, Status/State, Assignee, Comments, Attachments | | Problem | Problem Investigation | Short description, Description, Severity/Priority, Status/State, Assignee, Work notes | | **Any ServiceNow table** | **Any Remedy form** | **Standard + custom fields, Status/State mappings, Correlation ID (recommended)** | {% hint style="info" %} ZigiOps supports synchronization of all standard and custom fields. The table above lists only the most commonly used fields. {% endhint %} *** ### How Does the ServiceNow to Remedy Integration Work? ZigiOps connects ServiceNow and Remedy using their native REST APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. {% hint style="info" %} ZigiOps integrates with BMC Remedy using its REST API service. {% endhint %} *** ### Prerequisites and Permissions Before enabling the ServiceNow to Remedy integration, ensure the following prerequisites are met. | Scenario | ServiceNow Auth | ServiceNow Permissions | Remedy Auth | Remedy Permissions | Environment | | --------------------------------------------------- | ------------------- | ----------------------------------------------------------- | ------------------- | ----------------------------------------------------- | -------------------------------------------------------- | | ServiceNow Incidents - Remedy Incidents | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | Username + Password | Create/Read/Update on Incident forms; REST API access | ServiceNow: Utah or newer; Remedy: any supported version | | ServiceNow Problems - Remedy Problem Investigations | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | Username + Password | Create/Read/Update on Problem forms; REST API access | ServiceNow: Utah or newer; Remedy: any supported version | *** ### Setup Follow the steps below to enable the ServiceNow to Remedy integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired **ServiceNow to Remedy integration template**. 4. Select the corresponding **Integrated Systems** (ServiceNow and Remedy). 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Mapping Examples Below are typical field-mapping examples for the ServiceNow Incident to Remedy Incident scenario. Mappings can be customized per use case. **Example: ServiceNow Incident - Remedy Incident** | ServiceNow field | Remedy field | Advanced Field Mapping Example | | -------------------------------- | ------------ | ------------------------------------------------------------------ | | Short description | Summary | Direct mapping | | Description | Notes | Direct mapping | | Priority | Priority | Direct mapping | | State | Status | 1 (New) - New; 2 (In Progress) - Assigned; 6 (Resolved) - Resolved | | Assigned to | Assignee | Direct mapping | | Work notes / Additional comments | Work Info | Direct mapping | | Attachments | Attachments | Direct mapping | *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, status and state transitions, comments, attachments, and user assignments between ServiceNow and Remedy. Each field can be mapped independently per direction. *** ### Frequently Asked Questions (FAQ)
Can I use one template for multiple projects or assignment groups? Yes. Filters and conditions allow you to scope synchronization by project, assignment group, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my ServiceNow or Remedy data? No. ZigiOps does not permanently store transferred business data.
*** ### Related Resources * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow#how-do-i-connect-servicenow-to-zigiops) * [How to connect Remedy to ZigiOps](/available-systems/remedy#how-do-i-connect-bmc-remedy-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [ServiceNow Remedy integration troubleshooting](/operations-and-monitoring/troubleshooting) # Ivanti Jira Integration Integrate Jira and Ivanti to synchronize incidents and tasks across DevOps and ITSM teams This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between Jira and Ivanti.
### Ivanti Jira Integration Video {% embed url="" %} ### What Can I Integrate Between Jira and Ivanti? ZigiOps can integrate any Jira issue type with any Ivanti business object, enabling custom workflows tailored to your ITSM and project management processes. Out of the box, ZigiOps provides ready-made integration templates for the most common Jira to Ivanti scenarios, including: * OBM Events - Ivanti Incidents * Ivanti Incidents - Jira Tasks (configurable) These templates serve as preconfigured starting points and can be customized or extended to support additional business objects, Jira issue types, and workflows. | Common Ivanti entities | Common Jira issue types | Common fields typically synchronized | | ------------------------------ | ----------------------- | ----------------------------------------------------------------------------------------------------- | | Incident | Task / Issue | Summary/Short Description, Description, Priority, Status/State, Owner/Assignee, Comments, Attachments | | **Any Ivanti business object** | **Any Jira issue type** | **Standard + custom fields, Status/State mappings, Correlation ID (recommended)** | > **Note:** ZigiOps supports synchronization of all standard and custom fields. The table above lists only the most commonly used fields. ### How Does the Jira to Ivanti Integration Work? ZigiOps connects Jira and Ivanti using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. ### Prerequisites and Permissions Before enabling the Jira to Ivanti integration, ensure the following prerequisites are met. | Scenario | Ivanti Auth | Ivanti Permissions | Jira Auth | Jira Permissions | Environment | | ------------------------------- | ----------- | ------------------------------------------------ | -------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------- | | Ivanti Incidents to Jira Issues | API Key | Read/Write on Incidents; REST API access enabled | Username + API Token | Create/Read/Update issues; Access to target projects | Ivanti: All versions; Jira Software or Jira Service Management 7.x or newer | ### Setup Follow the steps below to enable the Jira to Ivanti integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired **Jira to Ivanti integration template**. 4. Select the corresponding **Integrated Systems** (Jira and Ivanti). 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Mapping Examples Below are typical field-mapping examples for the Ivanti Incident to Jira Task scenario. Mappings can be customized per use case. **Example: Ivanti Incident - Jira Task** | Ivanti field | Jira field | Advanced Field Mapping Example | | ---------------- | ----------- | ----------------------------------------------------- | | Summary | Summary | Direct mapping | | Description | Description | Direct mapping | | Priority | Priority | Direct mapping | | Status | Status | Active - In Progress; Resolved - Done; Logged - To Do | | Owner | Assignee | Direct mapping | | Journals (Notes) | Comments | Direct mapping | | Attachments | Attachments | Direct mapping | ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, status and state transitions, comments, attachments, and user assignments between Jira and Ivanti. Each field can be mapped independently per direction. ### Frequently Asked Questions (FAQ)
Can I use one template for multiple projects or assignment groups? Yes. Filters and conditions allow you to scope synchronization by project, assignment group, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my Jira or Ivanti data? No. ZigiOps does not permanently store transferred business data.
### Related Resources * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [How to connect Ivanti to ZigiOps](/available-systems/ivanti#how-do-i-connect-ivanti-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Jira Ivanti integration troubleshooting](/operations-and-monitoring/troubleshooting) # ServiceNow Freshservice Integration Integrate ServiceNow and Freshservice to synchronize incidents, problems, and change requests This integration enables real-time or scheduled data synchronization, eliminates manual updates, and ensures a single source of truth between ServiceNow and Freshservice. ### What Can I Integrate Between ServiceNow and Freshservice? ZigiOps can integrate any ServiceNow entity with any Freshservice entity, enabling custom workflows tailored to your ITSM processes. Out of the box, ZigiOps provides ready-made integration templates for the most common ServiceNow to Freshservice scenarios, including: * ServiceNow Incidents - Freshservice Tickets * Freshservice Tickets - ServiceNow Incidents These templates serve as preconfigured starting points and can be customized or extended to support additional entities and business-specific workflows. | Common ServiceNow entities | Common Freshservice entities | Common fields typically synchronized | | -------------------------- | ---------------------------- | ----------------------------------------------------------------------------------------------- | | Incident | Ticket (Incident) | Short description/Subject, Description, Priority, Status/State, Assignee, Comments, Attachments | | Problem | Problem | Short description, Description, Priority, Status, Assignee, Work notes | | Change Request | Change | Summary, Description, Priority, Status, Owner, Comments | | **Any ServiceNow table** | **Any Freshservice entity** | **Standard + custom fields, Status/State mappings, Correlation ID (recommended)** | > **Note:** ZigiOps supports synchronization of all standard and custom fields. The table above lists only the most commonly used fields. ### How Does the ServiceNow to Freshservice Integration Work? ZigiOps connects ServiceNow and Freshservice using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. ### Prerequisites and Permissions Before enabling the ServiceNow to Freshservice integration, ensure the following prerequisites are met. | Scenario | ServiceNow Auth | ServiceNow Permissions | Freshservice Auth | Freshservice Permissions | Environment | | ------------------------------------------- | ------------------- | ----------------------------------------------------------- | ----------------- | --------------------------------------------------- | ----------------------------------------------------- | | ServiceNow Incidents - Freshservice Tickets | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | Email + API Token | Create/Read/Update on Tickets; Agent role or higher | ServiceNow: Utah or newer; Freshservice: All versions | | Freshservice Tickets - ServiceNow Incidents | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | Email + API Token | Create/Read/Update on Tickets; Agent role or higher | ServiceNow: Utah or newer; Freshservice: All versions | ### Setup Follow the steps below to enable the ServiceNow to Freshservice integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired **ServiceNow to Freshservice integration template**. 4. Select the corresponding **Integrated Systems** (ServiceNow and Freshservice). 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Mapping Examples Below are typical field-mapping examples for the ServiceNow Incident to Freshservice Ticket scenario. Mappings can be customized per use case. **Example: ServiceNow Incident - Freshservice Ticket** | ServiceNow field | Freshservice field | Advanced Field Mapping Example | | -------------------------------- | --------------------- | -------------------------------------------------------------------------------------------- | | Short description | Subject | Direct mapping | | Description | Description | Direct mapping | | Priority | Priority | 1 (Critical) - 4 (Urgent); 2 (High) - 3 (High); 3 (Moderate) - 2 (Medium); 4 (Low) - 1 (Low) | | State | Status | 1 (New) - Open; 2 (In Progress) - Pending; 6 (Resolved) - Resolved | | Assigned to | Responder (Agent) | Direct mapping | | Work notes / Additional comments | Conversations (notes) | Direct mapping | | Attachments | Attachments | Direct mapping | ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, status and state transitions, comments, attachments, and user assignments between ServiceNow and Freshservice. Each field can be mapped independently per direction. ### Frequently Asked Questions (FAQ)
Can I use one template for multiple projects or assignment groups? Yes. Filters and conditions allow you to scope synchronization by project, assignment group, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my ServiceNow or Freshservice data? No. ZigiOps does not permanently store transferred business data.
## Related Resources * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow#how-do-i-connect-servicenow-to-zigiops) * [How to connect Freshservice to ZigiOps](/available-systems/freshservice#how-do-i-connect-freshservice-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [ServiceNow Freshservice integration troubleshooting](/operations-and-monitoring/troubleshooting) # SAP SolMan ServiceNow Integration Integrate SAP Solution Manager (SolMan) and ServiceNow to automatically convert SAP monitoring alerts into ITSM incidents This integration forwards SAP SolMan alerts to ServiceNow as incidents, eliminates manual ticket creation, and ensures IT operations and service management teams work from a shared, real-time view. *** ### What Can I Integrate Between SAP SolMan and ServiceNow? ZigiOps can integrate any SAP SolMan alert type with any ServiceNow table, enabling custom workflows tailored to your SAP monitoring and ITSM processes. Out of the box, ZigiOps provides ready-made integration templates for the most common SAP SolMan to ServiceNow scenarios, including: * SAP SolMan Alerts - ServiceNow Incidents * SAP SolMan Alerts - ServiceNow Incidents (Backsync) These templates serve as preconfigured starting points and can be customized or extended to support additional alert types, ServiceNow tables, and business-specific workflows. | Common SAP SolMan entities | Common ServiceNow entities | Common fields typically synchronized | | ----------------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------- | | Alert | Incident | Node/CI, Title/Short Description, Severity/Priority, Status/State, Category, Description, Attachments | | **Any SAP SolMan alert type** | **Any ServiceNow table** | **Standard + custom fields, Status/State mappings, Correlation ID (recommended)** | {% hint style="info" %} ZigiOps supports synchronization of all standard and custom fields. The table above lists only the most commonly used fields. {% endhint %} *** ### How Does the SAP SolMan to ServiceNow Integration Work? ZigiOps connects SAP Solution Manager and ServiceNow using the SAP Integration Package and the ServiceNow REST API. ZigiOps acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured through the ZigiOps UI and the SAP ZGW\_CONNECTIONS table * Supports event-based synchronization via the SAP RFC connection * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. {% hint style="info" %} The SAP SolMan integration requires the ZigiOps Integration Package for SAP SolMan to be imported into your SAP system. Contact for installation assistance. {% endhint %} *** ### Prerequisites and Permissions Before enabling the SAP SolMan to ServiceNow integration, ensure the following prerequisites are met. | Scenario | SAP SolMan Auth | SAP SolMan Permissions | ServiceNow Auth | ServiceNow Permissions | | --------------------------------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------- | ------------------- | ----------------------------------------------------------- | | SAP SolMan Alerts - ServiceNow Incidents | Username + Password; Client Number; Integration Package installed | ZGW\_CONNECTIONS table access; RFC connection configured | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | | SAP SolMan Alerts - ServiceNow Incidents (Backsync) | Username + Password; Client Number; Integration Package installed | ZGW\_CONNECTIONS table access; RFC connection configured | Username + Password | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | *** ### Setup Follow the steps below to enable the SAP SolMan to ServiceNow integration using a prebuilt ZigiOps template. {% stepper %} {% step %} #### Log in to your ZigiOps instance. {% endstep %} {% step %} #### Navigate to **ZigiOps - Configurator**. {% endstep %} {% step %} #### Load the desired **SAP SolMan to ServiceNow integration template**. {% endstep %} {% step %} #### Select the corresponding **Integrated Systems** (SAP SolMan and ServiceNow). {% endstep %} {% step %} #### Click **Save** to continue. {% endstep %} {% step %} #### Enable the integration using the **slider button** located in the middle section of the screen. {% endstep %} {% endstepper %} Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. SAP SolMan alerts are forwarded to ZigiOps via the configured RFC connection and ZGW\_CONNECTIONS table. *** ### Mapping Examples Below are typical field-mapping examples for the SAP SolMan Alert to ServiceNow Incident scenario. Mappings can be customized per use case. **Example: SAP SolMan Alert - ServiceNow Incident** | SAP SolMan field | ServiceNow field | Advanced Field Mapping Example | | ----------------------- | ------------------ | -------------------------------------------------------------- | | Alert Context ID / Node | cmdb\_ci | Direct mapping | | Alert Title | short\_description | Direct mapping | | Severity | urgency / impact | 1-Critical - 1 (High); 2-Major - 2 (Medium); 3-Minor - 3 (Low) | | Alert Category | category | Direct mapping or static value | | Alert Type ID | subcategory | Direct mapping | | Alert Status | state | Open - 1 (New); Closed - 6 (Resolved) | *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, status and state transitions, comments, attachments, and user assignments between SAP SolMan and ServiceNow. Each field can be mapped independently per direction. *** ### Frequently Asked Questions (FAQ)
Do I need to install anything in SAP SolMan before starting? Yes. The ZigiOps Integration Package for SAP SolMan must be imported and the RFC connection configured. Contact for assistance.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my SAP SolMan or ServiceNow data? No. ZigiOps does not permanently store transferred business data.
*** ### Related Resources * [How to connect SAP SolMan to ZigiOps](/available-systems/sap-solution-manager#how-do-i-connect-sap-solution-manager-to-zigiops) * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow#how-do-i-connect-servicenow-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [SAP SolMan ServiceNow integration troubleshooting](/operations-and-monitoring/troubleshooting) # ConnectWise Jira Integration Learn how to configure and manage ConnectWise PSA to Jira integrations in ZigiOps, including prerequisites, setup steps, mappings, and supported scenarios. Integrate ConnectWise PSA and Jira to synchronize service tickets, notes, attachments, and custom fields across MSP service desk and software development teams using ZigiOps - a secure, no-code integration platform. This integration enables real-time or scheduled data synchronization, eliminates manual ticket handoffs, and ensures a single source of truth between ConnectWise PSA and Jira. ### Integration video Video coming soon. A step-by-step walkthrough for this integration will be added here. ### What can I integrate between ConnectWise PSA and Jira? ZigiOps can integrate any ConnectWise PSA entity (Service Tickets, Projects, Activities, etc.) with any Jira issue type (Tasks, Bugs, Epics, etc.), allowing you to build custom workflows tailored to your processes and data models. Out of the box, ZigiOps provides ready-made integration templates for the most common ConnectWise PSA and Jira scenarios, including: * ConnectWise PSA Service Tickets to Jira Tasks * Jira Tasks to ConnectWise PSA Service Tickets * ConnectWise PSA Service Tickets to Jira Bugs * ConnectWise PSA Project Tickets to Jira Issues These templates serve as preconfigured starting points and can be customized or extended to support additional ConnectWise PSA ticket types, Jira projects, and business-specific workflows. Each integration scenario can be configured as one-way or bi-directional, with full control over field mappings, filters, triggers, and synchronization rules. | Common ConnectWise PSA entities | Common Jira issue types | Common fields typically synchronized | | ----------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------ | | Service Ticket | Task / Issue | Summary, Description, Priority, Status, Assignee, Notes / Comments, Attachments | | Project Ticket | Issue / Task | Summary, Description, Priority, Status, Owner / Assignee, Notes, Attachments | | Activity | Sub-task / Task | Summary, Description, Status, Assignee, Notes | | Service Ticket (Problem) | Bug / Issue | Summary, Description, Severity / Priority, Status, Assignee, Notes, Attachments | | **Any ConnectWise PSA ticket type** | **Any Jira issue type** | Standard + custom fields, Comments / Notes, Attachments, Status mappings, Correlation ID (recommended) | > **Note:** ZigiOps supports synchronization of all standard and custom fields for ConnectWise PSA and Jira. The table above lists only the most commonly used fields for clarity and illustration purposes. ### How does the ConnectWise PSA and Jira integration work? ZigiOps connects ConnectWise PSA and Jira using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling-based and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. ZigiOps supports both cloud and on-premise ConnectWise PSA deployments. ### Prerequisites and permissions Before enabling the ConnectWise PSA and Jira integration, ensure the following prerequisites are met. The prerequisites below apply to all ConnectWise PSA and Jira integration scenarios. Scenario-specific behavior is handled at the mapping and workflow level. | Integration Scenario | ConnectWise PSA - Authentication | ConnectWise PSA - Permissions | ConnectWise PSA - Environment | Jira - Authentication | Jira - Permissions | Jira - Environment | | ---------------------------------------------- | ------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------- | | ConnectWise PSA Service Tickets to Jira Tasks | Company ID + Public Key + Private Key | API access; Read / Create / Update service tickets | ConnectWise PSA (cloud or on-premise, up to and including version 2019.1) | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | Jira Tasks to ConnectWise PSA Service Tickets | Company ID + Public Key + Private Key | API access; Read / Create / Update service tickets | ConnectWise PSA (cloud or on-premise, up to and including version 2019.1) | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | | ConnectWise PSA Service Tickets to Jira Bugs | Company ID + Public Key + Private Key | API access; Read / Create / Update service tickets | ConnectWise PSA (cloud or on-premise, up to and including version 2019.1) | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software, Version 7.x or newer | | ConnectWise PSA Project Tickets to Jira Issues | Company ID + Public Key + Private Key | API access; Read / Create / Update project tickets | ConnectWise PSA (cloud or on-premise, up to and including version 2019.1) | Username + API Token | Create / Read / Update issues; Access to target projects | Jira Software or Jira Service Management, Version 7.x or newer | ### Setup Follow the steps below to enable the ConnectWise PSA and Jira integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to ZigiOps - Configurator. 3. Load the desired ConnectWise PSA and Jira integration template. 4. Select the corresponding Integrated Systems (ConnectWise PSA and Jira). 5. Click **Save** to continue. 6. Enable the integration using the slider button located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Mapping examples Below are typical field-mapping examples used across the ConnectWise PSA and Jira integration scenarios. Mappings can be customized per use case. **Example: ConnectWise PSA Service Ticket to Jira Task** | ConnectWise PSA field | Jira field | Advanced Field Mapping Example | | --------------------- | -------------------- | ------------------------------------------------------- | | Summary | Summary | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | New - To Do, In Progress - In Progress, Resolved - Done | | Owner | Assignee | - | | Notes | Comments | - | | Attachments | Attachments | - | | Company | Custom field / Label | - | **Example: Jira Task to ConnectWise PSA Service Ticket** | Jira field | ConnectWise PSA field | Advanced Field Mapping Example | | ----------- | --------------------- | ------------------------------------------------------- | | Summary | Summary | - | | Description | Description | - | | Priority | Priority | - | | Status | Status | To Do - New, In Progress - In Progress, Done - Resolved | | Assignee | Owner | - | | Comments | Notes | - | | Attachments | Attachments | - | **Example: ConnectWise PSA Project Ticket to Jira Issue** | ConnectWise PSA field | Jira field | | --------------------- | ------------- | | Summary | Summary | | Description | Description | | Priority | Priority | | Assigned to | Assignee | | Notes | Comments | | Attachments | Attachments | | Board / Project | Project | | Custom fields | Custom fields | ### What data can be synchronized? ZigiOps supports synchronization of: * Standard fields * Custom fields * Status / state transitions * Notes and Comments * Attachments * Users and assignments (configurable) * Company and contact data (configurable) Each field can be mapped independently for each synchronization direction. ### Frequently asked questions (FAQ)
Can I use one template for multiple Jira projects or ConnectWise boards? Yes. Filters and conditions allow you to scope synchronization by Jira project, ConnectWise board, status, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates between ConnectWise PSA and Jira.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI. No scripting or coding is required.
Can I start with one-way sync and later enable bi-directional sync? Yes. Synchronization direction can be changed at any time from within the ZigiOps Configurator.
Does ZigiOps store my ConnectWise PSA or Jira data? No. ZigiOps does not permanently store transferred business data.
Which ConnectWise PSA versions are supported? ZigiOps supports ConnectWise PSA up to and including version 2019.1, for both cloud and on-premise deployments.
### Related resources * [How to connect ConnectWise PSA to ZigiOps](/available-systems/connectwise#how-do-i-connect-connectwise-psa-to-zigiops) * [How to connect Jira to ZigiOps](/available-systems/jira#how-do-i-connect-jira-software-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Attachments and Comments sync](/design-and-mappings/attachments-and-comments) * [Custom fields sync](/design-and-mappings/custom-fields) # OBM ServiceNow Integration Integrate Operations Bridge Manager (OBM) and ServiceNow to automatically convert monitoring events into ITSM incidents This integration forwards OBM events to ServiceNow as incidents (including via a Staging Table), eliminates manual ticket creation, and ensures IT operations and service management teams work from a single source of truth. ### Integration Video {% embed url="" %} ### What Can I Integrate Between OBM and ServiceNow? ZigiOps can integrate any OBM event type with any ServiceNow table, enabling custom workflows tailored to your monitoring and ITSM processes. Out of the box, ZigiOps provides ready-made integration templates for the most common OBM to ServiceNow scenarios, including: * OBM Events - ServiceNow Incidents * OBM Events - ServiceNow Incidents (Staging Table) These templates serve as preconfigured starting points and can be customized or extended to support additional event types, ServiceNow tables, and business-specific workflows. | Common OBM entities | Common ServiceNow entities | Common fields typically synchronized | | ---------------------- | ---------------------------- | ------------------------------------------------------------------------------------- | | Event | Incident | Node, Title/Short Description, Severity/Priority, Status/State, Category, Description | | Event (Staging Table) | Incident (via Staging Table) | Node, Title, Severity, Status, Category, Custom fields | | **Any OBM event type** | **Any ServiceNow table** | **Standard + custom fields, Status/State mappings, Correlation ID (recommended)** | {% hint style="info" %} ZigiOps supports synchronization of all standard and custom fields for OBM and ServiceNow. The table above lists only the most commonly used fields. {% endhint %} *** ### How Does the OBM to ServiceNow Integration Work? ZigiOps connects OBM and ServiceNow using their native APIs and acts as a secure integration layer between the two systems. * No scripting or custom development required * Configured entirely through the ZigiOps UI * Supports polling- and event-based synchronization * Does not permanently store transferred business data The platform can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. *** ### Prerequisites and Permissions Before enabling the OBM to ServiceNow integration, ensure the following prerequisites are met. | Scenario | OBM Authentication | OBM Permissions | ServiceNow Permissions | | ------------------------------------------------- | ------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------- | | OBM Events - ServiceNow Incidents | Username + Password | External Event Processing Connected Server; Read/Write on events | x\_ziw\_obm.admin; personalize\_read\_dictionary; itil role | | OBM Events - ServiceNow Incidents (Staging Table) | Username + Password | External Event Processing Connected Server; Read/Write on events | x\_ziw\_obm.admin; personalize\_read\_dictionary; Access to staging table | *** ### Setup Follow the steps below to enable the OBM to ServiceNow integration using a prebuilt ZigiOps template. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired **OBM to ServiceNow integration template**. 4. Select the corresponding **Integrated Systems** (OBM and ServiceNow). 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Mapping Examples Below are typical field-mapping examples used in the OBM to ServiceNow Incident scenario. Mappings can be customized per use case. **Example: OBM Event - ServiceNow Incident** | OBM field | ServiceNow field | Advanced Field Mapping Example | | ------------------ | ------------------ | --------------------------------------------------------------------- | | node | cmdb\_ci | Direct mapping | | title | short\_description | Direct mapping | | severity | urgency / impact | 1-Critical - 1 (High); 2-Major - 2 (Medium); 3-Minor - 3 (Low) | | description | description | Direct mapping | | status (lifecycle) | state | Open - 1 (New); Acknowledged - 2 (In Progress); Closed - 6 (Resolved) | *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, status and state transitions, comments, attachments, and user assignments between OBM and ServiceNow. Each field can be mapped independently per direction. *** ### Frequently Asked Questions (FAQ)
Can I use one template for multiple projects or assignment groups? Yes. Filters and conditions allow you to scope synchronization by project, assignment group, state, priority, or custom logic.
Is the integration bi-directional? Yes. All scenarios support bi-directional synchronization, configurable per field.
How are update loops prevented? ZigiOps uses correlation IDs and internal logic to prevent circular updates.
Do I need to write scripts or use APIs manually? No. All configuration is done through the ZigiOps UI.
Can I start with one-way sync and later enable bi-directional sync? Yes. Direction can be changed at any time.
Does ZigiOps store my OBM or ServiceNow data? No. ZigiOps does not permanently store transferred business data.
*** ### Related Resources * [How to connect OBM to ZigiOps](/available-systems/operations-bridge-manager-obm#how-do-i-connect-obm-to-zigiops) * [How to connect ServiceNow to ZigiOps](/available-systems/servicenow#how-do-i-connect-servicenow-to-zigiops) * [Data mapping fundamentals](/design-and-mappings/data-mapping-fundamentals) * [OBM ServiceNow integrations troubleshooting](/operations-and-monitoring/troubleshooting) # Single Pane of Glass Connect any two monitoring or observability tools. Automatically synchronize alerts, events, metrics, and topology data. Whether your organization runs Dynatrace alongside OBM, Datadog alongside Splunk, or Amazon CloudWatch alongside on-premises monitoring tools, ZigiOps enables real-time data exchange between any two monitoring platforms. ### What Monitoring Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any two monitoring platforms with accessible APIs can be connected, including: * OBM / OpsBridge * Dynatrace * Datadog * Splunk Enterprise / Splunk Observability * SolarWinds * New Relic * Zabbix * Icinga * Nagios XI * Prometheus * AppDynamics * Foglight * CA UIM * vROps * Amazon CloudWatch * Azure Monitor * Oracle Enterprise Manager * Microsoft SCOM * SAP Solution Manager * BMC TrueSight OM * Nutanix * Kubernetes | Source Monitoring Tool (examples) | Target Monitoring Tool (examples) | Typical Scenarios | | --------------------------------- | --------------------------------- | ----------------------------------------------------------------------- | | Dynatrace | OBM / OpsBridge | Forward Dynatrace problems to OBM for centralized operations visibility | | Datadog | OBM / OpsBridge | Consolidate Datadog monitor alerts into OBM event console | | Zabbix | OBM / OpsBridge | Forward Zabbix alerts to OBM for cross-domain correlation | | Splunk | OBM / OpsBridge | Push Splunk notable events into OBM for AIOps processing | | Amazon CloudWatch | OBM / OpsBridge | Sync AWS cloud alerts into OBM alongside on-premises monitoring data | | **Any monitoring tool** | **Any monitoring tool** | **Any alert type, any entity - configurable via ZigiOps** | > **Note:** ZigiOps can integrate with any monitoring system that exposes a REST API, even if it is not in the pre-built template library. ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, alert and event data, metrics, topology records, and CI data between monitoring platforms. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ------------------ | ----------------------- | --------------------------------------------- | ---------------------------------------------------------------------- | | Alerts / Events | Bi-directional | Dynatrace Problem - OBM Event | Node/CI, Title, Severity, Status, Category, Description, Source system | | Metrics | Monitoring - Monitoring | CloudWatch Metric - OBM Metric | Metric name, Value, Timestamp, Source, Tags, Dimensions | | Topology | Monitoring - Monitoring | VMware vROps Topology - OBM Topology | Node name, Relationships, Attributes, CI type | | Custom alert types | Both directions | Any monitoring entity - Any monitoring entity | All standard and custom fields supported | ### How Does the Monitoring to Monitoring Integration Work? ZigiOps acts as a secure integration layer between two monitoring systems, using their native APIs and event mechanisms to read and write data. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based, event-driven, and webhook-based synchronization * Start from a pre-built template or build a custom integration from scratch * Apply severity mappings, topology transformations, field conditions, and filters * Does not permanently store transferred business data ### Setup Follow the steps below to enable a Monitoring to Monitoring integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Frequently Asked Questions (FAQ)
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
# Monitoring to DevOps Integration Connect any monitoring or observability tool to any DevOps platform. Automatically convert monitoring alerts and events into DevOps issues. Whether your teams use Dynatrace, Datadog, Splunk, Zabbix, New Relic, or another observability tool, ZigiOps enables real-time data exchange with DevOps platforms such as Jira, Azure DevOps, GitHub, and more. ### What Monitoring and DevOps Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any monitoring platform with an accessible API can be integrated with any DevOps tool supported by ZigiOps. **Monitoring and observability tools supported by ZigiOps:** * Dynatrace * Datadog * Splunk Enterprise / Splunk Observability * SolarWinds * New Relic * Zabbix * Icinga * Nagios XI * Prometheus * AppDynamics * OBM / OpsBridge * Amazon CloudWatch * Azure Monitor * CA UIM * vROps * Foglight * SAP Solution Manager **DevOps tools supported by ZigiOps:** * Jira (Software and Service Management) * Azure DevOps * GitHub * Bitbucket | Monitoring Tool (examples) | DevOps Tool (examples) | Typical Scenarios | | -------------------------- | ---------------------- | ------------------------------------------------------------------------------------ | | Dynatrace | Jira | Create Jira issues from Dynatrace problems; sync resolution status back to Dynatrace | | Datadog | Azure DevOps | Forward Datadog monitor alerts to Azure DevOps work items for engineering triage | | Splunk | Jira | Convert Splunk notable events to Jira bugs for developer follow-up | | Zabbix | Jira | Create Jira issues from Zabbix triggers; close them when alerts resolve | | New Relic | Azure DevOps | Forward New Relic violations to Azure DevOps for engineering investigation | | **Any monitoring tool** | **Any DevOps tool** | **Any alert type, any entity - configurable via ZigiOps** | {% hint style="info" %} ZigiOps can integrate with any system that exposes a REST API, even if it is not in the pre-built template library. {% endhint %} *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, alert and event data, severity mappings, and state transitions between monitoring tools and DevOps platforms. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ------------------ | -------------------- | --------------------------------------------- | ------------------------------------------------------------------------------ | | Alerts / Events | Monitoring - DevOps | Dynatrace Problem - Jira Bug | Node/CI, Title/Summary, Severity/Priority, Status/State, Category, Description | | Build failures | CI - DevOps tracking | Jenkins Build Failure - Jira Issue | Build ID, Status, Result, Branch, Error message | | Custom alert types | Both directions | Any monitoring entity - Any DevOps issue type | All standard and custom fields supported | *** ### How Does the Monitoring to DevOps Integration Work? ZigiOps acts as a secure integration layer between monitoring and DevOps systems, using their native APIs and event mechanisms to read and write data. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based, event-driven, and webhook-based synchronization * Start from a pre-built template or build a custom integration from scratch * Apply severity translations, state transitions, field mappings, and filters * Does not permanently store transferred business data *** ### Setup Follow the steps below to enable a Monitoring to DevOps integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Frequently Asked Questions (FAQ)
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
# DevOps to DevOps Integration Connect any two DevOps tools using ZigiOps. Automatically synchronize tasks, work items, bugs, stories, and pipeline events. Whether your teams work across Jira and Azure DevOps, GitHub and Jira, Bitbucket and Jira, or Jenkins and any issue tracker, ZigiOps enables real-time, bi-directional data exchange between any two DevOps platforms. ### What DevOps Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any two DevOps tools with accessible APIs can be connected, including: * Jira (Software and Service Management) * Azure DevOps * GitHub * Bitbucket | Source DevOps tool (examples) | Target DevOps tool (examples) | Typical Scenarios | | ----------------------------- | ----------------------------- | --------------------------------------------------------------------------------- | | Jira | Azure DevOps | Sync Jira issues and Azure DevOps work items across product and engineering teams | | Jira | GitHub | Create GitHub issues from Jira; sync labels, status, and comments back | | Azure DevOps | Jira | Forward Azure DevOps work items to Jira for cross-team visibility | | Bitbucket | Jira | Link Bitbucket commits and issues to Jira tickets | | Jenkins | Jira | Create Jira issues from Jenkins build failures automatically | | **Any DevOps tool** | **Any DevOps tool** | **Any entity, any field, any direction - configurable via ZigiOps** | > **Note:** ZigiOps can integrate with any DevOps system that exposes a REST API, even if it is not in the pre-built template library. ### What Data Can Be Synchronized? ZigiOps supports synchronization of all standard and custom fields, status transitions, comments, attachments, labels, and build metadata between DevOps tools. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ----------------------- | --------------- | ------------------------------------- | ----------------------------------------------------------------------------------- | | Tasks / Work Items | Bi-directional | Jira Issue - Azure DevOps Work Item | Title/Summary, Description, Priority, Status/State, Assignee, Comments, Attachments | | Bugs / Defects | Bi-directional | Jira Bug - GitHub Issue | Title, Description, Severity, Status, Assignee, Labels, Comments | | Build / Pipeline events | CI - Tracking | Jenkins Build - Jira Issue | Build ID, Status, Result, Branch, Triggered by | | Custom work item types | Both directions | Any DevOps entity - Any DevOps entity | All standard and custom fields supported | ### How Does the DevOps to DevOps Integration Work? ZigiOps acts as a secure integration layer between two DevOps systems, using their native APIs to read and write data. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based and event-driven (webhook) synchronization * Start from a pre-built template or build a custom integration from scratch * Apply field mappings, transformations, conditions, and filters per use case * Does not permanently store transferred business data ### Setup Follow the steps below to enable a DevOps to DevOps integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Frequently Asked Questions (FAQ)
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
# Incident Lifecycle Integration Connect any monitoring or observability tool to any ITSM platform. Automatically convert monitoring alerts, events, and topology data into ITSM incidents Whether your teams use Dynatrace, Datadog, Splunk, Zabbix, New Relic, OBM, or another observability platform, ZigiOps enables real-time data exchange with ITSM systems such as ServiceNow, Remedy, Freshservice, Ivanti, and more. ### What Monitoring and ITSM Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any monitoring platform with an accessible API can be integrated with any ITSM system supported by ZigiOps. **Monitoring and observability tools supported by ZigiOps:** * OBM / OpsBridge * Dynatrace * Datadog * Splunk Enterprise / Splunk Observability * SolarWinds * New Relic * Zabbix * Icinga * Nagios XI * Prometheus * AppDynamics * Foglight * CA UIM * vROps * Amazon CloudWatch * Azure Monitor * Oracle Enterprise Manager * Microsoft SCOM * SAP Solution Manager **ITSM platforms supported by ZigiOps:** * ServiceNow * Jira Service Management * BMC Remedy / Remedyforce/ Helix * Freshservice * Freshdesk * Ivanti * Cherwell * TOPdesk * IFS Assyst * Zendesk / Zendesk Sell | Monitoring Tool (examples) | ITSM Platform (examples) | Typical Scenarios | | -------------------------- | ------------------------ | ------------------------------------------------------------------------------- | | Dynatrace | ServiceNow | Forward Dynatrace problems to ServiceNow incidents; sync resolution status back | | Datadog | Jira Service Management | Create Jira tickets from Datadog monitors; update Datadog on ticket close | | Zabbix | Remedy | Convert Zabbix triggers to Remedy incidents automatically | | OBM / OpsBridge | ServiceNow | Forward OBM events to ServiceNow incidents (direct or via Staging Table) | | Splunk | Freshservice | Convert Splunk notable events to Freshservice tickets | | New Relic | Ivanti | Forward New Relic alerts to Ivanti for ITSM handling | | **Any monitoring tool** | **Any ITSM platform** | **Any alert type, any entity - configurable via ZigiOps** | > **Note:** ZigiOps can integrate with any system that exposes a REST API, even if it is not in the pre-built template library. ### What Data Can Be Synchronized? ZigiOps supports synchronization of standard and custom fields, alert and event data, topology information, and CMDB records between monitoring tools and ITSM platforms. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ------------------ | ---------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------- | | Alerts / Events | Monitoring - ITSM | Dynatrace Problem - ServiceNow Incident | Node/CI, Title/Short Description, Severity/Priority, Status/State, Category, Description | | Metrics | Monitoring - ITSM | Datadog Metric - ServiceNow CI metric | Metric name, Value, Timestamp, Source, Tags | | Topology / CMDB | Monitoring - ITSM CMDB | OBM Topology - ServiceNow CMDB | Node name, Relationships, Attributes, CI type | | Custom alert types | Both directions | Any monitoring entity - Any ITSM table | All standard and custom fields supported | ### How Does the Monitoring to ITSM Integration Work? ZigiOps acts as a secure integration layer between monitoring and ITSM systems, using their native APIs and event mechanisms to read and write data. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based, event-driven, and webhook-based synchronization * Start from a pre-built template or build a custom integration from scratch * Apply field mappings, severity translations, state transitions, and filters * Does not permanently store transferred business data ZigiOps can be deployed on-premises or used as a cloud service. ### Setup Follow the steps below to enable a Monitoring to ITSM integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. ### Frequently Asked Questions
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
# Multi-Vendor ITSM Integration Connect any two ITSM platforms. Automatically synchronize incidents, problems, change requests, and service tickets across service desks and enterprise ITSM systems Whether your organization runs ServiceNow alongside Remedy, Freshservice alongside Zendesk, or TOPdesk alongside Ivanti, ZigiOps enables real-time, bi-directional data exchange between any two ITSM systems. *** ### What ITSM Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any two ITSM platforms with accessible APIs can be connected, including: * ServiceNow * Jira Service Management * BMC Remedy / Remedyforce / Helix * Freshservice * Freshdesk * Ivanti * Cherwell * TOPdesk * IFS Assyst * Zendesk / Zendesk Sell * Salesforce Service Cloud * Microsoft Dynamics 365 * ConnectWise | Source ITSM (examples) | Target ITSM (examples) | Typical Scenarios | | ---------------------- | ---------------------- | ------------------------------------------------------------------------------ | | ServiceNow | Remedy | Sync incidents and problems bi-directionally between enterprise ITSM platforms | | ServiceNow | Freshservice | Bridge IT operations (ServiceNow) with team-level service desks (Freshservice) | | Remedy | Ivanti | Forward Remedy incidents to Ivanti for regional or departmental handling | | Freshservice | Zendesk | Escalate Zendesk tickets to Freshservice for IT team handling | | TOPdesk | ServiceNow | Bridge facilities or HR service desks with enterprise ITSM | | **Any ITSM platform** | **Any ITSM platform** | **Any entity, any field, any direction - configurable via ZigiOps** | {% hint style="info" %} ZigiOps can integrate with any ITSM system that exposes a REST API, even if it is not in the pre-built template library. {% endhint %} *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of all standard and custom fields, status and state transitions, comments, attachments, and user assignments between ITSM platforms. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ------------------- | --------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Incidents / Tickets | Bi-directional | ServiceNow Incident - Remedy Incident | Short description/Summary, Description, Priority, Status/State, Assignee, Comments, Attachments | | Problems | Bi-directional | ServiceNow Problem - Remedy Problem Investigation | Summary, Description, Severity, Status, Owner, Work notes | | Change Requests | Bi-directional | ServiceNow Change - Freshservice Change | Summary, Description, Risk, Status, Approvals, Owner | | Custom entities | Both directions | Any ITSM form - Any ITSM form | All standard and custom fields supported | *** ### How Does the ITSM to ITSM Integration Work? ZigiOps acts as a secure integration layer between two ITSM systems, using their native APIs to read and write data without modifying either system. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based and event-driven (webhook) synchronization * Start from a pre-built template or build a custom integration from scratch * Apply field mappings, transformations, conditions, and filters per use case * Does not permanently store transferred business data ZigiOps can be deployed on-premises or used as a cloud service. *** ### Setup Follow the steps below to enable an ITSM to ITSM integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. *** ### Frequently Asked Questions (FAQ)
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
*** # Shift Left (ITSM to DevOps) Connect any ITSM platform to any DevOps tool. Automatically synchronize incidents, tickets, problems, and change requests between your service management and development toolchains Whether your teams use ServiceNow, Remedy, Freshservice, Ivanti, Cherwell, or another ITSM system, ZigiOps enables real-time, bi-directional data exchange with DevOps platforms such as Jira, Azure DevOps, GitHub, Bitbucket, Jenkins, and more. *** ## What ITSM and DevOps Systems Can I Connect? ZigiOps supports 60+ enterprise systems. Any ITSM platform with an accessible API can be integrated with any DevOps tool supported by ZigiOps. **ITSM platforms supported by ZigiOps:** * ServiceNow * BMC Remedy / Remedyforce / Helix * Freshservice * Freshdesk * ConnectWise * Ivanti * Cherwell * TOPdesk * IFS Assyst * Zendesk / Zendesk Sell * Salesforce Service Cloud * Microsoft Dynamics 365 **DevOps tools supported by ZigiOps:** * Jira (Software and Service Management) * Azure DevOps * GitHub * Bitbucket | Source ITSM (examples) | Target DevOps (examples) | Typical Scenarios | | ---------------------- | ------------------------ | ----------------------------------------------------------------------------- | | ServiceNow | Jira | Sync incidents to Jira issues; sync Jira issues back to ServiceNow tickets | | Remedy | Azure DevOps | Forward Remedy incidents to Azure DevOps work items; sync status updates back | | Freshservice | GitHub | Create GitHub issues from Freshservice tickets; sync resolutions back | | Ivanti | Jira | Forward Ivanti incidents to Jira; sync comments and status bidirectionally | | Cherwell | Azure DevOps | Push Cherwell tickets to Azure DevOps work items | | Any ITSM platform | Any DevOps tool | Any entity, any field, any direction — configurable via ZigiOps templates | > **Note:** ZigiOps can integrate with any system that exposes a REST API, even if it is not in the pre-built template library. *** ### What Data Can Be Synchronized? ZigiOps supports synchronization of all standard and custom fields, status and state transitions, comments, attachments, and user assignments between ITSM and DevOps systems. Each field can be mapped independently per direction. | Entity type | Direction | Examples | Common fields synchronized | | ------------------- | --------------- | ------------------------------------ | ----------------------------------------------------------------------- | | Incidents / Tickets | ITSM - DevOps | ServiceNow Incident - Jira Issue | Summary, Description, Priority, Status, Assignee, Comments, Attachments | | Problems | ITSM - DevOps | Remedy Problem - Azure DevOps Bug | Summary, Description, Severity, Status, Owner, Work notes | | Change Requests | ITSM - DevOps | ServiceNow Change - Jira Epic | Summary, Description, Risk, Status, Approval state, Owner | | Custom entities | Both directions | Any ITSM form - Any DevOps work item | All standard and custom fields supported | *** ### How Does the ITSM to DevOps Integration Work? ZigiOps acts as a secure integration layer between ITSM and DevOps systems, using their native APIs to read and write data without modifying either system. * No scripting or custom development required * All configuration is done through the ZigiOps UI * Supports polling-based and event-driven (webhook) synchronization * Start from a pre-built template or build a custom integration from scratch * Apply field mappings, transformations, conditions, and filters per use case * Does not permanently store transferred business data ZigiOps can be deployed on-premises or used as a cloud service, depending on your security and compliance requirements. *** ### Setup Follow the steps below to enable an ITSM to DevOps integration using ZigiOps. 1. Log in to your ZigiOps instance. 2. Navigate to **ZigiOps - Configurator**. 3. Load the desired integration template (or create a new one from scratch). 4. Select the corresponding **Integrated Systems**. 5. Click **Save** to continue. 6. Enable the integration using the **slider button** located in the middle section of the screen. Once enabled, ZigiOps starts synchronizing data based on the configured mappings and rules. Templates can be adjusted at any time without restarting the integration. *** ### Frequently Asked Questions (FAQ)
Do I need coding or API skills to set up a custom integration? No. All configuration is handled through the ZigiOps UI. No scripting or API expertise is required.
Can I integrate systems that do not appear in the pre-built template library? Yes. ZigiOps allows you to create integrations from scratch for any system with an accessible API.
Is bi-directional synchronization supported? Yes. All integration types support bi-directional data flow, configurable per field.
How does ZigiOps prevent update loops? ZigiOps uses correlation IDs and internal deduplication logic to prevent circular updates between systems.
Can I apply conditions and filters to control which records are synchronized? Yes. Conditions, filters, and transformations can be applied at the field, record, or workflow level.
Does ZigiOps store transferred business data? No. ZigiOps does not permanently store transferred business data.
*** # Integration Guides Step-by-step integration guides for ZigiOps. Connect Jira, ServiceNow, Azure DevOps, Salesforce, and 60+ enterprise systems without writing a single line of code. This section contains detailed, step-by-step guides for every integration available in ZigiOps. Whether you are connecting Jira with ServiceNow, syncing Azure DevOps with Salesforce, or automating incident data between monitoring and ITSM tools, each guide walks you through the full setup process from start to finish. Each integration guide covers the required prerequisites, connected system configuration, template loading, field mapping, and any system-specific notes you need to know before going live. You do not need coding or API knowledge to follow these guides. ZigiOps handles all communication between systems through its no-code interface. Use the links below to navigate to the integration you need. If you are looking for a specific system's connection setup rather than a full integration walkthrough, visit the [Supported Systems](https://docs.zigiwave.com/available-systems) page instead. ### **Integration Guides** * Jira and ServiceNow Integration Guide * Jira and Azure DevOps Integration Guide * Jira and Salesforce Integration Guide * Jira and Remedy Integration Guide * ServiceNow and Azure DevOps Integration Guide # Jira ServiceNow Integration Guide Learn how to set up a bi-directional Jira ServiceNow integration in ZigiOps. Configure system instances, field mappings, filters, and correlation step by step. This guide explains how to configure a bi-directional integration between Jira and ServiceNow using ZigiOps. It covers adding system instances, selecting entity pairs, configuring correlation, building field mappings, applying filters, and testing the workflow. No scripting or coding is required at any stage. For a full overview of the sync capabilities between the two platforms, see the [Jira and ServiceNow integration page](https://www.zigiwave.com/integrations/jira-integration-with-servicenow) on the ZigiWave website. ### Overview The Jira-ServiceNow integration synchronizes records between your ITSM platform (ServiceNow) and your project tracking tool (Jira) automatically. When a record is created or updated in one system, ZigiOps reflects the change in the other system based on the workflow configuration. {% embed url="" %} **Most common supported entity pairs:** | ServiceNow Entity | Jira Entity | Sync Direction | | ---------------------- | ---------------------------------------- | ---------------------- | | Incident | Issue / Task | Bi-directional | | Problem | Bug | Bi-directional | | Change Request | Task | Bi-directional | | Service Catalog Task | Task | ServiceNow to Jira | | Work Notes | Comment | Configurable | | Additional Comments | Comment | Configurable | | Priority (numeric 1-4) | Priority (Highest / High / Medium / Low) | Mapped with conditions | | State (numeric) | Status (text transition) | Mapped with conditions | {% hint style="info" %} ZigiOps supports all Jira and ServiceNow entities. Contact support if you have questions for entities that are not mentioned here or for more complex use cases: . {% endhint %} ### Prerequisites Before configuring this integration, confirm that the following requirements are met: * **ZigiOps instance:** installed and running. See the Installation guide. * **Jira:** a dedicated integration user account with API token access and project-level permissions. * **ServiceNow:** a dedicated integration user with read and write permissions on Incident, Problem, or Change Request tables. * **Custom fields:** correlation fields must be created in both systems before configuring the workflow. See the [Correlation section](#step-4-configure-correlation) below. * **License:** the ZigiOps license must include the Jira-ServiceNow system pair. {% stepper %} {% step %} ### Add System Instances A system instance defines the connection between ZigiOps and a specific Jira or ServiceNow environment. You must add one instance for each system before configuring a workflow. #### Add a Jira System Instance 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **Jira**. 3. Enter the following connection parameters: * **Server URL:** the base URL of your Jira environment (for example, `https://yourcompany.atlassian.net`). * **Username:** the Jira user account ZigiOps will use for API calls. * **API Token:** generated in your Atlassian account settings under Security > API tokens. * **Project Key:** scopes the integration to the correct Jira project. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. 4. Click **Save** to store the configuration. 5. Click **Test Connection** to verify that ZigiOps can reach the Jira API. If the test succeeds, available fields and projects are downloaded automatically.

ZigiOps UI - Adding Jira as a Connected System.

#### Add a ServiceNow System Instance 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **ServiceNow**. 3. Enter the following connection parameters: * **Instance URL:** the base URL of your ServiceNow instance (for example, `https://yourcompany.service-now.com`). * **Username:** the ServiceNow integration user account. * **Password:** the password for the integration user. * **OAuth Credentials (optional):** Client ID and Client Secret, required if your ServiceNow instance enforces OAuth 2.0 authentication. 4. Click **Save**. 5. Click **Test Connection** to verify connectivity.

ZigiOps UI - Adding ServiceNow as a Connected System.

{% hint style="info" %} If the Test Connection fails, verify that the integration user has the required API permissions and that the instance URL does not include a trailing slash. {% endhint %} {% endstep %} {% step %} ### Create or Load a Workflow A workflow defines the complete configuration for your integration, including the entity pair, triggers, field mappings, filters, and correlation logic. ZigiOps provides pre-built workflow templates for the most common Jira-ServiceNow use cases. A template includes pre-configured field mappings for summary, description, and priority, as well as basic correlation and trigger settings. You can load a template and adjust it to match your environment, or create a custom workflow from scratch. #### Option A: Load a Workflow Template 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Load from Template**. 3. Locate the relevant Jira-ServiceNow template (for example, ServiceNow Incidents to Jira Tasks). 4. Click **Load** and then adjust the configuration as needed.

ZigiOps UI - Workflow template selection screen.

#### Option B: Create a Custom Workflow 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Custom Integration**. 3. Assign a name to the workflow and proceed to configure each section as described in the steps below. {% endstep %} {% step %} ### Select the Entity Pair The entity pair defines which record types in each system will be synchronized. Select the combination that matches your use case. | Use Case | ServiceNow Entity | Jira Entity | | ------------------------------------- | -------------------- | ------------ | | Incident-driven development | Incident | Issue / Task | | Root cause analysis alignment | Problem | Bug | | Change management and sprint planning | Change Request | Task | | Service request fulfillment | Service Catalog Task | Task | For a fully bi-directional synchronization, configure at least two actions within the workflow: one to create and update Jira records from ServiceNow records, and one to update ServiceNow records when Jira records change.

ZigiOps UI - Entity pair selection screen.

{% endstep %} {% step %} ### Configure Correlation Correlation is the mechanism ZigiOps uses to match existing records across systems during update cycles. It stores only unique identifiers, not business data. Without correlation, every sync cycle would create new records rather than updating existing ones. You define which field in each system stores the unique identifier of its counterpart. Common patterns are: * **Jira custom field (for example, "ServiceNow ID"):** stores the ServiceNow `sys_id` of the linked incident. * **ServiceNow field (for example, "correlation\_id" or a custom field "Jira Reference"):** stores the Jira issue key (for example, `OPS-4512`). Create the required custom fields in each system **before** configuring correlation in ZigiOps. Once the fields exist, map them in the Correlation section of the workflow.

ZigiOps UI - Correlation configuration screen.

{% hint style="info" %} ZigiOps supports one-to-one correlation by default. Each Jira record maps to exactly one ServiceNow record. This prevents duplicate creation even if an event is processed more than once. {% endhint %} {% endstep %} {% step %} ### Configure Field Mappings Field mappings define which fields are synchronized between the two systems and how their values are transformed. Mappings are configured separately for each action direction.

ZigiOps UI - Field Mapping table.

#### Minimum Required Field Mappings | ServiceNow Field | Jira Field | Notes | | --------------------------- | ---------------------------- | --------------------------------------------------------------- | | `short_description` | `summary` | Direct text mapping | | `description` | `description` | Direct text mapping | | `priority` (numeric) | `priority` (text) | Requires conditional mapping | | `state` (numeric) | `status` (text transition) | Requires conditional mapping with Jira transition IDs | | `work_notes` | `comment.body` | Internal notes only. Apply author filter to prevent echo loops. | | `assignment_group` | `assignee` or `component` | Map based on team structure | | `sys_id` | Custom field: ServiceNow ID | Used for correlation. Not displayed to end users. | | `number` (e.g., INC0012345) | Custom field: SNOW Reference | Human-readable cross-reference | #### State Mapping ServiceNow uses a numeric State field based on an ITIL state machine. Jira uses a text-based Status field controlled by workflow transitions. These must be mapped conditionally, not as a direct value lookup. | ServiceNow State (numeric) | ServiceNow Label | Jira Status | Notes | | -------------------------- | ---------------- | -------------------- | ----------------------------------------------------- | | 1 | New | To Do | Direct mapping | | 2 | In Progress | In Progress | Direct mapping | | 3 | On Hold | On Hold / Blocked | Map to custom Jira status if available | | 6 | Resolved | Done | Requires `close_code` and `close_notes` in ServiceNow | | 7 | Closed | Done | Terminal state. Do not reopen via integration. | | 8 | Cancelled | Cancelled / Won't Do | Map to custom Jira status if available | {% hint style="info" %} Closing a ServiceNow incident requires both `close_code` and `close_notes`. If these fields are not included in the mapping when Jira status is set to Done, the ServiceNow API call will fail. Add a conditional mapping: when Jira status = Done, send `close_code` = `'Closed/Resolved by Caller'` and `close_notes` = `'Closed by Jira integration'`. {% endhint %} When mapping ServiceNow Resolved to Jira Done, use the Jira transition ID rather than setting the status field value directly. This ensures that Jira workflow validators, post-functions, and required fields are respected.

ZigiOps UI - State conditional mapping.

#### Priority Mapping ServiceNow calculates priority from a combination of Impact and Urgency. Jira uses a flat text-based priority list. A direct numeric-to-text mapping will often misrepresent business impact. The recommended approach uses both source fields together: | ServiceNow Priority | ServiceNow Impact | ServiceNow Urgency | Jira Priority | | ------------------- | ----------------- | ------------------ | ------------- | | 1 - Critical | 1 - High | 1 - High | Highest | | 2 - High | 1 - High | 2 - Medium | High | | 2 - High | 2 - Medium | 1 - High | High | | 3 - Moderate | 2 - Medium | 2 - Medium | Medium | | 4 - Low | 3 - Low | Any | Low |

ZigiOps UI - Priority conditional mapping.

#### Comment Synchronization ServiceNow distinguishes between Work Notes (internal) and Additional Comments (customer-visible). Jira does not make this distinction. Syncing all ServiceNow notes to Jira without filtering may expose internal information to development teams. Recommended comment mapping: * **ServiceNow Additional Comments to Jira:** sync public-facing comments only. * **Jira comments to ServiceNow:** map to Work Notes (internal) to preserve visibility boundaries. * **Author filter:** exclude comments authored by the integration user to prevent echo loops. * **Last Time expression:** use `{lasttimecomment}` to collect only comments created after the last successful run. Configure comment synchronization via the Related Records section of the field mapping configuration in ZigiOps. {% endstep %} {% step %} ### Configure Triggers Triggers define when ZigiOps collects data from the source system. ZigiOps supports two trigger types, which can be used together for the most reliable coverage. | Trigger Type | Mechanism | Recommended Use | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Poller | ZigiOps queries the source system API on a configurable schedule (default: every 1 minute). | SLA monitoring, controlled sync cycles, systems without webhook support | | Web Listener | ZigiOps registers an HTTP endpoint and waits for the source system to push data via webhook. Activated when the action is enabled. | Real-time status updates, incident creation alerts, near-instant synchronization | Using both trigger types in combination is the recommended approach for production deployments. The Poller provides complete coverage; the Web Listener reduces latency for time-critical events.

ZigiOps UI - Trigger configuration.

{% endstep %} {% step %} ### Add Filters and Conditions Filters control which records are collected and when. Without proper filtering, the integration may process records that should be excluded or miss critical records that need to be synced. Common filter configurations for Jira-ServiceNow workflows: * **Last Time expression:** collect only records created or updated since the previous run. Use the `{lasttime}` expression in the filter condition. * **Environment scope:** exclude records from test or sandbox projects. * **Priority threshold:** sync P1 and P2 incidents in real time; batch-sync lower priorities. * **Author exclusion:** filter out comments where the author matches the integration user account, to prevent duplicate comment loops. * **Production-only scope:** apply environment-based conditions to sync only production-affecting incidents. ZigiOps supports AND and OR logic, with operators including: is, is not, is one of, is not one of, is empty, is not empty, contains, does not contain, less than, greater than, and equals. Conditions can be applied to any field available from the connected system.

ZigiOps UI - Filter and Condition Builder.

{% endstep %} {% step %} ### Use Expressions for Data Transformation (Optional) Expressions apply transformations to field values after data is collected from the source and before it is delivered to the target. They are configured in the Source and Target tabs of the workflow action and do not require any scripting. | Expression | What It Does | Jira-ServiceNow Example | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Date and Time Format | Converts epoch timestamps to a human-readable string | Convert ServiceNow `sys_created_on` to a readable date for a Jira custom field | | First N Characters | Extracts the first N characters of a field value | Truncate long ServiceNow descriptions to fit Jira's 255-character summary limit | | Pattern (RegEx) | Extracts a value matching a regular expression. Group 1 is returned if a capturing group is defined. | Extract environment name (for example, PROD-EU-WEST) from a monitoring alert payload | | Replace Text | Replaces a specific substring with another value | Replace internal codenames with public-facing system names before syncing to Jira | | Replace Pattern (RegEx) | Replaces all matches of a RegEx pattern | Mask IP addresses or credentials before syncing logs from ServiceNow to Jira | | Build Array | Combines multiple values into a comma-separated array | Aggregate multiple ServiceNow tags into a Jira label array | | Last Time | Stores the timestamp of the last successful run; auto-increments on each execution | Collect only records updated after `{lasttime}` to prevent duplication | | To Lower Case / To Upper Case | Normalizes text casing | Align status values or category names that differ only in casing between systems |

ZigiOps UI - Expression configuration.

{% endstep %} {% step %} ### Test and Activate the Workflow Before activating the workflow in production, test each action individually using the built-in troubleshooting tools. #### Testing Tools Available in ZigiOps * **Real-time operation logs:** show every record collected, processed, and delivered. * **Payload inspector:** displays the raw data sent to and received from each system, useful for debugging field mapping issues. * **HTTP request and response data:** provides API-level details for connectivity troubleshooting. * **Error classification:** distinguishes between mapping errors, connectivity issues, and API rejections. **To activate the workflow:** 1. Run the workflow in **test mode** against a non-production record. 2. Verify that the target record is created with the correct field values. 3. Check the Activity Log for any errors or unexpected field values. 4. Once results are confirmed, set the workflow status to **Active**. {% endstep %} {% endstepper %}

ZigiOps Dashboard - Monitoring view.

### Advanced: Governance and Reliability The following practices apply to production deployments and regulated environments. #### Idempotency via Correlation Lookup Before any write operation, ZigiOps checks whether a correlated record already exists in the target system. If one exists, it performs an update. If none exists, it creates a new record. This two-path logic prevents duplicate records when events are reprocessed after a failure or retry. #### Retry Logic Failed operations caused by transient API errors (rate limits, maintenance windows, network interruptions) are retried automatically. ZigiOps distinguishes between transient failures (retried) and permanent failures (logged and surfaced in the Activity Log). Retries do not create duplicate records due to the correlation lookup described above. #### Governance Recommendations | Practice | Why It Matters | How ZigiOps Supports It | | ---------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Define integration ownership | Someone must be accountable for mapping logic and change testing | ZigiOps provides user-level access control and admin roles | | Test changes in staging first | Untested mapping changes can silently misbehave in production | ZigiOps supports multiple environments; test before activating | | Export and version integration templates | Integration configurations should be treated like production code | Export templates and store in a version control system | | Monitor operational health continuously | Silent failures are as damaging as loud ones | ZigiOps provides dashboards with real-time error tracking and operation metrics | | Audit comment and attachment sync rules | Internal notes may be exposed to unauthorized teams if filters are missing | Use conditional mapping and author filters to enforce data classification | ### Troubleshooting | Issue | Likely Cause | Resolution | | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Fields are missing from mapping suggestions | The system schema was not refreshed after new fields were added | Navigate to Connected Systems, select the system, and click Save to re-download the schema | | Duplicate comments appear in the target system | Integration user exclusion filter is missing, or `{lasttimecomment}` expression is not configured | Add a trigger condition excluding the integration user as comment author; configure the `{lasttimecomment}` filter | | ServiceNow incident fails to resolve via Jira | `close_code` and `close_notes` are required by ServiceNow but are not included in the mapping | Add conditional mappings: send `close_code` and `close_notes` only when Jira status = Done | | Jira status does not update after a ServiceNow state change | The mapping is setting the status field value directly rather than using a Jira workflow transition ID | Replace the status field value with the correct Jira transition ID in the mapping configuration | | Workflow saves but fails to activate | A mandatory configuration field is missing, or the license does not include the Jira-ServiceNow system pair | Review the error message in the UI; verify the license status under Admin > About | | Priority values do not match between systems | ServiceNow numeric priorities are mapped directly to Jira priority labels without considering Impact and Urgency | Use conditional mapping to evaluate Impact and Urgency together and produce the correct Jira priority output | ### Related Resources * [Workflow Templates - ServiceNow Incidents to Jira Tasks](/integration-catalog/jira-servicenow-integration) * [Building Integrations - Data Mapping Fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Building Integrations - Filters and Conditions](/design-and-mappings/filters-and-conditions) * [Building Integrations - Transformations and Expressions](/design-and-mappings/transformations-and-expressions) * [Building Integrations - Comments and Attachment Sync](/design-and-mappings/attachments-and-comments) * [Troubleshooting - Mapping Issues](/operations-and-monitoring/troubleshooting) * [ZigiOps System Requirements](/integration-platform/system-requirements) # Jira Salesforce Integration Guide Learn how to set up a bi-directional Jira Salesforce integration in ZigiOps. Configure system instances, entity pairs, field mappings, and filters step by step. This guide explains how to configure a bi-directional integration between Jira and Salesforce using ZigiOps. It covers adding system instances, selecting entity pairs, configuring correlation, building field mappings, applying filters, and testing the workflow. No scripting or coding is required at any stage. For a full overview of the sync capabilities between the two platforms, see the [Jira and Salesforce integration page](https://www.zigiwave.com/integrations/jira-integration-with-salesforce) on the ZigiWave website. ### Overview The Jira-Salesforce integration synchronizes records between your CRM platform (Salesforce) and your project tracking tool (Jira) automatically. When a record is created or updated in one system, ZigiOps reflects the change in the other system based on the workflow configuration. {% embed url="" %} **Most common supported entity pairs:** | Salesforce Entity | Jira Entity | Sync Direction | | ----------------- | ------------------------ | ---------------------- | | Case | Issue / Task | Bi-directional | | Case | Bug | Bi-directional | | Lead | Task | Salesforce to Jira | | Opportunity | Task | Configurable | | Custom Object | Task / Issue | Configurable | | Case Comment | Comment | Configurable | | Attachment | Attachment | Configurable | | Priority | Priority | Mapped with conditions | | Status | Status (text transition) | Mapped with conditions | > **Note:** ZigiOps supports all standard and custom Salesforce objects. Contact support for entities not listed above or for more complex use cases: . ### Prerequisites Before configuring this integration, confirm that the following requirements are met: * **ZigiOps instance:** installed and running. See the Installation guide. * **Jira:** a dedicated integration user account with API token access and project-level permissions. * **Salesforce:** an administrator account, or a user account with "Modify All Data" permission and API access enabled. The account must have access to all objects and fields included in the integration. * **Salesforce Connected App:** a Connected App must be configured in Salesforce to obtain the Client ID and Client Secret required for OAuth authentication. See the [Salesforce system instance section](#add-a-salesforce-system-instance) below. * **Custom fields:** correlation fields must exist in both systems before configuring the workflow. See the [Correlation section](#step-4-configure-correlation) below. * **Attachment sync (optional):** Salesforce does not update the `lastmodifieddate` field when an attachment is added to a record. If attachment synchronization is required, a mechanism that updates `lastmodifieddate` on attachment creation must be implemented on the Salesforce side. * **License:** the ZigiOps license must include the Jira-Salesforce system pair. {% stepper %} {% step %} ### Add System Instances A system instance defines the connection between ZigiOps and a specific Jira or Salesforce environment. You must add one instance for each system before configuring a workflow. #### Add a Salesforce System Instance Salesforce uses OAuth 2.0 authentication. Before adding the system instance in ZigiOps, retrieve the Client ID and Client Secret from your Salesforce Connected App. **How to Find Your Client ID and Client Secret in Salesforce** 1. Log into your Salesforce instance. 2. Navigate to **Settings** > **Setup** > **Apps** > **App Manager**. 3. Click the **View** button for the desired Connected App. 4. The **Client ID** and **Client Secret** are displayed in the Manage Application menu. **Add the Salesforce system instance in ZigiOps:** 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **Salesforce**. 3. Enter the following connection parameters: * **URL:** the base URL of your Salesforce instance (for example, `https://example.lightning.force.com`). * **Username:** the Salesforce integration user account. * **Password:** the password for the integration user. * **Client ID:** the Client ID from your Salesforce Connected App. * **Client Secret:** the Client Secret from your Salesforce Connected App. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. 4. Click **Save**. 5. Click **Test Connection** to verify that ZigiOps can reach the Salesforce API. If the test succeeds, available objects and fields are downloaded automatically.

ZigiOps UI - Adding Salesforce as a Connected System.

#### Add a Jira System Instance 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **Jira**. 3. Enter the following connection parameters: * **Server URL:** the base URL of your Jira environment (for example, `https://yourcompany.atlassian.net`). * **Username:** the Jira user account ZigiOps will use for API calls. * **API Token:** generated in your Atlassian account settings under Security > API tokens. * **Project Key:** scopes the integration to the correct Jira project. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. 4. Click **Save**. 5. Click **Test Connection** to verify that ZigiOps can reach the Jira API. If the test succeeds, available fields and projects are downloaded automatically.

ZigiOps UI - Adding Jira as a Connected System.

> **Note:** If the Test Connection fails for either system, verify that the integration user has the required API permissions and that the instance URL does not include a trailing slash. > {% endstep %} {% step %} ### Create or Load a Workflow A workflow defines the complete configuration for your integration, including the entity pair, triggers, field mappings, filters, and correlation logic. ZigiOps provides pre-built workflow templates for the most common Jira-Salesforce use cases. A template includes pre-configured field mappings for summary, description, and priority, as well as basic correlation and trigger settings. You can load a template and adjust it to match your environment, or create a custom workflow from scratch. #### Option A: Load a Workflow Template 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Load from Template**. 3. Locate the relevant Jira-Salesforce template. Commonly used templates include: * Salesforce Cases to Jira Tasks * Jira Tasks to Salesforce Cases 4. Click **Load** and adjust the configuration as needed.

ZigiOps UI - Workflow template selection screen.

#### Option B: Create a Custom Workflow 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Custom Integration**. 3. Assign a name to the workflow and proceed to configure each section as described in the steps below. {% endstep %} {% step %} ### Select the Entity Pair The entity pair defines which record types in each system will be synchronized. Select the combination that matches your use case. | Use Case | Salesforce Entity | Jira Entity | | ------------------------------------------------- | ----------------- | ------------ | | Customer issue tracking and development alignment | Case | Issue / Task | | Bug tracking linked to customer reports | Case | Bug | | Sales-driven feature or project requests | Opportunity | Task | | Marketing or sales lead follow-up | Lead | Task | | Custom business process synchronization | Custom Object | Task / Issue | For a fully bi-directional synchronization, configure at least two actions within the workflow: one to create and update Jira records from Salesforce records, and one to update Salesforce records when Jira records change.

ZigiOps UI - Entity pair selection screen.

{% endstep %} {% step %} ### Configure Correlation Correlation is the mechanism ZigiOps uses to match existing records across systems during update cycles. It stores only unique identifiers, not business data. Without correlation, every sync cycle would create new records rather than updating existing ones. You define which field in each system stores the unique identifier of its counterpart. Common patterns are: * **Jira custom field (for example, "Salesforce Case ID"):** stores the Salesforce Case ID or object ID of the linked record. * **Salesforce field (for example, a custom field "Jira Reference"):** stores the Jira issue key (for example, `OPS-4512`). Create the required custom fields in each system **before** configuring correlation in ZigiOps. Once the fields exist, map them in the Correlation section of the workflow.

ZigiOps UI - Correlation configuration screen.

> **Note:** ZigiOps supports one-to-one correlation by default. Each Jira record maps to exactly one Salesforce record. This prevents duplicate creation even if an event is processed more than once. > {% endstep %} {% step %} ### Configure Field Mappings Field mappings define which fields are synchronized between the two systems and how their values are transformed. Mappings are configured separately for each action direction.

ZigiOps UI - Field Mapping table.

#### Minimum Required Field Mappings | Salesforce Field | Jira Field | Notes | | ---------------- | ---------------------------------- | ------------------------------------------------------------------------- | | `Subject` | `summary` | Direct text mapping | | `Description` | `description` | Direct text mapping | | `Priority` | `priority` | Requires conditional mapping if label names differ | | `Status` | `status` (text transition) | Requires conditional mapping with Jira transition IDs | | `Case Comment` | `comment.body` | Configure via Related Records. Apply author filter to prevent echo loops. | | `OwnerId` | `assignee` | Map based on team structure | | `Id` (Case ID) | Custom field: Salesforce Case ID | Used for correlation. Not displayed to end users. | | `CaseNumber` | Custom field: Salesforce Reference | Human-readable cross-reference | #### Status Mapping Salesforce Cases use a text-based Status field with values that are configurable per organization. Jira uses a Status field governed by workflow transitions. These must be mapped conditionally, not as a direct value copy. | Salesforce Case Status | Jira Status | Notes | | ---------------------- | ----------------- | -------------------------------------------------------------------- | | New | To Do | Direct mapping | | Working | In Progress | Direct mapping | | Escalated | In Progress | Map to an Escalated status in Jira if available | | On Hold | On Hold / Blocked | Map to custom Jira status if available | | Closed | Done | Terminal state. Verify any required Jira resolution fields are sent. | > **Note:** Salesforce status values are configurable per organization and may differ from the defaults above. Verify the exact status labels used in your Salesforce instance before configuring these mappings. When mapping Salesforce Closed to Jira Done, use the Jira transition ID rather than setting the status field directly to ensure workflow validators and required fields are respected.

ZigiOps UI - Status conditional mapping.

#### Priority Mapping Salesforce uses a text-based priority field (High, Medium, Low). Jira also uses text-based priorities, but label names may vary between instances. Map values conditionally to ensure business impact is accurately represented. | Salesforce Priority | Jira Priority | Notes | | ------------------- | ------------- | -------------------------- | | High | High | Direct conditional mapping | | Medium | Medium | Direct conditional mapping | | Low | Low | Direct conditional mapping | > **Note:** Verify the exact priority label names used in your Jira instance before configuring these mappings. Label names vary between Jira Cloud and Jira Data Center, and may differ per project. If your Jira instance includes a "Highest" priority level, map Salesforce High cases that are also marked Urgent or Critical to that value using a conditional mapping. #### Comment Synchronization Salesforce uses Case Comments for customer-facing and internal communication. Jira uses Comments. Syncing all Salesforce Case Comments to Jira without filtering may expose customer-visible notes to internal development teams, or vice versa. Recommended comment mapping: * **Salesforce Case Comment to Jira Comment:** sync only comments relevant to the development team. * **Jira Comment to Salesforce Case Comment:** map developer updates back as Case Comments to keep customer-facing teams informed. * **Author filter:** exclude comments authored by the integration user to prevent echo loops. * **Last Time expression:** use `{lasttimecomment}` to collect only comments created after the last successful run. Configure comment synchronization via the Related Records section of the field mapping configuration in ZigiOps. {% endstep %} {% step %} ### Configure Triggers Triggers define when ZigiOps collects data from the source system. ZigiOps supports two trigger types, which can be used together for the most reliable coverage. | Trigger Type | Mechanism | Recommended Use | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Poller | ZigiOps queries the source system API on a configurable schedule (default: every 1 minute). | SLA monitoring, controlled sync cycles, systems without webhook support | | Web Listener | ZigiOps registers an HTTP endpoint and waits for the source system to push data via webhook. Activated when the action is enabled. | Real-time status updates, case creation alerts, near-instant synchronization | Using both trigger types in combination is the recommended approach for production deployments. The Poller provides complete coverage; the Web Listener reduces latency for time-critical events.

ZigiOps UI - Trigger configuration.

{% endstep %} {% step %} ### Add Filters and Conditions Filters control which records are collected and when. Without proper filtering, the integration may process records that should be excluded or miss records that need to be synced. Common filter configurations for Jira-Salesforce workflows: * **Last Time expression:** collect only records created or updated since the previous run. Use the `{lasttime}` expression in the filter condition. * **Environment scope:** exclude records from sandbox or test Salesforce environments. * **Priority threshold:** sync High priority cases in real time; batch-sync lower priorities. * **Author exclusion:** filter out Case Comments authored by the integration user to prevent duplicate comment loops. * **Record type scope:** restrict collection to specific Salesforce record types or case origins (for example, only sync cases where Origin = Web or Email). ZigiOps supports AND and OR logic, with operators including: is, is not, is one of, is not one of, is empty, is not empty, contains, does not contain, less than, greater than, and equals. Conditions can be applied to any field available from the connected system.

ZigiOps UI - Filter and Condition Builder.

{% endstep %} {% step %} ### Use Expressions for Data Transformation (Optional) Expressions apply transformations to field values after data is collected from the source and before it is delivered to the target. They are configured in the Source and Target tabs of the workflow action and do not require any scripting.

ZigiOps UI - Expression configuration.

| Expression | What It Does | Jira-Salesforce Example | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Date and Time Format | Converts epoch timestamps to a human-readable string | Convert Salesforce `CreatedDate` to a readable format for a Jira custom field | | First N Characters | Extracts the first N characters of a field value | Truncate long Salesforce case descriptions to fit Jira's 255-character summary limit | | Pattern (RegEx) | Extracts a value matching a regular expression. Group 1 is returned if a capturing group is defined. | Extract a product version or error code from a Salesforce case subject line | | Replace Text | Replaces a specific substring with another value | Replace internal account codes with product names before syncing to Jira | | Replace Pattern (RegEx) | Replaces all matches of a RegEx pattern | Mask customer account numbers before syncing case descriptions | | Build Array | Combines multiple values into a comma-separated array | Aggregate multiple Salesforce case tags into a Jira label array | | Last Time | Stores the timestamp of the last successful run; auto-increments on each execution | Collect only records updated after `{lasttime}` to prevent duplication | | To Lower Case / To Upper Case | Normalizes text casing | Align status or category values that differ only in casing between systems | | {% endstep %} | | | {% step %} ### Test and Activate the Workflow Before activating the workflow in production, test each action individually using the built-in troubleshooting tools. #### Testing Tools Available in ZigiOps * **Real-time operation logs:** show every record collected, processed, and delivered. * **Payload inspector:** displays the raw data sent to and received from each system, useful for debugging field mapping issues. * **HTTP request and response data:** provides API-level details for connectivity troubleshooting. * **Error classification:** distinguishes between mapping errors, connectivity issues, and API rejections. **To activate the workflow:** 1. Run the workflow in **test mode** against a non-production record. 2. Verify that the target record is created with the correct field values. 3. Check the **Activity Log** for any errors or unexpected field values. 4. Once results are confirmed, set the workflow status to **Active**. {% endstep %} {% endstepper %}

ZigiOps Dashboard - Monitoring view.

### Advanced: Governance and Reliability The following practices apply to production deployments and regulated environments. #### Idempotency via Correlation Lookup Before any write operation, ZigiOps checks whether a correlated record already exists in the target system. If one exists, it performs an update. If none exists, it creates a new record. This two-path logic prevents duplicate records when events are reprocessed after a failure or retry. #### Retry Logic Failed operations caused by transient API errors (rate limits, maintenance windows, network interruptions) are retried automatically. ZigiOps distinguishes between transient failures (retried) and permanent failures (logged and surfaced in the Activity Log). Retries do not create duplicate records due to the correlation lookup described above. #### Governance Recommendations | Practice | Why It Matters | How ZigiOps Supports It | | ---------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | Define integration ownership | Someone must be accountable for mapping logic and change testing | ZigiOps provides user-level access control and admin roles | | Test changes in staging first | Untested mapping changes can silently misbehave in production | ZigiOps supports multiple environments; test before activating | | Export and version integration templates | Integration configurations should be treated like production code | Export templates and store in a version control system | | Monitor operational health continuously | Silent failures are as damaging as loud ones | ZigiOps provides dashboards with real-time error tracking and operation metrics | | Audit comment and attachment sync rules | Customer-visible notes may be exposed to internal teams if filters are missing | Use conditional mapping and author filters to enforce data classification | ### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Fields are missing from mapping suggestions | The system schema was not refreshed after new fields were added | Navigate to Connected Systems, select the system, and click Save to re-download the schema | | Duplicate Case Comments appear in Jira | Integration user exclusion filter is missing, or `{lasttimecomment}` expression is not configured | Add a trigger condition excluding the integration user as comment author; configure the `{lasttimecomment}` filter | | Salesforce record fails to update when Jira changes | The correlation field in Salesforce is empty or not correctly mapped | Verify that the Respond Mapping writes the Jira issue key to the Salesforce correlation field after record creation | | Jira status does not update after a Salesforce status change | The mapping is setting the status field directly rather than using a Jira workflow transition ID | Replace the status field value with the correct Jira transition ID in the mapping configuration | | Attachments are not being collected from Salesforce | Salesforce does not update `lastmodifieddate` when attachments are added | Implement a Salesforce trigger or flow that updates `lastmodifieddate` on the parent record when an attachment is added | | Workflow saves but fails to activate | A mandatory configuration field is missing, or the license does not include the Jira-Salesforce pair | Review the error message in the UI; verify the license status under Admin > About | | OAuth authentication fails on Salesforce connection | Client ID or Client Secret is incorrect, or the Connected App does not have the required OAuth scopes | Verify the Connected App configuration in Salesforce and confirm that API access is enabled for the integration user | ### Related Resources * [Integration Catalog - Salesforce Jira Integrations](/integration-catalog/salesforce-jira-integration) * [Building Integrations - Data Mapping Fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Building Integrations - Filters and Conditions](/design-and-mappings/filters-and-conditions) * [Building Integrations - Transformations and Expressions](/design-and-mappings/transformations-and-expressions) * [Building Integrations - Comments and Attachment Sync](/design-and-mappings/attachments-and-comments) * [Troubleshooting - Mapping Issues](/operations-and-monitoring/troubleshooting) * [ZigiOps System Requirements](/integration-platform/system-requirements) # Azure DevOps ServiceNow Integration Guide Learn how to set up a bi-directional Azure DevOps ServiceNow integration in ZigiOps. Configure system instances, entity pairs, field mappings, and filters step by step. This guide explains how to configure a bi-directional integration between Azure DevOps and ServiceNow using ZigiOps. It covers adding system instances, selecting entity pairs, configuring correlation, building field mappings, applying filters, and testing the workflow. No scripting or coding is required at any stage. For a full overview of the sync capabilities between the two platforms, see the [Azure DevOps and ServiceNow integration page](https://www.zigiwave.com/integrations/servicenow-azure-devops-integration) on the ZigiWave website. *** ### Overview The Azure DevOps-ServiceNow integration synchronizes work items and ITSM records automatically. When a record is created or updated in one system, ZigiOps reflects the change in the other system based on the workflow configuration. This eliminates manual handoffs between development and operations teams, reduces resolution times, and keeps both teams aligned throughout the full incident and development lifecycle. {% embed url="" %} **Most common supported entity pairs:** | Azure DevOps Entity | ServiceNow Entity | Sync Direction | | ----------------------- | ------------------------------ | ---------------------- | | Work Item (Bug / Issue) | Incident | Bi-directional | | Work Item (Task) | Problem | Bi-directional | | Work Item (Task) | Change Request | Bi-directional | | Comment | Work Note / Additional Comment | Configurable | | Attachment | Attachment | Configurable | | State | State (numeric) | Mapped with conditions | | Priority (numeric 1-4) | Priority (numeric 1-4) | Mapped with conditions | > **Note:** ZigiOps supports all Azure DevOps work item types and all ServiceNow entities. Contact support for entities not listed above or for more complex use cases: . *** ### Prerequisites Before configuring this integration, confirm that the following requirements are met: * **ZigiOps instance:** installed and running. See the Installation guide. * **Azure DevOps:** a user account with a Personal Access Token (PAT) and the required work item permissions. See the [Azure DevOps system instance section](#add-an-azure-devops-system-instance) below. * **ServiceNow:** a dedicated integration user with read and write permissions on the Incident, Problem, or Change Request tables. See the [ServiceNow system instance section](#add-a-servicenow-system-instance) below. * **Custom fields:** correlation fields must exist in both systems before configuring the workflow. See the [Correlation section](#step-4-configure-correlation) below. * **License:** the ZigiOps license must include the Azure DevOps-ServiceNow system pair. *** ### Step 1: Add System Instances A system instance defines the connection between ZigiOps and a specific Azure DevOps or ServiceNow environment. You must add one instance for each system before configuring a workflow. #### Add a ServiceNow System Instance {% stepper %} {% step %} **Log into ZigiOps and open the ServiceNow connection form** * Log into your ZigiOps instance. * Navigate to **Connected Systems** > **Add New System** > **ServiceNow**. {% endstep %} {% step %} **Enter the connection parameters** Enter the following connection parameters: * **Server URL:** the base URL of your ServiceNow instance (for example, `https://yourinstance.service-now.com`). * **Username:** the ServiceNow integration user account. * **Password:** the password for the integration user. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. {% endstep %} {% step %} **Save and test the connection** * Click **Save** * Click **Test Connection** to verify that ZigiOps can reach the ServiceNow API. If the test succeeds, available tables and fields are downloaded automatically. {% endstep %} {% endstepper %}

ZigiOps UI - Adding ServiceNow as a Connected System.

> **Note:** The ServiceNow integration user must have read and write permissions on the `incident`, `problem`, and `change_request` tables, as well as permission to read and write `sys_journal_field` entries for work note synchronization. #### Add an Azure DevOps System Instance Azure DevOps authenticates via a Personal Access Token (PAT). Before adding the system instance in ZigiOps, generate a PAT in your Azure DevOps organization. **How to Create a Personal Access Token in Azure DevOps** {% stepper %} {% step %} **Sign in and open Personal Access Tokens** * Sign in to your Azure DevOps organization (for example, `https://dev.azure.com/{yourOrganization}`). * Open your user settings, select **Personal Access Tokens**, and click **+ New Token**. {% endstep %} {% step %} **Configure the token** * Name your token, select the organization where you want to use it, and set an expiration date. * Set the token scope to **Work Items (Read & Write)**. Limit the scope to the minimum permissions required for your integration. {% endstep %} {% step %} **Copy the token** * Copy the generated token immediately. It will not be shown again after you leave the page. {% endstep %} {% endstepper %} **Add the Azure DevOps system instance in ZigiOps:** {% stepper %} {% step %} **Open the Azure DevOps system form** * Log into your ZigiOps instance. * Navigate to **Connected Systems** > **Add New System** > **Azure DevOps**. {% endstep %} {% step %} **Enter the connection parameters** Enter the following connection parameters: * **Server URL:** the base URL of your Azure DevOps environment (for example, `https://dev.azure.com`). * **Instance Type:** select the type of your Azure DevOps instance (Cloud or Server). * **Organization / Collection:** the name of your Azure DevOps organization or collection. * **Username:** the Azure DevOps user account ZigiOps will use for API calls. * **Private Access Token:** the PAT generated in the steps above. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. {% endstep %} {% step %} **Save and test the connection** * Click **Save**. * Click **Test Connection** to verify connectivity. Available work item types and fields are downloaded automatically on success. {% endstep %} {% endstepper %}

ZigiOps UI - Adding Azure DevOps as a Connected System.

**Required permissions per action:** | Action | Azure DevOps Permission | ServiceNow Permission | | --------------------------------------------- | ----------------------- | ---------------------- | | Create ServiceNow record from Azure DevOps | Work Items: Read | Create on target table | | Update ServiceNow record from Azure DevOps | Work Items: Read | Write on target table | | Create Azure DevOps work item from ServiceNow | Work Items: Read, Write | Read on source table | | Update Azure DevOps work item from ServiceNow | Work Items: Read, Write | Read on source table | > **Note:** If the Test Connection fails for either system, verify that the integration user has the required API permissions and that the instance URL does not include a trailing slash. *** ### Step 2: Create or Load a Workflow A workflow defines the complete configuration for your integration, including the entity pair, triggers, field mappings, filters, and correlation logic. ZigiOps provides pre-built workflow templates for the most common Azure DevOps-ServiceNow use cases. A template includes pre-configured field mappings for title or description, priority, and state, as well as basic correlation and trigger settings. You can load a template and adjust it to match your environment, or create a custom workflow from scratch. #### Option A: Load a Workflow Template {% stepper %} {% step %} **Open the workflow template selection** * Navigate to **Configurator** > **Workflows** > **Add New Workflow**. * Select **Load from Template**. {% endstep %} {% step %} **Choose and load the template** Locate the relevant Azure DevOps-ServiceNow template. Commonly used templates include: * Azure DevOps Work Items to ServiceNow Incidents * ServiceNow Incidents to Azure DevOps Issues Click **Load** and adjust the configuration as needed.

ZigiOps UI - Workflow template selection screen.

{% endstep %} {% endstepper %} #### Option B: Create a Custom Workflow {% stepper %} {% step %} **Open the workflow creation screen** * Navigate to **Configurator** > **Workflows** > **Add New Workflow**. * Select **Custom Integration**. {% endstep %} {% step %} **Name and continue** * Assign a name to the workflow and proceed to configure each section as described in the steps below. {% endstep %} {% endstepper %} *** ### Step 3: Select the Entity Pair The entity pair defines which record types in each system will be synchronized. Select the combination that matches your use case. | Use Case | Azure DevOps Entity | ServiceNow Entity | | ------------------------------------------------------ | ----------------------- | ----------------- | | Escalating a dev issue to ITSM for incident tracking | Work Item (Bug / Issue) | Incident | | Syncing root cause analysis across teams | Work Item (Task) | Problem | | Coordinating production deployments with ITSM approval | Work Item (Task) | Change Request | For a fully bi-directional synchronization, configure at least two actions within the workflow: one to create and update ServiceNow records from Azure DevOps work items, and one to update Azure DevOps work items when ServiceNow records change.

ZigiOps UI - Entity pair selection screen.

*** ### Step 4: Configure Correlation Correlation is the mechanism ZigiOps uses to match existing records across systems during update cycles. It stores only unique identifiers, not business data. Without correlation, every sync cycle would create new records rather than updating existing ones. You define which field in each system stores the unique identifier of its counterpart. Common patterns are: * **ServiceNow field (for example, `correlation_id` or a custom field "Azure DevOps ID"):** stores the Azure DevOps work item ID of the linked record. * **Azure DevOps custom field (for example, "ServiceNow Reference"):** stores the ServiceNow incident number (for example, `INC0012345`) or `sys_id`. Create the required custom fields in each system **before** configuring correlation in ZigiOps. Once the fields exist, map them in the Correlation section of the workflow.

ZigiOps UI - Correlation configuration screen.

> **Note:** ZigiOps supports one-to-one correlation by default. Each Azure DevOps work item maps to exactly one ServiceNow record. This prevents duplicate creation even if an event is processed more than once. If the correlation key is missing or modified, ZigiOps can re-establish or update correlation safely, preventing data drift. *** ### Step 5: Configure Field Mappings Field mappings define which fields are synchronized between the two systems and how their values are transformed. Mappings are configured separately for each action direction. #### Minimum Required Field Mappings | Azure DevOps Field | ServiceNow Field | Notes | | -------------------- | ------------------------------------ | ----------------------------------------------------------------------------------- | | `Title` | `short_description` | Direct text mapping | | `Description` | `description` | Direct text mapping | | `Priority` (numeric) | `priority` (numeric) | Requires conditional mapping; both systems use numeric values but scales may differ | | `State` | `state` (numeric) | Requires conditional mapping with ServiceNow state machine values | | `Comment` | `work_notes` | Configure via Related Records. Apply author filter to prevent echo loops. | | `Assigned To` | `assigned_to` | Map based on team structure | | `ID` (Work Item ID) | `correlation_id` or custom field | Used for correlation. Not displayed to end users. | | `Work Item ID` | Custom field: Azure DevOps Reference | Human-readable cross-reference |

ZigiOps UI - Field Mapping table.

#### State Mapping Azure DevOps uses text-based state values (which vary by process template). ServiceNow uses a numeric State field governed by an ITIL-compliant state machine. These must be mapped conditionally in both directions. | Azure DevOps State | ServiceNow State (numeric) | ServiceNow Label | Notes | | ------------------ | -------------------------- | ---------------- | --------------------------------------------------------------- | | New | 1 | New | Direct mapping | | Active | 2 | In Progress | Direct mapping | | Resolved | 6 | Resolved | Send `close_code` and `close_notes` when mapping to Resolved | | Closed | 7 | Closed | Terminal state. Do not reopen via integration. | | Removed | 8 | Cancelled | Map if Cancelled state is available in your ServiceNow workflow | > **Note:** Closing a ServiceNow incident requires both `close_code` and `close_notes`. If these fields are not included in the mapping when the Azure DevOps work item state is set to Resolved or Closed, the ServiceNow API call will fail. Add a conditional mapping: when Azure DevOps State = Resolved, send `close_code` = `'Closed/Resolved by Caller'` and `close_notes` = `'Resolved by Azure DevOps integration'`.

ZigiOps UI - State conditional mapping.

#### Priority Mapping Azure DevOps uses a numeric priority field (1 to 4, where 1 is highest). ServiceNow also uses a numeric priority field (1 to 4, where 1 is Critical). The scales align, but ServiceNow derives priority from a combination of Impact and Urgency. Verify the priority matrix in your ServiceNow instance and map values conditionally. | Azure DevOps Priority | ServiceNow Priority (numeric) | ServiceNow Label | Notes | | --------------------- | ----------------------------- | ---------------- | -------------------------- | | 1 | 1 | Critical | Direct conditional mapping | | 2 | 2 | High | Direct conditional mapping | | 3 | 3 | Moderate | Direct conditional mapping | | 4 | 4 | Low | Direct conditional mapping | #### Comment and Work Note Synchronization ServiceNow distinguishes between Work Notes (internal) and Additional Comments (customer-visible). Azure DevOps uses a single Comment entity. Syncing all notes without filtering may expose internal ITSM information to development teams, or vice versa. Recommended comment mapping: * **ServiceNow Work Note to Azure DevOps Comment:** sync only work notes that are relevant to the development team. * **Azure DevOps Comment to ServiceNow Work Note:** map developer updates back as internal work notes. * **Author filter:** exclude comments authored by the integration user to prevent echo loops. * **Last Time expression:** use `{lasttimecomment}` to collect only entries created after the last successful run. Configure comment synchronization via the Related Records section of the field mapping configuration in ZigiOps. *** ### Step 6: Configure Triggers Triggers define when ZigiOps collects data from the source system. ZigiOps supports two trigger types, which can be used together for the most reliable coverage. | Trigger Type | Mechanism | Recommended Use | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Poller | ZigiOps queries the source system API on a configurable schedule (default: every 1 minute). | SLA monitoring, controlled sync cycles, systems without webhook support | | Web Listener | ZigiOps registers an HTTP endpoint and waits for the source system to push data via webhook. Activated when the action is enabled. | Real-time status updates, incident creation alerts, near-instant synchronization | Using both trigger types in combination is the recommended approach for production deployments. The Poller provides complete coverage; the Web Listener reduces latency for time-critical events. For critical Priority 1 incidents, configure a Web Listener trigger to minimize response time.

ZigiOps UI - Trigger configuration.

*** ### Step 7: Add Filters and Conditions Filters control which records are collected and when. Without proper filtering, the integration may process records that should be excluded or miss records that need to be synced. Common filter configurations for Azure DevOps-ServiceNow workflows: * **Last Time expression:** collect only records created or updated since the previous run. Use the `{lasttime}` expression in the filter condition. * **Last changelog expression:** use `{lasttimechangelog}` to collect change history entries created after the last run. * **Last comment expression:** use `{lasttimecomment}` to collect only comments created after the last successful run. * **Priority threshold:** sync Priority 1 and Priority 2 records in real time; batch-sync lower priorities. * **Author exclusion:** filter out comments authored by the integration user to prevent duplicate comment loops. * **Assignment group scope:** restrict ServiceNow collection to incidents assigned to specific groups that require development involvement. * **Work item type scope:** optionally restrict Azure DevOps collection to specific work item types (for example, only sync Bugs, not Tasks or Epics). ZigiOps supports AND and OR logic, with operators including: is, is not, is one of, is not one of, is empty, is not empty, contains, does not contain, less than, greater than, and equals. Conditions can be applied to any field available from the connected system.

ZigiOps UI - Filter and Condition Builder.

*** ### Step 8: Use Expressions for Data Transformation (Optional) Expressions apply transformations to field values after data is collected from the source and before it is delivered to the target. They are configured in the Source and Target tabs of the workflow action and do not require any scripting. | Expression | What It Does | Azure DevOps-ServiceNow Example | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Date and Time Format | Converts epoch timestamps to a human-readable string | Convert ServiceNow `sys_created_on` to a readable format for an Azure DevOps custom field | | First N Characters | Extracts the first N characters of a field value | Truncate long ServiceNow descriptions to fit Azure DevOps title character limits | | Pattern (RegEx) | Extracts a value matching a regular expression. Group 1 is returned if a capturing group is defined. | Extract an environment name or CI reference from a ServiceNow incident description | | Replace Text | Replaces a specific substring with another value | Replace internal assignment group codes with display names before syncing to Azure DevOps | | Replace Pattern (RegEx) | Replaces all matches of a RegEx pattern | Remove HTML tags from ServiceNow rich-text description fields | | Build Array | Combines multiple values into a comma-separated array | Aggregate multiple ServiceNow categories into an Azure DevOps tag array | | Last Time | Stores the timestamp of the last successful run; auto-increments on each execution | Collect only records updated after `{lasttime}` to prevent duplication | | To Lower Case / To Upper Case | Normalizes text casing | Align state or priority values that differ only in casing between systems |

ZigiOps UI - Expression configuration.

*** ### Step 9: Test and Activate the Workflow Before activating the workflow in production, test each action individually using the built-in troubleshooting tools. #### Testing Tools Available in ZigiOps * **Real-time operation logs:** show every record collected, processed, and delivered. * **Payload inspector:** displays the raw data sent to and received from each system, useful for debugging field mapping issues. * **HTTP request and response data:** provides API-level details for connectivity troubleshooting. * **Error classification:** distinguishes between mapping errors, connectivity issues, and API rejections. **Pre-activation checklist:** * Confirm Azure DevOps PAT permissions include all required scopes for work items, comments, and attachments. * Verify ServiceNow integration user roles include the necessary permissions for the target tables. * Ensure all required correlation fields exist in both systems and are accessible via API. * Validate state mappings across all possible transitions, including terminal states. * Test end-to-end synchronization including comments, attachments, state changes, and closures. **To activate the workflow:** {% stepper %} {% step %} **Run a test** * Run the workflow in **test mode** against a non-production record. {% endstep %} {% step %} **Verify the result** * Verify that the target record is created with the correct field values. * Check the **Activity Log** for any errors or unexpected field values. {% endstep %} {% step %} **Activate the workflow** * Once results are confirmed, set the workflow status to **Active**. {% endstep %} {% endstepper %}

ZigiOps Dashboard - Monitoring view.

*** ### Advanced: Governance and Reliability The following practices apply to production deployments and regulated environments. #### Idempotency via Correlation Lookup Before any write operation, ZigiOps checks whether a correlated record already exists in the target system. If one exists, it performs an update. If none exists, it creates a new record. This two-path logic prevents duplicate records when events are reprocessed after a failure or retry. If the correlation key is missing or modified, ZigiOps can re-establish correlation automatically based on configurable matching rules. #### Retry Logic Failed operations caused by transient API errors (rate limits, maintenance windows, network interruptions) are retried automatically. ZigiOps distinguishes between transient failures (retried) and permanent failures (logged and surfaced in the Activity Log). Retries do not create duplicate records due to the correlation lookup described above. #### Governance Recommendations | Practice | Why It Matters | How ZigiOps Supports It | | ----------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | Define integration ownership | Someone must be accountable for mapping logic and change testing | ZigiOps provides user-level access control and admin roles | | Test changes in staging first | Untested mapping changes can silently misbehave in production | ZigiOps supports multiple environments; test before activating | | Export and version integration templates | Integration configurations should be treated like production code | Export templates and store in a version control system | | Monitor operational health continuously | Silent failures are as damaging as loud ones | ZigiOps provides dashboards with real-time error tracking and operation metrics | | Audit Work Note and attachment sync rules | Internal ITSM notes may be exposed to development teams if filters are missing | Use conditional mapping and author filters to enforce data classification | *** ### Troubleshooting | Issue | Likely Cause | Resolution | | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Fields are missing from mapping suggestions | The system schema was not refreshed after new fields were added | Navigate to Connected Systems, select the system, and click Save to re-download the schema | | Duplicate comments appear in Azure DevOps or ServiceNow | Integration user exclusion filter is missing, or `{lasttimecomment}` expression is not configured | Add a trigger condition excluding the integration user as comment author; configure the `{lasttimecomment}` filter | | ServiceNow incident fails to resolve when Azure DevOps work item closes | `close_code` and `close_notes` are required by ServiceNow but are not included in the mapping | Add conditional mappings: send `close_code` and `close_notes` only when Azure DevOps State = Resolved or Closed | | Azure DevOps work item state does not update after a ServiceNow change | The state transition is not permitted by the Azure DevOps workflow from the current state | Configure intermediate state transitions in the ZigiOps workflow mapping, or adjust Azure DevOps workflow rules to allow the required transitions | | ServiceNow record fails to update when Azure DevOps changes | The correlation field in ServiceNow is empty or not correctly mapped | Verify that the Respond Mapping writes the Azure DevOps work item ID to the ServiceNow correlation field after record creation | | Workflow saves but fails to activate | A mandatory configuration field is missing, or the license does not include the Azure DevOps-ServiceNow pair | Review the error message in the UI; verify the license status under Admin > About | | PAT authentication fails on Azure DevOps connection | The Personal Access Token has expired, or the token scope does not include Work Items (Read & Write) | Generate a new PAT in Azure DevOps with the correct scopes and update the system instance in ZigiOps | | State values do not match between systems | Azure DevOps state names differ by process template (Agile, Scrum, CMMI) | Verify the exact state label names in your Azure DevOps project and update conditional mappings accordingly | *** ### Related Resources * [Integration Catalog - Azure DevOps ServiceNow Integrations](/integration-catalog/servicenow-azure-devops-integration) * [Building Integrations - Data Mapping Fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Building Integrations - Filters and Conditions](/design-and-mappings/filters-and-conditions) * [Building Integrations - Transformations and Expressions](/design-and-mappings/transformations-and-expressions) * [Building Integrations - Comments and Attachment Sync](/design-and-mappings/attachments-and-comments) * [Troubleshooting - Mapping Issues](/operations-and-monitoring/troubleshooting) * [ZigiOps System Requirements](/integration-platform/system-requirements) # Jira Azure DevOps Integration Guide Learn how to set up a bi-directional Jira Azure DevOps integration in ZigiOps. Configure system instances, entity pairs, field mappings, and filters step by step. This guide explains how to configure a bi-directional integration between Jira and Azure DevOps using ZigiOps. It covers adding system instances, selecting entity pairs, configuring correlation, building field mappings, applying filters, and testing the workflow. No scripting or coding is required at any stage. For a full overview of the sync capabilities between the two platforms, see the [Jira and Azure DevOps integration page](https://www.zigiwave.com/integrations/jira-azure-devops-integration) on the ZigiWave website. *** ### Overview The Jira-Azure DevOps integration synchronizes work items and tasks between Azure DevOps and Jira automatically. When a record is created or updated in one system, ZigiOps reflects the change in the other system based on the workflow configuration. {% embed url="" %} **Most common supported entity pairs:** | Azure DevOps Entity | Jira Entity | Sync Direction | | ------------------- | ------------------------ | ---------------------- | | Work Item (Task) | Task | Bi-directional | | Work Item (Bug) | Bug | Bi-directional | | Work Item (Story) | Story | Bi-directional | | Work Item (Epic) | Epic | Bi-directional | | Comment | Comment | Configurable | | Attachment | Attachment | Configurable | | State | Status (text transition) | Mapped with conditions | | Priority | Priority | Mapped with conditions | {% hint style="info" %} ZigiOps supports all Azure DevOps work item types. Contact support for entity types not listed above or for more complex use cases: . {% endhint %} *** ### Prerequisites Before configuring this integration, confirm that the following requirements are met: * **ZigiOps instance:** installed and running. See the Installation guide. * **Azure DevOps:** a user account with a Personal Access Token (PAT) and the required work item permissions. See the [Azure DevOps system instance section](#add-an-azure-devops-system-instance) below. * **Jira:** a dedicated integration user account with API token access and project-level permissions. * **Custom fields:** correlation fields must exist in both systems before configuring the workflow. See the [Correlation section](#step-4-configure-correlation) below. * **License:** the ZigiOps license must include the Jira-Azure DevOps system pair. *** ### Step 1: Add System Instances A system instance defines the connection between ZigiOps and a specific Azure DevOps or Jira environment. You must add one instance for each system before configuring a workflow. #### Add an Azure DevOps System Instance Azure DevOps authenticates via a Personal Access Token (PAT). Before adding the system instance in ZigiOps, generate a PAT in your Azure DevOps organization. **How to Create a Personal Access Token in Azure DevOps** {% stepper %} {% step %} **Sign in to Azure DevOps** Sign in to your Azure DevOps organization (for example, `https://dev.azure.com/{yourOrganization}`). {% endstep %} {% step %} **Open Personal Access Tokens** Open your user settings, select **Personal Access Tokens**, and click **+ New Token**. {% endstep %} {% step %} **Configure the token** Name your token, select the organization where you want to use it, and set an expiration date. {% endstep %} {% step %} **Set token scope** Set the token scope to **Work Items (Read & Write)**. Limit the scope to the minimum permissions required for your integration. {% endstep %} {% step %} **Copy the token** Copy the generated token immediately. It will not be shown again after you leave the page. {% endstep %} {% endstepper %} **Add the Azure DevOps system instance in ZigiOps:** {% stepper %} {% step %} **Log in to ZigiOps** Log into your ZigiOps instance. {% endstep %} {% step %} **Open the Azure DevOps system form** Navigate to **Connected Systems** > **Add New System** > **Azure DevOps**. {% endstep %} {% step %} **Enter connection parameters** Enter the following connection parameters: * **Server URL:** the base URL of your Azure DevOps environment (for example, `https://dev.azure.com`). * **Instance Type:** select the type of your Azure DevOps instance (Cloud or Server). * **Organization / Collection:** the name of your Azure DevOps organization or collection. * **Username:** the Azure DevOps user account ZigiOps will use for API calls. * **Private Access Token:** the PAT generated in the steps above. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. {% endstep %} {% step %} **Save the system instance** Click **Save**. {% endstep %} {% step %} **Test the connection** Click **Test Connection** to verify that ZigiOps can reach the Azure DevOps API. If the test succeeds, available work item types and fields are downloaded automatically. {% endstep %} {% endstepper %}

ZigiOps UI - Adding Azure DevOps as a Connected System.

**Required Azure DevOps permissions per action:** | Action | Required Permission | | ------------------------------------ | ----------------------- | | Create Jira Task (from Azure DevOps) | Work Items: Read | | Update Jira Task (from Azure DevOps) | Work Items: Read | | Update Azure DevOps Work Item | Work Items: Read, Write | #### Add a Jira System Instance {% stepper %} {% step %} **Log in to ZigiOps** Log into your ZigiOps instance. {% endstep %} {% step %} **Open the Jira system form** Navigate to **Connected Systems** > **Add New System** > **Jira**. {% endstep %} {% step %} **Enter connection parameters** Enter the following connection parameters: * **Server URL:** the base URL of your Jira environment (for example, `https://yourcompany.atlassian.net`). * **Username:** the Jira user account ZigiOps will use for API calls. * **API Token:** generated in your Atlassian account settings under Security > API tokens. * **Project Key:** scopes the integration to the correct Jira project. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. {% endstep %} {% step %} **Save the system instance** Click **Save**. {% endstep %} {% step %} **Test the connection** Click **Test Connection** to verify connectivity. Available fields and projects are downloaded automatically on success. {% endstep %} {% endstepper %}

ZigiOps UI - Adding Jira as a Connected System.

**Required Jira permissions per action:** | Action | Required Permissions | | ----------------------------- | ----------------------------------------------------------------------------------------------- | | Create Jira Task | Browse Projects, Create Issues, Assign Issues | | Update Jira Task | Edit Issues, Assign Issues, Resolve Issues, Transition Issues, Add Comments, Create Attachments | | Update Azure DevOps Work Item | Browse Projects | {% hint style="info" %} If the Test Connection fails for either system, verify that the integration user has the required API permissions and that the instance URL does not include a trailing slash. {% endhint %} *** ### Step 2: Create or Load a Workflow A workflow defines the complete configuration for your integration, including the entity pair, triggers, field mappings, filters, and correlation logic. ZigiOps provides pre-built workflow templates for the most common Jira-Azure DevOps use cases. A template includes pre-configured field mappings for title, description, and priority, as well as basic correlation and trigger settings. You can load a template and adjust it to match your environment, or create a custom workflow from scratch. #### Option A: Load a Workflow Template 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Load from Template**. 3. Locate the relevant Jira-Azure DevOps template. Commonly used templates include: * Azure DevOps Tasks to Jira Tasks * Jira Tasks to Azure DevOps Work Items 4. Click **Load** and adjust the configuration as needed.

ZigiOps UI - Workflow template selection screen.

#### Option B: Create a Custom Workflow 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Custom Integration**. 3. Assign a name to the workflow and proceed to configure each section as described in the steps below. *** ### Step 3: Select the Entity Pair The entity pair defines which record types in each system will be synchronized. Select the combination that matches your use case. | Use Case | Azure DevOps Entity | Jira Entity | | ------------------------------------- | ------------------- | ----------- | | Cross-team task synchronization | Work Item (Task) | Task | | Bug tracking across development teams | Work Item (Bug) | Bug | | Story-level planning alignment | Work Item (Story) | Story | | Portfolio and program management | Work Item (Epic) | Epic | For a fully bi-directional synchronization, configure at least two actions within the workflow: one to create and update Jira records from Azure DevOps work items, and one to update Azure DevOps work items when Jira records change.

ZigiOps UI - Entity pair selection screen.

*** ### Step 4: Configure Correlation Correlation is the mechanism ZigiOps uses to match existing records across systems during update cycles. It stores only unique identifiers, not business data. Without correlation, every sync cycle would create new records rather than updating existing ones. You define which field in each system stores the unique identifier of its counterpart. Common patterns are: * **Jira custom field (for example, "Azure DevOps ID"):** stores the Azure DevOps work item ID of the linked record. * **Azure DevOps custom field (for example, "Jira Reference"):** stores the Jira issue key (for example, `OPS-4512`). Create the required custom fields in each system **before** configuring correlation in ZigiOps. Once the fields exist, map them in the Correlation section of the workflow.

ZigiOps UI - Correlation configuration screen.

{% hint style="info" %} ZigiOps supports one-to-one correlation by default. Each Jira record maps to exactly one Azure DevOps work item. This prevents duplicate creation even if an event is processed more than once. {% endhint %} *** ### Step 5: Configure Field Mappings Field mappings define which fields are synchronized between the two systems and how their values are transformed. Mappings are configured separately for each action direction. #### Minimum Required Field Mappings | Azure DevOps Field | Jira Field | Notes | | ------------------- | ----------------------------- | ------------------------------------------------------------------------- | | `Title` | `summary` | Direct text mapping | | `Description` | `description` | Direct text mapping | | `Priority` | `priority` | Requires conditional mapping if label names differ | | `State` | `status` (text transition) | Requires conditional mapping with Jira transition IDs | | `Comment` | `comment.body` | Configure via Related Records. Apply author filter to prevent echo loops. | | `Assigned To` | `assignee` | Map based on team structure | | `ID` (Work Item ID) | Custom field: Azure DevOps ID | Used for correlation. Not displayed to end users. | | `Work Item ID` | Custom field: ADO Reference | Human-readable cross-reference |

ZigiOps UI - Field Mapping table.

#### State Mapping Azure DevOps uses a text-based State field, with values that vary by work item type and process template (Agile, Scrum, CMMI). Jira uses a Status field governed by workflow transitions. These must be mapped conditionally, not as a direct value copy. | Azure DevOps State (Agile / Scrum) | Jira Status | Notes | | ---------------------------------- | ---------------- | ---------------------------------------------- | | New | To Do | Direct mapping | | Active | In Progress | Direct mapping | | Resolved | In Review / Done | Map based on your Jira workflow | | Closed | Done | Terminal state. Do not reopen via integration. | | Removed | Cancelled | Map to a custom Jira status if available | {% hint style="info" %} Azure DevOps state names differ by process template (Agile, Scrum, or CMMI). Verify the exact state labels used in your Azure DevOps project before configuring these mappings. When mapping to Jira Done, use the Jira transition ID rather than setting the status field directly to ensure workflow validators and required fields are respected. {% endhint %}

ZigiOps UI - State conditional mapping.

#### Priority Mapping Azure DevOps uses a numeric priority field (1 to 4, where 1 is highest). Jira uses text-based priorities. Map values conditionally to ensure business impact is accurately represented. | Azure DevOps Priority | Jira Priority | Notes | | --------------------- | ------------- | -------------------------- | | 1 | Highest | Direct conditional mapping | | 2 | High | Direct conditional mapping | | 3 | Medium | Direct conditional mapping | | 4 | Low | Direct conditional mapping | {% hint style="info" %} Verify the exact priority label names used in your Jira instance before configuring these mappings. Label names vary between Jira Cloud and Jira Data Center, and may differ per project. {% endhint %} #### Comment and Attachment Synchronization Both Azure DevOps and Jira support comments and attachments. Syncing all comments without filtering may create echo loops if the integration user's own writes are collected on the next cycle. Recommended comment and attachment mapping: * **Azure DevOps Comment to Jira Comment:** sync comments relevant to the Jira team. * **Jira Comment to Azure DevOps Comment:** map updates back to keep the Azure DevOps team informed. * **Author filter:** exclude comments authored by the integration user to prevent echo loops. * **Last Time expression:** use `{lasttimecomment}` to collect only comments created after the last successful run. * **Attachments:** configure attachment sync via the Related Records section. Apply the same Last Time filter to avoid re-syncing existing attachments. Configure comment and attachment synchronization via the Related Records section of the field mapping configuration in ZigiOps. *** ### Step 6: Configure Triggers Triggers define when ZigiOps collects data from the source system. ZigiOps supports two trigger types, which can be used together for the most reliable coverage. | Trigger Type | Mechanism | Recommended Use | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Poller | ZigiOps queries the source system API on a configurable schedule (default: every 1 minute). | SLA monitoring, controlled sync cycles, systems without webhook support | | Web Listener | ZigiOps registers an HTTP endpoint and waits for the source system to push data via webhook. Activated when the action is enabled. | Real-time status updates, work item creation alerts, near-instant synchronization | Using both trigger types in combination is the recommended approach for production deployments. The Poller provides complete coverage; the Web Listener reduces latency for time-critical events.

ZigiOps UI - Trigger configuration.

*** ### Step 7: Add Filters and Conditions Filters control which records are collected and when. Without proper filtering, the integration may process records that should be excluded or miss records that need to be synced. Common filter configurations for Jira-Azure DevOps workflows: * **Last Time expression:** collect only records created or updated since the previous run. Use the `{lasttime}` expression in the filter condition. * **Last changelog expression:** use `{lasttimechangelog}` to collect change history entries created after the last run. * **Last comment expression:** use `{lasttimecomment}` to collect only comments created after the last successful run. * **Environment scope:** exclude work items from test or sandbox Azure DevOps projects. * **Priority threshold:** sync Priority 1 and Priority 2 work items in real time; batch-sync lower priorities. * **Author exclusion:** filter out comments authored by the integration user to prevent duplicate comment loops. * **Work item type scope:** optionally restrict collection to specific work item types (for example, only sync Bugs and Tasks, not Epics). ZigiOps supports AND and OR logic, with operators including: is, is not, is one of, is not one of, is empty, is not empty, contains, does not contain, less than, greater than, and equals. Conditions can be applied to any field available from the connected system.

ZigiOps UI - Filter and Condition Builder.

*** ### Step 8: Use Expressions for Data Transformation (Optional) Expressions apply transformations to field values after data is collected from the source and before it is delivered to the target. They are configured in the Source and Target tabs of the workflow action and do not require any scripting. | Expression | What It Does | Jira-Azure DevOps Example | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Date and Time Format | Converts epoch timestamps to a human-readable string | Convert Azure DevOps `System.CreatedDate` to a readable format for a Jira custom field | | First N Characters | Extracts the first N characters of a field value | Truncate long Azure DevOps titles to fit Jira's 255-character summary limit | | Pattern (RegEx) | Extracts a value matching a regular expression. Group 1 is returned if a capturing group is defined. | Extract a sprint name or area path component from an Azure DevOps field value | | Replace Text | Replaces a specific substring with another value | Replace internal team prefixes with display names before syncing to Jira | | Replace Pattern (RegEx) | Replaces all matches of a RegEx pattern | Remove HTML tags from Azure DevOps rich-text description fields | | Build Array | Combines multiple values into a comma-separated array | Aggregate multiple Azure DevOps tags into a Jira label array | | Last Time | Stores the timestamp of the last successful run; auto-increments on each execution | Collect only records updated after `{lasttime}` to prevent duplication | | To Lower Case / To Upper Case | Normalizes text casing | Align state or priority values that differ only in casing between systems |

ZigiOps UI - Expression configuration.

*** ### Step 9: Test and Activate the Workflow Before activating the workflow in production, test each action individually using the built-in troubleshooting tools. #### Testing Tools Available in ZigiOps * **Real-time operation logs:** show every record collected, processed, and delivered. * **Payload inspector:** displays the raw data sent to and received from each system, useful for debugging field mapping issues. * **HTTP request and response data:** provides API-level details for connectivity troubleshooting. * **Error classification:** distinguishes between mapping errors, connectivity issues, and API rejections. **To activate the workflow:** {% stepper %} {% step %} **Run a test** Run the workflow in **test mode** against a non-production record. {% endstep %} {% step %} **Verify the result** Verify that the target record is created with the correct field values. {% endstep %} {% step %} **Check the Activity Log** Check the **Activity Log** for any errors or unexpected field values. {% endstep %} {% step %} **Activate the workflow** Once results are confirmed, set the workflow status to **Active**. {% endstep %} {% endstepper %}

ZigiOps Dashboard - Monitoring view.

*** ### Advanced: Governance and Reliability The following practices apply to production deployments and regulated environments. #### Idempotency via Correlation Lookup Before any write operation, ZigiOps checks whether a correlated record already exists in the target system. If one exists, it performs an update. If none exists, it creates a new record. This two-path logic prevents duplicate records when events are reprocessed after a failure or retry. #### Retry Logic Failed operations caused by transient API errors (rate limits, maintenance windows, network interruptions) are retried automatically. ZigiOps distinguishes between transient failures (retried) and permanent failures (logged and surfaced in the Activity Log). Retries do not create duplicate records due to the correlation lookup described above. #### Governance Recommendations | Practice | Why It Matters | How ZigiOps Supports It | | ---------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Define integration ownership | Someone must be accountable for mapping logic and change testing | ZigiOps provides user-level access control and admin roles | | Test changes in staging first | Untested mapping changes can silently misbehave in production | ZigiOps supports multiple environments; test before activating | | Export and version integration templates | Integration configurations should be treated like production code | Export templates and store in a version control system | | Monitor operational health continuously | Silent failures are as damaging as loud ones | ZigiOps provides dashboards with real-time error tracking and operation metrics | | Audit comment and attachment sync rules | Internal notes may be exposed to unauthorized teams if filters are missing | Use conditional mapping and author filters to enforce data classification | *** ### Troubleshooting | Issue | Likely Cause | Resolution | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Fields are missing from mapping suggestions | The system schema was not refreshed after new fields were added | Navigate to Connected Systems, select the system, and click Save to re-download the schema | | Duplicate comments appear in Jira or Azure DevOps | Integration user exclusion filter is missing, or `{lasttimecomment}` expression is not configured | Add a trigger condition excluding the integration user as comment author; configure the `{lasttimecomment}` filter | | Azure DevOps work item fails to update when Jira changes | The correlation field in Azure DevOps is empty or not correctly mapped | Verify that the Respond Mapping writes the Jira issue key to the Azure DevOps correlation field after record creation | | Jira status does not update after an Azure DevOps state change | The mapping is setting the status field directly rather than using a Jira workflow transition ID | Replace the status field value with the correct Jira transition ID in the mapping configuration | | State values do not match between systems | Azure DevOps state names differ by process template (Agile, Scrum, CMMI) | Verify the exact state label names in your Azure DevOps project and update conditional mappings accordingly | | Workflow saves but fails to activate | A mandatory configuration field is missing, or the license does not include the Jira-Azure DevOps pair | Review the error message in the UI; verify the license status under Admin > About | | PAT authentication fails on Azure DevOps connection | The Personal Access Token has expired, or the token scope does not include Work Items (Read & Write) | Generate a new PAT in Azure DevOps with the correct scopes and update the system instance in ZigiOps | *** ### Related Resources * [Integration Catalog - Azure DevOps Jira Integrations](/integration-catalog/jira-azure-devops-integration) * [Building Integrations - Data Mapping Fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Building Integrations - Filters and Conditions](/design-and-mappings/filters-and-conditions) * [Building Integrations - Transformations and Expressions](/design-and-mappings/transformations-and-expressions) * [Building Integrations - Comments and Attachment Sync](/design-and-mappings/attachments-and-comments) * [Troubleshooting - Mapping Issues](/operations-and-monitoring/troubleshooting) * [ZigiOps System Requirements](/integration-platform/system-requirements) # Jira BMC Remedy Integration Guide Learn how to set up a bi-directional Jira BMC Remedy integration in ZigiOps. Configure system instances, entity pairs, field mappings, and filters step by step. This guide explains how to configure a bi-directional integration between Jira and BMC Remedy using ZigiOps. It covers adding system instances, selecting entity pairs, configuring correlation, building field mappings, applying filters, and testing the workflow. No scripting or coding is required at any stage. For a full overview of the sync capabilities between the two platforms, see the [Jira and Remedy integration page](https://www.zigiwave.com/integrations/jira-bmc-remedy-integration) on the ZigiWave website. ### Overview The Jira-BMC Remedy integration synchronizes records between your ITSM platform (BMC Remedy) and your project tracking tool (Jira) automatically. When a record is created or updated in one system, ZigiOps reflects the change in the other system based on the workflow configuration. {% embed url="" %} **Most common supported entity pairs:** | BMC Remedy Entity | Jira Entity | Sync Direction | | --------------------- | ------------------------ | ---------------------- | | Incident | Issue / Task | Bi-directional | | Problem | Bug | Bi-directional | | Change Request | Task | Bi-directional | | Work Order | Task | Bi-directional | | Work Log / Work Notes | Comment | Configurable | | Attachments | Attachments | Configurable | | Priority | Priority | Mapped with conditions | | Status (numeric) | Status (text transition) | Mapped with conditions | {% hint style="info" %} ZigiOps supports all Jira and BMC Remedy entities. Contact support for entities not listed above or for more complex use cases: . {% endhint %} ### Prerequisites Before configuring this integration, confirm that the following requirements are met: * **ZigiOps instance:** installed and running. See the Installation guide. * **Jira:** a dedicated integration user account with API token access and project-level permissions. * **BMC Remedy:** a dedicated integration user with read and write permissions on the Incident, Problem, Change Request, or Work Order forms. * **Custom fields:** correlation fields must exist in both systems before configuring the workflow. See the [Correlation section](#step-4-configure-correlation) below. * **License:** the ZigiOps license must include the Jira-BMC Remedy system pair. {% stepper %} {% step %} ### **Add System Instances** A system instance defines the connection between ZigiOps and a specific Jira or BMC Remedy environment. You must add one instance for each system before configuring a workflow. #### Add a Jira System Instance 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **Jira**. 3. Enter the following connection parameters: * **Server URL:** the base URL of your Jira environment (for example, `https://yourcompany.atlassian.net`). * **Username:** the Jira user account ZigiOps will use for API calls. * **API Token:** generated in your Atlassian account settings under Security > API tokens. * **Project Key:** scopes the integration to the correct Jira project. * **Proxy Settings:** configure if your environment requires routing traffic through a proxy. 4. Click **Save**. 5. Click **Test Connection** to verify that ZigiOps can reach the Jira API. If the test succeeds, available fields and projects are downloaded automatically.

ZigiOps UI - Adding Jira as a Connected System.

#### Add a BMC Remedy System Instance 1. Log into your ZigiOps instance. 2. Navigate to **Connected Systems** > **Add New System** > **BMC Remedy**. 3. Enter the following connection parameters: * **Server URL:** the base URL of your BMC Remedy instance (for example, `https://remedy.yourcompany.com`). * **Username:** the BMC Remedy integration user account. * **Password:** the password for the integration user. * **Proxy Settings:** configure if required. 4. Click **Save**. 5. Click **Test Connection** to verify connectivity. ZigiOps will download available forms and fields from BMC Remedy during this step.

ZigiOps UI - Adding BMC Remedy as a Connected System.

{% hint style="info" %} If the Test Connection fails, verify that the integration user has the required API permissions and that the instance URL does not include a trailing slash. {% endhint %} {% endstep %} {% step %} ### Create or Load a Workflow A workflow defines the complete configuration for your integration, including the entity pair, triggers, field mappings, filters, and correlation logic. ZigiOps provides pre-built workflow templates for the most common Jira-BMC Remedy use cases. A template includes pre-configured field mappings for summary, description, and priority, as well as basic correlation and trigger settings. You can load a template and adjust it to match your environment, or create a custom workflow from scratch. #### Option A: Load a Workflow Template 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Load from Template**. 3. Locate the relevant Jira-BMC Remedy template. Commonly used templates include: * Remedy Incident to Jira Task * Remedy Problem to Jira Bug * Remedy Change Request to Jira Task * Remedy Work Order to Jira Task * Jira Task to Remedy Incident 4. Click **Load** and adjust the configuration as needed.

ZigiOps UI - Workflow template selection screen.

#### Option B: Create a Custom Workflow 1. Navigate to **Configurator** > **Workflows** > **Add New Workflow**. 2. Select **Custom Integration**. 3. Assign a name to the workflow and proceed to configure each section as described in the steps below. {% endstep %} {% step %} ### Select the Entity Pair The entity pair defines which record types in each system will be synchronized. Select the combination that matches your use case. | Use Case | BMC Remedy Entity | Jira Entity | | ------------------------------------- | ----------------- | ------------ | | Incident-driven development | Incident | Issue / Task | | Root cause analysis alignment | Problem | Bug | | Change management and sprint planning | Change Request | Task | | Service fulfillment tracking | Work Order | Task | For a fully bi-directional synchronization, configure at least two actions within the workflow: one to create and update Jira records from BMC Remedy records, and one to update BMC Remedy records when Jira records change.

ZigiOps UI - Entity pair selection screen.

{% endstep %} {% step %} ### Configure Correlation Correlation is the mechanism ZigiOps uses to match existing records across systems during update cycles. It stores only unique identifiers, not business data. Without correlation, every sync cycle would create new records rather than updating existing ones. You define which field in each system stores the unique identifier of its counterpart. Common patterns are: * **Jira custom field (for example, "Remedy ID"):** stores the BMC Remedy Incident ID or Entry ID of the linked record. * **BMC Remedy field (for example, "Vendor Ticket Number" or a custom field "Jira Reference"):** stores the Jira issue key (for example, `OPS-4512`). Create the required custom fields in each system **before** configuring correlation in ZigiOps. Once the fields exist, map them in the Correlation section of the workflow.

ZigiOps UI - Correlation configuration screen.

{% hint style="info" %} ZigiOps supports one-to-one correlation by default. Each Jira record maps to exactly one BMC Remedy record. This prevents duplicate creation even if an event is processed more than once. {% endhint %} {% endstep %} {% step %} ### Configure Field Mappings Field mappings define which fields are synchronized between the two systems and how their values are transformed. Mappings are configured separately for each action direction. #### Minimum Required Field Mappings | BMC Remedy Field | Jira Field | Notes | | --------------------- | ------------------------------ | ------------------------------------------------------------------------- | | `Description` | `summary` | Direct text mapping | | `Detailed_Decription` | `description` | Direct text mapping | | `Priority` (text) | `priority` (text) | Requires conditional mapping if label names differ | | `Status` (text) | `status` (text transition) | Requires conditional mapping with Jira transition IDs | | `Work Log` | `comment.body` | Configure via Related Records. Apply author filter to prevent echo loops. | | `Assignee` | `assignee` | Map based on team structure | | `Entry_ID` | Custom field: Remedy ID | Used for correlation. Not displayed to end users. | | `Incident_Number` | Custom field: Remedy Reference | Human-readable cross-reference |

ZigiOps UI - Field Mapping table.

#### Status Mapping BMC Remedy and Jira use different status models. BMC Remedy statuses are text-based but follow an ITIL-aligned lifecycle. Jira statuses are governed by configurable workflow transitions. These must be mapped conditionally, not as a direct value copy. | BMC Remedy Status | Jira Status | Notes | | ----------------- | -------------------- | ----------------------------------------------------------------- | | New | To Do | Direct mapping | | Assigned | In Progress | Direct mapping | | In Progress | In Progress | Direct mapping | | Pending | On Hold / Blocked | Map to custom Jira status if available | | Resolved | Done | Verify required fields (Resolution, Resolution Category) are sent | | Closed | Done | Terminal state. Do not reopen via integration. | | Cancelled | Cancelled / Won't Do | Map to custom Jira status if available | {% hint style="info" %} When mapping BMC Remedy Resolved to Jira Done, use the Jira transition ID rather than setting the status field directly. This ensures that Jira workflow validators, post-functions, and required fields are respected. {% endhint %}

ZigiOps UI - Status conditional mapping.

#### Priority Mapping BMC Remedy uses a text-based priority field (Critical, High, Medium, Low). Jira also uses a text-based priority list, but label names may differ between instances. Map values conditionally to ensure business impact is accurately represented. | BMC Remedy Priority | Jira Priority | Notes | | ------------------- | ------------- | -------------------------- | | Critical | Highest | Direct conditional mapping | | High | High | Direct conditional mapping | | Medium | Medium | Direct conditional mapping | | Low | Low | Direct conditional mapping | {% hint style="info" %} Verify the exact priority label names used in your Jira instance before configuring these mappings. Label names vary between Jira Cloud and Jira Data Center, and may differ per project. {% endhint %} #### Comment and Work Log Synchronization BMC Remedy uses Work Logs to track internal notes and activity. Jira uses Comments. Syncing all BMC Remedy Work Log entries to Jira without filtering may expose internal operational notes to development teams. Recommended comment mapping: * **BMC Remedy Work Log to Jira Comment:** sync only entries that are intended for cross-team visibility. * **Jira Comment to BMC Remedy Work Log:** map developer updates back as Work Log entries to keep ITSM teams informed. * **Author filter:** exclude entries authored by the integration user to prevent echo loops. * **Last Time expression:** use `{lasttimecomment}` to collect only entries created after the last successful run. Configure comment synchronization via the Related Records section of the field mapping configuration in ZigiOps. {% endstep %} {% step %} ### Configure Triggers Triggers define when ZigiOps collects data from the source system. ZigiOps supports two trigger types, which can be used together for the most reliable coverage. | Trigger Type | Mechanism | Recommended Use | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Poller | ZigiOps queries the source system API on a configurable schedule (default: every 1 minute). | SLA monitoring, controlled sync cycles, systems without webhook support | | Web Listener | ZigiOps registers an HTTP endpoint and waits for the source system to push data via webhook. Activated when the action is enabled. | Real-time status updates, incident creation alerts, near-instant synchronization | Using both trigger types in combination is the recommended approach for production deployments. The Poller provides complete coverage; the Web Listener reduces latency for time-critical events.

ZigiOps UI - Trigger configuration.

{% endstep %} {% step %} ### Add Filters and Conditions Filters control which records are collected and when. Without proper filtering, the integration may process records that should be excluded or miss records that need to be synced. Common filter configurations for Jira-BMC Remedy workflows: * **Last Time expression:** collect only records created or updated since the previous run. Use the `{lasttime}` expression in the filter condition. * **Environment scope:** exclude records from test or sandbox environments. * **Priority threshold:** sync Critical and High priority records in real time; batch-sync lower priorities. * **Author exclusion:** filter out Work Log entries authored by the integration user to prevent duplicate comment loops. * **Status scope:** optionally restrict collection to records in specific statuses (for example, only sync records that are In Progress or Assigned). ZigiOps supports AND and OR logic, with operators including: is, is not, is one of, is not one of, is empty, is not empty, contains, does not contain, less than, greater than, and equals. Conditions can be applied to any field available from the connected system.

ZigiOps UI - Filter and Condition Builder.

{% endstep %} {% step %} ### Use Expressions for Data Transformation (Optional) Expressions apply transformations to field values after data is collected from the source and before it is delivered to the target. They are configured in the Source and Target tabs of the workflow action and do not require any scripting. | Expression | What It Does | Jira-BMC Remedy Example | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Date and Time Format | Converts epoch timestamps to a human-readable string | Convert BMC Remedy Last Modified Date to a readable format for a Jira custom field | | First N Characters | Extracts the first N characters of a field value | Truncate long BMC Remedy descriptions to fit Jira's 255-character summary limit | | Pattern (RegEx) | Extracts a value matching a regular expression. Group 1 is returned if a capturing group is defined. | Extract a CI name or environment tag from a BMC Remedy alert description | | Replace Text | Replaces a specific substring with another value | Replace internal team codes with display names before syncing to Jira | | Replace Pattern (RegEx) | Replaces all matches of a RegEx pattern | Mask sensitive reference numbers before syncing Work Log entries | | Build Array | Combines multiple values into a comma-separated array | Aggregate multiple BMC Remedy categories into a Jira label array | | Last Time | Stores the timestamp of the last successful run; auto-increments on each execution | Collect only records updated after `{lasttime}` to prevent duplication | | To Lower Case / To Upper Case | Normalizes text casing | Align status or category values that differ only in casing between systems |

ZigiOps UI - Expression configuration.

{% endstep %} {% endstepper %} ### Test and Activate the Workflow Before activating the workflow in production, test each action individually using the built-in troubleshooting tools. #### Testing Tools Available in ZigiOps * **Real-time operation logs:** show every record collected, processed, and delivered. * **Payload inspector:** displays the raw data sent to and received from each system, useful for debugging field mapping issues. * **HTTP request and response data:** provides API-level details for connectivity troubleshooting. * **Error classification:** distinguishes between mapping errors, connectivity issues, and API rejections. **To activate the workflow:** 1. Run the workflow in **test mode** against a non-production record. 2. Verify that the target record is created with the correct field values. 3. Check the **Activity Log** for any errors or unexpected field values. 4. Once results are confirmed, set the workflow status to **Active**.

ZigiOps Dashboard - Monitoring view.

### Advanced: Governance and Reliability The following practices apply to production deployments and regulated environments. #### Idempotency via Correlation Lookup Before any write operation, ZigiOps checks whether a correlated record already exists in the target system. If one exists, it performs an update. If none exists, it creates a new record. This two-path logic prevents duplicate records when events are reprocessed after a failure or retry. #### Retry Logic Failed operations caused by transient API errors (rate limits, maintenance windows, network interruptions) are retried automatically. ZigiOps distinguishes between transient failures (retried) and permanent failures (logged and surfaced in the Activity Log). Retries do not create duplicate records due to the correlation lookup described above. #### Governance Recommendations | Practice | Why It Matters | How ZigiOps Supports It | | ---------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Define integration ownership | Someone must be accountable for mapping logic and change testing | ZigiOps provides user-level access control and admin roles | | Test changes in staging first | Untested mapping changes can silently misbehave in production | ZigiOps supports multiple environments; test before activating | | Export and version integration templates | Integration configurations should be treated like production code | Export templates and store them in a version control system | | Monitor operational health continuously | Silent failures are as damaging as loud ones | ZigiOps provides dashboards with real-time error tracking and operation metrics | | Audit Work Log and attachment sync rules | Internal notes may be exposed to unauthorized teams if filters are missing | Use conditional mapping and author filters to enforce data classification | ### Troubleshooting | Issue | Likely Cause | Resolution | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Fields are missing from mapping suggestions | The system schema was not refreshed after new fields were added | Navigate to Connected Systems, select the system, and click Save to re-download the schema | | Duplicate Work Log entries appear in Jira | Integration user exclusion filter is missing, or `{lasttimecomment}` expression is not configured | Add a trigger condition excluding the integration user as Work Log author; configure the `{lasttimecomment}` filter | | BMC Remedy record fails to update when Jira changes | The correlation field in BMC Remedy is empty or not correctly mapped | Verify that the Respond Mapping writes the Jira issue key to the BMC Remedy correlation field after record creation | | Jira status does not update after a BMC Remedy change | The mapping is setting the status field directly rather than using a Jira workflow transition ID | Replace the status field value with the correct Jira transition ID in the mapping configuration | | Workflow saves but fails to activate | A mandatory configuration field is missing, or the license does not include the Jira-BMC Remedy pair | Review the error message in the UI; verify the license status under Admin > About | | Priority values do not match between systems | Label name differences between BMC Remedy and the specific Jira project | Use conditional mapping to translate BMC Remedy priority labels to the exact values used in your Jira project | ### Related Resources * [Integration Catalog - BMC Remedy Jira Integrations](/integration-catalog/remedy-and-helix-with-jira-integration) * [Building Integrations - Data Mapping Fundamentals](/design-and-mappings/data-mapping-fundamentals) * [Building Integrations - Filters and Conditions](/design-and-mappings/filters-and-conditions) * [Building Integrations - Transformations and Expressions](/design-and-mappings/transformations-and-expressions) * [Building Integrations - Comments and Attachment Sync](/design-and-mappings/attachments-and-comments) * [Troubleshooting - Mapping Issues](/operations-and-monitoring/troubleshooting) * [ZigiOps System Requirements](/integration-platform/system-requirements) --- [Next Page](/llms-full.txt/1)