Types of Alert Correlation

Zenduty offers the following correlation modes:

1. Time-based Correlation

Time-based correlation groups all incoming alerts into a single incident if they arrive within a specified timeframe. This is the simplest form of correlation — any alert that fires within the configured window after the initial alert will be attached to the same incident, regardless of its content.

To configure, select Time-based correlation and choose a duration from the dropdown (e.g., 2 minutes, 5 minutes, etc.). All alerts received within that window will be correlated into one incident.

2. Content-based Correlation

Content-based correlation provides more granular control by grouping alerts based on matching payload data. Instead of correlating all alerts purely by time, this mode compares specific fields in the alert payload and only groups alerts that share matching values. See the detailed configuration guide below.

3. AI Correlation (Coming Soon)

AI correlation will use machine learning to automatically identify and group related alerts based on patterns in your alert data. This feature is currently in development. Click Get Beta Access on the Noise Reduction tab to request early access and be notified when it becomes available.

4. Auto Pause Transient Alerts (Coming Soon)

Auto pause transient alerts will automatically suppress short-lived, self-resolving alerts that would otherwise create unnecessary incidents. This feature is currently in development. Click Get Beta Access on the Noise Reduction tab to request early access and be notified when it becomes available.

5. No Alert Correlation

Select this option if you do not want any alert grouping. Each incoming alert will create a separate incident.

Setting Up Content-Based Correlation

Content-based correlation suppresses "noisy" repetitive alerts by grouping them based on specific payload data. This ensures that related alerts are attached to a single incident rather than creating multiple separate notifications for on-call engineers.

To set up content-based alert correlation:

1. Navigate to the Service you wish to configure.
2. Click on the Noise Reduction tab in the top navigation bar.
3. Select the radio button for Content-based correlation.
4. Configure the matching logic, fields, and time window as described below.
5. Click Save Changes.

1. Matching Logic

Define how strictly the system evaluates your selected fields using the logic dropdown:

• Any — Correlates alerts if at least one of the specified fields matches an existing open incident.
• All — Correlates alerts only if every specified field matches exactly.

2. Field Selection

Choose which parts of the alert payload should be used for comparison. You can add multiple fields using the + Add field button:

• Incident Title — Matches based on the main headline text of the alert.
• Incident Summary — Matches based on the detailed body or description of the alert.
• Integration — Groups alerts coming from the same source (e.g., Anodot, Email V2, or CloudWatch).
• Custom Field — Enter a specific JSON key from your integration payload (e.g., host_id) to correlate based on unique technical identifiers.

3. Time Window

Correlation is governed by a Fixed Window. Select a duration from the dropdown — options range from 1 minute to 20 minutes. Incoming alerts will only correlate to an existing incident if they arrive within this specified timeframe after the initial alert has triggered.

Available time window options: 1 minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 20 minutes.

Saving Your Configuration

Once you have selected your matching logic, fields, and time window, click the Save Changes button at the bottom of the form to activate content-based correlation for the service. Changes take effect immediately for all new incoming alerts.

Content-Based Correlation: Example

Suppose you configure content-based correlation with the following settings:

• Logic: All
• Fields: Incident Title, Integration
• Time Window: 5 minutes

If your Cloudwatch integration fires three alerts with the title "High CPU on prod-server-01" within a 5-minute window, all three alerts will be grouped into a single incident. A fourth alert with the title "Disk Full on prod-server-02" from CloudWatch within the same window will create a new, separate incident because the title does not match.

What can Zenduty do for LogicMonitor users?

With LogicMonitor's Integration, Zenduty sends new LogicMonitor alerts to the right team and notifies them based on on-call schedules via email, text messages (SMS), phone calls (Voice), Slack, Microsoft Teams, and iOS & Android push notifications.

Zenduty escalates alerts until they are acknowledged or closed, providing your NOC, SRE, and application engineers with detailed context, playbooks, and a complete incident command framework to triage and resolve incidents with speed.

• Incident Lifecycle: Whenever LogicMonitor triggers an alert, Zenduty creates an incident. When the alert is cleared in LogicMonitor, Zenduty automatically resolves the incident.
• Custom Routing: Use Alert Rules to route specific LogicMonitor alerts to specific users or teams, write suppression rules, or auto-add notes.

1. In Zenduty

1. To add a new LogicMonitor integration, go to Teams on Zenduty and click on the team you want to add the integration to.
2. Next, go to Services and click on the relevant Service.
3. Go to Integrations and then Add New Integration. Give it a name and select the application LogicMonitor from the dropdown menu.
4. Go to Configure under your integrations and copy the Webhook URL generated.

2. In LogicMonitor: Configure the Webhook

1. Log in to LogicMonitor. Navigate to Settings > Integrations.

1. Click on Add Integration and select Custom HTTP Delivery.

1. Fill in the following details in the Manage Custom HTTP Delivery form:
   • Name: Zenduty
   • Description: Integration to Zenduty Incident Management.
   • Alert Statuses: Check Acknowledged, Cleared, and Escalated/De-escalated.
   • HTTP method: Select HTTP Post.
   • URL: Paste the Webhook URL copied from Zenduty.
2. Under Alert Data, select Raw and set the format to JSON.
3. Paste the following JSON payload into the box:

JSON

{
  "alert_id": "##INTERNALID##",
  "alert_message": "##MESSAGE##",
  "alert_level": "##LEVEL##",
  "alert_type": "##ALERTTYPE##",
  "alert_status": "##ALERTSTATUS##",
  "data": {
    "subject": "alertseverity:##LEVEL## servername:##HOST## alertname:##DATASOURCE##_##DATAPOINT##_##INSTANCE##",
    "note": "Message from LogicMonitor: \n ``` \n##MESSAGE##\n ``` ",
    "tags": [
      "LogicMonitor Alert",
      "##LEVEL##",
      "##system.azure.resourcename##"
    ],
    "custom_fields": {
      "ci": "##system.azure.resourcename##"
    }
  }
}

4. Click Save.

3. In LogicMonitor: Create Recipient Group

1. Navigate to Settings > Recipient Groups.
2. Click Add Group. Name it accordingly, for example Zenduty Recipient

1. Under Recipients, search for the "Zenduty" integration you just created in Step 2.
2. Ensure the Contact Method is set to your Zenduty HTTP integration and click Save.

4. In LogicMonitor: Set Up Escalation Chain

1. Navigate to Settings > Escalation Chains.
2. Click Add Chain (or edit an existing one).

1. Give it a name (e.g., Zenduty Chain).
2. In the Stages section, click the + icon to add a stage.

1. In the Add new recipients window, search for the Zenduty Recipients group you created in the previous step and click Save.
2. Ensure the chain settings (like Rate Limiting) are configured as needed.

Click Save to complete the chain.

5. Final Step: Link to Alert Rules

1. Go to Settings > Alert Rules.
2. Select the rules for the resources you want to monitor.
3. In the Escalation Chain dropdown, select the Zenduty Chain you created.
4. Save the rule.

LogicMonitor is now successfully integrated. Zenduty will automatically create and resolve incidents based on your LogicMonitor alerts.

Prerequisites

Before starting the migration, ensure the following:

• You have admin access to your PagerDuty account.
• You have admin access to your Zenduty account.
• A Read-Only API Access Token is generated in PagerDuty.

Zenduty only requires read-only access. No changes will be made to your PagerDuty configuration.

Step 1: Generate a Read-Only API Token in PagerDuty

1. Log in to your PagerDuty account.
2. Navigate to Integrations → API Access Keys.
3. Click Create New API Key.
4. Select Read-Only as the access level.

Step 2: Start the Migration in Zenduty

1. Log in to your Zenduty account.
2. Go to Profile → Account → Account Migration.
3. Paste the Read-Only API key from PagerDuty.
4. Click Start Migration.

Step 3: Select Users to Migrate

• Select the users you want to migrate.
• Click Continue.

Step 4: Select Teams to Migrate

• Choose the teams you want to migrate.
• Click Continue.

Step 5: Select Schedules to Migrate

• Choose the schedules you want to migrate.
• Click Continue.

Step 6: Select Escalation Policies to Migrate

• Select the escalation policies you want to migrate.
• Click Continue.

Step 7: Select Services to Migrate

• Select the services you want to migrate.
• Click Continue.

Step 8: Track Migration Progress

• Once the migration starts, Zenduty generates a Migration ID.
• Use this ID for support or troubleshooting.

What can Zenduty do for Checkmk users?

With the Checkmk integration, alerts generated by Checkmk are sent directly into IMR using a webhook URL. IMR then routes alerts to the right teams based on escalation policies and notifies them via email, SMS, voice calls, Slack, Microsoft Teams, push notifications, and more—continuing escalation until the alert is acknowledged or resolved.

You can also use Alert Rules to custom route specific Checkmk Core alerts to specific users, teams or escalation policies, write suppression rules, auto add notes, responders and incident tasks.

To integrate Checkmk with Zenduty, complete the following steps:

On the Zenduty Dashboard:

1. To add a new Checkmk integration, go to Teams on Zenduty and click on the team you want to add the integration to.
2. Next, go to Services and click on the relevant Service.
3. Go to Integrations and then Add New Integration. Give it a name and select the application Checkmk from the dropdown menu.
4. Go to Configure under your Integrations and copy the Webhook URL generated.

In Checkmk (Docker Deployment):

1. Access the Docker Container

	$ docker ps
	$ docker exec -it <CONTAINER_ID> /bin/bash

2. Navigate to the Notifications Directory

$ cd /opt/omd/sites/cmk/local/share/check_mk/notifications/

• If the folder does not exist:

  $ mkdir -p /opt/omd/sites/cmk/local/share/check_mk/notifications/
  $ cd /opt/omd/sites/cmk/local/share/check_mk/notifications/

3. Create the Notification Script

      $ git clone https://github.com/xurrent/imr-checkmk-integration

4. Set Script Permissions

      $ chmod +x notify_via_imr.sh
      $ chown cmk:cmk notify_via_imr.sh

5. Verify Installation

      $ ls -la notify_via_imr.sh

In Checkmk (Server Installation):

1. Navigate to the notifications directory.

      $ cd ~/local/share/check_mk/notifications/

1. Add or create the notification script.
2. Set permissions

      $ chmod +x notify_via_imr.sh
      $ ls -la notify_via_imr.sh

4. Restart Checkmk

      $ omd restart

In Checkmk:

1. Log into the Checkmk Web UI and navigate to Setup → Events → Notification

2. Create a Notification Rule. Click Add rule.

3. Configure Rule Settings

• Description: IMR Integration (or any name you prefer)

• Notification Method: Select the notification script (notify_via_imr.sh).
• Choose Contacts: Select contacts who should receive notifications.
• Select Parameter: Parameter name: IMR_WEBHOOK. Paste your IMR webhook URL in the parameter field.

3. Save the rule and Activate Changes.

Check Notification Logs

Docker:

      $ docker exec -it <CONTAINER_ID> /bin/bash
      $ tail -50 /opt/omd/sites/cmk/var/log/notify.log

Local server:

      $ su - <SITE_NAME>
      $ tail -50 var/log/notify.log

• Log in to Zenduty as an account owner. In another tab, Log into Okta as an administrator.

• In Zenduty, click on your name in the top right corner, which will reveal a dropdown with your account's domain name. Copy your account domain name for later use.

• Go to your Okta admin dashboard. Click on Applications. Click on Create App Integration and choose for SAML 2.0 and Click Next.

In General Settings Page. Provide application name and application logo for your new custom integration and click Next.

In Configure SAML Page Fill in the given details in

SAML Settings-> General:

• Single sign-on URL: https://www.zenduty.com/api/account/saml/acs/
• Audience URI (SP Entity ID): https://www.zenduty.com
• Default RelayState: {Paste your Zenduty account domain name that you copied earlier}
• Name ID format: EmailAddress
• Application username: Email
• Update application username on: Create and Update

SAML Settings -> Attribute Statements (optional)

• email: user.email
• first_name: user.firstName
• last_name: user.lastName

then click Next

In Feedback Page. Click Finish

After finishing SAML Integration. Click on "Sign On" tab in your Okta custom Zenduty Application. Then click on "View SAML setup instructions"

Copy the Single Sign-On URL, Identity Provider Issuer and X.509 Certificate and Save it in a safe place (It will be required in future during the setup at Zenduty's platform)

Go to Zenduty Dashboard > Account > Single Sign-On > Select "Okta SSO" as SSO provider and Paste your previously saved details from Okta's Platform.
(Ex: SSO Provider, SAML Entity ID, Certificate)

Your SSO setup is now done.

Then Click on General tab. edit App Settings. choose SCIM as Provisioning. then Click Save

Enable SCIM Settings in Zenduty

• Toggle the Enable SCIM Settings to activate user provisioning.

• Copy the Base URL and Token provided. Save them securely — you’ll need these for OKTA configuration.

Configure the SCIM Connector in Okta

In the Okta Admin Console, open your Zenduty application and go to
Provisioning → Integration, then click Edit:

• SCIM version: 2.0
• SCIM connector base URL: Paste the base URL provided by Zenduty
• Unique identifier field for users: userName
• Supported provisioning actions: check Push New Users, Push
  Profile Updates, Push Groups
• Authentication Mode: HTTP Header
• HTTP Header → Authorization: Bearer <your Zenduty SCIM token>
  Click Test Connector Configuration and ensure it succeeds, then click
  Save

Provisioning to App (Enable Operations)

Open Provisioning → To App and click Edit. Enable the following
operations:

• Create Users
• Update User Attributes
• Deactivate Users

Note: The default username for account creation should be set to
Email (configured under Sign On). Sync Password must remain
disabled for SCIM.

Attribute Mappings

Open Provisioning → To App → Attribute Mappings and use the following
mapping set:

To Okta (Import Settings)

Under Provisioning → To Okta, the connector shows Import Not
Available.
This is expected—Zenduty is treated as a downstream application and does
not import users into Okta.
Ensure Import Safeguard thresholds meet your org policy (20% by
default)

You have successfully set up SCIM-based user provisioning between OKTA and Zenduty.

How GNR works (at a glance)

1. You add rules (delays in minutes) per urgency and channel.
2. Users add contact methods (e.g., email, phone). Zenduty then sets notification rules for the user based on your global defaults.
3. If you didn’t set rules for a channel, Zenduty applies smart defaults so responders still get notified.

Creating and managing rules

1. Navigate to Account → Customizations → Global Notification Rules

Add a new rule

1. Go to the High or Low urgency section.
2. Click Add Rule.
3. Enter the delay in minutes (0 = immediate).
4. Select a channel.
5. Click Add to save.

Example

Let’s say you configure High urgency rules as follows:

• Email at 10 minutes
• Phone call at 0 minutes (immediate) and 5 minutes

Result: When you or anyone else in the organization adds an Email or Phone call contact method, Zenduty automatically sets these notification rules for them without requiring each user to configure them manually.

Smart defaults

If you skip a channel, Zenduty applies sensible defaults:

• Email/Slack/Teams/Push: 0 minutes
• SMS: 5 minutes
• Phone: 10 minutes

Best practices

• High urgency:
  • Immediate Email or Push at 0 minutes.
  • Escalate with SMS at 5 minutes.
  • Add Phone at ~10–15 minutes.
• Low urgency:
  • Keep it minimal, e.g., Email or Slack at 0 minutes.
• Keep it simple: 2–3 steps per urgency are usually enough.
• Review quarterly to keep rules aligned with on-call expectations.

FAQs

1. Do these rules change existing users?
   No. They apply only when new contact methods are added. Existing users can edit their own rules anytime.
2. Can users change their own rules?
   Yes. User notification rules can always be edited individually.
3. Why can’t I save a rule?
   Check that delay is within 0–10,080 minutes and that the combination of delay + channel is unique.
4. Can I add multiple steps?
   Yes. Add as many as needed to build an escalation ladder.

Troubleshooting

• A user didn’t get notified? Confirm they added the contact method and that a rule exists for it in your GNR.
• Too many notifications? Remove or increase later steps for Low urgency.

The Zenduty–Xurrent integration connects your Xurrent account with Zenduty at the account level, mapping Zenduty Services with Xurrent Service Instances. This ensures seamless synchronization between incidents and requests — so when a request is raised in Xurrent, Zenduty automatically creates the corresponding incident, and vice versa. With synchronized notes, impacts, and priorities, teams gain real-time visibility across both platforms, reduce duplication of effort, and resolve issues faster with full context in the tool they already use.

To Integrate Xurrent with Zenduty, complete the following steps.

Configure OAuth in Xurrent

Log in to Xurrent and navigate to Settings → OAuth Applications.

Create a new OAuth application

• Click Create New OAuth Application.
• Name the application Zenduty.
• Under Grant Type, select Client Credentials Grant.

Assign the required scopes
Enable the following scopes:

• Account — Read
• Note - Create, Read
• Organization — Read
• Person — Read
• Problem — Read
• Project — Read
• Request — Create, Read, Update
• Service — Create, Read, Update
• Service Instance — Read
• Team — Read
• Webhook — Create, Read, Update, Delete
• Webhook Policy — Create, Read, Update, Delete

1. Generate the application
   Click Generate OAuth Application.
2. Create a token
   Once the application is created, click Add Token to generate a new token.
3. Copy credentials
   • Copy the Client ID and Client Secret. Keep these safe.
   • Navigate to Settings → Account Overview and copy your Account ID.

Connect Xurrent with Zenduty

Log in to Zenduty
Go to: Account → Connections → Xurrent.

Configure the connection

• Click Configure.
• Paste the Account ID, Client ID, and Client Secret.
• Select the correct Region and Environment.
  • Most setups use Production, unless testing with a demo account.
• Click Add to save the connection.

Set Up the Integration

Add an outgoing integration
Navigate to:
Teams → Service → Integrations → Add Outgoing Integration.

• Select Xurrent.
• Click Create Integration.

Select configuration details

• Choose the Tenant you created earlier under Connections.
• Select the Service Instance you want to link with your Zenduty service.

Choose the integration direction
Decide how requests and incidents should flow between Xurrent and Zenduty:

• Xurrent → Zenduty: Requests in Xurrent create incidents in Zenduty.
• Zenduty → Xurrent: Incidents in Zenduty create requests in Xurrent.
• Bidirectional (Zenduty ↔ Xurrent): Requests and incidents mirror across both platforms.

Configure additional options

• Sync Notes: Choose whether notes should sync across both systems.
• Default Impact: Set the default impact Zenduty applies when creating requests in Xurrent.
• Custom Impact Mapping (optional):
  • Map Zenduty incident priorities to Xurrent request impacts.
  • Requires at least 4 priorities in Zenduty.

Click Save Configuration.

✅ Your Xurrent instance is now successfully connected with Zenduty. Incidents and requests will sync automatically based on your chosen settings, ensuring smooth collaboration, better visibility, and faster resolutions across teams.

Before You Begin

You’ll need access to both:

• GitHub (to download the integration code)
• ServiceNow (admin permissions required)

We’ll set up a few things in GitHub first, then in ServiceNow, and finally connect them inside Zenduty.

Prepare GitHub

1.1 Create a Personal Access Token

1. Sign in to GitHub.
2. Go to Profile (top right) → Settings → Developer settings → Personal access tokens → Tokens (classic).
3. Click Generate new token → Generate new token (classic).
4. Name it something clear (e.g., ServiceNow Integration).
5. Select the following permissions:
   • ✅ repo
   • ✅ admin:repo_hook (optional but recommended)
6. Click Generate token.
7. Copy the token somewhere safe — you won’t see it again.

1.2 Fork the Integration Repository

1. In GitHub, search for: Zenduty/zenduty-servicenow.
2. Open the repository.
3. Click Fork (top right).
4. You’ll now have your own copy at:
   https://github.com/<your_username>/zenduty-servicenow

Prepare ServiceNow

2.1 Switch to the Global Scope

1. Log in to your ServiceNow instance as an admin.
2. Open: https://<your_instance>.service-now.com/now/nav/ui/classic
3. Click the sphere icon in the top-right → Application Scope → Global.

2.2 Add GitHub Credentials to ServiceNow

1. Go to: https://<your_instance>.service-now.com/discovery_credentials_list.do
2. Click New → Basic Auth Credentials.
3. Fill in:
   • Name: GitHub Integration Credential
   • User Name: Your GitHub username
   • Password: The GitHub token you created in Step 1.1
4. Save.

2.3 Allow Access to Required Tables

For each of these tables:

• incident
• sys_user_group
• cmdb_ci
• sys_journal_field

Do this:

1. Open the table (via https://<your_instance>.service-now.com/sys_db_object_list.do).
2. Under Application Access:
   • ✅ Can read
   • ✅ Can create
   • ✅ Can update
   • ✅ Allow access via web services
   • ✅ Allow configuration
3. Under Controls:
   • ✅ Extensible
4. Click Update.

2.4 Enable OAuth Client Credentials

1. Go to: https://<your_instance>.service-now.com/sys_properties_list.do
2. Search for:
   glide.oauth.inbound.client.credential.grant_type.enabled
3. If it exists → set Value to true.
4. If it doesn’t exist → create it:
   • Name: glide.oauth.inbound.client.credential.grant_type.enabled
   • Type: true/false
   • Value: true
   • Ignore cache: checked
   • Save.

2.5 Add Custom Fields

Incident Table:

• Column label: Originated From Type: Choice, Default: servicenow

• Column label: Zenduty Incident, Type: URL

sys_user_group Table:

• Column label: Zenduty Escalation Policy, Type: URL

cmdb_ci Table:

• Column label: Zenduty Integration , Type: URL

Install the Integration in ServiceNow

3.1 Open ServiceNow Studio

Visit:
https://<your_instance>.service-now.com/$studio.do?sysparm_transaction_scope=global&sysparm_use_polaris=true

3.2 Import the App from GitHub

1. Click Import from Source Control.
2. Fill in:
   • Network Protocol: https
   • URL: https://github.com/<your_username>/zenduty-servicenow
   • Credential: GitHub Integration Credential (from 2.2)
   • Branch: main
3. Click Import.

3.3 Configure OAuth

1. In ServiceNow Studio, open the Zenduty application.
2. Go to Application Registries → Zenduty OAuth.
3. Add the field OAuth Application User to the form layout.

After clicking this you might see this

Click edit this section in Global
Add OAuth Application User to selected fields and save.
Now you will be able to see OAuth Application User in Zenduty OAuth file

1. Assign this user the following roles:
   • oauth_admin
   • web_service_admin
   • rest_service
   • itil
2. Copy the Client ID and Client Secret — you’ll need them shortly.
3. Copy the Scope by navigating to App details.

Copy only your ServiceNow instance name from the URL. It will be something like https://<ServiceNow_Instance>.service-now.com/

Connect ServiceNow to Zenduty

1. In Zenduty, go to Profile → Account → Connections → ServiceNow.
2. Click Configure.
3. Fill in:
   • Client ID
   • Client Secret
   • Scope
   • ServiceNow instance name
4. Click Add.

Your ServiceNow tenant is now connected to Zenduty.

Add Escalation Policy Mapping to a ServiceNow Assignment Group

1. In Zenduty, go to the ServiceNow Connections.
2. Click Add Mapping.
3. From the Assignment Group dropdown, select the ServiceNow group you want to map.
4. From the Escalation Policy dropdown, choose the Zenduty escalation policy you want linked to that group.
5. Click Add Mapping to save your changes.

Set Up Mappings & Outgoing Integration

1. In Zenduty, map Escalation Policies to ServiceNow Assignment Groups.
2. Go to: Teams → [Your Team] → Services → [Service] → Add Outgoing Integration.
3. Search for ServiceNow → Add Integration.

Configure:

Mapping Type: OR (either condition triggers) or AND (both required)

Assignment Group and/or Configuration Item

Direction (one-way or two-way)

Status mapping

Urgency mapping

Note & Priority syncing

Mandatory fields for acknowledge/resolve actions

Click Save.

✅ Done — Zenduty and ServiceNow now exchange incidents in real time.

1. On-call Switch

Automated system monitors on-call schedule rotations and sends real-time webhook notifications when transitions occur.

Go to Account → Connections → Webhook to create a webhook connection.

You will receive a response in the following format:

{
    "event_type": "oncall_change",
    "transitions": {
        "Team Name": {
            "Schedule Name": "Schedule details including on-call switch"
        }
    }
}

Example :

{
    "event_type": "oncall_change",
    "transitions": {
        "Engineering": {
            "Primary Schedule": [
                {
                    "schedule_id": "12345678-abcd-1234-efgh-987654321000",
                    "schedule_name": "Primary Schedule",
                    "team_id": "abcd1234-5678-90ef-ghij-1234567890ab",
                    "team_name": "Engineering",
                    "previous_user": {
                        "username": "user_001",
                        "first_name": "Alice",
                        "last_name": "Johnson"
                    },
                    "new_user": {
                        "username": "user_002",
                        "first_name": "Bob",
                        "last_name": "Smith"
                    },
                    "transition_time": "2025-08-11T10:00:00+00:00",
                    "layer_type": "layer",
                    "layer_name": "Layer 1",
                    "time_zone": "UTC",
                    "escalation_policies": [
                        {
                            "ep_id": "ep-12345678",
                            "ep_name": "Critical Escalation Policy"
                        }
                    ]
                }
            ]
        }
    }
}

The Service catalog feature provides a visual mapping system that allows you to define and visualize the relationships between services in your infrastructure. This interactive dependency graph helps teams understand service interconnections, troubleshoot issues more effectively, and maintain better oversight of their service architecture

Accessing Service catalog

1. Navigate to Teams > Service > Service Catalog
2. The Service catalog will be displayed as an interactive flow diagram

Key Features

Visual Dependency Graph

• Interactive Flow Chart: Services are displayed as nodes connected by directional arrows showing dependency relationships
• Zoom and Pan: Navigate large dependency maps using mouse controls or the built-in zoom controls
• Grid Background: Dotted grid background helps with visual alignment and navigation
• Responsive Layout: The map automatically adjusts to fit your viewport and repositions nodes for optimal viewing

Service Health Status

Each service node displays real-time health status indicators:

• Healthy: Service is operating normally
• Needs Attention: Service has unresolved incidents within past one year and requires monitoring
• Maintenance: Service is currently under maintenance

Managing Service Catalog

Adding Services to the service catalog

Adding Upstream Services

Upstream services are dependencies that the current service relies on.

1. Look for the "Add Upstream Service" button in the dependency map
2. Click "Add Upstream Service" button to open the service picker
3. Select the Team that owns the service you want to add
4. Choose the specific Service from that team
5. The service will be automatically positioned and connected as an upstream dependency

Adding Downstream Services

Downstream services depend on the current service.

1. Find the "Add Downstream Service" button in the dependency map
2. Click "Add Downstream Service" button to open the service picker
3. Select the appropriate Team and Service
4. The service will be added and connected as a downstream dependency

Service Node Actions

Each service node provides several interactive options accessible through the three-dot menu:

Available Actions

1. Service Catalog

   • Navigate directly to the service overview page
   • Available for all services except the current service being viewed

2. Unlink

   • Remove specific dependency connections
   • Opens a dialog showing upstream and downstream connections
   • Allows selective unlinking of individual relationships
   • Preserves the service node while removing only the selected connections

3. Delete Node

   • Completely removes the service from the dependency map
   • Removes all associated connections (both upstream and downstream)
   • Important: This only removes the service from the dependency graph; it does not delete the service from the team
   • Requires confirmation before deletion

Unlinking Services

The unlink feature provides granular control over service dependencies:

1. Access: Click the three-dot menu on any service node and select "Unlink"
2. Upstream Tab: View and unlink services that the current service depends on
3. Downstream Tab: View and unlink services that depend on the current service
4. Selective Removal: Choose specific connections to remove without affecting others
5. Confirmation: Each unlink action requires confirmation to prevent accidental changes

Navigation and Controls

Viewport Controls

• Pan: Click and drag on empty space to move around the map
• Zoom: Use mouse wheel or the zoom controls in the bottom-right corner
• Fit View: The map automatically fits all services in the viewport when loaded
• Grid Snap: Services automatically snap to a grid for clean alignment

Interactive Elements

• Service Nodes: Click to view basic information, hover to reveal action menu
• Connection Handles: Small dots on service nodes where connections can be made
• Connection Lines: Arrows showing dependency direction between services

Best Practices

Organizing Your Dependency Map

1. Start with Core Services: Begin by mapping your most critical services
2. Work Outward: Add dependencies layer by layer from core to peripheral services
3. Keep It Current: Regularly update the map when services change or new dependencies are added
4. Use Clear Naming: Ensure service names are descriptive and consistent

Troubleshooting with Dependencies

1. Follow the Flow: Use the dependency map to trace issues from affected services to their root causes
2. Check Upstream Health: When a service has issues, examine its upstream dependencies first
3. Monitor Downstream Impact: Understand which services might be affected when making changes

Maintenance Considerations

1. Regular Reviews: Periodically review and clean up outdated dependencies
2. Team Coordination: Ensure all team members understand how to maintain the dependency map
3. Documentation: Keep the dependency map aligned with your service documentation

Limitations and Notes

• Single Service Node: Each service can only be present once in the entire graph
• Real-Time Updates: Changes to the dependency map are saved immediately and visible to all team members
• Service Node Deletion: Removing a service node from the dependency map does not affect the actual service or its data, but removes connections and its connected service nodes from the graph

Troubleshooting

Getting Help

If you encounter issues with the Service Dependency feature:

1. Check your user permissions with your team administrator
2. Verify that all services are properly configured in their respective teams
3. Contact Zenduty's administrator for technical support

Note: Workflows are exclusively available on paid plans.

How Workflows Work

Workflows are triggered by specific events in the system and execute a series of predefined actions based on configured conditions. They support automation for tasks such as:

• Incident assignment
• Priority adjustments
• Task creation
• Responder notifications
• Email/webhook communications
• Conditional branching and delays

This flexibility allows teams to tailor responses to various scenarios, improving response times and reducing manual effort.

Workflow Structure

A workflow is constructed using four core building blocks:

• Trigger: The event that initiates the workflow
• Action: The specific tasks or operations performed
• Condition: Logic that determines the workflow's path
• Delay: A timed pause to allow for resolution or further evaluation

Building Blocks of Workflows

Triggers

A trigger is the event that starts the workflow, acting as the entry point for automation. Currently, Zenduty supports a single trigger, with plans to expand in future updates.

Available Triggers

Incident Created

• Description: Activates the workflow when a new incident is logged in the system
• Context Variables:
  • {{trigger_data.unique_id}}: Unique identifier (e.g., 550e8400-e29b-41d4-a716-446655440000)
  • {{trigger_data.summary}}: Incident summary (e.g., Database connection timeout)
  • {{trigger_data.incident_number}}: Sequential number (e.g., 1234)
  • {{trigger_data.creation_date}}: Creation timestamp (e.g., 2024-01-15T10:30:00Z)
  • {{trigger_data.status}}: Status (1 = triggered, 2 = acknowledged, 3 = resolved)
  • {{trigger_data.title}}: Incident title (e.g., Production Database Error)
  • {{trigger_data.service}}: Service UUID
  • {{trigger_data.urgency}}: Urgency level (0 = low, 1 = high)
  • {{trigger_data.assigned_to}}: Assigned user (e.g., john.doe or null)

Example: A workflow triggers when a new incident titled "Server Down" is created, using the "Incident Created" trigger to initiate automated steps.

Actions

Actions are the operational steps executed within the workflow, defining what happens after a trigger. Users can chain multiple actions to handle incidents comprehensively.

Available Actions

Change Incident Status

• Parameters: status (required: 1 = Triggered, 2 = Acknowledged, 3 = Resolved)
• Example: {"status": 3} sets the status to "Resolved"

Change Priority

• Parameters: priority (required, team-defined values)
• Example: {"priority": "P1"} sets priority to "P1"

Change Escalation Policy

• Parameters: escalation_policy (required, policy ID or name)
• Example: {"escalation_policy": "Default Escalation Policy"} routes to the senior team

Change Assignee

• Parameters: assignee_username (required)
• Example: {"assignee_username": "Michael"} assigns to "Michael"

Change Urgency

• Parameters: urgency (required: 0 = Low, 1 = High)
• Example: {"urgency": 1} sets urgency to "High"

Change Summary

• Parameters: summary (required, new text)
• Example: {"summary": "Updated: Server overload detected"} revises the summary

Add Note

• Parameters: note (required, text content)
• Example: {"note": "Checking server logs now."} adds a note

Add Task

• Parameters:
  • title (required)
  • description (optional)
  • due_in (optional, minutes)
  • assigned_role (optional, e.g., engineer)
• Example: {"title": "Review Logs", "due_in": 120, "assigned_role": "engineer"} creates a task

Add Responder

• Parameters: responder_username (required)
• Example: {"responder_username": "Michael"} adds a responder

Add Stakeholder

• Parameters: stakeholder_email (required)
• Example: {"stakeholder_email": "manager@company.com"} adds a stakeholder

Add Tag

• Parameters: tags (required, array of strings)
• Example: {"tags": ["database", "production"]} adds tags

Send Email

• Parameters:
  • to (required, email or array)
  • subject (required)
  • message (required, supports templating)
• Example: {"to": "support@company.com", "subject": "Incident: {{trigger_data.title}}", "message": "ID: {{trigger_data.unique_id}}"} sends an email

Send Webhook

• Parameters:
  • url (required)
  • method (required, e.g., POST)
  • headers (optional)
  • body (optional)
• Example: {"url": "https://api.external.com", "method": "POST", "body": "{\"Id\": \"{{Incident Created.unique_id}}\", \"incident_number\": \"{{Incident Created.incident_number}}\"}"} sends a webhook

Conditions

Conditions evaluate logic to branch the workflow, using "left value," "operator," and "right value," or "True"/"False" outcomes to decide the next steps.

Supported Operators

• eq: Equal
• neq: Not Equal
• lt: Less Than
• gt: Greater Than
• lte: Less Than or Equal
• gte: Greater Than or Equal
• contains: Contains
• does not contain: Does Not Contain

Parameters

• left_value: The variable to evaluate (e.g., {{trigger_data.urgency}})
• operator: The comparison operator (e.g., eq)
• right_value: The value to compare against (e.g., 1)

Example: A condition checks if urgency is High: {"left_value": "{{trigger_data.urgency}}", "operator": "eq", "right_value": 1}. If true, it assigns a responder; if false, it proceeds normally.

Delays

A delay pauses the workflow for a specified duration, allowing time for manual intervention or status updates.

Parameters

• delay: Number of time units (e.g., 15)
• unit: Time unit ("minutes" or "seconds")

Example: A delay of 15 minutes {"delay": 15, "unit": "minutes"} waits before checking if an incident is resolved.

Creating Workflows

1. Navigate to the Workflows tab in your Zenduty dashboard

2. Click Create Workflow and enter the workflow 'Name' and 'Description'

3. Assign the workflow to a team (e.g., Backend Team or API Team) and click Create

4. Select the Incident Created trigger

5. Add actions (e.g., "Change Status," "Send Email"), conditions, and delays as needed

6. Click Save to activate

Important: Ensure you have the required permissions to create and manage workflows.

Use Cases and Examples

Use Case 1: Auto-Resolve an Incident

Automates the resolution of minor incidents after a 60-minute window.

Create the Workflow

• Name: "Auto Resolve"
• Description: "Automatically resolves incidents after 60 minutes if unresolved"
• Team: Backend Team

Flow Steps

1. Trigger: "Incident Created" initiates the workflow

2. Delay: Wait 60 minutes to allow resolution attempts

3. Condition: Check if status is not "Resolved" ({{trigger_data.status}} not equal 3)

4. Action: If true, update status to "Resolved" ({"status": 3})

Here is the workflow shown below:

Use Case 2: Major Incident Workflow - P0 Incident Updates

Manages critical P0 incidents with timely updates.

Create the Workflow

• Name: "Major Incident Workflow"
• Description: "Sending updates for P0 incidents"
• Team: API Team

Flow Steps

1. Trigger: "Incident Created" starts the process

2. Condition: Check if team priority is P0 ({{Incident Created.team_priority}} eq "6ac5f10d-9680-4391-9c0e-6e492fb24960a")

3. Action (True): Add responder "Michael" and send email:

To: ‘support@acme.org’

Adding a Responder:

• Send email to support@acme.org with subject: "P0 Incident Detected: {{trigger_data.title}} (Incident #{{trigger_data.incident_number}})"

4. Delay: Wait 15 minutes

5. Condition: Check if status is "Resolved" ({{trigger_data.status}} eq 3)

6. Action (True): Send resolution email to support@acme.org

Here is the WorkFlow shown below : 

Use Case 3: Proactive Monitoring Alert

Automate notifications for incidents requiring immediate attention based on urgency.

Create the Workflow

• Name: "Urgent Alert Workflow"
• Description: "Sends alerts for high-urgency incidents"
• Team: Operations Team

Flow Steps

1. Trigger: "Incident Created" starts the workflow

2. Condition: Check if urgency is "High" ({{Incident Created.urgency}} eq '1')

3. Action (True): Send email to ops@acme.org with urgent alert
4. Delay: Wait 10 minutes

5. Condition: Check if status is not "Resolved" ({{Incident Created.status}} not eq 3)

6. Action (True):

• Add note about ongoing triage
• Add stakeholder manager@company.com

Best Practices for Workflows

To maximize the effectiveness of workflows, consider the following guidelines:

Keep Conditions Simple

Use straightforward logic to avoid complex branching that may confuse troubleshooting efforts.

Monitor Delays

Set reasonable delay times to balance automation with human intervention opportunities.

Document Changes

Add notes within the workflow to explain the purpose of each step for future reference.

Assign Clear Teams

Ensure workflows are assigned to teams with appropriate permissions and expertise.

Troubleshooting Workflows

If a workflow fails to execute as intended, follow these steps:

1. Review Condition Logic: Ensure the left_value, operator, and right_value are correctly configured
2. Inspect Action Parameters: Confirm all required parameters (e.g., status, to) are provided and valid
3. Examine Delay Timing: Ensure the delay duration aligns with the expected resolution timeline
4. Contact Support: If issues persist, reach out to Zenduty support with workflow details and error logs

Advanced Configuration Tips

Templating in Emails/Webhooks

Leverage mustache templating (e.g., {{trigger_data.unique_id}}) to include dynamic incident data in communications.

Chaining Actions

Combine multiple actions (e.g., "Add Note" followed by "Send Email") to create a comprehensive response.

Conditional Escalation

Use conditions to escalate only high-urgency incidents to senior teams.

Integration with Existing Tools

Workflows can enhance integration with existing Zenduty features:

Escalation Policies

Use "Change Escalation Policy" to dynamically route incidents based on conditions.

Responders

Leverage "Add Responder" to include on-call team members automatically.

Notifications

Combine "Send Email" and "Send Webhook" to notify both internal teams and external systems (e.g., Slack, PagerDuty).

Frequently Asked Questions

What happens if a delay exceeds resolution time?

The workflow continues after the delay, checking the latest incident status.

Are there limits on actions per workflow?

No strict limits, but keep workflows efficient by focusing on key actions.

Ready to implement automated incident response? Start building your first workflow today and streamline your team's operations with Zenduty's powerful automation capabilities.

✅ Allowed Configuration

• Use HTTPS (Port 443):All URLs must use HTTPS and the default port 443.
  • Example (valid): https://api.example.com/api/webhook/

❌ Not Allowed

1. Custom Ports in URLs:URLs specifying ports other than 443 are not supported and will be considered invalid.
   1. Example (invalid): https://example.com:8000/api/webhook/
2. IPv6-only Domains:Domains that resolve only to IPv6 addresses are not allowed. Domains must be either IPv4-resolvable or support dual-stack (both IPv4 and IPv6).
3. Private IP Address Resolution:If the provided domain resolves to a private IP (e.g., 10.x.x.x, 192.168.x.x, or 172.16.x.x–172.31.x.x), it will be considered invalid.

🔔 Notifications and Compliance

• Customers currently using ports other than 443 will receive notifications prompting them to update their webhook configurations accordingly.

Overview

Zenduty supports two login methods:

• SSO Login – Access via identity providers like Google, Okta, Azure AD
• Standard Login – Using your registered email and password

Most login issues are caused by:

• Browser-related issues (cookies, extensions, outdated cache)
• DNS/network problems (VPNs, firewalls)
• Incorrect login credentials
• Misconfigured SSO settings or recent changes to your SSO application configuration
• Recent network or firewall upgrades in your organisation

General Troubleshooting Checklist

Before diving into specific fixes, ensure the basics:

• Stable internet connection
• Access the official login page: https://www.zenduty.com/login/
• Use the latest Chrome, Firefox, Edge, or Safari
• Try Incognito/Private Mode
• Disable browser extensions (especially VPNs, ad blockers)
• For SSO users: make sure you have your organisation’s domain name

Issues with SSO (Single Sign-On)

When Do You Need Your Domain Name?

You’ll need your organisation's domain name only when logging in via SSO (e.g., Google, okta, Azure AD).

Common Scenarios:

• First-time SSO login
• Switching from email/password to SSO
• Troubleshooting SSO login issues
• Using the Forgot Domain option to retrieve the login URL

How to Find Your Domain Name

If You're Not Logged In:

• Ask your admin or IT team
• Check your Zenduty invite email
• Use: https://www.zenduty.com/forgot-domain/

If you're already Logged In:

• From Organisation Settings:
  1. Click your profile icon (top right)
  2. Go to Organisation Settings
  3. Check under SSO Settings or General Settings

Redirect Fails / Blank Screen

Possible causes:

• Local DNS resolution issues
• Misconfigured Identity Provider (IdP) metadata
• Stale SSO sessions in browser cache

Steps to resolve:

1. Open login page in Incognito/Private Mode
2. Try a different browser
3. Use a mobile hotspot to bypass DNS/firewall rules
4. Clear cache and cookies (see browser guide below)

Post-Login Access Issues

1. Team/Service Missing: Ask your admin to confirm you're added to the correct team and service.
2. Limited Access: Your role may not have permission. Verify your role with the admin.
3. Changes Not Reflecting: Log out and back in, or refresh the page.
4. Stuck/Blank Screen: Clear browser cache or try Incognito mode.

Issues with Standard Login (Email/Password)

Forgot Password

1. Click “Forgot Password” on the login screen.
2. Check your spam/junk folder for the reset email.
3. Ensure your account is activated.

Invalid Credentials

• Passwords are case-sensitive
• Re-enter credentials manually (avoid auto-fill)
• Type into a text editor first to catch invisible typos

Account Not Found

• Double-check your email for typos or wrong domain (e.g., .com vs .co)
• Confirm with your admin that the account is created and activated

Network-Related Issues

VPN / Corporate Network Blocking

VPNs or firewall settings may block authentication services.

Try the following steps in incognito mode,(Avoid opening multiple Incognito windows)

• Disable VPN and try again
• Switch to a mobile hotspot
• Use public DNS like 8.8.8.8 (Google)

Allow the following domains in your network settings:

• *.zenduty.com
• Whitelist : https://zenduty.com/docs/whitelisting/#ip-whitelisting

Browser Troubleshooting

Try Incognito/Private Mode

• Disables extensions and cached sessions
• Steps: Open browser > New Incognito/Private Window > Visit https://www.zenduty.com/login/

Clear Cache & Cookies for Zenduty via Chrome’s Site Info Menu

1. Open https://www.zenduty.com/ in Chrome.
2. Click the lock icon (🔒) or info icon (ⓘ) on the left side of the address bar.
3. Select “Site settings” from the dropdown.
4. Click “Clear data” or “Clear storage” to remove cached files and cookies for Zenduty only.
5. Confirm by clicking Clear.
6. Close the tab and reload the Zenduty login page.

Note: Similar site-specific cache and cookie clearing options are available in other browsers like Firefox, Edge, and Safari via their respective site info menus or settings

Try a Different Browser

Switch to Firefox, Edge, or Safari to rule out browser-specific issues.

Try Another Device or App

• Try logging in from your mobile browser or tablet (e.g., iPad).
• Alternatively, download the Zenduty mobile app for Android or iOS

Still Can’t Log In?

If none of the above steps resolve the issue, please contact Zenduty Support through chat or email:

Email: support@zenduty.com
Include:

• A screenshot of the issue
• Your email ID
• Whether you’re using SSO or password login
• Any error messages you’re seeing

Best Practices

• Always use your organisation’s designated login method
• Bookmark the official login page: https://www.zenduty.com/login
• Keep your browser and OS updated
• Avoid VPNs or network restrictions when possible

What can this Zenduty integration do for Status cast users?

With StatusCast’s two-way integration with Zenduty, incident communication and response are tightly synchronized across both platforms. When an incident is triggered in StatusCast, Zenduty immediately generates an alert and notifies the appropriate team based on on-call schedules via email, SMS, voice calls, Slack, Microsoft Teams, and mobile push notifications. Zenduty continues escalating the alert until it’s acknowledged or resolved, while also providing NOC, SRE, and engineering teams with rich incident context, linked playbooks, and a full incident command framework to accelerate response.

Likewise, when a new incident is created in Zenduty—whether triggered by monitoring tools or manually—it automatically creates or updates the corresponding incident in StatusCast, keeping end-users informed without requiring manual input. Once the incident is resolved in either platform, the status is updated in both systems, ensuring alignment between internal response workflows and external communication.

You can further customize workflows using Alert Rules to route incidents, suppress noise, auto-add responders or notes, and assign tasks across both systems for a seamless incident lifecycle.

To integrate StatusCast with Zenduty, complete the following steps:

In Zenduty(Account Settings):

1. Navigate to Account Settings → Connections.
2. Select StatusCast, then click Add Domain.
3. Enter the domain name of your StatusCast account.
4. If signature verification is required, enable Check Signature.
   • Follow the StatusCast setup steps to get the public and private keys.
   • Paste the corresponding keys into the required fields.
5. Click Save to complete the setup.
6. After saving, you will see the Webhook URL.Please copy and save this URL for future use during the StatusCast configuration.

In StatusCast:

1. Navigate to Settings -> Integrations.
2. Install or Configure Webhook.
3. If you plan to enable Use Signature Header, make sure to do this step before the Zenduty setup.
   • Enable Use Signature Header and copy the Public Key and Private Key (these will be needed in Step 4 of the Zenduty setup).
4. Paste the Webhook URL from Zenduty, and click Save.

5. Navigate to Settings -> Settings, then select Beacons.
6. Click New Integration.
7. Enter the Beacon Name.
8. Select Uptime Monitoring Service as the Beacon Type and click Next.
9. Choose Zenduty as the provider and click Next.
10. Select the user you want to assign the beacon to and click Next.
11. Preview the integration details and click Submit.
12. Copy the displayed Webhook URL and save it.

In Zenduty

1. In Zenduty, navigate to the Teams section where you want to create the integration.
2. Under the selected team, go to Services.
3. Create a new service using the exact same name of the Service in StatusCast (note: the name is case-sensitive, so enter it carefully).
4. Inside the service, click on Add Outgoing Integration.
5. From the list, select StatusCast.
6. Click Add Integration.
7. Paste the Webhook URL you copied from StatusCast.
   Note: Please refer to the Outbound Communication Guidelines document for the correct URL structure.
8. Click Save to complete the integration.

Note:

External Id is must while creating incident from statuscast.

What can this Zenduty integration do for Zoho Desk users?

With Zoho Desk's Integration, Zenduty sends new Zoho Desk ticket alerts to the right team and notifies them based on on-call schedules via email, text messages(SMS), phone calls(Voice), Slack, Microsoft Teams and iOS & Android push notifications, and escalates alerts until the alert is acknowledged or closed. Zenduty provides your NOC, SRE and application engineers with detailed context around the Zoho Desk Ticket issue alert along with playbooks and a complete incident command framework to triage, remediate and resolve incidents with speed.

Whenever a Zoho Desk ticket is generated, an alert is sent to Zenduty, creating an incident. When that ticket is closed, Zenduty will auto-resolve the incident.

You can also use Alert Rules to custom route specific Zoho Desk ticket alerts to specific users, teams or escalation policies, write suppression rules, auto add notes, responders and incident tasks

To integrate Zoho Desk with Zenduty, complete the following steps:

In Zenduty(Account Settings):

1. Navigate to Account Settings → Connections.
2. Select Zoho Desk, then click Add Url.
3. Enter the Base URL of your Zoho Desk account, specific to your country.
   Note: Please refer to the Outbound Communication Guidelines document for the correct URL structure.
4. Click Save.
5. After saving, you will see the WEBHOOK URL.Copy and save this URL to use it in Zoho Desk.

Note

• Base url example https://desk.zoho.in/ for India

In Zoho Desk

1. Login to Zoho Desk.
2. Navigate to Setup by clicking the gear icon located at the top right of the screen. In the Setup menu, under Developer Space, select Webhooks.
3. Click on New Webhook. You will be prompted to enter the Webhook URL and other details. Paste the copied webhook URL from Zenduty. Then, choose the events for which the webhook should be triggered.
4. Currently, only the following three events are supported: Ticket Add, Ticket Update, and Ticket Delete.
5. After selecting the events, you can optionally choose a specific Department if you want the webhook to apply only to that department. By default, the webhook will be triggered for all departments if no specific department is selected.
6. Click Save to complete the configuration.

Setting Up Integration

In Zoho Desk

1. Navigate to Setup by clicking the gear icon at the top right of the screen.
2. Under the Organization section, select Departments.
3. Click on the department you want to set up for the integration.
4. In the URL of the page, you'll see a number after departments/ — this is the Department ID.
5. Copy this number and save it for use in the integration configuration.

In Zenduty

1. In Zenduty, navigate to Teams and select the team for which you want to create the integration.
2. Under the selected team, go to Services.
3. Choose the service you want to integrate with, then click on Add Incoming Integration.
4. From the list of available integrations, select Zoho Desk.
5. Choose the case in which you want Zenduty to create an incident and set the default urgency.
6. After setting the urgency, click Add Integration.
7. You will be redirected to the Configure Integration page.
8. On this page, you will see your Webhook URL and a field to enter the Department ID.
9. Paste the Department ID you copied earlier from Zoho Desk into the appropriate field.
10. Click Save to complete the integration setup.