Demonstrate the capabilities of Microsoft Copilot Studio practice questions

Integrate with a custom API by writing JavaScript code.

Why it fails: Custom code is required for advanced API integration.

Train the copilot with a custom machine learning model.

Why it fails: Copilot Studio uses prebuilt models; custom training requires AI Builder or custom code.

Deploy the copilot to a third-party website using custom HTML.

Why it fails: While possible, deploying to a website typically requires embedding code or additional configuration.

Use the 'Search' feature with a SharePoint connector and configure it to query the document library in real-time.

Why it fails: The Search feature can query SharePoint, but it does not provide generative answers with citations. It returns search results, not synthesized answers. The requirement is for accurate answers with citations, which generative answers provide. Search alone does not meet the need for cited, conversational responses.

Manually upload the PDF documents to the copilot's knowledge base and set a recurring reminder to re-upload them.

Why it fails: Manual uploads are static and do not automatically update. Re-uploading requires manual effort and is error-prone. This does not meet the requirement for frequent updates. The copilot would provide outdated answers between uploads. This approach is not scalable or reliable.

Create a Power Automate flow that triggers when a file is modified in SharePoint and updates the copilot's knowledge base via the Copilot Studio API.

Why it fails: While possible, this requires custom development and API usage, which is complex and may not be supported natively. The built-in SharePoint data source with synchronization is simpler and designed for this purpose. Using a flow adds unnecessary complexity and potential points of failure. This is not the intended no-code solution.

An environment variable

Why it fails: Environment variables in Power Platform are used to store configuration data such as URLs or keys that solutions reference, not conversational user input. They are not designed to hold per-conversation values like an employee ID. Using an environment variable for this purpose would be inappropriate and would not persist correctly across conversation turns.

A global variable

Why it fails: Global variables persist across sessions for a specific user, which is more than needed here and can introduce complexity. For capturing a value within the current conversation and using it in later turns, a topic-level variable is the intended mechanism. Global variables are better suited for values like user preferences that must survive beyond a single conversation.

A Power Automate flow variable

Why it fails: Variables inside a Power Automate flow exist only during that flow run and cannot be directly referenced by Copilot Studio question nodes. While a flow can return values to a copilot, it does not provide a place to store input for later conversational use. The maker needs a Copilot Studio variable, not a flow variable.

Embed the ticketing system's API key in the copilot's authentication settings and call the API from a topic.

Why it fails: Copilot Studio does not support calling external APIs directly from topics. Authentication settings are for user authentication, not for API keys. You need a Power Automate flow with a custom connector to handle API calls. This option is technically incorrect.

Configure the copilot to use the 'Send an HTTP request' action directly within a topic to call the ticketing system's API.

Why it fails: Copilot Studio does not have a built-in 'Send an HTTP request' action within topics. HTTP calls are typically made via Power Automate flows. While you can use the HTTP action in Power Automate, it is not a native Copilot Studio topic action. This option is not directly supported.

Use the 'Create a record' action in the Common Data Service to insert a ticket directly.

Why it fails: The Common Data Service (now Microsoft Dataverse) is a data storage service, not a ticketing system. Creating a record in Dataverse does not create a ticket in an external system. This option does not meet the requirement of integrating with the external ticketing system's API.

Republish the copilot to refresh the knowledge source.

Why it fails: Republishing the copilot deploys the latest configuration of the bot but does not force a re-index of the knowledge source. The knowledge source has its own refresh schedule, and republishing does not override it. While republishing is necessary after changes to topics or settings, it will not solve the issue of outdated indexed content from SharePoint in this scenario.

Change the knowledge source to use a different SharePoint library.

Why it fails: Switching to a different library would change the scope of content but does not address the core issue of index staleness. The original library still contains the updated document, and the copilot simply needs its index refreshed. Changing the library could even remove relevant content, making the solution worse, and it does not solve the immediate need for updated information.

Delete and recreate the SharePoint site connection.

Why it fails: Deleting and recreating the connection does not update the indexed content; it only re-establishes authentication. The knowledge source index remains unchanged until a refresh occurs. This action is disruptive and unnecessary, and it does not guarantee that the latest document version will be picked up any faster than a manual refresh.

Enable the 'Authentication' feature and require users to accept terms and conditions before using the copilot.

Why it fails: Authentication and terms acceptance do not modify the copilot's responses. They are for user verification and legal consent, not for adding disclaimers or preventing advice. This does not meet the requirement to include a disclaimer in every response. It is unrelated to content control.

Use the 'Content moderation' settings to block responses that contain financial advice and add a disclaimer message.

Why it fails: Content moderation can block inappropriate content, but it does not automatically add disclaimers to responses. It also may not reliably detect financial advice. This feature is more about filtering harmful content. It does not fulfill the requirement to include a disclaimer in all responses.

Modify the 'Conversation boosting' settings to include a disclaimer in every response.

Why it fails: Conversation boosting is used to add phrases that improve recognition, not to append disclaimers. It does not control the content of generative answers. This feature is not designed for compliance messaging. Using it would not meet the requirement.

No authentication

Why it fails: No authentication allows anonymous access, which means the copilot cannot identify individual students. Without identity, it cannot securely retrieve personalized schedules from a protected API. This setting is suitable for public bots with no user-specific data, but it fails the requirement to authenticate students and access their personal information.

Authenticate with Microsoft

Why it fails: Authenticate with Microsoft is designed for users within the same Microsoft Entra ID tenant, such as internal employees. Students are often external users without organizational accounts, so this option may not work for them. While it provides authentication, it is not the most flexible choice for a university that needs to support students who are not tenant members.

Use a Power Virtual Agents bot channel registration

Why it fails: Bot channel registration is a legacy configuration for connecting bots to channels and does not provide the built-in user authentication needed for personalized data retrieval. It is not the recommended way to authenticate users in Copilot Studio, and it would require additional custom development. This option does not directly satisfy the requirement for student authentication.

Authenticate with generic OAuth 2.0 providers

Why it fails: Generic OAuth 2.0 providers are for external identity systems, not Microsoft Entra ID. While this could work for external users, it does not meet the requirement of using Microsoft Entra ID credentials for internal employees. It would add complexity and not leverage the existing Microsoft 365 identity infrastructure.

No authentication

Why it fails: No authentication means the copilot cannot identify users or access protected resources on their behalf. This directly contradicts the requirement to use Microsoft Entra ID credentials for protected resources. It is suitable only for public, anonymous copilots that do not need user context.

Authenticate manually with OAuth 2.0

Why it fails: Manual OAuth 2.0 authentication can be used for custom identity providers, but it is not the primary choice for internal employees using Microsoft Entra ID. It requires more configuration and may not integrate as seamlessly with Teams and Microsoft resources. For the stated scenario, the built-in Microsoft authentication is the more appropriate option.

Disable generative answers and rely only on authored topics.

Why it fails: Disabling generative answers would eliminate the feature that provides flexible answers, but it also removes the ability to answer questions outside authored topics. The goal is to reduce ungrounded responses, not to remove generative capabilities entirely. Authored topics alone may not cover the breadth of user questions, so this is an overly restrictive solution.

Publish the copilot to a different channel.

Why it fails: Changing the channel does not affect how generative answers are grounded. The behavior of generative answers is determined by the copilot's configuration, not the channel. While some channels may have different rendering, the grounding issue would persist. The maker needs to adjust the knowledge source settings, not the deployment channel.

Increase the number of topics in the copilot.

Why it fails: Adding more topics increases authored coverage but does not directly control how generative answers select and ground content. The ungrounded responses likely come from the generative answers feature using general knowledge or unapproved sources. Without restricting the knowledge sources, adding topics may not solve the problem and could even increase maintenance overhead.

Generative AI feature

Why it fails: Generative AI is a capability within Microsoft Copilot Studio, not the feature that connects a knowledge source. It generates responses from whatever grounding is configured, but does not itself ingest SharePoint documents. The correct feature is the knowledge source configuration that points the copilot at SharePoint content.

Power Automate cloud flow

Why it fails: Power Automate cloud flows orchestrate actions, approvals and connectors; they do not ground a copilot's answers in SharePoint documents. A flow could trigger after a response, but retrieval requires a knowledge source. Power Automate is correct when the requirement is automating a business process, not supplying conversational knowledge.

Copilot for Microsoft 365

Why it fails: Copilot for Microsoft 365 is a prebuilt assistant surfacing Microsoft Graph data inside Office apps; it cannot be authored as a custom copilot grounded on selected SharePoint documents. Microsoft Copilot Studio is required to build that. Copilot for Microsoft 365 suits organisations wanting ready-made productivity assistance without custom knowledge scoping.

Enable the 'Show citations' option

Why it fails: Showing citations only displays the source links behind a generated answer; it does not refresh stale SharePoint or website content, so outdated responses persist. Citations suit auditing and user trust when answers are already accurate. The accuracy problem stems from knowledge-source indexing, which requires reindexing or updating the sources instead.

Reduce the number of topics

Why it fails: Reducing topics trims conversational triggers, not the stale content the generative answers draw from SharePoint and public websites. It is tempting because topic limits can affect performance, and pruning them is valid when a copilot has too many overlapping triggers or hits orchestration limits — but here the fix is refreshing or re-indexing the knowledge sources.

Turn off Generative AI for responses

Why it fails: Disabling generative AI prevents the copilot from synthesising answers at all, so stale knowledge-source content still surfaces verbatim rather than being resolved. It is tempting because generative mode is what hallucinates or paraphrases, and switching it off suits deterministic, scripted flows with fixed responses — not a knowledge-grounded copilot needing fresher retrieval.

Anonymous access

Why it fails: Anonymous access grants no user identity, so the copilot cannot retrieve personalised onboarding information. It is tempting because anonymous access removes sign-in friction and suits public-facing bots, but the stem requires authenticated, per-employee content tied to Microsoft Entra ID accounts.

Manual authentication

Why it fails: Manual authentication requires the administrator to supply an authorisation URL and credentials, bypassing Microsoft Entra ID sign-in entirely, so personalised identity claims are unavailable. It is tempting because manual auth suits external or custom identity providers, but the stem already mandates Microsoft Entra ID.

SharePoint authentication

Why it fails: SharePoint authentication only verifies access to SharePoint resources, not Microsoft Entra ID identities, so it cannot deliver the personalised onboarding data tied to the employee's Entra ID account. It is tempting because SharePoint hosts onboarding content, and it would fit a copilot scoped solely to SharePoint document retrieval without per-user identity.

Embed a Power Apps canvas app

Why it fails: A canvas app provides a user interface, not backend workflow orchestration, so it cannot create the Dataverse record and dispatch the approval email. It is tempting because Power Apps integrates with Copilot Studio, but a Power Automate cloud flow supplies the multi-step automation this scenario requires.

Use AI Builder to create a model

Why it fails: AI Builder builds and consumes machine-learning models such as prediction or form processing; it does not create Dataverse records or send approval emails. It is tempting because it extends copilots with intelligence, but a Power Automate cloud flow provides the required record creation and approval action.

Configure the Dataverse connector directly

Why it fails: The Dataverse connector alone performs create, read, update and delete operations; it cannot orchestrate an approval email step. It is tempting because the workflow writes to Dataverse, but a Power Automate cloud flow is needed to chain the record creation and approval action together.

Enable anonymous access to allow external users

Why it fails: Anonymous access removes authentication entirely, so anyone reaching the copilot could query sensitive employee data with no identity verification or audit trail. It is tempting because anonymous access suits public-facing bots answering general questions, but a copilot handling confidential HR records requires authenticated Microsoft Entra ID sign-in and access controls.

Disable authentication to simplify access

Why it fails: Disabling authentication lets anyone interact with the copilot and reach sensitive employee data without identity verification, defeating compliance and audit requirements. It is tempting because removing sign-in simplifies access during testing, but production copilots handling confidential data must authenticate users through Microsoft Entra ID and enforce permissions.

Add public websites as knowledge sources

Why it fails: Public websites are unauthenticated external content, so grounding answers in them risks leaking sensitive employee data and cannot enforce compliance boundaries. Adding public sites is tempting for general knowledge bots, but this scenario requires restricting knowledge sources to internal, permission-trimmed repositories such as SharePoint or Dataverse.

The public website refresh is set to daily

Why it fails: The public website refresh schedule governs external web content crawling, not SharePoint site indexing. HR policies live in SharePoint, whose content is indexed on its own cycle. A daily public refresh setting would be relevant only when the copilot sources answers from an internet-facing site.

Authentication is not properly configured

Why it fails: Broken authentication would block users from reaching the copilot entirely, producing sign-in errors rather than stale answers. The reported behaviour is partial: some HR content answers, recent updates do not. Authentication misconfiguration is the cause when no user can authenticate or query the copilot at all.

Generative AI is disabled

Why it fails: Disabling generative AI would stop the copilot answering any question, not merely recent HR content. The stem describes selective failure on today's updates, which points to search indexing latency. Generative AI being off is the cause when the copilot returns no responses whatsoever.

Enable Microsoft Entra ID authentication to restrict access

Why it fails: Enabling Microsoft Entra ID authentication restricts who can reach the copilot; it does not stop the public website from supplying irrelevant citations or wrong specifications. It is tempting because authentication hardens access, but the reported problem is answer accuracy and source relevance, not anonymous access.

Turn off Generative AI and use only manual topics

Why it fails: Disabling generative answers forces every response through authored topics, removing the ability to answer industry news questions from the public website. It is tempting because it eliminates hallucinated specifications, but the requirement explicitly retains open-ended news answering, which only generative orchestration provides.

Add additional SharePoint sites with product specifications

Why it fails: Adding more SharePoint sites increases the volume of indexed content without correcting the public website's unrelated citations, so inaccuracies persist. It is tempting because enriching authoritative documentation can improve grounding, but the immediate fault is an untrusted knowledge source, not insufficient product content.

The bot is stuck in the Fallback topic.

Why it fails: Fallback triggers only when no topic matches the utterance; here the order-status topic matched and prompted for the number, so the bot is not in Fallback. It is tempting because unhandled input often lands there, and Fallback would be correct if the bot had failed to recognise the initial request.

The trigger phrase does not match exactly.

Why it fails: The trigger phrase already matched, since the bot asked for the order number, so exact phrase matching is not the failure point; the entity capture or variable handling afterwards is. It is tempting because trigger mismatches commonly cause silent failures, and it would be correct if the bot had never recognised the opening request.

The "Redirect to Order Lookup topic" action is placed before the message actions.

Why it fails: Placing the redirect before the message actions would skip the prompt entirely, yet the customer did receive it, so ordering is not the cause. It is tempting because action sequence errors do break flows, and this would be correct if the bot had redirected without ever asking for the order number.

Reorder topics so that "Refund Policy" appears before "Shipping Information" in the topic list.

Why it fails: Copilot Studio selects a topic by matching trigger phrases and confidence, not by list position, so reordering changes nothing. Topic order is relevant only for chained or redirected conversation flow, not for which topic initially fires on a user utterance.

Lower the trigger confidence threshold for the "Refund Policy" topic to 0.7.

Why it fails: Lowering the threshold makes the Refund Policy topic fire on weaker matches, but the Shipping Information topic still matches the identical phrase "refund policy", so ambiguity persists and misrouting continues. Threshold tuning suits cases where a correct topic scores just below the trigger limit.

Delete the "Shipping Information" topic and recreate it without the phrase "refund policy."

Why it fails: Deleting and recreating the topic removes its configuration, variables and any connected flows, exceeding the minimal-change requirement. Editing the trigger phrases directly achieves the same result. Recreating is warranted only when a topic is fundamentally broken or corrupted.

Use a Power Automate flow that sends a proactive message to the user when the conversation starts.

Why it fails: Power Automate flows can send proactive messages, but they are triggered by external events, not automatically on conversation start within Copilot Studio. They require configuration and may introduce latency. The built-in system topic is simpler and designed for this purpose. Using a flow here is overcomplicated and not the intended method.

Create a custom entity that captures the user's name and date, and set it as a required input in the greeting topic.

Why it fails: Custom entities are used to extract information from user utterances, not to automatically populate a greeting. They require user input to be triggered. Setting a required input would force the bot to ask for the name, which is not the desired automatic personalized greeting. This approach adds unnecessary steps.

Configure the copilot's authentication settings to retrieve the user's name from Microsoft Entra ID and insert it into the greeting.

Why it fails: Authentication can provide the user's name, but it does not automatically insert it into a greeting message. You still need a message node in the greeting topic to display it. Authentication alone does not handle the timing or content of the greeting. This option addresses only part of the requirement.

The Power Apps canvas app screen navigator

Why it fails: Power Apps canvas screens provide a graphical app UI for users, not a conversational copilot. Navigating between screens is a different interaction model from a chat-based copilot, and it would not deliver the greeting and natural-language Q&A behavior the support team lead needs.

The Dataverse table designer with relationship columns

Why it fails: Dataverse stores business data in tables and relationships, but it does not author conversational logic. Building a table schema will not create trigger phrases or question nodes that drive a customer conversation, so it does not satisfy the requirement to structure the copilot dialogue without code.

The Power Automate cloud flow designer with trigger conditions

Why it fails: Power Automate cloud flows orchestrate backend automation such as approvals or data updates, not the conversational branching of a copilot. While a copilot topic can call a flow, the flow itself does not present questions to the user or branch the dialogue, so it cannot by itself structure the customer greeting and Q&A experience described.