Dataverse e Power Platform: o que aprendi trabalhando com dados estruturados da Microsoft
Em 2019 precisei integrar um sistema com Dataverse da Microsoft. Era a primeira vez que encontrei uma plataforma de dados low-code enterprise. O que aprendi sobre dados estruturados ficou comigo.
O cliente usava Microsoft Dynamics CRM. Precisava integrar dados de leads com ele.
Fui pesquisar a API. Descobri que a API do Dynamics era a API do Dataverse. Descobri que Dataverse era o banco de dados subjacente do Power Platform da Microsoft. Descobri que Power Platform incluía PowerApps, Power Automate, Power BI.
Passei uma semana entendendo o ecossistema antes de escrever uma linha de integração.
Dataverse é o banco de dados por baixo do Power Platform da Microsoft. Parece um banco relacional normal — tem tabelas, colunas, relacionamentos — mas com diferenças importantes: schema extensível via interface ou API (sem SQL DDL), API RESTful nativa para qualquer tabela via OData, controle de acesso por papel/registro/coluna, auditoria automática.
Para dev acostumado com PostgreSQL, parece mágico. É conveniente. Até você precisar fazer algo que não foi projetado para suportar.
O primeiro obstáculo foi a nomenclatura. O que eu chamaria de "tabela" era "entidade". Colunas eram "fields" ou "attributes". A documentação usava terminologia própria que eu precisava aprender antes de conseguir fazer qualquer coisa.
Depois veio OData. É um padrão para APIs RESTful, mas com sintaxe de query diferente: filtros usam $filter=name eq 'João', expansão de relacionamentos usa $expand=account, paginação usa @odata.nextLink. Tem lógica própria.
O pior: a API retorna no máximo 5.000 registros por página por padrão. Se você tem 50.000 leads e quer todos, precisa implementar paginação via @odata.nextLink. Descobri isso depois de horas tentando entender por que minha query retornava dados parciais. Não estava na documentação principal — estava numa nota de rodapé.
O momento que mais aprendi foi quando precisei fazer uma query com lógica condicional complexa. Em SQL, seriam 10 linhas. Em OData + Dataverse, virou um exercício de descobrir os limites da API, encontrar workarounds, e eventualmente admitir que certo caso precisava de uma solução diferente.
Isso não é crítica à plataforma. É realidade de qualquer abstração. O valor é acelerar os casos comuns. O custo é que os casos incomuns ficam mais difíceis — às vezes muito mais difíceis.
Trabalhar com Dataverse em 2019 me ensinou que antes de integrar com qualquer plataforma enterprise, vale descobrir três coisas: quais são os limites de paginação/rate limit, quais casos de uso foram projetados para suportar, e onde a abstração começa a vazar.
Essa semana: se você trabalha com qualquer plataforma low-code ou no-code, identifica um limite que você já encontrou — algo que ela não consegue fazer ou faz de forma inconveniente. Esse ponto de fricção é onde você aprende mais sobre a abstração.