# Freshdesk Jira Schnittstelle

*Freshdesk → Jira*

**Kurz gesagt:** Eine Freshdesk-Jira-Anbindung macht aus einem Support-Ticket einen nachverfolgbaren Entwicklungsvorgang und hält beide Seiten synchron. Eskaliert ein Agent ein Freshdesk-Ticket, legt die Pipeline im richtigen Projekt und Vorgangstyp ein Jira-Issue an, überträgt Beschreibung, Priorität und Anhänge und schreibt den Jira-Key zurück auf das Ticket. Danach überführt sie öffentliche Antworten in Jira-Kommentare, spiegelt Statusübergänge aus Jira zurück ins Ticket und unterdrückt das Echo, damit keine Seite in eine Schleife läuft. Richtig gemacht ist das kein Webhook-Skript, sondern eine idempotente, bidirektionale Pipeline, die Workflow-Änderungen und Rate-Limits übersteht.

## Was eine Freshdesk-Jira-Anbindung wirklich leistet

Der Support arbeitet in Freshdesk, die Entwicklung in Jira. In dem Moment, in dem sich ein Ticket als echter Bug oder als Feature-Wunsch entpuppt, müssen diese beiden Welten miteinander reden - und standardmäßig tun sie das per Copy-and-paste. Ein Agent legt von Hand ein Jira-Issue an, fügt das Ticket ein und springt dann eine Woche lang zwischen Tabs hin und her, um herauszufinden, ob die Entwicklung schon draufgeschaut hat, damit er dem Kunden etwas Zutreffendes sagen kann.

Eine Freshdesk-Jira-Anbindung ersetzt diese Handarbeit. Eskaliert ein Agent ein Ticket, legt die Pipeline das Jira-Issue im richtigen Projekt und Vorgangstyp an, überträgt Beschreibung, Priorität, den Kontext des Anfragenden und die Anhänge und schreibt den Jira-Key zurück auf das Ticket. Danach hält sie beide Seiten synchron: Öffentliche Antworten werden zu Jira-Kommentaren, und Statuswechsel aus Jira fließen zurück ins Ticket, sodass das Support-Team genau weiß, wo ein Kundenproblem steht, ohne je Jira zu öffnen.

## Welche Daten fließen

| Objekt / Vorgang in Freshdesk | Wird in Jira zu | Hinweis |
| --- | --- | --- |
| Eskaliertes Ticket | Neues Issue im zugeordneten Projekt + Typ | Typ (Bug / Story / Task) nach Gruppe, Tag oder Agentenauswahl |
| Betreff & Beschreibung | Summary & Beschreibung des Issues | Freshdesk-HTML nach Atlassian Document Format (ADF) konvertiert |
| Ticket-Priorität | Issue-Priorität | Die vier Freshdesk-Stufen auf Ihr Jira-Prioritätsschema gemappt |
| Öffentliche Agentenantwort | Issue-Kommentar | Interne Notizen werden bewusst nicht synchronisiert |
| Anfragender & Firma | Reporter-Kontext / Labels | Externer Kontakt als Text hinterlegt, nicht in einen Jira-Nutzer gezwungen |
| Anhänge | Issue-Anhänge | Innerhalb der Jira-Dateigrößengrenzen neu hochgeladen |
| Statuswechsel im Ticket | Je Richtung behandelt | Meist steuert Jira den Ticketstatus zurück, nicht umgekehrt |
| Statusübergang in Jira | Freshdesk-Ticketstatus + Notiz | Über gültige Workflow-Übergänge, nicht durch rohes Feldschreiben |

Projektzuordnung, Typregeln, Prioritäts- und Statusmapping stimmen wir einmalig ab und hinterlegen sie in der Pipeline. Danach ordnet sie niemand mehr pro Ticket von Hand zu.

## Die Details, an denen einfache Syncs scheitern

Eine Marketplace-App oder ein roher Webhook deckt den Normalfall ab und lässt die teuren Ränder offen:

- **Doppelte Issues.** Ohne gespeicherte Verknüpfung zwischen Ticket und Issue legt eine erneute Eskalation oder ein wiederholt zugestellter Webhook ein zweites Jira-Issue an. Der Jira-Key muss zurück aufs Ticket geschrieben und vor jedem Anlegen geprüft werden.
- **Die Echo-Schleife.** Wird eine Freshdesk-Antwort nach Jira synchronisiert, feuert Jira einen Webhook; wird der zurücksynchronisiert, feuert Freshdesk ebenfalls einen. Ohne Herkunftskennzeichnung und Echo-Unterdrückung schieben sich beide Systeme denselben Kommentar endlos hin und her.
- **Übergänge statt Felder.** Man kann den Status eines Jira-Issues nicht direkt auf "In Arbeit" setzen. Man muss den Übergang aufrufen, der ihn dorthin bewegt - und den gibt es nur aus bestimmten Zuständen. Das Statusmapping muss übergangsbewusst sein, sonst bleiben Issues hängen.
- **Prioritäts- und Statuswortschatz unterscheiden sich.** Niedrig/Mittel/Hoch/Dringend aus Freshdesk ist nicht das Jira-Schema, und die festen Freshdesk-Status sind nicht Ihr Projekt-Workflow. Beides braucht eine explizite Zuordnung, je Projekt.
- **HTML gegen ADF.** Freshdesk-Beschreibungen und -Antworten sind HTML; Jira Cloud speichert Rich Text als ADF. Ein naives Textkopieren verliert Formatierung, eingebettete Bilder und Codeblöcke. Die Konvertierung muss echt sein.
- **Interne Notizen bleiben intern.** Eine interne Freshdesk-Notiz ist nicht für den Kunden und oft auch nicht für Jira. Die Pipeline filtert nach Sichtbarkeit, damit nichts Internes hinüberleckt.
- **Rate-Limits auf beiden Seiten.** Freshdesk drosselt je nach Plan pro Minute; Jira Cloud arbeitet mit kostenbasierten Limits. Ein Schwung Eskalationen muss sich stauen und zurückstufen, nicht Vorgänge verlieren.

## Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Automatisierungsregel. Freshdesk-Vorgänge kommen per Webhook an (mit einem zeitgesteuerten Abgleichlauf als Sicherheitsnetz), werden validiert, auf Ihr abgestimmtes Jira-Projekt, den Typ, die Priorität und den Workflow gemappt und über die Jira-Cloud-REST-API angewendet - die Gegenrichtung für Status und Kommentare läuft genauso.

Die Pipeline ist idempotent: Jedes Ticket und jedes Issue trägt eine stabile Kennung und eine gespeicherte Querverknüpfung, sodass ein Retry, eine Wiederholung oder eine doppelte Eskalation nie ein Duplikat erzeugt oder einen Kommentar in die Schleife schickt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Ticketinhalte und Kundenkontaktdaten verlassen die EU nicht, was AVV und DSGVO sauber hält.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten von API-Änderungen bei Freshdesk und Atlassian liegen vertraglich bei uns. Atlassian nimmt Jira-Cloud-Endpunkte nach Zeitplan außer Betrieb; wir migrieren vorher, damit Ihr Eskalationsfluss nie stillschweigend stoppt. Sie bekommen einen festen Ansprechpartner und ein SLA, kein Skript, das jemand hüten muss.

## Wann sich diese Anbindung lohnt

Wenn ein paar Tickets im Monat zu Jira-Issues werden, ist Handarbeit völlig in Ordnung - und das sagen wir Ihnen auch. Die Anbindung lohnt sich, wenn das Eskalationsvolumen so hoch ist, dass Agenten Zeit mit der Statussuche verlieren, wenn Sie auf mehrere Jira-Projekte mit unterschiedlichen Workflows verteilen, wenn Support und Entwicklung sich ständig über veraltete Informationen streiten, oder wenn eine Marketplace-App schon an der Echo-Schleife oder einer Workflow-Änderung zerbrochen ist und Duplikate hinterlassen hat. Dann zahlt sich eine betreute Pipeline, die Zuordnung, Schleife und die Änderungen der Upstream-APIs übernimmt, mit jedem abgeschlossenen Eskalationsvorgang aus.

## Häufig gestellte Fragen

### Macht das die Jira-Cloud-App aus dem Marketplace nicht schon?

Für ein einzelnes Projekt mit Standardfeldern kann sie reichen. Sie kommt an ihre Grenzen, sobald Sie Tickets auf verschiedene Jira-Projekte verteilen, die Freshdesk-Priorität auf ein eigenes Prioritätsschema abbilden, den Ticketstatus in Workflow-Übergänge übersetzen oder interne Notizen aus Jira heraushalten wollen. Für die Echo-Schleife, in der ein synchronisierter Kommentar wieder einen Webhook auslöst, hat sie keine Antwort. Wir bauen die Zuordnung und die Schleifenunterdrückung als Pipeline-Logik, nicht als App-Einstellung.

### Ist die Synchronisation einseitig oder in beide Richtungen?

Beides kommt vor, wir schneiden es auf Ihren Ablauf zu. Das übliche Muster: Freshdesk-Ticket wird bei Eskalation zum Jira-Issue, öffentliche Agentenantworten werden zu Jira-Kommentaren, und Status samt Lösung fließen aus Jira zurück ins Ticket, damit der Support den Kunden informieren kann, ohne ein Board zu beobachten. Sie legen fest, in welche Richtung jedes Feld läuft, die Pipeline setzt das konsistent durch.

### Wie verhindern Sie doppelte Jira-Issues?

Der Jira-Key wird auf das Freshdesk-Ticket zurückgeschrieben (in ein eigenes Feld oder den Verknüpfungsspeicher), sobald das Issue angelegt ist. Jeder spätere Vorgang prüft zuerst diese Verknüpfung, sodass eine erneute Eskalation, ein Retry oder ein wiederholt zugestellter Webhook das bestehende Issue aktualisiert statt ein zweites anzulegen. Die Pipeline ist idempotent - derselbe Vorgang zweimal verarbeitet ergibt genau ein Ergebnis.

### Können Sie Freshdesk-Priorität und -Status auf unseren Jira-Workflow abbilden?

Ja, und genau hier scheitern einfache Connectoren. Freshdesk hat vier Prioritäten und einen kleinen festen Statussatz; Ihr Jira-Projekt hat ein eigenes Prioritätsschema und einen Workflow, dessen Übergänge nicht frei setzbar sind. Wir bilden die Priorität explizit ab und steuern den Status über gültige Übergänge statt ein Statusfeld zu schreiben - so versucht die Pipeline nie einen unzulässigen Schritt und lässt kein Issue hängen.

### Wer betreibt die Schnittstelle nach dem Go-live?

Wir. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, die wir überwachen. Ändert Freshdesk oder Atlassian eine Schnittstelle - und Atlassian nimmt Jira-Cloud-Endpunkte nach einem veröffentlichten Zeitplan außer Betrieb - ist das unser Problem, keine Überraschung, die Ihre Support-Leitung entdeckt, wenn keine Eskalationen mehr durchlaufen. Sie bekommen einen festen Ansprechpartner, Alerting und ein SLA statt einer Automatisierung, für die sich niemand zuständig fühlt.

## Verwandte Integrationen

- [Freshservice ↔ Jira](https://seamless.engineering/de/integrations/freshservice-jira/): Freshservice Jira Schnittstelle
- [Jira ↔ Slack](https://seamless.engineering/de/integrations/jira-slack/): Jira Slack Schnittstelle
- [Salesforce ↔ Jira](https://seamless.engineering/de/integrations/salesforce-jira/): Salesforce Jira Schnittstelle
- [ServiceNow ↔ Jira](https://seamless.engineering/de/integrations/servicenow-jira/): ServiceNow Jira Schnittstelle
- [Zendesk ↔ Jira](https://seamless.engineering/de/integrations/zendesk-jira/): Zendesk Jira Schnittstelle
- [Asana ↔ Jira](https://seamless.engineering/de/integrations/asana-jira/): Asana Jira Schnittstelle

## Nach System

- [Alle Schnittstellen für Jira](https://seamless.engineering/de/integrations/jira/)
- [Jira Cloud API-Changelog](https://seamless.engineering/de/api-changelog/jira/): 2 Breaking Changes und 11 Deprecations in den letzten 90 Tagen

## Scoping-Gespräch anfragen

Sie möchten diese Integration umsetzen und dauerhaft betreiben lassen? Sagen Sie uns, welche Systeme verbunden werden sollen und welche Daten fließen müssen. Festpreis-Angebot zur Aufwandsabschätzung innerhalb von 48 Stunden.

- E-Mail: hello@seamless.engineering
- Kontaktformular: https://seamless.engineering/de/#contact