I’ve been asked a few times about how you can add a rich text editor to Entity Forms or Web Forms on Power Apps Portals, and while I haven’t had the need to do this for a real implementation, I was curious to try it out. In the process, I found out about a setting I didn’t know existed that’s been around for at least a few years.
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.
For the most part, Entity Lists try to mirror the functionality of the selected model-driven form in CDS. This means that certain settings on the model-driven form can have a significant impact on how things work in Power Apps Portals, event if it is not obvious at first. In this post, I’ll cover one of those not-so-obvious (at least to me) settings – Show Related Records.
For the most part I don’t blog about the (roughly) monthly releases for Power Apps Portals, mostly because they deal with bug fixes for relatively obscure issues. However, last month I was happy to see a few items on the list that I’ve been waiting for, and I thought were worth sharing.
My latest article for MSDynamicsWorld.com was published today. It talks about the Power Apps Portals-related features in the 2020 Wave 1 Release Plans announced by Microsoft today, including updates to the Power Apps Portals Studio, and the CRUD API we’ve all been waiting for!
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.
One of the most frustrating things that can happen when developing any type of software is when you’ve got the code correct but, due to it being in the wrong place, it doesn’t work as you’ve expected. A recent question on the community forums highlights the importance of putting your JavaScript in the right place.
A question popped up a couple weeks ago about the best way to force everyone to have to login to your Power Apps Portals before getting access to anything. At first I gave a very wrong answer – thankfully MVP Nick Doelman corrected me, and in the process, we all learned another thing about licensing.
Caching has long been a hot topic when it comes to the Portals technology – so much so that it used in the name of top rated Power Apps Portals podcast “Refresh the Cache” hosted by MVPs Nick Doelman and Colin Vermander. So what is caching, why is it important for Power Apps Portals, and what’s changed about it recently?
