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.
I’ve been asked a few times recently about my recommendations for customers who aren’t using Dynamics 365 Online but still want portal functionality. In this post I’ll present some options and provide my two cents.
The April ’19 Release Notes we’re published on Monday – at over 300 pages, there is a lot to digest! In this post I’ll discuss highlights related to the Dynamics 365 Portal product, including CDS starter portal, maintenance mode, PowerBI enhancements, and more!
A question that pop ups from time to time is the difference between restarting a Microsoft Dynamics 365 Portal, and resetting it. The concern is typically around losing any of the customizations or configurations you’ve performed if you do either of those two things. Let’s look at the difference between these two 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.
2018 was a busy year for the Dynamics 365 Portal product! From the end-of-life of Adxstudio v7 to the release of new features like SharePoint and PowerBI integrations, I’ll cover the most exciting developments throughout the year.
During last week’s eXtreme365 event in Austin, Texas, I was lucky enough to co-present a session with Nikita Polyakov (a Senior R&D Solution Architect at Microsoft, with a focus on Dynamics 365 Portal implementations). One of the tips he mentioned during the session was about using Liquid to decide which Entity Form to display on a page – it’s a very cool technique that seems to be underused. Then, a question showed up on the Dynamics 365 Community forums where that technique could be used to solve the problem. So I figured I’d write a quick blog post to get the word out on using Liquid to determine which Entity Form to display on a page.
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.
While working on my series about all the places you can put your code in a Dynamics 365 Portals implementation, I ran into an odd quirk with regards to how Liquid is handled in the Custom JavaScript attribute of Entity Lists. I did a bit of digging, and was able to figure out why in some instances, Liquid code is evaluated as you’d expect, and in other cases, it is not.
