Fabric Pipelines need a lightweight “no‑op” or “barrier” activity that performs no action but can be used as a synchronization point between groups of activities. This is essential for real‑world workflows where multiple setup tasks must all complete before the next stage can begin. For example, imagine a pipeline with 10 setup activities running in parallel—loading configuration, preparing variables, validating inputs, checking dependencies, etc. Once all setup tasks are complete, the pipeline needs to run multiple processing activities. Today, Fabric requires manually connecting each of the 10 setup activities to each of the processing activities. This creates a dense web of connections that is difficult to read, error‑prone, and extremely time‑consuming to maintain. The inefficiency becomes even more severe as the pipeline evolves. If a new setup activity is added, it must be connected to every processing activity. If a new processing activity is added, it must be connected to every setup activity. This results in exponential wiring effort and makes the pipeline visually overwhelming. Some workarounds I could think of, but each has drawbacks: 1. Using an IF activity as a fake barrier Wrap all setup activities inside an IF block that always evaluates to true. Then all processing activities are connected to the IF activity. This works, but it is unintuitive, adds unnecessary logic, and clutters the pipeline with conditional structures that don’t actually represent conditional behavior. It also confuses anyone reading the pipeline because the IF activity doesn’t reflect real branching logic. 2. Using a Wait activity A Wait activity must be set to at least 1 second, which introduces unnecessary delay and still feels like a hack rather than a proper orchestration tool. 3. Using an empty notebook or Set Variable activity These technically work as barriers, but they are not designed for this purpose and make the pipeline harder to understand. 4. Splitting the pipeline into multiple pipelines This is also not ideal because: Each pipeline execution has startup overhead, slowing down the workflow Logs become fragmented across multiple pipeline runs, making troubleshooting harder You lose the ability to see the entire workflow in one place You introduce additional pipeline‑to‑pipeline dependencies and permissions A dedicated “barrier” activity would solve all of these issues cleanly. All setup activities could connect to a single barrier node, and all processing activities could start from that node. Adding a new setup or processing activity would require only one connection instead of many. This dramatically improves maintainability, readability, and scalability as pipelines grow. From a runtime logging perspective, it would also help identify where in the process your run is at, making debugging easier and giving progress benchmarks as you are monitoring a running operation. Current workarounds are functional but unintuitive and not designed for this purpose. A true no‑op activity would align Fabric Pipelines with orchestration best practices and significantly reduce visual clutter in complex workflows.
... View more
on:
CI/CD support for Notebook Resources folder
tbindas-msft
on:
Add Object, Workspace and User details to Capacity...
on:
Variable Library: Shortcuts with variable value th...