Dynamics 365 Business Central, Service-to-Service authentication (OAuth) and Task Scheduler

Just before Christmas I received a request from a partner about a feature that personally I never had the need to implement before (at least in this way). In the current Dynamics 365 Business Central implementation they have an API that permits to an external application to post records in a custom table and after that the application also creates a task in the Task Scheduler for processing those records asynchronously.

The external application consumed the API by using Basic Authentication successfully for lots of months. But one of the work done with this partner in the last weeks was to optimize some of its services for the cloud and to move its APIs integrations from using Basic Authentication to using the recommended S2S authentication with OAuth2.

What happens now after these changes?

The API integration started failing with the following error:

"You do not have permission to create or run scheduled tasks."

The partner has also worked on changing permissions to the Azure Active Directory Application registration, but nothing changes.

Why this error? Is this a bug or not?

NO… this is by design!

As stated with the Delegated Administrators documentation, scheduled tasks must be created and executed in the context of a licensed user, so you cannot create or execute a task with the S2S authentication. For security reasons, an app registration cannot create or execute scheduled tasks (and this is absolutely correct).

The only possible way to obtain the same result as before (if you really need to do this from an external app) is to encapsulate the logic of the scheduled task in an API and then call it from a Timer Trigger Azure Function or from a Recurrence trigger of a Logic App flow (or obviously do the task scheduling via a real user):

If you’re doing similar things now, don’t be crazy if your integrations will start failing when moving to S2S authentication and just remember this post 😉

3 Comments

  1. couldn’t the table have code on the onvalidate trigger to call a codeunit that performs what the task scheduler schedules to do?

    Like

    1. Yes. The solution here is only to place the code into the API itself, because scheduling a task directly with Task Scheduler is not possible. If you really need to create and execute scheduled processes from the outside, a good approach is to use timer triggered flows.

      Like

  2. There are lots of reason I can think of why you want to use the Job Queue for handling the processing of a recordset. For example, you want to post data to BC that requires a lot of processing. When you call it directly from within the API or bij calling other functions in codeunits or whatsoever, the API will keep waiting for the processing to finish until it returns a Success Status Code like 200.
    So performance is one real goed reason. If you just save the data to BC and won’t do any processing, but instead, create a Job Queue Entry that handles that part, the API will finish immediately after the Job Queue Entry is created. This can save a lot of time on the API if the API has a lot of processing to do.

    Like

Leave a Reply to Renco Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.