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.
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.
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.
Despite my preference for using CSS to customize the user experience for a Dynamics 365 Portal, as expressed in my last post, unfortunately CSS can’t do everything. Continuing on with the theme of the Dynamics 365 Portal integration with SharePoint, this post talks about using JavaScript to perform additional validation on the uploaded files.
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.
As most Dynamics 365 Portal developers start as CRM developers, we often try to take the same approach to solve similar problems on both platforms. However, it’s important to remember that a D365 Portal implementation is using different technologies, and sometimes there is a better way. Case in point – consider using CSS instead of JavaScript to control visibility of out-of-the-box features you don’t want.
In my last post in the series on all the different places to look for Dynamics 365 Portals code, I discuss our best practices.
In my third post in the series on how you can add an integration with SharePoint to the Employee Self-Service Portal in Dynamics 365 without using server-side code, I’ll dive into using the SharePoint REST API to display documents in a folder related to a record in Dynamics 365.
In this post I go through some of our favorite platforms for building portals, and I’ll let you know what we love, and what we don’t, about each one of them.
