|
| 1 | +--- |
| 2 | +title: "How managed solutions are merged (Common Data Service) | Microsoft Docs" # Intent and product brand in a unique string of 43-59 chars including spaces |
| 3 | +description: "To avoid multiple installed solutions from interfering with one another, follow best practices while constructing a solution" # 115-145 characters including spaces. This abstract displays in the search result. |
| 4 | +ms.custom: "" |
| 5 | +ms.date: 02/27/2020 |
| 6 | +ms.reviewer: "" |
| 7 | +ms.service: powerapps |
| 8 | +ms.topic: "article" |
| 9 | +author: "shmcarth" # GitHub ID |
| 10 | +ms.author: "jdaly" # MSFT alias of Microsoft employees only |
| 11 | +manager: "ryjones" # MSFT alias of manager or PM counterpart |
| 12 | +search.audienceType: |
| 13 | + - maker |
| 14 | + - developer |
| 15 | +search.app: |
| 16 | + - PowerApps |
| 17 | + - D365CE |
| 18 | +--- |
| 19 | +# Understand how managed solutions are merged |
| 20 | + |
| 21 | +When you prepare your managed solution to be installed, remember that an environment may have multiple solutions installed or that other solutions may be installed in the future. Construct a solution that follows best practices so that your solution will not interfere with other solutions. |
| 22 | + |
| 23 | +The processes that Common Data Service uses to merge customizations emphasize maintaining the functionality of the solution. While every effort is made to preserve the presentation, some incompatibilities between customizations may require that the computed resolution will change some presentation details in favor of maintaining the customization functionality. |
| 24 | + |
| 25 | +<a name="BKMK_MergingFormCustomizations"></a> |
| 26 | + |
| 27 | +## Merge form customizations |
| 28 | + The only form customizations that have to be merged are those that are performed on any entity forms that are already in the environment. Typically, this means that form customizations only have to be merged when your solution customizes the forms that were included for entities created when Common Data Service was installed. One way to avoid form merging is to provide new forms for any Common Data Service entities. Forms for custom entities will not require merging unless you are creating a solution that updates or modifies an existing managed solution that created the custom entities and their forms. |
| 29 | + |
| 30 | + When a solution is packaged as a managed solution the form definitions stored in FormXML are compared to the original FormXML and only the differences are included in the managed solution. When the managed solution is installed in a new environment, the form customization differences are then merged with the FormXML for the existing form to create a new form definition. This new form definition is what the user sees and what a system customizer can modify. When the managed solution is uninstalled, only those form elements found in the managed solution are removed. |
| 31 | + |
| 32 | + When you add new elements to a form that is to be merged, we recommend that you include your new elements within new container elements (tabs or sections). Additions to any container will be appended to the end of the container. For example, fields added to a section will be positioned at the end of the section. It is expected that a customizer installing a solution will then modify the form to rearrange elements after it is installed. |
| 33 | + |
| 34 | + Managed solutions that contain forms that use new security roles depend on those roles. You should include these security roles with your managed solution. If there are security roles associated with a form that are not in the environment that the managed solution is being installed on, the installation will not fail but the forms may not be associated with any security roles. When the managed solution is uninstalled, any security roles included with it will be removed. Any forms outside the managed solution can no longer be associated with those security roles. |
| 35 | + |
| 36 | +> [!NOTE] |
| 37 | +> When a managed solution entity contains multiple forms and the environment entity form also contains multiple forms, the new forms are not appended to the bottom of the list of available forms – they are interleaved with the original entity forms. |
| 38 | + |
| 39 | +<a name="BKMK_MergingNavigationCustomizations"></a> |
| 40 | +## Merge navigation (SiteMap) customizations |
| 41 | + When a solution is packaged as managed the SiteMap XML is compared to the original SiteMap XML and any other customizations made to the SiteMap. Only the differences are included in the managed solution. These differences include items that are changed, moved, added, or removed. When the managed solution is installed in a new environment, the SiteMap changes are merged with the SiteMap XML found for the environment where the managed solution is being installed. A new SiteMap definition is what people see. |
| 42 | + |
| 43 | + At this point, a customizer can export the SiteMap to an unmanaged solution and that SiteMap definition will include all the elements of the active SiteMap. A customizer can then modify the SiteMap and reimport it as an unmanaged customization. Later, if the managed solution is uninstalled, the SiteMap XML that was imported with the managed solution will be referenced to remove the changes introduced with that managed solution. A new active SiteMap is then calculated. |
| 44 | + |
| 45 | + Whenever a new visible element is added to the SiteMap, it appears at the bottom of whatever container it belongs in. For example, a new area appears at the bottom of the Navigation area. To position the elements that have been added, you must export the SiteMap, edit it to set the precise position and then import it again as an unmanaged solution. |
| 46 | + |
| 47 | +> [!NOTE] |
| 48 | +> Only one SiteMap customization can be applied between publishing. Any unpublished SiteMap customizations will be lost when a new SiteMap definition is imported. |
| 49 | + |
| 50 | +<a name="BKMK_MergingOptionSetOptions"></a> |
| 51 | +## Merge option set options |
| 52 | + Each new option set option is initialized with an integer value assigned that includes an option value prefix. The option value prefix is a set of five digits prepended to the option value. An option value prefix is generated based on the solution publishers customization prefix but may be set to any value. The option value prefix helps differentiate new option set options created in the context of a specific solution publisher and reduces the opportunity for collisions of option values. Using the option value prefix is recommended but not required. |
| 53 | + |
| 54 | + A managed solution usually updates or adds options for option sets that are already in the environment, for example, the account Category or Industry option sets. When a managed solution modifies the options available in an option set, all the options defined in the managed solution are available in the environment. When the managed solution is uninstalled, the option set options will be returned to their original state. |
| 55 | + |
| 56 | +### See also |
| 57 | + |
| 58 | +[Solutions overview](solutions-overview.md) <br /> |
| 59 | +[Export solutions](export-solutions.md) <br /> |
| 60 | +[Create a model-driven app site map using the site map designer](../model-driven-apps/create-site-map-app.md) |
0 commit comments