What Should Nonprofit Salesforce Managed Services Include?

The minimum layer

A credible baseline managed service should normally cover:

1. user and licence administration
2. permissions and access
3. configuration changes
4. Flow/automation support
5. reports and dashboards
6. issue troubleshooting
7. release/change review
8. user support
9. documentation
10. a predictable request/change process

Those are important, but they are not the entire operating problem.

The next layer: data integrity

Ask the provider:

• Do you proactively check missing required information?
• Do you find duplicates?
• Do you normalize inconsistent values?
• Do you validate impossible dates or state transitions?
• Do you check closed records for required outcomes?
• Do you identify unused fields and stale configuration?
• Do you report trends, not only fix isolated records?

If the answer is “we can clean data when requested,” data quality is still being managed reactively.

The next layer: integration reconciliation

Many nonprofit workflows cross systems, for example:

• Website → donation form → payment processor → Salesforce → accounting → email
• Referral form → Salesforce → case/program workflow → partner notification
• Grant award → Salesforce → program delivery → outcome reporting → funder report

A provider should not only ask whether the integration job ran — it should ask whether the expected records arrived and whether exceptions were resolved.

The next layer: workflow exception control

Happy-path automation is relatively easy. Operational reliability depends on what happens when the process does not follow the happy path. Useful exceptions include:

• donation paid but not reconciled
• grant report approaching due date with no owner
• participant intake without assessment
• referral older than service target
• high-value donor without required stewardship action
• integration record rejected
• KPI outside expected range

Ask whether the managed service can surface and assign those exceptions.

The next layer: reporting as an operating process

There is a major difference between “we can build a report” and “we manage the data and reporting process required for leadership, funders and programs to trust the number.” A nonprofit managed service should help define KPI ownership, data sources, calculation rules, exception handling, recurring delivery, and drill-down from metric to underlying record.

The next layer: AI governance

As AI becomes part of Salesforce and surrounding applications, administration expands. Questions include:

• What data may the AI use?
• Which users may access which data through AI?
• Which actions require human approval?
• Which outputs are logged?
• How is bad source data detected?
• Which AI use cases save enough time to justify complexity?

AI governance should be connected to CRM permissions and data quality rather than implemented as a parallel project.

The next layer: licence and SaaS optimization

Nonprofits often accumulate overlapping applications. A managed service should periodically ask:

• Is this Salesforce licence actually required?
• Is the feature already available elsewhere in the stack?
• Is a separate app still needed?
• Are we paying for an integration that can be simplified?
• Is the custom solution costing more to maintain than a standard feature?

The goal is not “put everything in Salesforce.” The goal is the least complex stack that reliably supports the nonprofit.

A 15-point vendor evaluation checklist

How a managed-scope provider compares to a typical Salesforce MSP

The dimensions above map onto a broader positioning question: how does a fuller operating scope compare to a conventional Salesforce managed-services provider?