Program Management Module
The Program Management Module (PMM) in Salesforce is a free, open-source application from Salesforce.org (now Salesforce for Nonprofits) that helps nonprofit organizations track programs, services,…
Definition
The Program Management Module (PMM) in Salesforce is a free, open-source application from Salesforce.org (now Salesforce for Nonprofits) that helps nonprofit organizations track programs, services, and client outcomes inside Salesforce. PMM provides the data model and the basic UI for a nonprofit operations team to manage program cohorts, schedule service deliveries, capture attendance, and measure impact across multiple programs and client populations. The module installs as a managed package on top of the standard Salesforce platform; nonprofits use it alongside NPSP (the Nonprofit Success Pack) or Nonprofit Cloud to handle the operational program-tracking needs that those broader products do not cover directly.
PMM is designed for nonprofits running services that touch clients repeatedly over time: workforce development cohorts, mental health counseling appointments, after-school program sessions, food pantry distributions. The data model centers on Programs (the umbrella initiative), Program Engagements (a client enrollment in a Program), Service Schedules (the calendar of when the service is delivered), and Service Deliveries (the individual records of service rendered). Reports built on top of this model drive grant reporting, board updates, and program improvement decisions.
Program Management Module in Salesforce: data model, capture workflow, and reporting
The PMM data model: Program, Program Engagement, Service Delivery
PMM centers on four standard objects. Program represents an umbrella initiative the nonprofit runs (Job Readiness Training, Mental Health Counseling, After-School Tutoring). Program Cohort represents a specific instance of the program (the Fall 2025 Job Readiness Training cohort). Program Engagement represents a client enrollment in a program; one client may have multiple engagements across different programs. Service Schedule defines when a service is delivered (every Tuesday at 4pm at the East Branch). Service Delivery is the actual record of service rendered (Tutoring session on October 15, 2025, with student X by tutor Y). The relationships between these objects let reports roll up service deliveries to engagements, engagements to cohorts, and cohorts to programs. This is the data backbone of any program-focused nonprofit operation.
Service Deliveries and attendance tracking
Service Delivery is the most operationally important PMM object. Each record captures one instance of service: who received the service, who delivered it, when, where, what type, and whether the recipient attended. Capture happens through several paths: a coordinator filling out attendance after a class, a kiosk where clients check in at the door, a mobile app where field staff record visits. Service Delivery records roll up to Program Engagement, which rolls up to Program, which rolls up to grant reports. The fidelity of Service Delivery capture directly drives the reliability of every impact report; nonprofits that capture sloppily or inconsistently end up with grant reports that misrepresent what they actually did. Mature PMM implementations build attendance capture into the staff workflow, not as a separate administrative task.
Program Engagements and the client lifecycle
Program Engagement is the bridge between Contact (the client) and Program (the service). Each engagement carries the start date, the end date (or expected end date), the engagement role (student, participant, mentee), the cohort assignment if applicable, and the outcome at end. The engagement lifecycle mirrors the client journey: enrolled, active, completed, dropped. Mature implementations capture both the start and end states (intake assessment, completion outcome) so impact reports can compare before-and-after. The engagement record also drives reporting: which clients are currently active, how long the average engagement lasts, what percentage complete versus drop. Without this longitudinal view, the nonprofit knows what services it delivered but not what changed for the clients.
Reporting, dashboards, and the grant reporting story
PMM ships pre-built report types and dashboard templates tuned for nonprofit operations. Standard reports cover: service deliveries by program per period, attendance rates by cohort, engagement completion rates, outcomes by demographic, average services per engagement. Mature nonprofits extend these with grant-specific reports (the metrics the funder requires, in the format the funder requests). Grant reporting is one of the highest-stakes uses of PMM data; funders make next-year funding decisions based on the report content, and inaccurate or sloppy data has real funding consequences. Build the grant reports as part of the PMM implementation, not after; designing the data model with grant reporting in mind ensures the right fields exist on the right objects.
Integration with NPSP and Nonprofit Cloud
PMM coexists with NPSP (the Nonprofit Success Pack) and Nonprofit Cloud, the broader Salesforce nonprofit data models. NPSP holds donor data, gift records, and household relationships; PMM holds program and service delivery data. The two share the Contact object as the bridge: a Contact in the org can be both a donor (with Opportunities through NPSP) and a client (with Program Engagements through PMM). For Nonprofit Cloud users, PMM is being incrementally absorbed into the broader Nonprofit Cloud data model with similar objects under different names. The shared Contact lets nonprofits build a 360-degree constituent view: who gives, who volunteers, who is served, who is all three. This integrated view is the strategic value of running multiple Salesforce nonprofit products together.
Implementation pacing and the typical adoption curve
PMM implementations are smaller in scope than full NPSP or Nonprofit Cloud projects but still take focused work. The typical pacing is: weeks one to four for data model setup (Programs, Cohorts, Schedules); weeks five to eight for the operational workflow (attendance capture, engagement tracking); weeks nine to twelve for reporting and dashboards. The biggest risk is over-engineering the data model at the start; PMM ships an opinionated structure that fits most nonprofits, and customizing it heavily before live operations begin produces complexity that the staff cannot maintain. Mature implementations launch with the out-of-the-box structure plus a small set of org-specific custom fields, then iterate based on actual operational needs. PMM is free, so the budget pressure on the project is light, but staff time is not free; pace the project realistically.
Implementing Program Management Module for a nonprofit operations team
Implementing PMM is a multi-month project that combines configuration, training, and ongoing operational discipline. The four-phase routine covers: install the package and configure the basic objects, design the Program structure with the operational team, build the service delivery capture workflow, and operationalize reporting for staff and funders. PMM is free but staff time is not; pace the project realistically and resist over-engineering the data model before live operations begin.
- Install PMM and configure the basic objects
From Salesforce Setup, install the Program Management Module managed package from the Salesforce.org distribution. Confirm the package installs cleanly and the new objects (Program, Program Engagement, Service Schedule, Service Delivery) appear in Object Manager. Assign the relevant permission sets to the staff who will use the module: program coordinators, service delivery staff, evaluation staff. Configure the basic page layouts for each object to match your operational vocabulary; PMM ships with generic field labels that you may want to customize (Student instead of Participant, Class instead of Session). Document the customizations in the runbook.
- Design the Program structure with the operational team
Work with program coordinators to map your nonprofit programs into PMM structure. Each top-level program becomes a Program record. Cohorts (Fall 2025 Job Readiness, Spring 2026 Job Readiness) become Program Cohort records. Service schedules (the weekly class times) become Service Schedule records. Validate the mapping with the actual coordinators who will use the system; PMM mappings that look right on paper sometimes do not match how the program actually operates. Iterate before going live. Document the mapping in the program operations runbook so future coordinators inherit the structure.
- Build the service delivery capture workflow
Pick the capture path that fits your operation. For classroom-based programs, a coordinator-facing roster page where staff check off attendance after each session works well. For drop-in services (food pantry, walk-in counseling), a kiosk or mobile app where clients check in at arrival works better. For field-based programs (home visits, outreach), the Salesforce Mobile App with offline capability is the path. Implement the chosen workflow as a custom Lightning record page or a Flow-driven screen. Train staff on the capture process; the workflow has to be fast and unambiguous, or staff will skip it and the reporting data quality collapses.
- Operationalize reporting for staff and funders
Build the standard PMM reports for daily and weekly operational use: today expected service deliveries, attendance rate by cohort, engagements approaching their end date. Build a Program Manager dashboard combining these reports. Build the grant-specific reports each funder requires; coordinate with grants management staff to ensure the metrics and the report formats match the funder requirements. Schedule the grant reports to email to the appropriate staff before the funder deadline. Train the program team on reading the reports and acting on the metrics; the data is only useful if the team consumes it regularly.
- PMM is free, but staff time is not. Pace implementations realistically; over-engineering the data model before live operations begin produces complexity the staff cannot maintain.
- Service Delivery capture quality determines reporting quality. Sloppy capture produces grant reports that misrepresent the nonprofit work, with real funding consequences.
- PMM and NPSP coexist through the shared Contact object. Plan the relationship explicitly; without coordination, donor data and client data drift apart and the constituent 360 view breaks.
- PMM is being incrementally absorbed into Nonprofit Cloud. For new implementations on Nonprofit Cloud, use the equivalent Nonprofit Cloud objects rather than installing PMM separately.
- Grant reporting requirements vary by funder. Each funder has specific metrics and formats; build grant-specific reports during implementation, not after the first reporting deadline.
Trust & references
Straight from the source - Salesforce's reference material on Program Management Module.
- Program Management Module OverviewSalesforce Help
- Nonprofit Success Pack OverviewSalesforce Help
- Nonprofit Cloud OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Program Management Module?
Q2. Who uses it?
Q3. Why is program tracking valuable?
Discussion
Loading discussion…