The fetchxml Liquid tag is arguably the most powerful Liquid tag in Power Apps Portals – it allows you to meet complex requirements for the display of data. But, if you combine it with a complex Entity Permissions model, you could find yourself getting unexpected errors. In this post I’ll cover what can cause those errors, and how to work around them.
PowerApps Portals offers two primary languages for customization: JavaScript and Liquid. This leads to confusion as to which technology should be used when – I’ll try to clear up some of that confusion in this blog post, as well as demonstrate that is many cases, the best option is a combination of the two.
There are some areas of PowerApps Portals that are still implemented using either ASP.NET MVC or ASPX, instead of via Web Templates, which means the configurability options are limited – one of those is the Knowledge Base (which exposes Knowledge Article entities). Often we can use Liquid and JavaScript to customize some of these areas, but there is one thing in particular that makes doing this for the Knowledge Base challenging – in this post I’ll explain what that is, and how to get around it.
During last week’s eXtreme365 event in Austin, Texas, I was lucky enough to co-present a session with Nikita Polyakov (a Senior R&D Solution Architect at Microsoft, with a focus on Dynamics 365 Portal implementations). One of the tips he mentioned during the session was about using Liquid to decide which Entity Form to display on a page – it’s a very cool technique that seems to be underused. Then, a question showed up on the Dynamics 365 Community forums where that technique could be used to solve the problem. So I figured I’d write a quick blog post to get the word out on using Liquid to determine which Entity Form to display on a page.
While working on my series about all the places you can put your code in a Dynamics 365 Portals implementation, I ran into an odd quirk with regards to how Liquid is handled in the Custom JavaScript attribute of Entity Lists. I did a bit of digging, and was able to figure out why in some instances, Liquid code is evaluated as you’d expect, and in other cases, it is not.
Recently I was asked about executing a FetchXML query using the Web API in Power Pages, and while you won’t find any specific documentation on that in the Power Pages documentation, you’ll be happy to know that it is supported. In this blog post, I’ll look at how its done.
Recently there was a comment on my blog Power Apps Portals: Related Entity as Source of Next Web Form Step about adding a custom Edit button to a list or subgrid. In this case, rather than editing the main row in the table, they wanted to edit a row that was related to the main row. If you want the edit form to pop up in a modal, it requires a bit of JavaScript. In this post, I’ll go through what you need to do in order to achieve this functionality.
This month we continue our look at some of the pro code techniques that appear in the templates available for Power Pages. This time we’re going to look at the “Schedule and Manage Meetings” template, which provides a multistep form for booking a meeting. This form has lots of pro code goodies in it, so this won’t be the only post, but for now, we’re going to look at the first step in the form where the user chooses what type of meeting they want to have.
Independent Software Vendors (ISVs) have been an important part of the Microsoft Business Applications space for a long time. ISVs create solutions that build on top of the platforms and products that Microsoft provides off-the-shelf. As the Power Platform has continued to grow and evolve, more opportunities have presented themselves for ISVs. In this post, I’ll look at what ISVs might want to consider when looking at incorporating Power Pages as part of their offering.
