Data Export Service with Dynamics365 – Gotchas

I had the opportunity to use the Data Export service in Dynamics365 a few weeks ago.  There is a good explanation of the service here and when the implementation is up and running it does a great job of synchronizing data between Dynamics365 and an Azure SQL database.

There were a few gotchas I ran into that I thought I’d write down.

Setting your Azure environment

The trickiest part of the initial implementation is setting up the connection to your environment.

# ----PLACEHOLDER------------------------------------------------------------------ #
$subscriptionId = '[Specifies the Azure subscription to which the Key Vault belongs.]'
$keyvaultName = '[Specifies the name of the Key Vault. If the Key Vault does not exist, the script will create one]'
$secretName = '[Specifies the name of the secret that is put into the Key Vault. The secret holds the destination database connection string.]'
$resourceGroupName = '[Specifies the Resource Group for the Key Vault.]'
$location = '[Specifies the Azure region where the Resource Group and Key Vault is placed.]'
$connectionString = '[Specifies the destination database connection string that would be placed as a secret in the Key Vault.]'
$organizationIdList = '[Specifies a comma separated list of all the CRM Organization Id which will be allowed to export data to the destination database.]'
$tenantId = '[Specifies the Azure Active Directory Tenant Id to which all the specified CRM Organizations belong to.]'
# -------------------------------------------------------------------------------- #

The script itself, does a great job of explaining what you need to do and what variables are required for you to run the script itself.  Once you’ve done this and once you are able to connect to your keyvault, the rest of the implementation is pretty straightforward.

Note: I ran into an issue where I have multiple azure tenants and ended up creating components in the wrong tenant.  Make sure you have your tenant and subscription id set to the correct environment.

Selecting Entities

The second gotcha I ran into was the selection of entities.  I initially went and selected everything thinking this was the easiest way to go.  This was a very bad idea.  There are some entities that are not enabled for Data Export.  Which ones they are, I don’t know.  I didn’t go through all of them and instead focused on the ones that I wanted to sync.  In general this is a good approach for production, but in development, if you’re like me, you want to get up and running, so selecting everything isn’t a bad idea.  In this case it is, only select what you need.

Dynamics365 Tenants must be set to Production

Another gotcha which I didn’t realize until I thought I had everything up and running.  After I fixed the first two issues, when I went to run the first sync, everything was perfect and went fine, afterward, I never had any delta changes being made which became quite problematic as the whole idea is to synchronize it.  What I found is that my Dynamics365 tenant was a sandbox tenant (because it’s in Development) but to use the Data Export service, it has to be marked as Production.  Once I did that, everything worked fine.

Hopefully, this saves you some time and gets you to the point where you start seeing this in your Dynamics tenant.

dataexport

 

Post A Reply

%d bloggers like this: