Dynamics Community Forum Thread Details

Dataverse integration Job Queue Entries switches user resulting in error

Hi there,

For our implementation of BC and Dynamics 365 Sales professional we have enabled both the "Dataverse connection setup" and the "Microsoft Dynamics 365 Connection Setup". Following the guides, I've enabled them through an administrator account. The Dataverse integration user is listed below.

Figure 1. Dataverse Integration User.

After setup, Job queue entries were created under the name of the admin account I provided. Data was correctly synced.

Figure 2. Job Queue Entries running under the Admin account.

But if (normal) users of the Dynamics CRM make changes to records, the Job Queue Entries are set run from their corresponding account! This lead to errors, since these accounts have no write-privileges in BC. Data is now no longer synced.

Figure 3. Job Queue Entries suddenly running under a normal user account.

Expected behaviour:
The admin account provided when setting up the sync user is responsible for triggering the synchronization task for BC and Dataverse/Dynamics 365. The user account that makes changes to records should not be used to trigger the sync.

Categories:

Other

Data Migrations

Hello,

This is a known issue - job queue entries that are in state On Hold With Inactivity Timeout change the owning user to current user, when the current user performs a CRUD operation on the related record.

This will be addressed by Microsoft when we get to it.

Ad-hoc mitigation:

Sign in as the user who initially set up the Dynamics 365 Sales integration and restart the affected job queue entries. This will change the user back to the correct user who has enough permissions to run the synchronization.

Other mitigations (if ad-hoc mitigation is not enough)

If you have a business scenario such that users without effective permissions to run the synchronization (such as Team Member license users) need to perform CRUD operations on invoices, customers, units of measure, sales prices etc. then you have two options:

- elevate the permissions of these users so that they have the required permissions to run job queue entries and Dynamics 365 Sales integration related codeunits and tables (assign him the same license as the users who can perform these actions have)

- if you don't want to elevate the permissions of these users, you can write a per tenant extension and have a "job queue management" codeunit, and set it up to constantly run in background (as a recurring job queue entry under the admin user). This codeunit needs to subscribe to event OnAfterEnqueueJobQueueEntry fired by JobQueueEnqueue.Codeunit.al (453), and check if the job queue entry that is being requeued is a Dynamics 365 Sales codeunit and that it has changed the owner to some other user (other than the user who initially set up the synchronization). In this case, from the subscriber code, restart that job queue entry from the subscriber method, and it will get the admin as the owning user again.

Having this subscriber, you will make sure that the owner of the job queue entries doesn't change.

Thanks.

Quick Links

Leaderboard