If you follow us on social media, hopefully you’ve seen that we at Engineered Code shared some exciting news this week. We announced ecLearn, a learning management system (LMS) built on top of Microsoft Dataverse. In this blog post I’m going to give you a bit of a glimpse into the ecLearn journey.
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.
This month I’m continuing my series on looking at how functionality is built into the new templates available for Power Pages. In this post I looking at the Program Registration template, which allows users to browse and sign up for classes, and is useful in scenarios such as an after school program. Specifically, I’m going to look at the functionality that allows users to search through the available classes.
While there is a lot you can do with the out-of-the-box capabilities of list and forms with Power Pages, pretty often on projects you do run into cases where you need more than what you can do with just configuration. In these cases, Liquid and JavaScript are often used to help you meet requirements. While there aren’t too many choice to make when using Liquid, the same can’t be said for JavaScript. In this blog post, I’ll look at some different options for writing client-side code with Power Pages.
If you’ve come from the world of Dynamics 365 (or CRM…) and are starting to work with Portals, it can be frustrating when you discover that client-side JavaScript code that works great in your model-driven app doesn’t work on a Power Apps Portal – especially because Entity Forms and Web Forms are marketed as a technology that exposes your existing forms to the web. This post we look at why it doesn’t translate, and provide some code that solves a common request: modifying the available options in an option set.
The topic of my first Portals Community Call back in January was the how to build a portal that allows a customer to view and print invoices. While solutions for this has been described by others (including Megan V. Walker’s excellent post), I also presented a different approach that I thought was worth covering in a blog post so that I could get a bit more into the technical details.
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.
A topic I find that often leads to confusion for those new to Dynamics 365 Portal development (and even for those who have been doing it for a while) is the various options for displaying an Entity List or an Entity Form on a page. So in this week’s post, let’s look at the options.
