u/oartconsult

A handful of Copilot Studio builds come up again and again — bulk Excel operations, pulling data out of emails, document processing — and most people end up wiring them from scratch every time, because there's nowhere to just see how a working one is put together.

So I put 10 complete flows in one place: each with its full canvas, its node/variable/resource counts, and a step-by-step walkthrough of how it's built.

Each card is a complete build — node / variable / resource counts shown on every one.

The 10 builds:

1. Compact Excel Query — reads 50,000+ rows without choking
2. Full Excel CRUD Topic — read/add/update/delete across 100,000+ rows (88 nodes)
3. Excel Full CRUD Extended — a reusable, dynamic version you point at any file
4. Email Data Assistant — pulls structured data straight out of the inbox
5. Email Invoice Processing — extracts data from emailed invoices end-to-end
6. Multi-Purpose Document Processor — handles multiple document types in one flow
7. Hybrid Knowledge Assistant — retrieval across mixed sources (55 nodes)
8. Logistics Assistant — automates logistics request handling
9. Folder Structure Assistant — monitors and checks folder trees
10. Project Manager Assistant — automates project tracking

The point isn't the list — it's that each one shows the actual wiring: prompts, nodes, variables, the whole canvas. The bigger ones run 50–88 nodes, so the interesting parts are the bits that usually break — looping over large Excel ranges, capturing tool output as text so you can reuse it, handling the item-ID column that quietly poisons responses.

You can browse the whole collection and see how each was built — I'll drop the link in a comment.

Which of these is closest to what you're building right now? And what's the one agent you keep wishing someone had already figured out?

Checking every incoming order against a folder of frame agreements is the kind of work nobody enjoys — right vendor? still valid? quantity and price within contract? So I built a Copilot Studio agent that handles it end to end. Sharing the two tricks that made it actually reliable, because they reuse far beyond purchase agreements.

What it does: you drop a frame agreement into a SharePoint folder (scanned PDF, image, crooked phone photo — doesn't matter). It OCRs the doc, extracts every line item into a clean Excel register, decides per item whether to create / update / skip so no duplicates pile up, files the original into a processed or error folder, and monitors incoming emails to warn the purchasing team when an order breaks the contract.

Trick 1 — feed the OCR coordinates to the model, not just the text. In the "Recognize text in an image or document" action, I append each line's top/left bounding-box coordinates alongside the text. Now the model knows where things sit on the page and reconstructs the layout instead of guessing from a flat wall of text. Extraction on messy scans got dramatically better. Works for invoices, forms, any structured doc.

Trick 2 — a composite key for update-vs-create. Excel rows have no stable ID, so I generate one: vendor + "-" + item ID. Add it as the first column, set it as the key column in Update Row. The prompt then outputs an operation field per item — create if the combo's new, update if it exists with newer validity dates, no if unchanged/older. The agent reads the current table first (List Rows in an agent flow), then acts.

Wiring, briefly:

• Power Automate triggers on file creation → OCR → hands the agent the text+coordinates and original file ID
• Agent: generative orchestration on, web/general knowledge off, GPT-4o (4.1 in Part 2). Tools: Add/Update/List Rows, Move File ×2, Get/Send Email
• A counter loop with INDEX() writes each line item to Excel (one agreement = multiple items)
• Turn on pagination in List Rows (transfer up to 10,000) so it can read big tables
• Email monitoring: trigger passes the message ID → Get Email → compare against the register → if mismatch, send a warning email

Demo: dropped 5 scanned agreements, re-dropped with edited dates to show the update logic skip/refresh correctly, then emailed an order for 526 m³ at €97 against a 500 m³ contract — got back an automatic warning naming the exact mismatch.

Full step-by-step build in the first comment. How are you handling update-vs-duplicate on Excel/SharePoint tables — composite keys like this, or something cleaner?

Plain-text answers look fine in a demo and terrible in real use — a wall of text with no hierarchy, hard to scan in Teams or a web canvas. The usual fix is worse: hand-building Adaptive Card JSON for every answer shape, which breaks the moment the content changes.

So instead of designing cards, I let the AI design them.

What the flow does:

• Sits at the very end of an existing hybrid knowledge assistant — nothing upstream changes
• A single prompt action takes the user's question and the compiled answer, and returns only the body array of a valid Adaptive Card 1.4 as raw JSON
• The AI decides the layout from the content — a price list becomes a table, a comparison becomes columns, automatically
• A parseJSON() formula drops that into the Adaptive Card field of a message node, and it renders

You write the formatting rules once in the prompt. You never design another card.

Live demo in the video (against a fictional product knowledge base):

1. "Three cheapest products on stock" → clean numbered card
2. "Full description + technical data for the cheapest one" → headings, spec section, use-case list
3. "Compare the two cheapest, with price and stock" → comparison table
4. Same prompt, three different layouts — zero manual design

I'm sharing the full flow on a flospect canvas — the prompt action, the exact model instructions, the parseJSON formula, the message node setup. Read it, copy it, bolt it onto your own assistant.

Flow + video link in the comments.

How are you handling visual output today — hand-built Adaptive Card JSON, plain text, something else?

One thing I keep running into when delivering Copilot Studio flows to clients: they ask "what will this cost to run?" and I don't have a clean answer.

Microsoft's pricing depends on too many variables at once — message credits per conversation, Pay-As-You-Go vs capacity pack, which actions consume AI Builder credits vs Copilot credits, conversation volume, whether generative orchestration is on. And the licensing model is changing fast enough that any estimate risks being outdated within months.

I usually end up with a rough projection based on expected volume and a list of assumptions. That's not good enough when a client needs to budget properly.

I'm considering adding a cost calculator tab to flospect — map your flow's components and get an estimated monthly cost based on current Microsoft pricing. But before building it, I want to know if something like this already exists or if others have a reliable method they use.

• Do you estimate costs before deployment, and if so how?
• Is there a tool or spreadsheet already doing this that I've missed?
• How do you handle the cost question with clients or stakeholders?

Genuinely asking before investing time into building something that might already exist in a better form.

A lot of the data we need to track lives in our inbox first — invoices, requests, confirmations — and someone always has to open the email and copy the details into a spreadsheet by hand. When one project update lists eight action items with owners and deadlines, that's eight rows typed out one at a time.

So I built an agent that handles it the moment the email arrives.

Here's what it actually does:

• Triggers on a new email — Power Automate passes only the message ID to the agent, keeping the prompt clean
• Pulls the full email inside the topic — sender, subject, body, received time — with a Get Email tool
• A GPT-5 reasoning prompt extracts the fields you care about and returns them as JSON arrays, so one email can produce many rows instead of just one
• Counts the items, loops through them, and writes each one as its own row in an online Excel table
• Swap the prompt's "what to extract" line and the same flow works for invoices, project tasks, customer requests — whatever your emails carry

Live demo in the video:

1. A test email lands in the agent's mailbox with financial data in the body — monthly financial summary example
2. The agent triggers on its own, retrieves the email, and extracts the values the AI judges relevant
3. The online Excel table fills in live — sender, received time, subject, and each extracted data point and value as its own row
4. Multiple clean rows from a single email, no manual entry

The full topic is in my flospect library — same link as always, this build has been added. Every node, prompt, variable, and the array formula. Read it, copy it, rebuild it in your own environment.

Video + sharing link in comments.

What's the most repetitive email-to-data process your team is still doing by hand? Curious what others have run into.

A few weeks ago I asked here whether a Copilot Studio solution-zip importer would be useful, or if it was just my problem. Thanks to everyone who replied — it shaped what I built first.

The itch: once an agent's built, handing it over cleanly — to a client or another team — is harder than building it. There's no native way to show someone the full picture (topics, agent flows, connected Power Automate flows, and the logic between them) without giving them environment access or writing it all up by hand.

So I built it — and the interesting part wasn't reading the files, it was what's not in the export. An unmanaged solution .zip gives you the topics, agent flows and connected Power Automate flows as separate config files, but no picture of how it actually runs: what connects to what, what's grouped, which flow calls which. That has to be reconstructed. What surprised me most — subflows I hadn't selected still had to come in, because other parts referenced them. Leave them out and the picture breaks.

Where it landed: drop the .zip in, pick what you want, and it lays the agent out on a readable canvas — nodes grouped by function, with variables, prompts and resources pulled into their own tables (I build this in flospect). Test scenarios and docs then generate off the actual structure. I recorded the full walkthrough end to end — link's in the first comment if it's useful to see it in motion.

For anyone who does handovers — do you reconstruct the logic by hand, do a screen-share walkthrough, or just hand over access and hope? Trying to understand what the real process looks like today.

A while back I shared a single Copilot Studio topic that does full read, add, update, and delete on a 100K+ row online Excel file. It worked, but the document library, file name, and table were hard-coded — it only ever worked on that one file, and it wasn't wrapped as a tool.

So I made it fully dynamic:

• Swapped the hard-coded file/library/table for global variables
• Wrapped the topic as a reusable tool with five inputs (document library, file, table, SharePoint location, user request) and one output for the final response
• Now I call it with "Go to another topic," pass in any online Excel file, and reuse it without rebuilding

The gotcha that cost me the most time:

Once the inputs to "List rows present in a table" were global variables, I couldn't just store the action's table output in a variable inside the topic — it wouldn't catch. The fix: add a Set text variable node, define a new variable, and feed the Excel tool's output into it. It stores correctly as text, and then you can pass it to the prompt downstream. Had to do this in both spots where I use List rows. That one node was the whole unlock.

Smaller fix: the list action returns an item internal ID that isn't a real column, and the agent kept referencing it. One line in both prompts — don't use the item internal ID for any purpose — cleaned it up.

Demo adds 10 new rows by copying data from 10 existing records one by one, with the Excel file updating live.

Video + flospect sharing link (full canvas: nodes, prompts, variables, formulas) in comments.

Anyone else hit the List rows output issue once their inputs went dynamic?

Most document processing setups handle one type of document. You build a fixed extraction template for invoices and it works — until someone sends an order confirmation, a contract, or a multi-page PDF instead. Then it falls apart.

So I built a single flow that handles all of them. The extraction logic is AI-driven and configurable, so the same architecture works for whatever document type arrives in the email.

Here's what it actually does:

• Triggers when an email with attachments lands in a dedicated folder — multiple attachments in one email are all processed in the same run
• Loops through every attachment, runs OCR on each one, and captures both the text content and the bounding box coordinates — so the AI knows not just what the text says but where it sits on the page
• Passes the full OCR output to a prompt action that extracts the data you define — invoice fields, contract terms, order details, anything — and returns it as a structured JSON array
• Loops through the extracted data and writes each row to an online Excel table
• Moves the processed email to a designated folder when done

The key design decision: the OCR captures coordinates alongside text. Most people skip this — but without knowing where text sits on the page, the AI can't reliably distinguish a "total amount" from a "subtotal" or a "vendor address" from a "billing address" when they're visually separated but textually similar.

Live demo with five attachments in one email: one PNG, one JPEG, a single-page PDF, a multi-page PDF, and one more for good measure. All processed in one run. Excel table populated with filename, data type, and value for every field extracted.

The extraction prompt is the only thing you change to adapt this to a different document type. Everything else stays identical.

Full walkthrough in the comments.

What's the most painful document type your team is still processing manually — and what makes it hard to automate?

Curious how others approach this.

When a request comes in for "an agent that does X," how much do you actually evaluate before opening Copilot Studio? I find myself increasingly wanting to slow down and look at things like:

• Is this the right use case to automate, or is the underlying process too broken?
• Are the data sources actually where we think they are?
• Will the right people be available to test and approve at handover?
• Are there governance or compliance issues that should shape the design from day one?

The honest answer for most builds I've seen (mine included) is "we just started building." Then halfway through, the data isn't where we thought, or the stakeholder can't articulate what success looks like, or compliance flags something that needs a rework.

What do you do?

• Any structured pre-build check, even informal?
• If you're delivering for clients, is this part of your engagement?
• For internal builds, does anyone gate Copilot Studio projects with a readiness review?
• Or just dive in and adjust as you go, on the theory that you learn faster by building?

Genuinely curious about both sides. There's a real case that overthinking the start kills momentum. There's also a case that we're shipping a lot of Copilot Studio agents that probably shouldn't have been built the way they were.

What's your experience been?

Most Copilot Studio tutorials show you one happy-path demo in isolation. You see the agent work once, cleanly, with perfect input. What you don't see is what happens when the input is incomplete, the data is missing, or the file has 50,000 rows.

I built five agents across five completely different business problems and put every single one in one video — with live demos showing real input, the process running, and the actual output. Including what happens when things go wrong.

Here's what's in it:

1. Email invoice processor with OCR Emails arrive with invoice attachments — PDFs, PNGs, multi-page documents. The agent reads them, extracts the fields, validates completeness, registers clean invoices to an Excel table, and routes anything with missing data to an error folder. Zero manual input.

2. Hybrid knowledge assistant One question that needs two different sources to answer — a descriptive catalogue and a live data table. The agent decides which source to query, loops through both if needed, and compiles one complete answer. Falls back to web search for questions outside both sources.

3. Logistics assistant with external API Incomplete delivery request — no address, no dimensions, nothing. The agent figures out what's missing, searches the web for what it can find itself, builds a JSON payload, and calls an external shipping API via HTTP. Returns real carrier options with prices and delivery times.

4. SharePoint folder structure monitor Runs on a schedule every morning. Reads a SharePoint library, detects misplaced files and subfolders in the wrong location, and emails a structured report with a prioritised to-do list. No manual checks needed.

5. Large Excel data handler — 50,000+ rows Natural language query against an Excel file with 50,000+ rows. Uses OData filters to pull only the exact rows needed — no loading the whole file. Tested on a comparison between a row near the beginning and one near the very end of a 50,000-row dataset.

Five different architectures, five different trigger types, five different real-world outcomes.

Full walkthrough in the comments.

Which of these would solve something your team is still doing manually? Or what would a sixth agent on this list look like?

One of the most common questions I see in Power Platform: how do you call a third-party system that doesn't have a native connector — and how do you handle the case where the user hasn't given you all the required parameters upfront?

Most setups either hardcode the missing values, ask the user for everything at once, or just fail. None of those work in practice.

So I built a Copilot Studio agent that solves both problems in one architecture.

Here's what it actually does:

• Takes an incomplete natural language request and figures out what's missing before making any API call
• Runs a reasoning loop driven by a single prompt action that decides the next step every iteration: ask the user, search the web, build the payload, deliver the answer, or stop
• Fills missing parameters automatically using web search — if the user gives vague input, the agent finds the data itself instead of asking
• Builds a structured JSON payload from everything collected and sends it via HTTP request to an external API — with auth headers, content type, and body configured correctly
• Handles empty or error responses from the API gracefully and routes accordingly

The architecture — one controlling topic, one prompt driving all decisions, one accumulating variable — is the reusable pattern here. The logistics use case is just the demo. The same setup works for any external system: pricing APIs, ERP endpoints, custom internal services, anything with an HTTP interface.

Three live demos in the video showing the full loop from a vague input to a real API response with carrier options, prices, and delivery times.

Full walkthrough in the comments.

What external APIs or third-party endpoints have you needed to connect to from Power Platform without a native connector? Curious what others are building.

Most Copilot Studio agents only use Microsoft tools — query Excel, read SharePoint, send an email. The moment you need to call an external third-party system via HTTP, most setups fall apart fast.

So I built a logistics assistant that shows exactly how to do it — including the messiest part: the user never gives you all the data upfront.

Here's what it actually does:

• Takes an incomplete request — "get me a delivery price from Chicago to New York" — and figures out what's missing before making any API call
• Runs a decision loop driven by a single prompt action that decides the next step every iteration: ask the user, search the web, call the API, answer, or stop
• Searches the web automatically for missing details — if the user says "it's just a shoebox," the agent finds the dimensions itself instead of asking
• Builds a structured JSON payload and sends it via HTTP request to an external shipping API with proper auth headers
• Returns real carrier options with prices and delivery times

The architecture is one topic acting as a controller, one prompt making every routing decision, one variable accumulating everything — original request, follow-up answers, web results — so the agent gets smarter with every loop.

The main point of this build is the HTTP pattern: once you can call one external API this way, you can call any of them. The logistics use case is the demo — the same architecture applies to any third-party system your business connects to.

Three live demos in the video showing the full loop from vague input to real API response.

The full flow is in my flospect library — same link as always, this build has been added. Every node, prompt, variable, and HTTP setup. Ready to view and rebuild in your own environment.

Video walkthrough + library link in the comments.

What external APIs or third-party systems have you needed to connect to from Copilot Studio? Curious what others are trying to integrate.

Every time I finish a Copilot Studio build, I hit the same uncomfortable moment: how do I properly validate this works across all the scenarios it's going to face in production?

The happy path is easy. But edge cases, ambiguous inputs, error handling, boundary conditions — those are the things that break at the worst possible moment.

Most approaches I've seen fall into one of three buckets:

• A spreadsheet with test cases that nobody keeps updated
• Clicking around in the test chat and hoping for the best
• No structured testing at all — just shipping and monitoring what breaks

None of those feel right for anything running in a real environment.

Curious what others are doing — do you have a systematic approach to testing before go-live, or is it still mostly informal?

I've been building Copilot Studio flows for clients for a while, and one thing keeps coming up: once a flow is built, handing it over cleanly is harder than building it.

There's no native way to share a complete picture of an agent with a client or internal team — what topics are inside, how the logic is structured, what flows are connected — without giving them access to your environment or spending hours writing it up manually. And inside organisations, cataloguing what's been built across projects and teams has the same problem.

I built two videos about this earlier, video links in the comments.

So I built a Copilot Studio solution zip importer for flospect. Here's what it would do:

You export your agent from Microsoft 365 as a zip and drop it into flospect. It reads the contents — topics, agent flows, Power Automate flows — and lets you select what to import. AI then generates a visual canvas from the structure: nodes grouped, logic labelled, everything readable. You can configure the audience, layout direction, and verbosity level before generating. From there you can share it with clients or stakeholders, build test protocols, and generate documentation — all without exposing your environment or credentials.

The feature is technically ready. But before I release it, I genuinely want to know: would you use a zip importer like this? What would you use it for — client handover, internal cataloguing, something else? And is there anything you'd want it to do that isn't described above?

Most invoice processing setups I've seen rely on someone opening each email, reading the attachment, and typing the data manually into a system. At volume that becomes a part-time job.

So I built a flow that handles all of it automatically — from the moment an email lands in a dedicated folder to the moment the structured data is extracted and registered.

Here's what it actually does:

• Triggers when a new email arrives in a "To Process" folder — only processes emails with attachments, ignores everything else
• Loops through all attachments in a single email — one email can contain multiple invoices
• Saves each attachment to SharePoint, runs OCR text recognition, and stores the output as a structured text file including bounding box coordinates so the AI understands where data sits on the page
• Passes only the file path to the Copilot Studio agent — not the full OCR text — to avoid overloading the prompt
• AI extracts the fields: invoice number, vendor, customer, invoice date, due date, amount, currency
• Validates completeness — if any required field is missing, the attachment routes to an error folder instead of passing silently
• Registers the extracted data to a data table — in my example an online Excel file, but the same logic applies to any structured data target you connect to
• Moves the original email to a processed folder when done

Five attachments in the live demo: one PNG, one JPEG, a 2-page PDF, a 5-page PDF, and one file with a missing field on purpose to show the error routing. Four clean rows registered, one file in the error folder.

One licence note: the "Recognize text in image or document" action in Power Automate requires a Power Automate Premium licence. Worth checking before you build.

The full flow is in my flospect library — same link as always, this build has been added. Every node, prompt, variable, and formula. Ready to view and rebuild in your own environment.

Video walkthrough + library link in the comments.

What's the most repetitive document process your team is still handling manually? Curious what others are dealing with.

One thing I've learned delivering Copilot Studio agents: if the underlying SharePoint folder structure is inconsistent, the agent inherits the problem. Files in the wrong folder, subfolders under the wrong parent, naming that doesn't follow any convention — it causes misrouting, wrong data retrieval, and hard-to-debug failures.

The root cause is simple: colleagues move fast, nobody monitors the structure, and the mess compounds quietly over time.

So I built a Copilot Studio agent that checks the folder structure daily and sends a report. It's a straightforward build — one of the simpler ones I've done — but it solves a real operational problem.

Here's what it does:

• Recurrence trigger runs every morning at 8 AM automatically
• Get Files Properties tool pulls file and folder metadata from a SharePoint library
• AI prompt analyses the structure and detects misplaced files, wrong subfolder placement, and naming inconsistencies
• Generates a structured report with a prioritised to-do list — file path, issue type, created by, where it needs to move
• Flags items that need manual review where metadata alone isn't enough to decide
• Sends the full report by email before the working day starts

Full flow is in my flospect library — same link as always, this build has been added. Video walkthrough + library link in the comments.

What does your current folder governance look like — manual checks, nothing, or something automated?

Copilot Studio has a zip export, but it's essentially a deployment package. You can move it between environments, but you can't read it, present it, or hand it to someone who wasn't involved in building it.

Which means every time I need to show a client or a manager how an agent actually works — the logic, the decision branches, the prompts, the variables — I'm either recording a screen walkthrough, taking screenshots, or rebuilding the explanation from scratch in a separate document.

None of those scale.

Curious what others do here. If you could export a Copilot Studio agent into a genuinely useful format — not just a deployment package — what would that look like for you?

A visual flow diagram? A structured document with the prompt logic included? Something you could hand to a non-technical stakeholder and have them understand it? Or is this a problem most people just accept and work around?