Globally Unique Identifiers (GUIDs) are the primary key of all entities in CRM and are sequentially generated. There is often confusion about how GUIDs work, how unique they are, and how they are generated in CRM. This confusion can often lead to unnecessary or bad requirements when planning integrations or migrations for Dynamics 365. Let's discuss some of the different kinds of GUIDs, and how their nature will affect requirement gathering.
A GUID is a range of values, much like a number. However, instead of using a base-10 number to represent each value in the range, as with an integer, it uses a "hexadecimal digit with the range of 0-9 and a-f in the format of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx."
Perhaps the most important feature of the GUID is the extend of the range. The number of possible GUIDs is astronomically vast. The total number of possible combinations is 2^128. to show how big a number this is, here it is without scientific notation:
340,282,366,920,938,000,000,000,000,000,000,000,000
(This is roughly the number of every gain of sand on earth, times 4.5 billion, then times again by one billion.)
One main issue of confusion regarding GUIDs is the misunderstanding that there are different types, that derive their value in different ways. While there are formally five versions of GUIDs (and functionally many ways of getting these five versions), all GUIDs can be summed up in two categories: Sequential and Random.
One main point to take away here: GUIDs are designed to be unique, not random.
In Microsoft SQL Server (the database driving D365), there are two ways to generate GUIDs. The first we'll discuss, NEWSEQUENTIALID, is sequentially (not randomly) generated. It is important to note that the range at which the GUID starts is randomly selected when windows starts, and each subsequent GUID created will be a value sequentially higher than the previous. When windows restarts, the next sequential "GUID can start from a lower range, but is still globally unique." Also, different machines will be working with different ranges, however these will also still be globally unique.
Using sequential GUIDs as primary keys for DB tables allows for optimal indexing and performance, both for creating and querying records. As such, D365 follows best practice.
The other type of method to create GUID in MSSQL is NEWID. This is a randomly generated, but still unique. However, these don't index as well and have more of a performance impact when used as primary keys on DB tables (poor practice, but not how CRM works). Often when speaking to infrastructure architects and the likes, make sure they know that GUIDs are sequentially generated, and will perform similarly to an incremental integer as a primary key.
Another point to take away: CRM generates GUIDs sequentially, not randomly.
Another concern that comes from a misunderstanding of GUID generation is a fear that a duplicate might occur.
This might be a following example where this fear might exhibit:
There is a project in which multiple child Dynamics 365 systems needed to be integrated into one main D365 parent. There were concerns that, even though sequentially generated, these different CRM systems could share the same GUID ranges and could cause collision if we tried to directly map the primary keys from the child to the parent. This concern, while understandable, is negligible.
Another point to take away: You'll never see a GUID duplicated.
The likelihood of getting duplicates are very unlikely. Here are some stats to show how completely negligible these chances are.
In this project, if we had 1000 child D365 orgs that were each creating one billion records per second each for a year (that's right, 1,000,000,000,000 per second between all Orgs, for a total of 31,536,000,000,000,000,000 records), the likelihood that there would be a duplicate collision in the master org integration would be about this:
0.000000000000000009%
So... zero percent.
According to National Geographic, a person worrying about duplicates would be more than 15 trillion times more likely to be struck by lightning than for a duplicate to occur in the above scenario in that same year.
Another point to take away: Always map the primary key between D365 and other systems.
It is best practice to maintain the GUID from any record when integrating or migrating between any environment. This will help ensure data integrity, and there is no need for concern regarding GUID collision.
For more Dynamics 365 tips and tricks – be sure to subscribe to our blog!
Happy Dynamics 365'ing!
