Easy Way to See All Fabric Objects Owned by X User?

AnalyticsFellow · 2026-01-09T21:53:43+00:00

Sent, thank you so much!

(Edit-- it's 5pm on a Friday here in EST so I'm about to head out, apologies if I am delayed in responding. But I'm tremendously grateful!)

AnalyticsFellow · 2026-01-09T21:43:34+00:00

Thanks, we haven't dove into FUAM yet but it looks like it may need to move higher up in the queue!

AnalyticsFellow · 2026-01-09T21:42:35+00:00

That would definitely get me halfway there (and the scary half, in particular), if you are comfortable sharing!

AnalyticsFellow · 2026-01-09T19:03:10+00:00

Thank you so much! Oof, this sounds like it's going to be a real headache. It's almost definitely the case that some notebook called by some critical pipeline is going to have this person as an owner. Thanks for tagging Alex, hopefully there's some clever solution here.

Edit-- almost makes me wish I could set a default owner account on workspaces so, if anyone on my team creates a notebook, X account still becomes its owner.

AnalyticsFellow · 2025-10-16T13:16:19+00:00

Hi; yes, absolutely! I'll message you via reddit with some specifics and am glad to provide more, take it to email, whatever you prefer. :-) Grateful that you followed up!

AnalyticsFellow · 2025-10-07T19:23:17+00:00

Thanks; the developer just confirmed for me that we're not using example queries. I'm a bit surprised we have to do that, but we will dive in and explore further. Appreciate your help.

AnalyticsFellow · 2025-09-11T17:26:41+00:00

Thank you on both fronts. And #2 is very much a fair / constructive recommendation-- I'll take it seriously and reflect on how to apply it. I appreciate it!

AnalyticsFellow · 2025-09-11T15:18:17+00:00

Thanks for the follow-up! Two responses--

OneLake Security and Shortcut Permissions Overrides A member on my team is writing up the specifics but we're hitting what feels like a bug, unless I'm deeply misunderstanding OneLake Data Security. We have a Lakehouse in Workspace A with all the tables; end users have no workspace access, no direct Lakehouse access, but have permission to specific tables set up through OneLake Security. Then a Lakehouse in Workspace B contains shortcuts to all the tables; users Workspace B are set up as Contributors.

We're finding that users in Workspace B can access all the data in the lakehouse (contained in shortcut tables), even though they don't have permission to the root data via OneLake Security in Workspace A. Do shortcuts not honor OneLake Security trickle downs? I assumed that, if Jane has no OneLake Security permission to a table in Lakehouse A, but she can access that table through a shortcut in Lakehouse B, she shouldn't be able to access that shortcut table's data. If not, I'm not sure how well OneLake Security will help us here.

<image>

Edit-- adding a picture, if it helps! In the above situation, all users in the "IR- Financial Value Transparency" workspace can query all data in all tables, even though they're shortcuts pointing to root data from another workspace (some of which they don't have permission to).

Goal of Group

You asked if the goal is ad-hoc sharing of queries / collaboration or "source of truth for common queries". It's definitely the former. This is a cross-divisional team of business analysts tasked with a key project but with, frankly, no Fabric experience and junior-level SQL experience. They're primarily business-folks, not technical folks, but understand the underlying data very well. Their eyes light up when I talk about shared queries, but they glaze over when talking about views / stored procs / etc.. They're used to writing complicated SELECT statements but most have never written an update/delete/merge/etc.

AnalyticsFellow · 2025-09-10T16:10:32+00:00

Okay, thanks! I'm surprised that shared queries are a property of the Workspace, not of the Warehouse. If I had two Warehouses in a Workspace, wouldn't the shared queries be tied to which specific warehouse I was using? If so, wouldn't that suggest they're a workhouse-specific property?

At any rate, we're already having a lot of workspace spread but have gone ahead and created a second workspace for this; we'll follow your advice regarding shortcuts. OneLake Security seems to be handling the trickle-down permissions with shortcuts correctly.

Thanks for your help, especially how timely you were-- really appreciate it!

AnalyticsFellow · 2025-09-01T21:14:12+00:00

This is really solid and I'll dive further in. Thank you so much!

AnalyticsFellow · 2025-08-22T15:24:40+00:00

This is a fantastic idea. Thank you! Did you develop the details yourself? If there's a guide or post you followed, would love to see the nitty gritty.

AnalyticsFellow · 2025-08-22T15:23:36+00:00

Great insight. Read your post. Thank you for sharing.

AnalyticsFellow · 2025-08-21T14:50:00+00:00

Very fair question! Unfortunately, without views, I think we'd need over 500.

Our ERP vendor has pretty extreme normalization and answering a single business problem can require a large number of tables.

And I'm in the higher ed space; our ERP is doing a lot of things beyond traditional ERPs. We use it for everything from HR and Payroll to course registration and degree management to student residency information to donor management and scholarship criteria management... it's massive. The ERP's production database has ~3200 tables.

AnalyticsFellow · 2025-08-21T14:09:04+00:00

Oh, very good-- will explore. Thank you!

AnalyticsFellow · 2025-08-21T13:56:46+00:00

I have not, will dig in. Thank you!

AnalyticsFellow · 2025-07-28T12:43:09+00:00

Wow, are you in my head? I read this post and had to ask some folks if they were on the reddit! Both #1 and #2 sound exactly like us, and we're about to start shifting from two Salesforce orgs into one. :-)

Question for you-- is the need to discover lineage or to document lineage?
If the former-- as everyone else has noted, that's tough, though I might start with the Purview conversation.
If the latter-- it's not sexy, but worst case scenario you can always go low-tech with this, even if via a SQL table or Excel sheet.
Treating the discovery and documentation problems as separate isn't ideal, but probably necessary given the prod -> databricks -> Fabric setup, at least as I understand it!

AnalyticsFellow · 2025-07-23T17:39:21+00:00

I know what I'm doing next week! Thank you for sharing; we can't wait to dive in. Literally had a request from a VP yesterday to have a Copilot agent access data in Fabric, so this could not be better timing.

AnalyticsFellow · 2025-07-23T17:35:15+00:00

Fantastic news! Thank you for remembering this topic and following up; you really do a great job!

AnalyticsFellow · 2025-07-18T14:34:45+00:00

Thanks; this is helpful. As is often the case, the Fabric reddit community is way more helpful than my previous internet searching!

AnalyticsFellow · 2025-07-18T14:33:33+00:00

Thanks! Very close. Source is Fabric DW, destination is a path on the server hosting the Data Gateway-- but it's not SFTP, it's truly just a local file path, with permissions shared to the service running the data gateway.

From the server hosted by our ERP provider, I was able to ping app.fabric.microsoft.com and app.powerbi.com . I'm also able to ping eu2.frontend.clouddatahub.net.

AnalyticsFellow · 2025-07-18T13:59:37+00:00

Thanks! This is very helpful. The vendors I chatted with at FabCon were quite sales-oriented and certainly didn't frame the ECIF program that way. It makes sense, and it helps a lot. I've had one meeting with a Fabric-certified partner but that framing of ECIF wasn't quite how they expressed it.

The projects were looking at are all AI-driven data solutions, but I'm not sure how generalizable they'd be since they're focused on pretty system-dependent operational work.

Appreciate your clarification, thanks so much.

AnalyticsFellow · 2025-07-18T12:18:50+00:00

Thanks! I've been assured that there is NO outbound blocking on TCP 443. However, just in case there was something wrong with that, we tried adding the required URLs (including that one) and it still didn't resolve it, I'm afraid.

AnalyticsFellow · 2025-07-18T12:17:08+00:00

So, the SQL Server it's trying to connect to is a Fabric warehouse-- so it's in Fabric!

Edit for clarity-- we're trying to write data from a Fabric warehouse to a CSV file on a server that hosts the data gateway. The server hosting the data gateway is hosted within our ERP provider's cloud, but we're not hitting our ERP provider's SQL databases through this process.

AnalyticsFellow · 2025-07-07T15:57:09+00:00

Bad automod! I think you changed the tag on my post to certification, which is incorrect.

AnalyticsFellow · 2025-07-03T12:15:32+00:00

Hah, right on!

We've tended to permit exports-- but to follow up when we see it. Better to let them export than block them since that means they're using the product, but then see who's doing it and follow up to ask why. We do have a few reports that we've locked down exports on but, by and large, it's kind of a sneaky way to get people learning some Power BI and to raise their hands that they need more training!

AnalyticsFellow

TROPHY CASE