Ever wanted to connect with your customers on a certain issue extremely quickly and won’t want to put much fuss into it? Sounds like you need to push out a survey in a matter of minutes – and want a robust place to store it that integrates with your existing systems. SurveyMonkey probably immediately springs to mind, but the frustration of that service is you are ultimately going to be exporting that data and transforming it to do your own analytics on it. Wouldn’t it be nice to have a very quick way to put out a survey, but leverage your existing O365 environment and CDM/CRM database? Of course it would! That’s were Microsoft Forms comes into play.
Ah Portals, our favorite child of Microsoft Dynamics CRM. It’s been around for while and people have gotten used to it as a piece of the D365 picture. However, people are starting to pick up on the fact that the Power Platform has a Portal offering too? Is this the same thing? How do Portals fit into the picture of Power BI, Power Automate, and Power Apps?
Portals and Customer Engagement
Well I suppose the first thing to clear up is how Portals fit into Dynamics 365 Customer Engagement. And to do that, we need to clear up how Dynamics 365 Customer Engagement fits into Dynamics 365.
Well for starters, it’s not Dynamics 365 Customer Engagement anymore. With that out of the way, I’ve got nothing better to call the set of model-driven power apps that are part of the Microsoft Dynamics 365 licensing structure, so to heck with it, I’m going to keep referring to it as CE for this article.
It’s a long story, but the short-short version is that when CRM, NAV and AX all went online, Microsoft decided to market them all as the same thing – just different parts of the same platform. This actually makes perfect sense because in theory they compliment each other very well. NAV / AX (Now Business Central and F&O) handle the accounting / ERP side of things, which allow your business to manage its finances and inventory, while CE handles the sales and customer service side of things. Together they really do represent a complete picture, in theory, if only they integrated together a bit better.
So where does the portal come into play? Essentially, it’s the customer-facing portion of your customer engagement solution. Basically, if you are a business, and you have customers, you need a portal of some kind, and if you have a Dynamics 365 CE implementation, the Dynamics Portal makes a pretty good use case to fill this role. External users interact with your Portal which in turn interfaces with D365 CE.
OK, but what does this have to do with the Power Platform?
So far we’ve been talking about D365 and how the Dynamics Portal fits into CE. However this article is about how the Portal fits into the Power Platform. So perhaps we should be asking ourselves how D365 CE fits into the Power Platform.
Well, it’s a long story. Really I would say that the best explanation ever was provided by MVP Nick Doelman in this blog post. Give it a read – it’s a great story.
Dynamics 365 and the Power Platform
Here’s the short version: Microsoft loves bundling software together into Platforms, and three applications that worked pretty well together were Power BI, Flow, and PowerApps (Now called “Power Apps”, with a space). Power BI is Microsoft’s premiere business intelligence software – it can connect to various data sources, create reports based on that data, and allows for powerful visualizations, data manipulation and forecasting. Flow (Now called Power Automate, in case you missed it) is a next-generation low/no-code workflow engine, also connecting to a variety of data sources and allowing for the automation (power automation!) and streamlining of repetitive tasks. Finally, PowerApps started as a platform to allow customers to easily build unique purpose-driven applications. This would allow “citizen developers” to build custom applications low/no-code. This began with a set of drag-and-drop tools and low-code functions to build pixel-perfect apps that connect with a large variety of different data sources via connectors.
As this was all coming together into the Power Platform, Microsoft realized that what’s missing from this combo of Flow, Canvas PowerApps, and PowerBI is a citizen developer-friendly data store that is easy to set up and customize. A highly extendable relational database -which could be called the Common Data Service (CDS) and a basic schema with some pre-defined entities like contacts, accounts, and activities – which could be called the Common Data Model (CDM).
Turns out Microsoft basically already had such a thing and that was the Dynamics CRM data model and business application layer. For years and years, we in the Dynamics CRM world had learned to adopt the “xRM” mindset and think of CRM as a platform, because of how extendable and robust it is. Dynamics CRM had in fact everything Microsoft was looking for in and therefore CRM formed the basis for this new CDS and CDM. In the spirit of not fixing what isn’t broken, the Unified Client Interface (UCI) was welcomed with open arms and the concept of Model-Driven Apps was born.
The Dynamics data model was re-branded CDM and the different customization tools like the solution editor had a PowerApps (later “Power Apps”) label put on them. The power platform was really ramping up now – a complete platform allowing for all aspects of engagement, functionality, analysis, and automation to come together. What had been the “naked” CRM business application layer had become CDS/CDM. the customization tools and UCI came to form Model-driven Apps. The original pixel-perfect apps and tools because known as “Canvas” apps, and then Flow was renamed Power Automate for some reason.
But exactly where does “Dynamics 365” fit in? Is Dynamics 365 gone now? Or is it just ERP now? after all, CRM is just CDS/CDM and Model-driven apps now. The answer lies in the question of what apps we are talking about. The “CRM” part of Dynamics 365 – D365 CE – is no longer a platform, instead, it’s just a brand name (and licensing structure) for a series of first-party Model-Driven apps, that come pre-loaded with all sorts of features and functions that you can’t get otherwise. It’s still very much built on the Common Data Model and very much part of the Power Platform… Although it’s also still very much part of Dynamics 365 as well, so it’s marketed alongside the ERP side of Dynamics, as if things weren’t confusing enough. Maybe a diagram will help.
Portals and the Power Platform
This brings us back to the Portal. A while back I posted about how finally we get a “blank” Portal that runs off of CDS without needing Dynamics 365 licensing. This is brand new app type, right along Model-Driven and Canvas, known as Portal Apps. The Portal App is identical tech-wise to the Dynamics 365 Portal that we kicked this article off with. Just as Dynamics 365 apps are just first-party model-driven apps that come pre-loaded with features, so are the Dynamics 365 Portal Apps (like the Community Portal, Partner portal, etc.) first-party Portal Apps that use the Dynamics 365 licensing instead of the Power Apps licensing. Or to put it another way, just as CDM + Model-driven apps is a “naked” CRM, so are the Portal Apps, “naked” portals!
So what business value do the Portal Apps add to the Power Platform? Well, just as the portal represented the external “Customer” side of Dynamics Customer Engagement, the Portal Apps allow for external users to interact with your custom line-of-business application. The scenarios are endless just as are the scenarios for Power Apps – the limit is your imagination. Online shopping, profile registrations, service requests, open information, the list goes on – if you are building a line-of-business application with Power Apps and need a way to expose information to or capture interactions or information from external users, Portals is a potential solution.
Thanks for reading! Be sure to like, share and subscribe if you want to see more!
Managing changes coming from Microsoft and staying on top of the latest updates and deprecated can be quite daunting for many. If you let up on it for a couple of months, as many of us are wont to do, myself included, you can quickly find yourself overwhelmed by what’s new out there simply because of the dramatic pace of change.
One quick win would be to opt-in to early access to new features as early access becomes available, so you can start testing, learning, and leveraging them right away. This advice will always apply, but here’s the guide to early access features at the time of this writing.
For each of the various major releases, you can opt in for early access about 2 months prior. So for the features set to release in Apr 2020, you’ve been able to get early access since February. Wave 2 will release in October, so you’ll be able to opt in in August.
Here are some reasons to opt-in:
- You will have more time to test and learn new features
- You will be able to identify potential problems (such as with deprecated features) faster
- You’ll get a jump start on development
- You will be ahead of the curve in terms of knowledge and readiness
I have definitely spoken to a few people who express concerns when it comes to opting in to early upgrades, because it might cause instability with production environments. Putting that aside, it’s a no-brainier to start testing out and leveraging early access features if you’ve got multiple environment that you can use to do so. The early access updates are available for all types of environments, including trial, sandbox, and production. So don’t hesitate to do so for your non-production environments.
- Sign in to the Power Platform admin center.
- Select the environment to update.
- Under Updates, you’ll see that the new release wave is available. Select Manage.
- Select Update now, and then proceed through the confirmation dialog boxes to enable the new features and capabilities of the release wave.
- After the update is complete, all early access features will be enabled for your model-driven apps in your environment.
Remember, you can’t opt-out of the eventual upgrade – that’s actually the beauty of SaaS; it forces a different dynamic than the “giant upgrade, sit around and wait, fall desperately behind, repeat” one. It’s for that reason that i’d recommend some best practices in terms of your approach to upgrades:
- Download the release plans when they become available: Reading these will give you a good idea of what the next release includes. Essential for members of the community! At the time of this writing, the current release plan is in two waves: wave 1 and wave 2.
- Stay up to date with the Roadmap: This will give you a sense of what’s coming: https://dynamics.microsoft.com/en-gb/roadmap/overview/
- Ensure you have sufficient environments: Production, UAT, Test and Development at a minimum. This is separate from “play” environments that you use for learning. This keeps development far away from your live environment so that early opt-in, not to mention your dev work, won’t break production.
- Opt in to the early access updates from the Power Platform admin center, and test and evaluate new features against your requirements regularly: Begin with your sandbox environment. An update might introduce new functionality that you can leverage in new engagements as a consultant, solve a pain point on an existing system, or even remove the need for a third-party tool and introduce a cost-cutting shift. So many times I’ve consulted with clients who left feeling like “they should have known better” after paying big bugs for a custom solution when they could have used recently-introduced D365 features OOTB to fullfill all the requirements!
- Leverage both early opt-in and preview features: The most time-consuming task is testing the updates, so the earlier that you start test features you know are coming the longer you have to test. You want to catch issues as early as possible. This would apply to leveraging preview features as well, although preview features can always change, it still gives you a lot of extra time to test features and prepare.
Hopefully, this makes you more comfortable and excited about staying on top of the latest and greatest. Opting-in to early upgrades is one great piece of that puzzle!
Ah, CRM. If you have lived in Dynamics CRM land for a long time, you know exactly what I mean when I say CRM. It used to be pretty simple; It’s Microsoft’s CRM product: Dynamics CRM. Then Microsoft branding and marketing got involved and we got a long ever-changing road of really confusing terminology.
In case you’ve been living under a rock… or you know, think of Dynamics as a brand of ERP products (we’ll get to that later), CRM stands for Customer Relationship Management. Essentially, if you are a business, and have customers, then you need a CRM system. Depending on the size of your business, that might just be a black book, or a series of Excel spreadsheets, or a database of some kind. A first-class CRM product would be called for if you have salespeople who need to track contacts, accounts, sales and opportunities. You might also need one to track customer service cases or to manage marketing campaigns.
In any event, Dynamics CRM started as a first-class CRM product that just happened to be very customizable (perhaps “xRM” rings a bell?). You could use it as just a CRM (you know, like Salesforce), or you could customize it to do almost anything you want with it (I’ll get to that later too). We always just called it “CRM”. That’s it. Not “Dynamics CRM” or anything like that, Just “CRM”. Everyone knew what we were talking about.
So when did the confusion begin really? Well originally, Dynamics CRM was on-prem. Fast forward to a few years ago (please don’t tell me it’s been almost 10) and Microsoft decided that like literally everything else that exists now Dynamics CRM would be offered in the cloud as SaaS. At first, the online version was called “Microsoft Dynamics CRM Online”. Nice.
Things were simple until it was decided in 2016 to rebrand CRM under the Dynamics 365 umbrella along with several different ERP products. CRM would appear in this suite of software – along with the ERP products AX and NAV – but wouldn’t be called CRM anymore. Instead you had a few different busniess apps – “Dynamics 365 for Sales”, “Dynamics 365 for Customer Service”, etc. Each of these apps was just CRM but with a narrow sitemap containing only the module in question. Of course there were also apps like “Dynamics 365 for Finance” which was NAV under the hood or “Dynamics 365 for Operations” which was AX under the hood. In terms of licensing you didn’t get a license for CRM as a whole anymore, instead there were different Dynamics 365 plans which included different apps from this unified selection.
In a way it did all make sense from a marketing perspective; since the desire was to mainstream the Dynamics products that had previously been under a different business umbrella. A popular blog post from 2016 compared it to when they bundled a bunch of previously separate products like Word, Outlook, PowerPoint and Excel into “Office 365”. Instead you have a bunch of previously separate products that collectively are called the same thing – Dynamics 365. The difference really is that with the Office 365 product the separate apps are still called the same thing that they were before they were bundled. Word is still Word, Excel is still Excel. With Dynamics 365, you didn’t have a direct line of naming succession, and CRM was now called different things depending on the business application.
Further to all this, Dynamics CRM had for some time been pushed as a more than “just” a CRM application. It had been pushed as a platform. Some of you may have been around long enough to remember this:
CRM was actually xRM. Meaning that it was a platform that you could build a wide range of business applications on top of that went way beyond just CRM. Dynamics CRM was highly customizable and was in fact a great platform to serve this purpose. It was so robust that we even built a Portal product to sit on top of it and allow businesses to engage with their customers at a whole new level. Well, now that platform with all those applications and the Portal and all that…doesn’t officially exist anymore. Sure it still exists under the hood of Dynamics 365 Sales, Dynamics 365 Customer Service, and so on, but what should we call the platform now? Just “Dynamics 365”?
Here’s the thing. If you find yourself attending D365 community events or UG events, or worse still if you work on projects that have both a CRM and ERP element to them and D365 is the selected platform, you might bump into the situation were you start up a conversation with someone about Dynamics 365 and very quickly realize that you are speaking different languages. To the ERP person “Dynamics 365” means the ERP product. Dynamics 365 IS an ERP product to them. For you, it’s the opposite. When you say “Dynamics 365” what you really mean is “CRM” but you can’t say that anymore. Or you know, you could say screw it and keep calling it CRM anyway.
Realizing that there had to be some way of distinguishing the portion of Dynamics 365 that came from the platform that had been CRM, Microsoft decided in 2017 to introduce the name “Dynamics 365 Customer Engagement” to refer to the product that had been CRM but wasn’t allowed to be called that anymore. All was well. Soon the confusion started to abate. We had “Dynamics 365 Business Central” for “BC” for short, and that was the new name for NAV online. Then you had “Dynamics 365 Finance & Operations” and that was the new name for AX. And of course you had CE for CRM. So now you just had to get over the habit of saying “Dynamics” (or CRM) when you meant “CE”. Easy.
That is until Microsoft officially announced that CE is gone from the Microsoft cloud. The apps are still there, but they won’t be referred to collectively as “customer engagement” anymore. Instead we are back to them not really having a collective name and just being separate D365 apps again.
So why the change? CE was a perfectly good name to describe the online CRM offering no? Of course there is a problem with this. CE is the name for the online version of the CRM product, right? Well, increasingly, the online product isn’t really the same product as the on-prem product anymore – it’s not even built on the same foundations. Under the hood, the underlying platform has shifted from what was CRM to what is now the Power Platform. No one explains it better than Nick in his amazing blog post explaining the Power Platform. Long story short – we got xRM, but in the form of the Common Data Service, and Dynamics 365 apps are just vertical apps built on this service. It’s all part of the power platform. So, there is no distinct CE product that is separate from the Power Platform anymore – least not for much longer from a tech or infrastructure perspective.
CE is now the name for the on-prem product. CRM is truly gone. Meanwhile, we are still stuck trying to figure out how to refer to “the set of model-driven premium business apps that you pay separate licensing costs for that aren’t ERP”. Or in other words “the CRM stuff”. Well, for now at least, the correct way to reference any of the individual apps is “[Insert Dynamics 365 app name] running on Common Data Service”, so for example “Dynamics 365 Sales running on Common Data Service”. Yes, that’s a mouthful and also notice there is no “for” in the title anymore. Therefore, as a whole, the set of apps should be called “Dynamics 365 apps running on Common Data Service”.
That all said, I might suggest a better name: wait for it.
Dynamics 365 Power Apps
Hope you enjoyed the read! I’ve been gone for a while but hope to post more frequently again and will be making some updates to my site. Stay tuned, like and share!
If you are going to be working on implementations of Dynamics 365 having certifications under your belt can help demonstrate that you have the skills and knowledge that make you up to the task – although there’s no substitute for hands-on experience. Depending on your role, the certifications you are interested in might differ. With Dynamics expertise, the job title that gets a lot of attention is functional consultant, and you can now earn associate-level certification as a functional consultant for any of the main Dynamics 365 CE and F&O verticals:
- Sales (CE)
- Customer Service (CE)
- Marketing (CE)
- Field Service (CE)
- Financials (F&O)
- Manufacturing (F&O)
- Supply Chain Management (F&O)
You see, Microsoft recently switched up its certification structure for Dynamics 365. In fact you may have noticed a wave of LinkedIn notifications a while back from all the people who earned the certs while they were still in beta (congratulations to all those people by the way!). These new exams are replacing the old exams, and in turn the new certifications are replacing the old ones.
Until recently, you could earn an expert-level certification as a Microsoft Certified Solution Expert (MCSE) in Business Applications for Dynamics 365. You see, Microsoft certifications have 3 levels: Fundamentals, Associate, and Expert, with Expert being the highest level of certification currently available for any kind of certification.
The MCSE in business applications for Dynamics required you to first earn a Microsoft Certified Solutions Associate certification in Dynamics, requiring exams such as MB2-715 (now retired) before taking more exams to upgrade to the expert-level. This was significant because with the old Certification system, you could earn the Microsoft Certified Professional (MCP) designation by getting the expert-level MCSE certification.
…as of right now there is no expert-level certification available for Microsoft Dynamics 365 CE.
This is being revamped – the designation that you will now earn going forward is Microsoft Certified Functional Consultant – by getting certified in one (or more) of the functional areas of Dynamics 365 for CE. You do this by passing the MB-200 Exam, plus one additional exam per functional area you want to get certified in: Sales, Customer Service, Marketing, or Field Service. It is interesting and important to note that as of right now there is no expert-level certification available for Microsoft Dynamics 365 CE.
Before we continue, just what is a functional consultant anyway?
Functional consultants are involved in the planning, design and oversight of the implementation of a system – in this case, a Dynamics 365 CE implementation. They take the requirements of the client or customer – often but not always discovered and documented with the help of a business analyst (BA) – and use their understanding of the technology (Dynamics) to analyse various methods and solutions to build a system that meets the requirements of the client. The job requires a balance of providing technical solutions and meeting and manipulating business requirements. I mentioned the role of functional consultant in my article on Building the Perfect Portal Team and I’ll speak about the qualities that make for a good functional consultant in a future article.
So what are the exams, and more importantly, how do you prepare for them? Before I get to the breakdown, I’d like to point out the resources available for learning. Obviously, there’s no substitute for hands-on learning and practice. It’s assumed that you are taking these exams after working a fair bit with Dynamics 365 CE. However, it’s unlikely that in the regular course of using and configuring the system that you are going to bump into every scenario equally often and discover every nuance. Therefore it’s a great idea to study up as well. To this end, there are 3 big buckets of free knowledge available that should be enough to get you prepared for the exams.
First, there’s community learning as I outlined in my last blog post on the Adoxio Community Website on the subject. Second, there’s Microsoft learn. Finally, there is material available on the Dynamics Learning Portal (DLP) – but that’s only available to partners, so if you aren’t a partner you might need to find alternative ways of accessing this or similar content and it likely won’t be free.
You can also pay for courses / bootcamps – and if you are new to Dynamics that’s probably worth the investment – but if you aren’t new to Dynamics try the free sources first. A further recommendation is that even with all these learning materials, some of the latest features are still lacking much content, especially free Microsoft Learn content. So it’s important to go through the MSDN documentation as well. Not really the ideal learning content, but great for filling in the gaps.
For my breakdown of the exams, I’ll talk about the exam and the topics covered, and link to the Microsoft Learn resources that can be used to prepare. I’ll also point out the course numbers from DLP that are relevant for those readers lucky enough to have access to that resource. If you are going through the Microsoft Learn material, remember that you can get a lot more information on every topic covered in the MSDN documentation as well as the community resources I previously mentioned. So don’t just read through and think that’s enough; on every page, look up the documentation on MSDN on the subject, and google additional material. Also, don’t forget to play around as much as possible.
Exam MB-200: All of the Functional Consultant Certifications require the exam MB-200 as a prerequisite. In order to prepare for this exam, you’ll need to learn the following skills (with links and DLP course numbers):
- Implement and Configure Dynamics 365 CE and Learn Power Platform Basics:
- Learn: https://docs.microsoft.com/en-us/learn/paths/dyn-power-plat-bus-app-fundamentals/
- Learn: https://docs.microsoft.com/en-us/learn/paths/implementing-customer-engagement-online/
- Learn: https://docs.microsoft.com/en-us/learn/modules/configure-model-driven-apps-customer-engagement/
- DLP: 81269AE: Designing XRM Customizations in Dynamics 365
- DLP: 81270AE: Customizing the Microsoft Dynamics 365 User Interface
- DLP: 81234AE: Customizing Unified Interface in Microsoft Dynamics 365
- DLP (old but still useful): 81060AE: Configuration in Microsoft Dynamics 365 for Sales and Customer Service
- DLP (old but still useful): 81059AE: Customization in Microsoft Dynamics 365 for Sales and Customer Service
- Manage Data and Implement Security:
- DLP: 81268AE: Configuring and Building a Dynamics 365 Security Structure
- MSDN (Entire Section – needed as Microsoft Learn doesn’t have much on security): https://docs.microsoft.com/en-us/dynamics365/customer-engagement/admin/manage-security-users-and-teams
- Manage Processes (Microsoft Flow is optional but recommended):
- Learn: https://docs.microsoft.com/en-us/learn/modules/get-started-with-workflows-in-dynamics-365-for-customer-engagement/
- Learn: https://docs.microsoft.com/en-us/learn/modules/work-with-business-process-flows-dynamics-365/
- (Optional) Learn: https://docs.microsoft.com/en-us/learn/modules/get-started-with-flow/
- (Optional) Learn: https://docs.microsoft.com/en-us/learn/paths/automate-process-using-flow/
- DLP: 81271AE: Process Automation in Microsoft Dynamics 365
- Configure OOTB integrations:
- Configure Portals:
Exam MB-210: This is needed for the Functional Consultant for Sales Certification:
- Understand the Sales Process
- Learn: https://docs.microsoft.com/en-us/learn/modules/overview-d365-sales-professional/index
- Learn: https://docs.microsoft.com/en-us/learn/modules/administer-configure-d365-sales-professional/index
- Learn: https://docs.microsoft.com/en-us/learn/paths/working-with-dynamics-365-sales/
- DLP (old but still useful): 81066AE: Introduction to Microsoft Dynamics 365
- Configure Advanced Analytics
- Use LinkedIn Sales Navigator:
- Apply Goal Management
Exam MB-220: This is needed for the Functional Consultant for Marketing Certification:
- Configure Marketing Applications
- Manage Custom Journeys, Emails, Forms, and pages
- MSDN: https://docs.microsoft.com/en-ca/dynamics365/customer-engagement/marketing/prepare-marketing-emails
- MSDN: https://docs.microsoft.com/en-ca/dynamics365/customer-engagement/marketing/create-deploy-marketing-pages
- MSDN: https://docs.microsoft.com/en-ca/dynamics365/customer-engagement/marketing/customer-journeys-create-automated-campaigns
- Manage Events and Webinars
- Configure Microsoft Forms Pro (In October 2019 this will be the new way to create forms)
Exam MB-230: This is needed for the Functional Consultant for Customer Service Certification:
- Understand Cases and the Service Desk
- Learn: https://docs.microsoft.com/en-us/learn/modules/dynamics-365-for-customer-service/index
- Learn: https://docs.microsoft.com/en-us/learn/paths/work-with-cases-in-dynamics-365-for-customer-service/
- Configure Service Management
- Learn: https://docs.microsoft.com/en-us/learn/paths/work-with-entitlements-and-slas-in-microsoft-dynamics-365-for-customer-service/
- Learn: https://docs.microsoft.com/en-us/learn/modules/dynamics-365-ai-insights-driven-business-applications/index
- DLP: 81058AE: Service Intelligence in Microsoft Dynamics 365 for Customer Service
- Configure a Knowledge Base
- Learn: https://docs.microsoft.com/en-us/learn/paths/work-with-knowledge-management-solutions-in-microsoft-dynamics-365-for-customer-service/
- MSDN: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customer-service/search-knowledge-articles-csh
- MSDN: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customer-service/customer-service-hub-user-guide-knowledge-article
- Use Voice of the Customer
Exam MB-240: This is needed for the Functional Consultant for Field Service Certification:
- Configure the Application
- Manage Schedule, Works Orders, Assets and Inventory
When it comes to the format of the exams – well, if you’ve taken Microsoft exams in the last 5-10 years they will seem pretty familiar. One thing I’d say is that many of the questions involve having memorized the exact sequence of steps to perform certain actions. To me this is rote memorization, and I feel truly understanding the capabilities of the system and how they apply to different scenarios is far more indicative of a good functional consultant than having memorized the sequence of actions to configure a security role. Nonetheless, you’ll need to know that stuff to pass the exam so be prepared.
Hopefully you’ve found this post useful! If you have your own resources to share, please leave them in the comments! I’d love to update this guide. For now, I’ve limited it to mostly Microsoft Learn and DLP, with a few gaps filled in by MSDN documentation. But, I’m happy to expand this guide so feel free to leave suggestions!
Either way, if you think this kind of thing is useful, let me know.
In case you haven’t heard, the Microsoft October 2019 Release plan has some pretty huge news when it comes to Portals – They are going to be put on center stage as a first-class app type along with Canvas Apps and Model-Driven Apps.
Starting soon, when you go to web.powerapps.com and go to create a new app, in addition to Model-driven apps and Canvas apps there will be a third type of app: Portal!
These Portals will be exactly the same as the previous portals, but you don’t need dynamics CE anymore. These Portals run off of the Common Data Model (just like before, really). In fact, you’ve been able to see the CDS portal in action for a while now. Now, Dynamics CE is still an important vertical to consider, so in a future post we’ll look at when you should skip CE and when you should still include it in your solution.
Portals are going to now be open to a much bigger audience as people jump onboard the power platform. With PowerApps, you can built out purpose-driven applications to suit your business needs – no longer are we modifying a CRM system to implement a system that doesn’t really have anything to do with CRM. Naturally, Portals are a key part of that story and the technology used to build Dynamics portals is being brought forward as the missing part of the puzzle. This feels so rewarding as all the work that my colleagues and I did at Adxstudio back in Regina, Saskatchewan at the old park street office building Portals has really come to full fruition.
Let’s rewind to 2009. I had just completed my Master’s Degree – well, scratch that – I was close to completing my degree and decided to start working full-time while I finished up the last “month or two” of my thesis. Actually finishing and defending my thesis would take well over an additional year, but that’s another story.
You see, I had accepted a fantastic offer for a brand-new developer from a local company in Regina, SK called Adxstudio. I started off right out of the Gate as a Developer on the Product Team working on little product called the xRM framework, which was nearing completion of version 2.2 when I came on board.
Most of Adxstudio’s business came via it’s other product, a Content Management System (which was a big deal at the time) simply called Adxstudio CMS. It was a fine piece of software, but most of our investment was in Microsoft Dynamics CRM, which had recently released version 4. We believed that Microsoft Dynamics was the future – and we were all in. What we had developed was a framework which allowed developers to interface easily with Dynamics CRM without interfacing with the SQL database directly. The primary use case for this was to integrate a website withe Dynamics 365, so that records such as contacts from CRM could be surfaced in some way on the website. Sound familiar?
Included was an authentication model that allowed you to log in and have your user associated to a Contact in CRM. It also had a fully functional CMS allowing you to manage the website via Web pages, Web Links, Content Snippets and so on. We developed a few different websites too – we didn’t call them portals yet – such as the Company Website, branded Wireframe Industries – boy I wish screenshots from back then survived – the Conference Website, which used the amazing technology of Silverlight, and Community Website, which added some baked in features such as Blogs, Ideas and Forums.
Well as Dynamics CRM 2011 came out the door, we made the decision to give the xRM framework base code to Microsoft. It became part of the official Microsoft CRM SDK. This was rewarding it it’s own way but put us at an advantage because now the best way to surface data from CRM onto a website was to use a Portal using our framework. You could do some basic stuff for free using Microsoft’s accelerator portals, or starting from scratch using the framework that came with the SDK, but if you really wanted to play with power, you could use our product, which we kept adding features such as Web Forms, and later Entity Forms, Entity Lists, and finally Entity Permissions to. This product was finally named Adxstudio Portals (v4 of the xRM framework).
As Dynamics went through releases over the years so did Portals. With version 5 the solution layering was completely redone from scratch – manually, by me at first (!) – while we refined our ALM processes (and eventually came out with a great toolkit called the ALM toolkit to help automate the process ). With version 6 the front-end was completely redone to use bootstrap and Entity Permissions were added. With Version 7, we added liquid support which radically changed how customization of the Portals was done. It was now ready for the cloud.
And with that, Microsoft announced the acquisition of Portals (and the Adxstudio brand). I had the privilege of working with their new Portal product team to help integrate the Portals into their product lineup. Version 8 of Portals, as we called it internally, would soon be released as Dynamics portals – a fully in-the-cloud solution that extended Dynamics 365 for Customer Engagement.
Fast forward to today, and finally we are able to do the things with Portals that we saw ourselves doing with it way back in the days were we used “xRM” as a buzzword. I can’t wait to work on many more Portals implementations and I’m interested to see where we go from here.
Thanks for reading.
In my post about the Create Portal Content Wizard, I talked about how easy it is to add content to the portal using point-and-click configuration, and demonstrated that the Wizard creates a whole lot of records in the background for you so that you don’t have to. It’s like magic! It certainly does beat having to spend the time configuring Entity Forms, Lists, Permissions, and web pages all from scratch. However, the Wizard also has its limitations. There are several scenarios that it simply can’t manage, including some fairly basic ones. The Wizard can also leave you with a fair bit of manual work or cleanup to do, depending on what you’re building.
In order to better understand the Wizard, I figure now’s the time to spell out exactly what records actually get created by the wizard. To do this, we’ll go through the different options for configuring a list (we care mostly about displaying organization entities, so that’s the focus of this article) and then see exactly what configurations are created with each and what changes occur with the different settings. If you aren’t familiar with the Wizard, I explain the steps for using it here. Read that first, then come back – this article is more of a deep dive.Continue reading “A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard”