Program and Outcome Management in Salesforce: Prove Your Impact

Every funder asks the same question in a slightly different way: did this work? Most nonprofits can answer how many people they served and struggle to answer whether anything changed. That is rarely a reporting problem. It is a definition problem that shows up as a reporting problem months later. Agentforce Nonprofit ships program management and outcome management as core objects, which means the structure exists. This guide is about using it properly.

Why impact dashboards fail before anyone builds them

We have seen the same failure repeatedly. An organization commissions dashboards, the build finishes, and the numbers are unusable. The cause is almost never the tooling.

• The metric was never defined. "Job placement rate" sounds precise. Placement in what? Counted at what point? Does a 12 hour a week job count? Does someone who left after three weeks still count as placed? Five staff will give five answers.
• Each funder defines it differently and nobody wrote the differences down, so one field gets used three ways and the data becomes meaningless.
• Nobody owns the denominator. Placement rate out of enrolled, out of completed, or out of those who wanted a job? The choice changes the number by tens of points.
• Data collection was not designed. The dashboard needs a 90 day follow up that no staff member has time or a prompt to make.

Outputs and outcomes are not the same thing

This distinction drives which objects you use.

Outputs come out of running your programs properly. Outcomes require deliberate measurement. Most organizations report outputs and call them impact, and funders are increasingly unwilling to accept that.

The program management objects

All of these arrived in API version 57.0 and are core platform objects, so no package prefixes. Participants are Person Accounts, as described in the data model guide.

The chain to remember: a person enrols in a Program, the enrolment produces BenefitAssignment records, schedules say when delivery should happen, and each real delivery is a BenefitDisbursement. Disbursements are what you count when a funder asks what you actually provided.

Designing programs, benefits, and enrollment

The modelling questions that matter, in the order we ask them:

How granular is a program?

Too coarse and you cannot report by funder. Too fine and staff drown in enrolments. A useful test: if a funder pays for it separately, or you report on it separately, it is probably its own Program. Cohorts and terms usually belong underneath, not as separate programs.

What is a benefit?

Benefits are the things you give. Be concrete: a tutoring session, a food box, a bus pass, a counselling hour, a certification exam fee. Resist the temptation to make one benefit called "services" because it is easier, because then you can never report on what you actually delivered.

What does enrollment status mean?

Define the values and the transitions. A typical set is Applied, Waitlisted, Enrolled, Completed, Withdrawn, and Exited. Then answer the hard questions in writing:

• What separates Completed from Exited? Usually a completion criterion such as attending 80 percent of sessions.
• Can someone re-enrol? If yes, you get multiple enrolments per person per program, and every metric needs to say whether it counts people or enrolments.
• What happens after long inactivity? Auto-exit after 90 days keeps your active counts honest, but only if you write the rule down.

These definitions are the denominators for every outcome metric later. Getting them wrong at design time is what makes the dashboards wrong at the end.

Intake

Intake creates a Person Account, contact points, sometimes a household group, and a program enrolment. The Group Definitions business API can create a group with its members in one call, which suits an intake form.

Two things to plan. First, collect demographic data only where a funder requires it or you use it, because every extra field is a field somebody has to ask a person in crisis. Second, expect duplicates: participants arrive through multiple doors, often with name variations. Build matching into intake rather than cleaning up later.

Attendance and service delivery

Attendance is where program data lives or dies, because it is captured by busy staff, often away from a desk.

What works:

• Group capture, not one record at a time. A facilitator marks a whole session at once. If it takes more than a minute, it will happen at the end of the week from memory, or not at all.
• Mobile first, because delivery happens in classrooms, shelters, and vans.
• Offline tolerance where connectivity is unreliable.
• Absence is data. Recording that someone did not attend is often more useful than attendance, because it is the early warning that predicts a drop out.

Then use it. An attendance drop is the signal that lets a case manager intervene while it still matters. That is the operational value of program data, separate from any funder report.

The outcome management objects

These arrived in API version 59.0 and have no Nonprofit Success Pack equivalent, which is why NPSP organizations end up building custom objects for this.

The layering looks like overhead until you have more than one funder. Then it becomes the thing that saves you. A definition states what a measure means, once. An assignment attaches it to a particular outcome. A performance period sets baseline and target for a quarter. Results hold the numbers.

IndicatorDefinition can also reference a Flow, so a result can be calculated from program data rather than typed in by a staff member. Use that wherever the underlying data already exists in the system.

Writing an indicator that survives an audit

The IndicatorDefinition description field is the most important text in your whole program build. Write it as if the person reading it has never met you, because in three years that will be true.

A weak definition: Job placement rate.

A definition you can defend:

Every clause in that block prevents a specific argument. The hours threshold stops part-time gig work being counted as a placement. The denominator stops the rate being quietly improved by changing who is included. The exclusions stop people who never wanted a job from dragging the rate down. The owner and the collection point make it happen at all.

Write these before you build anything. If a funder disagrees with a definition, that is a conversation to have during design, not after you have reported a number they do not accept.

Eight funders, one program

This is the situation that breaks naive designs. Eight grants fund one workforce program, and each defines success differently. One wants placement at 30 days, another at 180. One counts any employment, another counts only jobs above a wage floor.

The wrong answer is a custom field per funder. You end up with Placement_Rate_FunderA__c through Placement_Rate_FunderH__c, eight code paths, and no way to compare anything.

The right answer uses the layering:

1. Collect the underlying facts once, at the finest useful grain: employment start date, hours per week, wage, employer, and verification method.
2. Create a separate IndicatorDefinition for each funder definition. Eight definitions is correct, not duplication, because they genuinely measure different things.
3. Use IndicatorPerformancePeriod to hold each funder's reporting period, baseline, and target.
4. Calculate IndicatorResult records from the same underlying facts, using each definition's own rule.

Now a new funder with a new definition is a configuration change, not a development project. That is the entire return on doing this properly, and it is why we insist on freezing metric definitions during design.

Dashboards and funder reports

Build for two audiences, and do not try to serve both with one screen.

Operational dashboards, for program staff, weekly:

• Active enrolments per program against capacity
• Attendance trend, and participants whose attendance dropped
• Follow ups due, especially outcome measurement points
• Participants with no contact in 30 days

Funder and board reports, quarterly:

• Enrolled, completed, and exited, with the definitions stated on the report
• Benefits delivered, counted from disbursements
• Indicator results against baseline and target
• Demographics where required by the grant

Put the definition on the funder report itself. A number without its definition invites a follow up email every single quarter.

Participant privacy is part of the design

Program data is more sensitive than donor data, and it is frequently protected less carefully.

Three decisions to make before you build:

1. Who can see case detail? Case notes, health information, and immigration status should be visible to assigned staff, not to everyone with a login. Fundraising staff in particular should not see them.
2. What is the retention rule? Keeping participant records forever is a liability, not an asset. Agree a retention period with your legal advisor and build the deletion or anonymisation process.
3. What is aggregated in reports? A dashboard filtered to a small cohort can identify individuals even without names. Set minimum cell sizes for published reporting.

If your programs touch health data, treat that as a separate design conversation, including field level security and encryption. The full architecture is in the nonprofit sharing model guide.

Implementation checklist

1. Program granularity decided against the "does a funder pay for it separately" test.
2. Benefits defined concretely, never as a single generic service.
3. Enrollment statuses defined, including what separates Completed from Exited.
4. Re-enrollment rule decided, and every metric states whether it counts people or enrolments.
5. Intake designed with duplicate matching, collecting only fields you use.
6. Attendance capture at group level, mobile friendly, recording absence.
7. Every metric has a written definition with numerator, denominator, measurement point, source, exclusions, and owner.
8. One indicator definition per funder definition, calculated from shared underlying facts.
9. Operational and funder dashboards built separately.
10. Participant data access, retention, and minimum cell size agreed.

Frequently asked questions