web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / New Dynamic, LLC / Utilizing Business Units in...

Utilizing Business Units in Configuration Logic Between Microsoft Dynamics 365

Travis South Profile Picture Travis South


Business Units (“BU’s”) are a great way to structure data security and configurations between User Groups that do not share common processes and/or data in Microsoft Power Platform. One of the downsides to BU’s though, is that using them in configuration definitions for items like views and processes means the objects are unique between environments. When moving solutions between environments, if you do not manually update the BU value in your definitions—due to the unique GUID—the configurations break.

The cumbersome and low-tech way of handling this is to organize an unmanaged layer of customization in each environment. After moving a solution to a new environment, you must then go and update all the objects that contain the BU reference and republish the changes, which can be time consuming and introduce extra complexity. The unmanaged layer is undesirable as well as risking that the process is not followed correctly and therefore the desired effect is not achieved.

There are ways to use advanced find logic for view definitions using default team patterns when attempting to define certain types of views, but I was looking for an even simple approach that could work in all use cases.

My original logic for views looked generally like this:

Edit Filters View Logic

For classic workflows it also specified the unique business unit identifier:

Classic Workflow Unique Business Unit Identifier

The solution was right in front of my face when a colleague suggested looking into using native column values to the BU table which I could control. The BU record has many out-of-box attributes that can be populated with data and used to query from, or you can create a custom attribute if you wish. My example approach uses the Division Column on the BU table.

If you are not using this field for another business purpose already, populate the Division Field with the name of your BU. You can then instead query the related BU record like this:

Related Business Unit Record

In a classic workflow, you do essentially the same thing:

Classic Workflow Business Unit Division Equals Custom Value

The only configuration required between environments is to set the Division Value (or whatever column you elect to incorporate - OOB or custom) on the BU records, and the customized objects in your solutions will travel intact - whether using the traditional export/import process or the modern pipeline experience.

Mike Springer – Senior Consultant

Working with New Dynamic

New Dynamic is a Microsoft Solutions Partner focused on the Dynamics 365 Customer Engagement and Power Platforms. Our team of dedicated professionals strives to provide first-class experiences incorporating integrity, teamwork, and a relentless commitment to our client’s success.

Contact Us today to transform your sales productivity and customer buying experiences.

Comments