Copilot Studio Agent with outlook connector

Question

Copilot Studio Agent with outlook connector

류재욱 25

Hello,

I am struggling with building an agent which helps user finding their Outlook email from the Inbox.

I've added o365 outlook connector (get email(v3)), set input as 'search_query',

but when i ask agent "find me the most recent email from ******@in4uclouud.com", it cannot find from Inbox and or finds only from other folder beside Inbox.

i thought this would be easy to build but cannot find the reason why this is failing...

does anyone know what could be the reason or how to build the proper mail searcher agent?

p.s. i've already got M365 Copilot Studio license

Thank you for your help!

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

William Edwards 165

The issue here is a fundamental mismatch between natural language and the API query language that the Outlook connector uses under the hood.

When you pass the agent's dynamic string directly into the Get emails (V3) connector, Copilot is likely passing the user's entire raw sentence ("find me the most recent...") into the Search Query field. The Outlook API does not process natural language. It expects rigid KQL (Keyword Query Language) syntax. When you feed it a full sentence, the API parses it as a massive "OR" search, pulling random garbage from Archive, Sent, or Deleted folders simply because those emails contain common words like "find" or "recent."

To fix this, you must physically bridge the gap between the AI's natural language and the API's hard syntax:

Constrain the AI's Extraction: Instead of a generic search_query input, rename your input variable to sender_email. In the input's description box, explicitly instruct the AI: "Extract only the exact email address from the user's prompt."
Hardcode the KQL Prefix: In the Get emails (V3) action setup, go to the Search Query field and physically type from: followed immediately by your dynamic sender_email variable (so the final execution reads exactly like from:******@in4uclouud.com).
Lock the Folder Path: Click the Folder dropdown in the action and physically select Inbox. Do not leave this as an AI-populated variable. The AI does not know your tenant's internal Exchange Folder IDs, and if it guesses, the connector will default to searching the entire mailbox tree.
Limit the Array: Set the Top or Fetch parameter to 1 so the array only returns the absolute most recent hit.

Are you adding this connector natively as a Copilot Studio Plugin Action, or are you routing the logic through a Power Automate Cloud Flow?

류재욱 25 Reputation points

2026-06-05T03:03:21.6+00:00

Thank u for answering!

Currently I have it set up as a native Copilot Studio Plugin Action and haven't used Power Automate yet since I'm still a beginner and wasn't sure which approach to take. My final goal is to build a more complete Outlook agent — not just email search, but also tasks like sending, or flagging emails, list outlook schedules and what not. so if Power Automate would be a better foundation for that, I'm open to switching. Which would you recommend for that scope?
Prasad-MSFT 10,541 Reputation points Microsoft External Staff Moderator

2026-06-08T13:12:07.23+00:00

For your stated goal (searching emails, sending emails, flagging messages, managing calendar events, etc.), I would start with native Copilot Studio actions where they meet your requirements, and introduce Power Automate only when you need additional control over the logic.

Native actions are generally simpler to set up and work well for straightforward Outlook operations. However, Power Automate gives you much more flexibility for scenarios such as parsing user input, building precise Outlook search queries, filtering results, handling multiple steps, applying business rules, and orchestrating actions across Outlook, Teams, SharePoint, and other services.

In your specific email-search scenario, a Power Automate flow can make it easier to extract the sender address, construct a deterministic search query, restrict the search to Inbox, sort by received time, and return the most recent result. That can be more predictable than relying on the agent to generate the correct connector inputs from natural language.

My recommendation would be: keep experimenting with the native Outlook actions first, but if you plan to build a full-featured Outlook assistant, learning Power Automate early will likely pay off because it gives you much finer control as the complexity of the agent grows.
William Edwards 165 Reputation points

2026-06-12T08:04:11.8866667+00:00
You're working with an outdated architectural dichotomy. The assumption that you must jump completely out of Copilot Studio into a standalone Power Automate Cloud Flow to handle stateful, multi-step operations like iterating through Exchange calendar arrays or mutating Message IDs is no longer accurate.

Legacy native plugin actions are essentially stateless REST wrappers; they choke on complex Graph API arrays because they lack an internal state machine. However, routing everything through a classic Power Automate Cloud Flow introduces unnecessary licensing overhead and breaks the native generative orchestration loop. The actual bottleneck is attempting to force an LLM to blindly manage rigid JSON payloads across multiple turns without a dedicated data-handling layer.

For a definitive native workaround to orchestrate multi-step Outlook operations, using the Copilot Studio Workflows designer to construct deterministic logic loops will completely decouple the process from the stateless limitations of legacy single-turn plugin actions.

Leverage Native Workflows: Bypass standalone Power Automate. The Workflows canvas directly inside Copilot Studio natively exposes standard M365 Outlook connectors alongside deterministic logic blocks (Variables, Loops, Switch cases).

Isolate Object IDs: Use native variables within the Workflow to explicitly extract and store the physical MessageId or EventId returned from your initial search node.

Chain the Execution: Pass that explicitly stored ID into subsequent nodes (like a Flag Email action) to physically prevent the LLM from hallucinating API parameters.

How are you handling the pagination tokens (@odata.nextLink) when querying Outlook schedules, or are you just hard-capping the Graph array fetch size to prevent the runtime from timing out?