Scope on Triggers

When using the Common Data Service (CDS) triggers it’s important to properly set the options on the trigger to ensure it only fires only when the desired modifications occur.

The Create, Update and Delete triggers all support the Scope setting to help minimise triggering. The Update trigger also has an attribute filter setting allowing you additional control on which records qualify based on field level detection. In this topic, we look at how both can be applied to reduce the triggering of your flows.

Setting Scope

The scope configured on the Create, Update and Delete triggers filter the triggering of the flow based on the connection user’s information on the trigger action and the triggering record owner’s information. The security role permissions for the trigger connection user also plays into the filtering as well. The actual owner of the Flow does not matter, it’s the user that is signed in to the CDS connector used by the trigger that matters for filtering.

The following are the valid options for the scope setting:

• Organisation – this will trigger for all records the user has read access to regardless of triggering record owner’s business unit.
• Business Unit – this will only trigger for data records the user has read access to and owned by a user in the same business unit.
• Business Unit + Child Business Unit – this will only include any of the records they have read access to in their business unit and the hierarchy of child business units.
• User – this is the most restrictive it will only fire for modifications to records they are the owner of.

In CDS, each user and team are associated with a business unit. All data records that are user and team owned and not organisation owned are associated with a business unit based on the record’s user/team ownership. That business unit can either be the root (top of the chain) or a child business unit within the overall hierarchy of business units. For our examples, let’s use the following structure:

For flows deployed with solutions that you intend to work on all records modified you would want the scope to configured to organisation and the connection’s user to have organisation level read access to work properly. For example, if the connection user was in Sales and Marketing, with the scope set to organisation and they only had business unit level read access they would only trigger the flow for records owned by Sales and Marketing.

Reducing scope to User can be helpful for users that have access to create their own flows that want to only see modifications to their own records. For these, the scope would be configured to the user, and they would see modifications done by any user to their owned records. By reducing scope, this user is not bothered by changes on other records and if they are modifying data they are only modifying their own records. This same user can attempt to overreach and ask for business unit or organisation level scope, however, the most they will get triggered on is based on their security role read access to the entity. So, if they only have business unit read access, setting an organisation scope doesn’t get them any additional triggering.

When you are testing your flows and use prior runs be aware that the filtering of scope is not performed. That is only done on the actual check, not a re-run of a prior run so you can end up testing with a record that wouldn’t otherwise qualify.

Filtering Update Attributes

Filtering on attributes is available only on the update trigger in the advanced options section.

By default, any update to the entity will trigger the flow. Attribute filters allow you to specify which attributes your flow cares about. In general, you should always set attribute filters unless you really are interested in all fields.

It’s important to know that if you list a field and your flow triggers, that doesn’t mean the value of the field has changed only that it was included in the update action that triggered execution. With model-driven apps for example, when the user clicks save, or the autosave happens only the changed fields on the record are modified. When you use CDS workflow, Microsoft Flow CDS update, or any developer API update if you specify the field in the action, CDS will treat it as a candidate for firing update triggers even though the contents of the field did not modify. The best practice when authoring any of those updates is to only pass the field when contents have changed, however in real-world applications that doesn’t always happen. When writing automations that use update triggers you should always do your own independent check if the contents changed if that matters for your scenario.