使用綁定 ID 讓多個觸發程序產生關聯

文章
01/31/2024

對於觸發程序型的可重複旅程，客戶可以在上一次運行未完成的情況下重複一個旅程。例如，考量發送約會確認和提醒的旅程。當一個人註冊他們的第一次約會時，他們進入旅程並收到確認。他們將繼續在旅途中等待，直到他們在約會前一天收到提醒。在此期間，同一人可以註冊第二次約會。旅程參與者將在第二次約會中再次開始相同的旅程。換句話說，同一個人現在正在經歷同一旅程的兩個例子。

在這種情況下，如果旅程參與者取消了其中一個約會，他們應僅退出與已取消的約會相關的旅程。例如，如果他們取消了第一個約會，則應退出與第一個約會有關的旅程，但會繼續與第二個約會有關的旅程。如果您使用的是現成的 Dataverse 型事件，則行為是自動的，不需要其他操作。但是，如果使用的是自訂觸發程序，則必須設定觸發程序以正確識別必須與觸發程序相關的旅程特定實例。

使用 bindingId 屬性唯一識別旅程的每個實例

每個自訂觸發程序都有一個可選的 bindingId 屬性，可用於將觸發程序綁定到旅程的特定實例。當 bindingId 屬性不存在時，觸發程序將作用於此人參與之旅程中的所有實例。例如，如果此人已註冊了兩個約會，但取消了其中一個約會，且如果取消的觸發程序未使用 bindingId，則該人員將退出旅程的兩個實例。如果打算在可重複的旅程中使用觸發程序，強烈建議在觸發程序中包含 bindingId。

當啟動旅程的觸發程序包含 bindingId 時，該 ID 用於識別旅程實例。若要識別旅程實例，任何其他事件都應使用相同的 bindingId。 bindingId 的格式如下：{entityType}/{entityId} 例如，如果開始事件是名為約會已確認的約會實體，並且其實體 Id 為「123」，則 bindingId 將為 Appointment/123。您的退出事件約會已取消應屬於同一實體類型，並應使用相同的 bindingId（Appointment/123）來唯一識別旅程實例。

如果您僅在旅程中使用自訂觸發程序，則可以依靠唯一字串來識別旅程實例。

Note

如果缺少 bindingId，或綁定是針對不同的實體類型，則自訂觸發程序將對某人參與之旅程的所有實例執行操作。

在自訂觸發程序和現成事件或自訂業務事件間進行關聯

如果要使用自訂觸發程序和現成或自訂業務事件的組合，bindingId 將使用特殊格式來唯一識別 Dataverse 表格和行。例如，您的旅程可以從現成的事件建立商機開始。然後，您可以對退出事件使用名為贏得商機的自訂觸發程序。自訂觸發程序贏得商機必須包含一個 bindingId，遵循已建立的商機事件模式，來唯一識別每個實例。

每當旅程由現成或自訂業務事件開始時，該旅程的每個實例都可以透過 {entityType}/{unique row ID} 模式唯一識別。此模式必須包含在任何自訂觸發程序的 bindingId 屬性中，以便在自訂觸發程序和現成或自訂業務事件間進行關聯。

在贏得商機自訂觸發程序中，bindingId 可以是：

bindingId = opportunity/{unique ID of the opportunity row}

如果自訂觸發程序遵循上述 bindingId 模式，則可以使用它們來識別確切的旅程實例，即使與其他業務事件一起使用也是如此。當 bindingId 完成執行時，它將作用於旅程的所有實例。

Note

綁定僅適用於相同的實體類型。

如何將 bindingId 新增到自訂觸發程序

可以在自訂觸發程序的代碼程式碼片段修改 bindingId 屬性。

若要存取現有的自訂觸發程序代碼程式碼片段：

移至 Customer Insights - Journeys>參與>觸發程序。
選擇要向其新增 bindingId 的自訂觸發程序。
選取移至程式碼片段。
複製程式碼片段並將其貼到您選擇的代碼編輯器中。按照上述格式修改 bindingId 屬性（如果僅將其用於自訂觸發程序或 {table_name}/{unique row ID} 在自訂觸發程序和現成事件或自訂業務事件間進行關聯，則該屬性是唯一字串）。

可以按照相同的步驟在建立新的自訂觸發程序時新增 bindingId。

bindingId 解譯

字元 / 是保留的。始終假定 bindingId 採用 / 單獨的格式，並且將移除任何前導或尾隨 /。此外，結果中沒有 /。該應用程式總是試圖以這種 {entityType}/{entityId} 方式解釋它。

範例:

"A/B"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"A"
will be interpreted as 
{entityType = ""}/{entityId = "A"}

"A/B/C" 
will be interpreted as 
{entityType = "AB"}/{entityId = "C"}

""
will be interpreted as 
{entityType = ""}/{entityId = ""}

"A/B/"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"///A/B////"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

比較演算法：

[Case 0] trigger has bindingId = "", meaning no restriction at all
    Always resume.
[Case 1] entityType matches, and entityId matches:
    Resume.
[Case 2] entityType matches, but entityId doesn't match:
    No resume.
[Case 3] entityType doesn't match trigger:
    It doesn't make sense to apply binding, so we fall back to what we have now and let it resume the journey instance.

範例:

Trigger event: "incident/000"
Resume event: "incident/000"
Result: Case 1 resume

Trigger event: "incident/000"
Resume event: "incident/001"
Result: Case 2 no resume

Trigger event: "incident/000"
Resume event: "opportunity/001"
Result: Case 3 resume

Trigger event: "incident/000"
Resume event: "opportunity/000"
Result: Case 3 resume

Trigger event: "incident/000"
Resume event: "random string"
Result: Case 3 resume

Trigger event: "random string"
Resume event: "random string"
Result: Case 1 resume

Trigger event: "random string 1"
Resume event: "random string 2"
Result: Case 2 no resume

Trigger event: "random string 2"
Resume event: ""
Result: Case 2 no resume

Trigger event: ""
Resume event: ""
Result: Case 0 resume

Trigger event: ""
Resume event: "incident/000"
Result: Case 0 resume

Trigger event: "incident/000"
Resume event: ""
Result: Case 3 resume

分享方式：