MB-230 Manage Cases in Customer Service Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create an automatic record creation and update rule that modifies the SLA KPI definition when status changes.

  Why it's wrong here

  Record creation and update rules govern case creation from activities such as emails; they cannot modify SLA KPI definitions, which are configured on the SLA itself. It is tempting because these rules legitimately automate case creation and field updates in scenarios involving email or social channel intake.

• ✗

  Define a custom Power Automate cloud flow that recalculates the warning and failure times whenever the case status changes.

  Why it's wrong here

  SLA pause conditions are configured natively on the SLA KPI with an applicable-when rule; a cloud flow recalculating warning and failure times cannot suspend the KPI instance. It is tempting because Power Automate is the correct tool for custom notifications or actions that native SLA configuration cannot express.

• ✓

  Configure an SLA configuration record with a pause condition where Case Status equals Waiting on Details.

  Why this is correct

  SLA pause conditions allow administrators to specify exact criteria, such as specific case statuses, that trigger a temporary stop in SLA time tracking. When the status changes away from the specified value, the SLA timer automatically resumes.

• ✗

  Implement an escalation path in the entitlement setup to suspend the SLA KPI instance.

  Why it's wrong here

  Escalation paths trigger actions when SLA KPIs near failure; they cannot suspend a KPI instance, which requires an applicable-when pause condition on the SLA item. It is tempting because escalation paths genuinely handle SLA breach behaviour, such as reassigning or notifying, in other scenarios.