Question
You need to resolve the issue reported by substitute employees after they are assigned service requests.
How should you configure the system? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Hot Area:
Explanation
Relationship: Service Request 1:N Qualification — Cascading behaviors (Assign, Share, Reparent, Delete, Merge) are defined only on the parent side of a one-to-many relationship, so the Service Request table must be the "1" side with Qualification rows as the related children in order to expose the cascading rules that push access down when a request is reassigned. Service Request N:1 Qualification points the wrong way (it would make Service Request the child, so cascading would be configured on Qualification instead), and Service Request N:N Qualification is a many-to-many relationship, which has no cascading behavior settings at all.
Cascading rule: Cascade All — With Cascade All, the Assign and Share actions performed on the parent Service Request are applied to every related Qualification row regardless of who owns them, so when a service request is reassigned to a substitute employee that person also receives ownership/access to the related qualification records and no longer hits the missing-record or permission error. Cascade None would leave the child rows untouched and reproduce the reported problem, and Restrict is only a delete-side rule that blocks removing a parent that still has children — it does nothing to grant the substitute access.
