201
If a user creates or restarts a job queue entry, the User ID is set to this user. And if this job queue entry makes any changes, the name of this user ends up in the change log. This creates the suggestion that the changes are made by a real user instead of a service account. And this leads to problems, it is a returning topic in audits but also leads to confusion and questions for other users (why has this person changed this record?).
The alternative is to only create / edit job queues when logged in as a system user, but that's easy to forget.
And within larger organizations there are more users with access to the job queue, but you cannot give all these users access to one service account because it can make their other changes untraceable to the real user.
Therefore, the idea is to set-up a service account for the job queue, and all changes made by the job queue will be logged with this user. So that it will be clear that these changes are made by the job queue.
To be short, go back to the situation before NAV 11 when this was introduced :).
Category: General
STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team

Comments

H

Almost 200 votes! How many more votes are needed before you will reconsider again? :)

Category: General

H

I think, security concerns could be addressed in BC by implementing a check when adding a "Run As"-User ID into a job queue entry which ensures that the current user account has at least the permission scope that the "Run As"-User ID has. Such check already exists in the user account management area of BC e.g. whenever you add permission sets to a user account. You cannot give more permissions than you have with the current account/User ID.BTW: Seems that Dynamics Finance and Operations already has the possibility to define a "Run-As User ID" in the batch job management. Not sure how they handle the security topic, but you could surely find this out within Microsoft.

Category: General

H

About half of my customers have requested this, so yeah this needs to be done Microsoft!

Category: General

H

It sure needed, even more since this event has been obsoleted : OnScheduleTaskOnAfterCalcShouldChangeUserID() with reason "Function ScheduleTask no longer changes user ID."(it's breaking a feature we did to reassign a "user/service account" on the Job Queue when task is scheduled after a restart done by a "user" on the web interface)References : https://learn.microsoft.com/en-us/dynamics365/business-central/application/base-application/obsoletion/obsolete_by_25.0https://www.yammer.com/dynamicsnavdev/threads/3082788667244544

Category: General

H

153 votes. How many more are needed to get this functionality?

Category: General

H

137 Votes and still no reaction.How many votes will this idea need to get picked up?

Category: General

H

This would be great to get sorted out. Today we have to deal with this with a subscription on "Job Queue Entry".OnBeforeModifyEvent and set a fixed user ID.

Category: General

H

116 Votes and still no reaction.There is also a post on Viva Engage discussing this requirement but no one from Microsoft, how would give any comment on it.https://www.yammer.com/dynamicsnavdev/threads/40371221602304

Category: General

H

Unintentional User ID changes can cause user confusion.Please consider this.

Category: General

H

This really is needed, as well as saving a lot of confusion over who made changes, this may also finally allow users with a partner login to start job queues to that we can deliver a more complete service to clients when building and testing their systems.

Category: General

  • 1
  • 2