Usar IDs de associação para correlacionar gatilhos

Artigo
01/31/2024

Para jornadas repetíveis baseadas em gatilho, um cliente pode repetir uma jornada sem ter concluído a execução anterior. Por exemplo, considere uma jornada que envia confirmações e lembretes de compromissos. Quando uma pessoa se registra para seu primeiro compromisso, ela entra na jornada e recebe uma confirmação. Ela continuará aguardando na jornada até receber um lembrete um dia antes do compromisso. Durante esse período, a mesma pessoa pode se registrar para um segundo compromisso. O participante da jornada iniciará a mesma jornada pela segunda vez para o segundo compromisso. Em outras palavras, a mesma pessoa está agora passando por duas instâncias da mesma jornada.

Nesta situação, caso o participante da jornada cancele um dos compromissos, deverá sair apenas da jornada associada ao compromisso cancelado. Por exemplo, se ele cancelar o primeiro compromisso, deverá sair da jornada associada ao primeiro compromisso, mas continuar a jornada associada ao segundo compromisso. Se você estiver usando eventos baseados no Dataverse prontos para uso, o comportamento será automático, e nenhuma outra ação será necessária. No entanto, se você estiver usando gatilhos personalizados, deverá configurar o gatilho para identificar corretamente a instância específica da jornada à qual o gatilho deve estar associado.

Usar o atributo bindingId para identificar de forma exclusiva cada instância da jornada

Cada gatilho personalizado tem um atributo bindingId opcional que pode ser usado para associar o gatilho a instâncias específicas de uma jornada. Quando o atributo bindingId não estiver presente, o gatilho atuará em todas as instâncias da jornada da qual a pessoa está participando. Por exemplo, se a pessoa se registrou para dois compromissos, mas cancela um, e se o gatilho cancelado não usou um bindingId, essa pessoa sairá das duas instâncias da jornada. Se você pretende usar gatilhos em jornadas repetíveis, é altamente recomendável incluir um bindingId no gatilho.

Quando o gatilho que inicia uma jornada contém um bindingId, essa ID é usada para identificar a instância da jornada. Para identificar a instância da jornada, qualquer outro evento deve usar o mesmo bindingId. O formato para o bindingId é o seguinte: {entityType}/{entityId}. Por exemplo, se seu evento inicial for uma entidade Compromisso chamada Compromisso Confirmado e tem um entityId de "123", o bindingId será Appointment/123. Seu evento de saída Compromisso Cancelado deve ser do mesmo tipo de entidade e deve usar o mesmo bindingId (Appointment/123) para identificar de forma exclusiva a instância da jornada.

Se você estiver usando apenas gatilhos personalizados na jornada, poderá contar com cadeias de caracteres exclusivas para identificar as instâncias da jornada.

Nota

Um gatilho personalizado atuará em todas as instâncias de uma jornada da qual alguém está participando se o bindingId estiver ausente ou se a associação for para um tipo de entidade diferente.

Correlacionar entre gatilhos personalizados e eventos prontos para uso ou eventos de negócios personalizados

Se você quiser usar uma combinação de gatilhos personalizados e eventos de negócios personalizados ou prontos para uso, o bindingId usará a formatação especial para identificar de forma exclusiva a linha e a tabela do Dataverse. Por exemplo, sua jornada pode começar com o evento pronto para uso Oportunidade Criada. Você poderia então usar um gatilho personalizado chamado Oportunidade Ganha para o evento de saída. O gatilho personalizado Oportunidade Ganha deve conter um bindingId que segue o padrão do evento Oportunidade Criada para identificar de forma exclusiva cada instância.

Sempre que uma jornada é iniciada por um evento de negócios personalizado ou pronto para uso, cada instância da jornada pode ser identificada de forma exclusiva pelo padrão {entityType}/{unique row ID}. Este padrão deve ser incluído no atributo bindingId de qualquer gatilho personalizado para correlacionar entre gatilhos personalizados e eventos de negócios personalizados ou prontos para uso.

No caso do gatilho personalizado Oportunidade Ganha, o bindingId poderá ser:

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

Se os gatilhos personalizados seguirem o padrão bindingId descrito acima, poderão ser usados para identificar a instância exata da jornada, mesmo quando usados com outros eventos de negócios. Quando o bindingId for implementado, ele atuará em todas as instâncias da jornada.

Nota

A associação só funciona nos mesmos tipos de entidade.

Como adicionar um bindingId a um gatilho personalizado

Você pode modificar o atributo bindingId no trecho de código para um gatilho personalizado.

Para acessar o trecho de código de um gatilho personalizado existente:

Vá até Customer Insights - Journeys>Participação>Gatilhos.
Selecione o gatilho personalizado ao qual você deseja adicionar um bindingId.
Selecione Ir para o trecho de código.
Copie o trecho e cole-o no editor de código de sua escolha. Modifique o atributo bindingId seguindo os formatos mencionados acima (uma cadeia de caracteres exclusiva se você estiver usando apenas com gatilhos personalizados ou {table_name}/{unique row ID} ao correlacionar gatilhos personalizados e eventos prontos para uso ou eventos de negócios personalizados).

Você pode seguir as mesmas etapas para adicionar um bindingId ao criar um novo gatilho personalizado.

Interpretação do bindingId

O caractere / é reservado. Sempre é pressuposto que o bindingId está em um formato separado por / e qualquer / à esquerda ou à direita será removido. Além disso, não há / no resultado. O aplicativo sempre tenta interpretá-lo neste formato {entityType}/{entityId}.

Exemplos:

"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 comparação:

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