Usar id. vinculantes para correlacionar desencadenadores

Artículo
01/31/2024

En el caso de los recorridos repetibles basados en desencadenadores, un cliente puede repetir un recorrido sin haber completado el anterior. Por ejemplo, considere un recorrido que envía confirmaciones y recordatorios de citas. Cuando una persona se inscribe en su primera cita, introduce el recorrido y recibe una confirmación. Seguirán esperando en el recorrido hasta que reciban un recordatorio un día antes de la cita. Durante este tiempo, la misma persona podría registrarse para una segunda cita. El participante en el recorrido iniciará el mismo recorrido una segunda vez para la segunda cita. En otras palabras, la misma persona ahora está pasando por dos instancias del mismo recorrido.

En tal situación, si el participante en el recorrido cancela una de las citas, deberá salir solo del recorrido asociado a la cita cancelada. Por ejemplo, si cancelan la primera cita, deben salir del recorrido asociado a la primera cita pero continuar el recorrido asociado a la segunda. Si está utilizando eventos basados en Dataverse listos para usar, el comportamiento es automático y no es necesario realizar ninguna otra acción. Sin embargo, si está usando desencadenadores personalizados, debe configurar el desencadenador para identificar correctamente la instancia específica del recorrido a la que debe asociarse el desencadenador.

Usar el atributo bindingId para identificar de forma única cada instancia del recorrido

Cada desencadenador personalizado tiene un atributo opcional bindingId que se puede usar para vincular el desencadenador a instancias específicas de un recorrido. Cuando el atributo bindingId no esté presente, el desencadenador actuará sobre todas las instancias del recorrido en el que participa la persona. Por ejemplo, si la persona se ha inscrito en dos citas pero cancela una, y si el desencadenador de la cancelación no utilizó un bindingId, entonces esa persona saldrá de ambas instancias del recorrido. Si tiene intención de utilizar desencadenadores en recorridos repetibles, es muy recomendable que incluya un bindingId en el desencadenador.

Cuando el desencadenador que inicia un recorrido contiene un bindingId, ese ID se usa para identificar la instancia del recorrido. Para identificar la instancia del recorrido, cualquier otro evento deberá usar el mismo bindingId. El formato para bindingId es el siguiente: {entityType}/{entityId}. Por ejemplo, si su evento de inicio es una entidad Cita llamada Cita confirmada y tiene una entityId de “123,” bindingId sería Appointment/123. Su evento de salida Cita cancelada debe ser del mismo tipo de entidad y debe utilizar el mismo bindingId (Appointment/123) para identificar de forma exclusiva la instancia del recorrido.

Si solo usa desencadenadores personalizados en el recorrido, puede confiar en las cadenas únicas para identificar las instancias del recorrido.

Nota

Un desencadenador personalizado actuará sobre todas las instancias de un recorrido en el que alguien esté participando si falta el bindingId o si el enlace es para un tipo de entidad diferente.

Correlacionar a través de desencadenadores personalizados y eventos listos para usar o eventos empresariales personalizados

Si desea utilizar una combinación de desencadenadores personalizados y eventos de negocio listos para usar o personalizados, bindingId usa un formato especial para identificar de forma exclusiva la tabla y la fila de Dataverse. Por ejemplo, su recorrido podría comenzar con el evento listo para usar Oportunidad creada. A continuación, podría utilizar un desencadenador personalizado llamado Oportunidad ganada para el evento de salida. El desencadenador personalizado Oportunidad ganada debe contener un bindingId que sigue el patrón del evento Oportunidad creada para identificar de forma única cada instancia.

Siempre que se inicie un recorrido mediante un evento de negocio listo para usar o personalizado, cada instancia del recorrido se puede identificar de forma única por el patrón {entityType}/{unique row ID}. Este patrón debe incluirse en el atributo bindingId de cualquier desencadenador personalizado para correlacionarlo con los desencadenadores personalizados y con los eventos de negocio listos para usar o personalizados.

En el caso del desencadenador personalizado oportunidad ganada, el bindingId podría ser:

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

Si los desencadenadores personalizados siguen el patrón bindingId descrito anteriormente, pueden usarse para identificar la instancia exacta del recorrido, incluso cuando se usan con otros eventos empresariales. Cuando se implementa bindingId, actúa en todas las instancias del recorrido.

Nota

El enlace solo funciona en los mismos tipos de entidad.

Cómo agregar un bindingId a un desencadenador personalizado

Puede modificar el atributo bindingId en el fragmento de código para un desencadenador personalizado.

Para obtener acceso al fragmento de código de un desencadenador personalizado existente:

Vaya a Customer Insights - Journeys>Interacción>Desencadenadores.
Seleccione el desencadenador personalizado al que desea agregar un bindingId.
Seleccione Ir al fragmento de código.
Copie el fragmento de código y péguelo en el editor de código de su elección. Modifique el atributo bindingId siguiendo los formatos mencionados anteriormente (una cadena única si lo usa solo con desencadenadores personalizados o {table_name}/{unique row ID} cuando se correlaciona a través de desencadenadores personalizados y eventos listos para usar o eventos empresariales personalizados).

Puede seguir los mismos pasos para agregar un bindingId cuando crear un nuevo desencadenador personalizado.

Interpretación de bindingId

El carácter / está reservado. Siempre se presupone que bindingId está en un formato separado por / y se eliminará cualquier / inicial o final. Asimismo, no hay ningún / en el resultado. La aplicación siempre intenta interpretarlo de esta manera {entityType}/{entityId}.

Ejemplos:

"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 de comparación:

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