Ações de fluxo de trabalho personalizados
Os fluxos de trabalho do HubSpot são usados para automatizar processos comerciais e permitir que os clientes da HubSpot sejam mais eficientes. Você pode criar ações de fluxo de trabalho personalizadas para integrar seu serviço a fluxos de trabalho do HubSpot.
Primeiro, você definirá a ação personalizada, incluindo as entradas que precisam ser preenchidas pelo usuário que cria um fluxo de trabalho e o URL que será solicitado quando a ação personalizada for executada. Depois, quando os clientes instalarem seu aplicativo, eles poderão adicionar sua ação personalizada aos fluxos de trabalho. Quando esses fluxos de trabalho forem executados, as solicitações HTTPS serão enviadas ao URL configurado com a carga útil configurada. Neste artigo, saiba como:
- Definir sua ação personalizada
- Validar a origem da solicitação
- Configurar os payloads padrão
- Personalizar a carga útil
- Publicar sua ação personalizada
- Testar sua ação personalizada
- Executar sua ação personalizada
- Bloquear a execução da ação personalizada
- Concluir uma ação bloqueada
- Adicionar mensagens de execução personalizadas
Antes de começar, anote o seguinte:
- Você precisará de uma conta do desenvolvedor da HubSpot com um app da HubSpot. O logotipo do seu aplicativo será usado como o ícone da ação personalizada.
- Ao fazer solicitações para os endpoints de ação de fluxo de trabalho, você precisa incluir sua chave de conta do desenvolvedor do HubSpot no URL de solicitação. Por exemplo:
https://api.hubspot.com/automation/v4/actions/{appId}?hapikey={API_key}
Definir sua ação personalizada
Para criar uma ação de fluxo de trabalho personalizada, você precisará definir a ação usando os seguintes campos. Essa definição também especifica o formato das solicitações que vêm do HubSpot, bem como o tratamento das respostas do seu serviço.
- actionUrl: o URL para o qual uma solicitação HTTPS é enviada quando a ação é executada. O corpo da solicitação conterá informações sobre o usuário para o qual ação está sendo executada e quais valores foram inseridos para os campos de entrada.
- inputFields: definem o conjunto de valores válidos para as entradas das ações. Uma lista estática ou uma URL de webhook pode ser fornecida. Se uma URL do webhook for fornecida, as opções serão buscadas desse URL sempre que a ação for editada por um cliente na ferramenta Fluxos de trabalho. Estes são opcionais para cada campo.
- outputFields: os valores que a ação enviarpa que podem ser usado por ações posteriores no fluxo de trabalho. Uma ação personalizada pode ter zero, uma ou muitas saídas.
- executionRules: uma lista de definições que você pode especificar para revelar erros do seu serviço ao usuário que cria o fluxo de trabalho.
- labels: texto que descreve o que os campos de ação representam e o que a ação faz ao usuário. Rótulos em inglês são obrigatórios, mas os rótulos podem ser especificados em qualquer um dos seguintes idiomas permitidos: francês (
fr
), alemão (de
), japonês (ja
), espanhol (es
), português do Brasil (pt-br
) e holandês (nl
). A especificação para cada idioma inclui os seguintes campos:
- actionName: o nome da ação mostrado no painel Escolha uma ação no editor de fluxo de trabalho.
- actionDescription: uma descrição detalhada da ação exibida quando o usuário está configurando a ação personalizada.
- actionCardContent: uma descrição resumida exibida no cartão de ação.
- inputFieldLabels: um objeto que mapeia as definições de inputFields para os rótulos correspondentes que o usuário verá ao configurar a ação.
- outputFieldLabels: um objeto que mapeia as definições de outputFields para os rótulos correspondentes mostrados na ferramenta de fluxos de trabalho.
- inputFieldDescriptions: um objeto que mapeia as definições de inputFields para as descrições abaixo dos rótulos correspondentes.
- executionRules: um objeto que mapeia as definições de executionRules para mensagens de erro que serão exibidas ao usuário se eles configurarem errado uma ação personalizada. Isso permite especificar mensagens personalizadas para resultados de execução de ação no histórico do fluxo de trabalho.
Um exemplo de definição de ação básica é especificado abaixo:
Validar a origem da solicitação
As solicitações feitas para sua ação personalizada usarão a versão v2 do X-HubSpot-Signature. Saiba mais sobre como validar solicitações do HubSpot.
Payloads padrão
Há dois tipos de chamadas feitas para ações de fluxo de trabalho personalizado:
- Buscas de opção de campo: preencha uma lista de opções válidas quando um usuário está configurando um campo.
- Solicitações de execução de ação: feitas quando uma ação está sendo executada por um fluxo de trabalho que inclui a ação personalizada.
Buscas de opções de campo
As solicitações para buscar opções são feitas quando um usuário está configurando sua ação personalizada no fluxo de trabalho deles.
Formato de solicitação:
Formato de resposta esperado:
Para limitar o número de opções que retornam em uma busca, você pode definir um cursor de paginação, que dirá os fluxos de trabalho que mais opções podem ser carregadas. Se quiser que a lista de opções seja pesquisável, você pode retornar "searchable": true
para permitir que os resultados sejam filtrados por uma consulta de pesquisa.
Solicitações de execução de ação
As solicitações de execução são feitas quando um fluxo de trabalho está executando sua ação personalizada em relação a um objeto inscrito.
Formato de solicitação:
Personalizar a carga útil com funções
Você pode personalizar as solicitações feitas para sua ação personalizada configurando funções sem servidor para a ação personalizada.
Personalizar buscas de opções de campo
Há dois hooks para personalizar o ciclo de vida de busca de opção de campo:
- PRE_FETCH_OPTIONS: isso permite configurar a solicitação enviada do HubSpot.
- POST_FETCH_OPTIONS: isso permite transformar a resposta do seu serviço em um formato compreendido pelos fluxos de trabalho.
PRE_FETCH_OPTIONS
Formato do argumento de entrada de função:
Formato de saída de função esperada:
POST_FETCH_OPTIONS
Formato do argumento de entrada de função:
Formato de saída de função esperada:
Personalizar solicitações de execução
Há um hook no ciclo de vida de execução de ação, uma função PRE_ACTION_EXECUTION. Essa função permite configurar a solicitação enviada do HubSpot.
Formato do argumento de entrada de função:
Formato de saída de função esperada:
Publicar sua ação personalizada
Por padrão, sua ação personalizada é criada em um estado não publicado e estará visível no portal de desenvolvedor associado ao seu aplicativo da HubSpot. Para tornar sua ação personalizada visível aos clientes, atualize o sinalizador publicado
na definição da ação para true
.
Testar sua ação personalizada
Você pode testar sua ação personalizada ao criar um fluxo de trabalho na ferramenta de fluxos de trabalho e adicionar sua ação personalizada.
Executar sua ação personalizada
O sucesso de uma ação é determinado ao examinar o código de status que seu serviço retornou:
- Códigos de status 2xx: isso indica que a ação foi concluída com sucesso.
- Códigos de status 4xx: isso indica que a ação falhou.
- A exceção aqui são os códigos de status de taxa limitada
429
. Eles são retratados como novas tentativas e o cabeçalho Retry-After é respeitado.
- A exceção aqui são os códigos de status de taxa limitada
- Códigos de status 5xx: isso indica que houve um problema temporário com seu serviço e sua ação será enviada novamente em um momento posterior.
Bloquear a execução da ação personalizada
Ações personalizadas podem bloquear a execução do fluxo de trabalho. Em vez de executar a próxima ação no fluxo de trabalho após a ação personalizada depois de receber uma resposta “concluída” (código de status 2xx ou 4xx) do seu serviço, o fluxo de trabalho deixará de executar ("bloqueará") essa inscrição até você instruir o fluxo de trabalho para continuar.
Para bloquear uma ação personalizada, sua resposta de execução de ação precisa ter o seguinte formato:
Você pode optar por especificar um valor para o campo hs_default_expiration, após a qual a sua ação personalizada será considerada expirada. A execução do fluxo de trabalho será retomada e a ação que se segue à ação personalizada será executada, mesmo que você não tenha instruído o fluxo de trabalho para continuar.
Concluir uma execução bloqueada
Para concluir uma execução de ação personalizada bloqueada, use o endpoint a seguir: /callbacks/{appId}/{callbackId}/complete
.
O formato do corpo da solicitação é:
Adicionar mensagens de execução personalizadas
Especifique as regras na sua ação que determinam qual mensagem é exibida na página de histórico do fluxo de trabalho quando a ação for executada. As regras corresponderão aos valores de saída da sua ação. Esses valores de saída devem ser fornecidos no corpo de resposta do webhook, no seguinte formato:
O executionRules
será testado na ordem fornecida. Se houver várias correspondências, apenas a mensagem da primeira regra que corresponde será mostrada ao usuário.
A regra corresponde quando a saída de execução corresponde a um valor especificado na regra. Por exemplo, considere esse conjunto de executionRules
:
As seguintes correspondências ocorrerão:
{"errorCode": "ALREADY_EXISTS", "widgetName": "Test widget"}
: Isso corresponderia à primeira regra, poiserrorCode
é igual aALREADY_EXISTS
. Nesse caso, embora haja uma saídawidgetName
, ela não é usada na definição de regra, de forma que qualquer valor é permitido.{"errorCode": "WIDGET_SIZE", "sizeError": "TOO_SMALL"}
: Isso corresponderia à segunda regra, poisTOO_SMALL
é um dossizeError
correspondentes eerrorCode
éWIDGET_SIZE
.{"errorCode": "WIDGET_SIZE", "sizeError": "NOT_A_NUMBER"}
: Isso corresponderia à terceira regra, pois, emboraerrorCode
sejaWIDGET_SIZE
, osizeError
não corresponde a nenhum dos valores especificados pela segunda regra (TOO_SMALL
ouTOO_BIG
).
Esse mecanismo de correspondência permite especificar erros de fallback, para que você possa ter erros específicos para casos de erro importantes, mas retornar a mensagens de erro mais genéricas para erros menos comuns.
Example 1
A basic example with the following input fields, created for contact and deal workflows:
- a static input field
- a dropdown field with options
- a field whose value is a HubSpot owner
- a field whose value is pulled from a property (that the user creating the workflow selects) on the enrolled object.
Exemplo 2
A ação personalizada a seguir usa uma função sem servidor para transformar o payload que é enviado ao actionUrl configurado. Como nenhum objectTypes é especificado, essa ação estará disponível em todos os tipos de fluxos de trabalho.
Exemplo 3
A ação personalizada a seguir tem dependências de campo e opções que são buscadas de uma API. Como o tamanho do widget depende da cor do widget, o usuário não poderá inserir um valor para o tamanho do widget até que uma cor de widget seja escolhida.
O custo do widget também depende da cor do widget, mas é condicional no valor que o usuário seleciona para a cord o widget. O usuário não poderá inserir um valor para o custo do widget, a menos que a cor do widget seja selecionada.
Exemplo 4
O exemplo a seguir é uma ação personalizada de bloqueio. A API de retorno de chamada pode ser usada para informar a HubSpot para concluir a ação e fazer com que o objeto inscrito continue para a próxima ação no fluxo de trabalho.
Você não precisará especificar que a ação bloqueia no momento de criação da ação. Isso será determinado pela resposta do actionUrl configurado.
Thank you for your feedback, it means a lot to us.