Workflow Scope and Security in Dynamics 365
When creating an automatic workflow in Dynamics CRM/365, it is very important to specify the scope of the process. This is to ensure that only exact records that are affected when the workflow is triggered. The best time to define the scope of your workflow is during the design phase before moving on to creating the workflow.
People often just go ahead to create a workflow and give a scope of organization. They often defend this by saying that they are planning ahead; if anything changes or a new record is created, they can still implement the same workflow. As much as this may seem like working smart, it is very wrong and can cause issues later.
In Dynamics 365, scoping acts just like security access levels granted to users and it works by allowing constraints on the records to be affected by the process. Simply put, workflow scope defines the level of records that a workflow can have an effect on. It is therefore good to understand the various scopes available and when they are applicable.
There are four options provided to define your scope.
- Business unit
- Parent: Child business unit
Choosing this scope means the workflow will run only on the records owned by the same user as the workflow user.
2. Business Unit
This means the workflow will run on all records owned by the users of the same business unit as the workflow user.
3. Parent: Child Business Unit
With this, the workflow will run on the records owned by the users of the same business unit as the workflow user as well as any child business units.
The workflow will run on records owned by any user in CRM. Since it will trigger for all records, organization scope is the most used scope option.
Why We Scope Automatic Workflow
By default, the scope is set to User. You have to change it while creating a workflow to allow the workflow to work for someone else.
Using the scope functionality, a person with the required security privileges can create their own workflows to help them with their work without actually enabling this for everyone else. For example, a user can create a private process to help him or her to deal with the workload, such as email reminders. Also, the customer service team as a business can make use of an escalation workflow to effectively provide support to customers and ensure issues are resolved promptly.
So, by scoping users with the right security privileges, you can create as many processes as needed. This protects against a heavy load on the server while trying to check for conditions triggering the workflow on all Dynamics 365 users.
Note: Scoping behaves like a security setting and the scope setting is attached to the workflow owner.
Automatic Workflow and Security
Workflows can be triggered based on specific conditions or they can be started manually by the users. When workflow processes are triggered automatically in the background, they are executed in the security context of the workflow process’s owner and not according to the user who performed the action on the record.
You can define user scope when you want to run workflows on records owned by a user but, if an organization level is set, any record can trigger a workflow.
With automatic workflows, security is of course still important, but it plays a different role than it does for on demand. It’s the “Scope” setting that determines which user will trigger an automatic workflow; its security will restrict what an automatic workflow can do.
In other words, ensure that the published CRM workflows’ owner (Dynamics 365 users) accounts are enabled and have the proper security privileges to carry out the automatic workflow processes. If the workflow’s owner is disabled or does not have the sufficient security privileges, the workflow will encounter access error upon automatic triggering.
Most times, organizations do not have any working plan or guide that they follow regarding process flows and this is very critical. You don’t go around creating processes, especially workflows, without having a scope.
Take your time to study the scenario, understand how your organization data works, and also consider the effect a workflow can have on records depending on the user. If you are ever confused about the scope to give a workflow, you can choose organization as scope. However, ensure that there are no security implications with regard to data. Choosing organization as the scope guarantees that the workflow runs and updates properly.
A resourceful approach to setting up a Microsoft Dynamics 365 Workflow so that it is only available and/or triggered automatically for selected CRM users is to properly configure the workflow scope and security based on the above understanding.
Remember that it is not just about creating a workflow but creating a workflow that properly addressed the issue without causing another one.