Campos no Bitrix24 são as células do card de um lead, negócio, contato, empresa ou processo inteligente: os de sistema ("Valor", "Etapa") o próprio Bitrix24 cria, os personalizados você adiciona para seus dados. De como os campos funcionam depende todo o resto: filtros, relatórios, automação, geração de documentos. Vamos ver os tipos, a obrigatoriedade, os valores múltiplos e — o principal, que não está na ajuda — como os robôs e processos de negócios trabalham com os campos.

Que tipos de campos personalizados existem no Bitrix24?

Você pode criar um campo direto do card ("Criar campo", na parte de baixo) ou nas configurações do CRM → Configurações de campos. Os tipos principais: string, número, sim/não, data/hora, lista, link, endereço, dinheiro, arquivo, vínculo com um funcionário ou com elementos do CRM. Escolha o tipo por como o campo será usado depois: por lista é cômodo filtrar e montar relatórios, por string não; "dinheiro" armazena a moeda junto com o valor; "vínculo com CRM" torna o campo uma ligação clicável, pela qual depois pode passar a automação. Renomear o campo dá sempre, mas o tipo, depois de criado, não muda — em caso de erro, o campo é recriado e os dados são migrados.

Como tornar um campo obrigatório — e por que "obrigatório por etapa" é melhor?

A obrigatoriedade é configurada no card do campo. Uma obrigatoriedade rígida "sempre" atrapalha os vendedores: na criação do lead ainda não há dados, e o campo é preenchido com lixo, só para conseguir salvar. A técnica certa é a obrigatoriedade por etapa: o campo "Orçamento" torna-se obrigatório ao passar para "Negociação", "Causa de recusa" — só na etapa "Perdida". Assim o card vai sendo preenchido conforme avança pelo funil. A falha desse mecanismo: ele só verifica as mudanças manuais — dados que chegaram por importação ou pela API contornam a verificação. O seguro está na automação: o robô «Verificar se o campo está preenchido» na etapa devolve S/N, e o processo ou deixa o negócio seguir adiante, ou cria uma tarefa para o vendedor completar o preenchimento.

O que há de especial nos campos múltiplos?

Um campo múltiplo armazena vários valores de uma vez — telefones, e-mails, tags. Duas pegadinhas. Nos processos de negócios, um valor múltiplo é inserido como uma lista separada por vírgula: para trabalhar com os itens separadamente, primeiro ele é decomposto (para strings — o robô «Dividir string por separador»). E ao atualizar via API ou robôs, os campos múltiplos não são complementados, e sim sobrescritos por inteiro — se você gravar um único valor, os demais somem. Por isso o cenário "adicionar uma tag" sempre tem a forma de "ler os valores atuais → adicionar o novo → gravar tudo de volta".

Como preencher, limpar e transferir campos automaticamente?

Quatro operações resolvem quase todos os cenários. Gravar um valor — a ação nativa "Alterar documento" ou os robôs de atualização de entidades. Limpar um campo de forma nativa é inconveniente (uma string vazia nem sempre é igual a "vazio") — o robô «Limpar campo» zera o valor corretamente para qualquer tipo. Transferir um valor entre entidades relacionadas — o par de robôs «Obter valor de campo de entidade relacionada» e «Gravar valor em campo de entidade relacionada»: por exemplo, ao mudar a etapa do negócio, ler a cidade do contato e gravá-la no negócio para fins de relatório, ou o contrário — empurrar o status do negócio para o card da empresa. Verificar o preenchimento antes de gerar um documento — «Verificar se o campo está preenchido», para que não vão dados cadastrais vazios para o contrato.

Erros frequentes ao trabalhar com campos

Campo duplicado: em vez de procurar um campo existente, cria-se um novo com nome parecido, e os dados se espalham — uma vez por trimestre, faça uma revisão das configurações de campos. String em vez de lista: filtros e relatórios por texto livre não funcionam ("São Paulo", "são paulo", "SP" são três valores diferentes); onde os valores se repetem, é preciso uma lista. Obrigatoriedade "sempre" em vez de "por etapa" — sobre ela, acima. E por último: verificação de preenchimento só na interface, sem o seguro no processo — automação, importação e API a contornam.

Conclusão

Os campos são o alicerce do CRM: o tipo certo, a obrigatoriedade por etapa e o preenchimento automático transformam o card numa fonte de dados para documentos e relatórios, e não num formulário para preencher por preencher. Os robôs para trabalhar com campos — limpeza, verificação, transferência entre entidades — estão reunidos no catálogo da Roboteka; a instalação é gratuita, e eles aparecem no designer ao lado dos nativos.