Microsoft Fabric Shortcuts - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why your data lives in too many places. Your customer data probably lives in a few different places right now, and nobody can tell you which copy is real. Your sales numbers sit in one cloud, your marketing files sit in another, and your customer list lives inside a Microsoft app. Microsoft Fabric Shortcuts were built to fix exactly that, and they work in a way that surprises most beginners. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Over the next twenty minutes, I'll explain what a shortcut really is, where it lives, and what it can point at. I'll also cover the limits nobody warns you about, and how it fits with the Microsoft three hundred sixty five and Azure tools you already use.

0:42 What a fabric shortcut really is. To understand a shortcut, you first need one sentence about where it lives. Microsoft Fabric is Microsoft's all in one platform for working with data, and every fabric setup comes with a single storage layer called one Lake. Think of one lake as one giant organized drive for all of your company's analytics data. It's already switched on the moment you get fabric so you don't build it and you can't delete it. You also can't accidentally create a second one. It runs on Azure storage and keeps your tables in open formats. That matters because your data isn't trapped in a format only one company can read inside that drive. A shortcut is just a pointer. It's an object that says the real data is over there, so go and get it from there. Microsoft uses two names that are worth learning because they show up everywhere in the documentation.

1:24 The target path is where the data actually sits, and the shortcut path is where the shortcut appears. When you create a shortcut in your lakehouse, you're putting a signpost at the shortcut path. That signpost points to the target path, and the data itself never moves. Take the icon on your desktop that opens a photo stored in a folder somewhere else. The icon isn't the photo and it isn't a copy of the photo. It's a reference to the photo. And it works because your computer knows where to look. A fabric shortcut works the same way the engineers who built it describe shortcuts as behaving like symbolic links, which is the technical term for that same idea. Delete the icon and the photo is still there. That's the part that surprises people, because you can remove a shortcut without any fear of losing the data behind it. This matters for a simple reason, because copying data is expensive and messy.

2:05 If two teams each keep their own copy of the customer records, you pay to store it twice. Worse, you end up with two versions that drift apart the moment someone updates one copy and forgets the other. A shortcut avoids both problems. There's one copy in one place, and every team that needs it points at it. When the source changes, the change shows up through the shortcut. So nobody has to run a nightly job to keep two copies in step. Table definitions stay in sync as well. So if someone adds a column at the source, the shortcut picks that up. Without you rebuilding anything. A shortcut is a pointer, not a copy. And that single idea is the foundation for everything else. The rest of this episode is really about where those pointers can live and what they can reach, where a shortcut lives. Inside fabric. You can create shortcuts in two main places today, and both of them live inside fabric.

2:48 The first is a lakehouse, which is fabrics workspace for storing and analyzing large amounts of data. The second is a CXL database, which is built for real time data. And we'll leave that one alone because it's a more advanced topic. If you're new to fabric, the lakehouse is where you'll spend your time. A lakehouse has two top level folders, and they behave differently. There's a tables folder for structured data in the files folder for raw or semi-structured data where you create your shortcut, decides how it behaves. So this part is worth getting right. If you create a shortcut under tables, you're telling fabric that the thing you're pointing at is a real table. Shortcuts in this folder have to sit at the top level, so you can't tuck one into a subfolder. If the data at the target is in the delta format, the lakehouse recognizes it as a table you can query with SQL and use in power BI.

3:28 The table definition syncs by itself, so new columns at the source show up without manual work. There's one small quirk worth knowing, which is that Delta doesn't allow spaces in table names. If you name a shortcut with a space in it, fabric won't treat it as a delta table if you place the shortcut under files instead, the rules loosen up. You can put it at any level of the folder hierarchy, and it can point at any file format from spreadsheets to images. The catch is that nothing here becomes a table automatically. Files shortcuts are great for engineers who plan to read the raw files with spark, but they won't appear in your SQL queries or your power BI reports on their own. A simple rule covers most cases, and it also sets up the next question. Use tables when you want something you can query with SQL and put in a report and use files.

4:10 When you're dealing with raw data, you plan to process first. Once you know where a shortcut lives, the obvious next question is what you can point it at. What you can point a shortcut at. This is where shortcuts become useful, because the list of places you can point at is long. Some of those places sit inside fabric and some are out in the wider world. The internal ones come first. You can point a shortcut at another lake house, a warehouse, a database, a mirrored database, a mirrored Azure Databricks catalog, a SQL database, or a semantic model that reads like a wall of product names. So the plain version is this. If the data already lives somewhere inside fabric, a shortcut lets you use it from somewhere else in fabric without copying it over. One team's data shows up in your workspace, and your users never have to know that it lives next door.

4:53 The external sources are the exciting part. The list reaches Azure Data Lake Storage, Gen2, Azure Blob Storage, Amazon S3 and S3 compatible storage, Google Cloud Storage, Dataverse, OneDrive, and SharePoint, and even on premises or network restricted locations through a gateway. There's also support for iceberg tables, which we'll come back to in a moment. Read that list again and notice what it means. Your data doesn't have to move into Microsoft's world to be usable in Microsoft's world. If your company keeps files in an Amazon bucket and a Google Cloud bucket, you can bring them together in fabric without dragging either one across the internet first. Once a shortcut exists, plenty of tools can read it, spark notebooks can read it, SQL can query it when it's a table, and the real time tools can use it to power.

5:34 BI can read it through a semantic model, including in direct lake mode, which we'll come back to later. Even applications outside fabric can reach it through the one lake API, because one lake speaks the same storage language as Azure Data Lake storage iceberg deserves a plain explanation because it's a name you'll hear often. Iceberg is another open table format, and some companies, snowflake among them, lean on it heavily. One lake can generate what it calls virtual metadata, which lets fabric read a supported iceberg table as if it were a regular table. Without rewriting the underlying data. Snowflake can stay the system of record and the main writer, while fabric reads the very same data through a shortcut. So the reach is wide and it crosses cloud providers. That range is exactly why the next question matters, which is what all of this looks like when a real company puts it together.

6:17 What this looks like at a real company. Picture. A company with four separate fabric workspaces. Sales owns the sales transactions, finance owns the budgets, and a shared data workspace. Owns the common tables everyone needs like customer, product, and date. Then there's a fourth workspace called Executive Analytics, and the people there need a little bit of everything. The obvious move would be to copy all of that data into the executive workspace that works, but it creates a second set of data to store a second set of pipelines to babysit, and a second place where the numbers can go stale. The better move is to create shortcuts, executive analytics points at the authoritative sales tables, the finance tables, and the shared reference tables, and presents them together in its own lakehouse to a report developer on that team.

6:58 The result looks like one clean collection of tables. They might not even know which tables are physically stored in their workspace, and which are shortcuts pointing somewhere else. And in a well-built setup, they don't need to know. Fabric resolves those paths. Behind the scenes. A report gets built, the numbers line up and nobody had to move a single file. There's a design lesson here that's worth carrying into your own work. Keep the truly shared data like the shared customer list, the product list, and the date table in one workspace that acts as the source of truth. Keep specialized data with the team that owns it because they understand it best. Then let everyone else point at what they need. The temptation is to build one giant workspace that holds everything, and that usually turns into a mess nobody wants to maintain. So the pattern is simple. You keep one authoritative copy.

7:39 Everything else is a shortcut, and the person building the report gets one clean experience. It sounds tidy and in a well-run setup it is tidy isn't the same as free though, and there are trade offs here that most introductions skip right past the trade offs. Nobody mentions start with speed because it's the first thing you'll notice. A shortcut doesn't copy the data and it doesn't preload it either. Nothing happens until something asks for the data, and then fabric fetches it from wherever it actually lives. That means the first read can be slower than reading a local copy, especially when the source is in another cloud or sitting behind an on premises gateway. Performance depends on a handful of things, including how far away the source is, how much network latency sits in between, and how the files are organized.

8:20 It also depends on whether the source is available at that moment and on which engine is doing the reading. Microsoft offers a way to soften this, and it's called shortcut caching. When one reads a file through a supported shortcut, it can keep a copy of that file in a cache for the workspace. Later requests get served from the cache instead of crossing the network again. You said how long cached files stick around anywhere from one day to twenty eight days, and each time someone touches a file, the clock resets. There are two limits worth remembering. Files larger than one gigabyte aren't cached. The cache also fills up file by file as people use the data, so it doesn't help the very first person who opens something. Caching is supported for Google Cloud storage, Amazon S3, S3 compatible storage, and shortcuts that come through the on premises gateway.

9:02 It's a real improvement for repeated reads, and it can cut the cost of moving data between clouds, but it doesn't turn a shortcut into a local table. The bigger trade off is dependency. A shortcut relies on the thing it points at. If someone moves or deletes the target, the shortcut breaks and the report built on top of it breaks with it. If the source changes its structure, that change flows through to everyone downstream, which is usually what you want and occasionally what you don't. You also don't get the same control over table maintenance that you'd have with a table you own outright. There are clear cases where a copy is the smarter choice, and Microsoft's own guidance spells them out. Copy the data when it needs heavy transformation before anyone can use it. Copy it when a rule or a regulation says the data has to stay in a particular region, copy it.

9:44 When you need full control over how the table evolves and how it's maintained. A shortcut is a wonderful default, but it isn't always the right answer. Knowing the difference is what separates a tidy setup from a fragile one. Mistakes that trip people up. The first mistake is the one that can actually hurt so it gets the most attention. Shortcuts don't do cascading deletes and that cuts both ways. If you delete the shortcut itself, the data sitting at the target stays completely safe, which is the behavior you'd expect if you delete a file or a folder inside a Writeable shortcut though, and you have delete permission at the target you deleted at the target. Two the shortcut was a doorway, and you just walked through it and knocked down a wall. Read that again before you clean up any folder that might contain a shortcut, because this is the mistake that turns a tidy afternoon into a very long evening.

10:28 The second mistake is assuming that files and tables are interchangeable, and they aren't. A folder full of plain parquet files is not a delta table, and a shortcut placed under files won't show up as a table you can run SQL against if you need it to be queryable, you either transform the data or load it into Delta. It's easy to create a file shortcut, open PowerBI, and then wonder why the data isn't there. The third mistake is expecting raw files to become tables on their own. They won't. But fabric offers a shortcut transformation that will point it at a folder of CSV, parquet, Json, or Excel files and fabric copies, and converts them into a managed delta table that stays in sync. Checking the source every two minutes. That's convenient, and it's worth knowing that this route isn't fully zero copy because a delta table is being created.

11:09 It's also a different tool from a plain shortcut, and it won't cover complex joins or business rules, which still belong in a proper pipeline. The fourth mistake is ignoring the limits. A single fabric item can hold up to one hundred thousand shortcuts and up to one hundred unique data connections. A single one lake path can hold up to ten shortcuts. Shortcut names can't contain a percent sign or a plus sign, and schema shortcuts only work in lake houses where schemas are switched on. None of these will bite you on day one, but they will bite you at scale. The fifth mistake is assuming your permissions travel with you. Internal shortcuts use your own identity, so you need access at the target. External shortcuts use a stored connection identity instead, which means anyone with access to the lake house can read through it.

11:49 When both a shortcut path and a target path are involved, the stricter of the two permissions wins. That's a design detail rather than a day one concern, but it explains a lot of confusing access errors. How this fits with Microsoft three hundred sixty five and Azure. Start with the Microsoft three hundred sixty five side, because that's where you'll see the payoff. The visible win is power BI. When a shortcut sits in the tables folder, it can flow into a semantic model and then into a report. It can even do that in direct lake mode, which pulls the data straight into the report's memory without a separate import step. For someone who only ever wanted their data in a report, that's the part that matters. You point at the data and it shows up where you already work. There's also a connection a lot of people already understand, which is OneDrive and SharePoint fabric lets you point a shortcut straight at files sitting in SharePoint or OneDrive, and that lands well, because those are the places where everyday documents already live.

12:38 If your team keeps a spreadsheet in SharePoint, that spreadsheet can appear inside fabric without anyone copying it around. Then there's Dataverse. If your team builds things with power apps or the wider power platform, Dataverse is likely where that data lives and a shortcut can reach it. That ties fabric back to the tools this channel covers every week. And it means the data from your business apps can sit alongside everything else. The Azure side fits in the same way. One lake is built on Azure Data Lake storage, which is why Azure tools like Synapse and Databricks can reach into it using the same APIs they already use. Fabric capacity itself is bought through Azure, and it's built by the second with a one minute minimum, plus the option of a yearly reservation to save money. That leads to the practical question of cost.

13:19 And the honest answer is that fabric runs on a capacity, and a per user license alone won't unlock it. The good news is that there's a way to try it. The fabric. Trial runs for sixty days and gives you the equivalent of an F sixty four. Capacity, which is plenty of room to explore. A free fabric license is handed out automatically the first time you sign in. It only lets you create lake houses and notebooks when the workspace sits on a capacity or a trial. One thing that trips people up is that a premium per user license doesn't give you a fabric capacity on its own, so it won't unlock the workloads we've been talking about. Your turn. The short version of everything we covered looks like this. A fabric shortcut is a pointer, not a copy. It can reach data inside fabric and data outside it across Azure, Amazon, Google Cloud, Dataverse, and SharePoint, and it stays in sync with the source.

14:03 It also comes with real trade offs around speed, dependency, and control, and those are worth weighing before you commit to building on it. My question for you is simple. Where does your data live today and is it somewhere a shortcut could reach? Tell me in the comments because I read them and your answers shape what I cover next. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.