Data Pipeline: linkedService name changes to GUIDs inflate Git diffs

[davadrl]

Hi all,

I've noticed that Microsoft Fabric is now replacing the linkedService.name property in pipeline-content.json with randomly generated GUIDs — even though previously I used defined, consistent names for Lakehouse and Warehouse connections in my Data Pipelines.

Here’s a simplified example:

Before:

"linkedService": {
  "name": "lakehousename",
  "properties": {
    "type": "Lakehouse",
    "typeProperties": {
      "workspaceId": "@pipeline().libraryVariables.workspaceId",
      "artifactId": "@pipeline().libraryVariables.lakehouseId",
      "rootFolder": "Tables"
    }
  }
}

Now:

"linkedService": {
  "name": "cc7e4456_6230_4e46_9986_ab7c206ded89",
  "properties": {
    "type": "Lakehouse",
    "typeProperties": {
      "workspaceId": "@pipeline().libraryVariables.workspaceId",
      "artifactId": "@pipeline().libraryVariables.lakehouseId",
      "rootFolder": "Tables"
    }
  }
}

The main issue is that the name is now a random GUID — and it changes every time I make even a small change to the pipeline, even if the linked service itself has not been touched.

This leads to the following problems:

• Large and unnecessary diffs in Git

• Confusion during code reviews, since it appears as if unrelated changes have occurred

• Reduced maintainability and traceability

Potential issues in multi-environment deployments, as the GUID does not exist consistently across branches

Technically, the pipeline still works because the workspaceId and artifactId are correctly set via variables. However, the constantly changing identifiers in the name field make the code harder to understand and maintain.

Questions:

• Is this the new intended behavior?

• If so, is there a way to disable or configure it?

• Will Microsoft consider reverting to the previous behavior where defined linkedService.name values are preserved?

Thank you in advance. I would appreciate any insights or confirmation from others experiencing the same issue.

[rajeshgumpena]

In Fabric, Manage connections and gateways assigns GUIDs to connections. In migration/resolution files, you map logical linked service names to these GUIDs (via "LinkedServiceToConnectionId"). Microsoft Learn notes:

“The value is the GUID of the Fabric connection you want to map to. You can find the GUID in settings of the Fabric connection.”

This suggests that connections are identified internally by GUIDs, so the "name" field in pipeline JSON is tied to that identifier.

Conclusion: It seems intentional that Fabric replaces friendly linkedService.name values with GUIDs to ensure consistency with the internal registry and support environment mapping. While this may cause noisy Git diffs, it doesn’t affect runtime since identity is managed separately. Currently, I haven’t seen any documented way to disable this behavior or preserve custom names.

[v-karpurapud]

Hi @davadrl 

Thank you for highlighting the issue of linkedService.name values being replaced with system-generated GUIDs within Fabric pipelines.

 This behavior is currently by design, as Fabric treats linked services as inline definitions rather than reusable named assets. While it does not impact pipeline execution because connections are resolved through workspaceId and artifactId, it creates challenges for developers, including inflated Git diffs, reduced readability during code reviews, and difficulties in maintaining consistency across environments. We recognize the impact this has on development workflows, and your suggestion to preserve user-defined names or introduce a reference-based model for linked services would significantly improve maintainability and developer experience. We encourage you to submit this feedback on the Microsoft Fabric Ideas portalFabric Ideas - Microsoft Fabric Community, to help bring visibility to the product team.

I hope this information is helpful. . If you have any further questions, please let us know. we can assist you further.

Regards,

Microsoft Fabric Community Support Team.

[v-karpurapud]

Hi @davadrl 

Can you please confirm whether you have raised it in Ideas forum, Please note that Microsoft regularly reviews ideas shared by the community, and your suggestion may be considered for future updates.

Thank you once again, and we encourage you to continue engaging with the Microsoft Fabric Community.

Best regards,

Community Support Team.

[anilgavhane]

@davadrl 

Use a Resolutions File

Microsoft recommends using a resolutions.json file to map your original linked service names to Fabric connection GUIDs. This helps maintain consistency across environments.

Example structure:

[ { "type": "LinkedServiceToConnectionId", "key": "lakehousename", "value": "cc7e4456_6230_4e46_9986_ab7c206ded89" } ]

You can find the GUID in the Fabric connection settings. This mapping ensures your pipeline logic remains stable even if the internal GUID changes.

More details: Microsoft Learn – Add Connections to Resolutions File

Can You Disable GUIDs?

No, there’s currently no supported way to disable or override GUID generation in pipeline-content.json. Microsoft has not announced plans to revert to the previous behavior.

✅ Best Practices

• Use resolution files for all linked services.
• Avoid editing pipeline-content.json manually—let Fabric manage it and use external mapping for clarity.
• Document your mappings in Git to aid reviewers.
• Raise feedback via Microsoft Fabric Community or support channels if this behavior impacts your workflow.

Let me know if you’d like help generating a resolution file or scripting the mappings for your pipelines.