本文へ移動
cccskills
無料GitHub で公開

program-outcome-tracking-design

Design guidance for program outcome measurement in Salesforce nonprofit orgs: logic model structure, indicator taxonomy, impact reporting design, and grant compliance reporting using NPSP Program Management Module (PMM) or Nonprofit Cloud (NPC) Outcome Management. NOT for configuring PMM programs, cohorts and service deliveries - use admin/npsp-program-management. NOT for setting up grant tracking, funding awards and disbursements - use admin/grant-management-setup.

PranavNagrecha/AwesomeSalesforceSkills
インストール方法を見る

含まれるファイル（7）

  • SKILL.md11.1 KB
  • references/examples.md4.1 KB
  • references/gotchas.md4.6 KB
  • references/llm-anti-patterns.md5.8 KB
  • references/well-architected.md2.9 KB
  • scripts/check_program_outcome_tracking_design.py10.4 KB
  • templates/program-outcome-tracking-design-template.md5.6 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Program Outcome Tracking Design

This skill activates when a nonprofit BA or program staff member needs to design an outcome measurement framework in Salesforce — mapping logic model components to platform objects, building indicator tracking, and designing grant compliance reports. It does NOT cover CRM Analytics report building, PMM package setup, or fundraising analysis.

Before Starting

Gather this context before working on anything in this domain:

  • NPSP vs Nonprofit Cloud (NPC): The outcome data model differs significantly between platforms. NPSP with PMM has NO native Outcome or Indicator objects — all outcome tracking requires custom objects. NPC has a dedicated Outcome Management feature with native objects. Confirm which platform the org is on before designing anything.
  • PMM operational objects: PMM ships 8 operational objects (Program__c, Service__c, ProgramEngagement__c, ProgramCohort__c, ServiceDelivery__c, ServiceSchedule__c, ServiceParticipant__c, ServiceSession__c). Outcome data in PMM lives only as Quantity__c and UnitOfMeasurement__c on ServiceDelivery__c, and Stage__c on ProgramEngagement__c. Structured indicator tracking requires custom fields or custom objects.
  • Grant compliance requirements: Grant reports typically require aggregated indicators (number served, number completing program, percentage achieving outcomes) mapped to specific services and date ranges. Design reports before designing the data model — reports drive what fields are needed.
  • NPSP is no longer offered in new production orgs as of December 2025. New nonprofits use Nonprofit Cloud (NPC). Orgs on NPSP are legacy; NPC orgs have different object models.

Core Concepts

PMM Does Not Ship Outcome or Indicator Objects

NPSP Program Management Module (pmdm namespace) provides operational service delivery tracking — who received what service when. It does NOT provide dedicated Outcome__c, Indicator__c, or LogicModel__c objects. Nonprofits that expect PMM to "do outcomes" are commonly disappointed.

What PMM provides for outcome-adjacent tracking:

  • Stage__c on ProgramEngagement__c (Active, Inactive, Graduated, etc.) — crude completion tracking
  • Quantity__c and UnitOfMeasurement__c on ServiceDelivery__c — units of service delivered
  • Custom fields on any PMM object — requires implementor design

Structured logic model outcome tracking (indicators, targets, actuals, baseline comparisons) requires custom objects on NPSP/PMM orgs.

NPC Outcome Management (NPC Only)

Nonprofit Cloud has a distinct Outcome Management feature with native objects:

ObjectRole
OutcomeRepresents a program result statement
IndicatorA measurable proxy for an Outcome
Indicator ResultThe actual measured value at a point in time
Participant GoalAn individual-level outcome target

This feature is NOT available in NPSP/PMM orgs. Designs using Outcome or Indicator objects require NPC licensing.

Logic Model Structure in Salesforce

A standard nonprofit logic model maps inputs → activities → outputs → outcomes → impact. In Salesforce:

Logic Model LayerPMM ObjectNotes
ActivitiesService__cType of service delivered
OutputsServiceDelivery__c (Quantity__c)Units delivered
Outcomes (completion)ProgramEngagement__c (Stage__c)Graduated/completed status
Outcomes (measured)Custom Outcome__c or NPC IndicatorRequires custom design or NPC
ImpactReports and dashboardsAggregated across cohorts

Common Patterns

Custom Outcome Tracking on NPSP/PMM

When to use: NPSP org with PMM where grant reporting requires measured outcomes beyond service counts.

How it works:

  1. Create a custom Outcome__c object with fields: Program__c (lookup to Program__c), Indicator__c (text or lookup), TargetValue__c, ActualValue__c, MeasurementDate__c, ProgramEngagement__c (lookup).
  2. Define the indicator taxonomy based on grant requirements (e.g., "Number who gained employment," "Percentage with improved housing stability").
  3. Staff enter Outcome records per participant per measurement period.
  4. Build reports joining ProgramEngagement__c → Outcome__c to aggregate indicators by program and grant period.

Why not ServiceDelivery Quantity: ServiceDelivery Quantity tracks units of service (sessions, hours) — not outcomes. Using it for outcome measurement conflates activity outputs with program results, producing grant reports that describe activity, not impact.

NPC Outcome Management

When to use: Nonprofit Cloud org with Outcome Management enabled.

How it works:

  1. Enable Outcome Management in NPC Setup.
  2. Create Outcome records defining program result statements.
  3. Create Indicator records linked to each Outcome with measurement type and unit.
  4. Create Indicator Results at assessment intervals (monthly, quarterly, program end).
  5. Create Participant Goal records for individual-level targets.
  6. Build reports on Indicator Result to track aggregate progress vs. targets.

Why not custom objects: NPC Outcome Management provides a structured, supported framework that connects outcomes to program enrollments natively, reducing custom development and avoiding data model fragmentation.

Decision Guidance

SituationRecommended ApproachReason
NPSP/PMM org — simple output countingServiceDelivery__c Quantity__c + reportsBuilt-in, no custom objects needed
NPSP/PMM org — grant requires measured outcomesCustom Outcome__c object + ProgramEngagement lookupPMM has no native Outcome object
NPC org — outcome measurementNPC Outcome Management (Outcome, Indicator, Indicator Result)Native, supported, no custom dev
Grant reporting on participants who completed programProgramEngagement Stage__c = GraduatedBuilt-in completion tracking
Pre/post measurement (surveys, assessments)Custom Outcome__c with pre/post measurement date fieldsPMM does not have survey instruments
CRM Analytics impact dashboardsCRM Analytics with PMM data sourcesThis skill does NOT cover CRM Analytics — separate skill

Recommended Workflow

  1. Platform confirmation — Determine NPSP/PMM or Nonprofit Cloud (NPC). This is the branching decision point for all subsequent design choices.
  2. Grant requirements analysis — Collect all grant reporting templates and indicator definitions before designing objects. Reports drive data model requirements.
  3. Logic model mapping — Map each logic model component (outputs, outcomes, impact) to available PMM objects and identify gaps requiring custom objects.
  4. Data model design — For NPSP/PMM, design custom Outcome__c object with appropriate fields and lookups. For NPC, configure Outcome Management.
  5. Report design — Design the grant compliance report layout first; validate that the data model supports the required aggregations (by program, by service, by cohort, by grant period).
  6. Staff training design — Define the data entry workflow for staff: when to create Outcome records, how to measure indicators, and how measurement dates align with grant reporting periods.
  7. Review — Validate that outcome objects use PMM standard object lookups (not Contact directly), that all grant indicator definitions are reflected in the data model, and that report date ranges match grant periods.

Review Checklist

  • Platform confirmed: NPSP/PMM or Nonprofit Cloud (NPC)
  • Grant indicator definitions collected and mapped to data model fields
  • Custom Outcome__c designed if NPSP/PMM (PMM ships no native Outcome object)
  • Outcome records linked to ProgramEngagement__c (not Contact directly)
  • Report design reviewed against grant compliance template before building
  • NPSP Opportunity-based reports are NOT used for program impact data
  • NPC Outcome Management objects are NOT referenced in NPSP/PMM org designs

Salesforce-Specific Gotchas

  1. PMM ships no Outcome or Indicator objects — The most common misconception. PMM provides operational service delivery tracking, not outcome measurement. Outcome tracking requires custom objects on NPSP/PMM orgs or the NPC Outcome Management feature.
  2. Using NPSP Opportunity reports for program impact is incorrect — Opportunities in NPSP represent gifts, not program results. Reports on Opportunity Amount have no relationship to program outcomes. Grant reports using Opportunity data to claim program impact conflate fundraising data with program data.
  3. NPC Outcome Management is not available in NPSP/PMM orgs — Attempting to create Outcome or Indicator objects in an NPSP/PMM org fails — these are NPC-specific objects. Design for each platform separately.

Output Artifacts

ArtifactDescription
Logic model to Salesforce mappingLogic model components mapped to PMM objects and custom objects
Outcome data model designCustom Outcome__c or NPC Outcome Management object model
Grant compliance report designReport layout showing indicator aggregations aligned to grant template

Related Skills

  • npsp-program-management — For PMM configuration, service delivery setup, and operational PMM administration
  • donor-lifecycle-requirements — For designing the donor engagement side of nonprofit CRM alongside program tracking

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

acceptance-criteria-given-when-then

無料

Use this skill when writing test-first, behavior-driven acceptance criteria in Given/When/Then format for a Salesforce user story. Covers happy path, edge cases, negative paths, permission boundaries, and data-state preconditions so the AC block can drive UAT scripts and Apex test design downstream. Trigger keywords: given when then, gherkin, behavior driven AC, test first acceptance criteria, scenario outline, BDD acceptance criteria. NOT for the user-story format itself (use admin/user-story-writing-for-salesforce). NOT for UAT script writing (use admin/uat-test-case-design). NOT for Apex test method generation (use agents/test-class-generator). NOT for high-level UAT planning (use admin/uat-and-acceptance-criteria). More triggers: acceptance criteria record, ac_id, req_id on a criterion, artefact under test, negative case for a rule-type requirement, no-match fall-through criterion, oracle for a Then clause, test type apex flow manual, criteria linter, check_ac_format.py, --manifest-dir.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

activity-and-task-patterns

無料

Task and Event objects: polymorphic WhatId/WhoId, Activity object model, ActivityHistory vs OpenActivity, activity timeline customization, bulk task creation, Einstein Activity Capture boundaries. NOT for turning on EAC or calendar sync — use admin/einstein-activity-capture-setup. NOT for Email-to-Case — use admin/case-management-setup. Covers ActivitiesSettings metadata, enableActivities, shared Task/Event custom fields and FLS, TaskStatus value sets, Shared Activities and TaskRelation/EventRelation, recurring and child activities, and partial-success bulk DML on Task.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-error-handling

無料

Design Invocable Apex actions that return deterministic, agent-friendly errors instead of surfacing raw exceptions to the LLM. NOT for authoring the action itself — @InvocableMethod schema, labels, security context — use agentforce/custom-agent-actions-apex. NOT for the Apex tests that force each error branch — use agentforce/agent-action-unit-tests.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-input-slot-extraction

無料

Use when designing how an Agentforce agent extracts structured input parameters (slots) from a user's natural-language utterance to invoke an action. Triggers: 'agent extract date from user', 'agent action argument extraction', 'agentforce slot filling', 'agent invocable input mapping', 'agent fails to fill required parameter'. NOT for action authoring (use agentforce/agent-actions) or for prompt-template variable binding (use agentforce/prompt-builder-templates).

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-unit-tests

無料

Apex test patterns for @InvocableMethod agent actions: per-reason-code branch coverage, bulk safety, callout mocking, deterministic assertions. NOT for testing whether the agent routes to the right topic or answers well — use agentforce/agent-testing-and-evaluation. NOT for designing the error envelope the tests assert on — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-actions

無料

Designing or reviewing Agentforce actions: Flow actions, Apex invocable actions, prompt-template actions, action naming, input and output contracts, confirmation requirements, and safe error behavior. Triggers: 'agent actions', 'build an agent that can look up an order', 'make the agent able to check order status', 'give the agent a capability', 'agent that can retrieve a record', 'flow action for agent', 'agent invocable action', 'action schema design'. NOT for writing the Apex class itself — use agentforce/custom-agent-actions-apex. NOT for the reason_code error envelope that stops an agent retry loop — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

PranavNagrecha のスキルをすべて見る

このスキルの問題を報告する