Fabric Apps e Rayfin: o BI está ganhando um botão de “agir”

Por Tamires Cavani, 18/08/2026

Uma analista de operações abre o painel de estoque toda manhã. Hoje, um centro de distribuição aparece com risco de ruptura em um produto de giro rápido. Ela sabe exatamente o que precisa acontecer: abrir um pedido de reposição emergencial.

Só que esse pedido não se resolve dentro do relatório. Ela anota o código do produto, sai do Power BI, entra no sistema de compras, procura o fornecedor certo, preenche um formulário e envia para aprovação. Dias depois, volta ao painel só para conferir se a reposição chegou a tempo.

O relatório fez o trabalho dele: mostrou o problema. Resolver o problema, porém, aconteceu em outro lugar, com outra ferramenta, fora do fluxo em que o dado foi encontrado.

É exatamente essa lacuna — entre “eu vi o problema” e “eu resolvi o problema” — que o Microsoft Fabric começou a atacar com dois lançamentos apresentados na Build 2026: Fabric Apps e Rayfin.

O que é, na prática, um Fabric App

Segundo a documentação oficial da Microsoft, Fabric Apps (ainda em preview) é uma camada de aplicação gerenciada dentro do próprio tenant do Fabric: um novo tipo de item de workspace que roda como uma aplicação completa — com banco de dados, autenticação e hospedagem — sem sair do ambiente onde os dados já vivem.

Na prática, isso significa construir uma tela pensada para uma tarefa específica — “aprovar reposição de estoque”, “revisar clientes em risco”, “liberar um desconto” — que consome dados do Fabric e também grava novas informações, tudo sob a mesma governança que já protege os relatórios de Power BI.

Isso substitui o Power BI? Não — resolve um problema diferente

Três ferramentas do ecossistema Microsoft, três perguntas diferentes que cada uma responde melhor.

Power BI continua sendo a ferramenta certa para responder “o que está acontecendo”: explorar, comparar, detectar tendências. Um Fabric App entra depois dessa pergunta, quando a resposta exige uma decisão dentro do próprio fluxo de trabalho. E quando o processo é longo e cheio de etapas — um formulário complexo, uma aprovação em várias camadas — o Power Apps continua sendo, hoje, a ferramenta mais madura.

São três ferramentas para três momentos diferentes de um mesmo processo, não uma substituindo a outra.

Onde entra o Rayfin

Se o Fabric App é a aplicação, o Rayfin é o que constrói o motor por trás dela.

Anunciado como projeto open source (licença MIT) durante a Build 2026, o Rayfin é um SDK e uma CLI que permite descrever o backend inteiro de uma aplicação em TypeScript — modelo de dados, regras de acesso, lógica de negócio — e publicar tudo no Fabric com um único comando, npx rayfin up.

A partir de um único modelo em TypeScript, o Rayfin gera as peças que normalmente seriam montadas uma a uma.

A partir dessa definição, o Rayfin provisiona automaticamente um banco de dados SQL dentro do Fabric, autenticação via Microsoft Entra ID, uma API GraphQL e hospedagem estática conectada ao OneLake. O desenvolvedor não monta essas peças manualmente: ele declara o modelo, e a ferramenta monta a infraestrutura.

Um detalhe relevante para quem pensa em arquitetura de dados: as informações geradas pela aplicação já nascem dentro do OneLake, disponíveis para o resto do Fabric — notebooks, pipelines, Power BI — sem que seja preciso montar uma esteira de ETL só para trazê-las para dentro da plataforma.

Dois tipos de aplicação pedem duas arquiteturas diferentes

Nem toda aplicação precisa gravar dados. E aqui mora uma confusão comum: tratar “Fabric App” como sinônimo automático de “SQL Database”. Não é bem assim.

Quando a aplicação é só para consulta — o exemplo mais simples é um painel de metas que qualquer gestor pode abrir sem precisar alterar nada — os dados podem vir direto de um Lakehouse ou de um Semantic Model já existente. Não há motivo para criar uma camada transacional só porque a interface é nova.

Quando a aplicação precisa registrar uma decisão — como no exemplo da reposição de estoque — aí sim entra o SQL Database do Fabric, pensado justamente para esse tipo de carga: registros de estado atual, aprovações, filas de trabalho.

O que é gravado no dia a dia e o que alimenta a análise histórica passam por caminhos diferentes — e depois se encontram.

Os dois lados não competem entre si: o SQL Database cuida do “agora” — o pedido está pendente, aprovado ou rejeitado — enquanto o Lakehouse acumula o histórico dessas decisões ao longo do tempo, normalmente movido por um pipeline que segue o padrão bronze-prata-ouro. Esse histórico é o que alimenta de volta o Semantic Model e, por consequência, o Power BI.

Voltando ao exemplo do estoque

• A analista abre o Fabric App e vê o alerta de ruptura, já com o histórico de consumo do produto ao lado.
• Ela aciona “solicitar reposição emergencial”. O pedido é gravado no SQL Database do Fabric, com status “pendente”.
• Um responsável pela cadeia de suprimentos recebe a notificação, abre o mesmo app, analisa o impacto e aprova.
• O status muda para “aprovado” — ainda dentro do SQL Database.
• Um pipeline leva esse registro para o Lakehouse, onde passa a compor o histórico de reposições.
• No Power BI, um relatório de operações passa a mostrar tempo médio de aprovação, ruptura evitada e custo da reposição emergencial por região.

A ação que a analista tomou dentro do app vira, poucas etapas depois, um dado que outra pessoa vai analisar num relatório. É um ciclo, não uma via de mão única.

O Semantic Model não perde espaço — ganha mais um consumidor

Vale destacar um ponto para quem já investiu tempo modelando dados no Fabric: nada disso aposenta o Semantic Model. Pelo contrário. Relacionamentos, medidas DAX e regras de RLS que já existem continuam sendo a camada de regras de negócio — só que agora podem ser consumidas por mais de um lugar ao mesmo tempo: um relatório de Power BI, um Fabric App e, cada vez mais, agentes de IA.

Isso evita duplicar lógica de negócio em cada aplicação nova. Mas também eleva a régua de qualidade: uma medida errada ou uma regra de RLS mal configurada pode agora se propagar para mais lugares do que apenas um dashboard.

A mesma identidade cuida da segurança em todas as camadas

Autenticação, permissões de aplicação e regras de segurança do modelo semântico operam em conjunto, não em paralelo.

Fabric Apps usa autenticação via Microsoft Entra ID — o mesmo login corporativo já usado no restante do Microsoft 365 e do Fabric. Isso resolve a pergunta “quem é você”. As permissões definidas junto com o modelo no Rayfin resolvem “o que você pode fazer dentro do app”. E quando a aplicação consulta um Semantic Model, as regras de RLS que já protegem esse modelo continuam valendo — resolvendo “quais dados você pode ver”.

Não é preciso inventar uma segunda arquitetura de segurança só porque existe uma aplicação nova. A que já protege o ambiente de BI é reaproveitada.

Precisa de inteligência artificial para construir isso? Não — mas ela ajuda bastante

A Microsoft tem posicionado o GitHub Copilot como o caminho recomendado para escrever o código de um Fabric App, e é comum ver agentes de IA — Copilot, Claude, Cursor — acelerando esse desenvolvimento. Mas isso é uma opção, não um requisito: como o Rayfin trabalha com TypeScript comum, qualquer desenvolvedor pode escrever esse código manualmente, sem depender de um agente.

A IA acelera a escrita do código. Quem efetivamente constrói e publica a aplicação é o Rayfin.

Como decidir entre Power BI, Fabric App e Power Apps

• Quer só distribuir análises e KPIs? Power BI resolve.
• O processo exige um formulário longo e um fluxo operacional já maduro, com aprovações em várias camadas? Power Apps ainda é, hoje, a escolha mais estável.
• Quer construir uma experiência que junte dado e decisão em um único lugar, dentro do Fabric? Vale investigar um Fabric App.
• Só precisa que o usuário grave um valor direto de dentro de um relatório de Power BI, sem construir uma aplicação nova? Isso já existe hoje através das Translytical Task Flows — um recurso independente, que não depende de Rayfin nem do item Fabric Apps.

Ainda é preview — e isso importa na prática

Fabric Apps e Rayfin entraram em preview público na Build 2026, em junho, e até o momento não há data confirmada de disponibilidade geral. Isso tem consequências concretas: a Microsoft não garante SLA de produção para o recurso, comandos de CLI e formatos de deployment podem mudar sem aviso, o custo de consumo de capacidade ainda não foi publicado, e a disponibilidade por região é limitada — vale checar a página de disponibilidade regional do Fabric antes de planejar qualquer projeto. Também é necessário ter capacidade Fabric dedicada; o recurso não funciona em capacidade compartilhada nem em workspaces de Power BI Pro.

Isso não invalida o conceito, mas indica com clareza o momento certo para experimentar: prova de conceito e ferramentas internas, sim; aplicação crítica de produção com muitos usuários, ainda não.

O que isso muda para quem trabalha com BI

Essa mudança não significa que todo profissional de BI precisa virar desenvolvedor full-stack. Mas sugere um deslocamento real na pergunta que orienta um projeto de dados.

Durante anos, a pergunta central foi: “como eu mostro esse dado da melhor forma?”

A próxima pergunta é: “o que a pessoa que está olhando esse dado precisa fazer a seguir — e dá para colocar essa ação dentro da própria experiência analítica?”

O caminho de dashboard → insight → decisão → ação deixa de ser um processo espalhado por três ou quatro sistemas diferentes e começa a caber dentro da mesma plataforma onde o dado já está. Para quem trabalha com Fabric e Power BI, entender essa arquitetura agora — mesmo em preview — é uma forma de estar pronto quando ela amadurecer.