Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Did you hear? There's a new SQL AI Developer certification (DP-800). Start preparing now and be one of the first to get certified. Register now

gesaur

Fabric Extensibility Toolkit: CI/CD, Remote Lifecycle Notifications, and Fabric Scheduler (Preview)

If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. 


Alongside the Microsoft Fabric Extensibility Toolkit (Generally Available), we are announcing three capabilities entering preview that complete the professional development story for Fabric workloads.

From the beginning, workload developers asked for two things: 1) to make items behave like native Fabric items across the full platform lifecycle (CI/CD, Git, Deployment Pipelines), and 2) to make it possible to build workloads that are tightly integrated with backend services and operational scheduling. All three of today's previews address exactly that.

CI/CD Support: Items in Deployment Pipelines and Git (Preview)

Fabric's CI/CD story is built around two pillars: Git integration for version control and Deployment Pipelines for promoting changes across environments. Starting today, custom workload items participate in both—with no custom logic required.

Git Integration for Workload Items

When a workspace is connected to a Git repository, Fabric extensibility workload items are now included automatically. Every workload item's definition—its metadata, configuration, and state—is serialized into the Git repository when committed:

workspace-git-repo/

MyItem.MyWorkloadItem/

.platform # Fabric item metadata

definition.json # Example of your item's persisted definition

  • Review item state changes in pull requests alongside code changes.
  • Branch strategies to isolate development from production item data.
  • Audited and version-controlled item configuration changes automatically.

Deployment Pipelines for Workload Items

Workload items can now move through Deployment Pipelines across dev, test, and production workspaces. When an item is promoted to the next stage:
  • The item's definition content is carried forward to the target workspace.
  • The platform handles workspace-specific adjustments (e.g., connection rebinding, capacity differences).
  • Partners can optionally implement a deployment hook to apply stage-specific transformations to the item definition before it lands in the target workspace.

Automated Deployment in Your Pipelines

If you use GitHub Actions or Azure Pipelines to automate your Fabric deployments, no additional tooling is required. Because workload items are now Git-native, your existing workspace commits and pipeline promotion automation handles them transparently.

For teams that automate via the REST API, the standard Deployment Pipelines REST API endpoints now work for custom workload items without special handling.

Variable Library Support

CI/CD support only truly works end-to-end if items can be configured differently per deployment stage. That is where Variable Library support comes in.

A Variable Library in Fabric is a workspace-level store of named values that can vary per deployment stage. Workload items can now read from the Variable Library, allowing you to build user experiences that adapt automatically when an item moves between environments.

The classic problem: if your item stores a hard-coded reference to a Lakehouse in its definition—say, a specific item ID—that reference will point to the development Lakehouse even after the item is promoted to production.

The solution: instead of storing the Lakehouse ID directly in your item definition, store a variable name. The Variable Library maps that name to the correct Lakehouse ID in each workspace—development, test, and production can each have a different value. No hard-coded IDs, no manual reconfiguration, no custom hook logic required.

Remote Lifecycle Notification API (Preview)

Workloads are no longer just passive objects sitting in a workspace. The Remote Lifecycle Notification API is an opt-in capability—there is no requirement to use it. If your workload does not need backend notifications, you simply don't register an endpoint, and everything works exactly as before.

When you register a notification endpoint in your workload manifest, Fabric will call your backend with a webhook whenever one of your items is created, updated, or deleted—anywhere, by anyone, through any path.

What Gets Notified

The notification payload identifies the event type (Created, Updated, Deleted), the item involved, and the workspace context. Your backend receives this in near real time regardless of how the event was triggered:
  • A user creates an item from the Fabric UI
  • An item is created via the Fabric REST API
  • An item is provisioned as part of a CI/CD pipeline or Deployment Pipeline promotion
  • An item is deleted by a workspace admin cleaning up resources

Key Use Cases

Licensing and entitlement checks: When a new item is created, your backend can verify that the user or organization is entitled to use your workload, enforce seat limits, or trigger a license activation flow—before the item is ever opened.

Infrastructure provisioning: Some workloads need to provision dedicated infrastructure per item—a database schema, a container, an API key, and a resource group in Azure. The Created notification is the reliable trigger to start that process. The Deleted notification is the reliable trigger to tear it down.

Synchronization with external systems: If your workload mirrors item state to an external catalog, governance tool, or data platform, the Notification API ensures your external representation stays accurate without polling.

Why This Completes the Platform Story

Combined with CI/CD support, the Notification API means that items can flow through automated pipelines at scale, and your backend always knows about it. An item promoted through three Deployment Pipeline stages will trigger three notifications—one per workspace—giving your backend the chance to provision or reconfigure the corresponding infrastructure in each environment automatically.

Fabric Scheduler: Remote Jobs (Preview)

The Fabric Scheduler, also referred to as Remote Jobs, is entering public preview. Like the Notification API, it is entirely opt-in—workloads that don't need scheduled jobs are not affected in any way.

It allows workload items to expose named job types that users can schedule directly from Fabric. When a scheduled job fires, Fabric calls a registered endpoint on your workload backend—passing along the item context and a delegated user token.

How Remote Jobs Work

You register one or more job types in your workload manifest. Users schedule jobs on individual items through the standard Fabric job scheduling UI—the same experience they use for Notebooks and Dataflows. At the scheduled time, Fabric sends a signed request to your backend endpoint containing:
  • Item context—the item ID, workspace, and any relevant item definition data your job needs
  • User token—a delegated On-Behalf-Of token scoped to the user who owns the schedule, allowing your job to call Fabric APIs, OneLake, or any other Entra-protected service on behalf of that user
Your backend executes the job, reports status back to Fabric, and the result surfaces in the standard Fabric job history UI alongside runs from native item types.

What This Enables

Because your job receives an OBO token, it can do anything the user is authorized to do:
  • Read from or write to OneLake folders associated with the item
  • Call the Fabric REST API to read or update item definitions
  • Query external APIs or databases using the user's identity
  • Chain into other Fabric capabilities—triggering Pipelines, reading Lakehouses, writing to Warehouses

Try it Out

Both CI/CD support and Remote Jobs are now included in the Starter Kit as ready-to-use samples. They are opt-in and can be activated with a single flag during setup:

Once activated, the samples wire up the relevant manifest entries, backend endpoints, and frontend UI so you can see the full flow end-to-end immediately—no scaffolding required.

Explore the toolkit at aka.ms/fabric-extensibility-toolkit-docs. Share your feedback on Fabric Ideas and join the conversation in the Extensibility Toolkit Gallery.