Utilizzare ID binding per eseguire la correlazione tra tra i trigger

Articolo
01/30/2024

Per Percorsi ripetibili basati su trigger, un cliente può ripetere un percorso senza aver completato l'esecuzione precedente. Ad esempio, considera un percorso che invia conferme e promemoria di appuntamenti. Quando una persona si iscrive al primo appuntamento, entra nel percorso e riceve una conferma. Continua ad aspettare durante il percorso fino a quando non riceverà un promemoria un giorno prima dell'appuntamento. Durante questo periodo, la stessa persona potrebbe registrarsi per un secondo appuntamento. Il partecipante al percorso inizierà lo stesso percorso una seconda volta per il secondo appuntamento. In altre parole, la stessa persona sta attraversando due istanze dello stesso percorso.

In tale situazione, se il partecipante al percorso annulla uno degli appuntamenti, deve uscire solo dal percorso associato all'appuntamento annullato. Ad esempio, se annullano il primo appuntamento, devono uscire dal percorso associato al primo appuntamento ma continuare il percorso associato al secondo appuntamento. Se stai usando eventi basati su Dataverse predefiniti, il comportamento è automatico e non sono necessarie altre azioni. Tuttavia, se utilizzi trigger personalizzati, devi configurare il trigger per identificare correttamente l'istanza specifica del percorso a cui deve essere associato il trigger.

Utilizzando l'attributo bindingId per identificare in modo univoco ogni istanza del percorso

Ogni trigger personalizzato ha un attributo bindingId opzionale che può essere utilizzato per associare il trigger a istanze specifiche di un percorso. Quando l'attributo bindingId non è presente, il trigger agirà su tutte le istanze del percorso a cui sta partecipando la persona. Ad esempio, se la persona si è registrata per due appuntamenti ma ne annulla uno e se il trigger annullato non ha utilizzato un attributo bindingId, quella persona uscirà da entrambe le istanze del percorso. Se intendi utilizzare i trigger in percorso ripetibili, è fortemente consigliabile includere un attributo bindingId nel trigger.

Quando il trigger che avvia un percorso contiene un bindingId, tale ID viene utilizzato per identificare l'istanza del percorso. Per identificare l'istanza del percorso, qualsiasi altro evento dovrebbe utilizzare lo stesso bindingId. Il formato del bindingId è il seguente: {entityType}/{entityId}. Ad esempio, se il tuo evento iniziale è un'entità Appuntamento chiamata Appuntamento confermato e ha un entityId di "123", il bindingId sarebbe Appointment/123. Il tuo evento di uscita Appuntamento annullato dovrebbe essere dello stesso tipo di entità e dovrebbe utilizzare lo stesso bindingId (Appointment/123) per identificare in modo univoco l'istanza del percorso.

Se utilizzi solo trigger personalizzati nel percorso, puoi ricorrere a stringhe univoche per identificare le istanze del percorso.

Nota

Un trigger personalizzato agirà su tutte le istanze di un percorso a cui qualcuno sta partecipando se il bindingId manca o se l'associazione è per un tipo di entità diverso.

Esegui la correlazione tra trigger personalizzati ed eventi predefiniti o eventi aziendali personalizzati

Se desideri utilizzare una combinazione di trigger personalizzati ed eventi aziendali predefiniti o personalizzati, bindingId utilizza una formattazione speciale per identificare in modo univoco la tabella e la riga Dataverse. Ad esempio, il tuo percorso potrebbe iniziare con l'evento predefinito Opportunità creata. È quindi possibile utilizzare un trigger personalizzato chiamato Opportunità acquisita per l'evento di uscita. Il trigger personalizzato Opportunità acquisita deve contenere un bindingId che segue lo schema dell'evento Opportunità creata per identificare in modo univoco ogni istanza.

Ogni volta che un percorso viene avviato da un evento aziendale predefinito o personalizzato, ogni istanza del percorso può essere identificata in modo univoco dal modello {entityType}/{unique row ID}. Questo modello deve essere incluso nell'attributo bindingId di qualsiasi trigger personalizzato da correlare tra trigger personalizzati ed eventi aziendali predefiniti o personalizzati.

Nel caso del trigger personalizzato Opportunità acquisita, il bindingId potrebbe essere:

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

Se i trigger personalizzati seguono lo schema bindingId descritto sopra, possono essere utilizzati per identificare l'esatta istanza del percorso, anche se utilizzati con altri eventi aziendali. Quando il bindingId viene implementato, agisce su tutte le istanze del percorso.

Nota

Il binding funziona solo con gli stessi tipi di entità.

Come aggiungere un bindingId a un trigger personalizzato

Puoi modificare l'attributo bindingId nel frammento di codice per un trigger personalizzato.

Per accedere al frammento di codice per un trigger personalizzato esistente:

Vai ai Customer Insights - Journeys>Interazione>Trigger.
Seleziona il trigger personalizzato che desideri aggiungere a bindingId.
Seleziona Vai al frammento di codice.
Copia il frammento e incollalo nel tuo editor di codice preferito. Modifica l'attributo bindingId seguendo i formati sopra menzionati (una stringa univoca se la stai utilizzando solo con trigger personalizzati o {table_name}/{unique row ID} quando si esegue la correlazione tra trigger personalizzati ed eventi predefiniti o eventi aziendali personalizzati).

Puoi seguire gli stessi passaggi per aggiungere un bindingId durante la creazione di un nuovo trigger personalizzato.

Interpretazione di bindingId

Il carattere / è riservato. Si presume sempre che il bindingId è in un formato separato da / e qualsiasi simbolo / iniziale o finale sarà rimosso. Inoltre, il risultato non contiene nessun simbolo /. L'app cerca sempre di interpretarlo in questo modo {entityType}/{entityId}.

Esempi:

"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"}

Algoritmo di confronto:

[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.