How to prevent pipelines from failing when the user account they were created with is deleted?

[KerenLopez]

Hi everyone!

I have several pipelines in Microsoft Fabric that recently failed because the user account used to create them was eventually deleted from Fabric due to company policies. In my case, the organization that owns the Fabric environment provided me with a user account to work within their platform, but this account is renewed every month. Once the account is deleted and recreated, the pipelines stop working because they rely on my personal user authentication.

Here is the error message:
Failed to get User Auth access token. The error message is: Failed to get User Auth access token. The error message is: AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '2025-07-25T13:53:33.1502935Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '2025-08-04T13:26:44.0000000Z'.

Is there a way to configure pipelines so they are not tied to a personal user account? For example, could I associate them with a Managed Identity, Service Principal, or any other non-expiring authentication method so they continue working even when my personal account changes?

Any insights or troubleshooting steps would be greatly appreciated.

Thanks in advance!

[Vinodh247 · Accepted solution]

I think its because the pipeline activities in fabric are tied to your personal AAD user authentication context, and once your account is deleted, the OAuth refresh token chain breaks.
The proper way to prevent this is to move your pipeline authentication to a non-user, nonexpiring identity such as a SPN or Managed Identity, depending on the data source

When you build a pipeline in Microsoft Fabric and authenticate connections using your user account:

• Fabric stores a refresh token tied to your AAD account.
• When the account is deleted or recreated, all refresh tokens are invalidated (TokensValidFrom changes).
• Pipelines depending on that token fail until someone re-authenticates.

This is not specific to Fabri, it is the same for Power BI, ADF, synapse pipelines, etc., when personal accounts are used.

How to make pipelines user independent?

Use a Service Principal for authentication

For most Fabric connectors (Azure SQL, Data Lake, Blob Storage, etc.), you can:

• Create an App Registration in AAD (your org's AAD admin must do this).
• Assign necessary RBAC roles or permissions (ex: Storage Blob Data Contributor on storage accounts).
• Configure the Fabric data connection to use Service Principal auth (Client ID + Secret or Certificate).
• Update your pipeline activities to use this connection instead of your personal account.

Pros: Works long term, unaffected by user account deletion.
Cons: Requires AAD admin involvement, not supported by every connector in Fabric yet.

Use Managed Identity (if Fabric supports it for your source)

• If your Fabric workspace is in a Premium capacity linked to an Azure resource, it can sometimes leverage Managed Identity to authenticate without storing secrets.
• You would enable Managed Identity on the Fabric capacity or connected service, then grant it permissions at the data source.
• Not all Fabric pipeline connectors support MI today, check the official Fabric data connection authentication documentation for connector-specific support.

Shared or Service Account (last option)

• If Service Principal is not available for your connectors, you can create a dedicated nonexpiring service account in AAD.
• Assign it the required permissions and use it for authentication in Fabric.
• This is less ideal because it is still a user account, but at least it is not tied to you personally.

Pipeline migration approach

• Identify all data connections in your pipelines.
• For each, reconfigure to use Service Principal or Managed Identity authentication.
• Test the pipelines after switching to ensure there are no hidden dependencies on your user context.
• Document and standardise this as a best practice in your team so all new pipelines avoid personal accounts.

Finally, always keep in mind that never tie production pipelines to a personal, expiring account. In Fabric, the safest approach is to move to SPN auth for all supported connectors, and only fall back to service accounts or Managed Identity where appropriate.

Please 'Kudos' and 'Accept as Solution' if this answered your query.

[V-yubandi-msft]

Hi @KerenLopez ,

Thank you for engaging with the Microsoft Fabric Community and I agree with @NandanHegde  explanation. You are correct that using a personal AAD account for pipeline authentication can cause token expiry problems if the account is deleted or recreated.

Switching to a Service Principal or Managed Identity is the best solution, depending on which connectors you use. If your deleted account was also set as the pipeline owner, you may need to transfer ownership refer to the guide.

Feel free to let me know if you need any additional details or clarification.

Best,

Yugandhar.

[NandanHegde · Accepted solution]

There can be 2 aspects pertaining to that :

1) The account has created the connection and has his/her own OAUTH

2) the account is the owner of the pipelines :

plz follow the below doc:

https://learn.microsoft.com/en-us/fabric/fundamentals/item-ownership-take-over

[Vinodh247 · Accepted solution]

I think its because the pipeline activities in fabric are tied to your personal AAD user authentication context, and once your account is deleted, the OAuth refresh token chain breaks.
The proper way to prevent this is to move your pipeline authentication to a non-user, nonexpiring identity such as a SPN or Managed Identity, depending on the data source

When you build a pipeline in Microsoft Fabric and authenticate connections using your user account:

• Fabric stores a refresh token tied to your AAD account.
• When the account is deleted or recreated, all refresh tokens are invalidated (TokensValidFrom changes).
• Pipelines depending on that token fail until someone re-authenticates.

This is not specific to Fabri, it is the same for Power BI, ADF, synapse pipelines, etc., when personal accounts are used.

How to make pipelines user independent?

Use a Service Principal for authentication

For most Fabric connectors (Azure SQL, Data Lake, Blob Storage, etc.), you can:

• Create an App Registration in AAD (your org's AAD admin must do this).
• Assign necessary RBAC roles or permissions (ex: Storage Blob Data Contributor on storage accounts).
• Configure the Fabric data connection to use Service Principal auth (Client ID + Secret or Certificate).
• Update your pipeline activities to use this connection instead of your personal account.

Pros: Works long term, unaffected by user account deletion.
Cons: Requires AAD admin involvement, not supported by every connector in Fabric yet.

Use Managed Identity (if Fabric supports it for your source)

• If your Fabric workspace is in a Premium capacity linked to an Azure resource, it can sometimes leverage Managed Identity to authenticate without storing secrets.
• You would enable Managed Identity on the Fabric capacity or connected service, then grant it permissions at the data source.
• Not all Fabric pipeline connectors support MI today, check the official Fabric data connection authentication documentation for connector-specific support.

Shared or Service Account (last option)

• If Service Principal is not available for your connectors, you can create a dedicated nonexpiring service account in AAD.
• Assign it the required permissions and use it for authentication in Fabric.
• This is less ideal because it is still a user account, but at least it is not tied to you personally.

Pipeline migration approach

• Identify all data connections in your pipelines.
• For each, reconfigure to use Service Principal or Managed Identity authentication.
• Test the pipelines after switching to ensure there are no hidden dependencies on your user context.
• Document and standardise this as a best practice in your team so all new pipelines avoid personal accounts.

Finally, always keep in mind that never tie production pipelines to a personal, expiring account. In Fabric, the safest approach is to move to SPN auth for all supported connectors, and only fall back to service accounts or Managed Identity where appropriate.

Please 'Kudos' and 'Accept as Solution' if this answered your query.