Reconciling Multi-Branch Donor & Partner Data Across a National NGO Network
Built from real, recurring patterns observed across national and pan-African NGOs — not a real client, not real data. Labeled honestly rather than presented as finished work.
The Situation
A composite, typical of what shows up across national NGOs with semi-autonomous branches: a secretariat in Abuja running programmes through a dozen-plus state or regional chapters, each reporting on whatever tool was locally available — one branch on spreadsheets, another on a paper log transcribed monthly, a couple on a shared drive with no shared format. A donor reporting deadline arrives, and the secretariat's programme team spends days manually reconciling submissions that don't share field names, date formats, or even currency conventions, before anyone can produce one clean number for a funder.
The Architecture
Built on Salesforce Non-Profit Success Pack (NPSP), structured around the Household/Organization Account model already native to NPSP — the national secretariat as a parent Account, each branch or partner as a child Account linked through the standard Account hierarchy, so branch-level activity rolls up to a single national view without losing branch-level detail.
Programme and grant data sit on custom objects related to each branch Account, rather than living in disconnected spreadsheets — this is what turns "branch X's numbers" into "one filterable slice of the same dataset."
Incoming records from branches (via Data Loader or Data Import Wizard for bulk imports) pass through Duplicate and Matching Rules configured on the key identifying fields — donor name, grant ID, reporting period — so records entered inconsistently across branches get flagged or merged rather than silently creating parallel entries. Flow-based validation catches the most common breakage points directly: mismatched date formats, missing required fields, and currency inconsistencies get caught at entry, not at reconciliation time three days before a donor deadline.
Reporting sits on top of this as report types and dashboards scoped by branch, region, or donor — giving the secretariat one live, consolidated view instead of a manual roll-up exercise every reporting cycle.
What This Would Change
Framed as expected outcomes of the architecture, not measured results of a real engagement: reconciliation before a donor report shifts from a manual, multi-day cross-check to a live report anyone on the team can pull. Duplicate donor and grant records stop accumulating silently across branches. And the secretariat gains a single source of truth it can hand to an auditor or funder without needing to explain which spreadsheet is the "real" one.
Milestone-Gated Fund Release for a Multi-Country Grant Cycle
Built from real, recurring patterns observed across grant-making and fellowship-running NGOs — not a real client, not real data. Labeled honestly rather than presented as finished work.
The Situation
A composite, typical of an organization running a grant cycle or fellowship where sub-grantees or cohort members are spread across several countries or regions, and funds are meant to release only as each recipient hits a defined milestone. In practice, the compliance team is stuck manually checking uploaded reports against a spreadsheet of milestone criteria before every disbursement, and different program officers apply the criteria slightly differently — some recipients get paid before their documentation is actually complete, others get held up for reasons that were never written down anywhere consistent.
The Architecture
Built on Salesforce NPSP, with each grant or fellowship modeled as an Opportunity (or a custom Grant object where the standard Opportunity fields don't fit cleanly), broken into stages that mirror the actual milestone structure — application, approval, milestone 1 delivered, milestone 2 delivered, closed. Each stage transition is gated by an Approval Process, so a disbursement can't move forward until the required documentation fields are populated and a reviewer has formally signed off — replacing "did someone remember to check" with a rule the system enforces every time.
Validation rules on the milestone fields catch incomplete submissions before they ever reach a reviewer's queue, and a Flow handles the notification side — automatically alerting the program officer and the recipient's point of contact the moment a stage changes, instead of relying on someone remembering to send an update email.
Because every grantee sits on a standard Account/Contact structure, the same reporting layer used for donor-side reconciliation (see the pattern above) applies here too — a dashboard showing exactly which recipients are pending, approved, or paid, filterable by country, cohort, or funding source.
What This Would Change
Framed as expected outcomes of the architecture, not measured results of a real engagement: milestone criteria stop living in one compliance officer's head or a personal spreadsheet, and instead become a rule the system applies the same way every time. Disbursement timing becomes consistent across program officers rather than varying by who's reviewing the file. And when a donor or auditor asks "show me exactly why this recipient was paid on this date," there's a system-enforced approval trail to point to, not a reconstructed explanation after the fact.
Structuring a Volunteer & Attendance System for Teens Church at The Transforming Church
The Situation
Teens Church, the youth ministry at The Transforming Church (TTC), runs weekly services across several functional units — Choir, Creative, Media, Music, Prayer, Sound, Ushering — each with its own unit head, sitting under a coordinating team lead. Attendance and segment leadership lived in whoever's head happened to be tracking it that week: a leader counting heads and mentioning the number to someone afterward, no shared record of who led which segment on which date, and no way for the coordinating team to see the whole picture without asking around unit by unit.
The Architecture
Built on Salesforce NPSP, with a Role Hierarchy modeled directly on Teens Church's actual leadership structure — CEO at the top, a Team Lead Teens role beneath it, and each unit head (Choir, Creative, Media, Music, Prayer, Sound, Ushering) reporting into that. Record visibility follows the real chain of leadership instead of defaulting to flat or over-permissioned access.
Church Services, Attendance, and Service Segments sit as related objects off the standard Contact record, so a segment leader, a service date, and an attendee are all connected rather than living as separate lists. A public-facing Screen Flow lets someone log their own attendance directly — it searches for a matching Contact, matches it against the current Church Service, and creates the Attendance record automatically, instead of routing through whoever happens to be holding a clipboard that day.
Sharing Rules extend read access to specific roles — a Cross-Unit Coordinator, for instance, sees Church Service records owned across the whole Team Lead Teens hierarchy — without opening those objects org-wide. Permission Sets scope field-level access per object (the Teens Church Leader profile gets exactly the fields their role needs on Church Services, no more), rather than leaning on broad, catch-all profile permissions.
A "Teens Church Cockpit" dashboard sits on the home page — attendance by service and gender, active segments and who's leading them — live the moment a leader or coordinator logs in.
What Changed
Attendance capture moved from someone remembering to relay a headcount to leaders logging it themselves, in the moment, from their own device. Leadership visibility became something the system shows rather than something a coordinator has to reconstruct by asking each unit head individually. And a question like "how many people came through last week, and who led which segment" now resolves to a report anyone with access can pull.