Applications based on Microsoft Dataverse, such as Dynamics 365 and Power Apps, are packed with powerful features. You can address many business scenarios with built-in functionalities or with minimal customization. However, on occasion, client requirements may go beyond what’s available out-of-the-box. What happens then?
We recently faced just such a puzzle. A client presented us with an unusual requirement that demanded a creative solution. It forced us to think outside the box and proved that sometimes, in the world of Dynamics 365, less really can be more!
Entity relationship behaviors in Dynamics 365
To understand our challenge, first we need to discuss the Entity (Table) Relationship Behavior feature. This functionality is incredibly useful, allowing you to define how the system should act on related records when a specific action occurs on the parent record.
The triggering actions include common operations like Assign, Share, Unshare, Reparent, Delete, and Merge.
Relationship behaviors in Dynamics 365 are a powerful tool. How do they translate to real-world use?
Imagine you need to share an Opportunity record with a colleague. Beyond just the Opportunity itself, you want them to have access to all the associated activities, ensuring they have the complete history.
Using Relationship Behavior, you can achieve this with just a few clicks in system customization settings. Simply change the behavior for the Share/Unshare operation from None to, for example, Cascade All. Instantly, all related activities are automatically shared along with the Opportunity.
A business case that challenged the norm
“When the owner of an Account record is changed, we need the owner to also update on related records from other tables. However, this should only happen for related records that are currently active and whose owner is the same as the original owner of the Account before the change.”
Our initial thought was, naturally, to use Relationship Behavior for the Assign action. We reviewed the available cascading options:
- Cascade All – the change applies to all related records,
- Cascade Active – the change applies only to related active records,
- Cascade User Owned – the change applies only to related records owned by the original record’s owner,
- Cascade None - the change does not apply to any related records
The problem is that none of those options, individually, could meet the client’s criteria of the records being both active and owned by the original owner. We needed a solution that combined the logic of Cascade Active and Cascade User Owned. Since by default we could only select one behavior, we had to find an alternative approach.
Expanding the possibilities of cascading
For a Dynamics developer who isn’t afraid to code, a common first inclination might be to:
- Set the relationship behavior to Cascade None,
- Create a plugin triggered upon the owner change on the Account table record. The plugin would then:
- retrieve related, active records owned by the same user as the previous Account owner,
- update the owner field on the retrieved records.
This seems like a viable solution, until you remember the plugin execution time limit (2 minutes). For Accounts with a large number of related records meeting the criteria, this approach could easily time out. The action would result in an error, reverting all changes and blocking further process execution. For a majority of scenarios, this would essentially make record updates with such plugin impossible.
Overcoming the time barrier
We needed a way to overcome the execution time limit of our plugin. Our next thought was to move the logic outside the plugin, for example, to a Power Automate Flow. The trigger and core logic would remain similar: initiate the flow when the Account owner field is updated.
However, though this solution addresses our challenge, it introduces a significant vulnerability that’s easy to overlook – a risk of data conflicts in an edge case when the record owner changes more than once in a short timeframe.
If a new flow instance is triggered for the same Account while a previous instance is still running and updating related records, both instances could attempt to modify the same data simultaneously, leading to overwrites, errors, and inconsistencies.
Solving the riddle: Manipulating the Target
The answer to our challenge lay in a deeper understanding and creative application of the mechanisms available within custom plugin development.
For this specific case, it is essential to understand the Event Execution Pipeline combined with Execution Context.
A standard practice when creating or updating records is to add or map extra information to the Target input parameter.
When these modifications occur during the PreOperation or PreValidation stages, the changes are automatically saved to the database as part of the main process, eliminating the need for an additional update operation later.
In the vast majority of cases, there’s no need to remove information from the Target parameter during these early stages – but it is possible, though often forgotten.
Information removed from the Target during PreOperation or PreValidation will simply not be included in the data saved to the database for that specific record in that process.
Our solution, step-by-step
- Set the Relationship Behavior for the Assign action to Cascade User Owned,
- Create a plugin for the owner change (Assign) set at the PreOperation stage.
- The plugin should, for any related inactive record, remove the ownerid and owningbusinessunit attributes from the Target.
- A crucial condition within the plugin logic is to verify that the owner change was initiated by the Account owner change. This can be verified by examining the ParentContext of the ExecutionContext property
By removing the ownerid from the Target for inactive related records, we effectively prevented the Cascade User Owned behavior from applying the owner change to them, precisely meeting the client’s requirement.
When less data is better than more
This example perfectly illustrates how you can practically combine Dataverse’s built-in functionalities with custom development approaches to effectively meet client’s unique and complex business requirements.
The core of our solution wasn’t adding complex logic or triggering asynchronous processes that could lead to conflicts. Instead, it was understanding and leveraging the capabilities of the Event Execution Pipeline, particularly the ability to manipulate the Target parameter during the PreOperation and PreValidation stages.
In this scenario, removing the ownerid and owningbusinessunit attributes from the Target for inactive records made it possible to meet the client’s specific conditions (active record + specific owner), while maintaining optimal performance and eliminating the risk of data conflicts in asynchronous data updates.
Usually, when working with entities, we tend to focus on adding or modifying data within the Target. Here, I wanted to highlight the power and utility of the often-neglected option to remove it. It’s easy to forget about this possibility, as it’s so rarely used – but when the right scenario arises, it can be the efficient solution that saves significant development time and prevents potential headaches.
Struggling with edge cases or atypical scenarios in your Dynamics 365 implementation? Don’t hesitate to reach out to us. Just like in the above example, we can help you develop creative, robust solutions to customize your Dynamics 365 environment so that it perfectly supports your business needs.
See the latest insights from Netwise
Creative use of relationship behaviors in Dynamics 365: How removing data from the Target field saved our project
In this article, we show how a unique client need led to a simple, creative solution beyond standard Dataverse features.
Read more
What’s new in Microsoft Dynamics 365 Field Service Mobile? (2025 Guide)
Discover new D365 Field Service Mobile updates enhancing performance and offline reliability for field teams.
Read more
Improving agent efficiency: A guide to Unified Routing in Dynamics 365 Customer Service
Dive into Unified Routing, the automated solution revolutionizing customer inquiry distribution in Dynamics 365.
Read more