As part of the migration process between environments, it’s important to consider if the GUIDs of any components need to be maintained. For example, a component (e.g. a workflow) that references (the GUID of) a particular queue in UAT that will need to reference the same GUID value in Production.

Solutions

When a solution is deployed to a higher environment, the GUIDs of the various components within the solution are maintained. One benefit of this is that a form’s JavaScript (in the higher environment) can reference the GUIDs of those components (although it may not be best practice) and the JavaScript will still work.

Example 1

Consider the example where a subgrid on a form has 3 different views, which are being being migrated from UAT to Production. (Note: The manual view selector isn’t enabled. The reason being that the view will be automatically set in JavaScript, based on the application type.)

The form’s JavaScript uses the selected view’s GUID to display that relevant view. Since the GUIDs didn’t change when migrated, the JavaScript still works.

function onSave() {
    if ((Xrm.Page.data.entity.attributes.get("cpl_applicationtype).getValue() !== null) {
        if (Xrm.Page.data.entity.attributes.get("cpl_applicationtype).getValue() == ApplicationType.HomeLoan) {
	    ApplicationDecision = {
            entityType: 1039,
            id: "{6BFE654A-2024-EC11-A2E5-005056856930}", 
            name: "Home Loan Application Decision"
            }
        } else if (Xrm.Page.data.entity.attributes.get("cpl_applicationtype).getValue() == ApplicationType.PersonalLoan) {
	    ApplicationDecision = {
            entityType: 1039,
            id: "{68925657-2024-EC11-A2E5-005056856930}", 
            name: "Personal Loan Application Decision"
        } else if (Xrm.Page.data.entity.attributes.get("cpl_applicationtype).getValue() == ApplicationType.CreditCard) {
	    ApplicationDecision = {
            entityType: 1039,
            id: "{39FC825F-2024-EC11-A2E5-005056856930}", 
            name: "Credit Card Application Decision"
        }
    }
}

...

try {
    Xrm.Page.getControl("thesubgrid").getViewSelector().setCurrentView(ApplicationDecision);
    } catch (e) {
        alert("setCurrentView caused an exception = " + e);
    }
}

Btw, when writing the JavaScript, the GUIDs of each view were found by using the Advanced find tool.

If any of the views were manually created in the production environment, rather than imported in a solution, the view’s GUID would be different to what’s specified in the JavaScript. This would result in the JavaScript failing.

Configuration Data

Configuration data (as opposed to application data) exists in several components e.g. Business units, users, teams, queues. This data, like application data, isn’t migrated as part of the solution but rather deployed separately (usually using the Configuration Migration Tool, spreadsheets or a XrmToolBox plugin). Quite often, each configuration data entry needs to retain their GUID when they’re deployed to a higher environment. An example of why this is the case is shown below.

Example 1

This view has been created with a filter that references the Team A’s GUID. So, when this view is migrated from UAT to Production, for instance, the view will only work if the GUID remains the same.

Example 2

This email has being defined with queues in both ‘From’ and ‘To’. Consider when the workflow that contains this ‘Send Email’ step is deployed to a new environment. The workflow will only start successfully if the GUIDs of the ‘Contoso Marketing’ and ‘Contoso Sales’ queues in the destination environment match the origin environment.

Example 3

Configuration data can also be user defined i.e. data stored in a custom entity. An example of this is the ‘Bank Account Types’ entity shown below.

Each account type is referenced in JavaScript (referencing the GUID) to determine which Dynamics 365 form tabs to show/hide depending of the account type. That is, if ‘Savings Account’ is selected, the form is rendered to display only tabs that are relevant for a savings account.

(Alternate option 1) Rather than keeping the GUIDs the same when migrating to a higher environment, another option could be to retrieve the GUIDs at runtime. To achieve this in the form’s JavaScript, a Web API call, using FetchXml could be used to fetch the GUIDs. There would be a performance impact with this option so that would need to be considered.

(Alternate option 2) A further option could be to have a entity which contains name/value pairs. For example:

Type A 264b925d-…

Type B e65e67f0-…

These values could be updated to the GUID values in the current environment and the form’s JavaScript could retrieve the GUIDs from this entity.