I am currently a moderator for the CRMUG/D365UG MB200 Certification Study Group (links to future and recorded webinars on my events page). Last week our topics included Workflows!
One topic that can be confusing about Workflows is knowing which user the workflow will run as. This user’s name will show up as the Modified By and/or Created By for records dealt with in the process. This user is different depending on the type of workflow being used.
Asynchronous or background workflows will run as the workflow owner when triggered automatically. This user will need access to do whatever actions the workflow is taking.
When a Workflow is triggered on-demand from the Run Workflow button on a record it will run as the user who clicks the button. This ensures that a user cannot use a Workflow to get around their own security rights.
With Real-Time workflows can be run as either the owner of a workflow or the use who made changes to the record. This allows you to do things like have a workflow running after create that fills in additional details but still shows the Modified On of the user who originally made the change.
So how does this change with Child Workflows? There are a few different situations to consider:
- Background workflow with background child: This will run as the parent workflow owner
- Background workflow with real-time child: Trick question! You can’t do this.
- Real-time workflow running as owner with background child: Runs as the owner of the Real-Time (parent) workflow
- Real-time workflow running as user with background child: Runs as the user who made the change
- Real-time workflow running as owner with real-time child set to run as workflow owner: Runs as the Owner of the Parent Real-Time Workflow
- Real-time workflow running as owner with real-time child set to run as user who made the change: Runs as the Owner of the Parent Real-Time Workflow
- Real-time workflow running as User with real-time child set to run as owner: Runs as user who made the change
- Real-time workflow running as User with real-time child set to run as user who made the change: Runs as user who made the change
So in summary – anytime child workflows are involved, the children will run as the same user as the parent workflow.