There are certain cases where you can do everything you’d think is required to setup an editable Entity Form, yet for some reason it keeps appearing as read-only. In this post, I’ll explain why. Spoiler alert: I don’t have a great workaround for this problem, but to save some other people the headache of trying to figure out what’s going on, I thought I’d put together a quick post.
A couple of weeks ago I shared a solution for supporting multiselect option sets on a PowerApps Portal (they aren’t currently supported out-of-the-box), however it only worked for creating new records. If you want it to work for updating existing records, there is a bit more work to do, but thankfully not that much!
Everyone rejoiced when multiselect option sets were added in Dynamics 365 for Customer Engagement v9. Unfortunately, PowerApps Portals/Dynamics 365 Portals do not yet support these field types out-of-the-box on Entity Forms or Web Forms. In this post, I’ll describe how, which a bit of code, you can add that support yourself, and demonstrate a particular pattern that can be used to add sophisticated UI elements to your Portal.
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.
As a follow-up to last week’s post on conditional action buttons, I wanted to dive a bit deeper into a very cool, but completely undocumented feature that exists in the Dynamics 365 Portal product: the Filter Criteria for action buttons.
A question was asked on the Microsoft Dynamics 365 Community forums about how to hide or show a workflow action button based on the current user’s role, and since there are a few different ways to do this, I thought it was worthy of a blog post.
