RCPmag first reported the planned integration on August 11, saying Blackbaud customers will be able to bring Raiser’s Edge NXT intelligence into Microsoft 365 Copilot while retaining the fundraising system’s existing permission controls. Blackbaud’s public Raiser’s Edge NXT product materials already advertise integration with Microsoft 365 and the Power Platform, but the Copilot connection is a distinct step: it moves the donor database into a natural-language research workflow that could be used while staff prepare outreach, review portfolios, or assemble meeting briefs.
For IT teams, the headline is not merely that Copilot can see another business system. It is that Blackbaud appears to be using Microsoft’s newer federated connector model, where the system of record remains Blackbaud and Microsoft 365 Copilot calls it at runtime under the user’s identity. That is a materially different data-governance posture from older Microsoft Graph connectors that crawl and index third-party data into Microsoft 365.
The connector is expected to be live-query, not a donor-data migration
Microsoft’s current documentation describes MCP-based federated Copilot connectors as real-time connections to external systems. They do not index source material into Microsoft 365, and the external application continues to enforce the user’s permissions. For a fundraising database, that distinction matters: constituent profiles, gift histories, relationship notes, prospect research, and fundraising opportunities can be highly sensitive even where they are not technically classified as regulated personal data.
In a conventional synchronized connector, an organization accepts a second data store and the operational burden that comes with it: connector crawling, identity mapping, indexing behavior, retention, search visibility, and the possibility that source-system permission changes take time to propagate. Microsoft says a federated connector instead fetches information dynamically through MCP and leaves the source data in place.
That does not mean the data never leaves Blackbaud during use. A user’s request and the returned information must still travel between Microsoft 365 Copilot and Blackbaud’s remote service to answer the prompt. The practical claim is narrower: Microsoft 365 does not build a standing searchable copy of the external dataset through this connector model.
For nonprofits, that can reduce one category of exposure, particularly for organizations reluctant to make donor information broadly discoverable through Microsoft Search or a Microsoft Graph index. It also means a response should reflect the current Raiser’s Edge NXT record rather than last night’s connector crawl. A gift entered, prospect reassigned, or constituent marked confidential in the source platform should be seen according to the live system state, assuming Blackbaud’s MCP implementation correctly applies those controls.
The tradeoff is dependency. If the Blackbaud service, its API, authentication flow, or the connector itself is unavailable, Copilot loses access at the moment of query. A live connector is better suited to lookup and research than to treating Copilot as an archival copy of the fundraising system.
“Existing permissions” is a starting point, not a deployment plan
RCPmag reports that the integration will preserve existing permissions and security controls. Microsoft’s federated-connector framework is designed around that model: users authenticate with their own credentials and the external source decides which records and fields they can access. Microsoft also says partner federated connectors require tenant-admin approval before they can be enabled.
That offers a better default than a broad service account that exposes the same donor information to everyone with Copilot. It does not remove the work that nonprofit administrators must do before opening the connection to a development office.
Raiser’s Edge NXT roles, constituent-security settings, record-level restrictions, user provisioning, and offboarding must already be reliable. Copilot can respect only the authorization decision Blackbaud gives it. An organization that has allowed informal shared accounts, overbroad fundraising roles, stale users, or inconsistent constituent restrictions has not solved that access problem by putting an AI layer in front of the data.
There is a second issue: a permission check governs whether a user may retrieve a record, but it does not by itself determine how much context Copilot should be allowed to assemble in one answer. A fundraiser may have legitimate access to multiple constituent records separately. A prompt such as “summarize our donors who have given more than $25,000, attended events in the last year, and have unresolved stewardship tasks” could pull those permitted records into a convenient aggregate. That may be useful operationally, but it changes the ease and scale of access.
Microsoft’s published federated-connector guidance says these connectors are read-only and auditable in Microsoft Purview. Those are welcome controls, but Blackbaud and Microsoft have not publicly specified the audit granularity for this proposed Raiser’s Edge NXT integration: whether administrators will see the user prompt, the exact connector tool call, which donor records were returned, or only a general Copilot activity event. They also have not described how the connector will treat sensitive Raiser’s Edge NXT fields, attachments, actions, relationship notes, wealth information, or custom fields.
Those omissions are significant because Raiser’s Edge NXT is not a generic document repository. The record types that make a fundraising CRM valuable also make careless AI access risky. A donor’s giving history may be routine for a major-gifts officer; prospect-research notes, personal circumstances, family relationships, and internal strategy can be much more sensitive.
Microsoft’s own rollout model puts the tenant admin in the middle
The early-adopter wording should temper expectations. RCPmag did not report a general-availability date, eligible regions, licensing requirements, participating tenant types, pricing, or the number of customers Blackbaud expects to admit. Neither the reported account nor the currently published Microsoft connector documentation establishes that every Raiser’s Edge NXT customer with Microsoft 365 Copilot will automatically receive the integration.
Microsoft’s partner process provides a likely explanation for the staged approach. A vendor submitting an MCP server for the Microsoft 365 Copilot Connectors Gallery must provide technical metadata, test credentials, sample prompts, and evidence that the exposed tools meet Microsoft’s requirements. Microsoft says partner connectors undergo review, then release discussions and ring-based rollout planning. After Microsoft approves and publishes a partner connector, each tenant administrator must still approve it before it becomes available in that tenant.
That is not a cosmetic approval step. Microsoft’s documentation says federated connectors can be enabled or disabled centrally, and partner connectors are not simply switched on by default. Organizations can also stage a custom federated connector to selected users or groups before broader deployment.
The deployment pattern nonprofit IT departments should favor is therefore obvious: begin with a narrow pilot of development operations staff and senior gift officers who already have well-defined Raiser’s Edge NXT access. Use a controlled set of prompts built around real work, such as account preparation, portfolio review, and meeting summaries. Check whether the answers accurately represent gifts, relationships, open opportunities, and data freshness before extending access to a wider fundraising team.
The pilot should also test undesirable but plausible requests. Can a user retrieve records they should not see? Does Copilot expose a restricted field through a summary even when the raw record view is blocked? Can a request accidentally combine information from several sources and lead a fundraiser to treat generated text as a verified donor profile? Those are implementation questions, not reasons to reject the connector outright.
Read-only access limits the first release, and that is appropriate
Microsoft’s current rules for gallery-submitted federated connectors allow search and fetch tools, requiring them to be annotated as read-only. If Blackbaud’s integration follows that program, the first release should allow Copilot to retrieve information but not to create constituent records, enter gifts, update opportunities, log actions, or alter stewardship plans.
That is an important boundary. The language around AI workflows can suggest an assistant that completes fundraising work from a conversational prompt. The available Microsoft framework instead points toward a controlled research interface: Copilot locates and summarizes authorized Blackbaud information, but staff remain responsible for validating it and making changes in Raiser’s Edge NXT.
Blackbaud has been building its own AI features inside fundraising products, including Blackbaud Copilot and natural-language interaction with donor information. The Microsoft 365 Copilot arrangement expands the interface rather than replacing that product direction. It gives nonprofits a chance to use the assistant already present in their Microsoft workday, but it also makes clear that Blackbaud wants its system of record to supply the underlying facts and authorization decisions.
There is already evidence that the market has been moving this way. CData, for example, documents an MCP server for Raiser’s Edge NXT that exposes live Blackbaud data to Claude Desktop. Blackbaud’s proposed Microsoft 365 Copilot connection would be more consequential for many organizations because it would be deployed through an enterprise Microsoft service, subject to Microsoft’s tenant-level administration and connector governance, rather than assembled as an individual desktop AI integration.
The missing facts now matter more than the announcement itself. Blackbaud has not publicly detailed the early-adopter timetable, the fields and Raiser’s Edge NXT objects available to Copilot, or the Microsoft 365 Copilot experiences that will support the connector. Microsoft currently lists federated-connector support in Copilot Chat, Copilot in Excel, and the Researcher agent, but that does not confirm that every one of those experiences will be enabled for Blackbaud at launch.
For nonprofits interested in the program, the immediate action is to treat it as an identity-and-data-access project, not a simple Copilot feature switch. The connector may keep donor data out of a Microsoft 365 index, but it will still make that data easier to ask for—and that makes existing Raiser’s Edge NXT permissions, role design, audit practices, and user training the controls that will determine whether the integration is useful or reckless.