Errored Windows Authentication (Non Shared) connections being cached

(1) Share

Report

Posted on by CU09010416-0

Is anyone else having issues with cached broken connections using Windows Authentication (Non Shared) connections to SQL Server?

I have a situation that if anything is wrong with the users login, e.g. they don't have the correct permissions on the database, they are then never able to login even once this issue is fixed. With many users of the connection, it's not workable to have to rebuild connections each time one user has an issue.

Has anyone experienced this? Is there a simple fix to the broken cached connection?

Categories:

Connector development

Building Power Apps

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Vish WR 3,748 on at

Like
a
(1)

Report
Copy link

Link copied!

@CU09010416-0

When a user’s SQL login fails once (e.g. due to missing permissions), Power Apps caches that failed connection. Even after fixing access in Microsoft SQL Server, the connection stays broken and doesn’t retry properly

You could delete and recreate the connection and republish. Also try clearing the browser cache

For a long-term solution, use a shared/service account or switch away from Windows Authentication.

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(1)

Report
Copy link

Link copied!

Yes, this is a known issue with non-shared Windows Authentication SQL connections in Power Platform, where failed authentication states get cached and persist even after permissions are corrected.

There is no clean way to reset the cached state;

the most reliable fix is to delete and recreate the connection or switch to a shared/service account-based connection to avoid the issue entirely.

Was this reply helpful? Yes No
RC-24040335-0 4 on at

Like
a
(1)

Report
Copy link

Link copied!

This is unfortunate with Microsoft recommending this connection type. It's unusable in a real business. Deleting the connection means people are bothered with reauthentication. So we're back to using service accounts, which allow anyone with access to use the data even if this isn't data they should see. Effectively, database security has to be bypassed to get Power Apps to work in the real world.

Was this reply helpful? Yes No
Suggested answer

Valantis 6,735 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @CU09010416-0,

The caching issue is real and delete/recreate is the only fix for it right now, no argument there.

On the service account vs security concern though Microsoft actually documents SQL Server Row Level Security as the way to handle this properly. You use a service account for the connection, but SQL RLS filters rows server-side based on the user's identity. That way the service account connects fine, but each user only sees what they're supposed to.

The catch: this works cleanly when using Azure AD Integrated auth, since the Entra identity flows through. For on-premises SQL with Windows Auth it gets more complex. Worth knowing if you're considering a migration path.

Doc reference: https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/connections/sql-server-security

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No