Microsoft Dynamics CRM 2013 – Automatically Triggered Background Workflow Processes Scope

Colin Maitland, 22 June 2014

In this blog I will describe how the Scope option for automatically triggered background Workflow Processes is applied using the example of four Workflow Processes designed to be automatically triggered to execute in the background when the Description field on an Opportunity is updated by a User.

The four Workflow Processes have the following properties:

The only difference between these four Workflow Processes is the configuration of the Scope option. The Scope option is set to either Organisation, Parent:Child Business Unit, Business Unit or User. The following image shows the configuration of one of the Workflow Processes with the Scope option set to Organisation.

Each of the four Workflow Processes is configured to run in ‘the background’ and is also configured to be able to be run ‘As an on-demand process’ in addition to being triggered when the Description field on an Opportunity changes.

Each of the four Workflow Processes is owned by James. The following diagram shows a sample Business Unit structure and with a User assigned to each Business Unit. James is assigned to the New Zealand Business Unit. There is also a fifth User, named Wilson, who is not shown in this diagram. Wilson could be assigned to any of the Business Units.

The Security Roles assigned each User provide the following common privileges:

  •  Organisation access level Read and Write privileges for Opportunities; i.e. each User may view and update any Opportunity within the Organisation.



  •  User access level Read privilege for Processes; i.e. each User may only view the Workflow Processes that they own. In this example, only James can view and manually execute any of the four Workflow Processes because he is the User that owns them.



  •  Execute Workflow Job = Enabled.



The following table summarises which of the four background Workflow Processes are automatically triggered when Wilson updates the Description field on any Opportunity owned by each of the following Users, including himself.



The following table summarises which of the four background Workflow Processes are automatically triggered when Wilson updates the Description field on any Opportunity owned by him.



The background Workflow Processes that are automatically triggered are dependent on:

  •  The Business Unit of the Opportunity’s Owner.
  •  The Business Unit of the Workflow Process’s Owner.
  •  The Scope of the Workflow Process.

There is no dependency between the Business Units of the Workflow Process’s Owner and the User who updated the Description field on the Opportunity. 

Some final points to be aware of are:

When the background Workflow Processes are automatically triggered they are executed in the security context of the Workflow Process’s Owner, i.e. James, rather than in the security context of the User who updated the Opportunity. This means that:

  •  Any actions, such as the creation or update of records etc., performed by the background Workflow Process as if James where performing them rather than as if Wilson were performing them.

  •  If the Execute Workflow Job privilege on Wilson’s Security Role was not enabled, the background Workflow Processes owned by James would still be triggered.

  •  If the Execute Workflow Job privilege on James’s Security Role was not enabled, the background Workflow Processes owned by James would not be triggered.

  •  Even though Wilson only has User access level to Read Processes; i.e. he is not able to view the Workflow Processes owned by James, and is therefore not able to manually invoke those Workflow Processes; these Workflow Processes are still automatically triggered when Wilson updates the Description field on an Opportunity.