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.
My latest article for MSDynamicsWorld.com was published today. It talks about the October ’18 release of the Dynamics 365 Portal product, which includes SharePoint and PowerBI integration, as well as some of the other exciting things to look forward to in future releases, including availability within CDS environments, client-side SDK and sandbox licenses.
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.
