MB-230 Practice Questions

To manage escalation workstreams effectively, creating two routing rules allows for distinct logic to be applied to regular tickets versus those meeting escalation criteria, ensuring they land in the correct queues. For the escalation handling tool, Power Virtual Agents is the officially supported platform for building bots that integrate with Omnichannel for Customer Service to handle initial customer interactions and facilitate seamless handoffs to human agents during escalations.

Microsoft Official Documentation: "Create routing rules in Customer Service Hub." (Section: Create a routing rule set).

Microsoft Official Documentation: "Configure Power Virtual Agents bots for Omnichannel for Customer Service." (Section: Prerequisites and integration).

Microsoft Learn (Official Curriculum): "Configure routing rules and workstreams in Dynamics 365 Customer Service." (Unit: Managing escalation paths).

Microsoft Official Documentation: "Unified routing for Customer Service - Rule sets and item routing."

To modify an active routing rule set in Dynamics 365 Customer Service while following the principle of least privilege, you must first ensure you have the appropriate security role. The Customer Service Manager role is the minimum standard role required to manage service configurations like routing rules; a representative role lacks these permissions.

Once in the correct area of the application, an active routing rule set cannot be edited directly. It must be deactivated first to make structural changes. After deactivation, you can edit the rule items or criteria. Finally, the rule set must be activated again to resume automatic case routing. Publishing customizations is not required for activating existing routing rule modifications.

Microsoft Official Documentation: Create routing rules to route cases automatically. (2024). Section: "Create a routing rule set." (Details requirement to deactivate before editing and the roles required for service configuration).

Microsoft Learn: Security roles and privileges in Customer Service. (2024). Table of predefined roles: Customer Service Manager vs. Representative.

Microsoft Dynamics 365 Guidance: Administering Customer Service. Section: "Routing rules - Deactivation and Activation lifecycle."

Microsoft Power Platform Documentation: Apply Principle of Least Privilege. (2023). Section: "Standard Security Roles for Dynamics 365 Apps."

To ensure a chart is visible to all users by default, it must be created as a System Chart rather than a Personal Chart. The correct administrative workflow begins in the Settings > Solutions area. First, you must ensure the target entity (Case/Incident) is included in your unmanaged solution. Next, you drill down into the entity's metadata structure to locate the Charts node. Finally, you use the Chart Designer to "Create and configure the chart" with the required dimensions (resolved cases by month and agent). Actions like "Navigate to the Service area" or "In Case View, create a new chart" lead to the creation of Personal Charts, which are private to the creator unless shared individually.

icrosoft Learn: Create or edit a system chart. This documentation specifies that system charts are created via the "Solutions" or "Customization" area to be available organization-wide. (Section: "Create a system chart").

Microsoft Power Platform Docs: Create a model-driven app system chart. Validates that "System charts are owned by the organization" and created through the solution explorer, distinguishing them from user-owned charts.

Dynamics 365 Customer Service Documentation: View and use charts. Explains the visibility differences between system-level visualizations and personal views/charts.

Microsoft Dynamics 365 Architecture Standards: Detail the requirement for using "Solutions" (unmanaged) to modify entity components like Charts and Forms for deployment across environments.

The image displays a Multi-stream dashboard standard view. It is "multi-stream" because it shows data from multiple sources (Active Cases, Resolved Cases, Emails, Activities) simultaneously in separate streams. It is in "standard view" because the streams are shown as lists of records; the "Switch to Tile View" button in the command bar indicates that the current view is not the tile view.

The filters shown at the top (doughnut, pie, and bar charts) are Visual filters. These interactive charts allow users to filter the data streams below by clicking on specific data segments (e.g., clicking a priority level in the doughnut chart). The "Hide Visual Filter" option in the command bar confirms that visual filters are currently active and visible.

Microsoft Learn (Official Vendor Documentation): "Configure interactive experience dashboards in Customer Service." This article defines multi-stream dashboards as those displaying data in real-time over multiple data streams.

Microsoft Dynamics 365 Documentation: "Use interactive dashboards to effectively manage service cases." This section distinguishes between standard (list) views and tile views, noting that the command bar allows toggling between them.

Microsoft Learn: "Customer Service Hub Guide - Track your cases using interactive dashboards." This documentation describes Visual Filters as the top-row charts (pie, bar, doughnut) used to filter the underlying data streams.

Microsoft Power Platform Documentation: "Create and configure interactive experience dashboards." (Section: Visual Filters vs. Global Filters). It specifies that Global filters are field-based filters (often hidden in a flyout), while Visual filters are the graphical representations shown at the top.

The most direct way to notify managers about unhappy customers (patients) is to enable and configure the real-time customer sentiment analysis feature. When the "Monitor real-time customer sentiment" option is set to 'Yes' within a workstream, the system analyzes incoming messages for sentiment. You can then configure alert rules that automatically send notifications to supervisors (managers) when a customer's sentiment drops below a specified threshold (e.g., "negative" or "slightly negative"). This feature is specifically designed for real-time intervention by supervisors in response to declining customer satisfaction during a conversation.

A. Configure Omnichannel Insights: Omnichannel Insights provides historical and real-time analytics dashboards for trend analysis and performance monitoring, not for triggering immediate notifications about individual conversations.

B. Set a routing rule for escalations: Routing rules direct entire conversations to different queues or agents based on conditions. While this could send a case to an escalation queue, it is not a direct notification to a manager; it's a work-routing mechanism.

1. Microsoft Learn. (2023). Monitor real-time customer sentiment. In Dynamics 365 Customer Service documentation.

Section: "Enable sentiment analysis" and "Configure sentiment alert rules".

Quote/Content: The documentation explicitly states

"You can configure notifications that you want to send to... supervisors when the customer sentiment reaches the threshold that you set." It details the first step as setting the "Monitor real-time customer sentiment" toggle to Yes within the workstream configuration. This directly supports enabling the feature as the correct action.

2. Microsoft Learn. (2023). Overview of unified routing. In Dynamics 365 Customer Service documentation.

Section: "Basic routing versus unified routing".

Content: This document explains that routing is the process of assigning work items to the best-suited queue or agent. It does not describe a direct notification mechanism for supervisors based on sentiment

confirming that routing rules (Option B) are for a different primary purpose.

3. Microsoft Learn. (2023). Introduction to Omnichannel insights dashboard. In Dynamics 365 Customer Service documentation.

Section: "Summary dashboard".

Content: This source describes the Insights dashboards as tools for providing "key performance indicators (KPIs) and trends" and for supervisors to "understand the overall support experience." This confirms its role as an analytical tool (Option A)

not a real-time alert system for individual interactions.

In Dynamics 365 Voice of the Customer, a Basic survey provides the necessary configuration for applying visual themes and branding. Response routing is utilized to implement server-side logic that directs users to different sets of questions or pages based on their selections. Client-side routing is specifically designed for immediate interactions on a single page, such as hiding or showing specific questions without requiring a page refresh. Piping allows the survey to dynamically insert data, such as a specific response from a previous question, into subsequent questions to create a personalized flow.

Microsoft Dynamics 365 Documentation: "Plan a survey (Voice of the Customer)" - Section: Survey Types and Themes.

Microsoft Dynamics 365 Documentation: "Create routing rules in a survey" - Paragraph: Client-side vs. Server-side routing logic.

Microsoft Dynamics 365 Documentation: "Personalize survey questions with piping" - Section: Answer Piping configuration.

To properly integrate and configure a chatbot within Dynamics 365 Customer Service, you must establish the routing logic and the data transfer mechanism. First, you need a dedicated queue for human agents to handle conversations escalated from the bot. The workstream routes incoming conversations to the chatbot initially, and upon escalation, reroutes them to the human agent queue. Second, configuring context variables is essential. These variables capture key information from the customer during the bot conversation (e.g., name, product, issue type) and pass it to the human agent, ensuring a seamless and informed transition without requiring the customer to repeat information.

A. Enable a Microsoft Copilot Studio chatbot to end conversations.

This is a standard capability configured within a bot's topic flow, not a primary integration or setup action for connecting it to the customer service platform.

B. Add the chatbot to an existing human agent queue.

This is incorrect. Chatbots are the first point of contact in a workstream; they escalate conversations to a human agent queue, but are not members of it.

C. Enable AI suggestions with the chatbot.

AI suggestions are a feature to assist human agents by providing real-time recommendations like knowledge articles or case resolutions, not a configuration step for the chatbot itself.

1. Microsoft Learn | Dynamics 365 Customer Service Documentation. "Configure context variables for a bot." This document explicitly states

"When a customer's conversation is escalated from a bot to a human agent

the complete context of the bot conversation can be shared with the human agent... To configure the transfer of conversation context

you must configure context variables." This directly supports option E.

2. Microsoft Learn | Dynamics 365 Customer Service Documentation. "Integrate a Copilot Studio bot." Under the "Create a bot user" and "Add the bot to a queue" sections

the documentation outlines the necessity of setting up the bot within a workstream that routes to a specific queue for bot interactions

and then configuring escalation rules to transfer to a separate human agent queue. This supports the structural setup described in option D.

3. Microsoft Learn | Microsoft Copilot Studio Documentation. "Configure hand-off to Dynamics 365 Customer Service." This guide details using the "Transfer to agent" node

which sends the conversation and its context (variables) to Omnichannel for Customer Service

which then uses its routing rules to assign the conversation to the appropriate human agent queue. This reinforces the need for both context variables (E) and a destination queue for humans (D).

In Dynamics 365 Omnichannel for Customer Service, agent script steps are categorized by their action types. For the first requirement, "Verify customer's information" is a manual instruction for the agent to follow; the Text action type provides these written directions as plain text within the agent's productivity pane. For the second requirement, "Enable auto search," the system must perform a programmatic action to trigger the search functionality based on session data (like the case title). This is achieved using the Macro action type, which automates multi-step tasks or triggers specific UI components, such as the Knowledge Search control, without manual agent input.

Microsoft Official Documentation: Create agent scripts, section "Agent script step action types." It defines Text for providing instructions and Macro for automating tasks like opening a knowledge search.

Microsoft Official Documentation: Macros in Omnichannel for Customer Service, section "Automation in productivity tools." This details how macros are used to perform contextual searches based on entity attributes.

Microsoft Official Documentation: Agent scripts in Customer Service, "Understand the difference between Macro and Script" identifiers. This clarifies that static guidance uses Text, while automated system interactions require Macros.

The Copilot case summary feature in Dynamics 365 Customer Service generates a summary based on key information within the case record. The primary data sources include the case title, the problem description, recent notes, and associated email activities. The error message "There's not enough information to summarize" indicates that the AI model lacks sufficient textual content from these sources to create a meaningful summary. Ensuring the case has a comprehensive description provides the necessary input for the Copilot feature to function as intended.

A. Expand the activity highlights summary.

The activity highlights summary is a distinct feature from the case summary. Configuring it does not resolve the lack of input data for the case summary card.

B. Change the case to resolved and expand the case summary card.

The case summary is most valuable for active cases to help agents get up to speed. Resolving a case is not a prerequisite for generating a summary.

C. Provide feedback comments to the Case summary feature in Copilot.

Providing feedback helps Microsoft improve the AI model over time but is not a configuration step that will immediately resolve the error on a specific case.

E. Refresh the case summary.

Refreshing the summary is only effective if the necessary data was recently added but not yet processed. It does not fix the root cause, which is the absence of information.

---

1. Microsoft Learn. "Use Copilot to summarize cases and conversations." Dynamics 365 Customer Service Documentation. This document states

"The case summary includes key information such as the case title

customer

product

subject

problem description

and case notes." This confirms the "problem description" field is a primary input.

2. Microsoft Learn. "Enable Copilot features in Customer Service." Dynamics 365 Customer Service Documentation. In the section detailing the "Summarize a case" feature

the documentation implicitly relies on the presence of data in the case record for the summary to be generated. The absence of this data

particularly in the description field

is a common reason for failure.

3. Microsoft Learn. "Frequently asked questions about Copilot in Customer Service." Dynamics 365 Customer Service Documentation. This FAQ explains the data handling and model behavior

noting that the quality and availability of summaries are dependent on the richness of the underlying case data. It states

"The summary is generated based on the case title

description

notes

and emails."

The Environment Maker role is specifically designed for users who need to create resources such as canvas apps, connections, and Power Automate flows within an environment. Crucially, this role does not grant any privileges to access or view the data stored within the Microsoft Dataverse database. This perfectly aligns with the scenario's requirements to provide creation capabilities while strictly prohibiting data access, thereby adhering to the principle of least privilege.

B. System Customizer: This role has read-only access to most application data to see customizations in context, which violates the "no data access" requirement.

C. System Administrator: This role has full permissions over the entire environment, including unrestricted access to all data, which violates both the "no data access" and "least privilege" principles.

D. Environment Admin: This role grants full administrative control over an environment, including managing users and data, which far exceeds the required permissions and violates the stated constraints.

1. Microsoft Learn. (2023). Predefined security roles. In Power Platform documentation. Retrieved from https://learn.microsoft.com/en-us/power-platform/admin/database-security#predefined-security-roles.

Section: Predefined security roles. The table in this section explicitly states for the Environment Maker role: "However

this role doesn't have any privileges to access data within an environment." For the System Customizer role

it notes: "users with this role can only view records for environment entities that they create." For the System Administrator

it states: "Can view all data in the environment."

2. Microsoft Learn. (2023). Configure user security in an environment. In Power Platform documentation. Retrieved from https://learn.microsoft.com/en-us/power-platform/admin/database-security.

Section: Environment Maker. This section details that the role is for building assets and explicitly contrasts it with roles that have data access

reinforcing its suitability for this scenario based on the principle of least privilege.