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 CRM Analytics dashboards, NPSP PMM implementation/setup, or fundraising data analysis.
Best use case
program-outcome-tracking-design is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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 CRM Analytics dashboards, NPSP PMM implementation/setup, or fundraising data analysis.
Teams using program-outcome-tracking-design should expect a more consistent output, faster repeated execution, less prompt rewriting, better workflow continuity with your supporting tools.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
- You already have the supporting tools or dependencies needed by this skill.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/program-outcome-tracking-design/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How program-outcome-tracking-design Compares
| Feature / Agent | program-outcome-tracking-design | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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 CRM Analytics dashboards, NPSP PMM implementation/setup, or fundraising data analysis.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 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: | Object | Role | |---|---| | Outcome | Represents a program result statement | | Indicator | A measurable proxy for an Outcome | | Indicator Result | The actual measured value at a point in time | | Participant Goal | An 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 Layer | PMM Object | Notes | |---|---|---| | Activities | Service__c | Type of service delivered | | Outputs | ServiceDelivery__c (Quantity__c) | Units delivered | | Outcomes (completion) | ProgramEngagement__c (Stage__c) | Graduated/completed status | | Outcomes (measured) | Custom Outcome__c or NPC Indicator | Requires custom design or NPC | | Impact | Reports and dashboards | Aggregated 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 | Situation | Recommended Approach | Reason | |---|---|---| | NPSP/PMM org — simple output counting | ServiceDelivery__c Quantity__c + reports | Built-in, no custom objects needed | | NPSP/PMM org — grant requires measured outcomes | Custom Outcome__c object + ProgramEngagement lookup | PMM has no native Outcome object | | NPC org — outcome measurement | NPC Outcome Management (Outcome, Indicator, Indicator Result) | Native, supported, no custom dev | | Grant reporting on participants who completed program | ProgramEngagement Stage__c = Graduated | Built-in completion tracking | | Pre/post measurement (surveys, assessments) | Custom Outcome__c with pre/post measurement date fields | PMM does not have survey instruments | | CRM Analytics impact dashboards | CRM Analytics with PMM data sources | This 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 | Artifact | Description | |---|---| | Logic model to Salesforce mapping | Logic model components mapped to PMM objects and custom objects | | Outcome data model design | Custom Outcome__c or NPC Outcome Management object model | | Grant compliance report design | Report 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
Related Skills
npsp-program-management
Use this skill when configuring or troubleshooting the Nonprofit Success Pack Program Management Module (PMM) — a separate managed package for program delivery, cohort setup, service scheduling, service delivery recording, and outcome/attendance tracking for beneficiaries. Trigger keywords: program management module, PMM, Program__c, ProgramEngagement__c, ServiceDelivery__c, cohort setup, bulk service delivery, service schedule, service participant. NOT for NPSP core donor management, gift entry, recurring donations, soft credits, or Health Cloud care programs.
omniscript-design-patterns
Use when designing or reviewing OmniScripts for guided experiences, step structure, branching, save/resume, and the boundary between OmniScript, Integration Procedures, DataRaptors, and custom LWCs. Triggers: 'omniscript design', 'too many steps in omniscript', 'save and resume omniscript', 'branching in omniscript', 'when should this be an integration procedure'. NOT for deep Integration Procedure or DataRaptor design when the guided interaction layer is not the main concern.
flexcard-design-patterns
Use when designing, building, or reviewing OmniStudio FlexCards — including data source selection, card states, actions, conditional visibility, flyout configuration, and child card iteration. Triggers: 'FlexCard', 'card template', 'flyout', 'card action', 'card state', 'data source', 'child card', 'conditional visibility'. NOT for OmniScript design, standalone LWC development, or Apex controller architecture outside the FlexCard context.
calculation-procedure-design
Design OmniStudio Calculation Procedures and Calculation Matrices for pricing, rating, and rules-heavy scoring. Trigger keywords: calculation procedure, calculation matrix, rating engine, pricing matrix, expression set, decision matrix, OmniStudio rules. Does NOT cover: generic Apex-only pricing code, Salesforce CPQ price rules (different product), or Flow-based decision logic.
api-error-handling-design
Designing HTTP error classification, RFC 7807-style error payload structure, and client-side error parsing for Salesforce REST/SOAP integrations and custom Apex REST endpoints. Use when deciding which HTTP status codes to return from custom Apex REST services, how to structure error response bodies, how to classify inbound API errors as retry-safe vs non-retry-safe, or how to parse Salesforce error responses on the consumer side. NOT for retry execution mechanics or circuit breaker implementation (use retry-and-backoff-patterns). NOT for Apex exception class design (use apex-error-handling-framework). NOT for OAuth error flows (use oauth-flows-and-connected-apps).
source-tracking-and-conflict-resolution
Use when diagnosing and resolving SFDX source-tracking conflicts between a local project and a Salesforce org — covering sf project pull/push/retrieve/deploy conflict errors, force overwrite decisions, tracking file corruption, and sandbox source-tracking enablement. Trigger keywords: source tracking, conflict, --force-overwrite, --ignore-conflicts, maxRevision.json, sf project retrieve, source:status. NOT for Git merge conflicts, DevOps Center pipeline conflicts, or change-set deployments.
field-history-tracking
Use when enabling, configuring, or querying Salesforce field history tracking to audit changes to field values over time. Covers enabling tracking on objects and fields, the 20-field-per-object limit, 18-month data retention, querying standard History sObjects (AccountHistory, OpportunityHistory, custom __History), and troubleshooting missing records. NOT for Event Monitoring (use security skills), NOT for Shield Field Audit Trail or FieldHistoryArchive (use field-audit-trail).
data-model-design-patterns
Use when designing, reviewing, or troubleshooting Salesforce object relationships and field type choices — lookup vs master-detail, junction object modeling, indexing strategy, and data model anti-patterns. NOT for object creation steps (use object-creation-and-design). NOT for bulk data loading operations.
data-extension-design
Use this skill when designing, creating, or troubleshooting Marketing Cloud Data Extensions — including sendable vs. non-sendable DE selection, primary key composition, data retention configuration, Send Relationship mapping, and performance indexing. Trigger keywords: data extension, sendable DE, send relationship, DE primary key, data retention, Marketing Cloud data model, DE columns, subscriber key mapping. NOT for CRM (Sales/Service Cloud) custom object design, Marketing Cloud Connect object sync configuration, or Contact Builder attribute group architecture beyond simple relationship type selection.
solution-design-patterns
Use when selecting the right automation layer (Flow, Apex, LWC) for a new feature, reviewing an existing design for technical debt, or troubleshooting a mismatched automation architecture. Triggers: 'should I use Flow or Apex', 'declarative vs programmatic', 'which layer should handle this', 'automation design review', 'should I use LWC or standard components', 'is this over-engineered'. NOT for individual feature design (use role-specific skills), NOT for detailed Apex implementation (use apex/ skills), NOT for LWC component authoring (use lwc/ skills), NOT for Flow-specific build steps (use flow/ skills).
sla-design-and-escalation-matrix
Use when designing the SLA tier definition table, escalation matrix document, and milestone threshold configuration for a Salesforce Service Cloud implementation. Covers designing the artifact layer — tier tiers (e.g., Enterprise/Professional/Basic), response and resolution time targets, business hours mapping, milestone percentage thresholds at 50/75/90/100%, and the escalation action matrix that maps thresholds to notification targets and automated actions. Triggers: SLA design, escalation matrix, milestone thresholds, tier definition, business hours alignment, SLA enforcement design. NOT for entitlement process configuration steps (use admin/case-management-setup), NOT for escalation rule setup (use admin/escalation-rules), NOT for CPQ quoting SLAs.
loyalty-program-architecture
Use when designing or reviewing the architecture of a Salesforce Loyalty Management program before configuration begins — tier-ladder economics, qualifying-vs-non-qualifying currency split, point inflation/deflation modeling, fraud-prevention controls, partner-network topology, multi-region program federation, and tier-descalation policy. Triggers: 'designing a loyalty program', 'how many tiers should we have', 'point economy design', 'preventing loyalty fraud', 'partner loyalty architecture', 'multi-region loyalty rollout', 'tier descalation policy', 'how do we set the qualifying threshold'. NOT for hands-on Loyalty Management setup (use integration/loyalty-management-setup) — this skill produces the architecture document, not the configuration steps. NOT for Marketing Cloud engagement programs (different product). NOT for B2B partner programs that aren't loyalty (regular Sales Cloud opportunity tracking applies).