As the landscape of business software solutions evolves, Dynamics 365 continues to make strides in providing flexible and powerful tools for businesses, and Dynamics Edge offers Dynamics CRM Solution Management Training October 2023 to help you succeed. Central to its offering is the concept of solution management, which allows businesses to manage and implement custom functionality within their CRM. Two types of solutions exist in Dynamics 365: managed and unmanaged. Understanding these, and their respective use cases, is essential for effective CRM management.

Dynamics CRM Managed vs Unmanaged Solutions
Dynamics CRM Managed vs Unmanaged Solutions


The primary difference between these two solution types lies in their lifecycle and flexibility. Managed solutions are typically completed and ready for deployment to production environments. They provide a comprehensive and stable lifecycle that can be readily distributed and installed, embodying a consistent and repeatable set of features. Consider these as your ‘out of the box’ solutions, standardized across deployments and locked for editing to ensure reliable and consistent functionality.

Unmanaged solutions, on the other hand, are akin to development playgrounds. These solutions are typically in-progress, offering a sandbox environment for developers to make iterative modifications and customizations. They are flexible, mutable, and dynamic, allowing organizations to mold the solution to fit their unique business processes. Developers may introduce changes, experiment with new features, and generally customize the solution to align with the organization’s unique needs.

When creating a new solution in Dynamics 365, the Power Apps Component Framework (PCF) can play a critical role. PCF offers a robust framework for creating and customizing components in both Canvas and Model-Driven apps. These custom components can be added to solutions and enhance their functionality.

Updating a PCF Canvas App solution typically involves incrementing the Input XML manifest file, specifically the ‘Solution.xml’ and ‘Customizations.xml’ files. This increment signals a version change and enables the updated solution to be deployed successfully.

The ‘Solution.xml’ and ‘Customizations.xml’ files are pivotal to a Dynamics 365 solution. The ‘Solution.xml’ file contains crucial information about the solution, such as the unique name, version number, and the publisher. The ‘Customizations.xml’ file, on the other hand, contains all the modifications or customizations of the solution, including the schema, attributes, entities, workflows, and more.

When updating a solution, both of these files need to be incremented to signal a version change. This incremental change in the version number informs the system of a new version, triggering an update process. However, different scenarios occur when none, only one, or both files are incremented.

  • When none are incremented: When neither the ‘Solution.xml’ nor the ‘Customizations.xml’ file’s version is incremented, the Power Apps platform does not recognize any changes. As a result, the update process is not triggered, and the older version of the solution continues to exist. This could lead to inconsistencies and potential issues, especially if there have been modifications in the actual solution components but the system has not been informed of these changes.
  • When only ‘Solution.xml’ is incremented: If only the ‘Solution.xml’ file’s version is incremented, the system recognizes that there is a new solution version, but since the ‘Customizations.xml’ version remains unchanged, it might not acknowledge any modifications in the solution’s customizations. This situation may lead to partial updates, where the new version of the solution is reflected, but the updated customizations may not actually be applied.
  • When only ‘Customizations.xml’ is incremented: Conversely, if only the ‘Customizations.xml’ file’s version is incremented, the system understands that there have been changes in the solution’s customizations. However, without the ‘Solution.xml’ version change, the system may not recognize it as a new version of the solution. This scenario may result in the system overlooking the overall solution update while applying the customization changes.
  • When both are incremented: Finally, the ideal scenario is when both ‘Solution.xml’ and ‘Customizations.xml’ files’ versions are incremented. In this case, the system recognizes the new version of the solution and acknowledges the customization changes. As a result, the update process is triggered correctly, ensuring that the new solution version, along with the updated customizations, is successfully deployed.

In essence, maintaining the correct versioning in both ‘Solution.xml’ and ‘Customizations.xml’ files is critical to successful solution deployment in Dynamics 365. Incorrect versioning can lead to partial updates or missed updates, causing potential inconsistencies and issues in the solution’s functioning. Thus, always remember to increment both files to ensure a smooth and successful solution update process.

The previous discussion focused on the importance of incrementing the version numbers in ‘Solution.xml’ and ‘Customizations.xml’ within the scope of a Dynamics 365 solution. Both these files play crucial roles in managing the versioning and applying updates to your solution. The ‘Solution.xml’ file houses vital information like the unique name, version number, and the publisher of your solution, while ‘Customizations.xml’ contains details of all modifications made to the solution.

Now, let’s shift our focus to another important part of the Power Apps ecosystem – the Power Apps Component Framework (PCF) within a Canvas App. Here, the files of interest are the ‘Solution.xml’ and the ‘ControlManifest.Input.xml’. Even though the ‘Solution.xml’ file appears in both cases, it serves a slightly different purpose in each. While it manages the overall solution versioning in Dynamics 365, in PCF it plays a key role in recognizing the updated solution during the import stage in Dataverse. The ‘ControlManifest.Input.xml’, on the other hand, is crucial for recognizing updates to the PCF control within the Canvas App.

Having clarified the roles of these files, let’s explore the consequences of different versioning scenarios for ‘Solution.xml’ and ‘ControlManifest.Input.xml’ in updating a PCF Canvas App.

  • When neither the Solution.xml nor the ControlManifest.Input.xml are updated: If neither of these files is incremented, the Power Apps platform would not be able to recognize any changes made to your code component. Consequently, the updated solution would not be imported to the Dataverse and no changes would be recognized. Also, there would be no prompt in the Power Apps Studio for updating the code component when reopening the Canvas App for editing. Essentially, your update would not be acknowledged and applied by the system, keeping the previous version intact.
  • When only the Solution.xml is updated: In this case, the updated solution will be recognized by Dataverse during solution import because the version number of the ‘Solution.xml’ file has been incremented. However, as the ‘ControlManifest.Input.xml’ remains unchanged, Power Apps Studio would not recognize any changes to the PCF control, thus no prompt for updating the code component when reopening the Canvas App for editing. As a result, while the solution might be updated in the Dataverse, the changes to the PCF component might not get applied in the Canvas App.
  • When only the ControlManifest.Input.xml is updated: This situation, although not specifically tested as per your recall, would likely behave similar to the scenario where neither file is updated. Because the ‘Solution.xml’ file controls the solution’s version number recognized by Dataverse, a lack of increment here might lead to the solution not being recognized as updated during the import stage in Dataverse. Therefore, despite changes in the PCF control (indicated by ‘ControlManifest.Input.xml’ increment), they may not get reflected in either the Dataverse or the Canvas App.
  • When both are updated: This is the optimal situation. Here, the system recognizes a change both in the solution (through the ‘Solution.xml’ increment) and the PCF control (through the ‘ControlManifest.Input.xml’ increment). Consequently, during the solution import, Dataverse acknowledges the updated solution, and when reopening the Canvas App for editing in Power Apps Studio, you are prompted to update the code component. Accepting this prompt applies the updated PCF control changes in the Canvas App.

To sum up, both ‘Solution.xml’ and ‘ControlManifest.Input.xml’ play a crucial role in ensuring your PCF control changes are recognized and applied correctly by the Power Apps platform. The ‘Solution.xml’ manages the overall solution versioning in the Dataverse, while the ‘ControlManifest.Input.xml’ controls the versioning of the PCF control in the Canvas App. Keeping both files correctly updated ensures a seamless update and deployment process for your PCF controls in Canvas Apps.

Beyond CRM capabilities, the broader Power Platform offers additional tools to supercharge business processes. Power BI, for instance, is a powerful analytics tool that can present complex data in an easily digestible format. Dynamics 365 Canvas Apps can be embedded in Power BI dashboards, providing an interactive experience where users can manipulate data and view real-time updates within their reports.

Over the years, Dynamics CRM has evolved and expanded to form part of the broader Dynamics 365 ecosystem, encompassing other services like Power Automate, Power Apps, and Power Virtual Agents. This ecosystem, now commonly referred to as the Power Platform, provides an integrated suite of tools that work seamlessly together, leading to greater efficiency and improved business processes.

The relationship between Dynamics CRM, Dynamics 365 Sales, Dynamics 365 Customer Service, and Power Apps is a symbiotic one. They all function within the same ecosystem and can be thought of as specific instances of Model-Driven Apps, each designed to address different business needs with tailored functionality.

Speaking of Model-Driven and Canvas Apps, these represent two different types of Power Apps. Model-Driven Apps are typically more structured and rely heavily on the underlying Dataverse data model, offering a complex and feature-rich interface. Canvas Apps, on the other hand, provide a blank canvas for developers to create a custom user interface, making them perfect for designing highly specific apps.

The evolution of Dynamics CRM into the Power Platform has been a game-changer. Earlier, Dynamics CRM was a standalone product that relied on its proprietary database. But with the introduction of the Power Platform, Dynamics CRM (now known as Dynamics 365 Customer Engagement) has become part of a more extensive ecosystem that utilizes a unified data model – Dataverse. This allows for easy integration and interoperability with both Model-Driven and Canvas Apps, all of which can now access and operate on the same data.

As for real-world applications, consider a federal government agency using PCF to develop a custom component that tracks and visualizes specific national security data. This component, integrated into their Dynamics 365 solution, would provide an enhanced tool for data analysis and intelligence operations. By leveraging the flexibility of the Power Platform, the agency can ensure that their solution is tailored precisely to their needs, delivering optimal value.

Have a Question ?

Fill out this short form, one of our Experts will contact you soon.

Call Us Today For Your Free Consultation