Show table names in outShow table names in outpuput for ForEach activity (Microsoft Fabric pipeline)

[SjoerdW]

Question:
I’m working with a pipeline in Microsoft Fabric where I use a ForEach activity to load multiple tables from a Lakehouse into a Warehouse.

Inside the ForEach, I use a Script activity that dynamically builds and executes SQL based on item().TableName. Functionally everything works fine.

However, in the pipeline run view I only see the same activity name repeated multiple times (e.g. Script2), without any indication of which table is being processed in each iteration.

My question:
Is there a way to make the table name visible per iteration in the pipeline run UI (for example in the activity list or overview)?

What I’ve already tried:

• Dynamic activity names (@{item().TableName}) → not supported
• PRINT / SELECT logging → only visible in activity output details
• Variables → not visible in the overview

Ideally, I would like to see:

• which table is being processed per iteration
• and which one failed (if applicable)

Am I missing something in Fabric pipelines, or is this currently not supported?

Thanks in advance!

[tayloramy]

Hi @SjoerdW, 

The way I would approach this is to use an "append variable" activity inside the for each loop that will append the table name to a variable, then you can access that variable outside of the loop. 

[Lodha_Jaydeep · Accepted solution]

Hi @SjoerdW,

Thanks for reaching community. will Happy to assist.

Dynamic activity names in ForEach are not supported in Fabric pipelines currently but there are workarounds to achieve visibility per iteration. Below are the possible work arounds to achieve this.

Workaround 1 - Use a  Set Variable Activity (Best for Tracking)

Add a Set Variable activity as the first step inside your ForEach, before the Script activity:

1. Create a pipeline variable: CurrentTableName (String type)
2. Inside ForEach, add Set Variable activity:
   • Name it something descriptive like Track_CurrentTable
   • Variable: CurrentTableName
   • Value: @item().TableName
3. Chain it → then your Script activity

Result: In the pipeline run view, the Set Variable activity output will show the table name in its input/output details, making it traceable per iteration.

Workaround 2 - Use Fail Activity for Failed Table Visibility

To see which table failed, add a Fail activity on the failure path of your Script activity:

This way the failure message in the pipeline run view explicitly shows the table name that caused the error.

ForEach
  └── Set Variable (CurrentTableName = @item().TableName)
  └── Script Activity
        ├── Success → (continue)
        └── Failure → Fail Activity
                       Message: @concat('Failed on table: ', item().TableName)
                       Error Code: 500

Workaround 3 - Append to a Log Variable (Full Audit) 

Create an Array variable ProcessedTables and append each table name as it processes:

1. Create pipeline variable: ProcessedTables (Array)
2. Inside ForEach, after Script activity add Append Variable:
   • Variable: ProcessedTables
   • Value: @concat(item().TableName, ' - Success')
3. After ForEach, add a Script activity or Set Variable to log the full array

// ProcessedTables output would look like:
["Table1 - Success", "Table2 - Success", "Table3 - Failed"]

Note: ForEach with batch count > 1 (parallel) can cause race conditions on Append Variable. Set batch count = 1 (sequential) if using this approach.

Workaround 4 - Write Logs to a Lakehouse Table

The most robust solution for production write iteration status directly to a log table. Truncate it first then insert So, you can have records for each pipeline run and not the olders.

-- In your Script activity, add this alongside your existing SQL:
INSERT INTO dbo.PipelineLog 
    (PipelineRunId, TableName, Status, StartTime)
VALUES 
    ('your-run-id', '@{item().TableName}', 'Processing', GETDATE())

 Then query this table anytime to see exactly which tables ran, succeeded, or failed with timestamps.

Fabric pipelines do not support dynamic activity names natively in the run UI this is a known limitation.

The Set Variable + Fail Activity combo (Workarounds 1 & 2 together) gives you the best visibility with minimal effort. For production pipelines, Workaround 4 (Lakehouse logging) is the most reliable long-term solution.

Please consider marking this as the Accepted Solution to help other community members find this fix more easily. If this helped you, Kudos are always appreciated!

[v-sshirivolu]

Hi @SjoerdW ,

I would like to take a moment to thank @Lodha_Jaydeep  , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
 

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions

[v-sshirivolu]

Hi @SjoerdW ,

I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you

[Lodha_Jaydeep]

Hi @SjoerdW,
Does the issue getting fixed or not? Feel free to reach out in case of any issues you are having will happy to assist.

@everyone just keep you heads For transparency, I used an AI tool to help structure my previous response, though I have personally verified all the steps and logic provided.
 

[deborshi_nag]

Hello @SjoerdW 

Your observation is correct, Fabric Data Factory doesn't give you a mechanism to make the TableName visible if you're doing it using a ForEach activity. 

Instead of using a Script activity inside ForEach, why don't you invoke a parameterised pipeline, that takes the TableName as an input parameter? The child pipeline can have the script that you're already using in your pipeline. This will give you the right monitoring visibility that you expect for each table.