Workflow activity after the timer activity shows created by user, instead of systemDescriptionWorkflow activity after the timer activity shows created by user, instead of systemafter timer activity, I expect task record to be created by systemafter timer activity, I expect run script to executed as system Unexpected Behavior:After timer activity, we see that the created by and updated by are from a user, and not system Expected behavior:After the timer activity, created by and updated by are from system STEPS TO REPRODUCE:create workflow similar to thiswhere run script contains script:gs.sleep(9999);and timer activity is just for 1 second In the scenario above it's expected that the catalog task is created by system, since it's after the timer activity. However in the screenshot below we can see that it's not: CauseAfter the scheduler picks up the timer job, it fails to retrieve workflow context due to it being used in another thread, in this case, the user that shows created by/updated by. In the node logs when the worker tries to obtain the workflow context we see the following: 09:31:29.142Infoworker.0worker.0 txid=38c58aef1b7d Spin waiting for mutex wf_context_f3b54eef1b7d00108dd90d81ec4bcb69 to be freed09:31:29.143Infoworker.0worker.0 txid=38c58aef1b7d Attempt to get mutex wf_context_f3b54eef1b7d00108dd90d81ec4bcb69 with spin failed because max spins was hit09:31:29.143Debugworker.0worker.0 txid=38c58aef1b7d DEBUG: Unable to get mutex '{0}' retying {1} more time(s).09:31:29.173Infoworker.0worker.0 txid=38c58aef1b7d Completed: Workflowf3b54eef1b7d00108dd90d81ec4bcb69 in 0:00:00.023, next occurrence is null What happens is that the timer complete message should go into the [wf_command] and be processed by the thread that has the mutex, or by the nudger if that misses it. However, if it's processed by the nudger it would have a created by / update by system. "Workflow Nudger" is a scheduled job, that runs every 5 minutes.ResolutionThis is the expected behavior. We see this behavior where the record is being updated multiple times by business rules and running subflows with timers causing multiple updates. To reduce the likeliness of seeing this, you would have to consolidate the updates being done.