Row-Level Security in Direct Lake Models: The Undocumented Gotchas
When we moved our sales reporting from Import mode to Direct Lake, RLS looked like the easy part. We already had dynamic RLS working in the old Import model: a security table, a USERPRINCIPALNAME() filter, and a couple of relationships. We expected to copy it over and be done in an afternoon. It took two weeks. The RLS logic itself was fine. What caused the trouble was how Direct Lake interacts with workspace permissions, the SQL analytics endpoint, framing, and fallback. Most of it is technically documented, but spread across a dozen pages, and a few behaviors we only found by testing. This post covers what we hit, how we diagnosed it, and what we'd do differently next time. The setup Here's a simplified version of what we built: Lakehouse: LH_Sales with fact_sales, dim_region, dim_product, dim_date Security table: sec_user_region (UserEmail, RegionKey), one row per user per region Semantic model: Direct Lake on the SQL analytics endpoint Users: about 400 sales reps and managers, each seeing only their regions The RLS role was the standard dynamic pattern: // Role: RegionSecurity // Table: sec_user_region [UserEmail] = USERPRINCIPALNAME() The relationship sec_user_region[RegionKey] → dim_region[RegionKey] had "Apply security filter in both directions" enabled, and dim_region filtered fact_sales. It worked when I tested it as myself, and it failed in several different ways once real users got access. Gotcha #1: Workspace roles silently bypass your RLS This is the most common one, and it matters more in Direct Lake. Semantic model RLS only applies to users who have Read permission on the model. Anyone with Admin, Member, or Contributor in the workspace has write permission, so RLS does not apply to them. They see everything. That's the same as Import mode. The Direct Lake-specific problem is the next part. The Viewer role has a hole too. A workspace Viewer is subject to your semantic model RLS, but Viewers can also connect to the lakehouse's SQL analytics endpoint and query fact_sales directly from SSMS, Excel, or a notebook. Your DAX roles don't exist there, so they can read every row. We found this when a regional manager emailed us a pivot table with national numbers. He had connected Excel to the SQL endpoint because he found it faster. The relationship sec_user_region[RegionKey] → dim_region[RegionKey] had "Apply security filter in both directions" enabled, and dim_region filtered fact_sales. It worked when I tested it as myself, and it failed in several different ways once real users got access. What we changed: Removed every business user from workspace roles. Shared the report and semantic model through an App (or item-level sharing) with Read permission only, without "Build" unless it was genuinely needed. Did not grant lakehouse access to end users at all (Gotcha #2 explains how that still works). Rule of thumb: If a user can see the lakehouse, assume they can see all of it unless you've also secured it at the SQL/OneLake layer. Gotcha #2: SSO vs. fixed identity changes who needs lakehouse access By default, a Direct Lake model on the SQL endpoint uses single sign-on (SSO): the viewer's own identity is used to access the underlying data. That means every report viewer needs permission to read the lakehouse, which brings back the problem from Gotcha #1. The fix is to configure the model's data source connection to use a fixed identity through a shareable cloud connection (a service principal or a dedicated account). Then: The fixed identity reads the Delta tables. End users only need Read on the semantic model. Your DAX RLS still applies per user, because USERPRINCIPALNAME() still returns the viewer, not the fixed identity. The catch: once you switch to fixed identity, any RLS you defined on the SQL analytics endpoint (T-SQL security policies) is evaluated against the fixed identity, not the end user. Warehouse-level RLS effectively stops being per-user for this model. So pick one layer as the source of truth: Approach Security lives in Connection Users need lakehouse access? A Semantic model (DAX roles) Fixed identity No B SQL endpoint (T-SQL RLS) SSO Yes We chose A. Mixing both led to confusing results where the same user saw different numbers depending on the path the query took. Gotcha #3: SQL endpoint RLS quietly forces DirectQuery fallback We initially tried approach B, because the data engineering team liked having security defined once in T-SQL: CREATE FUNCTION sec.fn_region_filter(@RegionKey INT) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS allowed FROM dbo.sec_user_region s WHERE s.RegionKey = @RegionKey AND s.UserEmail = USER_NAME(); CREATE SECURITY POLICY sec.RegionPolicy ADD FILTER PREDICATE sec.fn_region_filter(RegionKey) ON dbo.fact_sales WITH (STATE = ON); Security worked. Performance got much worse. With Direct Lake on the SQL endpoint, any table with RLS (or OLS) defined at the SQL endpoint can't be read directly from Delta, because VertiPaq can't enforce the T-SQL policy. Queries against it fall back to DirectQuery. Our main visuals went from about 300 ms to 4–8 seconds. It fails quietly. Nothing errors. Reports just get slow. How to detect it: Run a trace in DAX Studio or SQL Profiler against the XMLA endpoint and look for DirectQuery Begin/End events. In pure Direct Lake you should see only VertiPaq scan events. In Performance Analyzer in Desktop, a "Direct query" duration on a visual is a clear sign of fallback. How to make it fail loudly instead: set the model's DirectLakeBehavior property (via Tabular Editor or TMDL) to DirectLakeOnly: model Model directLakeBehavior: directLakeOnly Now fallback-triggering queries error instead of silently degrading. We set this in dev and test so we find these issues before users do. In production you may prefer Automatic so reports keep working, but you should make that choice deliberately. Note: Direct Lake on OneLake (the newer flavour) reads Delta directly and doesn't use the SQL endpoint for queries, so SQL endpoint RLS isn't applied there at all. That's another reason not to rely on T-SQL RLS for Direct Lake models. Check the current docs on how OneLake security interacts with it, because that area is still changing. Gotcha #4: Your security table can't be a view or a calculated table In Import mode, our security table was a calculated table that unpivoted a hierarchy of managers and regions using DAX. In Direct Lake (on SQL endpoint), calculated tables and calculated columns over Direct Lake tables aren't supported. The obvious next step is a SQL view. But SQL views in a Direct Lake on SQL endpoint model always fall back to DirectQuery, because they aren't Delta tables. Your security table sits in the filter path of every query, so it pulls every query into DirectQuery with it. What worked: materialise the security table as a real Delta table in the lakehouse, rebuilt by a notebook in the same pipeline that loads the facts: from pyspark.sql import functions as F sec = ( spark.table("stg_user_access") .withColumn("UserEmail", F.lower(F.trim("UserEmail"))) .select("UserEmail", "RegionKey") .dropDuplicates() ) sec.write.mode("overwrite").format("delta").saveAsTable("sec_user_region") Keep it narrow (two columns) and deduplicated. The next gotcha explains why the lower() matters. Gotcha #5: Case sensitivity changes between Direct Lake and fallback This one took us a day to track down. A user could see data in one report page but got blanks on another. Same model, same role. The cause: USERPRINCIPALNAME() returned [email protected]. The security table had [email protected]. In Direct Lake (VertiPaq), string comparison is case-insensitive, so it matched. One page had a visual that fell back to DirectQuery (it hit a guardrail). In DirectQuery, the RLS filter is pushed down as SQL, and the Fabric SQL endpoint's default collation is case-sensitive, so it didn't match. Same user, same role, different result depending on the query path. Fix: normalise on both sides. // Role filter on sec_user_region [UserEmail] = LOWER ( USERPRINCIPALNAME () ) Also lowercase the data during ingestion (see the notebook above). Don't rely on the engine's collation. Gotcha #6: RLS changes don't take effect until the model reframes We removed a departing manager from sec_user_region, the notebook ran, and the Delta table was updated. He could still see his old regions two hours later. Direct Lake doesn't read "live" Delta. It reads the version of the table captured at the last framing operation (a refresh). If you've turned off "Keep your Direct Lake data up to date" (common when you want facts and dimensions to update together), the model keeps using the old security table until the next refresh. Security changes follow your refresh schedule, not your data load. What we do now: The pipeline that rebuilds sec_user_region ends with a semantic model refresh activity, so the model reframes immediately. For urgent revocations such as terminations, we trigger an on-demand refresh and don't wait for the schedule. We added a small "Security last refreshed" card to the report, driven by a LastUpdated column in the security table, so support can check it quickly. Gotcha #7: "Test as role" isn't the same as a real user Testing with Security → Test as role in the service, using "Other user" and typing an email, is useful but has limits: Under SSO, data access still happens with your identity. You may see rows the real user can't access at the lakehouse level, or the reverse. It doesn't show you workspace-role bypass (Gotcha #1), because you're testing the role, not the user's actual permissions. We now add a hidden debug page to every RLS model: Debug_UPN = USERPRINCIPALNAME () Debug_RegionCount = COUNTROWS ( VALUES ( dim_region[RegionKey] ) ) Debug_SecRows = COUNTROWS ( sec_user_region ) For UAT, real test accounts (not admins) open the app and screenshot this page. It shows exactly what UPN the engine sees, which also helped with a B2B guest user whose UPN didn't match the email in our HR feed. Always compare against what USERPRINCIPALNAME() actually returns, not what you expect it to return. Gotcha #8: Large security tables affect memory and cold-cache performance Direct Lake loads columns into memory on demand. The security table and its relationship columns are touched by every query for every user under that role. Our first version of sec_user_region expanded the org hierarchy down to store level: about 2.1 million rows. After a reframe, the first visual for each user was noticeably slow because the security columns had to be transcoded, and memory pressure caused more column evictions under load. Collapsing it to region level (about 3,800 rows) and moving store-level granularity into the dimension fixed the problem. Tips: Filter at the highest grain that meets the business requirement. Avoid high-cardinality string keys in the security relationship; use integer keys. Keep bidirectional filtering limited to the one security relationship, not across the whole model. Consider a warm-up query (a scheduled DAX query after refresh) for large models so the first user of the morning doesn't pay the cold-cache cost. Our checklist now Before any Direct Lake model with RLS goes to production, we check: End users have no workspace role and access through an App or item sharing only End users have no direct lakehouse / SQL endpoint access Connection uses a fixed identity (if security lives in the model) No T-SQL RLS/OLS on tables used by the model (or fallback is intentional) Security table is a physical Delta table, not a view or calculated table Emails are lowercased on both sides of the comparison DirectLakeBehavior = DirectLakeOnly in dev/test to surface fallback Security table rebuild triggers a model refresh Debug page verified by real non-admin test accounts, including guests Security table kept small, integer-keyed, and at the coarsest grain possible Final thoughts The RLS logic in Direct Lake is the same as in Import mode, so it's easy to assume nothing else changes. What does change is the environment around it: permissions are shared with the lakehouse, security can exist in two layers, data only updates when the model reframes, and queries can fall back to DirectQuery without warning. Most of our problems came from those areas, not from DAX. If you're planning a migration, test RLS with real user accounts early, run a trace to check for fallback, and decide at the start which layer owns security. Have you run into other RLS issues with Direct Lake? Please share them in the comments. I'm especially interested in how people are handling OneLake security alongside model RLS as that feature matures.Vibe Coding Fabric Notebooks in VS Code: A Production Checklist
1. Key Insights Level: 300 - practical implementation. You need to know Spark and Fabric notebooks. You do not need to know how the extension works internally. The situation. Fabric notebooks are an excellent environment for developing and operating Spark workloads. But once a notebook passes a few hundred lines, the engineering activities - refactoring, documentation, architecture review, large-scale changes - become hard to do in a browser. The alternative. The Fabric Data Engineering extension for VS Code opens a different workflow: Download the notebook from Fabric Work on it locally with a modern coding agent - Claude Code, the Claude extension, GitHub Copilot agent mode, OpenAI Codex, or a local agent Publish it back You keep Fabric's managed Spark platform, and you add what VS Code already has: advanced refactoring, Source Control, review workflows, and project-wide AI context. What surprised me. The value was not where I expected it, and the line is not where most people draw it. Generating a notebook from scratch was the weakest use. Ask for the whole thing at once and you get something plausible that you then have to verify end to end - which costs more than writing it yourself. Generating code block by block worked well. "Add one more cell that does X" is bounded. I can read it, run it, and reject it in seconds. Improving notebooks that already exist was the strongest of all. The existing code is the specification, so the agent has something to be correct against. So the useful rule is not generation bad, refactoring good. It is about scope: the agent is reliable when the change is bounded and verifiable in one reading, and unreliable when it is unbounded. What it costs. Every capability here has its limitation, and they belong in the same paragraph: Notebook synchronization is not a real-time collaborative experience. Treat it as checkout, not as co-editing. AI-generated changes require human review - and the notebook diff you review is not a code diff. That is Section 3, and it is the part I did not expect. Production workloads still need governance, validation and security controls. The agent does not provide them. So, the conclusion up front. Successful Spark vibe coding is less about replacing engineering discipline and more about augmenting it. If you skip the review step, you have not saved time - you have only moved the risk later. What is in this article. A practical workflow: prerequisites, the development patterns that worked, three review strategies with their trade-offs, production safeguards, the prompt set I reuse, and the lessons from real experimentation. The prompts are at the end. 2. When Spark Notebooks Vibe Coding is Helpful Experimenting, I found a few cases where having Spark in VSCode is more beneficial than having to solve its complexity and logistic: Converting messy 30-cells notebook into a well-structured sanctuary Solving complex technical problems (API ingestion, complex transformation, complex dependencies), to save time for copy-paste, and doing that coding step-by-step, with powerful AI assistance in place Refactoring becomes just easier using VSCode. It may be done using AI, by prompting. Or, if we want to do it manually, F2 (Windows) or Fn-F2 when the desired variable is selected will help. It is a very clean way to refactor code at scale, with minimal risk. 3. When is Vibe Coding not worth the cost? Simple, straightforward notebooks - easier to modify using the web or copy-paste AI-generated code. Highly critical pipelines, where the mistake costs a lot or the privacy model is incompatible with AI provider terms - these are subject to reconsider using AI in autonomous or partly autonomous mode. Now, let's observe some workflows and prerequisites to be able to vibe-code in Spark notebooks. 4. Prerequisites What is needed to start vibe-coding in Fabric/Spark? VSCode - indeed; Fabric Data Engineering VS Code - to connect to Fabric; Coding agent (I use the Claude extension, installed in VSCode) Turned on AutoSave in VSCode will help avoiding overwriting and keep the changes actual. 5. Workflow Extension -> Workspace -> Notebook -> Download -> Open Then - modifying the code, using vibe-coding. Then - publishing back. If the notebook was updated on the web, it is possible but harder to merge all the changes. I would omit that scenario entirely to avoid any issues. Full journey may look like that: During testing, I found that notebook synchronization between Fabric and VS Code should not be treated as real-time collaboration. If substantial changes were made through the Fabric web interface, re-downloading the notebook may be safer than attempting to merge changes manually. Disclaimer: If somebody changed the code in the web interface, getting these changes may be a challenge. Simple Update icon doesn't help, even though it says the update was successful. So, additional awareness is required for that matter. It will be an alert during publishing the code with the option to accept local or remote change: 6. Production-ready best practices 6.1. Security & Privacy If we work in production, it is important to follow the organization's rules, and use only appropriate AI tools. 6.2. Responsibility AI may change code very unpredictably. It may break production silently. Two options for handling that. First is asking AI to show all the changes. The second one is to manually check points at the beginning of vibe-coding and at the end. 6.2.1. Strategy one - risky: Asking AI to show differences Before vibe-coding, give an instruction similar to this: Before making any file modifications, show me the proposed diff and wait for my approval. As a result, the agent may showcase the changes it made. The key thing here is it may miss something or hallucinate. So, for highly critical pipelines, it may not work. This strategy is good for prototype, PoC, and MVP development. But, actually, I would say, it is overall the best time to use vibe-coding. Fully productionized critical system - it is debatable whether the outcome outweighs risks using AI assistants to write code in agentic mode. It is much safer to use manual coding, by copy-paste-debug without writing to the final tables. 6.2.2. Strategy two - conservative: Backup notebook and related data Backing up related data and code - it is a highly conservative strategy. It make sence doint this only if vibe-coding will bring much more benefits than the other ways of changing the logic 6.2.3. Strategy three: Checking the changes before and after Open notebook in VS Code. Initialize Source Control (Git). Let Claude modify the notebook. Open Source Control (Cmd+Shift+G). Click the modified notebook, to see the differences, before publication. 7. Additional block - Prompts for success 7.1. Prompt 1 - Notebook Structure Overview the notebook, and add its title, description, and after that - all the Headlines and sub-headlines, with prefixes like 1., 2., 3., 1.1., 2.2., etc 7.2. Prompt 2 - Find weak points Check code and find what may be improved. Don't do any changes. Only give the comments. 7.3. Prompt 3 - Refactor Notebook Refactor this notebook without changing functionality. Extract duplicated logic into reusable functions, improve variable naming, add comments where necessary, and reorganize code into logical sections. 7.4. Prompt 4 - Documentation This is probably the highest ROI prompt. Generate markdown documentation for this notebook. Explain business purpose, inputs, outputs, dependencies, assumptions, and execution flow. Many Fabric notebooks have zero documentation. 7.5. Prompt 5 - Performance Review This is very Spark-specific. Review this PySpark code for performance issues. Identify unnecessary shuffles, collect operations, driver-side processing, inefficient joins, and repeated scans. 7.6. Prompt Set for Feature Building 7.6.1. API Ingestion Prompt: Review this notebook and create a reusable API ingestion framework with retry logic, pagination support, logging, and configuration-driven endpoints. 7.6.2. Data Quality Framework Prompt: Convert all validation checks into reusable functions and generate a summary report at the end of execution. 7.6.3. Monitoring Notebook Prompt: Extract all monitoring logic into reusable functions and create a centralized alerting section. 7.6.4. Legacy Notebook Cleanup Prompt: Refactor this notebook into logical sections and eliminate duplicated code. 8. Before & After examples Before: After: 9. What agents may we use here? The agents selection is not limited. When we work with the notebooks that way, they are stored locally. It means, Claude Code, OpenAI Code, Loca agent from VSCode, Github Copilot Agend mode and others are fully available for us. 10. Lessons Learned Documentation generation produced the highest ROI. Structural refactoring was more reliable than business logic generation. Source Control review was essential. Small notebooks rarely justified the overhead. Large notebooks benefited the most. This makes the article feel based on real experimentation rather than theory. 11. Conclusion Spark notebooks are a surprisingly good candidate for vibe coding. The extension also supports Python notebooks and Spark SQL, from what I tested. Large notebooks often contain repetitive patterns, technical debt, and insufficient documentation-areas where modern coding agents can provide significant value. However, AI-generated changes should always be reviewed before publication, especially for production workloads. Combined with VS Code Source Control and the Fabric Data Engineering extension, vibe coding can become a practical addition to a data engineer's toolkit rather than a replacement for engineering judgment.An introduction to Fabric Apps
One of the shiny new items in Microsoft Fabric is Fabric Apps, and these open up a bunch of possibilities for what is possible in Fabric. Fabric Apps enabled functionality that previously would have needed to be custom workloads, which are a lot more complex to get up and running than Fabric Apps. What is a Fabric App? A Fabric app (built on the Rayfin SDK) is a Fabric item with two components, a backend service for data access and authentication, and a front end web app. When a Fabric App is created, Fabric automatically creates a SQL Database, an authentication server, and static content hosting for the front end web app. You provide data models for your application in TypeScript and Fabric Apps automatically creates a database schema and type-safe GraphQL API. Before you can create one, a tenant admin has to enable it. It's still in preview, so it needs to be explicitly enabled, and Fabric Apps are not available in all regions. Fabric Apps are currently available in the following regions (As of August 18th, 2026): US - Central US US - North Central US US - West US US - West US 2 Europe - West Europe France Central Italy North Norway East Switzerland North UAE North South Africa North Asia - East Asia Asia - Southeast Asia Australia East India - Central India Japan East Korea Central To enable the preview in your tenant: 1. Sign in to the Fabric admin portal (https://app.fabric.microsoft.com/admin-portal). 2. Go to Tenant settings. 3. Under Enable Fabric App Items (preview), toggle it to Enabled, scoped to your whole org or specific security groups. 4. Select Apply. Give it a few minutes to propagate. If you don't see App (preview) in your New item list, either this is why or your capacity is in an unsupported region. Part 1: Create and Deploy the Sample App Create the item in Fabric Creating the item itself is the same as any other Fabric item: 1. Open a workspace where you have contributor or higher access. 2. Select New item. 3. Search for App (preview), select it, give it a name, and select Create. This creates the item, and all the backend services I mentioned before. From here, you can select a blank app, or start with a sample To-Do App, or a sample Data App. For the sake of this post, I am going to select the To-Do App. Once selected, Fabric will start to deploy your app and present you with some instructions for getting the Rayfin CLI up and running. Create the project with npm From a terminal, run the command shown in the Fabric App: npm create Microsoft/rayfin@latest -- "<appitemname>" --template todoapp --workspace <workspacename> That one command creates a full project from the `todoapp` template and wires it to the workspace and item you just created, using the Rayfin CLI. Then change your working directory to the project directory that was just created cd <your project directory> Run it locally npm run dev This spins up the frontend and backend together against your Fabric backend, so you can test changes before anything goes live. By default it runs at `http://localhost:5173`. Deploy with npx npx rayfin up Under the hood, `rayfin up` does six things in order: 1. It creates (or reuses) the Fabric App item 2. It retrieves the publishable key 3. It syncs your `rayfin.yml` settings 4. It applies the database schema from your TypeScript models 5. It builds and deploys static content, 6. Finally, it writes the deployment details back to `rayfin.yml` and a `.env.fabric-<workspacename>` file. When it finishes, you get a live hosting URL, a Fabric portal link, and a deployment ID. Tip: Want to check what a deploy will do without actually running it? Use `npx rayfin up --dry-run`. To check current deployment state at any time, use `npx rayfin up status`. Part 2: The Database Objects Here's the part that surprised me the most coming from a data background: there's no SQL to write, and no separate database designer to open. Your data models are TypeScript classes, and Fabric Apps turns them directly into database tables. Defining an entity Entities or tables live in `rayfin/data/` and use the `@entity()` decorator from `@microsoft/rayfin-core`, as well as field decorators for each column: Each table needs to be defined in it's own typescript file. import { entity, uuid, text, boolean, date } from '@microsoft/rayfin-core'; @entity() export class Todo { @uuid() id!: string; text() title!: string; text({ optional: true }) description?: string; @boolean({ default: false }) isComplete!: boolean; date() createdAt!: Date; date() updatedAt!: Date; } Every entity gets a UUID `id` primary key. If you don't include it in your entity definition, Fabric will automatically add it. When records are inserted into your table, Fabric will generated a UUID server-side unless you supply your own. Composite keys and custom key names aren't supported. The full set of field decorators: `@uuid()`, `@text()`, `@int()`, `@decimal()`, `@boolean()`, `@date()`, `@email()`, and `@set()` for enumerated strings. Modifiers like `{ optional: true }`, `{ unique: true }`, `{ default: value }`, and `{ min, max }` add constraints to the columns. Note: The TypeScript `?` optional marker only affects the compile-time type. To actually make a database column nullable, you need `{ optional: true }` in the decorator itself. Relationships If your app has more than one table, use `@one()` and `@many()` to define relationships, and Fabric auto-generates the foreign key column for you following a `{property}_id` convention. One-to-many and many-to-one are supported; many-to-many is not, so model it with an explicit join table instead. Registering the schema Once every entity has been created, they then need to be added to `rayfin/data/schema.ts`: import { Todo } from './Todo.js'; export type TodoAppSchema = { Todo: Todo; }; export const schema = [Todo]; Applying schema changes Whenever you add or edit an entity: npx rayfin up db apply If a change would drop a column or rename a table, the CLI blocks it and warns you first. You can override with `--force`, but know that as soon as you add --force, you will be making a destructive change that cannot be undone. Warning: Using `--force` on a schema apply can cause data loss and cannot be undone. After being deployed, you are able to see the database in your workspace under the Fabric App. The SQL Database child item will allow you to access the Fabric SQL query editor where you can run SQL queries to read data. Don't change things in SQL here, as anything you change will be overwritten the next time you deploy the schema. Wrapping Up This post covers creating the sample app, deploying it, and how the database objects work. The full version, including how authentication (local email/password vs. Fabric SSO) and the front end (the RayfinClient data calls) work, is on the blog, linked below. Microsoft Learn references: Create your first Fabric app (https://learn.microsoft.com/en-us/fabric/apps/create-app) | Fabric Apps project structure (https://learn.microsoft.com/en-us/fabric/apps/project-structure) | Define data models for Fabric Apps (https://learn.microsoft.com/en-us/fabric/apps/data-models) | Deploy a Fabric app to Fabric (https://learn.microsoft.com/en-us/fabric/apps/deploy-app) Read more: Read the full post, including the Authentication and Front End sections, on the Fabric Field Notes blog: https://www.fabricfieldnotes.ca/blog/2026/08/18/an-introduction-to-fabric-appsThe Fabric Blueprint: Architecting Workspaces for Enterprise Success
This quick guide establishes the organizational standard for managing Microsoft Fabric within our enterprise environment. By adopting these patterns, we ensure security, maintainability and streamlined CI/CD deployments across all data projects.
Microsoft Fabric Apps: The Next Step in Data Application Development
At Microsoft Build 2026, Microsoft introduced Fabric Apps, a new way to build, deploy, and share data-driven web applications directly inside Microsoft Fabric. As someone who has been working with Fabric since its early days, I wanted to move beyond the announcement and build something real. Here is what I found.Why Microsoft Fabric Is Changing Modern Data Analytics
At first, I thought Microsoft Fabric was just another Microsoft product. But after learning more, I realized the real idea behind Fabric is much bigger: bringing Data Engineering, Analytics, Data Science, and Power BI together in one unified platform. That’s exactly what made me start creating Arabic content to simplify the learning journey for others.Moved Your Power BI Model to a New Fabric Workspace and It Broke? Here's Why, and the New Fix
If you've ever moved a Direct Lake semantic model to a new Fabric workspace and watched your report break with a confusing partition error, you're not alone it's one of the most common questions in the Fabric Community. Here's why it happens in plain terms, and the official fix Microsoft just shipped.Fabric SDD+AI Series (1/3) | Plan Better, Deliver More [PT/EN/ES]
🇧🇷PT: Começar no Microsoft Fabric pode ser intimidador, mas o segredo do sucesso não está apenas na ferramenta, e sim no planejamento. Descubra como o Spec Driven Development (SDD) transforma o GitHub Copilot em seu assistente mais preciso para projetos de BI. Esta é a Parte 1 de uma trilogia dedicada a tirar você do zero com segurança e IA. 🇺🇸EN: Starting with Microsoft Fabric can be daunting, but the secret to success isn't just the tool—it's the planning. Discover how Spec Driven Development (SDD) turns GitHub Copilot into your most precise assistant for BI projects. This is Part 1 of a trilogy dedicated to getting you from zero to hero safely with AI. 🇪🇸ES: Comenzar en Microsoft Fabric puede ser intimidante, pero el secreto del éxito no está solo en la herramienta, sino en la planificación. Descubra cómo el Spec Driven Development (SDD) transforma a GitHub Copilot en su asistente más preciso para proyectos de BI. Esta es la Parte 1 de una trilogía dedicada a llevarlo de cero a la meta con seguridad e IA.Overcoming Common Challenges in Microsoft Fabric: A Practical Guide
Facing issues with data integration, performance, or governance in Microsoft Fabric? This guide breaks down the most common challenges and offers practical, real-world solutions to help you get the most out of your Fabric environment.
