Thank you Scott for clearly explaining a complex topic. Even out of the box business unit security is frequently mis-understood or overlooked, but the modern business units really open this up to be far more friendly for designers with less gotchas.
Thank you Scott! That’s really kind of you to say 😍 model driven security is definitely one of the most complex aspects to get your head around! Very flexible, but difficult to wrangle!
Great episode on these new changes! It's been so long since any changes came to security. Nice presentation and background. Context is super important to master your learning.
Thanks Scott, for this great content, particularly the app settings. I completely missed the preview announcement and have definitely experienced the pain of users working / moving between BUs, so this is a welcome feature enhancement. Glad I know about it now!
Awesome Scott, thanks for explaining in detail and different scenarios which are very tricky in nature and till date if any user moves from one BU to another BU at times we encountered access issue. Modernized Business Units will be a breather .
Well, that is interesting. Really well explained Scott - thank you. It reminds me of working in v3 when I accidentally moved the only System Admin to another BU and lost all Admin access! Thankfully, we can't do that anymore! Sounds like a reasonable step forward and I can see use cases where this will be helpful.
Hi Scott - the bit I've not seen called out yet is the method we're now supposed to be using to confer roles on users. The direction of travel here for the last couple of years appeared to be the adoption of AAD group-teams (rather than owner-teams) with all roles applied to these teams rather than individual users (along with the use of team-members privilege inheritance to make this work for privileges of basic scope). It makes lots of sense - especially for multiple instances - and the established "teams with members from other BUs" pattern fits this approach well". Now I'm left wondering which BU to create the Team in. I assume we can also apply roles from any BU to a Team not just a User... (hmmm maybe that's a dangerous assumption just now...) Finally the bit that (I think?) is still missing is to be able to set the user's BU using AAD (instead of having to set this individually in every Dataverse instance)... Any thoughts?
This was very helpful. I changed a user to a different business unit and updated her security role to Parent Child Business Units level on all my custom tables (Read, Append, and Append To). She can no longer see the records on the Lookup tables that someone else entered in the Original Business Unit. Therefore she can't enter any records that require a choice from a Lookup table. Can you tell me what I might have done wrong?
I have a question regarding applying security roles to Business Units. When you create or copy a new security role on a business unit, does that mean that the role is available to the business unit, but the role still needs to be applied to a user or team under the business unit to become active/effective ?
Thanks for this video Scott, a complex topic very well explained. This looks like it will actually resolve some challenges I’ve been trying to overcome recently with the standard BU functionality 😀.
I think compared to other approaches such as team membership and sharing, this will simplify things - however when combined together obviously it's another thing on the already long list!
I hope this means Owning Business Unit will become allowed for create and thus be eligible as alternate key column (so my index don't break cross-unit confidentiality).
Really interesting topic and your explanation to this tricky topic is bang on. Thank you 😊
Thank you Scott for clearly explaining a complex topic. Even out of the box business unit security is frequently mis-understood or overlooked, but the modern business units really open this up to be far more friendly for designers with less gotchas.
Thank you Scott! That’s really kind of you to say 😍 model driven security is definitely one of the most complex aspects to get your head around! Very flexible, but difficult to wrangle!
Great episode on these new changes! It's been so long since any changes came to security. Nice presentation and background. Context is super important to master your learning.
Wow, this is a shift change on security. Thanks Scott for making this video.
It's definitely a game changer imho. Thank you for such a clarifying explanation, keep the good work!
Thanks for making it simple to follow and understand. This is a fantastic new feature!
Thanks Megan!
Thanks Scott. Great video to break it down for easy digestion!
Thanks Scott, for this great content, particularly the app settings. I completely missed the preview announcement and have definitely experienced the pain of users working / moving between BUs, so this is a welcome feature enhancement. Glad I know about it now!
Thank you and thanks for watching! 😊I do love this feature!
Awesome Scott, thanks for explaining in detail and different scenarios which are very tricky in nature and till date if any user moves from one BU to another BU at times we encountered access issue. Modernized Business Units will be a breather .
Thank you - it's great to hear that this will help!
Awesome video, thanks for sharing.
Is it supported in dynamics 365 - 9.1 on premise?
Thanks for making this really useful video. I was watching the official MS one and feel asleep half way through. ;)
Thanks Scott for amazing explanation
Well, that is interesting. Really well explained Scott - thank you. It reminds me of working in v3 when I accidentally moved the only System Admin to another BU and lost all Admin access! Thankfully, we can't do that anymore! Sounds like a reasonable step forward and I can see use cases where this will be helpful.
Thank you!
Well explained, Thank you Scott🙌
Hi Scott - the bit I've not seen called out yet is the method we're now supposed to be using to confer roles on users. The direction of travel here for the last couple of years appeared to be the adoption of AAD group-teams (rather than owner-teams) with all roles applied to these teams rather than individual users (along with the use of team-members privilege inheritance to make this work for privileges of basic scope). It makes lots of sense - especially for multiple instances - and the established "teams with members from other BUs" pattern fits this approach well".
Now I'm left wondering which BU to create the Team in. I assume we can also apply roles from any BU to a Team not just a User... (hmmm maybe that's a dangerous assumption just now...)
Finally the bit that (I think?) is still missing is to be able to set the user's BU using AAD (instead of having to set this individually in every Dataverse instance)...
Any thoughts?
This was very helpful. I changed a user to a different business unit and updated her security role to Parent Child Business Units level on all my custom tables (Read, Append, and Append To). She can no longer see the records on the Lookup tables that someone else entered in the Original Business Unit. Therefore she can't enter any records that require a choice from a Lookup table. Can you tell me what I might have done wrong?
Scott..Very well explained and learned new concept. Thank you.
Do we use only powerapps UI going forward not D365 UI??
Amazing stuff, Thank you Scott 🙏
I have a question regarding applying security roles to Business Units. When you create or copy a new security role on a business unit, does that mean that the role is available to the business unit, but the role still needs to be applied to a user or team under the business unit to become active/effective ?
Thanks for this video Scott, a complex topic very well explained. This looks like it will actually resolve some challenges I’ve been trying to overcome recently with the standard BU functionality 😀.
Thank you for watching and those nice words - hope it makes your life easier!
Thanks for the video the functionality really looks great
Great explanation by a genius....
Thank you 😂
What about Test user 2, can it see the record "Created by User 1 in Dept A" because it is owned by a user which is in the same Business unit now ?
Good video in understanding 👍
Great video, thanks !
Thanks Julien!
Awesome info....awesome you
Scott, how is this going to effect internal control mgt? Is this going to complicate audits?
I think compared to other approaches such as team membership and sharing, this will simplify things - however when combined together obviously it's another thing on the already long list!
I hope this means Owning Business Unit will become allowed for create and thus be eligible as alternate key column (so my index don't break cross-unit confidentiality).
Awesome brother
Interesting stuff :)