How to deploy OrgApp and OrgAppAudience from one workspace to another workspace using GitHub Actions
Hi Team - I was looking to achieve the CI/CD for OrgApp and OrgAppAudience. I have a workspace-Dev which is Git Integrated and has the OrgApp and OrgAppAudience in below structure format. Sales Results.OrgApp ├── .platform ├── definition └── .children └── Sales Results.OrgAppAudience ├── .platform └── definition I'm trying with to achieve this deployment automation with GitHub actions. Steps performed are 1. Install fabric-cli 2. Login using Managed Identoty to fabric CLI 3. Deploy using fab deploy with config file with Items in scope as "OrgApp" and "OrgAppAudience" Observation Error - It looks the Fabcric CLI does not support this type of deployment. Please let me know the possibilities to achieve this deployment using GitHub actions only. FAQ on the Fabric User Groups
Best practices for separating Silver and Gold in Microsoft Fabric for AI agents
Hi Fabric Community, We're building a Microsoft Fabric data platform for an AI agent that investigates leads using Salesforce and Marketo data. The AI agent searches across Lead, Contact, Account, Opportunity, Case, Campaign, Marketo Person, and Activity data to summarize related opportunities, inquiries, engagement history, and other relevant information. Our goal is not BI or reporting. Instead, we're building a reusable data platform for AI agents, with the possibility of supporting additional sales AI agents in the future. Current architecture We are currently considering the following architecture: Workspace 1 (Data Engineering) Bronze Lakehouse: Stores raw Salesforce and Marketo data with minimal transformation, serving as the source for reprocessing and data lineage. Silver Lakehouse: Stores standardized and integrated data, including data type conversion, deduplication, entity matching, Salesforce–Marketo integration, and common business keys. This layer is intended to be the reusable, enterprise-wide data foundation. This workspace is used only by data engineers and administrators for data ingestion, transformation, and maintenance. Workspace 2 (AI & Business Consumption) Gold Lakehouse: Data exposed to AI agents and business users. This workspace is intended to isolate end-user consumption from the underlying data engineering layer and simplify permission management. Our challenge We're struggling to decide how much data should actually be placed in the Gold layer. Many of the objects we're considering—such as person investigation views, opportunity search views, and case search views—seem to be little more than AI-friendly views over the Silver layer. On the other hand, datasets such as person activity summaries, company activity summaries, or pre-aggregated Marketo Activity data seem like better candidates for Gold. Questions For AI-agent use cases, is it common for AI to query the Silver layer directly while keeping the Gold layer minimal? Or is it also considered a best practice to omit the Gold layer entirely and have AI consume data directly from the Silver layer? If you use a Gold layer, what kinds of tables or views do you typically put there? I'm particularly interested in real-world architectures and best practices from teams using Microsoft Fabric primarily for AI rather than traditional BI. Thanks in advance! #MicrosoftFabric #Lakehouse #MedallionArchitecture #AI #CopilotStudio #DataAgent #OneLake #Salesforce #Marketo
Azure Artifact Feed - Connection string not supported
Hi everyone, I'm trying to create a new Azure Artifact Feed (Preview) connection in Microsoft Fabric, but I'm consistently getting the following error: Unable to create connection for the following reason: Connection string is not supported. Details: Query contains unsupported function. Function name: AzureArtifactFeed.Contents Environment Microsoft Fabric Connection Type: Azure Artifact Feed (Preview) PyPi Feed URL format: https://pkgs.dev.azure.com/<organization>/_packaging/<feed>/... Creating the connection from Manage Connections and Gateways > New Connection > Cloud Questions Has anyone successfully configured an Azure Artifact Feed connection in Fabric recently? Could this be related to the note displayed in the UI indicating that some cloud connections are not supported by Dataflows Gen1 and Datamarts? Any insights or confirmation that this is a known issue would be greatly appreciated. Thanks!
Has anyone seen deleted Fabric Plans continue consuming capacity?
Hi all, I'm hoping someone else has run into this because I'm struggling to figure out whether this is expected behaviour or a bug in the Planning Preview workload. We recently created a Plan in Fabric Planning (Preview) to test the feature and later deleted it. The Plan is definitely gone from the workspace, but more than 24 hours later it still appears to be consuming capacity. When I look in the Capacity Metrics app, I can see three "Planner Session" entries under Background Operations. What's odd is that: None of them have a Start or End time. The User column contains GUIDs rather than actual user accounts. Each one is showing 86,400 seconds duration and around 100k CU consumption. If I pause and resume the capacity, the sessions come straight back. The other thing that's concerning is that the Planning workload's cumulative percentage keeps growing. At the moment it's sitting at around 3,694%, which is making up the majority of the cumulative utilization on our F4 capacity. A few questions for anyone who has been testing Planning: Is this normal behaviour for the 30-day Planning session model? Do Planner Sessions continue to exist after a Plan has been deleted? Has anyone seen these GUID-based sessions before? Is there any way to force the sessions to terminate or clean themselves up? Has Microsoft acknowledged this as a known issue in Preview? At first I thought this might just be a delay in cleanup, but it's now been over a week and the sessions are still there. The lack of Start/End times and the fact that they survive a capacity pause/resume makes me think something may be stuck in the backend. Would be interested to hear if anyone else has seen similar behaviour or if someone from the Fabric team can shed some light on it. Thanks!
Unable to navigate to workspace
Hi, I stumbled on a problem I can't seem to find a good solution to. When doing the learning tracks for Fabric certifications there is a lot of creating and removing workspaces. After a while I hit an invisible wall with a popup saying 'Unable to navigate to workspace - Only 10 workspaces can be opened at one time. On the left navigation bar, close a workspace and then try again.' I only have access to a total of 5 workspaces and only one is in the left navigation bar. Anmhy suggestions on how to fix this without clearing browser cache/cookies? Also, does anyone know if it is possible to register a bug report without being tenant Admin? Thanks in advance, Saittam
Concurrent Git Branching in Fabric Workarounds for Data Rehydration?
Hi Fabric Community, We're looking for recommendations on Git branching strategies for multi-developer teams in Fabric. The Challenge: In Synapse, developer branch selection was independent per user. In Fabric, changing the workspace Git branch alters the branch for all users in that workspace, making concurrent development on separate branches difficult. Current Workaround & Pain Point: Fabric documentation recommends creating a new workspace per feature branch. Issue: Rehydrating data for every feature workspace is time-consuming and something we want to avoid. Questions: What is the recommended best practice for isolated concurrent feature branching in Fabric? Are there established patterns (e.g., using shortcuts, thin reports, or shared lakehouses across dev workspaces) to avoid rehydrating data for each feature workspace? Appreciate any insights!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-apps
Unable to commit the following item type "Activator"
Hi Fabric Community, I'm running into an issue with a type activator in Fabric and could use some guidance from the community. When attempting to commit the activator to my repo, I received the following error message: "We weren't able to commit the following item: Please check the technical details for more information " I'm not entirely sure what this error means or how to troubleshoot it. If anyone has come across a similar issue with type activators in Fabric or has any insights into what might be causing this, I'd really appreciate your help. Thanks in Advance
