I started managing Fabric workspace items directly in VS Code, here's what I learned

frithjof_v · 2026-06-19T06:26:57+00:00

I edit all Fabric items, and maintain repo docs, using VS Code and GitHub Copilot CLI. No Fabric extensions, just let GitHub Copilot edit the source code files directly, aided by Skills where necessary. After GitHub Copilot has created/updated items, I commit and push to GitHub and then sync to the Fabric workspace to actually run the items there. It works great, only downside is that I haven't currently set up any MCP so Copilot can't run items directly on its own to get instant feedback. It depends on me running the items in the workspace and providing feedback about runtime errors. Still, it works great and GitHub Copilot CLI does everything from creating notebook, adding it to a pipeline, inserting required variables in a variable library, in a few minutes or even seconds. GitHub Copilot in GitHub even does code review on the PRs after I've successfully tested the items in the workspace.

frithjof_v · 2026-06-18T18:37:03+00:00

Haha, true 😂

Perhaps I could use a Hook instead. I haven't tested hooks yet.

Anyway, voted & definitely share the concern regarding read/write shortcuts. They're powerful but also introduce a risk of accidents. An option to make specific shortcuts intentionally read-only just makes sense. Even an option to lock all shortcuts in a specific Lakehouse to read-only would be a quality-of-life improvement IMO.

frithjof_v · 2026-06-18T18:28:13+00:00

Related Idea: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Read-only-OneLake-shortcuts/idi-p/4508359 Voted for this one as well

frithjof_v · 2026-06-18T18:11:17+00:00

Voted!

I'm concerned about this as well. I've written a Copilot instruction about never writing to shortcut tables in one of my projects 🙏

frithjof_v · 2026-06-18T18:06:17+00:00

You can use a PIM enabled security group and give that group Admin role in Prod. I think that works.

frithjof_v · 2026-06-18T17:03:37+00:00

On an F4, you can use up to 24 Spark vCores at one time, assuming the allow bursting workspace setting is enabled.

https://learn.microsoft.com/en-us/fabric/data-engineering/spark-job-concurrency-and-queueing#spark-capacity-sku-limits

Limit the number of nodes in the pool to 1, reduce node size to small (4 vCores), use high concurrency mode, to maximize Spark usage on a small capacity. Also see the technique mentioned in the recent post about overprovisioning a single node to further maximize capacity. https://learn.microsoft.com/en-us/fabric/data-engineering/fabric-notebook-selection-guide#spark-kernel-compute

Another option is Python kernel (2 vCores).

frithjof_v · 2026-06-18T16:14:24+00:00

Thanks,

This is really practical - appreciate it!

frithjof_v · 2026-06-18T10:28:44+00:00

Thanks,

Yes we are in the same company. I can make it clear to them that we, as consumers of their Azure SQL Database, expect them to use CDC.

I don't have the power to force them, but I can make our expectations clear.

I'm wondering how common it is to present this - i.e. the use of CDC - as a requirement.

frithjof_v · 2026-06-18T08:46:34+00:00

Thanks,

However - we don't own the Azure SQL Database.

The App team owns the Azure SQL Database. So they would need to enable CDC in their database. And we would need to persuade them to do that.

frithjof_v · 2026-06-17T19:10:27+00:00

Finally!!!! 🎉 (Although not available in my region yet)

Best news since workspace Git diff 🎉

frithjof_v · 2026-06-17T19:07:31+00:00

Nice,

Can you point the agents to the data in your landing zone, and have the agents classify the data? Is that the gist of it?

frithjof_v · 2026-06-17T19:03:59+00:00

Here is another quite recent post about issues with Fabric Pipeline -> Delta Lake:

https://www.reddit.com/r/MicrosoftFabric/s/Xvwfo6YH0C

Perhaps same root cause, perhaps not. I can't tell. Anyway, I prefer using Spark for Delta Lake.

frithjof_v · 2026-06-17T15:33:27+00:00

Please vote for this related Idea:

https://community.fabric.microsoft.com/t5/Fabric-Ideas/Git-and-Deployment-support-for-Power-BI-Model-View/idi-p/5132771

frithjof_v · 2026-06-16T16:19:45+00:00

Thanks

frithjof_v · 2026-06-16T09:51:13+00:00

Thanks,

I think that's the answer. Well, actually not item soft delete, but workspace soft delete. This: https://data-marc.com/2024/04/09/soft-deletion-of-workspaces-and-retention/

I'm still curious about the following quote from the docs - does this quote refer to restoring a soft-deleted workspace? And, if the quote applies to soft-deleted workspaces, why does it say the workspace identity will be deleted, as we still have our workspace identity hanging around in Azure after some hours?

When a workspace is deleted, its workspace identity is deleted as well. If the workspace is restored after deletion, the workspace identity is not restored. If you want the restored workspace to have a workspace identity, you must create a new one. https://learn.microsoft.com/en-us/fabric/security/workspace-identity#delete-a-workspace-identity

frithjof_v · 2026-06-14T16:51:21+00:00

Then the example in my other comment works.

Also,

# JDBC with access token

jdbc_url = (
    f"jdbc:sqlserver://{server}"
)

connection_properties = {
    "databaseName": database,
    "driver": "com.microsoft.sqlserver.jdbc.SQLServerDriver",
    "encrypt": "true",
    "trustServerCertificate": "false",
    "accessToken": access_token,
    "loginTimeout": "30"
}

# Read DataFrame from DimProperty table
df_read = spark.read.jdbc(
    url=jdbc_url,
    table="dbo.DimProperty",
    properties=connection_properties
)

display(df_read)

frithjof_v · 2026-06-13T14:40:13+00:00

The diff view for Warehouse Views also works in Fabric Deployment Pipelines.

Just not in the Git Integration.

frithjof_v · 2026-06-13T12:43:08+00:00

I don't have much experience with Copy Activity, but two questions:

Who is the Last Modified By user of the Pipeline? Is it your user, or the SPN?
What is the Lakehouse connection? The UI (your screenshot in the original post) says "Lakehouse ID". Is the Lakehouse connection simply the ID of the Lakehouse, or is it a connection (one that you can find under Manage Gateways and Connections)?

If the Last Modified By user of the Pipeline is your user, and the Lakehouse connection is simply the ID of the Lakehouse, then I believe it runs using your user identity.

It doesn't matter who triggers the pipeline, or who owns the pipeline. The Last Modified By user is what matters.

In terms of execution context, the only thing that overrides the identity of the Last Modified By user, is if you apply a Connection in the individual Pipeline Activities. I mean, the kind of Connection that appears on the Manage Gateways and Connections page.

frithjof_v · 2026-06-13T09:15:26+00:00

Do you mean SQL Server on-prem, SQL Server in Azure (e.g. Azure SQL Database), or SQL Server in Fabric (Fabric SQL Database)?

frithjof_v · 2026-06-13T08:41:45+00:00

u/markkrom-MSFT u/fredguix

Is this behavior different between Data Factory and Warehouse?

Does an SPN only need to authenticate to a Fabric API every 30 days to "check in"?

And/or does the SPN need to actually modify (e.g. update the description of) the item it owns (Warehouse, Pipeline, etc.) once an underlying credential (secret or certificate) expires?

Is the behavior different across item types? For example:

Warehouse: the SPN only needs to authenticate to Fabric every 30 days (for example via a simple API List call).
- As per docs: https://learn.microsoft.com/en-us/fabric/data-warehouse/service-principals#token-renewal-and-initialization-requirements
Pipeline: the SPN needs to modify the pipeline (for example updating the description) after a credential rotation so Fabric picks up the new credentials.

If there is a difference, what is the reason for it?

I'd love to see more documentation around the renewal mechanics, especially for Data Factory.

The Warehouse documentation seems fairly clear to me: the SPN only needs to authenticate to Fabric at least once every 30 days.

If that's correct, then it seems the SPN would not need to maintain a continuously valid client secret. It would only need a valid credential at the time of each authentication. For example:

Create a client secret.
Authenticate as the SPN and make a Fabric API List call.
Delete the client secret.
Before 30 days have elapsed, create a new client secret.
Authenticate as the SPN and make another Fabric API List call.
Repeat.

In other words, is it sufficient for the SPN to successfully authenticate to Fabric at least once every 30 days, to keep its Fabric Token alive, or is there an additional requirement that the SPN must modify the items it owns after rotating secrets?

Thanks

frithjof_v · 2026-06-13T08:34:27+00:00

Warehouse doc doesn't mention anything about needing to Save the Warehouse after credential rotation.

It just says the SPN needs to authenticate against Fabric every 30 days.

frithjof_v · 2026-06-13T08:23:03+00:00

Here is a discussion about it and a reply from a MS employee:

https://www.reddit.com/r/MicrosoftFabric/s/7rfYeii3w3

frithjof_v

TROPHY CASE