web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / System job owner diffe...
Microsoft Dynamics CRM (Archived)

System job owner differs from Workflow owner

(0) ShareShare
ReportReport
Posted on by Matt07

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.

*This post is locked for comments

I have the same question (0)
  • antc Profile Picture
    antc 2,909 on at

    Are you changing any data that would be starting or restarting the work flow?

  • ashlega Profile Picture
    ashlega 34,477 on at

    Are those real-time or background workflow? Maybe they used to be background but were converted to real-time as part of the release?

  • Matt07 Profile Picture
    Matt07 on at

    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.

  • Matt07 Profile Picture
    Matt07 on at

    These are all background workflows and are still showing as background.

  • Matt07 Profile Picture
    Matt07 on at

    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?

  • Matt07 Profile Picture
    Matt07 on at

    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.

  • antc Profile Picture
    antc 2,909 on at

    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.

  • Verified answer
    Matt07 Profile Picture
    Matt07 on at

    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.

  • bpr_admin Profile Picture
    bpr_admin on at

    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.

  • Matt07 Profile Picture
    Matt07 on at

    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.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans