Wednesday, February 12, 2020

Power Platform Bootcamp 2020 Belgium - Forms Pro survey

Thursday, February 06, 2020

Quick tip: keep your Dynamics 365 development tools up to date using Nuget

I recently encountered an issue when I tried switching the view of the registered plugins & custom workflow activities in the Plugin Registration Tool.



When updating to the latest version using the PowerShell script listed on Download Dynamics 365 development tools from Nuget the error got resolved. Lessons learned: make sure that you keep your Dynamics 365 development tools up to date.

Monday, February 03, 2020

Lessons learned about Dynamics 365 solution layering - Part 1


This is the first in a series of blog posts on Dynamics 365 solutions and solution layering in which I will cover the basics about Dynamics 365 solutions and gradually delve deeper into the mysterious world of the inner workings of Dynamics 365 solutions.

In my opinion,  based on how managed solutions and solution layering work - I think that in the majority of cases you should only use a single managed solution to avoid issues down the line. Read on to see why...


This blog post assumes that you are using managed solutions to deploy to all environments and only have unmanaged solutions in your development environment.

Dynamics 365 solutions fundamentals

If you work with Dynamics 365/CDS solutions, you should be aware of the concept of solution layering. Solution layering occurs on import of solutions when a specific component is affected by a change within one or more solution. Solution layering will determine the kind of behavior that a user will see in Dynamics 365.

The figure above shows how layering works: at the bottom, you have the standard CDS solutions on top of which you might have some first party apps installed like Dynamics 365 Sales/Customer Service etc... If you deploy custom managed solutions, they will go on top based on the order in which they are installed. Direct customizations and unmanaged solutions are always at the top but there is no real layering of unmanaged solutions - they all end up directly modifying the base behavior.

Solution layers describe the dependency chain of component from the root solution introducing it, through each solution that extends or changes the component’s behavior. Solution layers are created through extension of an existing component (taking a dependency on it) or through creation of a new component or version of a solution. So it is very important to understand that layers should be considered on a per component basis.

In April 2019, Microsoft introduced a new user interface component which visualizes the different solution layers which are impacting the behavior of a specific component - View solution layers for a component. Below is an example of the solution layers of the case form which was quite an interesting example.


Going beyond the basics

But what happens if two or more solutions define solution components differently? This article  - Introduction to solutions - conflict resolution explains the two conflict resolution strategies - Merge and Top Wins. The article is also valid for online according to Microsoft support - even though it was written for Dynamics 365 on premise and last updated in December 2017.


When importing a managed solution with the overwrite customization option, it is possible to override the "top wins" conflict resolution  but this does not apply to components which apply a “merge strategy” - for more details see Understand how managed solutions are merged

So you need to be very careful when adding components which apply a merge strategy in multiple solutions with different publishers since the merge behavior might cause unexpected side effect such as creating a separate active layer on top which would block your customization to appear to the user.

An active layer can emerge in two scenarios - a direct customization was done in the instance but it seems that it is also possible that a managed active layer is created when using only managed solutions without direct customizations in the system. This happens when managed solutions in one system, with different publishers (the Microsoft solutions count as a different publisher) are trying to update the same component. It is a defense mechanism that Microsoft has built in when there are object inconsistencies across managed solutions.

The general recommendation is that you keep the number of managed solutions with common components (e.g. forms with a different form layout) to a minimum. This will avoid merging issues across the layers.

Single solution to rule them all?


Taking into account all of the above it seems that you would opt to use a single managed solution to deploy to other environments.

Single solution approach
Pros:

  • Easier to version control
  • Avoid solution layering issues
  • Less environments needed
  • Easier to promote across environments
Cons:

  • Longer duration of solution import
  • Long list of components


I do think that a single solution might make sense in the majority of cases but there are of course exceptions to this rule.  I would recommend you to take a look at the Solution Lifecycle Management: Dynamics 365 for Customer Engagement Apps whitepaper and especially the section on solution boundaries which outlines some of other valid scenarios for having multiple solutions e.g.  the scenario where you need to deploy to multiple regional production instances with small variations with a core solution approach and on top local solutions  or the scenario where you need to release subsets of applications on different cadence/timeline.


Friday, January 31, 2020

Dynamics 365 and Power Platform monthly reading list December 2019

Technical topics (Configuration, customization and extensibility)

Topics for Dynamics 365 Business Application Platform analysts, project managers and power users

Thursday, January 16, 2020

Dynamics 365 or Power Platform New Year's resolutions

We are already 3 weeks in 2020 but there is still time for New Year's solution so choose one of the 12  potential Dynamics 365/Power Platform New Year's resolution as proposed in Episode 69 of the CRM MVP Podcast hosted by @gusgonzalez2.



I will try to take at least 10 out of 12 in 2020 so what is yours?
  1. Write a valuable blog article every week - I probably want to go for 52 blog posts this year.
  2. Deliver at least 4 webinars or  community presentations in a year
  3. Register for the Dynamics Insider program and commit to test every new release and provide feedback to Microsoft
  4. Answer 60 questions on the forums (Microsoft Dynamics Forums, CRMUG Forums, etc...) 
  5. Attend a training from a Dynamics 365/Power Platform expert that you admire or who you consider to be a top expert in the domain
  6. Create a XrmToolBox plugin 
  7. Speak at a major conference
  8. Contribute 24 tips to @crmtipoftheday by sending an e-mail to jar@crmtipoftheday.com
  9. Learn something new about Power Platform/Dynamics 365 every month - you can learn a lot by dedicating 8 hours a month on a single topic
  10. Teach something new about Power Platform/Dynamics 365 every month e.g by delivering a lunch&learn session in your company
  11. Use "new" functionality in Power Platform/Dynamics 365 at least once every month e.g. use Flow/Power Automate instead of using workflows or use the new Admin portal and solution designer
  12. Release a free solution to the community  e.g. a PCF control 

Update on Dynamics 365/CDS request limits

End of August Microsoft announced an API based limitation which is based on users and the type of licenses they have - the latest documentation is available on http://aka.ms/platformlimits  as well as PowerApps and Microsoft Flow licensing FAQs for October 2019. I would recommend regularly checking these pages as they have been updated quite a few times in the last months.

During interactions with Microsoft the last couple of months, they explained that the allocated number of API calls within the different licenses are based upon internal telemetry on the current Dynamics 365 customer base. The claim is that 95% of customers fall within the standard allocated API limits. But if you are using a lot of integrations, you might need to  re-architect part of your solution.

Listed below are the key takeaways:
  • Users with a Dynamics 365 Enterprise Application license have 20.000 API requests allocated in a 24 hour window.
  • Technical/non-interactive/application users get allocated 100.000 API requests if at least one Dynamics 365 API license is available.
  • If a user exceeds the limits the admin for the tenant/environment will receive a notification - end users will not be blocked from using the app.
  • This new licensing went into effect for new customers who on boarded after October 2019. Existing customers have a transition period until October 2020 or when their licensing contract expires. Whichever is longer. For customers with an enterprise agreement this will be the end of their EA (in most cases I know these contracts are valid for 3 years), customers on a CSP contract typically have a yearly expiration date. Reach out to your licensing partner or Microsoft for more details. 
  • The currently available statistics in the Power Platform Admin Center are still quite rudimentary but are a good starting point to assess the impact on your environment 
  • It is possible to purchase additional blocks of 10,000 daily API requests for $50 per month (For details reach out to your licensing partner)
  • Batch requests (Executemultiple) only count as 1 API call, so you can wrap a 1.000 individual calls in one ExecuteMultiple call.
References:

Tuesday, January 14, 2020

My perspective on the PowerApps Build Tools for Azure DevOps

Mid July 2019 Microsoft released a preview of a set of PowerApps specific Azure DevOps Build tasks.  In the last months this tooling has been updated on a quite regular pace which indicates that  ALM (Application Lifecycle Management) for Power Platform (and Dynamics 365 Sales/Customer Service/etc..) is high on the priority list for Microsoft.


For those of you who are new to Azure DevOps, here is a small summary. Azure DevOps is a set of services hosted on Microsoft Azure cloud which support your full software development lifecycle  e.g. you can use Azure Boards for work tracking and backlogs, Azure Pipelines for  CI/CD, Azure Repos for source control, and much more.  Azure DevOps is successor to  Visual Studio Team Services (VSTS) and the best thing of all you can get started with it for free. (For more details see Pricing for Azure DevOps). You can start learning Azure DevOps by exploring the Azure DevOps Hands-On Labs

In the past most Dynamics 365 CE consultants largely relied on a BYOALM (Bring Your Own ALM) approach meaning that you need a combination of PowerShell script, SDK extensions, etc … to automate the build and release of Dynamics components. I even think that in the majority of cases there is no fully automated build and release process in place - meaning that a deployment relies on a number of (hopefully documented) manual steps.  In one of the projects I recently worked on - we have been using the excellent Dynamics 365 Build Tools for Azure DevOps from Wael Haemze so there are other extensions available for Azure DevOps as well.

After you have installed the PowerApps Build Tools you will see a whole set of build and release tasks that you can use in your build and release pipelines. To explore the possibilities you can start with the PowerApps Build tools for Azure DevOps Hands On Lab files which contains a walk through of the different scenarios like for example using the PowerApps Solution Checker (see reference section for more information on this)



If you compare the PowerApps Build Tools with the Dynamics 365 Build Tools, you will probably see that Dynamics 365 Build Tools currently still offers more capabilities but it does seem worthwhile to start exploring the newly released Microsoft tooling.  I recently also got feedback within the context of a Microsoft support case that they recommended to use the new PowerApps build tooling because they would not troubleshoot issues with other extensions on top of Azure DevOps in combination with Dynamics 365.

I  also expect more information to come available in the coming weeks as we are getting closer to the Dynamics 365 and Power Platform 2020 Release Wave 1 . In the meanwhile I will be sharing more information in some upcoming blog posts.


References: