In this series of blog posts, I’m looking at the ways to enable an asynchronous conversation between Dynamics/Power Apps users and portals users. The two most common techniques I see use Entity/Web Form Metadata – either the Notes or Timeline metadata option. This post covers the newer way – using the Timeline metadata option.
In this series of blog posts, I’m looking at the ways to enable an asynchronous conversation between Dynamics/Power Apps users and portals users. The two most common techniques I see use Entity/Web Form Metadata – either the Notes or Timeline metadata option. This post covers the original way – using notes.
In many cases, allowing for a “conversation” between your Dynamics/Power Apps model-driven app users and your Power Apps Portals users is a requirement for a portal. For example, once a description is entered into a Case, often a back-and-forth is required in order to lead to its successful resolution. In Power Apps Portals, the two primary ways to achieve this functionality is by leveraging either the Notes or the Timeline options of Entity or Web Form Metadata. In this series of posts, I’ll look at these options in more details.
The Web Forms functionality lets you build complex multi-page, multi-entity wizard-style forms on your Power Apps Portals. And while there are a ton of options, it’s not uncommon to run into situations where you can’t do everything you want with configuration, so you might need to resort to a bit of JavaScript (and maybe even Liquid). One of those situations is if you want the source entity for the next step in your Web Form to be a record related to the entity of the current step.
The power of Entity Forms in Power Apps Portals is that they mirror much of the functionality available in model-driven apps (and Dynamics 365). While the parity isn’t 100%, one advanced feature that Entity Forms does support is Related Records Filtering on lookups, where the available options in the lookup are filtered by some other data that has already been selected. However, in certain cases, this functionality doesn’t offer exact parity out-of-the-box – one of those cases is when you are creating a new record via a subgrid, and you’re expecting that the parent record is used in the filtering of the lookup.
I’ve always been an advocate for using CSS to control the visibility of out-of-the-box Power Apps Portals features. Unfortunately, sometimes CSS isn’t enough, and you do have use JavaScript. And even then, sometimes you have to resort to some exotic techniques – one of those times is customizing some aspects of how notes and activities are rendered on Power Apps Portals.
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.
