Ticket Merger

Freshdesk and GitHub

A Freshdesk GitHub link is easy to install. The workflow around it decides whether customers get told when their bug ships, and most teams never design that part.

Start free trialAll Freshdesk guides

What you're actually trying to solve

A customer reports a bug. An agent confirms it is real. Engineering needs it in their tracker. And then, weeks later, somebody has to tell the customer it is fixed.

That last step is the one that fails. Nearly every team gets the first three right and then a fix ships silently, the ticket sits Pending forever, and the customer chases. The chase becomes a second ticket.

So evaluate any Freshdesk to GitHub integration against one question: when the issue closes, does anything happen to the ticket? If the answer is no, you have a link, not an integration, and you'll need a human habit to fill the gap.

The Freshdesk GitHub marketplace app route

The Freshworks Marketplace carries a GitHub app for Freshdesk. Broadly, apps of this kind let an agent create a GitHub issue from a ticket without leaving it, link a ticket to an existing issue, and see issue status in the ticket sidebar.

Installation follows the usual pattern: install from the marketplace inside your account, authorise against GitHub, choose which repositories are in scope. Feature coverage and the specific sync behaviour vary by app version, so read the listing and its documentation for what your install actually does rather than trusting a general description including this one.

The questions to ask before you commit.

Does it support private repositories and your organisation's access model, including SSO-enforced orgs.
Is status sync one way or two. Ticket to issue is the easy direction. Issue back to ticket is the one that matters.
What happens on close. Does the agent get notified, does the ticket change status, or does nothing happen at all.
How many tickets can point at one issue. Fifty customers reporting the same bug is normal, and an app that only handles one-to-one won't survive contact with reality.
Who can see what. GitHub issue titles and comments can be blunt. Anything mirrored into a ticket must land as a private note, never a public reply.

The webhook alternative

If the app does not cover your case, or you want the close-the-loop behaviour it lacks, build it with webhooks in both directions. It is genuinely a small piece of work.

Freshdesk to GitHub. An automation rule fires a webhook when a ticket is tagged, say, bug-confirmed. Your endpoint receives it and calls the GitHub API to create an issue, then writes the issue number back onto the ticket in a custom field. The webhooks guide covers how the Freshdesk side is configured.

GitHub to Freshdesk. A repository webhook on the issues event hits your endpoint when an issue closes. You look up every ticket carrying that issue number in the custom field and, for each, add a private note and move the status so an agent picks it up.

Deliberately, that second flow doesn't email the customer automatically. An issue closing means the code merged, not that it's deployed and not that this particular customer's symptom is resolved. Put a human in the loop and let them write one honest sentence.

Store the issue number in a structured custom field, not in the ticket body. A number in a field can be queried, which is what makes the fan-out from one issue to fifty tickets possible.

The workflow rules that make it work

The tooling is the easy half. These conventions are the half that decides whether it survives six months.

One issue, many tickets. Never create a new GitHub issue per report. Search for an existing one first, and link. Otherwise engineering gets forty duplicate issues and stops reading them.
Agents do not open issues freely. Route bug reports through a triage step, whether that is a lead or a weekly session. Uncontrolled issue creation from a support queue is the fastest way to have engineering mute the integration.
Write the issue for engineers. Steps to reproduce, environment, actual and expected. Pasting a customer email verbatim into a GitHub issue is rude to both sides.
Keep the ticket in a waiting state, ideally a status that pauses the SLA clock, so a nine-week engineering fix does not appear in your response metrics as nine weeks of your own inaction.
Count the tickets per issue and send that number to engineering. It's the most useful thing support can give a prioritisation meeting, and it only exists if the links are structured.

The alternative to all of this is a Jira-style two-way sync, and if your engineering team is there instead, the same reasoning applies to the Jira integration.

FAQ

Frequently asked questions

How do you link a ticket to a GitHub issue?

Through the marketplace app or a webhook. To link a Freshdesk ticket to GitHub you create or attach an issue from the ticket, and any Freshdesk developer integration needs a rule for who tells the customer when it ships.

Is there an official Freshdesk GitHub integration?

There is a GitHub app on the Freshworks Marketplace. Check the listing for the current feature set and whether status sync runs both ways, since that varies by version.

Can one GitHub issue be linked to several tickets?

That's the case you should design for, since many customers report the same bug. Store the issue number in a structured custom field so you can query every ticket attached to it.

Does closing a GitHub issue update the Freshdesk ticket?

Not automatically unless something makes it happen. Either the app supports it or you build it with a repository webhook on the issues event. Without it, fixes ship silently and customers chase.

Should the customer be emailed when the issue closes?

Not automatically. A closed issue means merged, not deployed and not necessarily fixed for that customer. Notify the agent, let a human confirm and write the reply.

Can I build this without the marketplace app?

Yes. A Freshdesk automation firing a webhook outbound, and a GitHub repository webhook inbound, covers both directions with a small service in between.

Forty reports, one bug, forty tickets

A widespread bug fills the queue with the same conversation over and over. Ticket Merger groups and merges those automatically on Freshdesk and Zendesk.

Start free trial

14-day free trial. No credit card required.

Keep reading

Freshdesk Webhooks: Reacting to Tickets in Real Time
How Freshdesk webhooks work, when to use them instead of polling the API, what to send, and how to build a consumer that doesn't lose events.
The Freshdesk Jira Integration: Setup and Rules
How the Freshdesk Jira integration works, escalating a ticket to an issue without losing the customer thread, and the process rules that keep it useful.
Freshdesk Integrations: Which Ones Are Worth It
How Freshdesk integrations work, the marketplace apps most support teams actually need, and what to check before you install anything into your queue.
Freshdesk Archived Tickets: Find, Restore, Report
What Freshdesk archived tickets are, when archiving kicks in, how to find and unarchive one, and what archiving quietly does to reporting and the API.
ServiceNow Zendesk Integration: Who Owns What
A ServiceNow Zendesk integration bridges a customer helpdesk and enterprise ITSM: which system owns which record, the four handoff shapes, and where mapping dies.
Companies That Use Zendesk: The Profiles It Fits
The kinds of companies Zendesk actually suits, sorted by size, sector and support model, plus the profiles that consistently regret buying it and the reason why.