Microsoft Fabric Data Pipelines Explained: From Triggers to Migration
- 19 min read
- on June 2, 2026
- by Lekhya Veera
TL;DR
Microsoft Fabric data pipelines are orchestration tools, not transformation engines — they control when and how data moves, while Dataflow Gen2 and Spark Notebooks handle the actual transformation, and getting this distinction right is what determines whether a pipeline survives production load. This article covers pipeline fundamentals, triggers, architecture patterns, and governance.
Most teams get a Microsoft Fabric pipeline running in an afternoon. Far fewer can build one that survives a quarterly data volume spike, a compliance audit, or a new team member picking up the codebase cold. The gap shows up in cost overruns, silent failures at 2 AM, and migration projects that stretch from weeks to months.
The problem is usually not the pipeline logic. It is the underlying architectural decisions, hardcoded connections, no incremental load pattern, and monolithic designs that break when one activity fails.
In this article, we’ll cover Fabric pipeline fundamentals, trigger types, expressions, architecture patterns, monitoring, migration paths, governance, and cost management.
Key Takeaways
- Fabric data pipelines are orchestration tools, not transformation engines. They control when and how data moves. Dataflow Gen2 and Spark Notebooks do the actual transforming.
- There are 90+ activity types available, from Copy Data and ForEach to Notebook execution and REST API calls.
- Three trigger types are GA in Fabric: Scheduled, Storage Event, and Manual. Interval-based schedules (the Tumbling Window equivalent) are still in preview as of mid-2026.
- Dynamic expressions using
@syntax are what separate a hardcoded demo pipeline from one that holds up in production. - Migrating from SSIS or ADF to Fabric is not a lift-and-shift. Most teams underestimate the effort by 40-60% by treating it as a copy exercise rather than a redesign.
What Is a Microsoft Fabric Data Pipeline?
A Fabric data pipeline is a cloud-native orchestration tool inside Microsoft Fabric’s Data Factory workload. It lets teams design, schedule, and monitor ETL and ELT workflows using a visual canvas with 90+ activity types, connecting data sources to Lakehouses, Warehouses, and semantic models.
The key distinction upfront: a pipeline is an orchestration tool. It controls the sequence and conditions under which data moves and transforms. The heavy transformation work sits in Dataflow Gen2 (Power Query engine) or Spark Notebooks. Pipelines call those as activities.
1. How Fabric Pipelines Fit Into a Modern Data Stack
Fabric pipelines sit between raw data sources and the analytical layers that serve reports and AI models. The flow looks like this:
Pipelines orchestrate every step in that chain. They coordinate, not transform. They sit between your data lake, data warehouse, and analytics layers, connecting each component in the broader data architecture.
2. Fabric Pipeline Vs Dataflow Gen2: When To Use Each
A pipeline is for orchestration: control flow, scheduling, error handling, multi-step sequencing. Dataflow Gen2 is a Power Query-based transformation tool. They are complementary, pipelines call Dataflow Gen2 as one activity among many.
The most common mistake is using Dataflow Gen2 alone for large-volume ingestion. It hits memory limits above roughly 500 million rows. The better pattern is Copy Data (pipeline activity) for ingestion into Lakehouse Files, followed by Dataflow Gen2 or a Notebook for transformation.
3. Fabric Pipeline Vs Azure Data Factory: What Actually Differs
Fabric pipelines share ADF’s underlying engine. The JSON-based pipeline definition is largely the same. But the differences matter in production. The official Microsoft comparison covers the technical specifics.
ADF still makes sense when an organization has a complex Azure-SSIS IR setup, multi-cloud destinations (AWS S3, GCP BigQuery), or significant ADF investment that doesn’t yet justify migration. For Microsoft-first stacks targeting Fabric Lakehouse and Warehouse destinations, Fabric pipelines are the cleaner choice: unified billing, unified monitoring, and native OneLake integration out of the box.
Transform Your Business with AI-Powered Solutions!
Partner with Kanerika for Expert AI implementation Services
Microsoft Fabric Pipeline Trigger Types
Triggers determine when a pipeline runs. In practice, trigger selection affects data freshness, cost, reliability, and failure recovery. Most tutorials skip the trade-offs.
Three trigger types are currently GA in Fabric. A fourth, interval-based schedules, is in preview as of mid-2026.
1. Scheduled Triggers
Runs a pipeline on a recurring schedule: hourly, daily, or using a cron expression for finer control. The right choice for batch workloads with predictable rhythms, nightly loads, weekly aggregations, end-of-month reporting refreshes.
The time zone setting deserves attention in multi-region deployments. A “midnight” run that executes at midnight UTC hits during business hours in Asia-Pacific. If a scheduled trigger fires while a previous run is still executing, Fabric starts the new run in parallel by default. For sequential batch loads where parallel runs would corrupt watermark state, set the pipeline concurrency limit to 1.
2. Storage Event Triggers
Fires a pipeline when a file arrives in or is deleted from a specified OneLake or Azure Storage path. The most common use case: a vendor drops an EDI file or CSV to a designated Lakehouse Files path, the event trigger detects it, and the pipeline begins processing immediately. No polling overhead, no scheduled trigger checking for files that might not exist.
Configuration requires specifying the storage path, event type (blob created or deleted), and optionally a file name pattern filter.
3. Manual Triggers and On-Demand Execution
Runs a pipeline on demand via the Fabric UI or API. Useful for testing, ad hoc loads, and pipelines called programmatically from external orchestrators or Power Automate flows.
4. Interval-Based Schedules (Preview)
Tumbling window triggers track state. Each time window has a known start and end time, and ADF guarantees no window is skipped or double-processed. This makes them the right tool for backfill scenarios and time-partitioned incremental loads.
Microsoft has been building the equivalent for Fabric. Interval-based schedules entered preview in 2025 and are expected to reach GA in late 2026. Until then, teams need alternative patterns, typically watermark tables managed by pipeline logic, to replicate that behavior.
If you’re migrating from ADF and relying on Tumbling Window triggers, plan for this gap. The workaround isn’t hard, but it adds design time that migration timelines often don’t account for.
Fabric Pipeline Activity Types
The activity library is what makes Fabric pipelines genuinely useful for enterprise work. Activities fall into four categories.
1. Copy Data: The Workhorse
Copy Data handles the actual movement of data from source to sink. It supports 150+ connectors and is the most frequently used activity in any pipeline. The critical configuration decisions:
- DIU (Data Integration Units): this directly drives CU consumption. The default “Auto” setting works for small loads. For large recurring loads, profile first and set explicitly. Misconfigured DIUs are the single biggest cost surprise in enterprise Fabric deployments.
- Source and sink connectors: Workspace Connections pointing to source systems and Fabric destinations.
- Parallelism settings: partition source queries for parallel reads on large tables.
2. Control Flow Activities
| Activity | What It Does | When To Use It |
|---|---|---|
| If Condition | Branches logic based on expressions | Error handling, conditional load paths |
| ForEach | Iterates over an array of items | Processing multiple files, tables, or entities |
| Until | Loops until a condition is met | Polling patterns, retry with backoff |
| Execute Pipeline | Calls a child pipeline | Modular design, domain-specific reuse |
| Set Variable | Assigns runtime values | Dynamic parameterization, watermark tracking |
| Get Metadata | Retrieves file or table properties | File existence checks, schema validation |
| Switch | Multi-branch routing | Multi-environment config, routing by data type |
| Wait | Introduces a delay | Rate limiting, dependency timing |
| Fail | Forces intentional pipeline failure | Explicit error signaling |
ForEach deserves special attention on cost: by default it iterates sequentially. Set the batch count (1-50) and toggle parallel/sequential execution explicitly. A ForEach with batch count 50 running 50 Copy Data activities in parallel will spike CU consumption, a frequent surprise in environments that haven’t profiled capacity.
Execute Pipeline is consistently the most underused activity in enterprise deployments. Building modular, reusable child pipelines (one per domain or data source) is the difference between a fragile one-off pipeline and a maintainable production architecture.
3. Transformation Activities
The three primary transformation activities each have a distinct performance profile. Picking the right one depends on data volume, team skills, and how often the transformation logic changes.
| Activity | Engine | Best Volume Range | Owned By |
|---|---|---|---|
| Notebook activity | Apache Spark (PySpark) | 100M+ rows, multi-TB | Data engineers |
| Dataflow Gen2 activity | Power Query (M) | Up to ~500M rows | Analysts / engineers |
| Script activity | T-SQL | Warehouse-native volumes | SQL developers |
| Stored Procedure activity | T-SQL (pre-compiled) | Warehouse-native volumes | SQL developers |
The Notebook activity is the primary bridge between orchestrated data ingestion and ML model execution. Dataflow Gen2 is faster to iterate but hits memory limits at scale. The Script activity is the right choice when the transformation is SQL-native and performance is the priority.
4. Web and Utility Activities
The Web activity makes REST API calls, critical for Teams alerting on pipeline failure and webhook triggers to external systems. The Lookup activity queries data for use in downstream activities and is essential for watermark-based incremental loads. The Delete activity removes files or blobs after a successful load.
AI-Powered SSIS to Fabric Migration: A Step-by-Step Guide
Discover how to convert SSIS packages to Microsoft Fabric pipelines, re-express Data Flow logic, and configure SHIR for on-premises connectivity.
How To Architect Fabric Pipelines for Scale
This is where most guides stop, and where production failures start. The activity types are well documented. The architectural decisions that determine whether a pipeline survives at scale are not.
1. Medallion Architecture in Practice
Microsoft’s medallion lakehouse architecture maps cleanly to Fabric pipeline design:
- Bronze layer: Copy Data activity ingests raw data to Lakehouse Files (Delta or Parquet). No transformation. Preserve the source record exactly.
- Silver layer: Notebook or Dataflow Gen2 activity applies cleaning, deduplication, and business logic. Writes to Delta tables in Lakehouse.
- Gold layer: aggregation pipeline produces business-ready datasets. Often a combination of SQL Script activity and Notebook.
Each layer transition is a separate pipeline, called by a master orchestration pipeline via Execute Pipeline. A silver-layer failure doesn’t corrupt Bronze data. Each layer can be monitored, tested, and rerun independently.
2. Parent-Child Pipeline Design
A master orchestration pipeline should do very little data work. Its job is to call domain pipelines in the right order, with the right parameters, and handle failures cleanly.
The pattern: one master pipeline per domain (sales, finance, operations, HR), each calling child pipelines per data source or entity. This gives teams clear ownership boundaries, simplifies testing, and isolates failures. For related reading on automating these patterns at scale, see this overview of data pipeline automation.
3. Incremental Load: Watermark-Based and CDC
Full loads become unsustainable above roughly 10 million rows in most enterprise scenarios. Design for incremental from the start.
The standard watermark pattern:
- Lookup activity queries a watermark table for the last successful load timestamp
- Copy Data activity filters source data using
WHERE last_modified > @{variables('Watermark')} - Script or Stored Procedure activity updates the watermark table after successful load
For source systems with native Change Data Capture (CDC), Copy Data can read CDC streams directly, with no watermark management needed. Teams evaluating data fabric vs data virtualization approaches will find that CDC-based incremental loads often determine which architectural pattern is practical at their data volumes.
4. Error Handling: On Failure Branches and Dead Letter Patterns
Every activity has three dependency conditions: Success, Failure, and Completion. Production pipelines need explicit Failure branches, not just a retry count.
A solid error handling pattern:
- Set retry count to 2-3 with exponential backoff on transient failures
- Add an On Failure branch to every critical activity
- Route failures to a Web activity that calls a Logic App or Power Automate flow for Teams notification
- Write failed records to an error table in the Lakehouse (dead letter pattern)
Monitoring and Governance for Fabric Pipelines
Fabric pipelines generate operational data and move sensitive data at scale. Getting both sides right, what you observe and what you protect, determines whether a pipeline environment holds up under audit or incident.
1. Monitoring and Alerting
The Fabric Monitoring Hub is the unified observability layer for all pipeline runs across a workspace. It gives you:
- Run status and history: Succeeded, Failed, In Progress, or Cancelled for every pipeline run, with start time and duration
- Activity-level drill-down: click into any run to see each activity’s status, input, output, and error message
- Filter and search: filter by pipeline name, status, date range, or trigger type across the workspace
- 45-day retention limit: the Monitoring Hub only keeps run history for 45 days. For compliance environments, export run metadata to a Lakehouse Delta table via the Fabric REST API or use the Fabric Capacity Metrics app
For custom logging, write a row to a pipeline_execution_log table at pipeline start (status = ‘Running’), update on success with rows processed and end time, and update on failure with the error message from @activity().output.errors. This gives you a persistent, queryable audit log that survives beyond 45 days.
For alerting, Fabric has no native push notifications for failures. Wire an On Failure branch on every critical activity to a Web activity that calls a Power Automate flow or Logic App. The Web activity passes pipeline context as JSON so the notification includes run ID, pipeline name, failed activity name, and error message, not just a generic alert.
2. Connections and Integration Runtime
Before a pipeline can move data, it needs credentials and connectivity. Fabric uses Workspace Connections as its central credential store, a step up from ADF’s Linked Services model. A Workspace Connection stores the credentials (service principal, basic auth, managed identity) and connection string for a data source. When credentials rotate, they update in one place and every pipeline picks up the change automatically.
Fabric supports two Integration Runtime types:
- Azure IR (Auto-resolve): handles cloud-to-cloud connectivity. Fabric to Azure SQL, REST APIs, and cloud storage. No setup required, scales automatically
- Self-Hosted IR (SHIR): required for any on-premises source: SQL Server, Oracle, SAP, or any system not accessible over the public internet. A Windows agent installs in your network and acts as a secure relay. For high availability, run a clustered SHIR with 2+ nodes on dedicated Windows Server VMs
SHIR setup, including firewall configuration (outbound HTTPS port 443) and workspace key registration, consistently accounts for a large share of initial deployment effort in on-premises migrations. Plan for it explicitly.
3. Governance and Data Security
Pipelines move data across system boundaries at scale. Without lineage tracking and access controls, an organization loses visibility into where sensitive data goes, which is a direct compliance risk under HIPAA, GDPR, and SOX.
Key governance practices:
- Purview lineage: Fabric pipelines automatically emit lineage metadata to Microsoft Purview when a Purview account is linked to the tenant. End-to-end lineage from source through pipeline activities to Lakehouse tables to Power BI reports is captured without extra instrumentation
- Service principals: automated pipeline runs should use service principals, not interactive user credentials. Interactive credentials break when the user changes their password or leaves the organization
- Managed Private Endpoints: for sensitive source connectivity, private endpoints prevent data from crossing the public internet
- Sensitivity labels and log masking: column values from source systems appear in pipeline run logs by default. In regulated environments, configure sensitive columns to be excluded from activity output logging. The Microsoft documentation on Purview and Fabric covers sensitivity label propagation
Pairing Purview lineage with Fabric’s data masking capabilities at the Warehouse layer gives defense in depth without adding external tooling.
Migrating to Fabric Pipelines From SSIS, ADF, and Informatica
Most teams underestimate the effort by 40-60% because they treat it as a technical copy exercise rather than an architectural redesign. Understanding the risks in data migration before starting is the difference between a managed transition and an emergency rollback.
1. Migration Path Comparison
| Migration Path | Native Import? | Effort Level | Primary Complexity |
|---|---|---|---|
| SSIS to Fabric | No | High | Data Flow Task re-expression, SHIR setup |
| ADF to Fabric | Partial (JSON) | Medium | IR config, linked service re-mapping |
| Informatica to Fabric | No | Very High | Mapping re-expression as PySpark/Dataflow |
| Synapse Pipelines to Fabric | Partial | Medium-Low | Billing model shift, workspace consolidation |
2. SSIS to Fabric: No Native Import
SSIS packages have no native import path into Fabric. The migration involves:
- Converting SSIS control flow logic to Fabric pipeline activities (most of this maps cleanly)
- Re-expressing SSIS Data Flow transformations as Dataflow Gen2 or Spark Notebook logic (this is where the complexity lives)
- Handling SSIS custom components and Script Tasks, which require manual re-implementation
- Configuring SHIR for on-premises source connectivity
SHIR configuration, SSIS Data Flow Task re-expression, and test validation framework aren’t skills generalist consultants carry. Picking the right data migration partner matters more than most teams realize.
3. ADF to Fabric: What Transfers and What Doesn’t
ADF-to-Fabric is technically closer than SSIS-to-Fabric. The JSON pipeline definition imports largely intact. But the migration effort doesn’t disappear:
- Integration Runtime configurations don’t transfer. Azure-SSIS IR setups need re-evaluation.
- Linked service credentials need re-mapping to Fabric Workspace Connections.
- Trigger configurations differ between ADF and Fabric.
- Incremental load patterns built in ADF may need rebuilding using Fabric-native parameterization.
In practice, 30-50% of migration work is typically IR configuration and credential re-mapping, not pipeline logic. The ADF to Microsoft Fabric migration case study documents an engagement where consolidating separate ADF, Synapse, and Power BI licensing under one Fabric workspace delivered measurable operational simplification.
4. Informatica: A Re-Architecture, Not a Conversion
Informatica migrations are the most complex. Informatica mappings have no import path into Fabric. The transformation logic must be re-expressed as Fabric Notebook (PySpark) or Dataflow Gen2.
These environments often carry years of undocumented business logic embedded in mappings. Understanding the role of data governance in data migration is especially important here. Surface-level conversion without governance tracking creates compliance risk when output data doesn’t match historical baselines.
Fabric Pipeline Performance and Cost Optimization
1. How Fabric Pipelines Consume Capacity Units
The official Data Factory pricing documentation covers the billing model. Copy Data activities are the primary CU driver, calculated based on DIU setting multiplied by execution duration and data volume. Parallel activities running simultaneously burst CU consumption across the capacity.
The Fabric Capacity Metrics app shows CU consumption by workload and activity. Use it to profile pipelines before setting DIUs explicitly.
2. Five Optimization Patterns That Matter
| Optimization Pattern | Implementation Effort | CU Cost Impact | When To Apply |
|---|---|---|---|
| Full to incremental load | Medium (watermark design) | Very high | Any table >10M rows |
| Right-size DIUs | Low (profiling + config) | High | All recurring Copy Data activities |
| Partition source queries | Medium (partition config) | Medium | Large relational tables (>50M rows) |
| Enable staging | Low (config flag) | Low-Medium | High-volume Warehouse sink loads |
| Parallelize independent activities | Low (dependency review) | Neutral, improves speed | Pipelines with sequential independent tasks |
The highest-impact optimization in most enterprise pipelines is switching from full loads to incremental. Eliminating redundant full-table scans cuts both CU consumption and execution time. The cost model for Fabric differs materially from legacy ETL platforms, from per-job billing to capacity-based billing, and teams migrating from SSIS or ADF need to recalibrate cost estimation accordingly.
Common mistakes that inflate costs: running high-DIU Copy activities during peak capacity windows when other workloads compete for CUs, not scheduling high-volume batch pipelines for off-peak periods, and setting ForEach batch count to maximum (50) without profiling the CU burst against available capacity.
Medallion Architecture in Microsoft Fabric: Layers Explained
Learn how to design a scalable Lakehouse architecture with failure isolation between Bronze, Silver and Gold layers and the right activity type at each stage.
How Kanerika Helps With Microsoft Fabric Data Pipelines
Kanerika is a Microsoft Solutions Partner for Data and AI with Analytics Specialization and a Microsoft Fabric Featured Partner, with hands-on deployment experience across manufacturing, logistics, financial services, and packaging. The team has completed Fabric migrations across dozens of enterprise environments, running every engagement in parallel with live production systems and validating output parity before any cutover.
For migration work, Kanerika uses FLIP, a proprietary accelerator that automates assessment, conversion, and validation across SSIS, ADF, and Informatica paths. FLIP handles source inventory, field-level mapping with ambiguity flagging, business-logic conversion to PySpark and Dataflow Gen2, and row-count reconciliation between the source and target. It has delivered a 50-60% reduction in migration effort across engagements, with complex codebases completed in 8-12 weeks. FLIP is available on the Azure Marketplace and counts toward existing MACC commitments.
For governance, the suite adds KANGovern (policy templates and automated classification at ingestion), KANComply (audit-ready regulatory reporting), and KANGuard (real-time access anomaly detection across pipeline runs).
Case Study: SSIS to Microsoft Fabric Migration for Enterprise Logistics
A large enterprise with 100+ interdependent SSIS packages and on-premises SQL Server sources needed to move to cloud-native orchestration. The manual migration approach had stalled.
Challenges:
- Large-scale SSIS environments required extensive manual effort for maintenance, upgrades, and troubleshooting
- On-premises infrastructure costs were resource-intensive and difficult to justify against growing analytics demand
- Legacy SSIS pipelines could not handle increasing data volumes or support modern cloud security requirements
Solutions:
- Applied FLIP to extract, analyze, and migrate SSIS pipelines into Microsoft Fabric, automating the conversion of control flow and Data Flow Task logic
- Implemented PySpark Notebooks for complex transformations and Power Query for converting SSIS Data Flow logic within Fabric
- Configured SHIR for on-premises SQL Server connectivity and established medallion architecture in Fabric Lakehouse
- Implemented role-based access, encryption, and real-time monitoring across the new environment
Results:
- 30% improvement in data processing speeds through Microsoft Fabric’s optimized architecture
- 40% reduction in infrastructure and maintenance costs by moving from on-premises SSIS to cloud-native Fabric
- 99.9% data integrity maintained throughout migration via automated validation and testing
- Pipelines now scale dynamically based on business demand, removing the capacity ceiling that stalled the previous architecture
Case Study
FoodPharma Unified 6 Systems on Microsoft Fabric
Kanerika consolidated 50+ tables and ~1TB of history onto Microsoft Fabric — cutting cross-functional reporting from 2 business days to 90 minutes.
Read the Case Study →Talk to Kanerika
Building Data Pipelines in Microsoft Fabric?
Kanerika’s data engineering team designs Fabric pipelines that are fast, cost-optimized, and governed — and migrates your SSIS or ADF workloads across. Book a working session to scope your pipeline build.
Schedule a Demo →Wrapping Up
Fabric data pipelines are the orchestration backbone of any serious Fabric implementation. Getting the fundamentals right (triggers, expressions, activity types, medallion architecture, incremental load, governance) determines whether the investment scales or becomes a more expensive version of the legacy system it replaced.
The gap between a tutorial pipeline and a production architecture is real. It shows up in cost overruns from misconfigured DIUs, maintenance overhead from monolithic designs, compliance gaps from ungoverned data flows, and migration timelines that stretch because SSIS or ADF environment complexity was underestimated. Building pipelines that survive real-world pressure requires architectural decisions that most documentation skips over.
Transform Your Business with AI-Powered Solutions!
Partner with Kanerika for Expert AI implementation Services
FAQs
What is a data pipeline in Microsoft Fabric?
A Microsoft Fabric data pipeline is an orchestration tool inside Fabric’s Data Factory workload. It lets teams build, schedule, and monitor ETL and ELT workflows using 90+ activity types, including Copy Data, Notebook execution, Dataflow Gen2, and control flow activities like ForEach and If Condition, to move and transform data between sources and Fabric destinations like Lakehouses and Warehouses.
What trigger types does Microsoft Fabric support?
Fabric currently supports three GA trigger types: Scheduled (recurring time-based runs), Storage Event (fires on file arrival or deletion in OneLake or Azure Storage), and Manual (on-demand via UI or API). Interval-based schedules, Fabric’s equivalent of ADF’s Tumbling Window triggers with state tracking for backfill scenarios, are in preview as of mid-2026.
What is the difference between Fabric data pipelines and Azure Data Factory?
Fabric pipelines share ADF’s underlying pipeline engine but are workspace-native within Microsoft Fabric. Key differences include the billing model (Fabric Capacity Units vs. Azure IR billing), native integration with OneLake destinations, unified monitoring through the Fabric Monitoring Hub, and automatic Purview lineage emission. ADF remains preferable for multi-cloud scenarios or complex Azure-SSIS IR setups.
What is the difference between a Fabric data pipeline and a Dataflow Gen2?
Fabric pipelines handle orchestration: when and how activities run, including conditional logic, loops, and error handling. Dataflow Gen2 is a transformation tool built on Power Query. Pipelines often call Dataflow Gen2 as one of their activities. Using Dataflow Gen2 alone for large-volume ingestion is a common mistake, it hits memory limits above roughly 500 million rows.
How do pipeline parameters and variables work in Fabric?
Parameters are inputs passed in from outside (a trigger, parent pipeline, or API call) and are immutable during the run. Variables are internal state that can be set and modified during execution using Set Variable and Append Variable activities. Use parameters for values that change between runs (table names, date ranges) and variables for intermediate state within a run (watermark values, loop counters).
Can you migrate SSIS packages to Microsoft Fabric pipelines?
Yes, but it requires re-architecture, not direct import. SSIS packages have no native import path into Fabric pipelines. The migration involves converting SSIS control flow to Fabric pipeline activities, re-expressing SSIS Data Flow transformations as Dataflow Gen2 or Spark Notebook logic, and configuring Self-Hosted Integration Runtime for on-premises source connections.
How does Microsoft Fabric handle pipeline monitoring and alerting?
Fabric provides pipeline run history within each pipeline and the Fabric Monitoring Hub for workspace-level visibility. The Monitoring Hub retains run history for 45 days. For longer retention, export run metadata to a Lakehouse table via the Fabric REST API. Alerting requires explicit On Failure branches connected to Web activities calling Logic Apps or Power Automate flows.
How do Fabric data pipelines handle incremental data loads?
Through a watermark-based pattern: a Lookup activity retrieves the last processed timestamp, Copy Data filters source data using that watermark in a dynamic WHERE clause, and a Script or Stored Procedure activity updates the watermark after a successful load. For source systems with native Change Data Capture, Copy Data can read CDC streams directly without watermark management.
