Power BI: CSV folder connectors vs single-file pitfalls

In Power BI and Power Query, a CSV import can mean two very different things.

It can mean:

• one file is the dataset
• or
• a folder full of files is the dataset

Those are not the same operational model.

A single-file Text/CSV import says:

• this exact file is the source
• parse it
• type it
• model it

A folder connector says:

• the folder is a file system view
• each file is one candidate input
• Power Query should combine them into one logical table

That second model is much more powerful. It is also much easier to get wrong.

If you want the practical tooling side first, start with the CSV Validator, CSV Format Checker, and CSV Delimiter Checker. For recurring feeds, the CSV Splitter, CSV Merge, and the CSV tools hub are natural companions.

This guide explains when the folder connector is the right choice, when the Text/CSV connector is safer, and which Power Query behaviors quietly create brittle pipelines.

Why this topic matters

Teams search for this topic when they need to:

• combine monthly or daily CSV drops in Power BI
• choose between connecting to one file or a whole folder
• understand why a folder-based combine broke after a new file arrived
• stop schema drift from breaking refreshes
• debug Power Query’s example-file transformations
• reduce manual “replace file every month” workflows
• avoid hidden sample-file assumptions in Power BI refreshes
• turn ad hoc file imports into something repeatable

This matters because the wrong connector choice creates the wrong mental model.

If one file is authoritative but you use a folder connector, you may accidentally combine:

• extra files
• outdated files
• temp files
• differently shaped files
• subfolder files you did not mean to include

If a folder is the real recurring dataset but you hard-wire a single file, you may end up:

• replacing paths manually
• rebuilding queries each cycle
• trusting type inference from one historical sample
• or missing new files entirely

So the first decision is not technical. It is conceptual:

Is the dataset one file, or is the dataset the folder?

Start with the Power Query contract

Microsoft’s docs for the Text/CSV connector show the single-file model clearly: you select a local file, Power Query opens a navigator preview, and then you either load it or transform it. citeturn324745view2

Microsoft’s docs for the Folder connector show the other model: you connect to a folder and Power Query returns a file-system-style table of files, including metadata and the Content binary for each file. From there you can combine or transform. citeturn392534search5turn324745view1

Those are fundamentally different starting points.

Text/CSV

Best when:

• one file matters
• you want a direct preview of that file
• the path is stable
• refresh semantics revolve around that one file

Folder

Best when:

• many files share one schema
• the folder is a recurring landing zone
• new files arrive over time
• you want one combined logical table

A lot of Power BI pain comes from picking one model while the data actually behaves like the other.

The folder connector only works cleanly when the schema is really shared

Microsoft’s combine-files docs say the feature is useful when files in a folder have the same schema, and the specific CSV article says it is imperative that the files all have the same structure and the same extension. citeturn324745view1turn324745view0

That is the first real pitfall.

Teams often treat “same kind of report” as if it means “same schema.” It does not.

Files may differ by:

• extra columns
• reordered columns
• missing columns
• extra header rows
• different delimiters
• changed file encodings
• different summary footer lines

A folder connector assumes you are combining like with like. If the upstream process does not guarantee that, refreshes become fragile. citeturn324745view1turn324745view0

The biggest hidden behavior: combine logic is built from an example file

This is the folder-connector behavior most teams underappreciate.

Microsoft’s combine-files overview says Power Query analyzes the example file, which by default is the first file in the list, and uses it to determine the correct file connector and build the extraction logic. The combined-files output then includes:

• an example query
• a function query parameterized by binary input
• application of that function to every file in the folder list. citeturn324745view1turn324745view3

The CSV-specific combine docs say the same thing: the example file defaults to the first file, and Power Query automatically detects what connector to use based on that first file. citeturn324745view0

This creates a very practical risk:

one atypical first file can define the transform for every file.

If the first file:

• has an extra blank row
• uses a different delimiter
• has a different preamble
• has a different header offset
• has a one-off encoding quirk

then the generated sample query may be wrong for the rest of the folder. citeturn324745view0turn324745view1turn324745view3

That is why folder-based combines sometimes “suddenly” break after a new file becomes alphabetically first.

Example-file queries are powerful, but they can hide coupling

Microsoft’s Power BI Desktop combine-binaries docs say the combine transform creates:

• an example query that extracts data from a single file
• a function query parameterized with binary input
• application of that function to each binary in the original folder query citeturn324745view3

This is useful because:

• edits to the sample query propagate to all files
• you only build the logic once

It is dangerous because:

• the whole folder pipeline is now coupled to one sample-file logic path
• hidden assumptions in that sample query affect every refresh

So when debugging folder combines, always inspect:

• the base folder query
• the sample-file transform query
• the generated function
• the expanded combined table

A lot of “Power BI broke my CSV folder import” issues are really “the sample-file transform drifted away from the rest of the folder.”

Filtering early is not optional in folder workflows

Microsoft’s combine-files overview explicitly says it is good practice to filter the file-system view to show only the files you need to combine, such as by Extension or Folder Path. The CSV combine article also says selecting Combine directly is recommended only when you are certain the folder contains only the files you want. Power Query best-practices docs broadly recommend filtering early as a general rule. citeturn324745view1turn324745view0turn392534search4

This is one of the most important operational lessons in the whole topic.

A folder is rarely as clean as people think. It may contain:

• archived files
• test exports
• .txt variants
• temp files
• hidden output from another process
• subfolder content
• files with old schema versions

If you do not filter the folder list explicitly, your combine logic is doing dataset design by directory accident. citeturn324745view1turn324745view0turn392534search4

Single-file imports are simpler, but they have their own traps

The Text/CSV connector is easier to reason about because the scope is one file. That simplicity is real.

But single-file flows still have pitfalls:

• delimiter inference may be wrong
• file origin or encoding may be wrong
• types may be inferred badly
• users may think replacing the file contents is equivalent to a managed recurring feed

Microsoft’s Text/CSV docs say Power Query treats CSV as structured files with comma as a delimiter, while plain text files are inspected to infer whether they are delimiter-separated. The same docs also note that file origin matters and character set should not be assumed blindly. citeturn324745view2

So the single-file connector is safer when one file is the truth, but it is not magically schema-safe. It still needs explicit parsing and type review.

Power BI service CSV import is not the same thing as a folder-based Power Query pattern

Microsoft’s Power BI service docs for CSV say you can import a CSV file up to 1 GB, preview it, and create a semantic model or report. The same page says files stored in OneDrive can synchronize with Power BI about every hour. citeturn324745view4

That is important because some teams confuse:

• service-side CSV file import with
• a Power Query folder connector pattern in Desktop or a dataflow

These are different operational models.

Service CSV import

Good for:

• one file
• lighter-weight ingestion
• sync with OneDrive or SharePoint file replacement

Folder + combine in Power Query

Good for:

• recurring multi-file feeds
• month-by-month drops
• file-system-based ingestion logic
• transform reuse across many files

A lot of brittle pipelines come from trying to force one model into the other.

“Skip files with errors” is both useful and dangerous

Microsoft’s combine-files overview says the Combine Files dialog includes a Skip files with errors option. citeturn324745view1

That is helpful when:

• a recurring feed contains one damaged file
• you want refresh to continue
• the bad file can be triaged separately

It is dangerous when:

• skipped files are not monitored
• refresh success hides data loss
• the folder contract is already drifting
• the broken file was actually the month users care about

A good rule is:

Never enable skip-on-error without also logging what got skipped

Otherwise you trade a visible refresh failure for a silent completeness problem.

Schema drift is where folder connectors become fragile

Microsoft’s docs do not market this as “schema drift” in the combine-files pages, but the behavior is clear: folder combine is designed for files with the same schema. If columns are added, removed, renamed, or reordered upstream, your sample-query logic and expand steps may stop matching cleanly. citeturn324745view1turn324745view0turn324745view3

That means folder combines are best for:

• controlled feeds
• fixed report templates
• disciplined landing zones

They are not ideal as a first reaction to:

• arbitrary user-uploaded CSV archives
• folders used as dumping grounds
• vendors that change export structure without notice

In those cases, you usually need:

• staging validation
• folder filtering
• schema checks before combine
• or a preprocessing step outside Power BI

The safest practical workflow

A good Power BI CSV workflow usually looks like this.

Use Text/CSV when:

• one file is authoritative
• you want to inspect delimiter and types directly
• the refresh story is tied to that file
• the file path or cloud location is stable

Use Folder when:

• the folder itself is the data contract
• files are same-schema recurring drops
• you need to combine a monthly/daily series into one table
• you are willing to maintain sample-query logic consciously

In both cases:

• validate delimiter and encoding explicitly
• lock type changes deliberately
• preserve original files
• avoid manual Excel “cleanup” before diagnosis
• document the feed contract

A practical checklist for folder connectors

Before you use Combine Files on a CSV folder, check:

1. Are all files intended for one logical table?
2. Do they truly share schema and extension?
3. Have you filtered out irrelevant files first?
4. Which file is acting as the example file?
5. Is the sample query making assumptions about header rows, skip rows, or delimiter?
6. Are you monitoring skipped files or errors?
7. Is there a plan for schema drift?

If you cannot answer those clearly, the folder connector is probably being asked to do ingestion design work it was not meant to solve.

Good examples

Example 1: monthly finance exports

Twelve monthly files arrive in one folder with identical header rows and columns.

Best fit:

• folder connector with explicit extension filtering
• reviewed sample-file query
• locked types after combine

Why:

• the folder is the dataset
• recurring structure is shared

Example 2: one operational export replaced weekly

A single customers.csv file in SharePoint is overwritten weekly.

Best fit:

• single-file Text/CSV import or service-side CSV model depending on the refresh pattern

Why:

• one file is authoritative
• folder logic adds unnecessary complexity

Example 3: messy shared folder

A folder contains:

• current CSV files
• old ZIPs
• manual test files
• one different schema version
• a README text file

Best fit:

• not blind combine
• first filter the folder query aggressively
• maybe validate upstream before Power BI

Why:

• the folder is not yet a reliable dataset boundary

Example 4: first file is atypical

Alphabetically first file contains an extra four-line preamble, but later files do not.

Risk:

• sample query learns the wrong header offset
• every other file is transformed incorrectly

Fix:

• pick the correct example file explicitly and stabilize the transform logic

Common anti-patterns

Using folder combine because “there are many files,” without defining the folder contract

This creates accidental datasets.

Letting the first file choose the transformation silently

Always inspect the example-file logic.

Treating skip-on-error as success

It may be hiding missing months or broken upstream feeds.

Not filtering the folder list before combine

Folder-based refreshes should not depend on directory luck.

Using Excel cleanup before Power Query diagnosis

That changes the artifact you are trying to understand.

Repeatedly swapping one file into a single-file query when the real source is a recurring folder

That is manual orchestration pretending to be a pipeline.

Which Elysiate tools fit this article best?

For this topic, the most natural supporting tools are:

• CSV Validator
• CSV Format Checker
• CSV Delimiter Checker
• CSV Header Checker
• CSV Row Checker
• CSV Splitter
• CSV Merge
• CSV tools hub

These fit naturally because Power BI file connectors only behave predictably when the underlying CSV structure and file-set contract are already under control.

FAQ

When should I use the folder connector instead of Text/CSV in Power BI?

Use the folder connector when the folder contains a repeating series of files with the same schema and you want one logical table across them. Use Text/CSV when one specific file is the source of truth. Microsoft’s docs explicitly describe combine-files as a same-schema pattern. citeturn324745view1turn324745view0

Why do folder-based combines break so often?

Because combine logic is derived from an example file and then applied to every file, so schema drift, extra files, or an atypical first file can distort the transform. Microsoft documents that the example file defaults to the first file and that the combine output is driven by a sample-file query and generated function. citeturn324745view1turn324745view0turn324745view3

Is skipping files with errors a good idea?

Only if you also monitor what was skipped. It can keep refreshes alive, but it can also hide upstream data quality failures. Microsoft’s combine-files dialog explicitly offers the option, so teams need a policy around it. citeturn324745view1

Why is filtering the folder list so important?

Because Microsoft’s docs explicitly recommend filtering the file-system view to include only the files you need, and the Combine button is recommended only when you are certain the folder contains only the files you want. citeturn324745view1turn324745view0turn392534search4

Is Power BI service CSV import the same as a folder connector workflow?

No. Service CSV import is a one-file model, while folder connectors are a Power Query pattern for combining many files. The Power BI service docs also say OneDrive-backed files can sync about every hour, which is a different operational model from folder-based combine logic. citeturn324745view4

What is the safest default?

Filter the folder early, lock delimiter and type choices explicitly, inspect the example-file query, and treat the folder as a controlled data contract rather than a dumping ground.

Final takeaway

Power BI folder connectors and single-file CSV imports solve different problems.

The safest baseline is:

• use Text/CSV when one file is the truth
• use Folder when the folder is the truth
• assume folder combines are only as stable as their sample-file logic and schema discipline
• filter early
• review the example query
• treat skipped files and schema drift as first-class operational concerns

That is how you keep Power BI CSV ingestion from looking simple on day one and brittle by month three.