SharePoint Dataflow MFA/Conditional Access Issue After Re-authenticating Service Account

[Neevitha]

Background:

• On 15th September, I made changes to a master ETL pipeline in Microsoft Fabric.

• Changes were made to a Microsoft Fabric ETL pipeline that includes multiple source systems, some of which are SharePoint (Excel) files connected via dataflows.

• Notification activity was configured for error reporting, and a column was intentionally removed to test error handling

What I Changed:

1. Re-authenticated the notification connection.

2. Removed a column to trigger a test error.

3. Ran the full pipeline.

What Went Wrong:

• The pipeline failed with errors related to:

  • Conditional Access Policy

  • Multi-Factor Authentication (MFA)

• SharePoint dataflow connections were failing authentication.

What Fixed It:

• Re-authenticating each failing dataflow using the service account resolved the issue.

• The pipeline executed successfully afterward.

Questions

1. Immediate Resolution after Re-authentication

   • Why did re-authenticating the dataflow connections instantly fix the issue?

   • Does Fabric cache tokens or connection sessions that might expire silently?

2. MFA / Conditional Access Issues

   • Why were the connections initially blocked by MFA or Conditional Access?

   • How did re-authentication bypass these security checks?

3. Additional Connections Behavior

   • Who creates the extra SharePoint connections with the SP- prefix?

   • Are they always system-generated during re-authentication?

   • Why do they appear lower in the connection list even if created later?

4. Best Practices for Service Accounts

   • How can I ensure consistent and persistent connection behavior for service accounts across multiple dataflows?

[Vinodh247 · Accepted solution]

Immediate Resolution

• Maybe reauth fixed it because fabric refreshed the expired OAuth token.

• Yes, fabric caches access tokens. When conditional access or MFA policies change, those cached tokens become invalid silently until you re-authenticate.

MFA/Conditional Access Issues

• The initial block happened because the service account’s cached token did not satisfy updated cnditional access or MFA requirements.

• Re-authentication forced a new compliant token flow, which met the policy requirements and succeeded.

Additional Connections (SP prefix)

• The SP- connections are system-generated shadow connections created by Fabric when SharePoint connectors re-establish authentication.

• They often appear lower in the list because Fabric sorts connections by creation timestamp but groups system-generated ones separately.

Best Practices for Service Accounts

1. Use a dedicated, noninteractive service account excluded from MFA (via Conditional Access exceptions).

2. Re-authenticate all Fabric dataflows after any password or policy change.

3. Use organization-wide connections instead of per user connections where possible.

4. Document and monitor connection expiry intervals; revalidate proactively every 90 days or per token policy.

5. Keep Conditional Access policies aligned with automation accounts to avoid unexpected MFA prompts.

Hope this will help point you to the right direction.

[Neevitha]

Hi Vinodh,

Thanks so much for the clarification it really helps me understand how Fabric handles SP- connections and re-authentication.

I have a follow-up question:

• If I re-authenticate the same dataflow multiple times (e.g., 3 times in a row), will Fabric create 3 separate SP- connections (SP1, SP2, SP3)?

• Or does it reuse the existing SP- connection and just refresh the token?

Appreciate your insights!