You are testing security in a model-driven app. The business unit structure in the environment consists of a top-level business unit with three business units, named BusA, BusB, and BusC, directly…

There isn't a single 'feature' to turn off that granularly controls record ownership across business units; record ownership and security are fundamental and managed through security roles and business unit hierarchy.

Creating a new security role in the parent business unit with Business Unit level privileges, and then assigning it to BusA users, allows them to view records within their specific business unit (BusA) as intended. This action sets up the correct access.

Moving BusA users to the parent business unit would change their organizational context and assigning Parent:Child Business Unit roles would likely grant more access (to BusA, BusB, BusC) from the parent level, contradicting the requirement to view records only in their business unit.

If BusA users have roles from BusB and BusC with Business Unit level privileges, those roles grant access to all records in BusB and BusC. Changing the privilege levels on these problematic roles (or any roles assigned to BusA users that grant excessive access) to User level ensures that BusA users can only view records they own, thus restricting their unwanted broad access to BusB and BusC records.