Power Apps canvas x model-driven

A pergunta certa não é "qual é melhor", é "qual resolve o seu caso"#

Toda semana alguém pergunta para a gente qual tipo de app do Power Apps é o "certo", como se existisse um vencedor absoluto. Não existe. A decisão entre Power Apps canvas x model-driven não é uma questão de gosto nem de qual tela fica mais bonita: é uma questão de onde estão os seus dados, de quanto controle você precisa ter sobre o layout e de qual problema de negócio está na frente. Escolher errado no começo custa retrabalho, licença desperdiçada e um app que ninguém abre depois da segunda semana.

Neste artigo eu separo os dois modelos de forma honesta, mostro o papel do Dataverse, falo de licenciamento e dos limites que costumam pegar equipes de surpresa. Sem código, sem enrolação. Se você já leu nosso guia de Power Platform, Power Apps e Power Automate, pense neste texto como o aprofundamento na hora de decidir o tipo de aplicativo.

Power Apps canvas x model-driven começa pelo modelo de dados, não pela tela#

A diferença de fundo é simples de enunciar e fácil de esquecer no calor de um projeto. No app canvas, você começa pela tela: arrasta controles, posiciona campos pixel a pixel e depois conecta as fontes de dados que quiser. No app model-driven, você começa pelos dados: define tabelas, relacionamentos e regras de negócio no Dataverse, e a interface é gerada a partir desse modelo.

É por isso que o nome importa. "Canvas" é tela em branco. "Model-driven" é dirigido pelo modelo. Um coloca você no comando do desenho; o outro coloca a estrutura de dados no comando da experiência. Nenhum é atalho para o outro, e é aí que muita gente tropeça: tenta forçar um app canvas a virar um sistema de gestão inteiro, ou deixar um model-driven bonito como uma landing page. Os dois caminhos geram frustração.

A pergunta de partida, então, não é "quero controle de layout ou não?". É "o meu processo é dirigido por um modelo de dados e por regras, ou é uma experiência sob medida para uma tarefa?". A resposta já elimina metade das dúvidas.

O app canvas te entrega o pincel e a tela em branco#

O app canvas dá controle total do layout. Você decide onde fica cada botão, cada galeria, cada rótulo, com liberdade parecida com a de montar um slide. Esse é o principal atrativo e também a principal armadilha: liberdade total significa responsabilidade total, nada se organiza sozinho e a consistência visual depende de disciplina.

O segundo grande atrativo é a conectividade. O canvas conecta a mais de uma centena de conectores prontos: SharePoint, SQL Server, Excel, Dataverse, serviços da Microsoft 365 e dezenas de sistemas de terceiros. Ele não exige o Dataverse. Dá para subir um app canvas apontando para uma lista do SharePoint e resolver um processo de campo em poucos dias.

Onde o canvas brilha:

• Aplicativos de tarefa específica, focados em uma jornada curta e bem definida.
• Uso em celular e tablet, com telas pensadas para toque e para operação em campo.
• Cenários que precisam consumir fontes variadas ao mesmo tempo, inclusive fora do Dataverse.
• Experiências onde o visual e a marca importam, como formulários para o público interno com identidade própria.

Onde o canvas cobra o preço:

• Aplicações grandes, com muitas telas e entidades, viram trabalho manual de manutenção. Cada tela é construída à mão.
• Regras de negócio complexas se espalham por fórmulas dentro de controles, o que dificulta padronizar e auditar.
• Consultas sobre grandes volumes esbarram em limites de delegação, assunto que trato mais adiante.

Em resumo: canvas é a ferramenta certa quando a experiência é o ponto central e o escopo é focado. É o app que resolve um problema com elegância, não o sistema que roda a operação inteira.

O app model-driven monta a interface a partir do seu modelo#

O app model-driven inverte a lógica. Você não desenha telas: modela dados. Define as tabelas do Dataverse, os relacionamentos, as colunas, as regras de negócio, as visões e os formulários. A partir desse modelo, o Power Apps gera a interface de forma responsiva e padronizada, com navegação, listas, formulários de detalhe e componentes de relacionamento já prontos.

Isso troca controle de layout por velocidade estrutural e consistência. Você abre mão de posicionar cada pixel e ganha uma aplicação que se comporta como um sistema de verdade: formulários coerentes, buscas, filtros, gráficos e regras aplicadas de forma central. Quando o modelo muda, a interface acompanha.

Onde o model-driven brilha:

• Sistemas ricos em dados, com muitas tabelas relacionadas e processos que percorrem várias entidades.
• Aplicações de linha de negócio próximas de um CRM ou de um sistema de gestão, com cadastros, relacionamentos e histórico.
• Cenários que exigem regras de negócio centralizadas, segurança por papel e trilhas de auditoria.
• Casos em que a padronização e a manutenção a longo prazo valem mais do que uma tela sob medida.

Onde o model-driven não é a melhor escolha:

• Quando o layout precisa ser único, com forte identidade visual e livre disposição de elementos.
• Quando os dados vivem fora do Dataverse e não faz sentido trazê-los para lá.
• Quando o app é uma tarefa pontual, simples demais para justificar a modelagem completa.

Uma forma honesta de resumir: o canvas é alfaiataria, o model-driven é um sistema que se monta a partir das regras que você escreve.

O comparativo lado a lado que eu costumo mostrar em reunião#

Quando a discussão trava, esta tabela resolve boa parte das dúvidas de uma vez:

Critério	App canvas	App model-driven
Ponto de partida	A tela e a experiência	O modelo de dados e as regras
Controle de layout	Total, pixel a pixel	Limitado, gerado a partir do modelo
Fonte de dados	Mais de uma centena de conectores, com ou sem Dataverse	Dataverse como base principal
Complexidade ideal	Baixa a média, escopo focado	Média a alta, muitas entidades relacionadas
Regras de negócio	Espalhadas em fórmulas de controles	Centralizadas no modelo do Dataverse
Experiência mobile	Forte, pensada para toque	Responsiva, porém padronizada
Manutenção em escala	Manual, tela por tela	Estrutural, o modelo propaga mudanças
Curva de construção inicial	Rápida para apps pequenos	Exige modelar dados antes

Repare que quase toda linha aponta para o mesmo eixo: liberdade de desenho de um lado, força estrutural do outro. Nenhum app é o melhor nas duas colunas ao mesmo tempo. Escolher é abrir mão de algo de propósito.

Quando usar cada um, sem rodeios#

A tabela abaixo é o que uso como régua de decisão em projeto. Ela não é lei, mas acerta na maioria dos casos:

Situação	Escolha recomendada	Por quê
Formulário de campo no celular para registrar visitas	Canvas	Experiência focada, toque e câmera, escopo curto
Sistema de gestão de chamados com muitas tabelas	Model-driven	Estrutura relacional e regras centrais
App que lê SharePoint, Excel e um sistema legado ao mesmo tempo	Canvas	Vários conectores fora do Dataverse
Cadastro de clientes, contratos e histórico como um CRM leve	Model-driven	Dataverse como base, relacionamentos e auditoria
Aplicativo com identidade visual forte para o RH	Canvas	Controle total do layout e da marca
Processo com segurança por papel e trilha de auditoria	Model-driven	Segurança e governança nativas do Dataverse
Prova de conceito rápida para validar uma ideia	Canvas	Sobe rápido, sem modelar dados antes

Existe também o caminho do meio, que a gente usa bastante: um app model-driven com componentes canvas embutidos em telas específicas. Assim você fica com a estrutura do modelo onde ela importa e recupera o controle fino de layout onde a experiência precisa ser sob medida. É decisão de arquitetura, não truque, e merece ser desenhada com cuidado.

O Dataverse é o divisor de águas dessa conversa#

O Dataverse é o banco de dados do Power Platform. Não é uma lista, não é uma planilha: é um serviço de dados gerenciado, com tabelas, tipos de coluna, relacionamentos, regras de negócio, segurança por papel e trilhas de auditoria embutidas. Ele guarda os dados e também a lógica em volta deles.

Isso pesa direto na escolha do tipo de app. O model-driven existe para tirar proveito do Dataverse: lê o modelo e gera a interface. Sem Dataverse, não há model-driven. O canvas é agnóstico: usa o Dataverse se você quiser, ou fica em SharePoint, SQL e dezenas de outros conectores.

Por isso a decisão de adotar o Dataverse muitas vezes vem antes da de canvas x model-driven. Se o processo pede um modelo de dados sólido, com segurança fina e regras centralizadas, o Dataverse compensa e o model-driven faz sentido natural. Se os dados já vivem bem em outro lugar e o objetivo é uma experiência específica, o canvas apontando para essas fontes costuma ser mais direto e barato. Vale lembrar que um bom modelo de dados por trás disso é trabalho de engenharia de dados, não algo que se improvisa dentro do app.

Licenciamento é por app ou por usuário, e o Dataverse pesa na conta#

Aqui é onde muitos projetos levam susto no meio do caminho. O licenciamento do Power Apps é, de forma geral, por app ou por usuário. No plano por app, você licencia o direito de rodar um aplicativo específico por usuário. No plano por usuário, a pessoa roda quantos apps precisar dentro das regras do plano. A escolha depende de quantos apps cada pessoa usa e de quantas pessoas usam cada app.

Alguns recursos incluídos no Microsoft 365 ainda permitem criar apps mais simples sobre fontes como SharePoint e Excel, sem plano dedicado de Power Apps. Já o uso do Dataverse costuma influenciar o plano: apps que dependem dele, ou que usam conectores premium, tendem a exigir licença específica. O model-driven, por depender do Dataverse, quase sempre cai nesse território de licença dedicada.

Alguns princípios que ajudam a não errar o dimensionamento:

• Conte usuários e apps antes de fechar plano. Por app favorece poucos apps para muita gente; por usuário favorece muitos apps para o mesmo grupo.
• Trate o Dataverse como decisão de custo, não só técnica. Ele agrega capacidade e recursos, e isso entra na conta.
• Fique atento a conectores premium: muitos sistemas de terceiros são premium e mudam a exigência de licença.

Eu evito de propósito citar preço fixo, porque valores e regras de licenciamento da Microsoft mudam com frequência e variam por contrato, região e acordo comercial. O caminho seguro é validar número de usuários, número de apps e dependência do Dataverse antes de assinar qualquer coisa. Um dimensionamento errado aqui é a diferença entre um projeto barato e uma surpresa na renovação. Se quiser desenhar isso com quem já fez muitas vezes, é o tipo de conversa que temos em Power Platform.

Os limites que você precisa conhecer antes de prometer prazo#

Todo modelo tem teto, e conhecer o teto evita promessa que não se cumpre. No canvas, o limite mais famoso é a delegação. Boa parte dos conectores só processa um número limitado de registros por vez do lado do servidor; acima disso, o app trabalha apenas com um recorte dos dados, e filtros e cálculos podem devolver resultado incompleto sem avisar de forma clara. Em fontes com muitos registros, isso vira bug silencioso se ninguém desenhar as consultas pensando em delegação.

No model-driven, o limite é de outra natureza: você fica restrito ao que o modelo gera. Formulários, visões e navegação seguem os padrões da plataforma. Dá para configurar bastante, mas não para transformar a tela em algo totalmente livre. Quem espera uma landing page vai se frustrar.

Outros pontos de atenção que valem para os dois:

• Performance depende da fonte de dados e do desenho das consultas, não só do tipo de app.
• Governança precisa existir desde o início. Sem política de ambientes e conectores, os apps se multiplicam sem controle, tema que tratamos em soluções.
• Integração com Power Automate e Power BI muda a arquitetura e deve ser pensada antes, não depois.
• Migrar de um modelo para o outro no meio do projeto é caro. A escolha inicial tem peso real.

O erro clássico que vejo é começar um app canvas simples, ele dar certo, virar central para a área e crescer até bater na parede da delegação e da manutenção manual. Quando isso acontece, a conversa deixa de ser "melhora esse app" e passa a ser "reconstrói como model-driven". É evitável quando a decisão de tipo de app é feita com honestidade no começo, olhando para onde o processo vai chegar, não só para onde ele está hoje.

Perguntas frequentes#

Posso usar app canvas sem Dataverse? Sim. O canvas é agnóstico quanto à fonte e conecta a mais de uma centena de conectores, incluindo SharePoint, SQL Server, Excel e serviços da Microsoft 365. O Dataverse é opção, não exigência. Já o model-driven depende do Dataverse para existir, porque a interface é gerada a partir desse modelo de dados.

Qual dá mais controle sobre o visual? O canvas, com folga. Ele entrega controle total do layout, campo a campo. O model-driven troca esse controle por consistência e velocidade estrutural: a interface é padronizada e gerada pelo modelo, então você configura bastante, mas não desenha a tela livremente.

Dá para misturar os dois? Dá, e é comum. Você usa um app model-driven pela estrutura e pela governança e embute componentes canvas em telas específicas onde precisa de layout sob medida. É decisão de arquitetura que vale desenhar com cuidado, não improviso de última hora.

Como o licenciamento muda entre canvas e model-driven? O licenciamento do Power Apps é, em geral, por app ou por usuário, e o uso do Dataverse influencia o plano. Como o model-driven depende do Dataverse, ele quase sempre exige licença dedicada. Apps canvas mais simples, sobre SharePoint ou Excel, podem se apoiar em recursos já incluídos no Microsoft 365. Sempre valide usuários, apps e dependência do Dataverse antes de fechar.

O que é delegação e por que devo me preocupar? Delegação é a capacidade de o conector processar filtros e cálculos do lado do servidor. Muitos conectores só entregam um número limitado de registros por vez; acima disso, o app trabalha só com um recorte e pode devolver resultado incompleto sem alertar. Em fontes grandes, isso vira erro silencioso, então as consultas precisam ser desenhadas com delegação em mente.

Como o Power Apps se conecta ao meu Power BI? Os dois vivem no mesmo ecossistema e conversam bem. Você pode incorporar visuais do Power BI dentro de apps e acionar apps a partir de relatórios, unindo o app operacional com a camada analítica. Se o objetivo final é levar esses dados para análise, vale alinhar a estratégia de dados desde a modelagem, e não só depois que o app já está no ar.

O resumo que evita retrabalho#

Canvas quando a experiência é o centro e o escopo é focado. Model-driven quando o processo é dirigido por um modelo de dados rico e por regras que precisam viver no Dataverse. O tipo de app não é detalhe estético: é a decisão que define custo, manutenção e o teto de crescimento da sua solução. Decida olhando para onde o processo vai chegar, não só para onde ele está hoje.

Se você está na dúvida sobre qual caminho seguir, ou já sente que um app cresceu além do que aguenta, fale com a gente. A gente ajuda a desenhar a arquitetura certa antes de você gastar licença e tempo no modelo errado.