Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I need few more expert opinions on this design challenge and I hope you can help me! I know you would normally require a lot more details to make an informed decision, but I just need your initial and general views based on this information.
I have a new client who require a new Customer Portal that is integrated with Dynamics 365 Online. The portal will also be required to integrate with a number of legacy and 3rd party systems both on-premise and in the cloud. In other words, the portal will be expected to be highly customised with lots of custom integration directly to other applications such as SharePoint, external web services providers (including Postcode lookup) and existing internal legacy systems.
The portal will also require extensive branding and embedded marketing collateral, etc.
What technology would you choose? Adx Studio, Microsoft Portal (apparently source code to be released soon) OR a custom .Net MVC portal solution where I have full access to all source code and can freely build and extend it to interact with all applications including Dynamics?
Your own experiences and expert views are most appreciated.
Hi Mohamed, keep in mind that MS Portal (ADX Studio on-premise) source code release will be a one time release. No roadmap is provided with the open source variant.
Having said that if that isn't a concern for your client then the positives is that security and authentication to Dynamics is already provided, and would make a good base on which to build your web application.
With a custom MVC Application, depending on the skill level of your development team may also be a good way to go. Your application can be cleaner in structure and you can forego many of the legacy code that comes with ADX. This would be my preference if there is sufficient confidence in your team.
Just to throw another option to the mix, if what you require is content management also, budget permitting an enterprise grade CMS (such as Sitecore, Adobe Exp Mgr, Sitefinity) may be the best way to go. A good middle ground between custom dev for connectors to your exisiting legacy systems and Dynamics combined with the power of content management through drag and drop administration tools. They also come with decent tooling (such as Visual Studio) deployment tools to assist with your ALM.
Hopefully this helps with your considerations of all the options.
Honestly, I could never understand why ADX Portals architecture even took off in the first place - from the portal perspective, it introduces so much dependency on Dynamics.. Providing some sort of integration framework for generic portals would make more sense to me. The only scenario where ADX kind of makes sense is when there are no portal development resources, so the preference is, clearly, to use some sort of configuration tool instead.
In any complex scenario, I would definitely go for something else.
You need to consider mainly two factors:
1) When the project should start, if the project starts tomorrow, probably your only way is a custom ASP.NET MVC portal (or Django depends on the skills of the developers), if it can wait the release of Microsoft Portals Source Code, it should wait.
2) Don't focus on the integrations you have in the back, creating a convergence of the data inside a system (like put all the data before inside CRM) or inside an API (a REST endpoint that the web application will use to interact with the data) it's the "easy" part.
Focus on the capabilities the web application must have: assuming you need CRUD functionality (it's what we do over and over) which are the benefits of using Microsoft Portals instead of a custom web application and vice versa?
I know the ADX Studio/Microsoft Portal development fairly well, my primary job is not ASP.NET MVC developer but I had my fair share of hours creating web applications.
If you focus on the capabilities the selection on the platform will be easier, for example: your customer needs a CRUD on a custom entity (or on a common entity like account/contact) with search functionalities, make sure that the users can access only to their records? with Microsoft Portals you can configure this with very few hours, if you ask an ASP.NET MVC developer to create the same functionality (so index with a grid with sorting of the data, create page, edit page, delete page, search box, data security) it will take DAYS. And if we put on the plate for example a lookup field (like selecting the primary contact of the account) add more DAYS. You want to rearrange the fields or add/remove some fields, change the requirement level of the fields? add more DAYS. If you do these operations with a Microsoft Portals we talk about HOURS, not days, and requires a Portals customizer, not a developer.
The advantage of having the source code is that the project is an ASP.NET MVC and it can be extended (note: the ADX version 7 is a mix of Forms and MVC, nobody saw the source code of the new version yet) you want to create a custom page that shows data from Oracle and keeping the other pages from CRM? You can.
So, if the Microsoft Portals offers you most of the functionalities you need, than go with the Portals source code and deal with custom code for the rest part, if you need just a fraction of what a Portals can offer in term of CRUD, than maybe is better to go with a custom web application.
As I wrote before the integration of the systems is secondary, if you use the portals you can create (for example) an integration between the external system and a custom CRM entity, and expose this entity to the Portals, so you don't need to deal with connections to the external system at web application level, but only at CRM level.
Wrote this, working with the Microsoft Portals requires an intermediate/high level of training, but if you go with a custom web application you still need to find an intermediate/high level ASP.NET MVC developer, I saw too many developers saying that they know ASP.NET MVC and they only know how to do some scaffolding starting from the Visual Studio templates and they don't apply correctly the MVVM pattern, resulting in exposing confidential data or allowing malicious edits.
Many thanks Anderw, Alex and Guido for your responses. These are great insights and views which pretty much enforces my initial thoughts. So similar to your views and from my previous experience, Adx/MS Portal is an excellent quick / config way to achieve a portal to Dynamics 365. It provides a rapid approach to stand up a Customer Portal to Dynamics 365.
However, there are few important considerations for the Adx / MS Portal option. Performance is a risk if you have thousands of customers who need to access information on the portal as these are all direct reads from Dynamics 365. There is also the risk of performance and data storage limitations especially if you pass through all portal integrations through CRM only when it doesn't need to. You could probably end up with CRM being too complex just to service the required portal integrations when you don't need to.
The last consideration is the branding and customisation of the look and feel of the portal. Perhaps Guido can help by giving us his views from his ADX experience. I found customising Adx to apply clients specific branding and marketing context to be extremely limited and rigid. Am I missing a trick or would you agree with this? I understand the source code will help with that but you still also have the Architecture challenge of having your Portal tightly coupled with your CRM / front office application.
These are my views but I would love to hear back more responses to these points from other MVPs / Experts. I think this forum discussion could be valuable to a lot of people.
Looking forward to hear more views and for Guido to respond with his Adx experience on the points above.
Just to answer the question on the resources, I have strong .Net MVC dev team who have built a pure MVVM portal solution which is also a responsive design with Bootstrap etc. So I think, we tick this option for the client but I still want to build what is most suitable to the client - not what my team is capable of, if you see what I mean.
I guess having the MS portal source code will certainly make a difference as we can do proper ALM and Visual Studio development. I also agree with Andrew's idea of using an enterprise CMS and extend it to achieve the Customer Portal functionality except that client budgets don't always allow for such expensive options.
Looking forward to hear more views on this.
There is also the potential of bright future when it comes to the dynamics customer portals. If they get integrated with other azure tools, common data model, etc.. but it may take time. And it probably won't ever be true for the onprem version.
Regarding the performance, Portals has a very good caching mechanism, but yes, probably in terms of power of the web server you need something with more power than a normal web application, but if you have many users you probably need to implement caching and with Portals you get that included.
The amount of data inside CRM can be a problem and can make the CRM cost higher, maybe Virtual Entities can give you some help in the future (if they work oob with Portals), but having the portal source code you can still access the external services inside the same app (of course if the CRM entity to access are only 2 and the external services are 8, the Portals is not a good choice)
Regarding the branding and theme customization, the Portals has a bit rigid layout, but it still based on bootstrap, and if you have a front-end developer that knows how to deal with the asp.net mvc markup and structure (meaning he knows where to put his hands) you can get very good results, of course some components of the Portals (like the appearance of subgrids or lookups) you are a bit limited on what you can customize.
However the asp.net source code of ADX 7.x is still available, the new version will be different but if you give it to your dev team they can get an idea on how is structured (in terms of Areas, Layouts, Views) and give you a feedback (especially the front-end devs)
First off, Adxstudio v7 is essentially no longer being offered by Microsoft unless you apply for an exemption and can provide a compelling reason of why you can't use the Microsoft Online Portals and the customer has invested $250K (US) in Microsoft software. From what I have heard very few exemptions are being approved.
The Portals source code release from my understanding is meant as a one-time release. Microsoft will not update or support any modifications. In my opinion, this is very risky unless some well established company takes some kind of ownership of this.
There are plenty of other portal options, I wrote a blog article outlining the various options so hopefully it can provide some food for thought.
Hope this helps!
Thank you Guido and Nick for your response. I agree that building on top of an existing open source MVC portal is a good approach if the choice is not Adx / MS Portal because you would not be building from scratch. I personally found NopCommerce very useful and have successfully integrated NopCommerce with Microsoft Dynamics 365 (CRM) quite well. I shall write few blog posts about this experience.
Saying that, I can see Guido's points too except for Integration. Has anyone managed to integrate ADX / MS Portals with multiple 3rd party solutions and web services? Have these been straight forward and successful?
It will be good to get more feedback on the Integration capabilities for ADX / Microsoft Dynamics Portals.
Since Adxstudio is essentially a .NET web application, we have been able to build our own aspx/asmx pages and user controls which will give you a lot of flexibility. We have been able to modify to integrate to certain payment gateways and other services.
With the online portals, this code is now essentially closed off.
Something that you might want to check out, Colin Vermander from Adoxio has been cooking up a framework to extend the Dynamics 365 Online portal:
He is presenting it at an upcoming XRM Virtual meeting:
I only have read the high level stuff and haven't had a chance to dive into this yet but it might give you more info.
Thanks Nick. Very helpful. I think without the source code, it is pretty much not an option. However, Microsoft is promising to release the source code but as a one-off. Helpful but it means future compatibility will be an issue.
One last consideration if you or anyone can give their views on. How about Security? I think my client feels Microsoft Portal will be more secure as it is hosted within the cloud platform and the client doesn't have to worry about testing a custom .NET MVC Portal. My view is that you need to get your security right either way.
A quick note on Security.
I created a portal (for one of my clients) few years back, using MVC with Azure AD (Portal users as contacts). I did not face any security related issue. You have Microsoft Graph to go further.
Business Applications communities