Fabric pipelines fail together after an account or device change

Multiple Fabric pipelines and notebooks fail within the same window, while the data sources remain healthy. In a Fabric practitioner discussion, users described authentication failures that appeared tied to an account or device change. That case is a signal to inspect identity dependencies, not proof that every concurrent failure shares one cause.

Inventory the identities actually in use

For each failed activity, record its connection, authentication type, connection owner, scheduled run identity and workspace role. Compare the error timestamp with password, device, conditional-access and connection changes. Microsoft’s Fabric pipeline troubleshooting guide includes token and device-claim cases; match the documented error text before choosing a remedy.

Compare manual and scheduled execution

Run one controlled manual test and compare it with the scheduled failure. Microsoft’s workspace identity guidance notes that the invoking identity needs an appropriate workspace role even when the data connection uses workspace identity. A manual success by an admin does not prove the schedule’s identity is authorized.

Remove avoidable personal dependencies

Where a connector supports it, evaluate a managed workspace identity or suitable service principal with explicit source access. Change one connection at a time, prove both manual and scheduled runs, and retain the original error and run IDs. Avoid refreshing every credential blindly; that can hide the common cause.

Adovo’s view

Production data should not inherit an employee’s device lifecycle. An identity map is part of the pipeline design: who invokes the run, who reaches the source, and who can recover it when the person leaves.