Defina os campos obrigatórios no HubSpot no ponto em que alguém possa fornecer com veracidade a informação necessária para a decisão seguinte. Para uma mudança manual da fase do negócio, utilize a definição da fase relevante e teste valores em falta e preenchidos antes da implementação. A entrada automatizada exige uma verificação separada, porque a regra configurada e a via de software usada para enviar os dados podem alterar o resultado.
Um negócio está pronto para avançar, mas o ecrã pede dados que ninguém conhece ainda. Noutro ponto, um registo chega ao colega seguinte com um campo vazio. Começamos por escrever qual é a decisão que precisa dessa informação. Este guia trata dos requisitos das fases do negócio; um formulário do site ou um painel de criação de registos tem definições próprias.
Que regra de campos obrigatórios no HubSpot vai alterar?
Identifique quando a informação é necessária antes de escolher uma definição. O guia de pipelines do HubSpot distingue entre mostrar um campo numa fase e tornar obrigatório o seu valor. O guia do formulário de criação descreve requisitos para a criação manual de registos. Estes controlos aplicam-se em momentos diferentes: a primeira entrada e uma transferência posterior podem exigir informações distintas.
Uma propriedade é um campo de um registo. Um pipeline é a sequência de fases que um negócio percorre. Utilize as distinções seguintes quando perguntar ao administrador o que já está configurado.
| Controlo | Pergunta a que responde |
|---|---|
| Requisito do formulário de criação | O que tem de ser introduzido quando alguém cria manualmente o registo? |
| Propriedade condicional de fase | O que deve aparecer ou ser obrigatório quando alguém cria manualmente um registo nesta fase ou o move para ela? |
| Lógica condicional de propriedades | Que outros campos devem ser pedidos quando uma propriedade de controlo cumpre uma condição? |
| Opção Required do formulário do site | O que tem um visitante de preencher para enviar este formulário? |
| Validação do valor | O valor introduzido cumpre uma regra suportada de formato ou intervalo? |
O HubSpot documenta estes elementos como controlos separados, cada um com disponibilidade e âmbito próprios. O aparecimento de um campo no ecrã não prova que este bloqueia a gravação. Mesmo um campo preenchido precisa de conter uma resposta com significado.
Decida o que o colega seguinte precisa de saber
Escreva a decisão pretendida em linguagem corrente e identifique depois a informação necessária para a tomar. Para cada campo obrigatório proposto, registe quem utiliza a resposta, quando esta pode ser conhecida e o que um valor útil explica. Se ninguém conseguir explicar a sua utilização, mantenha o requisito em análise.
Por exemplo, um colega pode precisar de uma descrição clara do que o potencial cliente pediu antes de preparar uma proposta. Acorde o que essa descrição deve conter. Pedir mais cedo uma resposta baseada numa suposição deixaria a decisão por resolver, mesmo que o campo contivesse texto.
Mantenha uma forma explícita de tratar informação que ainda é desconhecida. Peça à pessoa responsável para rever a fase ou o momento do requisito. Preserve os dados existentes e verifique as dependências antes de alterar uma regra; eliminar campos ou adicionar valores fictícios não faz parte deste procedimento.
Se registos contraditórios tornarem incerto a que pessoa pertence a informação que está a alterar, resolva primeiro essa questão de identidade. O nosso guia separado para rever contactos duplicados no HubSpot explica por que motivo uma fusão exige verificações próprias.
Defina o campo para a fase pretendida do negócio
Siga o procedimento de fase documentado pelo HubSpot com um administrador autorizado já existente. O guia de pipelines exige a permissão Edit property settings e uma propriedade dependente existente que possa ser editada. Confirme a subscrição e a disponibilidade do objeto na conta concreta antes de avançar; a ausência de um controlo é motivo para consultar o administrador, não para comprar um plano superior com base numa suposição.
Antes de alterar qualquer elemento, registe a regra anterior e acorde como a repor. Prepare registos de teste aprovados num ambiente em que as verificações não possam contactar clientes, acionar campanhas ou faturação, nem alterar relatórios reais. Se esse isolamento não estiver disponível, peça ao administrador que o prepare antes dos testes.
- Abra Settings, depois Data Management e Objects. Selecione o objeto relevante e o respetivo separador Pipelines.
- Selecione o pipeline pretendido. Na linha da fase de destino, abra Add rule em Conditional logic rules.
- Confirme a condição da fase e adicione a propriedade dependente. Selecione Required quando a ausência do valor deva impedir a ação manual abrangida.
- Selecione Save logic e registe exatamente a fase e a propriedade abrangidas pela regra.
Segundo o mesmo guia, as propriedades só de leitura, incluindo valores calculados e de pontuação, não podem ser utilizadas como propriedades de fase. Se o campo não estiver disponível, verifique a sua definição antes de criar outro campo com o mesmo objetivo.
Teste valores em falta e preenchidos antes da implementação
Teste a condição acordada com um registo sintético aprovado e anote o resultado esperado antes de executar a ação. Comece com o campo selecionado vazio e introduza depois um valor de teste com significado. Após reabrir o registo, inspecione a fase e o campo guardados. O resultado aplica-se apenas à condição, pessoa ou sistema e via que efetivamente testou.
- Tente executar a mudança manual de fase abrangida sem o valor dependente. Registe se o aviso relevante impede a gravação; um resultado inesperado continua a ser uma questão em aberto.
- Introduza um valor de teste claramente fictício, mas que respeite o significado acordado. Repita a ação e inspecione o que foi guardado.
- Teste separadamente uma fase fora da condição configurada, para tornar visível um requisito inesperadamente abrangente.
- Mantenha juntos o estado inicial, o resultado esperado, o resultado observado e a pessoa responsável por qualquer divergência.
Utilize o mesmo registo com cuidado, para evitar que um valor anteriormente guardado invalide um teste posterior de valor em falta. Peça ao administrador para preparar o estado inicial pretendido. A conclusão de uma interação no ecrã não constitui, por si só, prova do resultado guardado.
Verifique as vias que escrevem nos seus registos
O sucesso manual não demonstra como um workflow, uma importação, um formulário do site ou um conector trata o requisito. Um workflow é um processo automatizado dentro do HubSpot; uma API é a interface de software que um conector pode utilizar para escrever registos. O guia de propriedades condicionais do HubSpot exclui as edições por workflow do âmbito manual que documenta.
O changelog para programadores descreve a aplicação de propriedades obrigatórias condicionais configuradas e de requisitos de criação de registos na versão 2026-09 da API, sendo os requisitos de criação aplicáveis a pedidos POST. A via e a versão efetivamente utilizadas por um conector são relevantes.
Peça à pessoa responsável por cada via utilizada que identifique a regra e execute verificações aprovadas com dados em falta e completos. Não precisa de adicionar uma importação ou integração apenas para a testar. Mantenha um resultado separado para cada via existente, incluindo a mensagem devolvida e, quando for possível inspecioná-los, a fase e o valor guardados.
O changelog da API desaconselha repetir sem alterações o mesmo pedido rejeitado. Se uma escrita for rejeitada, preserve o pedido de informação através do seu processo aprovado e atribua a correção a uma pessoa de forma visível. Investigue a informação ou o mapeamento em falta antes de voltar a testar; não enfraqueça a regra apenas para fazer o pedido passar.
Nas nossas verificações de configuração e integração de CRM, associamos cada decisão sobre um campo às vias que escrevem nele. Se uma fase também alimentar a medição de publicidade paga, acorde o significado desse estado antes de o utilizar nesse contexto. O preenchimento de um campo não prova uma venda nem um resultado publicitário válido.
O que deve rever após a alteração?
Reveja o requisito perante a decisão que este devia apoiar. Compare o mesmo tipo de registos e vias antes e depois da alteração. Mantenha visíveis as vias não testadas, repita as verificações afetadas após uma alteração relevante de uma regra ou integração e preserve os limites originais de um teste manual bem-sucedido.
- Os valores são úteis para a decisão do colega seguinte ou as pessoas introduzem valores de preenchimento?
- A pessoa responsável consegue ver e corrigir escritas incompletas ou rejeitadas?
- Uma resposta honestamente desconhecida continua visível com uma ação seguinte acordada?
- Que fases, intervenientes ou vias de escrita ainda não têm um resultado registado?
Estas observações apoiam a decisão de configuração seguinte. Não demonstram uma melhoria das vendas nem provam que todos os valores introduzidos são verdadeiros.
Onde intervimos
Começamos pelo objetivo do campo, pela fase em que a informação passa a ser conhecida e pela pessoa que precisa dela. Associamos essa decisão à definição existente e a uma verificação de cada via utilizada. Registe a fase problemática, a informação em falta e todas as vias que escrevem no registo. Não precisa de exportações de dados de clientes nem de credenciais da conta para definir esta questão.
