Unsere Salesforce-Synchronisierungslösung ermöglicht das automatische Teilen relevanter Geschäftsdaten über Abteilungen und Werkzeuge hinweg. In diesem Artikel beschreiben wir, wie die gemeinsame Nutzung von Vertragsdaten zwischen der maßgeschneiderten Webanwendung der Serviceabteilung und Salesforce funktioniert. Dadurch ist ein reibungsloser, abteilungsübergreifender Zugriff und eine automatisierte nutzungsbasierte Abrechnung möglich geworden.
Die Herausforderung
Salesforce ist ein Customer Relationship Management-System (CRM), das in einer Cloud läuft. Seit seinem ersten Erscheinen im Jahr 1999 hat es aus zwei Hauptgründen ständig an Popularität gewonnen. Erstens folgt es dem allgemeinen Trend zu Cloud-basierten Lösungen anstelle von On-Premise-Lösungen. Zweitens wurde es durch die geschickte Erweiterung des Ökosystems, das es umgibt (z. B. durch den Kauf von Heroku, Tableau und Slack, um nur einige zu nennen), zu einer der flexibelsten SaaS-Vertriebsplattformen.
Hier möchte ich erklären, wie wir einen maßgeschneiderten Zwei-Wege-Synchronisierungsdienst für Salesforce entwickelt haben, der unseren Kunden eine nahtlose Integration zwischen dem Vertriebs- und dem Serviceteam ermöglicht hat. Das Serviceteam unseres Kunden verwaltet das digitale Produkt (Anzeigen) auf jeder Plattform über eine maßgeschneiderte Serviceanwendung (Service-App), die auf dem leistungsstarken Django-Framework basiert. Die Service-Anwendung steuert sowohl den Inhalt der Anzeigen als auch große Teile der Geschäftslogik auf der Plattform. Auf der anderen Seite steht das Vertriebsteam, das die Verträge mit den Kunden abschließt.
Lassen Sie mich ein konkretes Beispiel anhand eines hypothetischen Unternehmens anführen, das Anzeigen in verschiedenen Größen (klein, mittel, groß, riesig) verkauft. Der Vertrieb hat mit einem Kunden einen Vertrag über 5 Einheiten riesiger und 3 Einheiten kleiner Anzeigen zu einem bestimmten Preis pro Einheit abgeschlossen. Eine Kleinanzeige wurde erstellt und auf den Auftrag gebucht, wie in der Spalte „Verbrauch“ der entsprechenden Produktart angegeben.
Die ersten drei Spalten werden vom Verkaufsteam bereitgestellt und in Salesforce verwaltet. Die Spalte für den Verbrauch muss manuell aktualisiert werden, wenn die Anzeigen in der Service-App tatsächlich erstellt wurden.
Das Vertriebs- und Serviceteam benötigte eine automatische, zuverlässige Möglichkeit, die relevanten Daten aus den beiden Diensten zu verknüpfen. Daher musste jede erstellte Anzeige mit einem Vertrag verknüpft und an Salesforce zurückgemeldet werden. So kann das Serviceteam sofort auf die Informationen zugreifen, welche Produkte für einen Kunden verfügbar sind, und das Vertriebsteam kann in seiner gewohnten Arbeitsumgebung ohne Kontextwechsel überprüfen, wie viele Produkteinheiten eines Vertrags verbraucht sind.
Unsere Lösung
Unsere bidirektionale Salesforce-Synchronisationslösung sorgt dafür, dass die Nutzung einer Einheit des entsprechenden Produkts an Salesforce zurückgemeldet wird. Technisch wird dies durch das Lesen und Schreiben der relevanten Daten aus Salesforce über dessen REST-API erreicht. Jedes Mal, wenn eine Anzeige in der Service-App erstellt wird, wird sie für die Nutzungsmeldung in eine Warteschlange gestellt. Ein Hintergrundprozess arbeitet diese Warteschlange permanent ab und meldet die Auslastung sofort an Salesforce zurück. Er verwendet die REST-API, um einen Nutzungseintrag für jedes von einer Anzeige verwendete Produkt zu erstellen. Diese Nutzungseinträge sind im Zuständigkeitsbereich der Service-App und werden von Salesforce lediglich aggregiert, um die verbrauchten und verfügbaren Einheiten für jeden Produkttyp des Vertrags zu berechnen.
Es gibt eine Zwei-Wege-Synchronisation zwischen Salesforce und der Service-App. Die Vertragsdaten sind in der Service-App zugänglich. In der Service-App erstellte Anzeigen werden an Salesforce zurückgemeldet.
Unsere maßgeschneiderte Lösung definiert eine klare Schnittstelle für den Informationsaustausch über die Salesforce REST API. Das Design wird von zwei Kernprinzipien geleitet:
- Entkopplung
- Datenzuständigkeit
Während im vorigen Abschnitt einige Gründe für die Entkopplung beschrieben wurden, fehlt noch eine klare Definition dieser. Ich betrachte Systeme als entkoppelt, wenn sie unabhängig voneinander arbeiten können, selbst wenn eines von ihnen ausfällt oder die Verbindung zwischen ihnen unterbrochen wird. Nur der Datenaustausch verzögert sich, bis die Verbindung wiederhergestellt ist.
Dateneigentum, das zweite Schlüsselprinzip, bedeutet, dass für jeden Dateneintrag nur ein System zuständig ist. Daher nur ein System darf ihn ändern, während das andere System die Informationen nur lesen kann. In unserem Fall werden die Vertragsinformationen von der Service-App direkt aus Salesforce gelesen und dem Benutzer angezeigt, wenn sie verfügbar sind. Da keine Informationen zwischengespeichert werden, bleiben die Daten immer auf dem neuesten Stand! Verträge sind Eigentum von Salesforce und werden von der Service-App niemals geändert.
Die Produktnutzungstabelle befindet sich zwar in der Salesforce-Datenbank, ist aber Eigentum der Service-App. Dies ermöglicht es den Benutzern der Service-App, Fehler zu korrigieren und ausgewählte Produkte oder Verträge zu ändern. Wenn ein Vertrag jedoch erfüllt ist, werden seine Nutzungseinträge gesperrt und jeder Versuch, sie zu ändern, führt zu einem Fehler. Zu diesem Zeitpunkt, der an die konkreten Geschäftsanforderungen angepasst werden kann, kann sich Salesforce darauf verlassen, dass die Nutzungsdaten unveränderbar sind. Die Produktnutzung kann zuverlässig zur Erstellung von Rechnungen und Buchhaltungsberichten verwendet werden.
Lassen Sie uns dies auf ein einfaches Beispiel herunterbrechen. Angenommen, unser Beispielvertrag gehört zu "Magic Ads Inc", die ihren Kunden am Ende des Monats eine Rechnung stellt. Nun stellt Petra Mitte des Monats fest, dass Klaus fälschlicherweise drei Kleinanzeigen statt einer Riesenanzeige gebucht hat. Sie kann diesen Fehler in der Service-App ganz einfach korrigieren, da die Daten eindeutig sind und die Datensätze laut Abrechnungsbestimmungen noch nicht gesperrt sind.
Ich möchte einen kurzen technischen Exkurs machen, um die Schlüsselrolle zu beschreiben, die die Verwendung von redis für unsere Warteschlange bei der Entkopplung und Fehlerbehebung spielt. In diesem Beispiel wird Anzeige 3 in der Service-App gespeichert und der Warteschlange hinzugefügt. Gleichzeitig holt der Hintergrundprozess die Anzeige 1 ab und versucht, die entsprechenden Nutzungsinformationen an Salesforce zu übermitteln.
Falls die Übermittlung von Anzeige 1 fehlschlägt, fügt der Hintergrundprozess sie wieder der Warteschlange hinzu:
Dieser Mechanismus stellt sicher, dass vorübergehende Übertragungsfehler nicht zu einem Datenverlust führen. Sobald die Ursache des Übertragungsfehlers von Anzeige 1 behoben ist, überträgt der Hintergrundprozess die Anzeige erneut. Da wir fehlgeschlagene Anzeigen an das Ende der Warteschlange stellen, verzögert eine einzelne fehlgeschlagene Anzeige nicht die anderen.
Wege, die wir nicht gegangen sind
Als Agentur, bei der die Entwickler im Vordergrund stehen, verfolgen wir bei djangsters einen schlanken Ansatz in Bezug auf die Infrastruktur und verlagern so viel wie möglich davon in eine Cloud. Da der Anbieter unserer Wahl, Heroku, seit 2010 ein Tochterunternehmen von Salesforce ist, prüfen wir zuerst die Out-of-the-Box-Lösungen. Die Service-App läuft auf Heroku. Es handelt sich um eine leicht angepasste Django-Webanwendung, die alle Anzeigendaten in der angeschlossenen Postgres-Datenbank speichert.
Mit Heroku Connect für Salesforce können Datenbanktabellen asynchron mit Salesforce synchronisiert werden. Die Mappings ermöglichen den direkten Zugriff auf interne Salesforce-Einträge aus der Postgres-Datenbank und umgekehrt. Dies klingt zwar nach einer großartigen Lösung des Anbieters, den wir lieben und auf den wir uns für unsere Infrastruktur verlassen, hat aber die negativen Auswirkungen der Kopplung beider Dienste auf Infrastrukturebene.
Das Fehlen einer klar definierten Schnittstelle würde Salesforce zu einer harten Abhängigkeit für den Kundenservice machen, d. h. der Kundenservice wäre auf Salesforce angewiesen, um zu funktionieren. Eine Abhängigkeit, die sowohl die technische Komplexität massiv erhöht als auch die geschäftlichen Möglichkeiten für unsere Kunden einschränkt. Da die Interaktion zwischen Salesforce und der Service-App einen klaren und begrenzten Zweck hat, scheint eine klare Trennung der Belange, die eine kundenspezifische Lösung bietet, sowohl aus technischer als auch aus geschäftlicher Sicht der bessere Ansatz zu sein.
Fazit
Durch eine maßgeschneiderte Lösung mit einer klaren, minimalen Schnittstelle erreichen wir eine Trennung der Bereiche. Service- und Vertriebsteams können von ihrer gewohnten Arbeitsumgebung aus auf relevante Informationen zugreifen, ohne dass ein zeitaufwändiger Kontextwechsel erforderlich ist. Beide Systeme arbeiten dabei unabhängig voneinander weiter, d. h. bei einem Ausfall des einen Systems kann das andere Team weiterarbeiten.
Das Dateneigentum sorgt für klare Verantwortlichkeiten. Dies ermöglicht eine zuverlässige Verbindung zwischen verkauften Produkten auf einem Vertrag und verbrauchten Produkteinheiten (Anzeigen) auf der Plattform. Während Fehler bis zu einem bestimmten Zeitpunkt leicht behoben werden können, sind Berichte und Rechnungen danach unveränderlich.
Die Lösung ist kostengünstig (es ist nur ein zusätzlicher Hintergrunddienst erforderlich) und wartungsarm, da der Prozess vollautomatisch abläuft und Fehler zuverlässig behoben werden. Durch die übersichtliche Oberfläche lässt sie sich leicht an veränderte Geschäftsanforderungen auf beiden Seiten - Vertrieb und Kundenservice - anpassen.
