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.
I hope this brings some clarity as you study for the MB200. Join us on the next study group and ask your questions!
3 thoughts on “Who Modified This?”
Hi Kylie, I had the same idea of workflow credentials as you had. That is until I noticed a permissions error when my background workflow was trying to read some data. The permission error was referring to the user who triggered the (async) workflow and not the owner of the workflow. I then discovered that even though the user interface for background workflows does not allow you to select “The user who made changes to the record” – if you convert a real-time workflow where this has been selected, into a background workflow, it will respect that setting. So in short, background workflows can run as the user who updated the record – you can do an advanced find, showing the mode (async) and run as to reveal the user context each workflow will run under.
How very interesting! I have not tried this but will have to test it out. Thanks for the tip!