Dynamics 365 Data integrations is something that we're quite familiar with - whether it's a custom integration tailored for one of our customers or it's utilizing our popular pre-built solution
One challenge that we've had in the past was speed. In other words, how much time it takes to actually get your data from another system into Dynamics 365. If all that's needed is to Create records, then speed usually isn't an issue. The challenge comes into play when data already exists in Dynamics 365 or you need to backfill data. This could sometimes take several days to several weeks! One of the main reasons for this was that this required 2 steps:
- First, query Dynamics 365 to determine if the record you want to update already exists
- If it doesn't exist, then Create it. If it does exist, then Update it.
That might not seem like much, but if you can imagine trying to backfill thousands or millions of rows of data, this can take a huge toll on performance.
A few years ago, Microsoft began allowing Dynamics 365 developers to use Upsert statements. Upserts can dramatically improve the speed of your data processing. Instead of making 2 separate calls to Dynamics 365, an Upsert allows for one call that can determine if a record needs to be Updated or Created based on a unique key. The key defines the unique identifier for the record (using one field or a combo of fields).
With the introduction of
Developers can create an alternate key programmatically or via the power platform admin center. You can specify up to 5 alternate keys per entity which is sufficient. There are a few other constraints as well, but these likely won't hold you back from using them:
- Only field types of decimal, whole number, single line of text, datetime, lookup and picklist can be included in the key
- All fields included in the key must be allowed to be populated via either a create or update of the entity records
- Field-level security needs to be turned off for the included fields (which is the default)
- Fields can't be logical or inherited. For example, address fields on Account and Contact entities
- The key size can be a maximum of 900 bytes and 16 columns
- Certain special characters (/,<,>,*,%,&,:,\\) in key field values will cause errors when performing a Get or Patch
The challenge with Alternate Keys
You may run into a challenge when creating Alternate Keys in an existing Dynamics 365 organization if it already contains duplicate records as defined by the Key. In that case, you will notice that the Key status is set to Inactive. In order to Activate it, you must eliminate the duplicate records, either by deleting the duplicates or removing the values on one of the corresponding fields for each duplicate record.
You can find duplicates in Dynamics 365 a couple different ways:
Create and publish a duplicate detection rule. Then, run a duplicate detection job on all records for that entity. This process works well for the most part, but can be slow if you have a ton of data.
Use the Dynamics 365 SDK or 3rd party tools which can help you identify duplicates within minutes.
Note: While Dynamics 365 allows you to merge records, this does not remove the duplicate record from the database, so the alternate key will remain Inactive. You can give your end users control over which duplicate records are removed by instructing them to merge the records or utilize a custom merge process. Then, use an automated process to delete the Inactive merged records.
We've been implementing alternate keys with Upserts in our data integration solutions for our customers and we have seen an incredible improvement in speed! It allows us to push more data in a timely manner and the keys help enforce record uniqueness at the database level which in turn makes our customers happy.
If you want to learn more about how you can improving Dynamics 365 data integrations with alternate keys,
Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in