Como usar dataflows no Power BI: passo a passo

Quando o mesmo Power Query aparece em dez relatórios, você tem um problema#

Se a sua área já usa Power BI há algum tempo, a cena provavelmente é familiar: um analista monta uma consulta bonita no Power Query, trata os tipos, limpa nulo, cria colunas calculadas, e aquilo vira a base de um relatório. Um mês depois, outro analista precisa da mesma tabela de clientes tratada e faz tudo de novo, do zero, com pequenas diferenças. Multiplique isso por dez relatórios e você tem dez versões ligeiramente diferentes da mesma verdade. É exatamente esse cenário que os dataflows Power BI resolvem, e é sobre isso que este guia trata.

Dataflow é, na prática, o Power Query rodando na nuvem, desacoplado do relatório. Em vez de a transformação viver dentro de cada arquivo .pbix, ela vive no serviço do Power BI, centralizada, agendada e reutilizável por quem tiver permissão. Você constrói uma vez e consome em vários lugares. Neste artigo vamos ver quando faz sentido usar, o passo a passo para criar o seu primeiro dataflow, os erros que mais aparecem e as boas práticas que separam um ambiente organizado de uma bagunça cara de manter.

Vale um aviso honesto logo de início: dataflow não é bala de prata. Ele resolve reuso e padronização de transformação, mas adiciona uma camada a mais no seu pipeline. Se você usar sem critério, troca um problema por outro. Ao longo do texto eu vou apontar onde ele ajuda e onde ele atrapalha.

Dataflows Power BI são a camada de transformação reutilizável do serviço#

Antes do passo a passo, é importante entender o que exatamente você está criando. Um dataflow é um conjunto de consultas Power Query que roda no serviço do Power BI e grava o resultado em armazenamento (por padrão, no Azure Data Lake Storage gerenciado pela Microsoft, ou no OneLake quando você está no contexto do Fabric). Cada consulta vira uma entidade, que nada mais é do que uma tabela pronta, já transformada.

A diferença central em relação ao Power Query dentro do Power BI Desktop é onde a lógica mora e quem pode reaproveitá-la:

Característica	Power Query no Desktop	Dataflow
Onde a transformação roda	Na sua máquina, dentro do .pbix	No serviço do Power BI, na nuvem
Reuso entre relatórios	Copiar e colar consulta	Um dataflow, vários relatórios apontando para ele
Atualização	Junto com o dataset do relatório	Agendada de forma independente
Quem mantém	Cada autor do relatório	Time de dados, de forma centralizada
Resultado armazenado	Não, recalcula sempre	Sim, fica persistido no data lake

Repare no último ponto: o dataflow persiste o resultado. Isso muda o jogo em performance de atualização, porque a transformação pesada acontece uma vez, no dataflow, e os relatórios só leem o que já está pronto. É um raciocínio parecido com o de uma camada de staging em engenharia de dados, e não por acaso: dataflow é o primeiro passo de muita gente rumo a uma arquitetura de dados mais madura. Se esse for o seu caminho, vale conhecer nosso trabalho de engenharia de dados.

Quando usar dataflow (e quando não usar)#

Dataflow faz sentido quando pelo menos uma destas situações aparece:

• A mesma transformação é usada por vários relatórios ou vários autores.
• Você quer separar a atualização dos dados da atualização do relatório.
• A fonte é lenta ou tem limite de acesso, e você não quer bater nela toda vez que um relatório atualiza.
• Você precisa de uma versão única e confiável de dimensões como calendário, clientes, produtos ou centros de custo.
• Você quer tirar lógica de transformação da mão de analistas e centralizar no time de dados.

E dataflow não faz sentido, ou pelo menos exige cautela, quando:

• É um relatório único, pontual, que ninguém mais vai reaproveitar. A camada extra só adiciona complexidade.
• Você precisa de tempo real ou quase real. Dataflow trabalha por atualização agendada, não é streaming.
• O volume é gigantesco e a régua de licença não acompanha. Aí a conversa vira Fabric, Direct Lake e outra arquitetura.

Passo a passo: criando seu primeiro dataflow#

Vamos ao prático. O roteiro abaixo assume que você tem acesso ao serviço do Power BI e permissão de colaborador ou administrador em um workspace. Idealmente, um workspace que não seja o pessoal (Meu workspace), porque dataflow em workspace pessoal não compartilha com o time e não escala.

Passo 1: escolha o workspace certo#

No serviço do Power BI, entre em um workspace de time. Se você ainda organiza tudo no workspace pessoal, pare e leia nosso guia sobre organização de workspaces em escala antes de ir adiante. A regra é simples: dataflow é ativo compartilhado, então precisa viver onde o time enxerga.

Passo 2: crie o dataflow#

Dentro do workspace, clique em Novo e escolha Dataflow. O serviço abre o editor do Power Query online, praticamente idêntico ao que você conhece do Desktop. Você vai ver a opção de Adicionar novas tabelas, que abre o seletor de fontes de dados.

Passo 3: conecte na fonte#

Escolha a fonte, um SQL Server, uma lista do SharePoint, um arquivo no OneDrive, uma API, o que for. Informe as credenciais. Aqui vale uma atenção: se a fonte é local (on-premises), você vai precisar de um gateway de dados configurado. Sem gateway, o serviço não alcança bancos que estão dentro da sua rede.

Passo 4: transforme os dados#

Agora é o Power Query de sempre. Remova colunas que não interessam, ajuste tipos, filtre linhas, faça merge e append, crie colunas condicionais. A recomendação de ouro é transformar o máximo possível antes de carregar, e favorecer transformações que permitam query folding, ou seja, que sejam empurradas para a fonte executar. Isso mantém a atualização rápida.

Passo 5: nomeie as entidades e salve#

Dê nomes claros às consultas, porque cada uma vira uma entidade que outras pessoas vão consumir. Nada de Consulta1 ou Tabela_final_v2_ok. Prefira dim_clientes, fato_vendas, dim_calendario. Depois clique em Salvar e dê um nome ao dataflow.

Passo 6: configure a atualização agendada#

Salvar não atualiza. Volte ao workspace, encontre o dataflow, abra as configurações e defina o agendamento de atualização. Escolha a frequência que faz sentido para o negócio, diária de madrugada é o padrão para a maioria dos casos. Configure também a notificação de falha, para não descobrir que o dado está velho só quando um gestor reclamar.

Passo 7: consuma o dataflow no relatório#

No Power BI Desktop, use Obter dados e escolha Dataflows do Power BI. Navegue até o workspace, encontre o seu dataflow e selecione as entidades que quer trazer. Pronto: o relatório agora lê de uma fonte tratada, padronizada e centralizada, sem repetir uma linha de transformação.

A tabela abaixo resume o fluxo para você usar como referência rápida:

Passo	Ação	Onde acontece
1	Escolher workspace de time	Serviço do Power BI
2	Criar dataflow	Serviço, botão Novo
3	Conectar na fonte	Power Query online
4	Transformar os dados	Power Query online
5	Nomear entidades e salvar	Power Query online
6	Agendar atualização	Configurações do dataflow
7	Consumir no relatório	Power BI Desktop

Os erros mais comuns com dataflows (e como evitar)#

Depois de ver muitos ambientes, alguns tropeços se repetem com uma regularidade quase cômica. Vale conhecer para não cair neles.

Transformar de menos e deixar tudo para o relatório. O ponto do dataflow é centralizar a lógica. Se você só carrega a tabela crua e faz toda a limpeza dentro de cada .pbix, jogou fora metade do benefício. Coloque a transformação pesada no dataflow.

Transformar de mais e criar um monstro único. O extremo oposto também dói. Um dataflow gigante, com trinta entidades e dependências cruzadas, vira um ponto único de falha e leva uma eternidade para atualizar. Separe por domínio ou por camada.

Ignorar o query folding. Quando você introduz um passo que quebra o folding (certos merges, colunas customizadas complexas, alguns filtros), a fonte para de fazer o trabalho e o serviço passa a puxar tudo para processar na nuvem. Em volume grande, a atualização despenca. Verifique o folding com o botão direito no passo e a opção de ver a consulta nativa.

Esquecer o gateway em fontes on-premises. Erro clássico de primeira viagem. O dataflow salva bonito, mas a atualização agendada falha porque o serviço não alcança o banco interno. Configure o gateway antes.

Não pensar em atualização incremental. Recarregar bilhões de linhas todo dia é desperdício de tempo e de capacity. Para tabelas fato grandes, configure atualização incremental no dataflow, trazendo só o que mudou.

Deixar tudo sem governança. Dataflow é dado tratado, muitas vezes com informação sensível. Quem pode ver? Quem pode editar? Sem uma política clara, você espalha dados sem controle. Esse é um tema que se conecta direto com governança de dados e vale tratar com seriedade.

Boas práticas que separam um ambiente saudável de uma bagunça#

Criar dataflow é fácil. Manter um ambiente com dezenas deles sem virar caos é o desafio real. Estas práticas ajudam:

Separe dataflows por camada. Uma abordagem que funciona bem é ter dataflows de ingestão (dado bruto da fonte) e dataflows de transformação (dado tratado, pronto para consumo). O segundo lê do primeiro. É o mesmo princípio da arquitetura em camadas que engenheiros de dados usam, e traz clareza sobre onde cada coisa acontece.

Padronize dimensões compartilhadas. Calendário, clientes, produtos, filiais. Essas tabelas deveriam existir uma única vez, num dataflow que todo mundo consome. Assim, quando alguém pergunta "quantos clientes ativos temos", a resposta é a mesma em qualquer relatório. Isso é metade do caminho para acabar com a discussão de número divergente em reunião.

Nomeie com disciplina. Prefixos como stg_, dim_ e fato_ deixam a intenção óbvia. Um nome bom economiza horas de investigação seis meses depois.

Monitore a atualização. Configure alertas de falha e acompanhe o tempo de atualização. Um dataflow que começou levando dois minutos e hoje leva quarenta está pedindo atenção.

Documente as fontes e as regras. Nem que seja uma página simples dizendo de onde vem cada entidade e que regras de negócio foram aplicadas. Ambiente sem documentação depende da memória de uma pessoa, e pessoas trocam de emprego.

Cuidado com o licenciamento. Recursos como computed entities e atualização incremental dependem de capacidade Premium ou Fabric. Entenda o que a sua licença cobre antes de desenhar a arquitetura em cima de algo que você não tem.

Para o quadro maior do Power BI na empresa, além de dataflows, vale a leitura do nosso guia completo de Power BI para empresas no Brasil.

Dataflow, dataset e datamart: entendendo as peças#

Uma confusão frequente é misturar dataflow com outras coisas do ecossistema. Rápida distinção para você não se perder:

Conceito	O que é	Para que serve
Dataflow	Camada de transformação (Power Query na nuvem)	Preparar e reutilizar dados tratados
Dataset / modelo semântico	Modelo de dados com relacionamentos e medidas DAX	Servir de base para relatórios e análises
Datamart	Dataflow + banco SQL + modelo, num pacote	Autoatendimento com banco gerenciado
Relatório	As visualizações que o usuário final vê	Consumir e explorar os dados

Na prática, o fluxo maduro costuma ser: dataflow trata o dado, o modelo semântico organiza e cria as medidas em DAX, e o relatório apresenta. Se DAX ainda te causa dúvida, nosso material de boas práticas de modelagem e DAX complementa bem este aqui.

Dataflow substitui um ETL de verdade? Para volumes moderados e autoatendimento, resolve muito bem. Para pipelines industriais, com bilhões de linhas e SLA apertado, você vai querer Data Factory, Fabric ou uma arquitetura de engenharia dedicada. Dataflow é a porta de entrada, não o destino final de todo mundo.

Perguntas frequentes#

Preciso de licença Premium para usar dataflows?

Não para o básico. Dataflows padrão funcionam com licença Pro. Alguns recursos avançados, como computed entities (entidades que fazem cálculo em cima de outras entidades no serviço), atualização incremental e integração mais profunda com data lake, dependem de capacidade Premium ou Fabric. Comece pelo que a sua licença cobre e escale quando a necessidade justificar.

Qual a diferença entre dataflow e Power Query no Desktop?

É o mesmo motor de transformação, mas em lugares diferentes. No Desktop, a lógica vive dentro do arquivo e recalcula a cada atualização do relatório. No dataflow, a lógica vive na nuvem, roda de forma agendada e independente, persiste o resultado e pode ser reaproveitada por vários relatórios e autores. Dataflow é o Power Query virando ativo compartilhado.

Dataflow atualiza em tempo real?

Não. Dataflow trabalha por atualização agendada ou manual. Se você precisa de dados em tempo real ou quase real, o caminho é outro, como Real-Time Intelligence no Fabric ou soluções de streaming. Para a grande maioria dos relatórios de gestão, uma atualização diária ou algumas vezes ao dia é mais do que suficiente.

Posso conectar dataflow a fontes locais, dentro da minha rede?

Sim, mas você precisa de um gateway de dados on-premises configurado e associado ao dataflow. Sem o gateway, o serviço do Power BI não consegue alcançar bancos e arquivos que estão dentro da sua infraestrutura. É o mesmo gateway usado para atualização de datasets.

Vale a pena migrar transformações que já estão nos relatórios para dataflows?

Depende de reuso. Se a mesma transformação aparece em vários relatórios, ou se várias pessoas mexem na mesma lógica, migrar para dataflow paga o esforço rapidamente em padronização e menos retrabalho. Se é uma transformação única, isolada, de um relatório que ninguém mais toca, a migração só adiciona complexidade sem retorno claro.

Dataflow serve para uma arquitetura de dados corporativa séria?

Serve como uma camada, não como a arquitetura inteira. Para autoatendimento e padronização de transformação em escala departamental, é excelente. Para pipelines corporativos com grande volume, governança rígida e integração com múltiplos sistemas, ele costuma ser uma peça dentro de um desenho maior que envolve engenharia de dados, Fabric e orquestração dedicada.

Comece simples, cresça com método#

Dataflow resolve um problema concreto e comum: a transformação de dados espalhada, repetida e inconsistente entre relatórios. Bem usado, ele centraliza a lógica, padroniza as dimensões, acelera a atualização e tira peso das costas dos analistas. Mal usado, vira mais uma camada bagunçada para manter. A diferença está no método: separar por camadas, nomear com disciplina, respeitar o query folding, pensar em governança desde o início.

Se você está começando, monte um único dataflow para uma dimensão compartilhada, o calendário é um ótimo primeiro caso, e sinta o benefício na prática antes de expandir. E se a sua empresa já sente que o ambiente Power BI cresceu mais rápido do que a organização dele, talvez seja hora de olhar o quadro completo, de dataflows a arquitetura de dados. Nesse ponto, fale com a gente: a gente ajuda a desenhar um caminho que cresce sem virar dor de cabeça.