A question we hear most weeks now, from fundraising directors and operations leads alike: “our team already uses an artificial intelligence assistant, can it talk to our Salesforce?”

The short answer is yes, and 2026 is the year that stopped being a science project. The longer answer is worth ten minutes of your time, because how you connect matters far more than whether you can. Here is the plain English version.

Where charities are starting from

Before the routes, a picture of the starting point, drawn from the steering groups and planning sessions we have sat in this summer.

The appetite is real, and it is coming from the top. A head of fundraising told us she thinks the sector is “at the brink of what’s possible” and that the more data her team puts into Salesforce, the more it will show them what it can do. A digital lead at a national charity had just been added to his organisation’s new artificial intelligence steering group, and told us the reason he is fixing the back end now is to get to the artificial intelligence pieces. A programme manager watching an agent demo said it felt like a case of striking while the iron is hot. Teams are conscious of not wanting to be left behind, and finance directors are asking what the licence costs rather than whether to bother.

Nearly every organisation is already using an assistant day to day, usually whatever came with the Microsoft or Google licence, sometimes a paid ChatGPT or Claude account that a few people lean on heavily. Very few are running agents yet, though the first Agentforce designs are now going through steering groups, and none has connected a general assistant to supporter or service user data.

Every leader who told us they want this also told us, in the same conversation, that the foundations come first: the data is not clean enough, the team is not yet using the system consistently, consent is not recorded everywhere it needs to be. They are right, and they are not being timid. A recent data leak elsewhere in the sector has made everyone more careful about anything that touches personal data, and the data protection officer now sits in the room for these decisions, asking where the data goes, whether it is used for training, and whether a person still makes the calls that matter.

That is the mood: keen, clear-eyed and waiting for the groundwork to be done. The three routes below are the ways in. The checklist at the end is the groundwork.

Route one: agents that live inside Salesforce

The first route is Salesforce’s own: Agentforce, the platform for building artificial intelligence agents that live where your data lives. An Agentforce agent works inside your org, uses the permissions and security model you already run, and acts on records directly: summarising a donor’s history, drafting a follow-up, updating a case.

The strength of this route is that closeness. Nothing leaves the platform, governance is Salesforce governance, and the agent can act rather than just answer. The trade-off is that it is a Salesforce product decision, licensed and configured as part of your org.

Route two: your assistant, connected in

The second route is newer and explains the sudden change in what is possible. Your team’s existing assistant, such as Claude or ChatGPT, can now connect directly to Salesforce through the Model Context Protocol (MCP), an open standard published by Anthropic, the maker of Claude, in late 2024. Think of it as a universal connector between artificial intelligence assistants and business systems: one standard plug instead of a custom integration for every pairing. If your organisation has standardised on Microsoft, ask whether your Copilot licence can use the same standard, because the answer is changing quickly.

Salesforce announced support for the standard in June 2025 and its hosted Model Context Protocol servers, piloted through 2025, reached general availability in spring 2026, included with Enterprise Edition and above at no extra cost. In practice, this means a fundraiser can ask their assistant “which of our regular givers lapsed in the last quarter and what do we know about why”, and get an answer drawn live from your Salesforce, without an export, a spreadsheet or a developer.

One design decision in Salesforce’s implementation deserves highlighting, because it carries most of the security weight: every request runs with the identity of the person asking. The assistant sees what that person can see, and nothing more. Your existing Salesforce permissions, sharing rules and audit trail all apply. Get those right and the assistant inherits them; get them wrong and the assistant inherits that too.

Route three: the plumbing

The third route is the oldest: integration tools such as MuleSoft and the platform’s application programming interfaces (APIs), moving data between Salesforce and other systems. This is not new and not specific to artificial intelligence, but it is often the unglamorous prerequisite, because an assistant can only reach the data that has actually made it into Salesforce. If your event platform, payment provider or case management tool holds data your customer relationship management (CRM) system never sees, no protocol fixes that.

Before you connect anything

The technology is now the easy part. These six checks are the hard part, and they are all within your control:

1. Review permissions first. The connected assistant is only as safe as the sloppiest permission set in your org. If people can see more than their role needs, fix that before connecting anything, not after.

2. Start in a sandbox. Salesforce lets you enable these connections in a test environment. Prove the value and the guardrails there before anyone touches production supporter data.

3. Have a written artificial intelligence policy. Which tools are approved, what data may never leave your systems, who authorises new connections. As we noted in our look at the Charity Digital Skills Report 2026, only 36% of small charities have one, and connecting an assistant to your CRM without one is the wrong order.

4. Mind the data quality. An assistant answering from duplicated, stale records gives wrong answers fluently. The same data foundation that makes supporter communications work makes connected assistants trustworthy.

5. Keep a human on anything outbound. Answers and summaries for staff are the right starting point. Anything that reaches a supporter, a participant or a funder should have a person approving it while you build confidence.

6. Know where the data goes. Before approving any assistant, get clear answers from the vendor on where prompts and responses are processed and stored, how long they are kept, and whether they are used to train future models. Business and enterprise plans from the main providers usually exclude training by default and offer a data processing agreement; consumer accounts usually do not. Your policy in check three should name the plans that are approved, not just the tools.

How we know this works

We are not writing from the brochure. Cirrico runs artificial intelligence tooling connected to our own systems, governed by a written security position covering permissions, approved tools and data boundaries, and we felt the difference within weeks: less time hunting for context, faster preparation, better answers. We also felt where the guardrails matter, which is why the checklist above comes before the enthusiasm.

If your charity is weighing up any of the three routes, or being pitched all of them at once, book a discovery call. We will help you work out which connection serves your mission, and which permissions review needs to happen first.