Um sintoma clássico de relatório Power BI mal projetado é a página com oito gráficos quase idênticos — um por métrica, um por dimensão — que o usuário rola sem parar. Os field parameters resolvem boa parte disso, permitindo que quem consome o relatório troque a métrica ou a dimensão exibida em um visual em runtime, sem que você duplique páginas ou visuais. Mas eles têm regras próprias que, ignoradas, geram relatórios lentos e cheios de armadilhas.
\nO que field parameters realmente são
\nAo criar um field parameter (Modeling > New parameter > Fields), o Power BI gera uma tabela calculada de valores que referenciam colunas ou medidas do modelo, usando a função NAMEOF. A tabela tem, por padrão, três colunas: o nome exibido, a referência ao campo (armazenada como texto no campo interno) e um índice de ordenação. Ao arrastar essa tabela para um slicer, o usuário escolhe quais campos alimentam o visual conectado.
O ponto-chave é que field parameters funcionam tanto para dimensões (colunas de eixo, Categoria, Região, Produto) quanto para medidas (Receita, Margem, Ticket médio). Você pode ter um parâmetro de \"qual métrica ver\" e outro de \"quebrar por qual dimensão\" no mesmo gráfico — reduzindo dezenas de visuais a um só.
Onde eles brilham
\nSWITCH(SELECTEDVALUE(...)). O field parameter tira essa lógica da medida e coloca no modelo, de forma declarativa.As armadilhas que aparecem em produção
\nReceita (moeda) e Margem % (percentual), o eixo e os data labels não trocam o formato sozinhos. Você precisa medidas com formatação dinâmica (format strings dinâmicas por medida) ou aceitar um formato único. É o problema mais reportado.Produto e o usuário troca o eixo para Região, o filtro continua ativo — o que pode confundir. Documente ou use bookmarks para limpar contexto.Boas práticas de modelagem
\nfMedida_ReceitaLiq.Quando não usar
\nSe o público precisa comparar duas métricas lado a lado o tempo todo, field parameter não é a resposta — ele mostra uma opção por vez. Se cada métrica tem um layout muito específico (eixo secundário, meta, formatação distinta), páginas dedicadas ou bookmarks entregam melhor experiência. E se o objetivo é liberdade total de exploração, o recurso de personalização de visuais (Personalize visuals) ou o próprio modo Explore podem ser mais adequados.
\nField parameters são uma daquelas features de baixo custo e alto impacto na governança de relatórios: menos páginas, menos duplicação, autoatendimento dentro de trilhos. Mas a decisão entre parâmetro, bookmark, personalização de visual e página dedicada é de arquitetura, e é aí que a experiência conta. Se sua empresa está reestruturando o portfólio de relatórios Power BI e quer reduzir manutenção sem perder controle de formatação e performance, a Dynamic Soluções ajuda a desenhar esse padrão com modelagem, ALM e governança do começo ao fim.
\nA classic symptom of a poorly designed Power BI report is a page with eight nearly identical charts — one per metric, one per dimension — that users endlessly scroll through. Field parameters solve much of this by letting report consumers switch the metric or dimension shown in a visual at runtime, without you duplicating pages or visuals. But they come with their own rules that, when ignored, produce slow reports full of traps.
\nWhat field parameters really are
\nWhen you create a field parameter (Modeling > New parameter > Fields), Power BI generates a calculated table of values that reference columns or measures in the model using the NAMEOF function. The table has, by default, three columns: the display name, the field reference (stored as text in the internal field), and a sort index. When you drag this table into a slicer, the user picks which fields feed the connected visual.
The key point is that field parameters work for both dimensions (axis columns like Category, Region, Product) and measures (Revenue, Margin, Average ticket). You can have one parameter for \"which metric to see\" and another for \"break down by which dimension\" in the same chart — collapsing dozens of visuals into one.
Where they shine
\nSWITCH(SELECTEDVALUE(...)). The field parameter pulls that logic out of the measure and into the model, declaratively.The traps that show up in production
\nRevenue (currency) and Margin % (percentage), the axis and data labels won't change format on their own. You need measures with dynamic format strings per measure, or accept a single format. This is the most reported issue.Product and the user switches the axis to Region, the filter stays active — which can confuse. Document it or use bookmarks to clear context.Modeling best practices
\nfMeasure_NetRev.When not to use them
\nIf your audience needs to compare two metrics side by side all the time, a field parameter isn't the answer — it shows one option at a time. If each metric has a very specific layout (secondary axis, target, distinct formatting), dedicated pages or bookmarks deliver a better experience. And if the goal is total exploration freedom, the Personalize visuals feature or Explore mode itself may fit better.
\nField parameters are one of those low-cost, high-impact features for report governance: fewer pages, less duplication, self-service on rails. But the decision between parameter, bookmark, visual personalization, and dedicated page is architectural, and that's where experience matters. If your company is restructuring its Power BI report portfolio and wants to cut maintenance without losing control of formatting and performance, Dynamic Soluções helps design that pattern with modeling, ALM, and governance end to end.
"}},"pageContext":{"slug":"/blog/power-bi-field-parameters-relatorios-dinamicos/","previousPost":null,"nextPost":{"frontmatter":{"title":"Microsoft Fabric: OneLake shortcuts vs cópia de dados na prática"},"fields":{"slug":"/blog/microsoft-fabric-onelake-shortcuts-vs-copia-dados/"}}}},"staticQueryHashes":["2269431855"]}