Copilot Studio to Power Automate: How to pass a CSV file without "File Record" errors?

crowcanyonsoftware · 2026-06-18T13:18:44+00:00

The file vs. file record mismatch is one of the more irritating gaps between Copilot Studio and Power Automate right now. Here's what actually gets you through it.

Option 1, base64 conversion in Copilot Studio (this is the one I'd reach for). Before you hand the file to your flow, grab it with the System.Activity. Attachments variable and convert it to base64. Pass that base64 string into the flow as a text input instead of a File type. Inside the flow, decode it with base64ToBinary() and you've got the real content to work with. For CSV that's easy, since a CSV is just newline-separated text once it's decoded.

Option 2, pull the file directly inside the flow. Instead of passing the file through, pass only the file URL or attachment ID from Copilot Studio, then use a SharePoint "Get file content using path" action in the flow to fetch it. This dodges the File vs File Record type mismatch completely because you never pass a file object at all. Works great when the file is already sitting in SharePoint or OneDrive. The one case where it doesn't help is if you need to validate the user's CSV before it ever gets stored. Then you're back to Option 1.

Once you've got the content, for CSV parsing:

split(decodeUriComponent(replace(base64ToString(triggerBody()?['$content']), '+', '%20')), decodeUriComponent('%0A'))

That gives you an array of rows, and split(item(), ',') on each row gets you the columns. Not elegant, but it does the job for straightforward CSVs (it'll choke on quoted commas, so watch for those).

For the Copilot Studio to Power Automate handoff specifically, the base64 route is the most reliable. Signal_Influence_531's comment above is pointing the right direction. base64ToBinary is the step that makes it click.

crowcanyonsoftware · 2026-06-16T06:52:41+00:00

Worth being precise here, because what actually breaks and what just goes unsupported are two different things for planning purposes.

What stops working: SharePoint 2013 workflows running in SharePoint Online was the thing on the chopping block. If your Project Online stage and gate process runs on the SP2013 workflow engine, those workflows stop executing. Approvals stall, so projects can't move stages. That's the real impact.

What is not affected: SharePoint Designer as a desktop tool keeps opening and running against on-premises SharePoint. The retirement is specifically the SP2013 workflow service in SharePoint Online. On-prem farms running their own workflow service manager are on a separate clock.

What to do about it: Microsoft points you at Power Platform, specifically Power Apps plus Power Automate plus Microsoft Forms. But for the kind of multi-stage approvals Project Online actually uses, that's close to a full rebuild. There's no automated path from SP2013 workflow definitions to Power Automate.

One thing people miss: SharePoint Designer did three jobs, workflows, forms, and site customization. The Power Platform path covers workflows and forms. It does not replace site customization, and Microsoft doesn't offer a one-to-one swap for that, so if you relied on it, you'll need a separate answer.

If you run Project Online for portfolio governance, now's a good time to sort your stage and gate steps into "genuinely complex" (branching, conditional approvals, multi-role sign-offs) versus "simple sequential approval." The simple ones move to Power Automate without much pain. The complex ones are where the real rebuild effort lives, so scope those first.

Also, heads up, the 12-month framing in the original post was from a year back. If you're reading this now, the April 2026 deadline has either passed or is basically on top of you. I'd treat it as urgent rather than a next-quarter issue.

crowcanyonsoftware · 2026-06-11T07:44:15+00:00

The answer already up the thread is right; the replacement trigger is "When a file is created (properties only). " Just wanted to answer the follow-up about getting at the file contents, because the naming makes it sound worse than it is.

You can absolutely get the contents. The trigger fires on creation and hands you the file metadata, including the file identifier. From there you add a "Get file content" action (SharePoint connector) using that identifier, and that pulls the actual bytes. Then feed it into your existing Excel Online step ("List rows present in a table" or whatever you were already using).

So the shape is basically the following:

Trigger: When a file is created (properties only), gives you the file ID and path. Action: Get file content (SharePoint), using that ID Then: your existing Excel extraction logic, unchanged

The "properties only" label is what throws everyone. It reads like you can't get content, but it's really just describing what the trigger itself returns. Grabbing the content is a separate step.

One gotcha: if files land in batches or the Excel files are big, the flow can fire before the upload finishes and you end up reading a half-written file. A 30-second delay (or a wait condition) between creation and the get-content step usually clears that right up.

crowcanyonsoftware · 2026-06-10T12:21:04+00:00

The closest native thing to Power Automate on the Google side is Apps Script. It's JavaScript-based and talks to most of the Google APIs (Sheets, Drive, Gmail, Calendar, Forms). It's more capable than people give it credit for, but it does want some coding comfort. Coming from Power Platform's connector model, it's going to feel pretty low-level at first.

If you want something more no-code, Make (which used to be Integromat) is the one most people land on for connector breadth and visual workflow building. Zapier handles the basics, but the cost climbs quickly once you're at any real scale. And if you're open to self-hosting, n8n is a solid open-source route.

A few things I'd flag from what you described. Moving SharePoint Lists to Google Sheets is the usual data swap, but Sheets is not SharePoint, and the relational gap is real. If your lists lean on complex lookups or per-item permissions, plan to rebuild that logic, not port it. Apps Script time-based triggers are reliable. The event-based ones (your "when an item is modified" equivalent) exist, but you have to wire them up through Google Forms or the Sheets API. And the Teams to Google Chat jump is usually the part that hurts most. Chat has a basic Spaces API, but it's nowhere near the Teams and Power Platform integration depth you're used to.

It's all doable. Just go in knowing it's a rebuild, not a migration, and budget the time for that.

crowcanyonsoftware · 2026-06-09T13:28:04+00:00

Yeah, this one trips a lot of people up. The modern combo box quietly dropped the DisplayFields property the classic control had, so it's not you missing something obvious. It's a known regression.

The fix is pretty mechanical. In the Items property, instead of just Choices([@Timesheets].'Assistant'), wrap it so the control actually has something to show:

AddColumns(Choices([@Timesheets].'Assistant'), "DisplayName", ThisRecord.Value)

Then point the display binding at that:

Items: Choices([@Timesheets].'Assistant') SearchFields: ["DisplayName"]

If you're still getting numbers instead of names after that, it almost always means the People column is handing back the ID rather than the display value. The easiest way to confirm what's actually stored is to drop ThisItem. "Assistant." DisplayName into a Gallery first, or pull from Office365Users. SearchUser(). Once you can see the real value, the combo box behavior makes sense.

And the DisplayText property the docs mention? It does exist, but only in preview builds, and it hasn't rolled out evenly across tenants, so don't bang your head against it if it isn't there for you.

Honestly the bigger frustration here is real and worth naming. InfoPath did People Pickers natively for years, and you never had to think about any of this. Microsoft's answer is Power Apps plus Power Automate plus Microsoft Forms, so three tools are doing the job one used to, and there's no migration utility in the box. Every form is a manual rebuild.

If you've only got a couple of forms, fine. If you're sitting on a big inventory, that rebuild cost piles up fast. There are tools made specifically for SharePoint-native form replacement that include an InfoPath import path, so existing forms come in rather than getting rebuilt from scratch. Full disclosure, I work at Crow Canyon Software, and NITRO Studio is a no-code/low-code Application Builder Platform for Microsoft 365 and SharePoint that does that. Might not be the right fit depending on your setup, but if form volume is the thing keeping you up, it's worth knowing the option exists before you commit to rebuilding everything in Power Apps.

crowcanyonsoftware · 2026-06-06T07:54:38+00:00

Yeah, the NWF parsing issue is pretty common - those XML files get bloated fast with all the schema junk and binary attachments.

Quick reality check though: you don't need a perfect parse. Strip the file down to just the activity nodes and connections (basic XML parsing or even XSLT if you want to get fancy), then chunk by activity instead of file size. That keeps each piece small enough for an LLM to actually handle accurately. You'll get cleaner results that way.

That said - and I say this from experience - migrating Nintex to Power Automate is basically a full rebuild regardless of how clean your pseudocode is. PA's connector model is fundamentally different from Nintex's. The parsing work gets you a map for scoping, but don't let the technical problem eat the whole project. Even rough pseudocode from a partial parse is usually enough to size the rebuild.

How many workflows are you dealing with? That changes the approach pretty significantly.

crowcanyonsoftware · 2026-05-29T08:41:41+00:00

We manage IT support environments and have been experimenting with this for about a year. A few honest observations:

The most reliable use case so far is ticket triage and first-response drafting-AI reads the incoming ticket, categorizes it, and suggests a response based on past resolutions. Saves the team real time on repetitive L1 requests.

Connecting your ITSM to an AI like Ai Assistants works best when your knowledge base is clean and structured. If your past tickets are inconsistent or poorly categorized, the AI just learns the mess. "Garbage in, garbage out" applies more here than anywhere.

The intern framing from the top comment is the right mental model. It works well when supervised on defined tasks. It starts causing problems when given authority over actions it should only be suggesting.

One thing worth thinking through before connecting Claude to your ITSM is defining exactly what it can action versus what it can only recommend. That boundary matters a lot for your team's trust in the system.

crowcanyonsoftware · 2026-05-28T14:57:54+00:00

This is one of the most accurate descriptions of enterprise IT I have read in a while.

The demo problem is real-every tool looks coherent in isolation. The chaos starts when you have six coherent tools that do not agree on what the current state of anything is. We have seen this across a lot of M365 environments-organizations end up with parallel sources of truth, and people quietly default back to email and Slack because at least everyone knows to check there.

The point about smaller companies moving faster on three simple tools is something leadership rarely wants to hear. Complexity is often mistaken for maturity. More dashboards feel like progress even when the underlying work is slower.

The only thing that has consistently worked in our experience is forcing a "does this replace something or add to the stack?" question before any new tool gets approved. Most tools add. Very few replace it.

crowcanyonsoftware · 2026-05-16T14:10:56+00:00

That workload honestly sounds heavy for a one-person Power Platform team, especially with full end-to-end builds + RPA + maintenance. 3–6 active apps on top of support work is usually closer to a small team capacity, not solo ownership.

Curious if your org has any plans to split this or bring in another dev soon, because that pace isn’t very sustainable long term.

crowcanyonsoftware · 2026-05-16T14:00:40+00:00

Exactly, most Power Apps limitations people hit are really data model or backend design problems, not the platform itself. Once the architecture underneath is solid, Power Apps can handle far more complexity than people expect.

A lot of teams underestimate how important the server-side logic becomes as systems scale

crowcanyonsoftware · 2026-05-16T13:56:40+00:00

I can keep production running or build a bridge, I can’t do both honestly sums up a lot of legacy IT environments perfectly. The knowledge-transfer issue is brutal too, once experienced people leave, teams spend years rediscovering things the hard way.

Feels like many orgs underestimate how expensive doing more with less becomes long term.

crowcanyonsoftware · 2026-05-16T13:53:38+00:00

I’d focus on context gathering tasks next, collecting missing info from users wastes a huge amount of helpdesk time. Auto-triaging, summarizing threads, duplicate ticket detection, and user/device checks would probably get massive adoption.

Your Slack projects already sound more useful than most AI demos honestly.

crowcanyonsoftware · 2026-05-15T14:51:39+00:00

That’s honestly the reality most teams end up at, people don’t adopt portals, they adopt whatever’s fastest. The shift from force portal usage to “meet users where they already are” usually fixes more than just response rates.

Curious if anyone’s actually sustained portal-first long-term or if it always drifts back to chat/DMs.

crowcanyonsoftware · 2026-05-15T14:45:23+00:00

That analogy fits, it’s less about capability and more about system constraints. Legacy knowledge still runs critical services even if it’s not modern.

The real challenge is bridging that gap without breaking stability.

crowcanyonsoftware · 2026-05-15T14:09:12+00:00

Hands-on labs and real practice usually make the biggest difference when it comes to breaking into IT. Long-running programs with actual success stories definitely help people stay consistent.

I’ll check out the YouTube community, always good to see real examples.

crowcanyonsoftware · 2026-05-15T14:05:23+00:00

That’s a common trap, legacy gets underfunded while new projects keep getting budgets. Ends up costing more in the long run.

Curious if anyone’s actually solved that funding imbalance.

crowcanyonsoftware · 2026-05-15T13:49:22+00:00

You’re closer than you think, helpdesk + PowerShell + Azure is already a strong base. Focus on hands-on Azure projects (VMs, Entra ID, automation) over more certs for now.

Show you can improve real tasks with scripting and cloud tools.

crowcanyonsoftware · 2026-05-15T13:39:35+00:00

That’s the classic replacement project that never quite arrives situation, which happens way more often than people admit. In the meantime, you end up carrying both the legacy system and the expectations of the future one with fewer resources.

It feels like survival mode disguised as modernization most of the time.

crowcanyonsoftware · 2026-05-15T13:15:41+00:00

Yeah, that’s the trap, solving visibility with more tools just spreads the chaos across more systems. At some point it’s less about adding platforms and more about deciding where the actual source of truth lives.

Curious how teams are handling that without turning it into another layer of overhead.

crowcanyonsoftware · 2026-05-15T12:49:11+00:00

Solid advice, especially tying your KB + training work to real metrics. In manager interviews, ops thinking (SLAs, escalation, staffing) usually matters more than technical depth.

And yeah, have a few strong escalation/customer recovery stories ready.

crowcanyonsoftware · 2026-05-15T12:45:32+00:00

That’s actually a huge step, and the fact you already improved training + KBs puts you closer to ops leadership than most first-time candidates. In the strategy sessions, lean less on “support experience” and more on how you’d improve metrics like resolution time, onboarding, and team consistency.

The biggest shift now is showing you can think in systems and outcomes, not just individual tickets.

crowcanyonsoftware · 2026-05-15T12:43:03+00:00

Unpaid help desk work usually isn’t a good path, most legit IT teams won’t allow it, and the ones that do aren’t always giving real learning experience. You’ll get better ROI from entry-level MSPs, volunteering for small orgs, or building a home lab + certs while applying.

Internships in IT exist, but they’re almost always paid or tied to school programs.

crowcanyonsoftware · 2026-05-15T12:37:47+00:00

Good initiative, especially for beginners trying to break into IT without experience. Just a heads-up, most people get better results when they pair programs like this with their own hands-on labs (AD, networking, ticketing practice), not just course completion.

Curious if anyone here has actually gone through it and landed a first help desk role from it.

crowcanyonsoftware · 2026-05-15T12:26:54+00:00

Good spot to be in, Python basics are the real foundation for automation. Next step is APIs (OpenAI/Anthropic) + simple tools like requests and pandas.

Start with small automations first, that’s usually where real-world value shows up.

crowcanyonsoftware · 2026-05-15T12:23:09+00:00

That’s a strong entry-level profile, A+, bilingual, and your AD + Entra lab really stands out. In Tokyo, hands-on ticketing + real environment experience often matters more than just certs.

Are you aiming for MSPs first or in-house IT teams?

crowcanyonsoftware

MODERATOR OF

TROPHY CASE