I’ve been spending a lot of time on Dynamics 365 Portal performance recently, and I was able to dig a bit into a topic that I thought was worth sharing: the output caching of the header and footer templates. If that doesn’t catch your attention, how about the fact that it involves donuts?
I spent last week in Amsterdam attending both eXtreme365 and the User Group Summit, and was lucky enough to get to present three sessions on Dynamics 365 Portal topics. At each one of these sessions, one of the areas that generates the most interest is when I discuss the idea of a Companion App. Companion Apps are a technique you can use to leverage server-side code in your Portal implementation, and since it’s a topic I haven’t really covered on my blog, I thought it was about time.
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.
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 previous blog post, I talked about looking at the page-specific attributes like Copy, Summary, Custom JavaScript and Custom CSS when you’re searching for where the code is being saved. In this post, I touch on a few other places, such as Entity Forms, Entity Lists, Web Files and Content Snippets.
In my previous blog post, I talked about the overall page structure for a Dynamics 365 Portals page, and the main elements included in the rendered page, including the Header, Footer, and the Page Content. In this post, I get into the details about where code might be within the Page Content.
When someone first gets started with the Portal capabilities for Dynamics 365, one thing I’ve noticed that can be a bit overwhelming is how many different places you can put a piece of HTML, JavaScript, Liquid, etc to achieve the same result. In this series of posts, I describe some of the options, and provide some 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.
