A manufacturer opens a field case in Customer Service, then orders the part through a Supply Chain copilot that cannot see that case. What should the architect design?
Select an answer to reveal the explanation.
Short Explanation
The broken unit and the part that fixes it are one repair, even when they live in two apps. You design a single resolution path that carries the field case and the parts order together. Asking the technician to retype the case number leaves the apps disconnected.
Full Explanation
A resolution that starts as a field case and finishes as a parts order crosses Customer Service and Supply Chain, so it should be one path. Two unrelated copilots that each close their own record reproduce the split and still hide the case from the order. A knowledge article that tells the technician to retype the case number is a manual workaround, not a process that shares the case. A dashboard that counts open field cases and does not place the parts order is a report, and the part still has to be ordered somewhere else with no link back. The parts order should carry the field-case identifier, and the case should show the order status, so a dispatcher sees one resolution. A technician who copies the case number into a second app is doing the join the design failed to provide. Exam caveat: one resolution path can still show two screens. The requirement is that the case and the order travel together, not that both apps disappear. Operational check: open a test field case, place the parts order from that case, and confirm the order shows the case identifier without anyone retyping it.