Advanced Field Control in Power Pages Using JavaScript and Liquid – Real Scenarios from Projects

While working on Dynamics 365 Power Pages implementations, I realized very quickly that portal metadata alone cannot handle complex business requirements. Basic field visibility rules are easy, but real-world forms demand dynamic behavior that depends on user role, record data, multi-select options, and business logic.

This is where combining JavaScript (client-side control) with Liquid (server-side logic) becomes powerful.

This article shares practical scenarios where this approach made the solution possible.

Why Configuration Alone Was Not Enough

Portal Management allows:

• a. Basic field visibility
• b. Required fields
• c. Read-only control

But in my projects, requirements looked like this:

• a. Show 3 additional fields only when two specific options are selected in a multi-select
• b. Change a field label dynamically based on the logged-in user type
• c. Lock a section once a case reaches a specific status
• d. Display manager-only questions inside the same form

These are not achievable with metadata alone.

Role of JavaScript vs Liquid (How I Use Them)

Liquid decides what context the page loads with.
JavaScript controls what happens after the page loads.

Scenario 1: Multi-Select Option Controls Multiple Fields

Requirement:
If a user selects “Service Issue” AND “Billing Issue” in a multi-select, show an escalation section.

Problem: Metadata rules cannot evaluate multiple selections together.

My Approach:

• a. Hide escalation fields by default
• b. Use JavaScript to read selected options
• c. Show section only when both values exist

This improved user experience and prevented unnecessary data entry.

Scenario 2: Role-Based Form Behavior

Requirement: Managers should see approval fields; normal users should not even know those fields exist.

Why Liquid Helped:
Portal roles are determined server-side, so I used Liquid to pass a flag to JavaScript.

{% if user.roles contains 'Manager' %}
<script>var isManager = true;</script>
{% else %}
<script>var isManager = false;</script>
{% endif %}

Then JavaScript handled visibility accordingly.

This ensured:

• a. Clean UI
• b. No role-check delays
• c. Better performance than API calls

Scenario 3: Locking Fields After Status Change

Requirement: Once a case moves to “Submitted”, users should only view, not edit.

Solution Design:

• a. Liquid checks record status when page loads
• b. If status = Submitted → pass a lock flag
• c. JavaScript disables fields dynamically

This approach avoided creating multiple forms and kept maintenance simple.

Scenario 4: Dynamic Label Changes

Requirement: Label should say:

• a. “Employee ID” for internal users
• b. “Reference Number” for external users

Instead of duplicating forms, JavaScript updated the label text based on user type passed via Liquid.

Preventing the Common Mistake

JavaScript improves UX, but it does not secure data. I always ensure final validation also exists in:

• a. Dataverse business rules
• b. Plugins
• c. Power Automate

Portal scripting is the first layer, not the only layer.

Lessons Learned from Real Implementations

• a. Run scripts only after the form fully loads
• b. Avoid mixing too many metadata rules with JS logic
• c. Handle portal caching during testing
• d. Always consider performance when adding scripts

To encapsulate, Power Pages becomes truly flexible when JavaScript and Liquid are used together with clear responsibility boundaries. Liquid prepares the context; JavaScript handles the interaction.

In my experience, this combination bridges the gap between standard configuration and complex business needs without overcomplicating the architecture.

Custom portal behavior is not about more code but it’s about placing logic at the right layer.

If you found this useful and are working on similar Power Pages scenarios, feel free to connect or reach out to the CloudFronts team – transform@cloudfronts.com, for deeper discussions on advanced Dynamics 365 implementations.