Microsoft Dynamics 365 Workflows: Start When and Scope

Now you already know about the types of processes and the left-side of the workflow options (Run When), so now we will talk about the right-side of the workflow options. This includes Scope and Start When.

Background Workflow Scope and Start When

Scope means who should this run for. Start when is what action should trigger this.

A few things to keep in mind before we get started:

1. Scope is always relative to the Owner of the workflow. If you tested and it worked for you but not others or it worked before you reassigned to a system user - you may want to review scope.
2. By default the workflow will run as the Owner. This means that the Owner's security will determine what can and cannot be done in the workflow. For example, if the workflow owner cannot delete tasks, then this step would fail in the workflow. Exceptions:
• On Demand workflows always run as the person who triggered it
• Real-Time workflows can be configured to either run as the owner or the user who triggered it
3. Who the workflow Runs As (see #2) will determine the name that is shown on the "Modified By" of any records manipulated in the workflow
• This is a good reason to use a system user of some kind so that users do not call you (the admin, workflow owner) when their records are modified by a workflow

Scope

Here are the possible options for Workflow scope:

• User
• The workflow will only run for records owned by the owner of the workflow
• The owner must trigger the "Start When" event
• This is good to use in testing (especially if you don't have a separate test environment) to make sure the logic works for you before opening up to the rest of the organization
• Business Unit
• Fires for records owned by the workflow owner or anyone in the same business unit
• Marketing wants a specific action for only their records, assign the workflow to someone in the Marketing Business Unit and have the scope set to Business Unit
• Parent: Child Business Unit
• Fires for records owned by the workflow owner, anyone in their business unit, and anyone in child business units
• If your business units are arranged in a hierarchy based on business line, you could use this to run specific logic for one business line and different logic for another. Each workflow would be owned by someone in the top of that business line with Parent:Child Business Unit scope
• Organization
• Fires for everyone
• Workflow is triggered on all records that meet the "Start When" conditions
• This is the most common scope
• Remember to always include a check condition as the first step of your workflow to make sure it only runs when necessary

Start When

Start When is very closely related to Scope. Scope determines when we care about actions, Start When determines what actions we care about.

• Record is Created
• When a record is saved for the first time
• Record Status Changes
• When Status changes from Active to Inactive, or an Activity changes from Open/Scheduled to complete or canceled
• Remember to use a check condition to determine which statuses you want to act on
• Always test! Some entities can be edited when in an Inactive status but not all 
• Record is Assigned
• When record owner changes
• Record Fields Change
• Select specific fields to monitor for changes
• Do not select "Modified On" especially if you are also modifying the record as part of the workflow
• Record
• When record is deleted
• Consider making this a Real-Time workflow so it can fire before the delete occurs
• If this is a background workflow you cannot prevent the delete from happening and you will not have the data accessible

Now you have all the information you need to figure out your workflow settings!