Toda equipe que opera Dataverse em escala esbarra na mesma pergunta de arquitetura: quando uma regra de negócio deve ser um plugin registrado no Dataverse, quando deve ser um fluxo do Power Automate e quando basta uma business rule ou uma classic workflow? A resposta errada aparece meses depois, na forma de registros salvos pela metade, latência que o usuário sente ou lógica que roda fora da transação e não pode ser desfeita. Este post é um guia de decisão para quem já passou do estágio de \"funciona no meu ambiente\".
\nO event framework do Dataverse é o ponto de partida
\nPlugins não são \"código solto\": eles se registram em estágios específicos do pipeline de execução do Dataverse, e entender esses estágios é o que separa uma decisão sólida de uma aposta.
\nA execução pode ser síncrona (o usuário espera, tudo na mesma transação, rollback automático em caso de erro) ou assíncrona (enfileirada no System Job, não bloqueia o usuário, mas não participa da transação do registro original).
\nPlugin síncrono: para o que precisa ser atômico e imediato
\nUse plugin síncrono quando a regra precisa de duas garantias ao mesmo tempo: acontecer antes de o usuário ver o resultado e estar dentro da transação para que uma falha desfaça a operação inteira. Exemplos:
\nO custo é latência: tudo que roda no plugin síncrono soma no tempo de resposta do salvamento. Há limite prático de 2 minutos por transação de plugin síncrono antes de timeout, e o corpo do código roda em sandbox isolado, sem acesso a arquivos ou rede fora de endpoints permitidos.
\nPower Automate: para orquestração, integração e o que pode esperar
\nO fluxo do Power Automate brilha quando a lógica é assíncrona por natureza e envolve orquestração entre sistemas ou pessoas. Sinais de que a regra deve ser um fluxo, não um plugin:
\nO trade-off é que o fluxo roda fora da transação e de forma eventualmente consistente: entre o Create do registro e o disparo do gatilho \"When a row is added\" há uma latência que pode ir de segundos a mais, dependendo de throttling e carga. Nunca dependa de um fluxo para garantir invariantes que precisam valer no instante do commit.
\nE as business rules e classic workflows?
\nAntes de escrever qualquer código, esgote as opções declarativas:
\nUm roteiro de decisão prático
\nUm erro comum é resolver tudo com Power Automate porque é low-code — e descobrir tarde que uma regra crítica de integridade não rodava quando o dado entrava via importação em massa, porque ninguém garantiu que o gatilho cobria aquela origem. Outro erro é escrever plugin para orquestração de aprovação, prendendo lógica de processo em assembly que exige um desenvolvedor e um deploy para cada ajuste de negócio.
\nGovernança e ALM não são detalhe
\nSeja plugin ou fluxo, a lógica deve viver dentro de uma solução gerenciada e passar pelo pipeline Dev/Test/Prod. Plugins exigem step registrations versionados e cuidado com ordem de execução (rank) quando há múltiplos plugins na mesma mensagem. Fluxos exigem connection references e environment variables para não vazar credenciais entre ambientes. Misturar as duas abordagens sem uma convenção clara de \"onde cada tipo de regra vive\" é o que transforma um Dataverse maduro em uma caixa-preta que ninguém consegue mais depurar.
\nEstruturar essa camada de lógica de negócio — decidir o que é plugin, o que é fluxo, o que é declarativo — é uma das decisões de arquitetura que mais impactam a manutenibilidade de uma solução Power Platform em escala. Se sua empresa está nesse ponto de maturidade e quer revisar a arquitetura antes que o débito técnico cresça, a consultoria e os planos de suporte da Dynamic Soluções ajudam a colocar essa camada em ordem, com ALM e governança de verdade.
\nEvery team running Dataverse at scale hits the same architecture question: when should a business rule be a plugin registered in Dataverse, when should it be a Power Automate flow, and when is a business rule or a classic workflow enough? The wrong answer shows up months later as half-saved records, latency the user actually feels, or logic that runs outside the transaction and can't be rolled back. This post is a decision guide for those already past the \"works on my environment\" stage.
\nThe Dataverse event framework is the starting point
\nPlugins aren't \"loose code\": they register at specific stages of the Dataverse execution pipeline, and understanding those stages is what separates a solid decision from a gamble.
\nExecution can be synchronous (the user waits, everything in the same transaction, automatic rollback on error) or asynchronous (queued as a System Job, doesn't block the user, but doesn't take part in the original record's transaction).
\nSynchronous plugin: for what must be atomic and immediate
\nUse a synchronous plugin when the rule needs two guarantees at once: happening before the user sees the result and being inside the transaction so a failure undoes the whole operation. Examples:
\nThe cost is latency: everything running in a synchronous plugin adds to the save response time. There's a practical 2-minute limit per synchronous plugin transaction before timeout, and the code runs in an isolated sandbox, with no file or network access beyond allowed endpoints.
\nPower Automate: for orchestration, integration and what can wait
\nA Power Automate flow shines when the logic is asynchronous by nature and involves orchestration across systems or people. Signs the rule should be a flow, not a plugin:
\nThe trade-off is that the flow runs outside the transaction and is eventually consistent: between the record Create and the \"When a row is added\" trigger firing there's a latency that can range from seconds to more, depending on throttling and load. Never rely on a flow to enforce invariants that must hold at the instant of commit.
\nWhat about business rules and classic workflows?
\nBefore writing any code, exhaust the declarative options:
\nA practical decision guide
\nA common mistake is solving everything with Power Automate because it's low-code — and discovering late that a critical integrity rule didn't run when data came in via bulk import, because nobody made sure the trigger covered that origin. Another mistake is writing a plugin for approval orchestration, locking process logic into an assembly that requires a developer and a deploy for every business tweak.
\nGovernance and ALM aren't a detail
\nWhether plugin or flow, the logic must live inside a managed solution and go through the Dev/Test/Prod pipeline. Plugins require versioned step registrations and care with execution order (rank) when multiple plugins share the same message. Flows require connection references and environment variables so credentials don't leak between environments. Mixing both approaches without a clear convention of \"where each type of rule lives\" is what turns a mature Dataverse into a black box no one can debug anymore.
\nStructuring this business logic layer — deciding what's a plugin, what's a flow, what's declarative — is one of the architecture decisions that most affects the maintainability of a Power Platform solution at scale. If your company is at this maturity point and wants to review the architecture before technical debt grows, Dynamic Soluções' consulting and support plans help put this layer in order, with real ALM and governance.
"}},"pageContext":{"slug":"/blog/dataverse-plugins-vs-power-automate-logica-negocio/","previousPost":null,"nextPost":{"frontmatter":{"title":"Copilot Studio vs Copilot padrão: quando customizar de fato"},"fields":{"slug":"/blog/copilot-studio-vs-copilot-m365-quando-customizar/"}}}},"staticQueryHashes":["2269431855"]}