PowerApps and Dynamics Portals Design Decisions

A lot has been said and written about ‘Portals’ since Microsoft bought ADX Studio in 2015. If you are unaware of the background, ADX Studio at the time was the de-facto market leader and default solution for building portals to front and expose data from Dynamics CRM.

With the ADX Studio product being built in a configurable way, it seemed like a good acquisition from Microsoft. This was a departure from earlier acquisitions of  technically different products which had to be integrated to Dynamics – see Parature (cough) or Marketing Pilot (splutter), which have since died a slow death. ADX Studio was a product that, on the face of it, could more easily integrate and slot in to the new approach.

Since 2015, Microsoft has been on a journey to integrate and extend this old ADX codebase onto what has since become Dynamics 365 and, more recently, the Power Platform. ADX Studio in its old form – a .NET website and configurable code framework – is now effectively dead* – the Microsoft shift to the cloud is nearing completion, with new features being added regularly.

Upgrades can cause Downgrades

Unfortunately, with a migration from a service provider hosted offering to one more tightly Microsoft controlled, some ‘downgrades’ occurred as Microsoft’s technical and functional roadmap became clear. Some features were removed while new features were added. Back in 2015, there were some pre-baked ADX Portals – for example Retail Portals, Partner Pipeline Portals and Government 311 portals. None of these exist anymore in their previous form.

As well as some of these starter portals disappearing, the ability for developers to get their hands dirty when building portals decreased. ADX Studio was easily extendible by traditional .NET developers and website journey builders, so more customisable. There is no longer this flexibility with cloud portals – ironically however, this can be a good thing.

Regardless of whether you use Microsoft Dynamics Portals or Power Apps Portals (which are technically the same product under the hood), anyone who implements a portal is likely to have design decisions which involve more functional and user story considerations than the traditional technical decisions I have mentioned above.

In the past, a critical design question may have been ‘Should I configure or customise my portal’? However, for public facing websites, the question is more likely to be firstly  ‘How can I meet my ideal Customer Journey’ followed by ‘How can I meet my ideal Customer Journey using a customisation first approach’?

What is a Portal anyhow?

A portal may mean one thing to one person and something completely different to another. In this regard, a portal is less of a technology and more of a marketing term that implies the provision of a one-stop shop for some or all of your customer transactions, whether authenticated or unauthenticated. A portal could contain :

• All the static content from your old decomissioned website
• Links to content in your still to be maintained main site
• Authenticated access to customers for Dynamics and PowerApps data
• Form Generation of leads from unauthenticated users
• Some or all of the above

The approach to implementing a new portal may differ based on where you are coming from and the architecture you have in place at the minute.

Configuration First v User Journey First Portals

A logical approach for the building of any portal is to begin with a configuration first approach, where Citizen Developers can take a no-code / low-code approach and take ownership of the portal functionality going forward. This approach may have a downside – should you build a portal in a way where it is primarily configurable, at the expense of an optimal user journey? Or should you build a portal considering the user journey first, with less of a focus on configuration and customise, knowing that it may have implications for ‘technical debt’?

Traditional User Journey Mapping

Herein lies one problem perception with Dynamics 365 and Power Platform Portal projects. For any organisation who wants a portal solution, the primary features an organisation often wants is to ensure that the website a) ‘looks amazing’ and matches any existing or new style branding and b) maps to whatever user journey research has been carried out or is in the process of being carried out.

It’s no good having a portal with a 100% configurable backend if the user is unimpressed or doesn’t use it. Traditional web developers who build non-Dynamics based websites are used to having  granular control of every last pixel and line of back-end code to achieve their aims. When the customer or pilot end user says “we absolutely must have this icon 26 pixels to the right and we want a splash screen here to pop up here only for people with these interests every Thursday”, the generic web developer will know how to slot (or hack) this into a non Dynamics website. For a web developer with no Dynamics experience faced with implementing one, they may initially find themselves scratching their head.

How customisable are Power Apps Portals for generic Web Devs?

The approach to styling has not changed dramatically now compared to the ADX Studio days. Any web designer should be easily able take, amend or replace the Bootstrap CSS to give a portal a different look. There is a learning curve for traditional web developers, in terms of needing to learn how to navigate the Dynamics 365 interfaces to manage and understand portal settings, but once they are over that short hurdle, the principles and practicalities of front-end web development are the same. It’s a mindset shift for traditional web developers who are often more used to developing from scratch or a bottom up framework they love to use. I often find however, because portals are pitched at citizen developers without these skills, that portals end up being minimally changed or styled.

Portal Web designers often need to understand :

• The overall architecture of Portals and Dynamics
• Understanding formation of Pages, Web and Page templates and other traditional ADX concepts.
• Understanding how to update CSS, JavaScript and other dynamic data techniques such as Liquid templates.
• New features coming from Microsoft so they don’t duplicate effort.

For background, a highly recommended listen is a recent CRM Audio podcast with Dileep Singh, Principal Programme Manager for PowerApps Portals. Dileep explained some of the rationale behind the Dynamics Portal and PowerApps portal roadmaps and features. In the same way Dynamics 365 has progressed in the past two years, the Portal framework and architecture is now becoming more mature. Some simple things like auto cache refreshing during Portal App development now streamline web developer portal development tasks. The fact that the new PowerApps Portal design tools are now more front end, drag and drop focused means you can see where the product is going. But until there is a theming engine for portals, traditional design skills are necessary to get rid of that ‘out of the box’ look.

If I have the design skills, should I use PowerApps for all my web content?

One common question is whether Portals is mature enough to replace an entire existing Content Management System. The answer is, it depends. Consider the following?

• Do you have an existing website style and brand you are happy with?
• Is your website mostly static content with little additional functionality?
• Do you have a minimal need to update content, blogs or news?
• Is your main use case for an authenticated portal to serve Dynamics 365 / PowerApps data?

If you can answer yes to these questions, Portals could be used for all your content. If you need more features, then traditional technologies may also be required.

What if I need more traditional (Content Management System) CMS features?

If you need traditional CMS features for static content, then your PowerApps portal may sit better alongside a traditional CMS such as PHP based WordPress, Joomla, Magento or Drupal or a stack aligned .NET CMS such as Kentico.

Traditional CMS have advantages that PowerApps Portals do not yet have, such as

• Mature approval process for content.
• More extensive pre-packaged theme support – ability to use off the shelf themes which can be easily tweaked to fit brand guidelines.
• An ecosystem for plugins for niche functionality.

Using a hybrid approach you can often have the best of both worlds. For this reason, many organisations have an easily updatable CMS website at http://www.contoso.com alongside a companion and aesthetically identical portal at the portal.contoso.com subdomain. Many users will not notice or care about the different URL in the address bar. If you don’t have the skills in-house, any large Dynamics Partner should be able to provide you with both Dynamics 365 services and traditional web design services to keep the user journey aligned across both platforms.

Your CMS should be a robust supported platform. A Power Portal is robust by virtue of the fact it is built by Microsoft on top of Dynamics 365 and PowerApps. It’s unlikely PowerApps portals will ever become a fully-fledged CMS with an ecosystem like WordPress or Joomla because that’s not its focus.

Should I use another Dynamics Portals Technology?

It’s true to say PowerApps and Dynamics portals is not the only show in town for integrating to Dynamics. There are numerous other options to expose information externally or get  – for example :

• A static html page which calls a Microsoft Flow (unauthenticated)
• A custom website which calls Dynamics 365 web services directly to create, update, retrieve Dynamics 365 data.
• The Open Sourced Community Portals* (see footnote below)
• Other packaged plugins e.g.
  • AlexaCRM – A currently supported WordPress Plugin that connects directly to Dynamics 365.
  • CRMPortalConnector – A currently supported Sitefinity (another mature CRM) add-on that connects directly to Dynamics 365.

Each of these approaches may have their strengths and weaknesses, however one additional important thing to consider is the long-term supportability and product roadmap of such approaches. Many old ADX Studio customers were caught on the hop when the product was suddenly discontinued. They had to go back to the drawing board with a lot of expense and rework. Do you want to risk third party options which may stop working if Microsoft deprecate an API in the future?

A Final Recommendation 

So, what should you choose? Whatever portal product or combination of products or offering you pick, make sure the roadmap matches your ambitions! Microsoft Portals is likely to be the long-term answer and the licensing is evolving to fit more use cases as features are developed. Expect more CMS style functionality in PowerApps Portals but it’s unlikely to compete against more mature content management systems like WordPress.

Be wary of short-term solutions which may not be around in a few years or which may be expensive to upgrade. Don’t discount a hybrid approach which can ensure both a configurable user journey and styling considerations across multiple best of breed platforms.

*Although a community portal fork of the old ADX Studio source code exists, it is not supported by Microsoft and it does not have a long-term roadmap. You may need to seek third party support if you do not have a web development team who can support this themselves.