Power Query: como coluna condicional e personalizada

A lógica do seu relatório está no lugar errado com mais frequência do que você imagina#

Boa parte dos problemas que a gente encontra em projetos de Power BI não está no DAX nem no visual, está antes, na hora de preparar os dados. Alguém precisou classificar um cliente como ativo ou inativo, calcular uma faixa de faturamento ou tratar um campo vazio, e resolveu tudo no lugar mais difícil possível. É aí que entra o assunto deste guia: em Power Query, coluna condicional e personalizada são as duas ferramentas que resolvem quase toda transformação de linha, e saber quando usar cada uma economiza horas de retrabalho.

Neste artigo eu mostro o passo a passo das duas, os operadores lógicos que você vai usar de verdade, como tratar nulos sem quebrar a consulta, e a decisão que mais confunde quem começa: criar a lógica na consulta ou deixar para o DAX. Tudo com código M, do jeito que a gente faz nos projetos aqui na Fynx. Para o panorama geral da ferramenta, vale ler antes o nosso guia completo de Power BI para empresas no Brasil.

Coluna condicional é a interface para quem não quer escrever M#

A coluna condicional é o caminho visual. Você vai na aba Adicionar Coluna, clica em Coluna Condicional e monta a regra por menus: se determinada coluna for igual a um valor, então retorna outro valor, senão retorna um terceiro. É um construtor de if / then / else com formulário, pensado para quem não quer digitar código.

O detalhe importante, e que quase ninguém percebe no começo, é que essa interface não faz mágica. Ela apenas gera, por baixo, uma expressão if / then / else na linguagem M. Você confirma isso abrindo a barra de fórmulas depois de criar a coluna: o que o formulário produz é exatamente o que você escreveria à mão. Ou seja, a coluna condicional é uma coluna personalizada com rodinhas de apoio.

Veja um exemplo. Suponha uma tabela de pedidos com a coluna Valor e você quer classificar cada linha em uma faixa. Pela interface, você monta três condições. O M gerado fica assim:

if [Valor] >= 10000 then "Alto"
else if [Valor] >= 3000 then "Médio"
else "Baixo"

Simples e legível. Para regras de igualdade, comparação numérica e alguns "está contido em", a coluna condicional resolve com rapidez e sem risco de erro de sintaxe.

Passo a passo da coluna condicional#

1. No Editor do Power Query, selecione a consulta e vá na aba Adicionar Coluna.
2. Clique em Coluna Condicional.
3. Dê um nome claro à nova coluna, por exemplo Faixa de Valor.
4. Na primeira cláusula, escolha a coluna base, o operador (igual a, maior que, começa com, etc.) e o valor de comparação. Defina o resultado no campo Saída.
5. Clique em Adicionar Cláusula para cada faixa adicional. A ordem importa: o Power Query avalia de cima para baixo e para na primeira condição verdadeira.
6. Preencha o campo Senão com o valor padrão para quando nenhuma condição bater.
7. Confirme e revise a fórmula gerada na barra de fórmulas.

O passo 5 é onde mais gente tropeça. Como a avaliação é sequencial, se você colocar a faixa "Baixo" antes de "Alto", todo mundo cai no "Baixo". Pense sempre da condição mais restritiva para a mais ampla.

Coluna personalizada é quando a regra cresce e a interface não acompanha#

A coluna condicional cobre o feijão com arroz, mas ela tem teto. No momento em que a regra precisa combinar duas colunas, aplicar uma função de texto, fazer uma conta ou testar mais de uma condição ao mesmo tempo, a interface trava. Aí você vai em Adicionar Coluna e escolhe Coluna Personalizada, que abre um campo livre para escrever fórmula M.

É aqui que a linguagem começa a aparecer de verdade. E o primeiro aviso que eu sempre dou nos treinamentos: a linguagem M diferencia maiúsculas e minúsculas. if funciona, IF não. Text.Upper funciona, text.upper não. O nome da coluna [Cliente] é diferente de [cliente]. Esse é um dos erros mais comuns de quem vem do Excel ou do DAX, onde essa distinção não existe do mesmo jeito.

Um exemplo de coluna personalizada que a condicional não daria conta: classificar o pedido como "Prioritário" quando o valor passar de 10.000 e o cliente for da região Sul.

if [Valor] > 10000 and [Regiao] = "Sul" then "Prioritário"
else "Normal"

Repare no and. Combinar condições é o motivo número um para sair da interface e ir para a coluna personalizada.

Os operadores lógicos que você vai usar todo dia#

Antes de escrever regras mais longas, vale fixar o vocabulário. A tabela abaixo reúne os operadores mais frequentes em M para colunas condicionais e personalizadas.

Operador	O que faz	Exemplo
=	Igualdade	[Status] = "Pago"
<>	Diferente de	[Status] <> "Cancelado"
> >= < <=	Comparações numéricas ou de data	[Valor] >= 3000
and	Verdadeiro quando as duas condições são verdadeiras	[Valor] > 0 and [Ativo] = true
or	Verdadeiro quando pelo menos uma é verdadeira	[UF] = "SP" or [UF] = "RJ"
not	Inverte o resultado lógico	not ([Status] = "Cancelado")

Duas observações que evitam dor de cabeça. Primeiro, os operadores lógicos em M são as palavras and, or e not, escritas em minúsculas, e não os símbolos && ou || que você usa no DAX. Segundo, quando você mistura and e or na mesma expressão, use parênteses para deixar a precedência explícita. Não confie na sorte:

if ([UF] = "SP" or [UF] = "RJ") and [Valor] > 5000 then "Sudeste Alto"
else "Outros"

Sem os parênteses ao redor do or, o resultado pode não ser o que você espera.

Nulo em M não é zero, não é vazio e precisa ser tratado#

Esse é o ponto que mais gera bug silencioso. Em M, o valor nulo é null, e ele se comporta de um jeito próprio. Uma comparação como [Valor] > 1000 quando [Valor] é null não retorna nem verdadeiro nem falso de forma útil, e some com a linha da sua classificação. Pior: uma operação aritmética envolvendo null, como [A] + [B] com [B] nulo, propaga o nulo para o resultado.

Existem duas formas principais de tratar isso, e você vai usar as duas.

A primeira é testar o nulo explicitamente com if ... = null. Serve quando você quer um valor padrão para células vazias:

if [Valor] = null then "Sem valor"
else if [Valor] >= 3000 then "Médio ou Alto"
else "Baixo"

A segunda, e mais poderosa, é o try ... otherwise. Ele executa uma expressão e, se der erro por qualquer motivo (nulo, tipo incompatível, divisão por zero), devolve um valor alternativo em vez de quebrar a consulta inteira. É o cinto de segurança da linguagem:

try [Faturamento] / [Pedidos] otherwise 0

Se [Pedidos] for zero ou nulo, em vez de a coluna virar um mar de erros, cada linha problemática recebe 0. Use try / otherwise sempre que a fórmula depender de dados que você não controla totalmente, como planilhas enviadas por terceiros. Se a origem dos seus dados é bagunçada de verdade, esse tratamento é parte do trabalho de engenharia de dados que sustenta qualquer relatório confiável.

A pergunta que separa o júnior do sênior: fazer na consulta ou no DAX#

Essa é a decisão que mais aparece nos nossos projetos de Power BI, e a resposta curta é: depende do que a lógica representa. A regra prática que a gente usa é a seguinte.

Coluna que descreve o que uma linha é, um atributo fixo, uma classificação, uma faixa, uma categoria, deve nascer no Power Query. É lógica de dimensão. Ela é calculada uma vez, na atualização, fica gravada e comprimida no modelo, e não pesa na hora de o usuário clicar no relatório.

Cálculo que responde quanto, que muda conforme o filtro, o período ou o contexto que o usuário seleciona, deve viver em DAX, como medida. Faturamento do trimestre, ticket médio do segmento selecionado, percentual sobre o total: isso não é atributo de linha, é resultado que só faz sentido no contexto do visual. Para se aprofundar nesse lado, veja o nosso guia de boas práticas de modelagem DAX.

A tabela abaixo resume o critério de decisão.

Situação	Onde resolver	Por quê
Classificar cliente em ativo ou inativo	Power Query (coluna)	Atributo fixo da linha, usado para filtrar e agrupar
Faixa de faturamento (Alto, Médio, Baixo)	Power Query (coluna)	Categoria de dimensão, calculada na atualização
Concatenar chave de junção entre tabelas	Power Query (coluna)	Prepara o modelo, não depende de contexto
Total de vendas do período selecionado	DAX (medida)	Depende do filtro do usuário
Percentual sobre o total geral	DAX (medida)	Muda conforme o contexto do visual
Comparativo ano contra ano	DAX (medida)	Contexto temporal dinâmico

O erro clássico é criar uma coluna calculada em DAX para algo que era claramente uma coluna de dimensão. Funciona, mas incha o modelo e piora o desempenho, porque coluna DAX não comprime tão bem quanto uma coluna trazida pela consulta. Regra de bolso: se você consegue resolver no Power Query sem depender do que o usuário seleciona, resolva no Power Query.

Um fluxo real de decisão, do começo ao fim#

Para fechar o raciocínio, imagine uma tabela de vendas com Valor, Regiao e Status. O que você faria com cada necessidade?

1. Classificar em faixa de valor: coluna condicional. É atributo, avaliação simples, resolve na interface.
2. Marcar como prioritário quando valor alto e região Sul: coluna personalizada com and.
3. Preencher "Sem status" onde o campo vier vazio: coluna personalizada com teste de null ou try / otherwise.
4. Calcular o faturamento do mês selecionado no filtro: medida DAX. Depende de contexto, não vira coluna.

Quando o volume de transformações cresce e passa a valer para vários relatórios, entra a padronização em camadas, dataflows e governança, que é onde a nossa sustentação de BI costuma atuar.

Perguntas frequentes#

Qual a diferença real entre coluna condicional e coluna personalizada no Power Query?

A coluna condicional é uma interface visual que monta uma regra if / then / else por menus, sem você escrever código. A coluna personalizada é um campo livre para escrever fórmula M diretamente. Na prática, a condicional gera M por baixo dos panos, então ela é um subconjunto mais fácil da personalizada. Use a condicional para regras simples e a personalizada quando precisar combinar colunas, aplicar funções ou testar várias condições.

A coluna condicional realmente gera código M?

Sim. Tudo o que você monta no formulário da coluna condicional vira uma expressão if / then / else em linguagem M. Você pode ver isso abrindo a barra de fórmulas logo após criar a coluna. É um bom jeito de aprender M, porque você monta pela interface e depois estuda o código que apareceu.

A linguagem M diferencia maiúsculas de minúsculas?

Sim, e essa é uma das maiores fontes de erro para iniciantes. if é diferente de If, Text.Upper é diferente de text.upper, e [Cliente] é diferente de [cliente]. Palavras reservadas como if, then, else, and, or e not são sempre em minúsculas. Nomes de função seguem o padrão com inicial maiúscula, por exemplo Text.Contains.

Como trato campos nulos para a regra não quebrar?

Você tem duas ferramentas. Para dar um valor padrão a células vazias, teste explicitamente com if [Coluna] = null then .... Para proteger fórmulas que podem gerar erro, como divisões ou operações com dados de terceiros, use try [expressão] otherwise [valor alternativo]. O try / otherwise evita que uma única linha problemática transforme a coluna inteira em erros.

Devo criar a lógica no Power Query ou em DAX?

Regra prática: se a lógica descreve um atributo fixo da linha (classificação, faixa, categoria), faça no Power Query como coluna. Se ela responde "quanto" e muda conforme o filtro do usuário (totais, percentuais, comparativos de período), faça em DAX como medida. Lógica de dimensão fica melhor na consulta, cálculo de medida fica melhor em DAX. Isso deixa o modelo mais leve e o relatório mais rápido.

Posso usar and, or e not na coluna personalizada?

Pode e deve, mas atenção à sintaxe. Em M os operadores lógicos são as palavras and, or e not em minúsculas, e não os símbolos && e || do DAX. Quando misturar and e or na mesma expressão, use parênteses para deixar clara a precedência e garantir que o resultado seja o esperado.

No Power Query, coluna condicional e personalizada bem escolhidas rendem um modelo mais leve#

Coluna condicional e personalizada são a base da transformação de dados no Power Query, e dominar as duas resolve a maior parte do que aparece no dia a dia. O segredo não está em decorar funções, e sim em decidir bem: regra simples de atributo vai na condicional, regra composta vai na personalizada, cálculo que depende de contexto vai para o DAX, e nulo sempre recebe tratamento. Com esse critério, seu modelo fica mais limpo e seus relatórios mais rápidos.

Se você quer estruturar isso com padrão e governança em vez de resolver caso a caso, fale com a gente. A Fynx ajuda times a montar a camada de dados do jeito certo desde o começo.