How to Integrate ServiceNow with Freshservice: Running Two ITSM Platforms Across Subsidiaries and Partners

Last updated: November 2026

To integrate ServiceNow with Freshservice, connect both platforms through their REST APIs, using a custom integration, ServiceNow IntegrationHub or a third-party integration platform such as ZigiOps, the no-code integration platform by ZigiWave. Define which records cross over (usually incidents, sometimes changes and requests), map fields and states, store a correlation ID on both sides, and agree who owns the SLA for shared tickets. This pattern is often called eBonding, and it is the standard way to let two service desks work together without merging their tools.

Most organizations do not choose to run both ServiceNow and Freshservice. They end up there. A group running ServiceNow acquires a company that runs Freshservice. A regional IT team picked Freshservice years ago while headquarters standardised on ServiceNow. An outsourced service provider works in one tool while the customer works in the other. In each case, replacing one platform is expensive and slow, but working without an integration means emails, phone calls and duplicated tickets. This guide explains how to connect the two platforms in a way that both teams can live with.

Three common scenarios

Mergers and acquisitions

The parent company runs ServiceNow; the acquired company runs Freshservice. Users in the acquired company keep their familiar portal and service desk, but incidents affecting shared infrastructure (identity, network, ERP) must reach the parent's teams. The integration often runs for one to three years, until a consolidation decision is made.

Vendor and customer service desks

A managed service provider, software vendor or hosting partner uses one platform; its customer uses the other. Incidents are raised by the customer and resolved by the provider, or the reverse. This is classic eBonding, and contracts usually define the SLA, so accurate timestamps matter.

Regional or business-unit IT

A business unit with its own IT team uses Freshservice for day-to-day service management, while central IT owns enterprise services in ServiceNow. Tickets cross between them when a local issue needs a central fix.

The scenario matters because it decides who owns the ticket, whose SLA applies and which data may be shared.

What eBonding means in practice

ServiceNow eBonding is the term for an electronic link between two ticketing systems in different organizations or teams. Each side keeps its own record. The integration creates a partner record when a ticket is handed over, then keeps agreed fields, comments and states in sync until both sides close. The important principles are:

  • Each side owns its record. Neither system edits the other's fields freely; updates follow agreed rules.
  • Correlation is explicit. Each record stores the other's ID.
  • Hand-over is deliberate. A ticket crosses because of an assignment, category or explicit action, not because it exists.
  • Closure is coordinated. The side that received the work resolves; the side that owns the customer confirms and closes.

Integration options

ServiceNow Freshservice integration approaches
Approach Strengths Limitations
Custom REST integration Full control; can be built on ServiceNow scripted REST APIs and the Freshservice API Needs development and ongoing maintenance; error handling, retries and logging are your responsibility
ServiceNow IntegrationHub Stays inside ServiceNow; uses Flow Designer and REST steps Requires an IntegrationHub subscription; Freshservice-side logic and webhooks still need configuration
Freshservice workflow automator with webhooks Simple outbound calls from Freshservice when rules match Better for one-way notifications than full bidirectional sync
No-code integration platform (for example ZigiOps) Prebuilt connectors, bidirectional mapping, retries and logging without code Another component to license and govern; check data storage and hosting options

ZigiOps has ready-made ServiceNow and Freshservice connectors for this pattern, configured in a guided UI. Other platforms, such as ONEiO, also offer eBonding connectors. The design steps below apply to any option, with notes on how each step looks in ZigiOps.

How to integrate ServiceNow with Freshservice, step by step

Step 1: Agree the operating model first

Before any configuration, the two IT teams should answer these questions in writing:

  1. Which record types cross over: incidents only, or also service requests, changes and problems?
  2. What triggers a hand-over in each direction?
  3. Who owns communication with the end user?
  4. Whose SLA clock applies, and does it pause while the other side works?
  5. Who resolves, and who closes?
  6. Which fields may be shared, and which must stay private?

Integration problems are often process problems that were never discussed. A one-page agreement saves weeks of rework.

Step 2: Prepare integration accounts

In ServiceNow, create a dedicated integration user with roles that allow reading and writing the incident table (and other tables in scope), plus read access to the reference tables used for mapping, such as sys_user_group and cmdb_ci. Avoid giving the account admin. In Freshservice, use a dedicated agent account and its API key, with a role limited to the relevant workspaces and groups.

Step 3: Choose correlation fields

On the ServiceNow incident, the out-of-the-box correlation_id and correlation_display fields are designed for this purpose. In Freshservice, create a custom ticket field, for example "ServiceNow Number". Both records then point to each other, and the integration can find the partner record without searching by description.

How this works in ZigiOps: ZigiOps writes the Freshservice ticket ID into the ServiceNow correlation_id field and the incident number into the Freshservice custom field, then uses that pair to route every update. Changes made by the integration itself are ignored, so updates do not loop between the two desks.

Step 4: Map incident fields

Example ServiceNow incident to Freshservice ticket mapping
ServiceNow incident Freshservice ticket Notes
number Custom field "ServiceNow Number" Correlation reference
short_description Subject Sync on create; optionally on update
description Description Sync on create
impact and urgency (priority) Priority (and urgency, impact if used) Use a lookup table; both tools use different scales
category and subcategory Category and sub-category Map controlled values; default to a catch-all when unknown
assignment_group Group Map only groups that handle partner work
cmdb_ci Asset or custom field Often sent as text, because CMDBs differ
caller_id Requester Only if users exist on both sides; otherwise send name as text or omit
comments and work_notes Public replies and private notes Work notes to private notes; filter what is shared externally
state Status See state mapping below

How this works in ZigiOps: Each row above becomes one line in the ZigiOps field mapping. Priority and category lookups are handled with conditional mapping, and ServiceNow comments and work notes are read from the journal fields and filtered before they reach Freshservice.

Step 5: Map states and agree closure

ServiceNow incident states typically include New, In Progress, On Hold, Resolved, Closed and Canceled. Freshservice ticket statuses include Open, Pending, Resolved and Closed, plus any custom statuses you add. A workable mapping for an incident handed from ServiceNow to Freshservice is:

  • ServiceNow New or In Progress creates a Freshservice ticket in Open.
  • Freshservice Pending maps to ServiceNow On Hold, with an on-hold reason such as "Awaiting vendor" or a value your process uses.
  • Freshservice Resolved sets ServiceNow to Resolved, with resolution notes and a resolution code mapped from Freshservice.
  • ServiceNow Closed (after user confirmation) sets the Freshservice ticket to Closed.
  • ServiceNow reopened (back to In Progress) reopens the Freshservice ticket.

ServiceNow often requires fields such as resolution code and resolution notes before an incident can move to Resolved. If the integration does not supply them, the update will fail. Test these mandatory-field rules early. In ZigiOps, a conditional mapping can fill the resolution code and resolution notes from Freshservice values, so the update to Resolved is accepted.

Step 6: Handle changes and requests if in scope

Change management deserves care. A change raised in Freshservice that affects shared infrastructure may need approval from the ServiceNow change advisory board. A common pattern is to create a linked change in ServiceNow, sync planned start and end dates, risk and implementation plan, and send the approval outcome back. Freshservice change management has its own approval workflow, so decide which side's approval is authoritative to avoid double approvals.

Step 7: Test, monitor and document

Test the full lifecycle in sub-production instances: create, update, comment, attachment, hold, resolve, reopen and close, in both directions. Then test failures: API credentials expired, one side unavailable, a mapped group renamed. Set up alerts for failed sync attempts and assign someone to review them.

SLA ownership for shared tickets

When two service desks share a ticket, both have SLA clocks. Disputes are common unless the rules are clear.

  • Customer-facing SLA stays with the desk that owns the end user. It keeps running.
  • Internal or contractual SLA (operational level agreement or underpinning contract) applies to the receiving desk from the moment the hand-over is accepted.
  • Timestamps for creation, acceptance and resolution should sync, so both sides can report on the same events.
  • Pending states should be mapped carefully so the receiving desk's clock pauses only when waiting on the other side.

Data sharing rules between the two desks

In a merger, both desks belong to the same group, but in vendor and partner scenarios they belong to different legal entities. Even inside one group, data protection rules and works council agreements may limit what employee data can move between companies. Agree a short data-sharing rule set before go-live:

  • Requester details: share a name and contact route only when the receiving desk must contact the user directly. Otherwise, the owning desk stays the single point of contact.
  • Work notes: share only notes that are written for the other team. A simple convention, such as a prefix or a dedicated field, makes filtering reliable.
  • Attachments: screenshots and log files can contain personal data, credentials or customer information. Sync them only when needed, and check size limits on both platforms.
  • Configuration item data: CMDB details about the parent company's infrastructure may be confidential. Send the service or application name as text rather than full CI records.

ZigiOps does not store the transferred data and is ISO 27001 certified, which simplifies the data protection conversation in vendor and partner scenarios.

Reporting across both platforms

Leaders usually want one view of shared work. Because each platform keeps its own record, a few synced fields make cross-platform reporting much easier: the partner record number, the hand-over timestamp, the acceptance timestamp, the resolution timestamp and the resolving group. With these in place, each side can report on volumes, response times and resolution times for shared tickets, and the two reports will agree. This data also helps if the organization later decides whether to consolidate on one platform.

Common mistakes

  • Syncing everything. Only tickets that need the other team should cross.
  • Mapping users that do not exist. Requester and assignee fields fail when users are missing. Send names as text or use a default.
  • Ignoring mandatory fields. ServiceNow resolve and close rules reject incomplete updates.
  • Sharing internal notes externally. In vendor scenarios, work notes may contain information the partner should not see.
  • No exit plan. In M&A scenarios, plan how the integration will be retired when platforms consolidate.

Frequently asked questions

Can ServiceNow integrate with Freshservice?

Yes. Both platforms have REST APIs, so they can be connected with a custom integration, ServiceNow IntegrationHub, Freshservice webhooks or a no-code integration platform such as ZigiOps.

Can ZigiOps sync ServiceNow and Freshservice in both directions?

Yes. ZigiOps syncs incidents, changes, comments, work notes, attachments and states in both directions through the two platforms' APIs, with no scripts on either side.

What is ServiceNow eBonding?

eBonding is an electronic link between two ticketing systems, often in different organizations, that creates partner records and keeps agreed fields, comments and states in sync until both sides close.

Do I need IntegrationHub to connect ServiceNow and Freshservice?

No. IntegrationHub is one option. Custom scripted integrations and external integration platforms can connect the two without it.

How do ServiceNow states map to Freshservice statuses?

Typically New and In Progress map to Open, On Hold to Pending, Resolved to Resolved and Closed to Closed. Add custom Freshservice statuses if you need more detail, and supply ServiceNow's mandatory resolution fields.

Who owns the SLA when two service desks share a ticket?

The desk that owns the end user keeps the customer-facing SLA. The receiving desk is measured against an internal or contractual agreement from the moment it accepts the hand-over.

Should we replace Freshservice with ServiceNow instead of integrating?

Sometimes, but consolidation takes time and money. Integration lets both teams work effectively in the meantime and gives you data to make the consolidation decision.

Key takeaways

  • Running ServiceNow and Freshservice together is common after acquisitions, with vendors and in regional IT.
  • Use the eBonding pattern: each side owns its record, correlation is explicit, hand-over is deliberate and closure is coordinated.
  • Agree the operating model, including SLA ownership, before configuring anything.
  • Map priority, categories, groups and states with lookup tables, and handle ServiceNow mandatory fields.
  • Test the full lifecycle and failure cases, and plan how the integration will be retired if platforms consolidate.
  • ZigiOps supports the full eBonding pattern between ServiceNow and Freshservice without code, including correlation, conditional mapping and loop prevention.