MB-230 common mistakes
MB-230 · Understand the traps and how to avoid them.
Sets up email-to-case, sends a test message, and nothing arrives - then starts rebuilding the rule instead of checking the mailbox, the queue, and whether the record creation rule is active.
Candidates study the rule configuration screen in isolation and skip the prerequisites that actually gate delivery: the mailbox must be approved and pass Test & Enable Mailbox (server-side sync), the queue must exist and the rule must target it, and the rule must be activated after publishing. Demos fail silently when any one of these is missing.
What to do instead
Before touching the rule, confirm the mailbox is approved and tested, server-side sync is enabled, the target queue exists and the rule is active. Then trace one email end to end: mailbox → queue → record creation rule → case. Learn the order of these checks so exam scenarios about 'cases not being created' resolve to the right failing component.
Describes resolving a case as a soft status change, and assumes fields can still be edited afterwards, that child cases close automatically, or that reopening needs no special privilege.
Resolution feels like a normal status update, so candidates overlook that it writes the resolution activity, sets the case to a resolved state that renders it read-only, and that reopen requires the appropriate privilege. Parent/child cascading is a relationship behaviour that must be configured, not a default.
What to do instead
Memorize the resolution lifecycle: resolve captures resolution details and locks the record; further edits require reopen; cascade behaviour for parent/child cases comes from the relationship configuration. When a scenario asks how to 'change a field on a closed case', the answer is reopen (or a new case), never a direct edit.
Builds SLA items with KPIs and actions, activates the SLA, and then cannot explain why no case ever shows a timer or a warning/failure state.
Candidates focus on the KPI definition and neglect the three things that make an SLA actually apply: an 'Applicable From' value, the SLA being marked as default (or explicitly attached to the case), and the KPI having both warning and failure actions configured. Without these the SLA is inert.
What to do instead
Adopt a checklist: SLA activated → Applicable From set → default SLA assigned (or the SLA lookup populated on the case) → each KPI has warning and failure actions → for pause/resume, 'allow pausing and resuming' is enabled and a pause condition exists on the timer. Practise explaining each element's failure symptom, not just its purpose.
Creates an entitlement with terms and channels, tests it against a new case, and concludes entitlements are broken because the case shows no entitlement and no remaining terms.
Entitlements only apply when they are actually attached - via the customer's default entitlement, an explicit entitlement on the case, or the entitlement lookup - and only when the case's customer, product, and channel fall within the entitlement's coverage dates and terms. Candidates test with a contact that has no default entitlement.
What to do instead
Learn the three attachment paths and the matching conditions (customer, product, channel, start/end dates) as a single model. In scenarios, first ask 'how is the entitlement associated with this case?' before evaluating terms, and remember 'restrict case creation to entitled products' changes creation behaviour rather than entitlement application.
Adds a knowledge search control to the case form and expects agents to find articles, but searches return nothing, and the candidate blames search configuration.
Article lifecycle is the usual cause: the article is still a draft or minor version, its visibility does not match the audience (internal vs. external/portal), the knowledge article entity's search is not enabled in the environment, or the article is expired/reviewed out. Candidates study the control and skip versioning and visibility.
What to do instead
Study the article lifecycle as a sequence: author → major version → publish → visibility set → expiry/review dates. For any 'agent cannot find the article' scenario, check publish state, major vs. minor version, visibility, and expiry before touching the search control or relevance search settings.
Configures a resource requirement and then reports that 'find availability' returns no slots, assuming a bug in the scheduling engine.
Scheduling output is the intersection of many inputs the candidate configured piecemeal: requirement duration and from/to window, the resource's working hours calendar, matching characteristics and roles, organizational unit membership, and fulfillment preference. One missing or mismatched input yields zero results with no error message.
What to do instead
Treat scheduling as a constraint pipeline: requirement duration/window → resource working hours → characteristics/roles match → organizational unit → fulfillment preference. When a scenario has no available slots, walk that pipeline in order and identify the single disqualifying constraint rather than re-creating the requirement.
Enables multi-session in the admin settings, then marks it as done - yet agents never see sessions or tabs on a case.
The feature needs more than the toggle: the session control must be placed on the case form, a session template must be created and assigned to the app, and agents must use the supported app experience. Candidates stop at the setting because it is the most visible step.
What to do instead
Learn the three-part requirement (setting enabled + session control on the form + session template tied to the app) and verify each in order. For scenarios, identify which of the three is missing instead of reconfiguring global settings, and remember session templates define the default tabs.
Reads a reporting requirement and immediately picks the out-of-box dashboard, ignoring refresh latency and the difference between real-time and historical analytics.
Candidates treat all analytics surfaces as interchangeable. Real-time analytics serve live operational monitoring, historical analytics run on a delay and cover a bounded retention window, and Power BI-backed views require the right roles and embedding configuration. Choosing the wrong surface produces an answer that is functionally plausible but wrong.
What to do instead
Map requirement language to a surface: 'right now / queue backlog' → real-time; 'trend over months / agent performance' → historical; 'custom visuals across data sources' → Power BI. Memorize that historical dashboards are not live, and check role/dashboard access prerequisites before assuming data is missing.
Reaches for a business rule or classic workflow to call an external service, transform data across systems, or run on a schedule.
Candidates see overlapping capabilities and pick the tool they used most recently. Business rules are client-side form logic with no external calls; classic workflows are deprecated for new automation and lack modern connectors; neither is the right answer for integration or scheduled orchestration. This overlap is exactly what the exam probes.
What to do instead
Build a decision table and memorize it: form behaviour and field validation without code → business rule; cross-system integration, approvals, or scheduling → Power Automate cloud flow; synchronous high-volume logic → plug-in. Practise justifying why the alternatives fail, since the exam often asks for the best tool given a constraint.
Sets up queues and routing rules, then describes unified routing as if those same rules will route work - or forgets capacity profiles entirely and cannot explain why nothing gets assigned.
'Routing' spans two models. Queues and routing rules belong to the older queue-based model, while unified routing requires workstreams with classification rules, assignment rules, and capacity profiles. Candidates mix terminology because both live under service administration and both involve queues.
What to do instead
Separate the two models explicitly in your notes: workstream → classification rule → assignment rule → capacity profile for unified routing, versus queue → routing rule for classic. In every routing scenario, first determine which model the environment uses (unified routing enabled, supported app, agent capacity configured) before choosing a component.