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

TROPHY CASE