TL;DR: O Activator do Microsoft Fabric agora atua como publicador de Business Events (Preview), indo além de notificações e workflows. Ele transforma alertas de Power BI, Real-Time Dashboards, KQL queries e Fabric Warehouse em eventos persistentes e governados no Real-Time Hub. Para empresas brasileiras, isso significa eliminar silos de automação, criar uma camada centralizada de eventos de negócio e permitir análises históricas com KQL. O ganho real é em observabilidade, governança e rastreabilidade de sinais críticos.
Se você ainda não conferiu, vale dar uma olhada no post do Arun Ulag, “Microsoft Build 2026: Building Agentic Apps with Microsoft Fabric and Microsoft Databases”, que traz um panorama completo dos anúncios do Microsoft Build em Fabric e bancos de dados.
O que são Business Events e por que eles importam?
Business Events representam ocorrências ou mudanças de estado que importam para o negócio: uma falha de pagamento, um atraso na entrega, um equipamento offline. Até agora, o Activator era excelente para detectar essas condições e disparar alertas ou ações — mas o sinal morria ali. Não havia um registro persistente, não era possível saber quantas vezes a condição ocorreu, e cada time construía sua própria automação sem visibilidade do todo.
Com o lançamento em preview, o Activator se junta a Notebooks, User Data Functions e Eventstreams como um publicador de primeira classe de Business Events no Microsoft Fabric. Ele emite eventos estruturados e governados para o Real-Time Hub, tornando esses sinais descobríveis, roteáveis, persistentes e compartilháveis em toda a organização.
Como o Activator publica Business Events na prática?
A mecânica é direta: ao configurar uma regra no Activator a partir de um Power BI report, Real-Time Dashboard, KQL query ou consulta SQL no Fabric Warehouse, você agora pode escolher a ação “Publish a business event”. Define o tipo de evento, mapeia parâmetros dinâmicos ou estáticos, e salva. Pronto: toda vez que a condição for atendida, o evento é publicado no Real-Time Hub.
Esses eventos são automaticamente armazenados no Eventhouse, prontos para consulta com KQL. Isso significa que você tem um registro histórico de cada sinal — essencial para trend analysis, root cause investigation e modelos de IA/ML.
Os três problemas que essa funcionalidade resolve
1. Sinais que desaparecem após o trigger — Antes, não havia um registro persistente para consultar. Agora, cada evento fica disponível no Eventhouse, permitindo rastrear frequência, padrões e contexto histórico.
2. Automação em silos — Times diferentes detectando a mesma condição, cada um com suas regras e formatos. Com Business Events, você define o evento uma vez no Real-Time Hub e qualquer fonte pode publicá-lo usando a mesma definição. Sem deriva de formato.
3. Falta de visibilidade do todo — Sem uma camada centralizada de eventos, perguntas básicas como “quantas vezes isso aconteceu?” ou “quem está respondendo?” eram difíceis de responder. A página de Business Events no Real-Time Hub oferece uma visão unificada de quem publica, quem consome e os payloads em tempo real.
Caso real: monitoramento de downtime em manufatura
A Microsoft ilustra com um cenário prático: uma empresa de manufatura monitora o uptime de equipamentos em múltiplas fábricas, cada uma usando ferramentas diferentes — um Activator observando um dashboard do Power BI, um Notebook varrendo dados de sensores, e Eventstreams processando telemetria. Antes, cada fábrica alertava de forma independente, com formatos diferentes e nenhuma visibilidade cross-site.
Com Business Events, a empresa define um único evento ExtendedDowntime no Real-Time Hub. Todas as três fontes publicam o mesmo evento, com campos como machine ID, production line, duration e facility name. O Eventhouse armazena tudo, permitindo consultas de padrões de downtime entre fábricas. E um consumer rule central no Activator assina o evento e coordena as respostas: notifica a manutenção, registra uma work order no Power Automate e escalona se múltiplas máquinas caírem simultaneamente.
Por que isso é relevante para empresas brasileiras?
No contexto brasileiro, onde muitas empresas lidam com heterogeneidade de ferramentas e processos manuais de monitoramento, a capacidade de criar uma camada única e governada de eventos de negócio é um diferencial. Reduz o retrabalho de cada time criar suas próprias regras, melhora a capacidade de auditoria e conformidade, e permite que times de SRE e operações tenham uma visão real do comportamento dos sistemas.
Além disso, a integração com o Power BI — ferramenta amplamente adotada no Brasil — significa que analistas e gestores podem transformar dashboards em produtores de eventos sem depender de desenvolvimento adicional.
Como começar?
- Crie um Business Event — Navegue até a página Business Events no Real-Time Hub e defina o evento com os campos do seu caso de uso.
- Configure um alerta nos seus dados — A partir de um Power BI report, Real-Time Dashboard, KQL query ou consulta SQL no Fabric Warehouse, selecione “Set alert” para abrir o painel de regras do Activator.
- Publique o evento — Escolha “Publish a business event”, selecione o tipo de evento e mapeie os parâmetros.
- Ative a regra — Sua regra está ao vivo. O Activator publicará um Business Event sempre que a condição for atendida.
- Explore no Eventhouse — Os eventos publicados são automaticamente armazenados e prontos para consulta com KQL.
- Configure consumidores — Use o Activator como consumidor para criar respostas centralizadas aos eventos.
Perguntas Frequentes
-
O que muda na prática com o Activator publicando Business Events?
Antes, ao detectar uma condição, o Activator enviava um e-mail ou acionava um workflow — o sinal se perdia. Agora, ele publica um evento estruturado no Real-Time Hub, que fica persistente no Eventhouse, pode ser consumido por outros times e ferramentas, e permite análises históricas com KQL. É a diferença entre um alerta descartável e um sinal de negócio reutilizável.
-
Como fica a governança com essa nova capacidade?
A governança é um dos pilares. Um Business Event é definido uma vez no Real-Time Hub e qualquer fonte (Power BI, Data Warehouse, KQL, Eventstream) pode publicá-lo usando a mesma definição. Isso elimina a deriva de formato entre equipes. A página de Business Events mostra quem publica, quem consome e os payloads em tempo real, centralizando a gestão.
-
Preciso migrar meus alertas existentes do Activator para usar Business Events?
Não é uma migração forçada. Os alertas tradicionais continuam funcionando. A publicação de Business Events é uma ação adicional que você pode selecionar na criação da regra. Vale adotá-la quando houver necessidade de compartilhar o sinal com outros times, fazer análise histórica ou coordenar respostas centralizadas.
-
O Activator como consumidor de Business Events funciona de forma diferente?
Sim. Além de publicar, o Activator pode agora ser um assinante de eventos publicados por outras fontes (Notebooks, User Data Functions, Eventstreams). Isso permite criar regras centralizadas que respondem a eventos independentemente de quem os publicou, centralizando o acionamento de workflows, notificações e escalonamentos.
-
Esse recurso já está disponível para clientes no Brasil?
O recurso está em Preview, disponível para testes em tenants que optarem por participar. Recomenda-se validar em ambientes não produtivos. A documentação oficial e a página de Business Events no Real-Time Hub já estão acessíveis. Fique atento ao roadmap do Fabric para a disponibilidade geral (GA).
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
