MB-230 cheat sheet
MB-230 · Keep the key ideas within reach.
Manage cases in Customer Service
Lifecycle: a case is Active at creation and ends as Resolved or Cancelled; only Resolved cases can be reactivated, and the reactivation window plus the Reactivate Case privilege control whether the action appears.
Merging: up to 10 cases can be merged into one master case; the merged records become child cases and are set to Cancelled while their activities roll to the master.
Queue choice rule: public queues are visible to every user holding queue access, private queues only to assigned queue members; use private queues for sensitive or skill-segmented work.
A queue item must be worked with Work on (assigns to the current user) or assigned explicitly; the Route To action on the case form moves the case and its open activities to another queue.
Record creation and update rules convert incoming email, social, or custom activities into cases; they fire on activity creation, set the target queue and source type, and can set Regarding to the originating activity.
Subjects form a category tree used for case classification, routing, SLA applicability, and analytics; set a subject on the case early because routing and reporting rules reference it.
Status reasons are configurable per status; the reason value (not just Resolved status) drives resolution reporting, so standardize reasons rather than letting agents free-type.
Parent-child cases: a child case keeps its own SLA and owner, and the Close all child cases when parent case closes behaviour must be confirmed in settings before relying on it.
Case resolve and cancel actions create a resolution activity that stores billable time, resolution type, and description; reopen by reactivating that record.
Manage knowledge management
Version model: major versions are whole numbers (1, 2, 3) and minor versions are decimals (1.1, 1.2); publishing creates the version visible to readers while draft minor edits stay unpublished.
Lifecycle order: Draft -> Proposed/In review -> Approved -> Published -> Expired or Archived; only Published content is served to portals and to the case Knowledge Search control.
Article templates (standard or structured with predefined sections) enforce consistent structure and required fields at authoring time; choose the template before content exists, because switching later loses section mapping.
Embedded knowledge search must be enabled in knowledge management settings for the Knowledge Search control to appear on the case form; search results can be filtered by article type and by visibility.
Link an article to a case through the Regarding field; only linked articles count as article usage in knowledge analytics, so coach agents to link rather than just read.
Internal vs external visibility is set per article and per version; external articles surface through Power Pages portals, internal ones only inside the app.
Article feedback stores a rating and comment per article per contact and rolls into knowledge analytics; use it to identify articles needing rewrite or retirement.
AI suggestion features (suggested articles, similar cases, case deflection) require the case form to host the Copilot/side-pane control and enough historical case data to produce relevant matches.
Article search relevance depends on title, keywords, and description fields; populate keywords deliberately because the search control ranks on those fields, not on body text alone.
Manage entitlements and SLAs
Entitlement applicability is decided by three checks together: the case customer matches the entitlement customer or contact, the case origin matches an enabled entitlement channel (Email, Phone, Web, Facebook, Twitter), and the current date falls inside the entitlement start and end dates.
Entitlement terms: Number of cases decrements a case counter per term period, Number of hours decrements remaining support hours, and Both enforces both limits; the default entitlement applies only when explicitly marked as default.
SLA anatomy: the SLA record holds the business hours calendar; each SLA item holds Applicable When conditions, a KPI (First response or Resolve by), a warning action, a failure action, and an Allow Pause flag.
Standard SLA applies through the Applicable From field on the SLA record; enhanced SLA uses SLA items and is required for pause, resume, and multiple conditional KPIs.
Only one SLA applies to a case at a time; set it as default on the SLA or apply it manually, and note that changing the case fields used in Applicable When can drop the KPI instances.
Due date formula: KPI by-time = KPI start time + KPI time, calculated against the SLA business hours calendar when one is attached, otherwise 24x7 elapsed time.
Warning behaviour fires at the warning threshold expressed as a percentage of the KPI duration before failure; typical use is notifying the owner or escalating priority.
Pause rule: with Allow Pause enabled, the timer stops while the case satisfies the item's pause condition (commonly status On Hold) and resumes when the condition becomes false.
SLA KPI instances expose On Track, Warning, Succeeded, and Failed states and are the records historical SLA reporting aggregates, not the SLA item itself.
Implement scheduling
Requirement to booking chain: a resource requirement captures duration, time window, characteristics, roles, territory, and resource type; the schedule assistant returns candidate resources and the chosen match becomes a bookable resource booking.
Fulfillment preference decision: None accepts any resource that meets the minimum constraints, Restricted requires every constraint to match exactly, and Full Capacity consumes all of the resource's available capacity in the booking.
Requirement groups bundle multiple requirements that must be filled by the same resource and in a defined order, which is how multi-step jobs keep one technician across all steps.
Availability search honours work hours calendars, existing bookings, capacity profiles, and the time zone of the search; results outside the requirement window are excluded even if the resource is free.
Schedule board views switch between hourly and daily granularity and between resource and requirement rows; drag and drop on the board edits bookings, and the map pane filters candidates by travel distance.
Booking statuses (Scheduled, Traveling, In Progress, Completed, and custom statuses) record where a job stands; booking timestamps capture actual start and end for duration analytics.
Resource Scheduling Optimization runs automated batch optimization across many requirements and resources, whereas the schedule assistant is an interactive, one-requirement search.
Presence and capacity both gate scheduling: a resource without available capacity in the target window is excluded regardless of skills, so check capacity profiles before widening skills filters.
Implement multi-session experiences for Customer Service
A session is one customer conversation; an agent handles several sessions concurrently, and each session can hold multiple tabs such as Conversation, Case, Knowledge, and Customer Summary.
Session templates define which tabs open for a session and are attached to workstreams, so different channels can present different tab sets without agent action.
Capacity profiles assign capacity units, and each workstream's capacity setting determines how much capacity a session consumes; an agent receives new work until available capacity is exhausted.
Presence (Available, Busy, Away, Offline, Do Not Disturb) is checked before assignment; Offline and Do Not Disturb block new sessions while Busy typically still allows the configured concurrency.
Wrap-up (after-conversation) time is configured at the workstream level and keeps the agent occupied finishing notes and case details after the conversation ends.
Session timeout and idle-close settings determine when an abandoned conversation ends automatically; set them per channel workstream rather than globally when channels behave differently.
Transfer moves the session to another queue or agent; consult opens a separate conversation with a colleague while the customer stays with the original agent.
The productivity pane surfaces Smart Assist suggestions, agent scripts, and knowledge article recommendations driven by the conversation text and case context.
Manage analytics, visualizations, and insights
Split by latency: historical analytics in the Customer Service Analytics app is refreshed on a schedule (typically daily) and supports trend analysis; real-time analytics in Omnichannel refreshes continuously for live supervision.
Core case KPIs to reconcile: case volume, first response time, average resolution time, SLA success and failure counts, reopened count, and CSAT.
Core conversation KPIs to reconcile: sessions waiting, active sessions, average wait time, average handle time, transfer rate, abandonment rate, and CSAT.
Case topics are AI-generated clusters derived from case title and description; they require a minimum volume of cases and are used to surface emerging issues and deflection candidates.
Sentiment analysis runs on conversation transcripts and is scored per conversation and per message; results feed real-time dashboards and the conversation record.
Dashboards come in two flavours: Dataverse standard or interactive dashboards built from views and charts, and Power BI dashboards or tiles embedded in the model-driven app through the Power BI visual control.
Knowledge analytics combine article views, article usage through case linkage, and feedback ratings; an article with high views and low ratings signals a rewrite, not a promotion.
SLA reporting reads SLA KPI instances, so failed and succeeded timers should be validated against the SLA item definition before trusting the dashboard totals.
Implement Microsoft Power Platform
Customization choice order for case forms: business rules for required and visible fields, calculated or rollup columns for derived values, Power Automate for cross-table or external actions, and JavaScript or PCF controls only when the first three cannot meet the requirement.
Business rule scope decides execution surface: scope set to a form runs client-side only, while scope set to an entity runs server-side for all data operations including imports and API writes.
Security model: security roles grant create, read, write, delete, append, and append-to privileges per table; business units define ownership boundaries and field security profiles protect individual columns.
Solutions should ship as managed in test and production and stay unmanaged only in development; use publishers to keep a consistent prefix and environment variables plus connection references for ALM.
Power Automate cloud flows replace classic workflows for new automation and can be triggered by Dataverse create, update, and delete events, schedules, or external connectors.
Data loss prevention policies in the Power Platform admin center classify connectors as business, non-business, or blocked; a flow cannot move data between business and non-business connectors.
Copilot Studio agents attach to Omnichannel as bots on a workstream and escalate to human queues when the bot cannot resolve the conversation.
Custom connectors wrap external REST APIs for use in flows and canvas apps; they require an OpenAPI definition and their own authentication configuration.
Implement Connected Customer Service and routing
Connected Customer Service requires its add-on solution; installing it adds IoT Alert, IoT Device, IoT Device Category, IoT Device Command, and device registration tables to the environment.
Device onboarding order: create an IoT provider instance (Azure IoT Hub or IoT Central), register the device with its device ID and authentication, then link the device record to the customer asset it belongs to.
Alert to case flow: an IoT alert arriving from the provider can trigger a workflow or Power Automate flow that creates a case, sets Regarding to the device asset, and copies telemetry for the agent.
Unified routing pipeline runs intake -> classification -> assignment: workstreams define channel, capacity, and rule sets, classification rule sets set attributes, and assignment rule sets choose a queue.
Workstream decision: the workstream record binds a channel instance to a capacity profile and to its classification and assignment rule sets, so a new channel requires a new workstream, not a new queue.
Assignment mode: push delivers work directly to a matching agent, while pick places it in the agent's open work items stream for manual selection; the queue's work distribution setting controls this.
Agent eligibility requires presence set to a routable status plus remaining capacity; an agent at capacity or in Do Not Disturb is skipped by assignment rules.
Classic routing still applies outside unified routing: queue items are routed by route-to-queue rules or by the Route To action on the case, and every case must belong to a queue to be worked.
Omnichannel assignment strategy on a queue (such as round robin or highest capacity) is evaluated after the assignment rule set selects the queue, not before.