Teilnahme an Journeys von Kontakten und Leads

***Hinweis: Der Inhalt ist zum Zeitpunkt der Erstellung korrekt. Microsoft mag in der Zwischenzeit Änderungen vorgenommen haben.***

Eine Sache, die mir im Outbound schon gefehlt hat, ist die Möglichkeit die Teilnahme an Journeys von Kontakten oder Leads zu sehen. Ich kann natürlich herausfinden, welche Emails aus einer Journey ein Kontakt bekommen hat. Aber es gibt keine gute Übersicht, die mir anzeigt, durch welche Journeys der Kontakt durchgelaufen ist oder in welchen Journeys er gerade noch steckt. Ich könnte mir vorstellen, dass es schon bald auch mit MS Fabric möglich sein könnte. Aber bishin habe ich nun eine kleine Lösung in Real-time Marketing gefunden. Am Kontakt oder Lead ist dann sichtbar, wann er Teil welcher Journey war. Darüber hinaus kann man diese neue Tabelle auch für Segmentierung verwenden. Momentan ist es nämlich nicht möglich in Segmenten, nach der Teilnahme an Journeys zu suchen.

Als Voraussetzung ist wichtig zu wissen, dass Dynamics 365 Customer Insights – Journey, aka Dynamics 365 Marketing, für jeden Zulauf in einer Journey einen Datensatz in die Tabelle Journey Instance (technischer Name: msdynmkt_journeyinstance) schreibt. Leider werden die GUIDs dort aber nicht in Lookups aufgelöst, sondern uns einfach als Text gegeben, aber das können wir ja easy in PowerAutomate nutzen. Ich möchte vorher noch klar machen, dass du prüfen solltest, ob diese Lösung für deine Organisation sinn voll ist und dass Microsoft diese Funktion hoffentlich bald standardmäßig nachliefern wird.

Kurzer Exkurs: Die Journey Instance Tabelle ist übrigens vom Typ „Elastisch“, das bedeutet, dass sie von Microsoft Dataverse verwaltet wird. Elastische Tabellen verfügen über die gleiche vertraute User-Experience und API wie Standardtabellen. Sie haben viele Aspekte und Optionen mit Standardtabellen gemeinsam, verfügen aber über eigene, einzigartige Funktionalitäten und Funktionalitäten, die von Azure Cosmos DB unterstützt werden.[1]

Erstelle eine neue Tabelle

Als erstes erstelle ich eine eigene Tabelle, in der ich die Informationen speichere und dann am Kontakt oder Lead anzeige. Ich nenne sie Journey Participations, weil ich das passend finde, aber das ist natürlich frei wählbar. Dazu lege ich ein paar Felder an:

Erstellung der Felder, die für die neue Tabelle benötigt werden.
  • Contact: Lookup zum Kontakt
  • Journey: Lookup zur Journey (msdynmkt_journey)
  • Journey Instance ID: Ein Textfeld, in dem ich die ID des Journey Instance Datensatzes speichere und später bei Updates des Journey Participation Datensatzes benötigt
  • Lead: Lookup zum Lead (das geht ja mittlerweile in Realtime Journeys)
  • State: Status der Journey Instance, der sich auch updaten kann. Die Werte sind Inprogress, Completed, cancelledbyExitEvent, cancelledbySupressionSegment, cancelledbyJourneyStopped, cancelledbyActionFailure. In der Tabelle Journey Instance ist das ein lokales Option Set und ich speichere es in einem einfachen Textfeld ab, ein bisschen aus Bequemlichkeit.
  • Timestamp: Zeitstempel, wann die Journey Instance erstellt oder geändert wurde
  • Trigger Type: Dieses Feld befülle ich später im PowerAutomate mit einem Wert aus der Journey selbst. Es kann folgende Optionen geben:
    • ongoing (Ein einmaliger Kontaktverlauf, bei dem neu hinzukommende Zielgruppenmitflieder jederzeit starten können)
    • recurring (Ein wiederkehrender Kontaktverlauf, bei dem alle Mitglieder der Zielgruppe den Kontaktverlauf wiederholen)
    • onetime (Ein einmaliger Kontaktverlauf mit einer statischen Zielgruppe)
    • Event (Auslöserbasiert)

Erstelle einen neuen Cloudflow für die Teilnahme an Journeys

Der Flow soll bei jeder erstellten oder aktualisierten Journey Instance eine Datensatz in unserer neuen Tabelle anlegen oder ebenfalls aktualisieren. Im ersten Teil des Flows starten wir mit dem Trigger, der immer auslöst, wenn eine Journey Instance erstellt oder aktualisiert wird. Danach hole ich mir nochmal die Informationen aus der Tabelle, das macht es für mich im späteren Verlauf des Flows leichter. Das gleiche mache ich auch für die Journey selbst, so dass ich an die Informationen für den Triggertyp gelange. Nutze dafür den dynamischen Wert Journey Definition aus dem Trigger, denn dahinter verbirgt sich die Journey-GUID.

Teil 1 des Flows zum Erstellen einer Teilnahme an Journeys

Im nächsten Teil des Flows schaue ich, ob es bereits einen Datensatz in der Journey Participation Tabelle gibt. Denn wenn nicht, soll ein neuer erstellt werden. Und wenn es schon einen gibt, soll dieser mit dem Zeitstempel und Status aktualisiert werden. In der Aktion „Listenzeilen“ filtere ich nach Journey Participations mit der gleichen Journey Instance GUID. Das geht z.B. mit dem oData Filter reply_journeyinstanceid eq ‚@{triggerOutputs()?[‚body/msdynmkt_journeyinstanceid‘]}‘. In der folgenden Bedingung nutze ich den Ausdruck length(outputs(‚Get_existing_journey_participations_‘)?[‚body/value‘]). Denn wenn keine Datensätze gefunden werden, ist das Ergebnis 0 und wenn es schon einen gibt, ist das Ergebnis 1 oder mehr, je nachdem wie viele Datensätze gefunden werden. Aber im Idealfall sollte natürlich nur ein Datensatz gefunden werden, der vorher schonmal erstellt wurde.

Teil 2 des Flows zum Erstellen einer Teilnahme an Journeys

Flow: Neuer Datensatz oder Datensatz aktualisieren

Gibt es keinen Datensatz, gehen wir also den Ja-Pfad entlang. Dort müssen wir erst prüfen, ob ein Kontakt oder Lead durch die Journey gelaufen ist. Das kann mit dem Feld Target Entity aus dem Trigger des Flows festgestellt werden. Abhängig vom Ergebnis legen wir einen neuen Datensatz für Journey Participations für Kontakte oder Leads an. In diesem neuen Datensatz füllen wir ebenso das Lookup Journey und den Zeitstempel aus. An dieser Stelle befüllen wir auch das Feld Journey Instance ID, mit dem wir im zweiten Teil nach bestehenden Datensätzen filtern. Wenn du auch die Felder State und Trigger Type wie ich als Textfeld angelegt hast, musst du am besten noch eine kleine Anpassung vornehmen, ansonsten wird dort nur der Wert und nicht das Label angezeigt. Ergänze also den Option Set technischen Namen im Flow mit @OData.Community.Display.V1.FormattedValue. Das sieht dann für State und Trigger Type folgendermaßen aus:

outputs('Get_Journey_Instance')?['body/msdynmkt_journeyinstancestate@OData.Community.Display.V1.FormattedValue']

outputs('Get_Journey')?['body/msdynmkt_triggertype@OData.Community.Display.V1.FormattedValue']
Teil 3 des Flows zum Erstellen einer Teilnahme an Journeys

Wenn es jedoch schon einen Journey Participation Datensatz gibt, gehen wir in der ersten Bedingung in den Nein-Pfad. Dort aktualisieren wir den bestehenden Datensatz für die Felder Status und Zeitstempel. So ist immer ein aktueller Stand der Journey Teilnahme am Kontakt sichtbar.

Teil 4 des Flows

Zeige die Teilnahme an Journeys auf dem Kontakt oder Lead an

Als letzten Schritt füge ich auf dem Lead und Kontakt eine Raster an, so dass die Datensätze auf dem Formular anzeigt werden. Die Ansicht erstelle ich mit den Spalten Zeitstempel, Journey, Trigger Type und State. Hierdurch ist für alle Nutzer*innen transparent sichtbar, an welchen Journeys dieser Kontakt teilgenommen hat.

Subgrid auf dem Kontaktformular

Hinweise

Wenn in deiner Organisation viele Journeys mit vielen Zuläufen stattfinden, solltest du bei PowerAutomate auf das API Limit achten. Mit anderen Worten: Je häufiger der Flow läuft, desto schneller wird dieses Limit erreicht. Damit der der Flow im Limit bleibt, wäre eine Möglichkeit ein Filter auf dem Trigger, so dass nur Journey Instances für zum Beispiel auslöserbasierte Journeys angelegt werden. Mehr Informationen dazu findest du hier: Requests limits and allocations – Power Platform | Microsoft Learn

Um die neue Tabelle in Segmenten zu verwenden, denke daran beim Erstellen der Tabelle in den Tabelleneinstellungen die Checkbox Track Changes anzuhaken.

Referenzen: [1] Elastische Tabellen erstellen und bearbeiten (Vorschau) – Power Apps | Microsoft Learn

Schau dir auch die FAQs in meinem Blog an: Kurze Fragen – schnelle Antworten! Zu den FAQs

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Sharing is caring

Stay informed

WordPress Cookie Hinweis von Real Cookie Banner