Dynamics 365 workflows allow organizations to automate business processes and create custom functions for end users to trigger. Some examples include creating a follow-up task when an action is performed or performing a calculation and updating a field on a form. Running workflows is more than just setting them up and letting them run though. Just like end users, they can't execute without the right permissions.
Types of workflows and what permissions they use to execute
There are currently two types of workflows in Dynamics 365:
Asynchronous : Executes in the background based on available resources, so it is not immediate but is better for performance. These are owned by system administrators, but will run using the end users permissions that triggered it.
Real-time : Executes immediately, but can cause performance issues if too many are executing at the same time. They are owned by system administrators, but can be configured to run as the owner or the end user who triggers it:
When choosing this option, you want to first consider what actions the workflow is performing and whether or not all users have those permissions. The workflow uses the permissions of the user that it runs as. So, for example, if you have a workflow that creates a new Lead based on an action, but not all users have permissions to create a Lead, then running it as an Owner would be your best option.
Benefits of running a workflow as the owner vs the user who triggered it
Running a workflow as the owner: The main benefit with this is that it allows end users to perform actions to targeted records that can't be granted via a security role. For example, if you wanted to allow certain end users to delete specific types of records based on a status, your admin can create a workflow to allow them to do this. If you were to grant this privilege to them via a security role, you'd have to give the end users privileges to delete records regardless of status.
Running a workflow as the user who made changes to the record: The main benefit with this is that it will update the modified by field value to the user who last made the change to the record rather than the workflow owner. Additionally, if the workflow is creating a new record, you may want the created by field value to be the initiating the user rather than your admin. Both of these fields are commonly used in views and reporting, so it may make more sense when those are in play.
Changing the user with custom plugin code
Sometimes you may have custom code running within a workflow. For example, custom code can perform calculations or other actions (such as delete) that otherwise can't be performed with the workflow actions available in the interface. When executing the code, you can get context information from a workflow using the IWorkflowContext interface. Unfortunately, this does not provide us the owner of the workflow if we wanted to change the user that calls the service. To workaround this, you can add an input parameter to your class to pass the Owner of the workflow. Then, when you declare your service, you can pass the owner id to the IOrganizationServiceFactory.CreateOrganizationService method.
Does your organization need help running workflows with the correct permissions in Dynamics 365? can help!
We’ve been working with Microsoft Dynamics since its inception. As a result, we’re always finding innovative ways to implement the latest tools and automate business processes. Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in and also provides expert , , and .
