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.
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.
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.
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 second 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 describe how we go about getting the SharePoint folder location for the current Case on the Edit Case page.
One of the big things we’ve talked about during the transition from Adxstudio Portals v7 to the Portal Capabilities for Dynamics 365 v8 is losing the ability to include server-side code in your website project. There are ways around this limitation – typically we recommend using a Dynamics 365 Portals Companion App. However, there is another technique, which we’ve always considered a bit of a hack, but not only does it work, Microsoft is using the technique in their own Portals. So if they can do it, why not us?
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.
