Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Since a production release earlier this week I've noticed workflows are creating system jobs with myself as the job owner (rather than the standard service account we use). The workflows that also send emails are setting the email From field to my user id too.
I've gone into customisations and listed all the processes and it shows the workflow owner is still set to the service account.
Can anyone give me any pointers as to why the system jobs are not also owned by the service account?
This is causing a real headache and I had to hastily enable my mailbox to allow outgoing emails!
Thanks in advance.
Are you changing any data that would be starting or restarting the work flow?
Are those real-time or background workflow? Maybe they used to be background but were converted to real-time as part of the release?
The workflows are triggered by users setting certain data fields, but I haven't done any data changes myself. The only change in the release affecting this particular entity was to hardcode an email recipient in another workflow (not the ones that have gone wrong). This was done in the dev area and the solution exported as part of the release.
These are all background workflows and are still showing as background.
I've just been trawling through some other workflow system jobs and one of them is spawning jobs in some cases with my account and other cases with the service account. How is this possible as I would expect it to be one or the other?
As an experiment I performed the same release in a test system but this time I logged in as the service account when importing the solution. There's no difference in terms of workflow ownership doing the import this way but the spawned system jobs do show the service account as the owner this time. I've reached out to Microsoft for an explanation and will update this thread if I make any progress. Previous releases I have always imported the solution logged in as myself, so not sure why that should suddenly cause an ownership issue.
MS have a support instance on one of our production systems testing this at the moment. We have background workflows from a MS solution set to organization failing due to no delete privilege of a user that has changed data and become the workflow owner. My understanding is the workflow owner should not change to a user with minimal permissions but I could be wrong.
Just to update anyone reading this thread, I spent some time with Microsoft Support and it appears that a recent hotfix update may have changed the behaviour of system job ownership.
An advanced find was performed on processes to show the 'mode' and 'run as user' columns for all our workflows. The vast majority of our workflows are background mode but with a 'run as user' setting of 'Calling User'. According to the support engineer the new behaviour is that when importing a solution this sets the workflow calling user to the user id that performs the solution import. This would explain why my user id suddenly owned all the spawned system jobs. It therefore seems that the safest way of performing releases is to log in as the user id that you want system jobs to be owned by.
They did suggest though that it is better to specifically set each workflow to the appropriate user, rather than relying on using the correct login at time of import. There does seem to be a bit of a flaw here though in that background workflows don't actually have an option to set the 'run as user' setting! The way the engineer achieved this in my test area was to initially convert the background workflow to a real-time one (there's an option at the top to do this), change the 'execute as' to owner (rather than 'the user who made changes to the record'), then convert the workflow back to background mode. It will then show up with a 'run as user' setting of 'Owner' rather than 'Calling user'.
I'm going to perform plenty of testing on this and will update if I encounter anything that deviates from the above advice.
Once the change was made, but then you re-imported the solution, would any workflows in the solution ownership go back to you when the process runs? I wonder if I could use XRMtoolbox to mass change the "execute as" user.
I've performed all our subsequent releases logged in with the appropriate service account rather than my own login. Haven't had any problems since. I'm pretty sure if I imported with my own login then the problem would occur again. I can replicate the issue if I import as myself into a test area. For production I make sure I remember to use the correct login whenever I import anything! I've not checked whether XRMToolBox has an app for doing that. It's an invaluable tool that's for sure.
If you can scarify some performance, then changing the workflow to a real time workflow will let you choose the "Execute as" option. You can select the owner of the workflow or the user who caused the changes to the record.
Did you ever get a solution to this? Meaning you can import solutions as an Admin NOT being the owner of the background workflows?
I'm having the same issue now (introduced recently) and as we have quite a number of different workflow owners, importing by all of these individually (separate solutions) is not efficient.
I have filed a support ticket and hoping for help by MS.
UPDATE for others with same issue:
I filed a support ticket and Microsoft were able to fix the problem. Required deactivation and reactivation of workflows though. We did a solution import to fix all in one go (does the deactivation and reactivation as part of the process).
Business Applications communities