A consultant configuring Dynamics 365 Sales for a holding company with multiple business units needs predictive opportunity scores visible to sellers within each business unit, but leadership wants scores for one sensitive business unit hidden from sellers in other business units who share the same environment. How should the consultant achieve this?
Select an answer to reveal the explanation.
Short Explanation
A predictive score rides on the opportunity record, so you protect it by protecting the record. Use security roles and business unit access to keep the sensitive unit's opportunities visible only to its sellers. The score visibility follows record visibility.
Full Explanation
The correct approach is the one that uses Dynamics 365 security roles combined with business unit-based record access to restrict visibility of the sensitive business unit's opportunity records, and therefore their scores, to its own users. Predictive opportunity scores live on the opportunity record itself, so controlling who can see them is a matter of controlling who can see the underlying opportunity records, which is exactly what Dynamics 365 security roles and business unit-based record access are designed to do. Scoping access so that sellers outside the sensitive business unit cannot open or query those opportunity records keeps the associated scores hidden from them while leaving scoring active and visible for sellers who are authorized. The approach that disables predictive opportunity scoring for the entire organization, since the feature cannot be scoped below the whole environment, is incorrect because disabling scoring for the whole organization would remove a useful capability from every other business unit just to protect one, when access control can isolate visibility without sacrificing the feature elsewhere. The approach that renames the predictive score field on the sensitive business unit's forms, since renaming a field removes it from other business units' security role queries, is incorrect because renaming a field has no effect on security role-based query access; visibility is governed by record and field-level security configuration, not by what a field is labeled, so this would not achieve the intended restriction. The approach that moves the sensitive business unit's opportunities into a separate Dataverse table so predictive scoring can be turned off for just that table is incorrect because moving records into a separate table is not how predictive scoring visibility is scoped, and Dataverse table-level toggles are not the mechanism for restricting which business unit's users can see an existing feature's output. Business unit hierarchies paired with security roles are the standard mechanism for this kind of segmented visibility across a shared environment.