Workflow runs as MID user after executing a MID activitySummaryOnly affects Orchestration (workflow) Expected Behavior: Workflow begins executing as the MID user account when it comes back from completing a job on MID. (Powershell, REST, and other templates) This may or may not cause any issues depending on what follows after the MID activity. The MID user typically does not have wide access to the platform. If you are calling a script api, it may fail depending on if the MID user is able to execute it. Possible issues because of expected behavior: While most of the time users do not encounter issues related to this, it can be confusing when it does happen. Access denied or inability to run a script or activity that occurs after a MID activity.Unexpected results due to a different user running the workflow. Workaround: If you are running into issues with the MID user running the workflow, there are some workaround options to try. (Recommended) Add a timer activity immediately following your MID activity. This forces the system to reschedule the workflow and it will run as the system user. You may set the timer at the minimum value to reduce any possible delays from using the timer. Or (Less recommended) Make sure your MID server user has required roles to run anything it is not able to access currently. Less recommended as it exposes access to things the MID user should not generally have access to. Insecure. Why would someone encounter this now? Often Orchestration activities that use MID are the final action taken by a workflow. They may not have used anything that would fail to run under a different user. If a workflow is updated and more activities are added after the MID activity, it is possible for this issue to show up when they had not experienced it before with the same workflow.