The refresh worked fine for months. Then multi-factor authentication was switched on for your Blackbaud sign-in, and the Excel workbook or Power BI report pulling from an Altru query’s OData feed started throwing credential errors. Nobody changed the query. Nobody changed the report. The only thing that changed was how you prove who you are.
That’s the core of the problem, and it’s worth understanding before you start re-entering passwords. This article explains why OData and MFA clash, what you can try, what to ask Blackbaud, and when it’s smarter to stop fighting the connection and move the data another way.
Why MFA breaks an OData connection
An OData feed is just a URL that returns query results in a structured format. The tool on the other end (Excel’s Power Query, Power BI, a script, a reporting connector) has to authenticate every time it asks for data. Historically, many of those tools did that with a stored username and password, sent quietly in the background.
MFA is designed to stop exactly that. A second factor (a code from an app, a push notification, a text message) needs a person to respond. A scheduled refresh running at 2 a.m. has no person to tap “approve.” So a connection that relied on a saved password either fails outright or prompts for a sign-in it can’t complete.
Two things matter here:
- What kind of sign-in your Altru environment uses. Blackbaud sign-in and its MFA options have changed over time, and your organization’s settings may differ from another site’s.
- What authentication methods your client tool supports for that feed. “Basic” authentication (username and password) is the one most likely to break. Some tools also offer an interactive browser-based sign-in, which can handle MFA when someone is present, but may not survive an unattended refresh.
We can’t tell you with certainty which combination will work for your specific setup. Treat the steps below as a diagnostic path, not a guaranteed fix.
Things to try, in order
1. Clear the saved credentials and reconnect
In Excel or Power BI, the old stored credential for the feed’s URL often sticks around and keeps failing. Remove it from the tool’s data source settings, then refresh and see which sign-in options it offers. If you get a choice beyond plain username and password, try the browser or organizational sign-in option and complete MFA when prompted.
2. Test a manual refresh before a scheduled one
If a manual refresh works with you at the keyboard but the scheduled refresh fails, you’ve confirmed the issue: the tool can’t complete MFA on its own. That’s useful information to bring to support, and it tells you a reconnect alone won’t solve the overnight job.
3. Ask Blackbaud support the specific question
Don’t open a ticket that says “OData is broken.” Ask something they can answer directly:
- Which authentication methods are supported for Altru OData feeds when MFA is enabled?
- Is there a supported way to run unattended refreshes (for example, a dedicated account or token-based approach), and what are the security requirements for it?
- Are there known limitations with specific tools such as Power BI scheduled refresh?
Their answer is the authority here, because sign-in behavior is controlled on Blackbaud’s side, not in your query.
4. Check how the query itself is set up
While you wait, confirm the query still exists, hasn’t been renamed or had its permissions changed, and returns results when you run it inside Altru. It’s easy to blame MFA for a failure that’s really a broken query or a user who lost access to it.
What not to do
- Don’t turn MFA off to get a report working. The account that can read constituent and revenue data is exactly the one that should be protected.
- Don’t share one person’s login so a report can borrow it. When that person leaves or resets their phone, the report dies, and you’ve created an account nobody can audit.
- Don’t paste credentials into a shared workbook or a script sitting on a shared drive.
When to stop relying on OData
OData is convenient for an analyst refreshing a workbook. It’s less convenient as the backbone of an automated process that other people depend on. If the data is feeding something operational (a daily attendance sheet for the front-of-house team, a mailing list, a board dashboard that must update without anyone touching it), ask whether a live OData connection is really the right tool.
Alternatives worth weighing:
- Scheduled exports from Altru queries that a person reviews and drops into a shared location. Lower tech, but predictable, and someone actually looks at the data.
- A sync tool built for Altru queries that handles the connection and pushes results to the place your team already works.
- Narrower queries. Whatever route you pick, send only the fields people need. Fewer columns of constituent data leaving Altru means less to secure downstream.
Quick answers
Can I still use OData with MFA turned on?
Often yes for interactive use, where you sign in and approve the prompt. Unattended scheduled refreshes are the part most likely to fail, and whether there’s a supported workaround is a question for Blackbaud support.
Is the problem in my Altru query?
Usually not, if the query runs normally inside Altru. The failure is in how the outside tool authenticates. Verify the query anyway before escalating.
A different route for recurring data
If what you really need is Altru query results showing up in Google Sheets, Mailchimp, or ActiveCampaign on a regular basis, Social Good’s Data Bridge syncs Altru query data to those tools, so your team isn’t depending on someone’s personal workbook connection staying signed in.
