Calling Server Logic from Liquid: the full circle in Power Pages

The tag

{% serverlogic name: 'installation-products',
             operation: 'getInstallationProducts',
             output: result %}

{% if result.success %}
  <ul>
  {% for inst in result.data.installations %}
    <li>{{ inst.name | escape }}</li>
  {% endfor %}
  </ul>
{% endif %}

Four parameters: name (the server logic record), operation (the JavaScript function to run, any function you define, not just get), input (optional string, JSON when you need structure), and output (the Liquid variable that receives the result). The result object carries success, status_code (500 on an execution error), data (the parsed JSON your operation returned), and raw_result (the unparsed response, for when the return value is not valid JSON).

The key line from Microsoft's docs: this server-side invocation "doesn't require a client-side HTTP request or Cross-Site Request Forgery (CSRF) token." Assign the server logic record to a web role the current user can access, and the tag does the rest at render time.

The full circle, live

I built exactly this in the demo portal: a web template with the tag above, calling an operation that reads the N:M relationship from part one and returns a compact list. Signed in as a portal user, the page renders the linked products server-side:

Same data as part one (Pump A, Valve B under an installation), same server-side Dataverse connector as part two, now rendered directly into the page by Liquid. That is the circle closed.

One function, two contexts

Here is the detail that saves you an afternoon. The same server logic function can be called two ways, from the client over HTTP and from Liquid, but it reads its input from two different places:

• Called over HTTP: Server.Context.QueryParameters["id"], plus Body, Headers, HttpMethod.
• Called from Liquid: Server.Context.Input, the string you passed in the tag's input parameter.

If you write one operation for both entry points, branch on the input source. QueryParameters is empty in a Liquid invocation, and Input is empty over HTTP.

Two things the docs do not spell out

I hit both while building the live example, so you do not have to.

function getInstallationProducts() {
  var options = "$select=pwrprtl_installation_name" +
    "&$expand=pwrprtl_installation_product($select=pwrprtl_product_name)";
  var res = Server.Connector.Dataverse.RetrieveMultipleRecords("pwrprtl_installations", options, true);
  var envelope = (typeof res === "string") ? JSON.parse(res) : res;
  var odata = (typeof envelope.Body === "string") ? JSON.parse(envelope.Body) : envelope.Body;
  var rows = (odata && odata.value) ? odata.value : [];

  var installations = [];
  for (var i = 0; i < rows.length; i++) {
    var prods = rows[i].pwrprtl_installation_product || [];
    var names = [];
    for (var j = 0; j < prods.length; j++) { names.push(prods[j].pwrprtl_product_name); }
    installations.push({ name: rows[i].pwrprtl_installation_name, products: names });
  }
  return JSON.stringify({ installations: installations });
}

Security: no CSRF is not no responsibility

Skipping the CSRF token is safe here because the call never leaves the server; there is no cross-site request to forge. But the operation still runs in the current user's context and respects web roles and table permissions, and the authorization decisions are still yours. Microsoft is explicit: treat input and returned values as untrusted. Validate Server.Context.Input before it touches a query, and apply the escape filter before rendering any returned string into HTML, exactly as in the tag above.

And the one real cost: the tag runs while the page renders, so a slow Dataverse query or external call increases page response time. That is the trade you make for server-side rendering. When responsiveness matters more than first paint, keep the client call from part two.

Three server-side ways, one decision

FetchXML is the quickest path for a plain query. The moment the logic is worth reusing or unit-testing, {% serverlogic %} gives you that at render time, and the same operation answers a client call after load. Three tools, one mental model: decide by when the user needs the data and how much logic sits behind it. That is the arc, closed.

Related articles

Sources

• Microsoft Power Platform blog: Extend Liquid with Server Logic in Power Pages (the announcement)
• Microsoft Learn: serverlogic Liquid object (syntax, parameters, result attributes)
• Microsoft Learn: Author server logic, call from Liquid ("doesn't require a client-side HTTP request or CSRF token"; render-time cost note)
• Microsoft Learn: Server objects, Context (Server.Context.Input for Liquid vs QueryParameters for HTTP)
• Hands-on in the Power Portals demo portal: a web template invoking a server logic operation via {% serverlogic %}, rendering the N:M list server-side, verified live (result.success true, status_code 200)