On 26 August 2026, Salesforce and Anthropic announced Claudeforce, an expanded partnership that puts Salesforce data, workflows, and governed actions directly inside Claude.
The core is Salesforce in Claude, a plugin with 37 prebuilt sales skills that lets sellers query, update, and act on live CRM data without opening Salesforce at all.
Salesforce CEO Marc Benioff called it a direct answer to "SaaSpocalypse" concerns, and the market agreed. CRM shares jumped in after-hours trading the moment the news broke.
For most of the Salesforce ecosystem, this is a signal to start planning. For ProvidusCRM, it is confirmation of a direction we have already been building in production.
At ProvidusCRM, We Were Already Building This
Almost a year before Claudeforce existed, ProvidusCRM was already combining Salesforce modernisation with Claude-powered intelligence.
We worked with a North American nonprofit organisation with approximately 180 employees and more than 35 Salesforce users to migrate its Salesforce environment from the Nonprofit Success Pack (NPSP) to Nonprofit Cloud while using Claude to accelerate the discovery, analysis, and redesign work involved in the migration.
The project involved more than simply moving records from one Salesforce environment to another. The organisation had accumulated years of constituent, fundraising, donation, engagement, automation, integration, and business-logic data inside NPSP.
Claude was used alongside Salesforce metadata and project documentation to help the team understand the existing environment, identify dependencies, accelerate data and configuration mapping, and then introduce AI-assisted workflows into the new Nonprofit Cloud environment.
Claudeforce validates the underlying approach we took: intelligence and reasoning from Claude, wrapped in Salesforce's governance, data model, and trusted workflows.
We reached that conclusion independently, through delivery work, before either company put a name on it.
The Problem We Solved
The client is a North American nonprofit organisation with approximately 180 employees and more than 35 Salesforce users. Salesforce had become central to its constituent, fundraising, donation, engagement, and operational processes.
After several years on Salesforce NPSP, the organisation had accumulated a significant amount of historical data, custom configuration, automation, integrations, and business logic.
The challenge was not simply moving records from NPSP to Nonprofit Cloud.
The real challenge was understanding what the existing Salesforce org actually did, determining which functionality was still required, and deciding what should be migrated, redesigned, replaced, or retired.
The client also had a relatively small internal Salesforce team. They needed a cleaner Salesforce Nonprofit Cloud environment that their administrators could understand and maintain after go-live rather than another heavily customised Salesforce implementation.
Key areas requiring attention included:
- More than 160,000 constituent and contact records.
- Approximately 30,000 historical donation and fundraising records.
- A large collection of custom fields and legacy configuration built up over years of NPSP usage.
- Existing Salesforce Flows and automations support fundraising, constituent management, receipting, consent, and other processes.
- External integrations and integration users had to continue operating after the migration.
- Legacy NPSP data structures that did not map one-to-one to the Nonprofit Cloud model.
- Donation and receipt processes involving different sources and channels.
- Consent and communication preferences needed to be preserved and redesigned around Salesforce's newer consent model.
- Complex relationships between donors, donations, campaigns, funds, fundraising pages, and external platforms.
The organisation therefore needed a migration based on understanding the existing system first, rather than simply copying its old configuration into Nonprofit Cloud.
How We Used Claude
One of the most valuable parts of the project was using Claude alongside Salesforce metadata and project documentation to accelerate the discovery and migration process.
Rather than treating AI as a chatbot for end users, we used Claude as an additional layer of intelligence over the existing Salesforce environment.
Claude was given access to the relevant Salesforce metadata and configuration information, allowing the team to interrogate the existing environment and understand relationships between:
- Objects and fields
- Flows and automation
- Custom functionality
- Data relationships
- Integrations
- Business rules
- Legacy NPSP configuration
- Reporting dependencies
This helped the team answer questions that are normally time-consuming during an NPSP migration:
- What does this field actually do?
- Which automation depends on it?
- Where is this data being used?
- Is this legacy configuration still required?
- What should this NPSP structure become in Nonprofit Cloud?
- What external process depends on this Salesforce field or object?
Instead of reviewing thousands of pieces of configuration independently, Claude helped the team analyse the metadata and identify relationships and dependencies that could then be validated by the Salesforce implementation team.
This became particularly useful when analysing older custom functionality where the original business context was no longer obvious from the Salesforce configuration itself.
Migration Architecture and Discovery
We began by auditing the existing NPSP environment and documenting the client's current data model, configuration, automation, integrations, and business processes.
The objective was to create a clear picture of the existing Salesforce org before designing the target Nonprofit Cloud environment.
Claude was used during this process to help analyse the available metadata and configuration and accelerate the mapping exercise.
The team then categorised existing functionality into three groups:
Migrate
Functionality that remained business-critical and had a clear path into Nonprofit Cloud.
Redesign
Functionality that was still required but needed to be rebuilt around the Nonprofit Cloud data model or newer Salesforce capabilities.
Retire
Legacy fields, automation, and customisations that no longer provided meaningful business value.
This prevented the project from becoming a simple "lift and shift" from NPSP to Nonprofit Cloud.
Data Mapping and Transformation
The migration involved more than moving records between Salesforce objects.
NPSP structures had to be mapped into the target Nonprofit Cloud architecture while preserving the relationships that staff depended on for fundraising and constituent management.
Claude was used to support the mapping process by analysing the existing metadata, field definitions, relationships, and legacy configuration.
This helped the team understand not only where a field was stored but also how that field was being used elsewhere in the Salesforce environment.
The migration process covered:
- Constituent and contact data
- Historical donations
- Fundraising information
- Campaign and engagement relationships
- Custom fields
- Legacy NPSP structures
- Consent and communication preferences
- Receipt-related information
- Integration identifiers and dependencies
Data was tested through repeated migration cycles rather than relying on a single production migration.
Understanding and Rebuilding Existing Workflows
The existing Salesforce Flows were treated as business processes rather than simply technical assets.
Each automation was reviewed to understand:
- What triggered it?
- Which records did it update?
- What business rule was it implementing?
- Did the process still make sense in Nonprofit Cloud?
- Could it be simplified?
- Could it be replaced with standard Salesforce functionality?
- Did an external integration depend on it?
Claude helped accelerate this analysis by allowing the team to reason across the metadata and existing configuration instead of examining individual components in isolation.
The result was a more deliberate approach to automation.
Some processes were rebuilt.
Some were consolidated.
Some were simplified.
And some legacy automation no longer needed to exist.
External Integrations
The migration also required careful consideration of systems outside Salesforce.
The client had processes involving external fundraising and payment platforms, including LaunchGood, Pillar, Stripe, and other integration points.
These integrations introduced dependencies that could easily be missed during a conventional Salesforce migration.
For example, the team had to investigate how externally generated donations were mapped into Salesforce, how fundraising information was associated with donations, how transaction identifiers were preserved, and how external systems interacted with Salesforce receipt and consent processes.
Claude was also useful here as a way of analysing the Salesforce-side metadata and configuration surrounding these integrations.
Rather than treating an integration as simply:
External System → Salesforce
We analysed the surrounding Salesforce objects, fields, Flows, mappings, integration users, and downstream processes to understand the complete workflow.
This was particularly important where the same donation could pass through multiple processes before reaching the final Salesforce record.
Consent and Communication Preferences
Consent management became another example of why the migration could not be treated as a simple data conversion.
The existing processes around email preferences, marketing consent, administrative communication, and donation receipts had to be reconsidered within the Nonprofit Cloud model.
The team moved toward Salesforce's standard consent architecture, using Contact Point and Consent records to represent channel-specific preferences.
The design distinguished between:
- Marketing consent
- Administrative communication
- Email preferences
- Other communication channels
- Donation receipt preferences
For example, marketing email consent was treated separately from the operational process of issuing a donation receipt.
The team also addressed scenarios involving multiple email addresses, changes to consent, historical consent records, and external donation sources.
This was another area where understanding the existing business logic was more important than simply migrating an old checkbox into a new field.
Claude-Powered Workflows
After the core Nonprofit Cloud foundation was established, we also used Claude to introduce AI-assisted workflows directly into Salesforce.
Using the MuleSoft for Flow Anthropic Connector, we connected Claude with Salesforce Flow so AI could operate as part of existing Salesforce processes rather than requiring users to move information into a separate AI application.
Several Flow-based use cases were developed, including:
Constituent Summarisation
A record-triggered Flow gathered relevant Salesforce information and passed it to Claude to generate a concise summary for staff.
This reduced the need for users to manually review multiple records before understanding a constituent's history and recent interactions.
Request Classification
An auto-launched Flow used Claude to classify incoming information and support routing to the appropriate team or process.
Recurring Summaries
Scheduled automation was used to generate recurring summaries so staff could surface relevant information without manually assembling it from multiple Salesforce records.
The prompts were refined through testing, with the Salesforce team validating outputs and adjusting the instructions, data supplied to Claude, and Flow logic.
Where AI was not appropriate or the result did not meet the required conditions, the existing human process remained available.
Testing the Real Salesforce Environment
Testing was performed at multiple levels.
The team validated:
- Record migration
- Relationships between records
- Field mappings
- Historical donation data
- Fundraising and campaign relationships
- Salesforce Flows
- External integrations
- Consent behaviour
- Receipt logic
- User workflows
- AI-generated summaries and classifications
Importantly, testing wasn't limited to checking whether records existed.
The team tested whether the business processes still worked after the data moved.
For example, donation testing included scenarios involving external fundraising sources, receipt information, consent preferences, and different communication outcomes.
This helped uncover issues that a basic record-count validation would not have identified.
The Outcome
The outcome was more than an NPSP-to-Nonprofit Cloud migration.
The organisation moved from a Salesforce environment shaped by years of incremental customisation toward a cleaner Nonprofit Cloud foundation designed around its current operating model.
The project delivered:
- A modernised Nonprofit Cloud data foundation.
- Migration of historical constituent and fundraising information.
- A structured review of legacy NPSP customisation and automation.
- Simplified and redesigned Salesforce workflows.
- Better understanding of dependencies between Salesforce and external integrations.
- A more structured consent and communication model.
- AI-assisted constituent and operational workflows directly within Salesforce.
- A migration approach that the internal Salesforce team could understand and continue to maintain.
Most importantly, Claude was not treated as an AI add-on after the Salesforce implementation was finished.
It became part of the implementation methodology itself—helping the team understand the legacy Salesforce environment, accelerate metadata and data mapping, analyse workflow dependencies, reason about external integrations, and then power new AI-assisted Salesforce processes.
That changed the role AI played in the project.
Instead of asking:
"Where can we add AI to Salesforce?"
The better question became:
"How can AI help us understand, modernise, and operate Salesforce better?"
For this migration, Claude was used for both sides of that equation: understanding the old Salesforce environment and building new intelligent workflows on the new Nonprofit Cloud foundation.
Why This Matters Now
Claude now belongs inside Salesforce, governed by Salesforce's data and workflow rules rather than sitting beside them.
For nonprofits, that shift is especially significant.
Many organisations have spent years building valuable constituent, fundraising, engagement, and program data inside NPSP. Moving to Nonprofit Cloud creates an opportunity to do more than simply migrate that data.
It creates an opportunity to rethink the Salesforce architecture underneath it and introduce AI into the workflows that staff already use.
That's exactly what we did with this engagement.
We combined an NPSP-to-Nonprofit Cloud migration with Claude-powered Salesforce intelligence, using Claude not only to power new AI-assisted workflows but also to help the implementation team understand and modernise the legacy Salesforce environment.
The migration architecture, metadata analysis, data mapping, Flow analysis, integration review, consent redesign, prompt engineering, testing, and rollout process are not theoretical for us.
We've already worked through them in a live nonprofit environment.
If your organisation is running NPSP and considering a move to Nonprofit Cloud, now is the time to think beyond simply moving your existing Salesforce setup.
The question isn't just how to migrate your data. It's what you want your new Salesforce environment to be capable of doing.
Explore ProvidusCRM's Salesforce integration services to find out what an NPSP-to-Nonprofit Cloud migration with Claude-powered Salesforce intelligence could look like in your organisation.
