Check out the latest Sales updates!Learn about the key capabilities and features of Dynamics 365 Sales and experience some of the new features.
Download overview guide | Watch Sales video
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
we have our own solution.
Now we installed Field Service as we are planning to use it.
Field Service now lies on Order 7 while our own solution is only on order 6.
How can we change the order of the solution layers, so our solution is on top again?
The Solution Layer Order is actually the order in which the solutions are installed.
So you only need to import your own solution again.
We tried this. But it did not work this way.
Do we have to change the version number or anything?
You can change the version number or the name of the solution and import it again.
I tried changing the version number and importing it again.
This did not seem to work. If I apply a solution upgrade, I would assume that it will still be on a lower level than Field Service.
For solutions that you install directly, then the previous answers are correct, in that it depends on the installation sequence.
However, Microsoft appear to have further control over the sequence of the solutions they provide (such as Field Service), and I don't think there's any way to change this.
What are you trying to achieve ? If you are trying to modify components that are part of Field Service, you could create a further solution with just those components, and I believe that should end up at a higher level
Thanks for the answer!
Fields Service modifies the Option Set "statuscode" (Status Reason) in the "Order" entity.
We customized this Option Set, but the Field Service Solution overwrites (or tries to merge) these changes.
I am not sure, that when I create a new solution, only having the Order Entity and the Option Set in it, that this would be applied AFTER the field service solution. But I guess I have to try.
I've contacted Microsoft Support. Lets see what they say.
I'm wondering if the following will re-organise your solution order:
1. create a copy of your existing solution using a different solution name
2. import this new solution
3. remove your previous solution
this is a good idea that I've also thought about.
To do this, I probably need to copy the XML files and rename the solution in there?
Is it only "solution.xml" where I have to change the name?
I will have to check if this doesn't mess up anything, but then it would be a good fix!
MS Support hasnt been really helpful until now.
Thats right the uniquename and localizedname elements... as below
<LocalizedName description="Employer Services Contact Hub" languagecode="1033" />
I too have been caught out by microsoft and their solution management.
I think its part of being involved in D365, it teaches you a lot about solution management.
We ran into the same issue. For my customer we have a core-solution containing our main customization's to entities and attributes. Our deployment is fully automated over Azure DevOps and working fine. After installing D365 Marketing solutions, we noticed our customization's are no longer taking effect. After raising a ticket with Microsoft Premier support, the support-engineer has informed us our solution is replaced in the layer-order by the last imported solution (being Microsoft Marketing).
It appears that increasing the version number of an existing solution, and deploying it with either Upgrade or Update option does not effect the layer stack. It appears only the initial date on which the first solution with that name was imported effects the layer stack.
For ALM to work in practice, it would be necessary for an existing solution, with increased version number, to also update to the highest order in the stack. Otherwise customer customization's would be nullified by any ISV or Microsoft solution installed.
I think it would be a great option to let customers control the solution order when upgrading or updating an existing solution (or let us define the position in the layer manually).
We will further discuss this option with the Premier support engineer and fast-track. Will let you know the outcome.
yup. That sounds like the exact same issue that we are facing right now.
So far, unfortunately our Consultants & (regular) Microsoft Support haven't been very helpful.
Through my own research I came to the same conclusion. Installation date is the sole metric that counts. Which is why the solution page is sorted by installation date by default.
The solutions I found so far:
1) The one from Arthur, which seems to work, but I couldn't fully test it yet.
1.1) Export your Solution as unmanaged
1.2) Rename in XML
1.3) Import unmanaged, delete old one
1.4) Export managed
1.5) Import to Production
1.6) (Maybe?) delete old managed solution from Production
2) Create a new solution
Thanks for letting us know, if the Premier Support comes to a better solution! Thanks :)
Our consultants also pushed the "1 Solution Approach" to us. Which I don't like so much anymore after working with solutions quite some time.
At least in our case, it would have made more sense to split Solutions by topics: "Hubspot Integration", "Hardware Management", "Portal Integration".
Business Applications communities