COPILOT IN EXCEL · GET DATA SKILL
Build a cleanup process you can use again
If you keep handing Copilot the same monthly cleanup job, it may be time to ask it for something you can reuse. That's what caught my attention about the Get Data skill and its connection to Power Query.
If you've spent much time preparing monthly reports in Excel, you probably know the routine: import another export, fix the dates, remove a few unwanted rows, bring in some lookup columns, and finally get the data into shape for a PivotTable. By the time the next file arrives, you get to enjoy the whole experience again.
Asking Copilot to handle that cleanup sounds like a reasonable improvement, and it certainly can help. But if I'm going to explain the process, check the results, and correct the inevitable misunderstanding about an account code, I'd like to have something to show for that work next month. Ideally, something more dependable than "please remember what we did last time."
That's why I'm interested in Get Data, a built-in Copilot skill in Excel. In Microsoft's announcement and demonstration, you describe the data you need, where it comes from, and how you want it shaped, and Copilot helps build the Power Query queries to do that work. For anyone who has been wondering how to turn an AI conversation into an actual reporting process, that connection is worth a closer look.
Availability: Microsoft's October 12, 2026 announcement listed a mid-October rollout of Get Data through Excel for the web. Availability may vary.
GET DATA brings in and transforms data.
CLEAN DATA identifies potential issues in data you already have and recommends corrections.
What is a Copilot skill?
Before getting into Power Query, it helps to be clear about what Microsoft means by a skill. A prompt is the request you give Copilot for the job in front of you, while a skill packages reusable instructions and supporting information for a particular kind of task. Microsoft provides built-in skills such as Get Data, and you can also create custom ones, as its documentation on skills in Excel explains.
You still give Copilot a prompt when you use a skill, because it needs to know which files you're working with and what you want done this time. The skill supplies guidance for doing that kind of work without requiring you to explain the entire approach from scratch. I think of the prompt as the assignment and the skill as the playbook.
01 · PROMPT
The assignment
"Import this month's sales file and keep account codes as text" tells Copilot what you need for this particular job.
02 · SKILL
The playbook
A skill gives Copilot reusable guidance for a type of task, such as bringing in and shaping data with Get Data.
03 · QUERY
The saved steps
A Power Query query holds the actual transformation logic that you can inspect, keep, and refresh.
The part I wouldn't gloss over is that a skill still guides a generative AI model. Having a better playbook can make the work more consistent, but the model still has to interpret and apply it. When you want the reviewed transformation logic to run again, the saved Power Query query is the part that makes that possible.
Get Data is also different from Skill Builder, which helps you create custom skills. Here, we're using an existing built-in skill to help prepare data.
Power Query saves the preparation steps as a query, so refreshing it applies those steps to the source data again. That repeatable transformation process is one of its core benefits, as Microsoft's Power Query overview describes. It means your conversation with Copilot can leave you with a working process in the workbook, ready for the next compatible export.
Your monthly report doesn't need creative differences
The word generative is doing a lot of work in "generative AI," and it's easy to lose sight of that when the tool is sitting inside something as familiar as Excel. When Copilot figures out a cleanup process, it generates a response and may choose actions or write code to carry it out. Asking again can produce another interpretation; Microsoft explicitly notes that the same prompt can produce different responses.
I like that flexibility when I'm exploring unfamiliar data and want help thinking through a few approaches. I'm considerably less excited about it when the assignment is to apply reporting rules we've already agreed on, because three interesting interpretations of which sales records count can make for a very uninteresting meeting with your manager.
RANDBETWEEN() in business casual?
You probably wouldn't put RANDBETWEEN() in charge of deciding which transactions survive the monthly cleanup, but "ask Copilot again and trust whatever comes back" can leave you with a similar lack of control over the process. At least this version explains its decisions politely and offers to make you a chart.
I'm using that comparison to make a point about reproducibility, not to suggest that Copilot literally calculates your results with a random number function. It can run exact formulas and code; the concern is asking it to generate a fresh implementation of your business rules every time you need the report.
Consider a request to "remove duplicate invoices." That might sound clear enough until you remember that an invoice can contain several product lines: keeping one row per invoice number and keeping one row per invoice-and-line combination are very different decisions. If the generated cleanup logic changes between runs, you could lose valid transactions and change the report total without changing the source file, which is quite a plot twist for a Tuesday morning.
This is why saving a prompt doesn't freeze the implementation. A skill gives Copilot more guidance to work with, but the model can still interpret that guidance and generate the steps. Giving your instructions a permanent home is useful; it doesn't, on its own, guarantee that the same operations will happen every time.
With a reviewed Power Query query, you can see which columns it keeps, which data types it assigns, which rows it excludes, and how it joins tables. Those decisions are recorded as steps, with the underlying logic expressed in Power Query's M language, so a refresh reruns the saved implementation. Microsoft explains how Power Query stores and applies those transformations.
| What you reuse | What happens next |
|---|---|
| A prompt Your request for a task |
Copilot interprets and carries out the request in the current context. |
| A skill Reusable task guidance |
Copilot applies that guidance to the current job; AI judgment can still be involved. |
| A Power Query query Saved transformation logic |
Refresh runs the defined steps against the source data. |
What appeals to me about Get Data is that Copilot can help you work out the process and build the query, then Power Query can handle the recurring preparation after you've reviewed it. You can use the same approach with formulas or scripts that Copilot helps create: once you have something that works and you've checked it, keep that implementation and reuse it.
If you've followed my writing on this for a while, you'll recognize the argument from my earlier post on Copilot and routine reporting. I was already banging this drum then, with my usual subtlety:
Copilot in Excel is NOT for routine reporting! 🙅
In my Copilot for Excel workshops, people ask this all the time. "How do I make Copilot remember my prompts for routine reports?"
Bad idea to even try, my friend….
That's because Copilot is amazing for ad hoc analysis:… pic.twitter.com/LpF8ZFiwqJ
— George Mount (@gjmount) October 23, 2025
My October 2025 reminder about relying on repeated prompts for routine reports.
Get Data gives that earlier argument an interesting update, because Copilot can now help build the repeatable process we're looking for. The recurring run can then use the saved, reviewed logic, which makes "run this query" a much more concrete request than "do whatever you did last month, please."
PUT THE BUSINESS RULES IN THE REQUEST
Give Copilot more than "clean this."
"Bring in this month's sales export. Keep account codes as text, standardize the dates, retain all transactions, join the account reference table, and flag unmatched codes. Build a Power Query query I can review and refresh."
For your own version, spell out the actual files, date conventions, and matching keys so Copilot has the business rules it needs.
What "deterministic" means here
When I call a workflow deterministic here, I mean that explicit rules applied to the same inputs under the same settings should produce the same transformation results. The query doesn't need an AI model to have another think about what "clean up the dates" meant; it runs the steps you've saved.
Of course, next month's results should change when next month's data changes. What you want to keep consistent is the preparation logic, so you can explain the difference in the report by looking at the data and any deliberate changes to the process.
That still takes some care when you build the query. Using the current date introduces a changing input, and you can't assume an earlier sort will survive every later operation: Microsoft specifically flags grouping, merging, and removing duplicates in its guidance on common Power Query issues. If the rule is "keep the latest record," define how that record gets selected rather than relying on whichever row happens to appear first.
REPEATABLE DOESN'T AUTOMATICALLY MEAN RIGHT
A repeatable process still needs checking
Power Query will quite happily apply a bad rule every month if that's what you've told it to do. The benefit is that you have concrete logic to inspect and test, so you can find the problem and correct the process.
Three workflows worth giving a refresh button
To make this a little more concrete, here are three familiar Power Query workflows from examples I've written about on this site. They're useful patterns to have in mind when working with Get Data, although what the skill can build for you will depend on its supported sources and your Excel environment.
01 · APPEND
Combine recurring exports into one reporting table
Suppose two departments send sales exports with matching columns, and you're responsible for turning them into one reporting table each month. Power Query can connect to both sources, standardize the columns and data types, and append the rows, leaving you with a query you can refresh when the next files arrive.
My example of appending two CSV files happens to use baseball data, but there's nothing especially baseball-specific about the operation. It works just as well for departmental exports or separate transaction lists, provided you've set up the source connections appropriately.
What I'd check: Before any intentional filtering or deduplication, the combined row count should equal the sum of the source row counts. It's a straightforward way to confirm that all the records made it into the combined table.
02 · UNPIVOT
Reshape a report so it works for analysis
One of the recurring frustrations with Excel is that a spreadsheet can be perfectly convenient to read and surprisingly awkward to analyze. If each product category has its own sales column, for example, the measure you want to summarize is scattered across several fields before you even get to the PivotTable.
That's the problem I work through in my post on storing data for analysis, where Power Query unpivots those category columns into Category and Sales fields. The same idea works for a budget with January through December across the top: you can turn it into fields such as Department, Month, and Amount, then reuse that preparation for the next compatible export.
What I'd check: Make sure the intended categories or periods are included and that the totals reconcile. A table can look much tidier while quietly leaving something out, so appearance alone isn't much of a test.
03 · MERGE
Add reference information and keep exceptions visible
Transaction exports often give you codes when what you really need are descriptions, whether those are country IDs, department numbers, product codes, or account numbers. Power Query can merge in a reference table to supply that information, but how you join the tables determines which records survive.
In my comparison of left outer and inner joins, a sales record has a country ID that isn't in the reference table. A left outer join keeps the sale and leaves the country name missing, while an inner join drops the sale entirely. Both operations run successfully, but they answer different questions.
If your report is supposed to retain every transaction, that's a good reason to specify a left join and flag unmatched codes for review. It's also a good example of a decision I would want saved in the query, rather than left for Copilot to reconsider next month.
What I'd check: Look at the unmatched codes and confirm that the reference keys are unique, since multiple matches can multiply transaction rows. Getting a description into every row is only helpful if you haven't accidentally doubled the sales along the way.
Make the next run easier to trust
Across all three examples, the instructions that matter most are the business rules. "Clean the data" leaves Copilot with quite a few decisions to make, whereas "keep every transaction, preserve account codes as text, and flag unmatched accounts" tells it much more about what a successful result should look like.
And yes, this does mean knowing enough about your data to recognize a bad rule when you see one. I may have mentioned that before, possibly five times in a single post:
AI won't fix bad Excel habits
AI won't fix bad Excel habits
AI won't fix bad Excel habits
AI won't fix bad Excel habits
AI won't fix bad Excel pic.twitter.com/oj2g3zijX4— George Mount (@gjmount) October 24, 2025
A recurring theme: AI won't fix bad Excel habits.
Before relying on a new query, I'd run it against another representative file and compare row counts and totals, inspect the missing matches, and check a few records where I already know what should happen. A successful refresh tells you the query ran, but these checks tell you much more about whether it did the work you intended.
I still see plenty of value in talking through unfamiliar data with Copilot and asking it to suggest approaches. Once you've settled on the rules for recurring preparation, though, a saved query gives you something you can maintain, explain to a colleague, and run again without reopening the whole conversation.
That's what makes the Get Data skill interesting to me: it can help you get through the initial setup while leaving behind a process you can inspect and refresh. The monthly export will probably find some new way to keep you entertained anyway, so your cleanup rules don't need to bring their own surprises.
PUT THIS TO WORK WITH YOUR TEAM
Let's make your recurring Excel work easier.
If your team keeps repeating the same Excel cleanup or is trying to figure out where Copilot belongs in its reporting process, that's the kind of work I help with. We can work through the business rules, build a refreshable workflow, and make sure people know how to check the results so they're comfortable using it again.