user data function with source control behavior

[hvdbunte]

Hi,
I am using a user data function in a workspace with git integration. We have the following senario: 

- I made a feature branch from main with source control > branch out to workspace

- in the feature branch I created a new UDF with a connection to the lakehouse in the feature branch. And queried some data from the lakehouse in the feature branch.

- Published the udf.

- with source control I committed the udf to git.

- created a pull request to merge into the main branch

- update the main branch from source control.

When I check the main branch I get the following issue:

There is a commit for the UDF. That’s something I didn’t expect. Other items don’t need to commit back in the main branch.

Does anybody know why this is happening? Is it because the connection change needs to be committed? from feature branch connection to main branch connection of my lakehouse?

I hope somebody can explain the behavior, if more information is needed please let me know

Kind regards,

[v-prasare]

Hi @hvdbunte ,

If your issue still persists, please consider raising a support ticket for further assistance.
To raise a support ticket for Fabric and Power BI, kindly follow the steps outlined in the following guide:

How to create a Fabric and Power BI Support ticket - Power BI | Microsoft Learn

Thanks,

Prashanth

[v-tejrama]

Hi @hvdbunte ,

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.

Thank you,

Tejaswi.

[hvdbunte]

Hi @v-tejrama 

We are still looking into this issue. We hope to resolve this maybe with library variables but are not sure yet if that will fix the issue. Otherwise we will start a support call with MS.

Thank you,

Hvdbunte

[v-tejrama]

Hi @hvdbunte ,

Thanks for the update. Please keep me posted on your findings with the library variables. Hopefully that resolves it, but starting a support call with MS sounds like a good next step if needed.

Thank you.

[v-prasare]

Hi @hvdbunte,

We would like to confirm if our community members answer helps resolve your query or if you need further help. your insights are truely valuable to community users,  If you still have any questions or need more support, please feel free to let us know.

@Mauro89 & @MJParikh ,Thanks for your prompt response

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[hvdbunte]

Hi @v-prasare ,

Thank you for the reply, I am still not sure if my last post is the solution that would be the solution or what would be a best practice for working with source control and User Data Functions. Could you confirm if this is the case or not?

Kind regards,

[hvdbunte]

Hi, @Mauro89 and @MJParikh

Hi,

Thank you both for the usefull and thorough responses.
@MJParikh  I agree with your reply but I did some further testing with the UDF connection. See below for details. Because I expected a silent rebind as you describe in your post and the names of the lakehouses are identical indeed.

@Mauro89  I also agree with your suggestion here, on other fabric items this is working but in my testing not with a UDF.

Because if I try to work with a UDF and connect to the lakehouse in DEV workspace in my feature branch, I followed below steps, I get an error, see screenshots.

So what I tried doing:

- I made a feature branch from main with source control > branch out to workspace

- in the feature branch I created a new UDF with a connection to the lakehouse in the dev workspace, that has the same name in dev and feature workspaces. And queried some data from the lakehouse in the dev workspace.

- Published the udf.

- with source control I committed the udf to git.

- created a pull request to merge into the main branch

- update the main branch from source control.

- I opened the UDF in main branch and ran my test. I still get a commit in main.

- commit the change to main branch with source control

I see a change in de definition.json, see below:

But the lakehouse in DEV has this ID (2ce75851-c895-49ea-87c6-32ed1b990e3a). The artifactId on the right side of the screenshot I cannot find in my workspace (DEV or feature).

- With a pull request I synchronized my feature branch with main.

- when I update the feature branch through source control. I get the below error message

So I’m still not sure what the best practices are for working with UDF’s and GIT.
For now I would suggest creating the connection to the feature branch and the binding will be correct. But for other Fabric items this is not the case.

I hope it is clear what I try to achieve. We are thinking of using UDF’s for error handling functions etc with multiple developers and are testing all fabric items and git integration. And this is some behaviour we didn’t expect.

Again thanks for your replies

Kind regards

[MJParikh]

You see a commit on main because the UDF’s connection binding changes when you switch from the feature branch lakehouse to the main branch lakehouse. That binding lives in the UDF’s serialized metadata in Git, so Fabric records a diff and asks for a commit. This is expected for items with external connections, while items without connections do not create this extra diff. Microsoft’s docs confirm UDFs store and version their connections, and lakehouses have tracked logical identifiers in Git. 

What to check

1. In the repo, inspect the PR or latest commit for the UDF folder. Look for a connections or settings file where only a connectionId or logicalGuid changed.

2. Confirm the lakehouse in the feature branch and main branch resolves to different workspace-scoped connection IDs, even if the display name matches.

Why this happens
• Connections are workspace scoped.
• Branching to a new workspace gives the lakehouse a different bound ID.
• When you update main, Fabric rebinds the UDF to main’s lakehouse connection and writes that change to Git, creating the commit.

Ways to avoid surprise commits
• Keep connection names consistent across branch workspaces and let Fabric rebind silently, then accept the one-time commit on main. Future cycles tend to be clean if bindings remain stable.
• If isolation is not required, avoid creating a separate lakehouse per feature branch. Use one lakehouse with the same logical guid across branches or move isolation to tables or folders.
• Make code-only changes in the feature branch, and create or rebind the connection only after merging into the main branch. This removes the connection diff from the feature PR.
• For stricter ALM, pair Git branches to separate workspaces and treat connection rebinding as a deliberate step in your pipeline. Document it in your branching guide.

[Mauro89]

Hi @hvdbunte,

in addition to the nice answer from @MJParikh I would like to add, that it best practice if you perform data operations in your feature branch to connect to your DEV workspace and only do code or schema changes in the feature branch. 
I also made the same experience with other Fabeic items and came to that conclusion. 

Best regards!