Jira und Salesforce integrieren: ein kurzer Leitfaden für plattformübergreifende Teams
Fragen Sie einen Jira-Admin, was er an seinem Support-Prozess ändern würde, und die Antwort hat selten mit Jira zu tun. Sie hat mit der Person aus dem Vertrieb zu tun, die immer wieder an irgendeinem Schreibtisch auftaucht und fragt, ob der Bug schon behoben ist.
Warum?
Nun ja – Ihre Entwickler arbeiten in Jira, Ihr Vertriebs- und Kundenteam arbeitet in Salesforce. Keines der beiden Systeme weiß vom anderen, also wandert der Status per Mensch: über eine Slack-Nachricht, ein Tippen auf die Schulter oder ein langes Meeting in einer ohnehin vollen Woche.
Was gewinnen Sie also, wenn Sie diese Lücke schließen?
Was Ihre Teams davon haben, Jira und Salesforce zu verbinden
Weniger Unterbrechungen, ganz klar. Die meisten davon haben eine gemeinsame Ursache: Jemand im Support oder Vertrieb braucht einen Status, und der einzige Weg dorthin führt über eine Person, die Jira sehen kann. Verbinden Sie die Systeme, und dieser Status erscheint direkt im Salesforce-Datensatz, den die Kollegen ohnehin gerade offen haben.
Außerdem kommen Issues mit Kontext an: Wenn ein Support-Case das Jira-Issue automatisch anlegt, bringt es genau das mit, wonach Ihre Entwickler sonst hinterherfragen müssen – welcher Kunde, welche Umgebung, was er gerade getan hat und was er schon ausprobiert hat.
Dann ist da noch das Backlog. Ohne Account-Daten ist es eine Liste gleich gewichteter Beschwerden – ein Bug, der drei Enterprise-Kunden trifft, sieht genauso aus wie einer, der einen einzelnen Testnutzer betrifft. Und die Jira-Lizenzkosten? Die können ebenfalls sinken: Support-Mitarbeitende, die nur einen Status nachlesen, brauchen keine eigene Lizenz mehr, sobald sie ihn im Salesforce-Datensatz sehen.
All das hängt davon ab, welche Daten tatsächlich synchronisiert werden. Schauen wir uns das also genauer an.
Was muss synchronisiert werden?
Nicht alles. Die meisten durchdachten Implementierungen decken am Ende dieselben Bereiche ab:
Die Verknüpfung selbst. Welcher Salesforce-Case zu welchem Jira-Issue gehört – als echte Beziehung gespeichert statt als Issue-Key, der in ein Textfeld kopiert wurde.
Status und Schlüsselfelder, in beide Richtungen. Status, Priorität, Bearbeiter und Lösung fließen von Jira nach Salesforce. Schweregrad, Auswirkung auf den Kunden und Account-Stufe fließen zurück.
Kommentare, mit Sichtbarkeitssteuerung. Hier verbrennen sich Teams am häufigsten die Finger. Ihre Entwickler schreiben interne Kommentare, die niemals bei einem Kunden landen dürfen, also muss die Integration unterscheiden können, was übertragen wird und was intern bleibt. Prüfen Sie, wie ein Tool damit umgeht, bevor Sie sich festlegen.
Anhänge. Screenshots, Logs und Exporte, die der Support bereits gesammelt hat – damit Ihr Team nicht ein zweites Mal danach fragen muss.
Benutzerzuordnung. E-Mail-Adressen stimmen zwischen zwei Systemen selten überein, besonders nach einer Übernahme. Wer Salesforce vor vier Jahren eingerichtet hat, hat eine andere Konvention verwendet als derjenige, der Jira aufgesetzt hat.
Benutzerdefinierte Felder und benutzerdefinierte Objekte kommen danach. Dort tauchen meist die interessanten Anforderungen auf (und dort stoßen die günstigeren Tools an ihre Grenzen).
Kommen wir also dazu, wer das Ganze baut – und wer sich darum kümmert, sobald es läuft.
Vier Wege, Jira und Salesforce zu verbinden
Die meisten Jira-Teams schließen eigene Entwicklung und Middleware früh aus. Wenn Sie aber alles in Betracht ziehen, wählen Sie zwischen diesen Optionen:
| Weg | Wo er läuft | Wer ihn administriert | Realistische Kosten |
|---|---|---|---|
| Eigenentwicklung über die REST-APIs | Ihr eigener Code, irgendwo selbst gehostet | Ein Entwickler, dauerhaft | Wochen oder Monate Entwicklung, danach laufende Wartung |
| Middleware oder iPaaS | Die Cloud des Anbieters | Wer auch immer sich in die Plattform eingearbeitet hat | Mittlerer fünfstelliger Betrag pro Jahr, steigend mit dem Volumen |
| Eine Jira-seitige Marketplace-App | Ihre Jira-Instanz | Ihr Jira-Admin | Marketplace-Preise pro Benutzer |
| Eine Salesforce-native App | Die Salesforce-Org | Der Salesforce-Admin | Jährliche Pauschale oder pro Benutzer, je nach Anbieter |
Wie also entscheiden? Hier die Vor- und Nachteile der einzelnen Optionen:
Die Eigenentwicklung wirkt am ersten Tag am günstigsten. Beide Plattformen haben ordentliche REST-APIs, und ein kompetenter Entwickler bringt ein Statusfeld an einem Nachmittag von einem System ins andere. Unterschätzt wird alles, was danach kommt: Wiederholungsversuche, Rate Limits, geänderte Feldzuordnungen und ein Stück Infrastruktur, das niemand dokumentiert hat.
Middleware lohnt sich, wenn Jira und Salesforce zwei von acht Systemen sind, die Sie miteinander verbinden müssen. Sind es nur diese beiden, kaufen Sie eine ganze Plattform für ein punktuelles Problem – und die Rechnung wächst mit der Datenmenge, die Sie hindurchschicken.
Eine Jira-seitige App hält die Arbeit in Ihrer eigenen Instanz. Das ist bequem, wenn Ihr Team Jira verantwortet und bei Salesforce nichts mitzureden hat. Der Haken: Ihr Jira-Admin erbt die Konfiguration, einschließlich aller Salesforce-seitigen Entscheidungen darüber, welche Felder wichtig sind.
Eine Salesforce-native App kehrt das um. Das Paket wird in der Salesforce-Org installiert, der dortige Admin konfiguriert es, und Ihre Jira-Instanz trägt keinerlei Zusatzlast.
In der Praxis entscheiden sich die meisten Jira-Teams zwischen diesen beiden Apps: eine in der eigenen Instanz, eine in der des anderen Teams.
So wählen Sie einen Jira-Salesforce-Connector aus
Für welche der beiden sollte sich ein Jira-Team also einsetzen? Entgegen der Intuition: für die, die nicht in Jira installiert wird.
Der erste Impuls ist, das Problem dort zu lösen, wo man selbst die Kontrolle hat. Doch die meisten Konfigurationsentscheidungen sind hier Salesforce-Entscheidungen: mit welchem Objekt das Issue verknüpft wird, welche Felder zugeordnet werden, welche Automatisierung auslöst, wer was sieht. Holen Sie diese Konfiguration auf Ihre Seite, erben Sie Fragen, die Sie ohnehin nicht beantworten können, ohne das Salesforce-Team zu fragen.
Sobald klar ist, auf welche Seite der Connector gehört, trennen zwei Dinge die Kandidaten, die einen Test wert sind, vom Rest.
Schauen Sie über die Demo hinaus auf die Funktionen
Jeder Connector auf beiden Marktplätzen wirbt mit bidirektionaler Synchronisation – diese Angabe sagt also nichts aus. Der Unterschied zeigt sich, sobald Sie den Standardfall verlassen:
- Benutzerdefinierte Objekte. Manche Connectoren ordnen jedes Salesforce-Objekt über eine Einstellungsseite zu; andere decken Cases ab und verlangen für alles andere Code. Fragen Sie vor der Installation nach – sonst finden Sie es nach etwa einem Monat heraus.
- Wo die Automatisierung läuft. Ein Connector, der seine Aktionen in Salesforce Flow bereitstellt, lässt den Salesforce-Admin Regeln mit einem Werkzeug bauen, das er bereits kennt. Einer mit eigener Regel-Engine ist ein weiteres Tool, das gelernt werden will.
- Sichtbarkeit von Kommentaren. Prüfen Sie, ob interne Jira-Kommentare intern bleiben können – und ob sich das pro Kommentar einstellen lässt statt nur nach dem Alles-oder-nichts-Prinzip.
- Cloud und Data Center. Wenn eine Migration auf der Roadmap steht, klären Sie, ob sie eine zweite Lizenz bedeutet.
Lesen Sie die Bewertungen – und achten Sie auf ihre Anzahl
Eine Bewertung allein sagt wenig. Eine 5,0 aus sechs Rezensionen und eine 4,9 aus hundertfünfzig sind nicht dasselbe Signal, denn hinter jeder Rezension steht eine echte Installation, mit der jemand gearbeitet hat. Lesen Sie also zuerst die Anzahl, dann die Bewertung (und lesen Sie die schlechten Rezensionen zuerst, denn dort beschreiben Nutzer, was kaputtging und wie lange der Support für eine Antwort brauchte).
Der Peeklogic Jira Connector ist hier ein nützlicher Maßstab, weil er auf beiden Seiten bewertet wird. Er hat 4,99 von 5 Punkten aus 147 Rezensionen auf AppExchange und 5 von 5 aus 216 Rezensionen auf dem Atlassian Marketplace. Das sind zusammen mehr als 360 Rezensionen – eine Basis, die groß genug ist, dass die Bewertung etwas über die Stabilität aussagt.
Einen Salesforce-nativen Connector Schritt für Schritt einrichten
Die folgenden Schritte orientieren sich beispielhaft am Peeklogic Jira Connector. Der Ablauf ist bei den meisten Salesforce-nativen Connectoren ähnlich, auch wenn die Bezeichnungen der Bildschirme abweichen.
Bevor Sie beginnen
Sie brauchen einen Salesforce-Admin mit der Berechtigung, Pakete zu installieren, und jemanden mit Jira-Administratorrechten, der die Verbindung autorisiert. Letzteres ist ein einmaliger Schritt, keine dauerhafte Rolle: Sobald die Verbindung autorisiert ist, bleibt die Konfiguration auf der Salesforce-Seite.
Legen Sie fest, welches Salesforce-Objekt Sie zuerst verknüpfen. Cases sind der übliche Einstieg, und es ist einfacher, später ein zweites Objekt hinzuzufügen, als einen chaotischen ersten Rollout zu entwirren.
Schritt 1: Paket installieren
Suchen Sie den Connector auf AppExchange:
Klicken Sie auf Get It Now und wählen Sie, ob Sie in eine Sandbox oder in die Produktion installieren.
Beginnen Sie mit einer Sandbox. Legen Sie fest, welche Profile Zugriff erhalten; „nur Admins“ ist die sichere Voreinstellung, bis Sie getestet haben.
Schritt 2: Mit Jira verbinden
Starten Sie den Einrichtungsassistenten und verweisen Sie ihn auf Ihre Jira-Instanz, Cloud oder Data Center. Die Authentifizierung läuft über Salesforce Named Credentials, sodass die Zugangsdaten im Salesforce-eigenen Credential Store liegen statt in einem Feld, das jemand auslesen kann. Für diesen Schritt brauchen Sie Ihren Jira-Admin.
Schritt 3: Objekte und Felder zuordnen
Wählen Sie das Salesforce-Objekt und das Jira-Projekt, mit dem es verknüpft wird, und ordnen Sie dann die Felder in beide Richtungen zu: Status und Priorität aus Jira, Schweregrad und Account-Daten nach Jira. Feldzuordnungen werden live in einem Admin-Panel bearbeitet, sodass eine spätere Änderung kein erneutes Deployment erfordert.
Schritt 4: Regeln für Kommentare und Anhänge festlegen
Entscheiden Sie, welche Kommentare in welche Richtung übertragen werden und wie sichtbar sie auf der anderen Seite sind. Erledigen Sie das, bevor irgendjemand die Verbindung nutzt – denn durchgesickerte Kommentare sind die Beschwerde, die am schnellsten beim Management landet.
Schritt 5: Automatisierung in Flow aufbauen
Fügen Sie die Aktionen des Connectors in einen Salesforce Flow ein. Eine typische erste Regel: Wenn ein Jira-Issue auf „Done“ wechselt, wird der Case-Status aktualisiert und der Verantwortliche benachrichtigt. Das Ganze wird per Klick gebaut und ist für jeden mit Admin-Rechten einsehbar.
Schritt 6: Absichtlich kaputtmachen, dann live gehen
Benennen Sie vor dem Produktivstart ein Feld auf der Jira-Seite um und prüfen Sie, ob der Connector es bemerkt. Schließen Sie ein Issue, öffnen Sie es wieder und kontrollieren Sie beide Datensätze. Wechseln Sie dann in die Produktion und fügen Sie Benutzer Profil für Profil hinzu.
P.S.: Bevor Sie sich für einen Connector entscheiden …
… fragen Sie, was passiert, wenn Sie ein zweites Objekt synchronisieren müssen. Manche Tools ordnen jedes Objekt über eine Einstellungsseite zu; andere decken den Standardfall ab und verlangen für alles andere Code – und das finden Sie nach etwa einem Monat heraus.
Wenn alles funktioniert, kommt niemand mehr vorbei, um nach dem Bug zu fragen. Der Support liest den Status direkt im Datensatz ab, der Vertrieb gibt ihn an den Kunden weiter, und Ihre Entwickler hören erst wieder von dem Ticket, wenn tatsächlich etwas zu beheben ist.
Und wenn Sie diese Liste lieber nicht selbst durcharbeiten möchten: Ihre Freunde bei Peeklogic sind immer nur einen kurzen Demo-Call entfernt.