Microsoft decided to make the October ’18 release notes available while I was on vacation (it’s like they didn’t even consider my schedule!), so I’m a bit late on this, but here are my thoughts on what to expect in the fall when it comes to the Portal capabilities for Dynamics 365.
The Portals-specific pages for the October ’18 release notes can be found here. It should be noted that all features, except the simplified customization, are scheduled for general availability in October 2018. The simplified customizations will be in public preview at that time.
I’ll start with the most exciting one – we’ll finally have SharePoint integration natively in Portals! This is by far the most requested feature we run into, so it’s great that it will be available out-of-the-box.
With Adxstudio Portals v7 no longer supported (as of August 1, 2018), this fills one of the big gaps between v7 and the Microsoft version (the other being, in my opinion, ecommerce).
The functionality appears similar to what was available in v7; essentially, you can place a grid that will display the SharePoint documents on an Entity Form or a Web Form. It also supports displaying/creating folders, and uploading new files.
Some might consider this feature even more exciting that the SharePoint integration – it certainly can lead to some very impactful visuals! With the ability to embed Power BI directly into Portals, your Portal users can have access to interactive visualizations.
From the description it seems like embedding the Power BI visualizations will be done via Liquid (similar to how charts currently work), and will include the ability to use filter parameters to personalize the views to the contact.
Anyone who has gone through at least one Portals project has probably had a thought similar to: “if having dev, test and prod is good development practice, how is there no simple way of customizing a portal in dev and moving those changes to the other environments?”
The problem lies in fact that much of a portal configuration is kept in Dynamics 365 data/records, which are not generally solution aware. So while you can move the forms and views between environments using solutions, for example, the Entity Form and Entity List definitions don’t follow in the same way.
In Portals v7, a program called Website Copy Utility existed, however it was only really meant for copying entire websites. This worked fine the first time you wanted to move changes from dev to test or prod, but it didn’t have any edit or upsert capabilities to keep things in sync after the initial launch.
For a while Microsoft has maintained a utility called the Configuration Migration tool which was designed to assist in migrating configuration data between environments, which sounds like exactly what we need. However, due to the complexities of the Portals data schema (a lot of cyclical relationships), our experience with it has been mixed. Also, it’s a fairly complicated tool, which can add significant overhead on a small Portals project.
As part of the October ’18 release, Microsoft will be providing a schema for the Configuration Migration tool designed specifically for Portals. The schema defines which entities are migrated, and can be time-consuming and error-prone to setup correctly for the first time. This should give people a huge head start as compared to starting from scratch.
Put simply, this feature will let you define a list of IP addresses (or IP address ranges) that can access your portal. If you’ve turned this feature on, and someone tries to access the portal from an IP address not on your list, they will get a 403 error.
To me, this sounds like a feature that was implemented because a large project required it and was worth Microsoft implementing it. It’s not something that we’ve heard people asking for. That being said, once it is available it will probably become standard practice to limit development instances whenever feasible. Also, making the portal only available to internal users is an interesting use case and may allow you to avoid forcing a login to protect content if you want anyone in the organization to view it, but restrict public access. However I feel like with so many people working from outside an office, using IP address for restricting content could be more trouble than it’s worth.
Microsoft isn’t providing a lot of specifics on this item, but I’m encouraged that it sounds like they will be focusing on the content authoring experience, something that hasn’t been a priority in a long time.
While the Portal capabilities for Dynamics 365 is well known to have come from the acquisition of Adxstudio in 2015, some may not know that before they built Portals, Adxstudio developed a stand-alone .NET/SQL Server-based content management system (CMS). It was based on this experience that Adxstudio developed Portals, once they saw the opportunity of the XRM platform. However, the focus of the product quickly changes from a CMS to an application platform for building functional portals. Since then, the basic CMS capabilities have been largely untouched, and nowhere near as sophisticated as the previous Adxstudio CMS product.
Now, Microsoft has been quite clear that they don’t see the portal capabilities for Dynamics 365 as a traditional CMS, and they don’t recommend using it for public corporate websites (although this is something we did all the time with v7), and I’m not advocating that they change this position, but it still think that there is some room for improvement in the authoring capabilities without going too far down the rabbit hole. So I’m excited about some of these features becoming a bit more polished.
The specifics are lacking a bit here too, but I love where this is going: providing more tools to allow Portals developers to troubleshoot their own issues.
It’s no secret that it’s possible to take down an entire portal with just a small configuration error. Other recent new features like turning off custom error pages and saving logs to Azure have been great, but anything more that will help us avoid submitting tickets to Microsoft when something goes wrong will definitely be appreciated.
There was also mention that due to platform changes, “Dynamics 365 Portal is now more reliable and performant than ever.” As compared to a few years ago, I’d definitely have to agree. It feels like the caching issues have mostly been sorted out, and while it’s still not the speediest platform in the world, in general it seems to be acceptable. That being said there is still room for improvement so, hopefully, the best is yet to come.
[…] post Portals and the October ’18 Release Notes appeared first on Engineered […]