Forum Discussion
Data Mapping Flow with DataLake as Sink
Hello everyone,
I am currently trying to read data from a source as changelog and writing it into a merged DataLake table. So basically cdc connector logic but as for SHIR the connector is not supported.
I always get the issue:
Operation on target merge_lakehouse_landing_to_delta failed: {"StatusCode":"DFExecutorUserError","Message":"Job failed due to reason: com.microsoft.dataflow.Issues: DF-SRC-002 - 'tableName' (Table Name) is required - \naction sink(\n) ~> sinkName,EXE-0001,Dataflow cannot be analyzed as a graph,[564 737]","Details":""}
I use scriptLines to transform the lines inside the dataflow and if I provide json File as sink the pipeline runs without errors at least. If I provide a lakehouse table even if I hardcode the table name in the dataset I get this error (already recreated it so an old version of the dataset cannot be the issue).
Why is that so can I not merge the data directly into lakehouse or is there another issue I've overseen why lakehouse doesn't work as sink here?
Thank you in advance
Lara
Hi Lara, based on the error, the issue appears to be with the Lakehouse sink configuration rather than the source or CDC logic itself. The key part is DF-SRC-002 - 'tableName' (Table Name) is required and action sink(), which usually means the generated sink definition does not have a valid table name bound at runtime.
In Dataflow Gen2 / Fabric destinations, the destination must be configured against a valid tabular query and mapped to a supported destination table. Microsoft documentation also notes that each query can have its own data destination, and destinations apply to tabular queries only. For Fabric Warehouse, Microsoft specifically points to using the Azure Synapse Analytics SQL DW connector with the SQL connection string.
If your target is a Lakehouse table and you are trying to do a true CDC-style merge/upsert directly from the dataflow, I would not rely on the dataflow sink for the merge logic. A safer pattern is to first land the changelog data into a staging Lakehouse table or files area, then run a Fabric Notebook or Spark SQL step to perform the MERGE INTO operation against the Delta table. That gives you more control over insert/update/delete handling and avoids the sink trying to infer or generate the target table incorrectly.
Also check whether the destination table is under a custom schema or referenced as schema.table. There are community reports where Dataflow Gen2 could see schema-based Lakehouse tables but failed at runtime, because the destination UI expects a table name and may assume the default dbo behavior rather than fully supporting schema-qualified names in that scenario.
So I would suggest testing this flow:
- Write the changelog output to a staging Lakehouse table or file first.
- Use a Notebook/Spark SQL activity for the Delta merge into the final table.
- Avoid schema-qualified target names in the dataflow sink during testing.
- Recreate the sink destination from the UI instead of relying only on scriptLines, to confirm that the table name is actually being persisted.
If JSON/file sink works but Lakehouse table sink fails, that strongly points to the Lakehouse destination metadata/table binding rather than the transformation logic itself.
Hi Lara,
The error you're seeing is actually coming from the Data Flow analysis stage rather than the MERGE operation itself:
DF-SRC-002 - 'tableName' (Table Name) is required
This usually means the sink transformation never receives a valid physical table name. Even if the dataset contains a table name, Mapping Data Flows expect the sink metadata to resolve to an actual Lakehouse table during graph compilation.
A few things I'd verify:
Ensure the sink is configured as a Lakehouse Table, not just a Lakehouse location/files path.
Open the sink transformation and confirm the Table property is populated there. If you're generating the sink via scriptLines, check that the generated script still contains the tableName property—it's easy for it to be omitted when editing the script manually.
If you're parameterizing the table name, verify the parameter has a value at debug/runtime. An empty parameter often produces exactly this error.
Try creating a brand-new Mapping Data Flow with a single source and a single Lakehouse table sink (no MERGE logic, no script edits). If that also fails, it's likely a dataset or Fabric limitation rather than your CDC logic.
If the simple flow succeeds, compare the generated data flow script with your scripted version. I'd expect the missing tableName definition to be the key difference.
One additional point: if your goal is CDC-style upserts into a Delta table, Mapping Data Flows can write to Delta/Lakehouse tables, but MERGE support depends on the specific Fabric/Data Factory capabilities you're using. In some cases, teams stage the changes into a Delta table first and then execute a Delta MERGE INTO (Notebook or SQL) as a second pipeline step. That approach is often more reliable and easier to troubleshoot.
Could you also share:
The sink portion of your Data Flow script (especially the sink(...) definition).
Whether the table name is hardcoded or parameterized.
Whether you're targeting a Fabric Lakehouse Delta table or another type of Data Lake destination.
That will help identify whether this is a missing tableName property in the generated script or a limitation of the current sink implementation.
4 Replies
- v-aatheequeCommunity Support
Hi LaraHaegele
We wanted to follow up to check if you’ve had an opportunity to review the previous responses. If you require further assistance, please don’t hesitate to let us know.- v-aatheequeCommunity Support
Hi LaraHaegele
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.
- Prince0011Solution Sage
Hi Lara,
The error you're seeing is actually coming from the Data Flow analysis stage rather than the MERGE operation itself:
DF-SRC-002 - 'tableName' (Table Name) is required
This usually means the sink transformation never receives a valid physical table name. Even if the dataset contains a table name, Mapping Data Flows expect the sink metadata to resolve to an actual Lakehouse table during graph compilation.
A few things I'd verify:
Ensure the sink is configured as a Lakehouse Table, not just a Lakehouse location/files path.
Open the sink transformation and confirm the Table property is populated there. If you're generating the sink via scriptLines, check that the generated script still contains the tableName property—it's easy for it to be omitted when editing the script manually.
If you're parameterizing the table name, verify the parameter has a value at debug/runtime. An empty parameter often produces exactly this error.
Try creating a brand-new Mapping Data Flow with a single source and a single Lakehouse table sink (no MERGE logic, no script edits). If that also fails, it's likely a dataset or Fabric limitation rather than your CDC logic.
If the simple flow succeeds, compare the generated data flow script with your scripted version. I'd expect the missing tableName definition to be the key difference.
One additional point: if your goal is CDC-style upserts into a Delta table, Mapping Data Flows can write to Delta/Lakehouse tables, but MERGE support depends on the specific Fabric/Data Factory capabilities you're using. In some cases, teams stage the changes into a Delta table first and then execute a Delta MERGE INTO (Notebook or SQL) as a second pipeline step. That approach is often more reliable and easier to troubleshoot.
Could you also share:
The sink portion of your Data Flow script (especially the sink(...) definition).
Whether the table name is hardcoded or parameterized.
Whether you're targeting a Fabric Lakehouse Delta table or another type of Data Lake destination.
That will help identify whether this is a missing tableName property in the generated script or a limitation of the current sink implementation.
- sannavajjalaResolver II
Hi Lara, based on the error, the issue appears to be with the Lakehouse sink configuration rather than the source or CDC logic itself. The key part is DF-SRC-002 - 'tableName' (Table Name) is required and action sink(), which usually means the generated sink definition does not have a valid table name bound at runtime.
In Dataflow Gen2 / Fabric destinations, the destination must be configured against a valid tabular query and mapped to a supported destination table. Microsoft documentation also notes that each query can have its own data destination, and destinations apply to tabular queries only. For Fabric Warehouse, Microsoft specifically points to using the Azure Synapse Analytics SQL DW connector with the SQL connection string.
If your target is a Lakehouse table and you are trying to do a true CDC-style merge/upsert directly from the dataflow, I would not rely on the dataflow sink for the merge logic. A safer pattern is to first land the changelog data into a staging Lakehouse table or files area, then run a Fabric Notebook or Spark SQL step to perform the MERGE INTO operation against the Delta table. That gives you more control over insert/update/delete handling and avoids the sink trying to infer or generate the target table incorrectly.
Also check whether the destination table is under a custom schema or referenced as schema.table. There are community reports where Dataflow Gen2 could see schema-based Lakehouse tables but failed at runtime, because the destination UI expects a table name and may assume the default dbo behavior rather than fully supporting schema-qualified names in that scenario.
So I would suggest testing this flow:
- Write the changelog output to a staging Lakehouse table or file first.
- Use a Notebook/Spark SQL activity for the Delta merge into the final table.
- Avoid schema-qualified target names in the dataflow sink during testing.
- Recreate the sink destination from the UI instead of relying only on scriptLines, to confirm that the table name is actually being persisted.
If JSON/file sink works but Lakehouse table sink fails, that strongly points to the Lakehouse destination metadata/table binding rather than the transformation logic itself.