If you follow us on social media, hopefully you’ve seen that we at Engineered Code shared some exciting news this week. We announced ecLearn, a learning management system (LMS) built on top of Microsoft Dataverse. In this blog post I’m going to give you a bit of a glimpse into the ecLearn journey.
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.
When using the Microsoft-provided PowerShell scrips to assist with an upgrade from Portals v7 to v8, there are a few known issues that could still leave your data in an undesirable state. We’ve released an XrmToolBox plugin to help address a couple of those items.
In a previous blog post I mentioned how it can be useful to use the Portals Source Code release to actually step through Portal source code in a debugger. However, there are more great uses for the Portals source code, even if you are using the official Microsoft-hosted option.
In a January blog post on upgrading to the xRM Portals Community Edition, I promised to look into automatic cache invalidation. It only took a few months, but I’m finally delivering on that promise.
If you’ve done any work with Dynamics 365 Portals, you’ve probably run into the dreaded “We’re sorry but something went wrong” white screen of death. In this post I’ll share the tricks I’ve used to get more details about the error without contacting Microsoft support.
When one of our clients who is using xRM Portals Community Edition wanted to batten down the hatches from a security perspective, we discovered that a core JavaScript file of Dynamics 365 Portals is being served with the incorrect content type.
Having gone through the entire process of upgrading a customer from Adxstudio v7 to xRM Portals Community Edition, I’d like to share what I’ve learned so that it might make your upgrade process a smoother experience.
