How to summarize a Data Pipeline with Copilot in Fabric

João Barros 13 de July de 2026 4 min read

When a Data Pipeline in Microsoft Fabric grows to dozens of activities, understanding what it does — and why it failed overnight — can take longer than the fix itself. Summarizing a Data Pipeline with Copilot in Fabric removes most of that pain in seconds: Copilot reads the activities, the connections and the dependencies and returns a plain-language description. It is the fastest way to document an inherited pipeline and to understand a run error without opening every activity one by one.

Prerequisites

A Fabric workspace on a capacity where Copilot is available (F2 or higher, or P1 or higher).
Copilot enabled at tenant level by the Fabric administrator (the Copilot and Azure OpenAI Service setting in the admin portal).
An existing Data Pipeline with at least two or three activities (for example, a Copy data followed by a Notebook).
Edit permissions on the workspace (Contributor role or higher).

Step 1: Check that Copilot is available

Open the workspace in Fabric and go into your Data Pipeline. In the top bar of the pipeline editor, look for the Copilot button. If it is missing, the cause is almost always one of three: the administrator has not enabled Copilot at tenant level, the workspace sits on a capacity that does not support Copilot, or you are viewing the pipeline in read-only mode. Confirm this first — it saves time later.

Step 2: Open the Copilot pane in the pipeline

Click Copilot. A side pane opens with a chat box. Copilot's context is the pipeline you have open: it "sees" the activities, their names, the connections and the execution order. You do not need to paste anything — just ask.

Step 3: Ask for a summary of the pipeline

Write a clear request. The more specific the prompt, the more useful the answer. These three examples work well and can be used as they are:

Summarize this pipeline: what it does, in what order, and where the data comes from.

List the activities in execution order and show the dependencies (on success / on fail).

Explain in 5 bullets what this pipeline does, for someone who has never seen it.

The summary usually describes the sources, the destinations (Lakehouse, Warehouse, files) and how the activities are chained. Read it carefully: it is a good starting point, but validating it is still your job.

Step 4: Ask Copilot to explain an error

When a run fails, go to the Output tab (or to Monitor), open the details of the failed activity and copy the error message. Paste it into the Copilot pane with an explicit request:

Explain this error in plain language and list the most likely causes:

ErrorCode=SqlFailedToConnect ... (paste the full message here)

Copilot translates the error code, explains what usually triggers it and suggests where to look (credentials, firewall, server name, incompatible data type). It is especially useful with long, noisy messages.

Step 5: Explain dynamic content expressions

Inherited pipelines tend to hide non-obvious expressions in parameters and file names. Paste the expression into Copilot and ask for an explanation:

@concat('sales_', formatDateTime(utcnow(), 'yyyyMMdd'), '.parquet')

A request such as "Explain what this expression does and give an example of the value it produces today" returns a step-by-step reading of each function plus a concrete example. It is a quick way to understand naming conventions without running the pipeline.

Step 6: Save the summary as documentation

A summary that stays in the Copilot pane is lost as soon as you close the tab. Copy the text and paste it somewhere permanent: the item description (the pipeline Settings menu), the team wiki, or a Markdown file in the repository where you keep your code. Always add the date and the name of whoever validated it.

Verify the result

Compare the summary against the pipeline canvas on screen: do the activities it mentions actually exist? Is the order right? Do the sources and destinations carry their real names? If Copilot mentions an activity you cannot see on the canvas, discard that sentence — language models can get things wrong, and your summary is only worth something if it is true. A good final test: give the summary to a colleague who has never seen the pipeline and ask them what they think it does.

Conclusion

With Copilot in Fabric, documenting a Data Pipeline stops being a task you postpone forever and becomes a five-minute step at the end of every change. The natural next step is to apply the same method to the Notebooks and Dataflows Gen2 in the same workspace, until the whole solution is described. Tip: keep your best prompts in a shared team file — the difference between a useless summary and an excellent one is almost always the prompt. Which pipeline in your team can nobody explain today?