A few months ago, CFAR came to us with a familiar problem. Their donor information was sitting in one spreadsheet, programme data in another, and beneficiary numbers were being emailed in from the field every month as Excel attachments. Nobody had a single place to see how a grant moved from proposal to disbursement to actual impact on the ground. If the CEO wanted to know how many people a programme had reached that quarter, someone had to manually pull numbers from three or four different files and hope they matched up.

We ended up building the whole thing on Salesforce Nonprofit Cloud, and I wanted to write up what that actually looked like in practice, because a lot of the write-ups you find online are either too high-level to be useful or too technical to make sense to anyone outside the Salesforce world.

Starting with donors

The first piece was donor management. We set up Organization Accounts for every donor CFAR works with, and split them into categories, Foundations, CSR donors, Government, and Individuals, since each of these has a different reporting cycle and different expectations. We also connected Gmail through Einstein Activity Capture, so every email exchange with a donor, both ways, shows up automatically on their record. This sounds like a small thing, but it removed a huge amount of manual copy pasting that the fundraising team used to do just to keep a paper trail of conversations.

Once a new donor contact is created, a welcome email goes out automatically and kicks off the onboarding process. It’s a simple flow, but it means nobody forgets to follow up with a new donor just because that week happened to be busy.

Tracking proposals and grants without losing anything

For proposals, we used the standard Opportunity object but reshaped it to match how CFAR actually works: Pipeline, Submitted, Under Review, Approved, or Rejected. Every proposal links back to the donor, the primary contact, and the specific programme it’s tied to, so there’s no ambiguity about which grant is funding which piece of work.

We also built in a simple but effective safety net: if a proposal sits pending for 30 days without movement, the system automatically creates a high priority task for whoever owns that proposal. Before this, follow-ups depended entirely on someone remembering to check. Now the system remembers for you.

Disbursements are tracked separately as payment records, with the date, amount, and status logged against each one, so CFAR has a clear installment-by-installment history of what’s actually been received from a donor, not just what was pledged.

Programmes as the centre of everything

The programme object is really the hub that everything else connects to, donors, proposals, beneficiaries, indicators, finance, and risk all sit around it. Each programme record captures where it’s running, down to state, district, and block level, along with the programme manager, status, total budget, and total beneficiaries.

Those budget and beneficiary totals aren’t entered by hand. An Apex trigger recalculates them automatically whenever a related finance entry or beneficiary report comes in, so the numbers on the programme record are always current. And when a programme’s status changes to Completed, the programme manager gets both an email and a Chatter notification, so there’s no lag between something finishing on the ground and the system reflecting it.

Getting real data from the field

Beneficiary reporting was probably the part CFAR cared about most, since this is the data that actually proves the work is happening. We built a custom Beneficiary Report object that captures counts by gender and age group, male, female, children, youth, adults, elderly, against a reporting period and programme, and enabled the Salesforce mobile app so field officers can log this directly from site visits instead of filling out a form later from memory.

One detail I’m genuinely proud of is a small Lightning component we built that shows the previous three reporting periods’ numbers right on screen while a field officer is entering a new report. It sounds minor, but it gives them an immediate reference point, so if a number looks way off from the last few months, they notice it before submitting rather than someone catching it in a review three weeks later. Every submitted report also automatically creates a review task for the programme manager, so nothing sits unreviewed.

Measuring what matters, and staying ahead of risk

On the monitoring and evaluation side, we set up Indicators with baseline values, annual targets, and end-of-programme targets, and a linked Indicator Result object that tracks planned versus actual values and calculates achievement percentage automatically. Finance works the same way in principle, planned budget against actual expenditure, with budget utilization and cost-per-beneficiary calculated as formula fields rather than manually in a spreadsheet.

We also added a Risk Register, where risks get scored automatically as likelihood multiplied by impact. If a risk scores 6 or higher and there’s no mitigation plan attached yet, the system creates a high priority task for the programme manager right away. It’s a small rule, but it means a serious risk can’t quietly sit without a plan just because it wasn’t flagged in a meeting.

Bringing it together in dashboards

None of this is useful if people can’t see it, so we built role-based dashboards for each team, one for leadership covering active programmes, donor counts, and geographic coverage, one for fundraising covering the proposal pipeline and donor engagement, one for M&E tracking planned versus actual achievement, one for finance, and one for programme teams tracking status and beneficiary distribution. Everyone gets a view built around what they actually need to act on, rather than one generic dashboard trying to serve everybody.

What this actually changed

The honest answer is that most of the value came from removing manual work and closing gaps where things used to fall through the cracks. Donor onboarding is consistent instead of dependent on someone remembering. Grant follow-ups happen on their own. Programme numbers update themselves instead of being recalculated by hand at month end. Risks with no mitigation plan get flagged instead of staying quiet. None of it is flashy, but it’s the kind of reliability that lets a small team run a much larger portfolio of programmes without things quietly slipping.

If your organisation is managing donors, grants, and field programmes across a handful of disconnected spreadsheets right now, this is roughly the shape of what a Nonprofit Cloud implementation can look like, not a complete overhaul overnight, but a steady replacement of manual steps with a system that keeps itself honest.