# 12/03/2026 #### **Atendimento** #### 👥 **Correção na exibição de atendimento ativo** Realizamos ajustes no fluxo de **início de atendimento** para melhorar a visibilidade quando um contato já possui um atendimento em andamento. 🔧 **O que estava acontecendo?** **Atendente responsável não exibido:** Ao abrir o modal **“Iniciar atendimento”**, quando o contato já possuía um atendimento ativo, o sistema exibia apenas **canal e equipe**, sem mostrar **o atendente responsável**. **Falta de aviso para atendentes restritos:** Para **atendentes restritos**, o sistema não exibia o aviso de atendimento em andamento durante a seleção do canal. O alerta só aparecia após tentar iniciar o atendimento. ✅ **O que foi corrigido?** **Exibição completa das informações:**\ O modal **“Iniciar atendimento”** agora exibe: * Canal * Equipe * **Atendente responsável** **Aviso também para atendentes restritos:** Atendentes restritos agora também visualizam o aviso de atendimento em andamento, seguindo o mesmo padrão dos demais usuários.
#### 💳 **Ajuste no campo “Complemento” do endereço** Realizamos uma correção no preenchimento de endereço durante a **configuração de solicitações de pagamento**. 🔧 **O que estava acontecendo?** Após informar o **CEP**, o sistema preenchia automaticamente os campos de endereço. Porém, em alguns casos, o campo **“Complemento”** também era preenchido automaticamente e **ficava bloqueado para edição**. Esse comportamento ocorria apenas para **determinados CEPs**, impedindo que o usuário **alterasse ou removesse a informação**, o que podia gerar dados incorretos no endereço do contato. ✅ **O que foi corrigido?** O campo **“Complemento”** agora permanece **habilitado para edição**, permitindo que o usuário **edite ou limpe o conteúdo** sempre que necessário.
#### **CRM** #### 📊 **Ajuste na exibição de contatos em painéis com carteirização** Realizamos ajustes na forma como os contatos **são exibidos nos cards dos painéis** quando a conta utiliza **carteirização com restrição de acesso aos contatos**. 🔧 **O que estava acontecendo?** Em painéis configurados como **Individual**, supervisores conseguiam visualizar **todos os cards da equipe**. Porém, quando a conta possuía **carteirização ativa com a opção “Restringir acesso aos contatos”**, ocorria um conflito de regras. Se o supervisor pertencesse a uma carteira e o **contato do card não estivesse na mesma carteira**, o sistema **ocultava completamente os dados do contato**, exibindo apenas o card sem identificação. ✅ **O que foi ajustado?** **Identificação do contato no card:**\ Quando o supervisor visualizar um card cujo contato **não pertence à sua carteira**, o sistema agora exibirá **o nome do contato**. **Ações bloqueadas por privacidade:**\ Nesse cenário, todas as ações do contato ficam **desabilitadas**, incluindo: * Ações Personalizadas * Acessar o atendimento * Agendar mensagem * Acessar detalhes do contato
#### 📤 **Correção na exportação de contatos** Realizamos um ajuste na **exportação de contatos** para garantir a integridade dos dados em campos personalizados. 🔧 **O que estava acontecendo?** Em campos personalizados do tipo **texto curto** ou **texto longo**, quando o valor começava com **zero à esquerda**, esse zero era removido durante a exportação. Exemplo: * Valor cadastrado: **00412** * Valor exportado: **412** Esse comportamento alterava o valor original informado no sistema, gerando inconsistências nos dados exportados. ✅ **O que foi corrigido?** Agora, campos do tipo **texto** são exportados **exatamente como foram cadastrados**, preservando qualquer **zero à esquerda** e evitando conversões automáticas de valor. #### **Contas** #### 🔎 **Correção na busca ao selecionar conta** Realizamos um ajuste no campo de **pesquisa da tela “Selecione uma conta”**. 🔧 **O que estava acontecendo?** Ao pesquisar por um **nome de conta inexistente**, apagar o texto digitado e tentar pesquisar novamente, o sistema **não retornava mais resultados**. Para que a busca voltasse a funcionar, era necessário **limpar o cache da aplicação**, o que prejudicava a experiência do usuário. ✅ **O que foi corrigido?** O comportamento da busca foi ajustado para funcionar corretamente em todos os cenários: * Quando **nenhuma conta for encontrada**, será exibida a mensagem: **“Nenhuma conta encontrada”**. * Ao **limpar o campo de busca**, todas as contas disponíveis voltam a ser exibidas. * Ao **digitar um novo termo**, o sistema exibirá apenas as contas correspondentes à pesquisa.
#### Grupos #### 👥 **Conclusão automática de atendimentos em grupos** Realizamos um ajuste no tratamento de **grupos de WhatsApp** quando o canal de atendimento sai do grupo. 🔧 **O que estava acontecendo?** Quando o número era removido ou saía de um grupo pelo **dispositivo móvel**, o grupo continuava aparecendo na plataforma e **não havia uma forma de removê-lo**, pois o sistema não recebia o evento necessário para encerrar o atendimento automaticamente. ✅ **O que foi corrigido?** Agora, quando a plataforma **receber o webhook informando que o canal saiu do grupo**, o atendimento relacionado será **concluído automaticamente**. #### 👥 **Ajuste na identificação de participantes em grupos (Z-API)** Realizamos melhorias no tratamento de **contatos sincronizados a partir de grupos via Z-API**, garantindo melhor identificação e evitando confusão na base de contatos. 🔧 **O que estava acontecendo?** **Nome genérico “invite”:** Em alguns webhooks recebidos da Z-API, devido a restrições de privacidade, o nome do contato chegava como **“invite”**. Isso fazia com que diversos atendimentos e registros no CRM fossem criados com esse mesmo nome, dificultando a identificação de quem estava participando da conversa. **Fragmentação de contatos:** Em certos casos, quando um participante enviava mensagem a partir de um **número privado (LID)** dentro de um grupo, o sistema criava um **novo contato temporário**, mesmo quando aquele usuário já possuía cadastro na plataforma. ✅ **O que foi ajustado?** **Tratamento do nome “invite”:** Quando o webhook retornar o nome **“invite”**, o sistema agora ignora esse valor e aplica uma **nomenclatura padrão**: * Para números identificáveis: **\[NOVO] (XX) X XXXX-XXXX** * Para números privados (LID): **\[NOVO] {ID}@lid**
**Atualização automática do contato:** Quando esse participante enviar uma mensagem com **nome válido**, o sistema atualiza automaticamente o cadastro do contato. **Vinculação com contato existente:** Se o sistema identificar que o **telefone ou LID já pertence a um contato existente**, o participante da conversa será **substituído pelo contato correto** no atendimento.
#### **Chatbot** #### 🤖 **Correção no tempo de espera para envio de resposta** Realizamos um ajuste no funcionamento da opção **“Tempo de espera para envio da resposta”** nos chatbots. 🔧 **O que estava acontecendo?** Mesmo quando um tempo era configurado no chatbot, o sistema **não respeitava o valor definido** e aguardava apenas **3 segundos** antes de enviar a resposta. Com isso, o tempo parametrizado no fluxo era desconsiderado. ✅ **O que foi corrigido?** O chatbot agora **respeita corretamente o tempo configurado** (de 1 a 40 segundos) antes de enviar a resposta. Além disso: * Se o contato enviar **novas mensagens durante a espera**, o tempo é **reiniciado**. * A resposta será enviada **somente após o período completo de inatividade** configurado.
#### 🤖 **Correção ao copiar condicionais entre contas** Realizamos um ajuste no comportamento de **cópia e colagem de nós condicionais** entre contas. 🔧 **O que estava acontecendo?** Ao copiar um nó de **condicional** que utilizava o caso **“Etiqueta do contato”** de uma conta e colá-lo em **outra conta**, o sistema **não permitia adicionar novas etiquetas** no nó colado. ✅ **O que foi corrigido?** Agora, ao colar o nó em outra conta: * As **etiquetas da conta de origem não são mantidas**; * O nó passa a considerar **apenas as etiquetas da conta de destino**; * Novas etiquetas podem ser **adicionadas normalmente** no nó condicional.
#### 🤖**Aviso ao copiar nós com configurações entre contas** Implementamos uma melhoria no comportamento de **nós que utilizam configurações específicas da conta** quando são copiados e colados entre contas diferentes. 🔧 **O que acontecia antes?** Ao copiar um nó com configurações vinculadas à **conta de origem** (como parâmetros específicos) e colá-lo em **outra conta**, essas configurações não eram válidas, mas o sistema **não indicava claramente que era necessário reconfigurá-las**. Isso podia gerar confusão e falhas na execução do fluxo. ✅ **O que foi implementado?** Agora, ao colar esses nós em outra conta, o sistema **exibe um aviso indicando que as configurações precisam ser definidas novamente**. O aviso orienta o usuário a **inserir os dados correspondentes da nova conta**, garantindo que o nó seja configurado corretamente antes de ser utilizado.
#### **API** #### 💬 **Inclusão de campos na listagem de conversas** Realizamos um ajuste nas rotas de **listagem de conversas da API**. 🔧 **O que estava acontecendo?** Ao listar conversas, tanto **por ID quanto na listagem geral**, os campos **lastMessageOut** e **lastMessageIn** não estavam sendo retornados na resposta da API. Isso dificultava as integrações que dependem dessas informações para identificar **a última mensagem enviada pelo usuário ou pelo contato**. Embora esses dados já fossem enviados corretamente **via webhooks**, eles **não estavam disponíveis nas rotas de consulta de conversas**. ✅ **O que foi ajustado?** Os campos **lastMessageOut** e **lastMessageIn** agora também são retornados nas **rotas de listagem de conversas**, permitindo que integrações acessem essas informações diretamente via API.
#### 👤 **Correção na associação de carteira ao atualizar contatos** Realizamos um ajuste no endpoint **Criar contato** quando utilizado no modo **upsert** (atualização de contatos existentes). 🔧 **O que estava acontecendo?** Ao atualizar um contato existente via **upsert** e informar uma **carteira (portfolio)**, a associação **não era realizada**. Apesar de os demais campos da requisição serem atualizados corretamente, o campo de **carteira** permanecia inalterado.\ Esse comportamento ocorria apenas na **atualização de contatos**. Na criação de novos contatos, a associação com a carteira funcionava normalmente. ✅ **O que foi corrigido?** Agora, ao utilizar o endpoint para **atualizar um contato existente**, informando **portfolioIds** e incluindo **Portfolio** no campo **upsertFields**, o sistema: * Atualiza corretamente o contato; * Associa o contato à **carteira informada**; * Retorna na resposta os campos **portfolioIds** e **portfolioNames** com os dados da carteira vinculada.