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 a comparison between the two.
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.
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.
