Category: Bug

Solving solution import error 0x80048011 – There are multiple root elements in sitemap client extension

Posted on by Peter Geil

UPDATE 27.07.2021

Microsoft support did confirm that this is a platform bug. A fix is in the making and should be rolled out beginning end of august 2021.

There was a CRM online environment which I did lift and upgrade from CRM2016 on-premise into the cloud (v9.2x) using the MS FastTrack OP2OL project service. So far so good. But whenever the (legacy) default Site Map component was exported in a solution, the resulting customizations.xml solution file was corrupted.

The legacy Site Map client extension was part of the problematic solution

The result was a nasty solution import failure saying that the Client Extension sitemap could not be processed because the related XML element contains multiple root elements.

Client ExtensionssitemapFailure0x80048011There are multiple root elements. Line 1, position 58.
Solution import error being reported

After inspecting the customizations.xml and validating it against the official XML Schemata for XML customization data provided by Microsoft as of today, it became clear why. For some reason the <SiteMap/> collection element contained invalid child nodes which renders the whole customizations.xml invalid.

Not only lines 8-11 contain invalid nodes, also dozens of other schema violations were reported (which are not new)

Solution

Manually edit the customizations.xml file inside the solution zip file and delete the XML nodes shown in the screenshot above (EnableCollapsibleGroups, ShowHome, ShowPinned and ShowRecents), or – when acceptable – just keep the whole legacy Sitemap out of your solutions. The legacy sitemap nowadays should only be needed when the non-UCI menu structure must be customized, which mostly affects the advanced settings area. So moving this into a separate solution that only needs to be deployed every now and then could be a reasonable solution.

Beware of Dynamics 365 Web API: When attribute and entity have same names

Posted on by Peter Geil

With increasing maturity of the OData Web API exposed by Dynamics 365 CE/CRM its adoption does also steadily increase. From my perspective especially from JavaScript client codes. While the Web API doubtlessly has its sweetspots, it also comes with a lot of pitfalls and limitations (yet) we must get comfortable with and become aware of.

One of these pitfalls which I want to recall today, was already covered back in 2017 by Tip #970: When attribute and entity collide and goes like this:

While (technically) the CRM platform allows an attribute to have the same name as the entity it is defined on, the OData Web API is not capable of handling this and simple throws an “Could not find a property” HTTP 400 error.

Keep in mind when designing the entity model: Avoid naming collisions by never giving an attribute the same schema name as its parent entity.

Howto: Attribute fields in detail window of workflow action “Update Record” not editable

Posted on by Peter Geil

Let’s end the week with a tricky issue found even in latest Dynamics 365 / CRM.

Once upon a time, there was a system workflow action called “Update Record”. When users added it to their workflow and opened the detail window for inserting value placeholders, certain fields were mysteriously greyed out so users could not edit them. Coincidentially, the fields being disabled, were exactly those, that have been configured as “read-only” on the entities main form. So obviously CRM is re-using the entities main form definition for building up the detail window of said standard workflow action.

Side note: CRM does this not only for the said “Update Record” workflow action, but also on several more places too, like e.g. bulkoperation distribution window and the outlook client dialogs.

Problem:

Fields marked as “read-only” on entities main form are not editable in detail window of standard workflow action “Update Record”.

Solution:

  1. Open developer tools of your browser (f.e. press F12 in Chrome)
  2. Pick the DOM element representing the attribute input field you want to edit
  3. Delete HTML element attribute “disabled=true”
  4. Do whatever you want to do
Whilst this is no “real” solution to a “real” problem, it’s rather more a clever workaround for editing the detail window form. Whether this is a bug or just a (too?) consequent behaviour of the read-only option of a form control might be debatable. 

Processes and arguments of type “Picklist” ━ a dead end street

Posted on by Peter Geil

Yesterday, one of the few perfect fits for a combination of Dialog and Action Processes have crossed my mind while revising a business requirement. Being satisfied because having found an elegant solution wich furthermore consists of no code or indirections, I first designed the Action Process. The part which caused my today’s rumbling is the following:

First we defined an in-argument of type Picklist (=OptionSet) as required and 
then wanted to write it into an OptionSet field..

Problem 

Microsoft Dynamics 365 (online and on-premise) still does not allow Picklist arguments to be written into Picklist fields.

Solution (😉)

Come on, are you kidding me?? But the story doesn’t end here. I investigated on this issue and found out, that this restriction is imposed somewhere in the platform UI layer, because the underlying Workflow engine used internally by the CRM platform (Windows Workflow Foundation with references to product-specific assemblies) to handle is undoubtedly able to handle those argument types. I exported my Action in a temp solution and edited the XAML workflow definition file manually, so that the above Picklist argument is written into the target field “Business Partner Type”. With success. Oh, and by the way: manually editing declarative workflow processes from MSCRM is supported even for Online.

So again, being happy about having also fixed this issue, I went on by creating my Dialog Process which would have to be invoked by the actual user for choosing the business partner type along with some other parametrized inputs. Then, as last step I added an “Invoke Action” command … but wtf is this? The list of available Actions does not contain the one I just finished before!

After some cross-checks it turned out this behaviour is solely related to the fact that the Action said does contain an In-Argument of type Picklist. Nothing else.

Finishing Move

Action Processes with in-arguments of type “Picklist” cannot be invoked from other Processes. This dilletante limitation seems to be around (google for it) since 2013 and I would not bet a cent that it will be fixed anytime soon.