{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/power-pages-liquid-web-api-fetchxml-dataverse-acesso-dados/","result":{"data":{"markdownRemark":{"frontmatter":{"title":"Power Pages: Liquid vs Web API vs FetchXML para acessar Dataverse","description":"Entenda os tres caminhos de acesso ao Dataverse em Power Pages: Liquid server-side, Portal Web API no browser e FetchXML, com seguranca, performance e decisao.","date":"21 de outubro de 2026","thumbnail":null},"html":"<p>Quando um portal Power Pages precisa ler e gravar dados no Dataverse, a pergunta nao e <em>se</em> da pra fazer, e <em>por qual camada</em>. O mesmo registro pode ser renderizado via Liquid no servidor, consultado via Portal Web API no browser ou extraido via FetchXML. Cada caminho tem um modelo de seguranca, um custo de performance e um ponto de falha diferente. Escolher errado produz portais lentos, vazamento de dados ou codigo que trava quando o volume cresce.</p>\n<p><strong>Liquid: renderizacao server-side, antes da pagina chegar ao cliente</strong></p>\n<p>Liquid e a linguagem de template que o Power Pages avalia no servidor, durante o render da pagina. Tudo que voce monta com <code>{% fetchxml %}</code>, <code>entityview</code>, <code>entitylist</code> ou os objetos globais (<code>user</code>, <code>website</code>, <code>page</code>) acontece <em>antes</em> do HTML ser enviado ao browser. Isso tem consequencias praticas:</p>\n<ul>\n<li><strong>O dado ja chega renderizado</strong> — bom para SEO, porque o conteudo esta no HTML inicial, nao depende de JavaScript.</li>\n<li><strong>As table permissions sao aplicadas automaticamente</strong> quando voce usa <code>entitylist</code>/<code>entityview</code>. Com a tag <code>{% fetchxml %}</code> crua tambem ha enforcement, mas e mais facil escrever uma query que ignora o contexto do usuario se nao tomar cuidado.</li>\n<li><strong>Nao ha interatividade</strong> — cada mudanca exige recarregar a pagina. Liquid e para <em>exibir</em>, nao para montar telas dinamicas.</li>\n</ul>\n<p>Use Liquid para listas, detalhes, blocos de conteudo e qualquer coisa que precise aparecer no HTML por SEO ou por simplicidade. Evite montar logica de negocio complexa em Liquid — a linguagem e limitada de proposito.</p>\n<p><strong>Portal Web API: CRUD no browser, com table permissions aplicadas</strong></p>\n<p>A Portal Web API (distinta da Dataverse Web API de back-office) e o endpoint <code>/_api/&#x3C;entityset></code> que o portal expoe para chamadas AJAX autenticadas. E o caminho para interatividade: filtrar uma grid sem recarregar, salvar um formulario via fetch, atualizar um campo inline.</p>\n<p>Pontos criticos de arquitetura:</p>\n<ul>\n<li><strong>As table permissions continuam valendo</strong> — a Portal Web API respeita o mesmo modelo de web roles e escopos (Global, Contact, Account, Self) do resto do portal. Nao e um bypass de seguranca; e seguranca aplicada em outra camada.</li>\n<li><strong>Cada tabela e cada operacao (create/read/update/delete) precisam ser habilitadas explicitamente</strong> em Site Settings (<code>Webapi/&#x3C;table>/enabled</code> e <code>fields</code>). Se nao estiver ligado, a chamada retorna 403 — por design.</li>\n<li><strong>O dado NAO aparece no HTML inicial</strong> — e carregado por JavaScript depois. Pessimo para SEO de conteudo publico, otimo para areas autenticadas dinamicas.</li>\n<li><strong>Suporta OData</strong> (<code>$filter</code>, <code>$select</code>, <code>$expand</code>, <code>$top</code>), o que da paginacao e projecao de colunas no proprio request.</li>\n</ul>\n<p>Use a Portal Web API para tudo que e interativo e pos-login. Nao a use para montar paginas publicas indexaveis.</p>\n<p><strong>FetchXML: a linguagem de query por tras das duas</strong></p>\n<p>FetchXML nao e exatamente uma terceira camada de acesso — e a linguagem de consulta que alimenta o Liquid (<code>{% fetchxml %}</code>) e os <code>entitylist</code>/<code>entityview</code>. Entender FetchXML e o que separa um portal que consulta bem de um que faz N+1 e estoura o tempo de render:</p>\n<ul>\n<li><strong>Selecione so as colunas necessarias</strong> (<code>&#x3C;attribute name=\"...\"/></code>), nunca a tabela inteira. Cada coluna a mais e peso no payload e no plano de execucao.</li>\n<li><strong>Pagine</strong> com <code>count</code> e <code>page</code> / paging cookie. Listas sem limite que crescem com o tempo sao a causa numero um de portais que degradam em producao.</li>\n<li><strong>Cuidado com link-entity em cadeia</strong> — joins profundos em FetchXML renderizado a cada hit de pagina custam caro. Se a agregacao e pesada, materialize no Dataverse (rollup, coluna calculada ou um registro de resumo via plugin) em vez de recalcular no portal.</li>\n<li><strong>As table permissions ainda filtram o resultado</strong> do FetchXML em Liquid — mas uma query mal escrita pode tentar trazer muito e ser cortada de forma confusa. Teste sempre com um usuario de role restrita, nunca so com admin.</li>\n</ul>\n<p><strong>Um roteiro de decisao</strong></p>\n<ol>\n<li><strong>O conteudo e publico e precisa de SEO?</strong> Liquid server-side, com FetchXML enxuto e paginado. O HTML tem que sair pronto.</li>\n<li><strong>E area autenticada com interatividade (filtros, salvar sem recarregar)?</strong> Portal Web API via AJAX, com as tabelas e operacoes habilitadas em Site Settings e table permissions por web role.</li>\n<li><strong>E uma regra de negocio com efeito colateral (validacao server-side, integracao, transacao)?</strong> Nenhum dos tres sozinho — chame um Power Automate ou plugin no Dataverse a partir do formulario, e deixe o portal so apresentar o resultado.</li>\n<li><strong>A consulta ja esta lenta no render?</strong> Antes de trocar de camada, revise o FetchXML: colunas, paginacao, link-entity e cache (object cache do Power Pages ajuda muito em listas que mudam pouco).</li>\n</ol>\n<p>O erro mais comum em portais Power Pages nao e escolher a camada errada de forma obvia — e assumir que table permissions \"estao ligadas por padrao\". Nao estao: sem permissao configurada, usuario autenticado nao ve nada, e usuario anonimo muito menos. E o inverso tambem acontece: habilitar a Portal Web API em uma tabela sensivel sem restringir campos expoe dados que nunca deveriam sair do back-office.</p>\n<p>Estruturar o acesso a dados de um portal externo com a seguranca e a performance certas e exatamente o tipo de decisao que pesa quando o portal vai para producao com usuarios reais. Se sua empresa esta construindo ou revisando um portal Power Pages integrado ao Dataverse, a Dynamic Solucoes ajuda a desenhar essa arquitetura — da modelagem de table permissions ao tuning de FetchXML — pela nossa consultoria e pelos planos de suporte continuo.</p>\n<p>When a Power Pages portal needs to read and write Dataverse data, the question isn't <em>whether</em> it's possible — it's <em>through which layer</em>. The same record can be rendered via server-side Liquid, queried via Portal Web API in the browser, or pulled via FetchXML. Each path has a different security model, a different performance cost, and a different failure point. Choosing wrong produces slow portals, data leakage, or code that breaks when volume grows.</p>\n<p><strong>Liquid: server-side rendering, before the page reaches the client</strong></p>\n<p>Liquid is the templating language Power Pages evaluates on the server, during page render. Everything you build with <code>{% fetchxml %}</code>, <code>entityview</code>, <code>entitylist</code> or the global objects (<code>user</code>, <code>website</code>, <code>page</code>) happens <em>before</em> the HTML is sent to the browser. That has practical consequences:</p>\n<ul>\n<li><strong>The data arrives already rendered</strong> — good for SEO, because the content is in the initial HTML and doesn't depend on JavaScript.</li>\n<li><strong>Table permissions are applied automatically</strong> when you use <code>entitylist</code>/<code>entityview</code>. The raw <code>{% fetchxml %}</code> tag also enforces them, but it's easier to write a query that ignores the user context if you're not careful.</li>\n<li><strong>There's no interactivity</strong> — every change requires a page reload. Liquid is for <em>displaying</em>, not for building dynamic screens.</li>\n</ul>\n<p>Use Liquid for lists, detail views, content blocks and anything that needs to appear in the HTML for SEO or simplicity. Avoid putting complex business logic in Liquid — the language is deliberately limited.</p>\n<p><strong>Portal Web API: browser-side CRUD, with table permissions enforced</strong></p>\n<p>The Portal Web API (distinct from the back-office Dataverse Web API) is the <code>/_api/&#x3C;entityset></code> endpoint the portal exposes for authenticated AJAX calls. It's the path to interactivity: filtering a grid without reloading, saving a form via fetch, updating a field inline.</p>\n<p>Critical architecture points:</p>\n<ul>\n<li><strong>Table permissions still apply</strong> — the Portal Web API respects the same web roles and scopes (Global, Contact, Account, Self) as the rest of the portal. It's not a security bypass; it's security enforced in another layer.</li>\n<li><strong>Each table and each operation (create/read/update/delete) must be explicitly enabled</strong> in Site Settings (<code>Webapi/&#x3C;table>/enabled</code> and <code>fields</code>). If it's not on, the call returns 403 — by design.</li>\n<li><strong>The data does NOT appear in the initial HTML</strong> — it's loaded by JavaScript afterwards. Terrible for SEO of public content, excellent for dynamic authenticated areas.</li>\n<li><strong>It supports OData</strong> (<code>$filter</code>, <code>$select</code>, <code>$expand</code>, <code>$top</code>), giving you paging and column projection in the request itself.</li>\n</ul>\n<p>Use the Portal Web API for everything interactive and post-login. Don't use it to build public, indexable pages.</p>\n<p><strong>FetchXML: the query language behind both</strong></p>\n<p>FetchXML isn't exactly a third access layer — it's the query language that feeds Liquid (<code>{% fetchxml %}</code>) and <code>entitylist</code>/<code>entityview</code>. Understanding FetchXML is what separates a portal that queries well from one that does N+1 and blows the render budget:</p>\n<ul>\n<li><strong>Select only the columns you need</strong> (<code>&#x3C;attribute name=\"...\"/></code>), never the whole table. Every extra column is weight on the payload and the execution plan.</li>\n<li><strong>Paginate</strong> with <code>count</code> and <code>page</code> / paging cookie. Unbounded lists that grow over time are the number-one cause of portals that degrade in production.</li>\n<li><strong>Watch out for chained link-entity</strong> — deep joins in FetchXML rendered on every page hit are expensive. If the aggregation is heavy, materialize it in Dataverse (rollup, calculated column, or a summary record via plugin) instead of recomputing it in the portal.</li>\n<li><strong>Table permissions still filter the FetchXML result</strong> in Liquid — but a badly written query can try to pull too much and get cut off in confusing ways. Always test with a restricted-role user, never just as admin.</li>\n</ul>\n<p><strong>A decision checklist</strong></p>\n<ol>\n<li><strong>Is the content public and does it need SEO?</strong> Server-side Liquid, with lean, paginated FetchXML. The HTML has to come out ready.</li>\n<li><strong>Is it an authenticated area with interactivity (filters, save without reload)?</strong> Portal Web API via AJAX, with the tables and operations enabled in Site Settings and table permissions per web role.</li>\n<li><strong>Is it a business rule with side effects (server-side validation, integration, transaction)?</strong> None of the three alone — call a Power Automate flow or a Dataverse plugin from the form, and let the portal just present the result.</li>\n<li><strong>Is the query already slow at render?</strong> Before switching layers, review the FetchXML: columns, pagination, link-entity, and cache (Power Pages object cache helps a lot on lists that change little).</li>\n</ol>\n<p>The most common mistake in Power Pages portals isn't picking the wrong layer in an obvious way — it's assuming table permissions are \"on by default\". They aren't: without a configured permission, an authenticated user sees nothing, and an anonymous user even less. And the reverse happens too: enabling the Portal Web API on a sensitive table without restricting fields exposes data that should never leave the back-office.</p>\n<p>Structuring an external portal's data access with the right security and performance is exactly the kind of decision that bites when the portal goes live with real users. If your company is building or reviewing a Power Pages portal integrated with Dataverse, Dynamic Solucoes helps design that architecture — from table permission modeling to FetchXML tuning — through our consulting and ongoing support plans.</p>"}},"pageContext":{"slug":"/blog/power-pages-liquid-web-api-fetchxml-dataverse-acesso-dados/","previousPost":null,"nextPost":{"frontmatter":{"title":"Dataverse: solution layers e managed properties sem surpresas"},"fields":{"slug":"/blog/dataverse-solution-layers-managed-properties-alm/"}}}},"staticQueryHashes":["2269431855"]}