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
This comes down to a basic principle that applies everywhere in Dynamics 365, not just to AI features: a score attached to a record is only as visible as the record itself. So if you want one business unit's deals, and the score sitting on them, hidden from everyone else sharing the same environment, the lever to pull is record-level access control tied to business units and security roles, not something specific to the AI feature. Turning scoring off for the whole company punishes every other team just to protect one group. Renaming a field doesn't touch who's allowed to query it, so that changes nothing about access. And shuffling records into a different table isn't how visibility gets scoped for this kind of feature. The reliable pattern is: figure out who should see the records, configure that with roles and business units, and the score visibility follows naturally from record visibility.
Full Explanation
The correct answer is C. 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. Option A 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. Option B 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. Option D 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.