Maintain the same GUIDs in Dynamics 365 environments
Introduction
In a Dynamics 365 environment, there are different types of data i.e.
- Migration data – data that is imported from various legacy systems
- Application user data – data that the users have entered
- Application configuration data – data such as postcodes, bank account types
- Technical configuration data – data such as business units, teams & queues
When importing configuration data records to a new environment, it’s recommended that each newly created record maintain the same GUID as in the origin environment. Three examples of why this is the case are shown below.
(To deploy this data, tools such as as KingswaySoft, the Configuration Migration Tool, spreadsheets, an XrmToolBox plugin…are used. (The data isn’t contained in a Dynamics 365 solution.))
Example 1 – Keeping the same Bank Account Type GUIDs
On a Dynamics 365 custom ‘bank account’ form (not displayed here), there is a lookup field, which is a lookup to the bank account types (Figure 1). Selecting ‘Savings Account’ displays the fields and sections on the form related to the ‘Savings Account’. The form’s JavaScript identities this account via it’s GUID and will only work successfully if the bank account type’s GUID in the destination environment match the origin environment
Example 2 – Keeping the same Team GUIDs
This view will only work in the destination environment if the Team GUID in the destination environment matches the origin environment. For example, if the Team GUID = 4DB74768-C73C-EA11-A812-000D3A794F5D (Figure 2)
Example 3 – Keeping the same Queue GUIDs
Starting a workflow that contains a ‘Send Emails’ step will only succeed if the GUIDs of the queues (Figure 3) in the destination environment match the origin environment.
Alternative solution to maintaining the same GUIDs between environments
Option 1
Rather than keeping the GUIDs the same when copying data to a target environment, another option could be to retrieve the newly created GUIDs (in the target environment) at runtime. To achieve this in the form’s JavaScript, a Web API call, using FetchXml could be used to fetch the GUIDs.
Option 2
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.
Appendix
Example 4 – ‘Views’ in a solution maintain the same GUIDs
Set the ‘application type’ field on a form to ‘Home Loan’ (not displayed here). This form also contains a subgrid (Figure 4) which contains three different views.
Referring to the code below, the form’s JavaScript uses the ‘Home Loan’ view’s GUID to display that particular view on the subgrid. The works because the views’ GUIDs don’t change between environments
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);
}
}
Determining the views’ GUIDs
Further reading
Migrate data from a legacy system into Dynamics 365