Um cenário do Make que passou meses movendo registros em silêncio quebra de duas maneiras: o histórico se enche de módulos vermelhos com uma linha de erro, ou ele emudece e ninguém percebe por uma semana. Nenhuma das duas é acaso. Quase toda falha entre o Make e o Bitrix24 (Alaio) vem dos mesmos quatro lugares: a conexão, o gatilho que consulta por sondagem, os códigos de campo e o passo de busca que falta antes de criar um registro.

Por que a conexão cai depois de meses funcionando?

O Make chega ao portal por meio de um aplicativo: o instalado a partir do Market, ou um aplicativo local que você mesmo registrou com client id, secret e uma URL de handler apontando para o canal de retorno do Make. Duas coisas congelam nesse momento: as permissões que o aplicativo pode usar e o funcionário cuja sessão o autorizou. Basta alguém remover o aplicativo do portal, desativar esse funcionário ou cortar permissões para que todos os módulos de todos os cenários caiam de uma vez, com erro de autorização e não de dados.

O texto do erro diz qual lado consertar. Se a resposta afirma que o aplicativo não está instalado, do lado do portal ele sumiu, e reautorizar no Make não muda nada enquanto ele não voltar. Um token inválido ou expirado significa outra coisa: o ciclo de renovação se rompeu e a conexão precisa ser autorizada de novo. Mexer no módulo que falha não resolve nenhum dos dois casos.

Por que o módulo Watch perde registros?

Porque ele consulta por sondagem. Watch Deals, Watch Leads e Watch Tasks não são assinatura de eventos: no ritmo do agendamento do cenário, eles perguntam ao portal o que apareceu desde a última vez. O que enxergam depende de três ajustes: o intervalo, se o filtro roda pela data de criação ou de modificação, e quantos itens um ciclo pode levar — um campo que vem com um valor padrão bem pequeno. Uma importação em massa de duzentos leads, portanto, pinga aos poucos até a fila alcançar o atraso, e isso se lê exatamente como um gatilho que perdeu registros. Filtrar por data de criação nunca percebe edições; filtrar por data de modificação relê o que o próprio cenário acabou de gravar.

A sondagem custa dos dois lados: a execução acontece tendo mudado algo ou não, e cada ciclo gasta chamadas REST do portal. O portal admite algo como um par de chamadas por segundo, então um laço sobre algumas centenas de registros sem pausas esbarra no limite — e esse teto é contado por portal, não por cenário, de modo que o segundo cenário o herda.

Quando a reação precisa ser imediata, deixe o portal empurrar: um webhook de saída apontando para um módulo Custom webhook, ou um passo dentro do próprio processo. A Requisição HTTP GET/POST dispara exatamente no ponto do processo que você escolheu e envia só o que você decidiu enviar; Construir JSON a partir de campos monta o corpo sem escapar aspas na mão; Extrair valor de JSON por caminho traz a resposta de volta para o processo — mais sobre isso no texto sobre JSON em processos de negócio. Onde perder uma entrega sai caro — um pedido que entra em produção, um documento que sai para assinatura — o Webhook tolerante a falhas repete as tentativas no próprio ritmo em vez de desistir na primeira. As duas direções estão em diagnóstico de webhooks.

Por que Create e Update falham se os dados parecem certos?

Quase sempre por causa dos códigos de campo. Campos personalizados viajam com o código UF_CRM_…, não com o rótulo que aparece no cartão; etapas e funis vão por identificador; telefone e e-mail são campos múltiplos, então uma string simples chega no formato errado ou silenciosamente não faz nada. Além disso, uma etapa pode exigir campos que um instante antes eram opcionais: por isso um registro que uma pessoa salva à mão volta recusado pelo módulo. Antes de culpar o módulo, confira a carga contra os códigos reais: o caso mais comum está destrinchado em atualizar um campo de negócio pela API. Métodos sem módulo próprio passam pelo Make an API Call, que segue as mesmas regras sem nenhum mapeamento de campos.

De onde vêm as duplicatas depois de uma reexecução?

Do fato de que módulos Create criam. Rode de novo um lote que morreu no meio e tudo o que veio antes da falha aterrissa uma segunda vez: nada na carga diz «este já existe». O formato que sobrevive a repetições é buscar, ramificar e só então criar ou atualizar, e o lugar mais barato para isso é o portal: Encontrar negócio por condição e Encontrar contato por telefone/e-mail devolvem o registro existente ao processo, de modo que a ramificação acontece antes de qualquer gravação. O que já se acumulou é outra tarefa — veja duplicatas no Bitrix24.

Qual metade do cenário não deveria estar no Make?

A metade que nunca sai do portal. Mover uma etapa, preencher um campo, abrir uma tarefa, ramificar por condição: levar isso para um cenário externo compra uma ida e volta pela rede, um segundo lugar para depurar e uma cota para vigiar, e nada além disso. A divisão que se sustenta é: o Make cuida dos sistemas de fora, o portal cuida dos próprios registros, e entre os dois existe uma chamada. O lado interno é a configuração de regras de automação de sempre; e se foi justamente esse passo interno que nunca começou, ajuda a lista de por que as regras não disparam. A mesma conta aplicada aos vizinhos está em conectores versus automação dentro do portal e em como conectar o Bitrix24 ao n8n.

Por onde seguir

Separe o cenário em duas listas: módulos que tocam sistemas fora do portal e módulos que tocam apenas registros do portal. Mova a segunda lista para dentro, e o que sobra costuma ser uma conexão e um webhook — pequeno o bastante para se manter vivo. Os blocos do lado interno estão no catálogo de robôs, e se faltar o que você precisa, descreva a tarefa: a Roboteka cria de graça as regras de automação que faltam e publica na biblioteca comum.